Joel Bodenmann

Thank you for bringing this to our attention. This is a stupid issue introduced by me because I was being stupid and didn't think this through. Let me explain: The reason I added the check for GFX_COMPILER_KEIL and GFX_COMPILER_ARMCC to the define of TRUE was, because I couldn't compile otherwise becaus ethe ARMCC/Keil preprocessor screwed some things up and the #if checks didn't work properly. It was a long night and I wanted to get this done before bed time so that Keil support would finally be completed. I took a look at the documentation and it seemed like Keil/ARMCC uses a define of 1 for TRUE by default. Keen to just get this fixed ASAP I decided to add that conditional #define for TRUE in gfx.h. Now that you mentioned this I gave everything a 2nd look and I forgot to include src/gos/gos_options.h in the commit ff01cc0 that you mentioned. Therfore, the GFX_COMPILER_KEIL and GFX_COMPILER_ARMCC macros were not initialized ans as you mentioned they will be treated as a certain default value which resulted in having huge #if problems down the line. Initializing the GFX_COMPILER_KEIL and GFX_COMPILER_ARMCC macros properly in src/gos/gos_options.h makes this problem going away and everything is working as it should. Can you please grab the latest master and check whether everything works now as expected for you too? Sorry for this trouble. Please don't tell this inmarket. I'd prefer to stay alive ~ Tectu

I am not completely sure (it has been a long day, too tired for much thinking) but yes, I think that could be feasible. If you can give it a go that would be great! ~ Tectu

We're proud to announce that uGFX Version 2.4 was released just moments ago. Download The 2.4 release can now be downloaded as a ZIP archive form the downloads section. If you're a student or hobbyist and therefore permitted to use uGFX free of charge please consider donating to the project to help us developing this library. Donations can be submitted through the PayPal donation button on the downloads page. Changelog Let's have a look at the change log: FIX: Add missing stm32m3 cpu makefile option. Update doc to match. FEATURE: Added ability to compile ugfx as a single file. Simply compile src/gfx_mk.c FEATURE: Added GFXSINGLEMAKE=yes|no to the ugfx makefile to compile ugfx as a single file. FEATURE: New board STM32F746G-Discovery FEATURE: New gdisp driver STM32LTDC FEATURE: Better support for Raw32 platforms FEATURE: Renaming GFX_NO_OS_INIT to GFX_OS_NO_INIT FEATURE: New demo applications/combo FEATURE: Adding more font metrics (BaselineX and BaselineY) FEATURE: Adding gdispGetStringWidthCount() FEATURE: Implementing widget focusing. See gwinSetFocus() and gwinGetFocus() FEATURE: Adding TextEdit widget FEATURE: Added color to widget style for focused widgets FEATURE: Added GWIN_FOCUS_HIGHLIGHT_WIDTH as an option in the configuration file FEATURE: Added support for CMSIS RTOS FEATURE: Added support for KEIL RTX FEATURE: Replace all references to inline with a reference to GFXINLINE FEATURE: Added config option GFX_NO_INLINE to run off inlining of ugfx functions. FEATURE: Added word-wrapping support for gdispDrawStringBox() and gdispFillStringBox() FIX: Fixing issue in touchscreen calibration code FEATURE: Added GFX_OS_PRE_INIT_FUNCTION for early hardware initialization FIX: Fixing GTIMER for high clock rate devices FEATURE: Added GFX_COMPILER_KEIL and GFX_COMPILER_ARMCC macros Beside many fixes and general improvements some new features have been added to the library: Text Wrapping A text wrapping option (GDISP_NEED_TEXT_WORDWRAP has been added. The string drawing functions that specify a box (gdispDrawStringBox() and gdispFillStringBox() automatically wrap the text to the next line if it exceeds the right border of the specified box. If this feature is disabled (default behavior), the string is simply cut off. Text Input Widget We added a new widget called the TextEdit widget. The TextEdit widget allows the user of an µGFX application to enter text. It is basically pretty much like a label just that it accepts text input. Due to the modularity of the GINPUT module the TextEdit widget can either be used together with a real physical keyboard or a the virtual on-screen keyboard widget. Widget Focus When keyboard support is enabled, the GWIN module provides a new focus feature. A widget that has focus will receive keyboard events. By default, a simple rectangle with the color specified in the widget style will be rendered around the widget to show that a widget has focus. The thickness of that border can be changed through the GWIN_FOCUS_HIGHLIGHT_WIDTH setting. We also added default keyboard event handlers for most widgets. Therefore, if keyboard support is enabled a button can not only be clicked using the touchscreen but also using the SPACE and the ENTER key. A list can be scrolled using arrow keys and so on. The widget focus can either be changed by clicking the widget or by using the TAB key to loop through them. Programmatically the focus can be changed using gwinSetFocus(). BareMetal Platforms We re-worked most of the RAW32 port (the port that is used to run on bare-metal systems). It is now a lot more flexible and supports even a wider range of CPU architectures. If you are running µGFX on a bare metal system updating to the new version is strongly recommended. Keil RTX (and CMSIS RTOS) Platforms We implemented a new GOS port that allows to run µGFX on any CMSIS RTOS compatible RTOS. Especially we implemented a port to run on the Keil RTX operating system (which is CMSIS RTOS compatible). Single File Inclusion Many of you told us that the µGFX library is difficult to use when not working with the Makefile build system as the library is composed of many file split across many directories. The new library version fixes this issue. All that needs to be done is adding the top-level uGFX directory to the include path and compiling just one file: gfx_mk.c. All required files will automatically be #included. We will put up a more detailed guide about this on the wiki shortly. Stay tuned. Feedback This release contains, as any other release, many bug fixes and new features that were contributed or requested by the µGFX users. Comments and any kind of feedback are welcomed as those help us to improve the µGFX library. ~ Tectu

