Joel Bodenmann

Well, both ChibiOS/RT 2.x and 3.x are officially supported by uGFX. However, as you just demonstrated there are always some hidden things that got missing during the process. This happens because it's nearly impossible for us to compile every feature for every given platform. Anyway: Thank you very much for your patch. We just pushed that one to the repository (but we didn't test it. If you can give it a final test that would be great). I am not sure what your code snipped is about. The support for ChibiOS 2.x and ChibiOS 3.x is implemented into /src/gos/gos_chibios.[ch] using the method you demonstrated (with checking for the CH_KERNEL_MAJOR macro). Changing the definition of anything that has been defined in ChibiOS/RT itself is definitely a bad approach. We really enjoy the patches that you are delivering. It makes life a whole lot easier for us. Please keep up the good work! ~ Tectu

Hello Sergej, We will have a look at your timings this Wednesday afternoon. Sorry for the delay - we are currently very busy. ~ Tectu

Hello Andre and welcome to the community! Thank you for your positive feedback. We are happy to hear that you like uGFX. Regarding the calibration issue: This is indeed a bug. You Are completely right, the two calculations need to be independent from each other. We just pushed a fix as per your suggestion: https://bitbucket.org/Tectu/ugfx/commit ... d7eaa3eb6a Thank you for your contribution! ~ Tectu

We just added some documentation for widget styles to the wiki: http://wiki.ugfx.org/index.php?title=Wi ... dget_Style ~ Tectu

Definitely not a stupid question The default rendering function of the label widget uses the text color of the currently active widget style. Therefore, In order to set an individual text color to a label widget you have to create a widget style and apply it to the label widget using gwinSetStyle(). Writing this I just realize that there is no article in the wiki explaining widget styles... I put that on our ToDo list. Until then: Have a look at the two default built-in widget styles to see how you can create them: https://bitbucket.org/Tectu/ugfx/src/69 ... idget.c-29 As you can see a widget style is nothing but a struct containing a bunch of colors. Note 1: In a similar fashion you can apply a specific font to your label so the label uses a font different than the GWIN default font. For this, use gwinSetFont(). Note 2: If you want to have some more control over the look of your widgets you can always create a custom rendering routine and apply it to either one or multiple widgets of the same type. This article will help you writing your own rendering function: http://wiki.ugfx.org/index.php?title=Cr ... ng_routine Note 3: The uGFX-Studio already provides a GUI to create your own widget styles and generates the code for you. If you have any questions regarding the implementation of widget styles or the implementation of custom rendering functions please do not hesitate to ask. ~ Tectu

An optional word-wrapping feature has just been added. More information can be found her: http://wiki.ugfx.org/index.php?title=Font_rendering Many thanks to Koryagin Dmitry (dkoryagin over at BitBucket) for this contribution. ~ Tectu

We just pushed your patch. Thank you once again! ~ Tectu

I assume that you understand that there are two different interfaces: The MCU interface and the RGB interface. The RGB interface allows you to directly stream pixel information from a frame buffer (eg. the LTDC of an STM32). However, you still need the MCU interface to first configure the display controller. Page 45 in the datasheet mentions that you have to use the SPI interface for that - are you doing that? I didn't find anything in your initialization code that seems to be wrong. Even the timings are spot-on. Can you give a few more information about the microcontroller side of your hardware? Are you sure that the microcontroller that you are using is capable of driving an RGB panel in 3x 6-bit mode? Did you verify that the timings are set up correctly in the microcontroller too? Can you verify that the microcontroller is properly generating the VSYNC, HSYNC and DOTCLK signals? There is a timing diagram for the 18-bit RGB interface in the datasheet on page 49. I would recommend you to grab your logic analyzer / oscilloscope and having a look. ~ Tectu

Thank you for your second patch. We will merge that ASAP. Generally we prefer one thread per incident to keep things clean. After all threads don't cost anything Thanks again for your contributions. They are very appreciated! ~ Tectu

It's already very good to know that you got it working in the two other modes. This way we know that it is an initialization issue for sure. I'll take a look at the datasheet tonight and compare it to your initialization code. Sorry for the delay. ~ Tectu

Hello ASergej and welcome to the community! Right now I don't have the time to look at the datasheet and I don't know the proper initialization codes for the 6-Bit mode out of my head. Is this a custom board or is this a dev-board that you bought? If it is a dev-board I would highly recommend you grabbing the initialization code from the example(s) that came with the board and putting those into the init() call of the GDISP driver. Did you also check with a logic analyzer whether the data is sent properly? Another thing that usually helps is to lower the clock frequency to something below 1 MHz in order to minimize the odds of hardware issues. I will take a look at the datasheet and your initialization code tonight. ~ Tectu

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