Joel Bodenmann

Hello woodstock and welcome to the community! Thank you for bringing this to our attention. We just fixed it: https://bitbucket.org/Tectu/ugfx/commit ... 3af9acbf6e We appreciate your contribution. Regarding file uploads: I just double checked and file uploads are definitely allowed. However, as you mentioned that you uploaded the patch file we assume that it was a *.patch extension which was not whitelisted. We added this extension to the list of allowed extensions. For the future: You can get around that filter by just wrapping everything inside a ZIP archive Regarding contributions: What you did is certainly fine and the world would be a better place if everybody would be that thorough like you. The most important things are: Detailed explanation of what is wrong / what changed / what feature was added and a short test case that either allows to reproduce the problem or demonstrating the new feature Adding information about the used toolchain, platform, etc. Uploading a patch file to the forum post Pull requests certainly work as well but personally we prefer to have a bare patch file attached to a forum post. ~ Tectu

uGFX now comes with a CMSIS RTOS port so the library can run on any CMSIS RTOS compatible RTOS. We provide specific support for Keil RTX but it's just an alias that will enable the CMSIS RTOS port. ~ Tectu

The online font-converter is up and running again. Thank you for reporting the issue. ~ Tectu

The online font converter is up and running again. Thank you for reporting this issue. ~ Tectu

To clarify: These are the API functions for the display power management: http://wiki.ugfx.org/index.php?title=GD ... er_control The display driver needs to implement these features in the gdisp_lld_control() functions but for a driver implementation it is of course not mandatory to handle them and as inmarket already mentioned we haven't implemented those for each display controller. Here you can see a working implementation for the SSD1289: https://bitbucket.org/Tectu/ugfx/src/50 ... 1289.c-279 When looking at the GDISP driver for the STM23F429i-Discovery board you will see that this driver doesn't implement that function at all. If you have any questions regarding the implementation of that function please do not hesitate to ask. ~ Tectu

We never used a monochrome or grayscale display with the STM32 LTDC ourselves but I gave the STM32F4xx reference manual a quick look and it indeed looks like the L8 mode is what you would want to be using for that. In either way I assure you that it will be no problem to use a monochrome or grayscale display with your STM32F429 and uGFX. Please note that you ARE NOT SUPPOSED TO use the STM32F429iDiscovery GDISP driver unless that is the board you are really using. Please use the generic STM32LTDC driver instead. The reason is that the display used on the STM32F429i-Discovery board needs to be initialized via SPI before the LTDC can be used. ~ Tectu

I cannot tell you that for sure but most likely yes. We are using the ILI9341 driver successfully on an ILI9342 display controller. When I understand correctly the last number is a feature-count number. We would recommend you to copy the ILI9341 driver, rename everything to ILI9340 and give it a try. This way you can make adjustments if necessary and we can add the ILI9340 driver to the list of supported display controllers Let us know when you have any other questions. ~ Tectu

I am not sure what your question really is. uGFX supports many different color formats and you select the one that your driver uses in the drivers configuration file. In your case you can just GDISP_PIXELFORMAT_MONO (or GDISP_PIXELFORMAT_GRAY* in case of you have a grayscale display) and everything else will be taken care of for you. ~ Tectu

Hello harshavardhan and welcome to the community! 1) We are looking into fixing the issue with the font converter right now. We hope that it will be going in a couple of hours/days again 2) Right now uGFX doesn't come with built-in image decoders for JPG and PNG files (because they are heavy (in CPU terms) compared to BMP and GIF and therefore not the first choice for most applications). However, the uGFX library is very modular and you can plug-in your own image decoders. 3) uGFX doesn't know the difference between capacitive and resistive touchscreens. That is abstracted behind the touchscreen driver. To actually answer your question: Yes, uGFX can handle both resistive and capcitive touchscreens. ~ Tectu

I am not sure what the I2C peripheral on your display controller is there for as I couldn't find a datasheet. However, there are other display controllers that need to be configured before a particular interface can be used. For example, the ILI9341 that you can find on the STM32F429i-Discovery board needs to be configured via SPI before the RGB interface can be used. It is very well possible to cleanly encapsulate such behavior in the display driver & board files of the uGFX GDISP driver interface. ~ Tectu

Yes, that article should contain all the necessary information to write your own display driver and board files. To use your display with uGFX you need to do two things: Write a display driver Write a board file Display Driver The display driver is represented by a folder in /drivers/gdisp. The display driver is the part that knows how to initialize the controller and how to manipulate the frame buffer content. There are three different types of how to implement a display driver and the wiki article you linked explains all three of them. Which one you are going to use depends on your display controller. Without knowing the A913 that you are mentioning I am pretty sure that you will want to write a driver using the Window Model. Important: The display driver itself does NOT know how to talk to the actual display. It contains functions like write_cmd() and write_data() or similar, but it does not know how to communicate to the actual hardware. Note: The display driver implements the interface specified in /src/gdisp/gdisp_driver.h. Board file The board file contains the actual interface to the hardware. It just implements the functions that the display driver is using. For example the display driver will call write_cmd(uint8_t cmd) from the board file. The implementation of that function in the board file will make sure that the display controller is in write mode and write the actual cmd value to the interface. In your case it would just put that value on the FSMC bus. We strongly recommend taking a look at some existing drivers such as the SSD1289 or the ILI9341 to get some inspiration on how things should look at the end. I hope that helps. Let us know when you have any additional questions. ~ Tectu

Hello Ilya and welcome to the community! We strongly recommend you to create a working ChibiOS + uGFX project before you start using the files generated by the uGFX-Studio. These two guides will lead you through the process: Getting Started Using ChibiStudio Note that in your case you will also have to write a display driver for the R61505 because we don't provide a driver for that display controller yet. To get started, we recommend using the TestStub driver. It is an empty driver that allows you to compile a project without errors so you know that your project and toolchains are set up correctly. Before starting to write your own driver we recommend taking a look at a few of the existing drivers which you can find under /drivers/gdisp/ and also reading this article: http://wiki.ugfx.org/index.php?title=Di ... iver_Model I hope that helps. ~ Tectu

Hello tupak and welcome to the community! uGFX works out of the box with ChibiOS/RT 2.x and ChibiOS/RT 3.x After all uGFX started out as an official extension to ChibiOS/RT as part of the ChibiOS project ~ Tectu

If this is a problem related to the code generated by the uGFX-Studio then please ask for advice in the appropriate forum. Also, please use code tags in the future if you want to include code or compiler output logs in your posts. The forum is also a source of knowledge for other people when they use the forum search trying to find an answer for their problem. Therefore we want to keep this forum as structured and organized as possible Generally having one "support thread per user" is not a helpful approach in that regard. ~ Tectu

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