inmarket
-
Posts
1,296 -
Joined
-
Last visited
-
Days Won
4
Content Type
Forums
Store
Downloads
Blogs
Posts posted by inmarket
-
-
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 TRUEto 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.
MCUFont Glyph Character Codepoint Mix-Up
in Support
Posted
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.