Joel Bodenmann

Yes, as written in a previous post the uint32_t modification is not meant to fix the warning that you're getting. It's just to ensure that we always get 32-bits worth of flags because 'unsigned' it not 32-bits on all platforms. We'll push the real fix (casting the statement in the macro explicitly to uint32_t) in the following days. ~ Tectu

The new drawing function is now part of the repository. Thank you for your contributions! ~ Tectu

Yes, we received your e-mail and we will reply shorty. Sorry for the delays - we've never been busier before. Right now we are testing the code that you published in this thread. Seems to work very well! Should be in the repository by tomorrow. ~ Tectu

This looks very good. We will test it ourselves and merge it into the repository eventually. Thank you for your great contributions! ~ Tectu

Your new default rendering function has been pushed to the repository. Thanks & keep up the good work! ~ Tectu

Well, we are interested into hearing and seeing all of your ideas! For the people who are interested into this new keyboard rendering, here are a few screenshots. We used a DejaVu 24 anti-aliased font. SSD1306.zip

Wow nice, this looks really awesome! We are very thankful for your contribution. We always wanted to implemented a better rendering function for the keyboard widget but we never got to it. After testing, we will add this to the library. Thank you very much! Are you interested into creating new/alternative custom renderings for other widgets as well? We would really love to provide some better looking (default) styles as the current ones are the biggest draw-back for most users. ~ Tectu

So far we only witnessed this warning with ARMCC (the compiler used by default by Keil MDK-ARM). ~ Tectu

Well, I guess the most proper thing that we can do from our side is properly/explicitly typecast the macro definitions. However, for the sake of consistency I'd like to add that to ALL flag definitions, and not just the top bit one. Any thoughts? ~ Tectu

We were able to reproduce the issue. The problem is that the compiler doesn't seem to recognize that this is an unsigned number and therefore it thinks that an overflow happened. You can supress that warning by casing the flag explicitely: psl->srcflags |= (unsigned)GKEYSTATE_MISSED_EVENT; We will see if there's a better solution to this. After all we shouldn't be using unsigned but uint32_t instead for the flag types in the GEVENT struct(s) (not that this would change anything in your case). For now, I'd recommend you not to worry about this warning. We'll let you know when we changed anything. Edit: We just pushed a commit to the repository that replaces unsigned with uint32_t. But as mentioned before, this of course doesn't make the warning go away. I'd just prefer not to explicitly cast flags each time... ~ Tectu

Thank you for bringing this to our attention. For completeness, can you please also add the actual compiler output and information about the compiler you are using? ~ Tectu

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