Joel Bodenmann

Hello pgis and welcome to the community! We are happy to hear that you got everything working. Great job! The warnings you are getting are nothing to worry about. Those won't bug you in the future. We just got our hands on a Keil µVision 5 license a couple of days ago and we are using uGFX with Keil without any problems. The warnings you are getting don't show up with GCC and that is the compiler that we mostly use. However, now that we are using Keil ourselves we will definitely look into resolving those issues. ~ Tectu

No worries, we didn't take this as complains and we are very happy for any kind of feedback. Especially as this one is so well structured Please keep it coming. It is in our own interest to fix every possible issue with the project. We will put everything onto the ToDo list - we are currently just working very slowly. Update: We added the IAR and EDG compiler to the list of suported compilers and added the #pragmas required to handle the warnings:

I would recommend you downloading the official ST demo for the STM32F429 discovery board and getting that one running. Once you have that demo running it is just a matter of throwing out the ST demo application code and include the uGFX files as the drivers already exist. All you have left to do is writing the actual board files and you can take the STM32F746-Discovery board files as a template as the hardware is very similar. ~ Tectu

FreeRTOS is the second most used port of uGFX and it is known to work without any issues at all. We even support advanced FreeRTOS features such as FreeRTOS+Trace. However, we can't supply you with a ready to run demo and neither do we for any other available ports. That uGFX contains a port for operating system XYZ means that you can just enable it in the configuration file and 99% of the rest is done for you (eg. in RAW32 you have to implement two functions to convert system ticks to milliseconds, that's the 1% we can't do for you). The variations for different hardware platforms, RTOSes, library configuration and compilers are just way too many to include any ready-to-run example. Also, we will never ever include any RTOS as 3rd party source into the library. With ChibiOS/RT it is just a whole lot easier because ChibiOS/RT comes with it's own Makefile build system. We can simply include the ChibiOS/RT Makefile in our own Makefile and you have a ready to run demo where you just have to type 'make'. FreeRTOS on the other hand doesn't come with a "default build system" so we can't provide such an easy-to-use feature. The general workflow is always: Get the operating system that you want to use running on your platform and then add uGFX. As soon as you have a running OS adding uGFX is just a matter of a few minutes. In case of RAW32 it is the same - you need to have a working minimal example for your platform and then you just add uGFX to it which is usually a matter of a few minutes. When working bare-metal with an STM32 you need to grab some of the ST examples - they come ready to build specific for each board and compiler and include the necessary startup code and linker scripts. Then just add uGFX and you are ready to go. tl;dr: There are way way way way to many different combinations of platforms, compilers, underlying systems and so on. We can't provide an example for each of them so we focus on making it easy to integrate the uGFX library in an existing project. ~ Tectu

Hello Ross and welcome to the community! The uGFX repository doesn't come with any of the operating systems it can run on, you have to supply those yourself! It's the same with ChibiOS/RT: There are many examples ready to be used with ChibiOS/RT but the ChibiOS/RT itself is not part of the uGFX repository - you have to supply that yourself. The normal workflow is getting the underlying operating system (FreeRTOS) in your case up and running before you add uGFX to it. The FreeRTOS port that comes with uGFX is known to be working with FreeRTOS versions 7.x and 8.x. A little side note: The Raspberry Pi port and example that you can find in our repository was not written nor tested by us. It was supplied by a user from this form. Maybe you want to contact him. His user name is macload1. When I remember correctly he put some videos on youtube that might contain a link to the project. I hope that helps. ~ Tectu

Sorry for the late reply. We are currently very busy and sadly we have to handle support request of the paying customers with a higher priority so usually we moderate this forum during our spare time (when we get to it). I never used the STM32F429i-Discovery board bare metal myself but I gave the schematics a quick look. PA9 and PA10 are definitely not used for the display/touchscreen and I am not sure why those definitions are in the board file. They should not have any effect and you should be able to just remove them without any issues. Anyway, you cannot use the ChibiOS/RT board files when you are not using ChibiOS/RT. You have to implement your own board files. For this, copy the \drivers\gdisp\STM32F429iDiscovery\board_STM32F429iDiscovery_template.h file to your project directory (remove the _template part of it) and implement the corresponding functions. The board files that we provide are for use with ChibiOS/RT only. When using your own library/HAL you have to make sure that all peripherals and pins are configured correctly. ~ Tectu

Thank you for sharing your experience! Note that there is a macro called GFX_OS_NO_INIT in the configuration file. If you set that to TRUE then gfxInit() will not automatically call the chSysInit() and halInit() functions. Furthermore, note that we provide a high-level makefile for using uGFX with ChibiOS. That file is a lot shorter than the ChibiOS Makefile and keeps things clear and tidy. You can find those in the various /boards/base/xxx/example_* directories. The STM32F429i-Discovery board file comes with an example for both ChibiOS/RT 2.x and ChibiOS/RT 3.x. Why three functions? There should only be two functions you have to implement yourself: gfxSystemTicks() and gfxMillisecondsToTicks(). Generally speaking uGFX should run out of the box on a bare-metal system when you select the RAW32 operating system in the configuration file and implement the two functions mentioned above. uGFX is widely used on bare-metal systems without any known issues. However, please note: We implemented a new scheduler a few months ago. Please use the latest master branch and not the latest stable release. The new scheduler allows you to either select the generic setjmp()/longjmp() scheduler or the specific Cortex-Mx scheduler. You can find more information about this here: http://wiki.ugfx.org/index.php?title=GOS ~ Tectu

