inmarket

When you commented out the fillarea calls you forgot to also comment out the if statement just before it. The if statement still being there is causing the following if statement to also be conditioned. Comment out the if statement just before the commented out fillarea statements and I suspect it will work.

This has been updated in the repository. Thanks for bringing it to our notice.

I am sorry we only support English on this forum. This is both for our ease (although we also understand some other languages) but also so that others can also make use of any information or answers to your post. Google translate normally does a good enough job of converting to English.

This is definitely more advanced uGFX functionality and uGFXStudio knows nothing of users so you would need to implement this yourself. Let me suggest again that the best approach for screendumps for manuals etc is to run your uGFX program on the Win32 emulator and then use the windows screen capture tools. I'm sure the same could be done using the Linux and X combination if that is your preferred development platform.

From an application that is currently not possible. Remember that uGFX is designed for small embedded processors that often cannot read their own framebuffer. If you want to draw onto a "virtual" display and then save that into a BMP file that is possible. Look at pixmaps. You will still need to do the BMP encoding yourself but you can use GFILE to save it to an SDCard. If you are just after screenshots for a demo of your product (or something similar), the easiest way is to compile and run your uGFX program on the win32 platform. You can then use the windows snipping tool to take screenshots of what is happening.

Given that this seems to be font size dependant my guess is that it is the encoder having the problem as the decoder built into uGFX is font size agnostic. Other than saying that, I have not heard of similar problems. Perhaps try using the win32 version of the encoder and also try the online converter to see if they give the same result. There have been minor bugs fixed over time so also check that you are using the latest version from the repository.

There is probably something wrong with your file system permissions as per the error message.

The way you have used the gdisp driver is incorrect. It cannot be copied to the src directory - that just won't work. Please reread the instructions again on how to do this properly.

Well done on finding the problem!

All things are possible - and this "thing" would not be hard. It is however not on our development agenda currently as it is not difficult for a user to get a running project with the makefile buuld system or with the single-file-make option. We are currently resources constrained and we are putting all our efforts into releasing uGFX V3.0

You have definitely not included the driver correctly. That is exactly what that error message you are seeing is saying. It is telling you that the color system has not been defined. The color system is defined by the proper inclusion of the driver. Please reread the instructions carefully.

Yep. Exactly correct. Much easier to use than a FreeRTOS semaphore.

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.