Joel Bodenmann

Thank you for sending the pull request, we appreciate your contributions a lot! Btw, as mentioned in an earlier post we would prefer the .patch file being attached to an explaining post here in the forum as it is easier for us to maintain it this way. Sadly bitbucket doesn't allow to download the patch file from a pull-request so it is rather cumbersome for us to try and verify the changes on our local testing repository before merging. Also, while the pull requests are usually totally fine there are some minor or additional changes required in other parts of the µGFX library to ensure proper compatibility across all features and platforms. In those cases we first have to merge the pull request and then modify the required things. This are also the reasons why there are many "declined" pull requests on the bitbucket site: Nearly all of them got merged but manually due to the issues described here. We definitely appreciate all your contributions! ~ Tectu

The issue has been fixed: https://bitbucket.org/Tectu/ugfx/commit ... b26edbbcd1 Thank you for bringing this to our attention! ~ Tectu

Hello BAT and welcome to the community! Yep, you are right. That is definitely an issue. We will have a look at this in the following days. Thank you for bringing this to our attention! ~ Tectu

Really glad to hear that you got it working! Big THANK YOU to Andrey_13 for helping you!!! ~ Tectu

Not sure what you are talking about. _LFN_UNICODE is a macro that is only used by the FatFS library, it has nothing to do with µGFX text rendering at all. ~ Tectu

Just curious... did this fix the problem you were having, woodstock? ~ Tectu

One more thing: There are many display controllers out there who actually have a scrolling feature implemented in hardware. This would vastly increase performance as everything happens inside the display controller and not inside your CPU. We would recommend you checking whether you display controller supports such a feature. ~ Tectu

Hello gargamel and welcome to the community! There is currently no "animation" support/module in the µGFX library. You will have to implement this yourself. Basically you just need to write text and then pixel-shift it. However, calling any of the gdispXxxStringXxx() string drawing functions each time in a loop will require a lot of CPU power. Therefore, we strongly recommend using PixMaps for this one. Pixmaps are actually intended for a use like that. As described in the documentation, a pixmap is nothing but a virtual display in your memory. Once you created a pixmap, you write the text to it (once). Then, all you need to do is rendering the same pixmap over and over again but just a different location. There is actually a complete, 1:1 example in the documentation as well as in the uGFX library directory showing how to do exactly that but with an image instead of text. Please do not hesitate to ask should you have any questions. ~ Tectu

Glad to hear that you got it working! Thanks for your feedback. ~ Tectu

Hello yusp75 and welcome to the community! Sorry for the late reply. We are currently very busy. The SSD1306 driver is known to work very well so integrating it into your project should not be much of a problem. The readme.txt is quite old and the information in there is not accurate anymore. While it is correct that the SSD1306 needs explicit flushing, this is hidden behind high-level API of the GDISP module. All you have to do is enabling the auto-flushing feature by setting GDISP_NEED_AUTOFLUSH to TRUE in your configuration file (gfxconf.h). To get started, we recommend reading the Getting Started guide on our wiki. It will lead you through different other articles that describe how the µGFX library is built (architecture) and how to configure it (gfxconf.h). After adding the µGFX library to your working project, all you have to do is enabling the GDISP module in the configuration file (as described in the wiki) and implementing the board file (copy the /drivers/gdisp/SSD1306/board_SSD1306_template.h to your project directory, rename it as described in the documentation and fill in the empty functions). All the board file does is initializing your peripherals (eg. SPI) and sending bytes over that interface. If you have any additional questions, please do not hesitate to ask. ~ Tectu

We have successfully compiled this project with arm-none-eabi-gcc 4.9. We also used the version from the Launchpad. ~ Tectu

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