Thank you for your offering. We might get back to that. However, we plan to release a custom desktop application in the future as the web based converter didn't play out that well after all. ~ Tectu

Thank you for letting us know that you got it working! We will try to write a dedicated desktop app for this in the future. But right know we have to get some other stuff done first. ~ Tectu

Please use the forum search (and wiki search if appropriate) to check whether your question has already been asked. This safes you a lot of time because you don't have to wait for an answer and it keeps the forum clean That being said, your question was already asked a few days ago: viewtopic.php?f=23&t=267 ~ Tectu

Sorry, I am not sure: Is this a question or are you sharing your results? Did you get your display running yet? ~ Tectu

Unicode is supported. We even got a video of a GUI using cyrillic fonts in your demos section: However, there is no support for RTL at all. You can find more information here: http://wiki.ugfx.org/index.php?title=Font_rendering ~ Tectu

I don't know the underlying system that you are using but your board file seems to be mostly fine. The thing you really want to change is setting the DC pin in write_data() as well in case of anything happens between write_index() and write_data(). Usually it is also a good idea to start with a lower bus frequency to rule out any wiring related issues. I would recommend you to grab a logic analyzer to see whether the data is sent via SPI properly. ~ Tectu

4.9 is quite a recent release. This must be something else in that case. To your compilation issue: This can either be related to your changes or due to the fact that you didn't properly include a display driver. Please make sure that you properly include/select/define the ILI9341 driver (how you do this depends on many factors such as your build system, whether it is a custom board or an already existing one and so on). ~ Tectu

That is a perfectly valid line of C code. Try removing one of the const until it compiles. And in the meantime please let us know which version of the g++ compiler you are using. We never experienced any issues but one and that was related to a very very very ancient compiler. ~ Tectu

Glad to hear that you finally managed to get your project compiling. We hope that everything else works out for you. ~ Tectu

The function gdisp_lld_draw_pixel() is a function that is part of the GDISP board file. If you get this error the linker couldn't find a valid board file. In order to use a custom board file that is part of the project/application all you have to do is placing the board file in your project directory and making sure that it gets compiled (the path containing the board file must be in your include path (usually INCDIR, INCS or something similar when using a Makefile). Note that you must not define the GFXBOARD variable in your board file when using a custom board file. Just leave the variable empty or don't declare it at all in your makefile. ~ Tectu

Can you be more specific? uGFX was designed to be used in C++ programs and we have many customers who use uGFX in a C++ environment, none of which ever reported any serious issues. ~ Tectu

Yes, that is exactly it. All you need to do know when implementing an uGFX port is wrapping the uGFX functions such as gfxAlloc() and gfxFree() around those ualloc calls. That is usually just a matter of either a macro or a simple one-line function. Eg. here you can see how it is done for FreeRTOS and ChibiOS/RT. It really just is a matter of forwarding the calls: #define gfxAlloc(sz) chHeapAlloc(0, sz) #define gfxFree(ptr) chHeapFree(ptr) ~ Tectu

uGFX internally uses mcufont as the author of mcufont was kind enough to provide us with a public domain license so we can include it in uGFX. The mcufont repository provides the sources for the font encoder. You can try building the binary from the sources. ~ Tectu

Minar doesn't seem to be a pre-emptive scheduler and that can lead to serious performance issues in case of uGFX. However, uGFX comes with an optional built-in scheduler which you can use. The scheduler is optimizable: It either uses setjmp()/longjmp() or you can supply your own context switching (assembly) code. We already implemented the optimized custom schedulers for all Cortex-M microcontrollers. Note: In case of MbedOS doesn't provide a memory manager either we have an optional built-in one as well. We provide a port called RAW32 which uses both the built-in scheduler and the build-in memory manager. If you want to use the memory manager of MbedOS (in case of it has one) then you can just copy the RAW32 port and throw out the memory manager part. In either case I would recommend you to create a new port called MbedOS. This way you can share the port and other users might be quite thankful for that ~ Tectu

Our server was recently updated and the update included a new PHP version. It looks like the update broke the font converter. Unfortunately we are currently very busy and we won't have time to look into this ASAP. We are currently thinking of either writing a dedicated desktop application for this or include the functionality into the uGFX-Studio. We are sorry for the inconvenience. ~ Tectu

Hello Mathias and welcome to the community! The SSD2119 driver is already part of uGFX and therefore you won't have much to do. And in case of you're using the standard STM32F4-Discovery + Embest STM32-DMSTF4BB there is nothing to do at all as the board files for this development board already exists as well. If you are working with a different setup all you have to do is implementing the board file for the SSD2119 driver. Copy the /drivers/gdisp/SSD2119/board_SSD2119_template.h file to your project, name it board_SSD2119 and implement the functions accordingly. Everything else is already done for you. I hope that helps. ~ Tectu

Hello vahid4134 and welcome to the community! You can use uGFX on top of any platform. However, uGFX doesn't come with a MbedOS port (yet). This means that you have to write a port yourself to make it work. Writing a port is not as hard as it sounds as everything you have to implement is in one place (the GOS module) and there are more than enough existing ports that can serve as examples. Furthermore, the interface is well documented. We also port uGFX to other platforms for customers as part of a commercial support contract. Kind regards, ~ Tectu

And with that uGFX comes with 43 built-in drivers for displays, touchscreens and audio 8-) Good work guys, keep it up! ~ Tectu