Joel Bodenmann

Is it possible that you included the same GDISP driver (SSD1306) multiple times? (or just more than one driver in general). ~ Tectu

inmarket is currently working with the STM32F7 Discovery board using ChibiOS 3. He mentioned some issues but I am not sure whether he managed to get it working yet so we better wait until he drops by. ~ Tectu

Hello jameskong and welcome to the community! We are terribly sorry for what happened. Of course we always send those e-mails using the BCC instead of the TO field - well "always". Sadly the damage has been done and there's not much we can do beside apologizing... :cry: This won't happen again, promised! Kind regards, ~ Tectu

Wow, we are very excited to hear about this! Support for RTL languages was a feature that was requested a lot. Sadly we couldn't implement it ourselves as none of the uGFX developer speaks an RTL language and therefore this would be a very error-prone process. We will take a look at your contribution in the following days. Thank you VERY much! ~ Tectu

Hello Luis and welcome to the community! Sadly we can't provide you with a step-by-step guide as we never worked with the Silabs Simplicity Studio IDE. All we can tell you is that GCC is a very well supported compiler and that there are no known issues with using µGFX with GCC. When it comes to integrating µGFX into an IDE then there are two options: Either your project can handle an external Makefile or you have to use the single-file inclusion mechanism. Makefile In case of you can call external Makefiles with the IDE that you are using, then just follow the guide on the wiki. All you need to do is including the main uGFX makefile and adding $(GFXSRC) to the source files and $(GFXINC) to the include path. Single File Inclusion Since version 2.4, uGFX comes with a mechanism that allows to compile the entire library by just including one single file in your IDE. Sadly we didn't found time yet to properly document this new feature. What you have to do is adding gfx_mk.c to your project files and adding the main uGFX directory to the compiler include path. Everything else will be taken care of in the background. Here are some more information: viewtopic.php?f=9&t=228&p=1920 We will try to find some time in the following days/weeks to put up a detailed guide for this on the wiki. Sorry for the inconvenience. ~ Tectu

You always have to sent 16-bits. The implementation depends on whether you use the controller in 8-bit or in 16-bit mode. In 16-bit mode you just write the word to the bus and you are done. In case of 8-Bit mode you will write the high-byte first and then the low-byte. Here are two example implementations for the ILI9341 that we are using successfully: // ILI9342 in 8-bit mode static inline void write_pixel(GDisplay* g, uint16_t pixel) { (void) g; LCD_DATA = (uint8_t)((pixel >> 8)); LCD_DATA = (uint8_t)((pixel >> 0)); } // ILI9342 in 16-bit mode static inline void write_pixel(GDisplay* g, uint16_t pixel) { (void) g; LCD_DATA16 = pixel; } Note that we hooked up our display controller to the FSMC peripheral of an STM32 CPU and therefore the timings are taken care of through the timings configuration. Done. ~ Tectu

The ILI9341 is known to work well. I have a couple of products/boards here that use the ILI9341. The only thing that might not be 100% supported are orientations and power modes. However, I have a fully working driver. I will put that into the repository soon next week. ~ Tectu

Well... Not much left to say here beside: Happy to hear that you got it fixed ~ Tectu

Glad to hear that you got it working. Great work! If you could write a wiki article that would be great - we appreciate it very much. Let us know when you think that it is time to do so and we will create a wiki account for you Thank you for your contributions to this project! ~ Tectu

Glad to hear that you got it working! Keep up the good work ~ Tectu

This looks great! Thank you very much for your work! If this is "finished", would you like to add the guide as an article to our wiki? We are going to add several guides like that for other IDEs such as Keil µVision in the near future as well. It would be nice if everything would be in the same place. We already have a guide for the ChibiStudio that was contributed by a community member (http://wiki.ugfx.org/index.php?title=Using_ChibiStudio) and right now another community member is working on an in-depth step-by-step guide for using the GIT repository (work in progress): http://wiki.ugfx.org/index.php?title=GIT_Instructions ~ Tectu

Thank you for showing your results. We will have a look at this some when during the next week. Right now we are very busy. We are currently improving the code-generator of the µGFX-Studio as we want to focus on getting a working version 1.0 out soon. ~ Tectu

Hello wolf, Thank you very much for your contribution. It is very appreciated! However, it seems like you forgot to actually attach your file(s) Please upload the files as a ZIP archive as *.h and *.c extensions are not directly allowed. Please keep up the good work! Kind regards, ~ Joel Bodenmann

There is an existing PWM driver for the GAUDIO playback module. You can find the driver in /drivers/gaudio/pwm/. The entire hardware configuration (eg. what pins, which PWM peripheral etc.) happens through the board file - the same as all the pin configurations for the display happen through the GDISP board file. All you need to do is copying the board file template that you can find in the drivers directory to your project directory and implementing those four functions and you are ready to go. Note that the readme in the drivers directory contains some more information. Also note that when copying the template to your project directory you have to rename it so it doesn't say "_template" anymore. The file must be named gaudio_play_board.h. Let us know should you have any other questions. ~ Tectu

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