Hello jayjian and welcome to the community! To your original post: Yes, uGFX supports chinese character rendering due to UTF-8 support. We also had at least one customer who successfully uses uGFX with chinese fonts in the past. However, none of the uGFX developers knows chinese. Therefore, it is very difficult for us to verify that it is working properly. It seems like there are different "version" of chienese, with different encodings and even different alphabets. We already fail at the stage where we need to make sure that we got a font that can be used with a random sentence that we copied off the internet somewhere. Anyway: We downloaded a random font and a random sentence and we definitely get something displayed. Whether that is proper chinese or not - we cannot say. The characters seem to match at least and provided the fact that a chinese customer used uGFX with chinese fonts without ever complaining should mean that it can uGFX can be used to handle chinese fonts. We took some free TTF chinese font, uploaded it to the font converted, disabled the filter and got all the converted glyphs back. Seems to work so far on our side. We are sorry that we can't really help you any better. ~ Tectu

I'll get that done in a few minutes/hours. This way it will still make it into the new 2.4 release. Thank you for your contribution! ~ Tectu

Hello wolf, Thank you for testing this. The DMA2D is a periphery inside the STM32F429 that offers hardware acceleration which can hugely improve performance. For example, when you fill a rectangle (let's say you clear the display) you would normally have to setPixel() every single pixel. With the DMA2D you can just give the coordinates of a rectangle and the color that you would like to have in that window. The DMA2D periphery will automatically fill the rectangle as fast as the LTDC driver periphery allows it (eg. display panel timings) and you CPU stays free. The DMA2D also allows blitting bitmaps (the same thing but with each pixel having a different color) and other features. I just checked - we haven't implemented rotation support for the DMA2D so far, how embarrassing! For the generic STM32LTDC driver we have added the support only for the fillArea(): https://bitbucket.org/Tectu/ugfx/src/5d ... LTDC.c-375 but for the STM32F429iDiscovery driver there is no orientation support at all: https://bitbucket.org/Tectu/ugfx/src/5d ... very.c-438 Would you have the time and motivation to look into this and adding the missing cases so that gdisp_lld_fill_area() and gdisp_lld_blit_area() would work for all four orientation modes? As you can see in gdisp_lld_fill_area() of the generic STM32LTDC driver it is "just a matter" of changing three register values of the DMA2D depending on the rotations. The three registers specify the position and the size of the rectangle by providing the start address, the end address and the number of pixels per line. ~ Tectu

We have added several rendering functions to the text label that allow setting different text justifications. More information: http://wiki.ugfx.org/index.php?title=Label ~ Tectu

Hello wolf, Thank you for the very detailed bug report. Can you please disable the DMA2D support in the driver configuration file and see whether the issue persists? You can do that by setting LTDC_USE_DMA2D to FALSE in /drivers/gdisp/STM32F429iDiscovery/gdisp_lld_config.h. ~ Tectu

Hello Greg and welcome to the community! Personally I don't like having the four-wire touchscreen hooked up directly to the microcontroller. In order to read one touch point, four measurements need to be taken. The problem is that in between each measurement the pin directions need to be changed. The next problem is that just one point measurement doesn't give a usable result. Our tests showed that at least four measurements (this means 4 * 4 = 16 individual ADC samplings, swapping pin configurations between each sampling) are required for usable results. Having a very good result usually requires 8 measurements (again, 8 x 4). That takes a lot of CPU time... In fact, working with the MCU driver is the reason why there are some touchscreen related configuration options in the uGFX library such as the lazy release feature. There was just too much noise. Using an external touchscreen controller is definitely the right way to go in our opinion. These chips usually provide enhanced noise rejection filters and also generate an IRQ once the touchscreen is being touched. When connecting the four-wire touchpanel directly to the ADC of the microcontroller you will have to scan periodically yourself in order to figure out when the touchscreen is actually being touched. With an external dedicated touchscreen controller chip you can just hook the IRQ signal up to an external interrupt pin of your microcontroller (or a regular GPIO and poll it regularly). The most used & best implemented touchscreen drivers are the ADS7843 (there is a list of compatible ones on our website) and the STMPE811. Personally I prefer the STMPE811. If money is becoming an issue then the XPT2046 (that is an ADS7846) should be available for just a couple of cents. ~ Tectu

Thank you for your contribution. Every contribution is highly welcomed. We will have a look at your CalibrationTransformation improvement. ~ Tectu

Yes, you are right. GFX_NO_INLINE is missing a default value. We added that just a couple of days ago and therefore it hasn't been tested on a wide variety of systems so far. We just pushed a fix for that (the default value is defined within the GOS module as this setting has to do with support different compiler sets). Can you please pull the latest master and check that this fixes the issue? Thank you for reporting this issue. ~ Tectu

Thank you for your recommendation regarding the ChibiOS Makefiles. We will have a look at this once we get to adding official demo projects. Regarding the GFX_USE_GDISP macro: Why do you say that it is undefined? There is a default value that is set in the top-level gfx.h file: * @brief GFX Graphics Display Basic API * @details Defaults to FALSE * @note Also add the specific hardware driver to your makefile. * Eg. include $(GFXLIB)/drivers/gdisp/Nokia6610/driver.mk */ #ifndef GFX_USE_GDISP #define GFX_USE_GDISP FALSE #endif ~ Tectu

We are currently planing on creating a second, dedicated repository named uGFX-Demos or uGFX-Demo-Projects. This repository will contain many ready-to-use projects. The goal is to have working-out-of-the-box projects for the most common boards (eg. the Discovery boards) and the most common IDEs (Keil, ChibiStudio, just Makefile, ...) and most common underlying systems (ChibiOS, FreeRTOS, BareMetal, ...). However, this is a lot of work and we will most likely rely on the help of the community to not only provide a large set of projects but also to keep them working. Regarding your question: I think you didn't follow or understand the guide properly. You are missing the configuration file. The file gfxconf.h is a hard-coded include inside the uGFX code. In order to compile your project just copy the available template as described in the wiki and enable the ChibiOS support and you should have a working project that just doesn't do anything yet If you have any other questions please do not hesitate to ask. ~ Tectu

Glad to hear that you got it working. We're interested into hearing what the issue was. Sorry that we couldn't help any sooner. We are currently very busy adding support for new platforms and preparing a new release for both the studio and the actual library itself. ~ Tectu

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