inmarket

1. This sort of thing is deep in the FreeRTOS code so really has nothing to do with uGFX. If #2 below fails you will need to seek help from the FreeRTOS forums. 2. Where you might be coming unstuck is if your main thread stack is too small. Again this is a FreeRTOS setting. What gives this indication is your comment on something pointing to the wrong memory area.

Use gfxMutux objects and calls instead. 1. It is portable to any uGFX supported os. 2. It prevents errors in coding as gfxMutex's are easier to use than FreeRTOS semaphore calls.

There are really only four possibilities... 1. The FreeRTOS semaphore functions aren't working properly. To ensure its not a coding error try using the gfxMutex object and calls instead. That way you can also remove the loop, just use the mutex enter and exit calls with no timeout. 2. A bus_release is not being called when it should be effectively causing the bus to remain locked thus preventing drawing. 3. There is a call to the hardware that is not surrounded by the mutex and that is causing contention. 4. You are suitably protecting the bus however you aren't getting the chip selects etc correct. Eg if the display and touch chip selects somehow both end up set or unset simultaneously. It could also be a chip select timing issue.

Option 1 from Joel's list above is the most obvious and most portable solution.

The fact that draw routines are being called but nothing is displaying, especially the crosses, indicates that perhaps only certain drawing operations are working. Please start with some of the gdisp module demos just to make sure all drawing operations including text are working properly. If they are working properly my guess is that sometimes the bus is not being released thus stopping the drawing from continuing.

I will check the repository code later today.

It appears that you have not implemented your board_ST7735.h properly as that is where those routines are defined.

Check the font is successfully opened.

I suspect that something else is going on as the driver structure is allocated and initialised to zeros before gdisp_lld_init is called. On the other hand the private area PRIV() is allocated and initialised by the driver in gdisp_lld_init.

It sounds like your path is not set correctly. "mkdir" is built into the windows command shell (cmd.exe) and is an external utility for cygwin bash. The fact that it is missing means something is wrong with your path.

There is now a new wiki article introducing the changes for V3.0 https://wiki.ugfx.io/index.php/Changes_from_V2.x_to_V3.0 This wiki article will expand with more detail as we get closer to the V3.0 release.

Can you please give us the exact version of the Keil compiler, and whether you are using it in ARMCC compile mode (the default) or GCC compiler mode. What would also help is if you add #define GFX_SHOW_COMPILER TRUE to your gfxconf.h It will display a warning about what it auto-detected the compiler as. This will help us track down what is causing the incompatibility.

I just checked the repository and it was a problem there too. I have now fixed it in the repository.

You also don't need to add GDISP_DRIVER_LIST to your gfxconf.h as the ST7789V driver is the only driver in the system

The STM32LTDC based board files have been updated in the repository.

Don't forget the main thread stack size (which is normally part of your board linker script or part of your operating system initialisation).

Make sure you are using the latest repository version as this bug may be fixed. If not, just add the g parameter to that call and where it is used. I will check the repository later and if it is wrong there I will fix it.

My guess is that the include path does not contain the driver directory (the directory containing the gdisp_lld_ST7789V.c file). Check that first. Don't forget to do a rebuild all afterwards if it wasn't there. If that is fine, the next step would be to debug into the gfxInit call to get some idea on why you are not getting to the gdisp_lld_init call.

Yes it does. If you look at the existing gdisp drivers you will see that they make a bus_aquire call and a bus_release call which are normally implemented in the board file. These calls are there so that they can be used to get exclusive access to the bus. Where the bus is not being shared with another device these calls can be simply ignored. So from the gdisp side that is what you need to use. From the touch side there is typically only the one call made. This call must also obtain exclusive access to the bus. If the bus is busy (due to a gdisp call) then gfxYield() can be called in a loop until the bus becomes available. Well done on getting what you have working!

This sounds like you are over-running your stack and therefore modifying unrelated data structures. Please check your stack sizes carefully.

Yep. That works too. Well done.

There is another simpler way... Listen for the toggle event in your main event loop and when you get it manually change tabs.

Correct. The board file is not portable. The driver is portable but not the board file. The board file is supposed to be specific to your particular board so it is not surprising that a board file from a different processor won't compiler. The board file is what you should be customising to get the toggle driver working for your board. Off the top of my head I can't remember if tabsets support toggles. Have a look at the source code and see if the toggle entries are set to anything in the vmt structure initialisation. If it is not supported yet they values will be zero.

The SAM7 toggle driver actually uses ChibiOS gpio calls. This should be completely portable to the stmf4 using chibiOS except that the corresponding board file will need to change the pin descriptions. Usually a hang straight after calibration is an indication that threading is not working. Please make sure the demo runs fine with ginput_need_toggle turned off first.

Not easily. Double buffering is never easy.