Joel Bodenmann

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

Sorry for the late reply. What uGFX revision are you on? We changed the LTDC code a few weeks/months ago as we introduced support for the F7 and back then the DMA2D seemed to work just fine. Is this only related to your other changes or is the DMA2D driver not working for you in general? ~ Tectu

Thank you for your feature request. We put it onto the ToDo list and we might give it a shot once we completed the TextEdit widget (separate branch) and implemented the default keyboard handlers for all widgets. If you need this more or less quickly I can only recommend you giving it a shot yourself. Implementing a widget yourself is not as difficult as it might look on first glance because the GWIN subsystem handles all the difficult tasks. Furthermore, there are already plenty of different widgets which can serve as examples. And if you have any questions we are happy to help where we can ~ Tectu

We cannot help you unless you post the compiler output logs. In case of you used 'very old' uGFX version before you updated to the latest master I would recommend you copying the latest board file templates and compare them to your current ones. There were some changes regarding the board files a few versions ago. Also, note that you don't have to create a board file directory for your custom board inside of the uGFX library directory. Just place the board files somewhere in your application/project directory and add them to your Makefile as any other source files. You should never ever modify the content of the uGFX library directory. Otherwise upgrading to a newer version can be very very cumbersome. There is no STM32F407 Discovery board file in the uGFX repository because this board does not have a display. There is however a board file for the Embest board which is an STM32F407 with an add-on. Furthermore, there are board files for dev-boards without a display but where a display can easily be added such as: ugfx\boards\addons\gdisp\board_SSD1289_stm32f4discovery.h. I assume that this is the board file from the 'previous version of ugfx' that you are referring to. ~ Tectu

The file gfx.h is not supposed to be in your project directory. What gave you the impression that you should copy it? Remove it and the error is gone. ~ Tectu

Can you please upload the ZIP archive as an attachment to your post? We will have a look at this during the weekend. Sorry for the delay. ~ Tectu

A simple forum search would have fixed your issue some time ago Another community member encountered this issue and we fixed it: viewtopic.php?f=28&t=263 Please let us know in the uGFX-Studio section of the forum whenever you encounter a problem with the studio. ~ Tectu

You should never ever modify the uGFX library sources to archive something in the application level of things. You can submit a custom rendering routine either through the widget initialization struct (the customStyle field) or the function gwinSetCustomDraw(). It doesn't matter where you implement your custom rendering routine. Usually they are located in a separate file. You can find more information here: http://wiki.ugfx.org/index.php?title=Cr ... ng_routine The uGFX-Studio currently only uses this feature to create custom rendering routines for the container backgrounds which you can create in the Backgrounds Manager tool. Maybe you can have a look at some of the generated code to see how it is used. ~ Tectu

Did you replace the Makefile of your project with the new one from the repository? Did you make sure that you set the paths to GFXLIB and CHIBIOS correctly? When you verified this and it is still not working please upload a .zip of your project. ~ Tectu

I made some changes to the build system for ChibiOS . Internally ChibiOS 2.x and ChibiOS 3.x are treated differently. There are now working examples for both ChibiOS 2.x and 3.x in the STM32F429i-Discovery board directory. As inmarket did not review the changes yet it might be that there will be some more changes as he is the one who originally implemented our build system. However, this way you can at least continue with your project. Sorry that this took so long. Let me know whether you got it working. ~ Tectu

Glad to hear that you got it working! Happy hacking ~ Tectu

That is correct. You can use GFXBOARD and GFXDRIVERS for easy inclusing of board files and drivers in your Makefile so you don't have to specify the path yourself. GFXDRIVERS can take a list of parameters, not just one value. Eg. you might want to do GFXDRIVERS = SSD2119, STMPE811 to include both a display and a touchscreen driver. The line you are referring to creates one valid Makefile inclusion statement for each driver entry in the list. You can just include a display driver, no need to use board files. Board files are really just a Makefile which will automatically include the necessary driver files to use all the features of the board. When you take a look at some of the board files you will find out that it really doesn't do much beside manually including the display and the corresponding touchscreen driver for that board. eg: GFXINC += $(GFXLIB)/boards/base/Embest-STM32-DMSTF4BB GFXSRC += GFXDEFS += -DGFX_USE_CHIBIOS=TRUE include $(GFXLIB)/boards/base/Embest-STM32-DMSTF4BB/chibios_board/board.mk include $(GFXLIB)/drivers/gdisp/SSD2119/driver.mk include $(GFXLIB)/drivers/ginput/touch/STMPE811/driver.mk Board files are just for the convenience for the user. No need to use them or create them. Just include the driver(s) manually in your Makefile and you will be fine. The board file included in the Makefile from that article will include the display and the touchscreen driver for that board. The board itself does not have an audio codec chip and therefore the board file does not include a corresponding driver but a user might add an audio codec add-on himself. Then he has to include the appropriate driver in the Makefile. The example shows how to include the board file and an additional driver (for the VS1053 in this case). Hence the commend "additional driver" (as it is not part of the board file). I hope that answers your questions. ~ Tectu