Joel Bodenmann

Glad to hear that you got it working. I guess we'll make one or two short videos where we create a project from scratch to demonstrate the intended workflow as per your suggestion. ~ Tectu

You want to change the 'Default Widget Style' of the GWIN Module. You can do that under Settings -> GWIN -> Default Style. The background property in the widget style only applies to the background of the display - not the widgets themselves. More information on widget styles can be found here: http://wiki.ugfx.org/index.php?title=Wi ... dget_Style I guess the uGFX-Studio seems to work reliably enough to start working on documentation now... what do you guys think? There's literally not a single line of documentation so far. ~ Tectu

1) How did you add the µGFX library to your project? Did you see this guide? ---> http://wiki.ugfx.org/index.php?title=Us ... _5_MDK-ARM 2) Can you describe what you mean by 'screen orientation is not working'? We fixed an issue in the STM32LTDC driver related to orientation a couple of weeks ago. Please make sure that you use the latest master branch of the µGFX repository. 3) Something is definitely very wrong in your project configuration. Can you please upload a ZIP archive containing the entire Keil µVision project and everything we need to compile? Otherwise it will be every hard for us to help. ~ Tectu

I think we should set the default value of GFX_OS_HEAP_SIZE to a non-zero value to prevent confusion in the future... A couple of remarks: 1) Using a rectangle in the background designer to 'change the background color' is NOT recommended. This is what widget styles are there for. You can create as many widget styles as you like using the WidgetStyle-Manager that you can find in the 'Tools' menu. 2) The missing pixels you are experiencing with the rounder corner buttons are actually rounding issues that are not easy to handle. Inmarket and I have discussed that a couple of days ago and we didn't come to a definitive conclusion on how to fix that so far. 3) The top and left border of the square buttons are not over overwritten - they simply don't exist. The default render implementation of the buttons only draws two lines (you guessed it: at the right and the bottom edge) in hopes of making it look more appealing. Line 205 and 206: https://bitbucket.org/Tectu/ugfx/src/4b ... tton.c-168 4) Matching the fonts is currently one of the biggest issues we are experiencing with the Studio. We will try to improve that for the next release(s). Thank you for your feedback. ~ Tectu

Hello Peter and welcome to the community! Thank you very much for sharing your experience. This will definitely be helpful to others. _sbrk_r() is a system call that's used for memory allocation/management. Usually this isn't something you would find on a microcontroller. It's either implemented in the underlying system that you're using or you simply shouldn't use it. I suspect that the µGFX-Studio project you are using generated a configuration file that enabled one of the file systems in the GFILE section. This has been an issue before but it was fixed a couple of updates before. Can you please let us know which version of the µGFX-Studio you are using and update to the most recent one? Version 0.12 was released two days ago and it contains many bug fixes. Now that I am writing this... is it possible that your configuration sets GFX_OS_HEAP_SIZE to 0? In that case the µGFX library would try to use malloc() and free() which would be supplied by your standard clib which call _sbrk_r(). More information on this can be found here: http://wiki.ugfx.org/index.php?title=Ba ... Management It would also be helpful if you could upload a ZIP archive of your µGFX-Studio project so we can look at both the configuration and the generated files. I'm pretty sure that something is enabled that shouldn't be. ~ Tectu

We updated the online font converted. Can you please give it a try and let us know whether everything works now? ~ Tectu

Thanks for sharing your experience with the ST7735, pigs. Is it possible that you upload a ZIP archive of the driver that you created so we can include it into the repository? ~ Tectu

It's correct to use gdispXxx() instead of gdispGxxx() as mentioned in the documentation. You only need the one that takes the display parameter if you are working with multiple displays (if you have more than one display connected to your microcontroller). First of all I would like to point you to the documentation that explains the GDISP driver interface. It contains some valuable information that might be helpful to understand what happens: http://wiki.ugfx.org/index.php?title=Di ... iver_Model I assume that the reason that your gdisp_lld_draw_pixel() isn't getting called is because in your drivers configuration file you enabled some hardware accelerated drawing method. It's either possible that you set GDISP_HARDWARE_DRAWPIXEL to TRUE or that you enabled hardware accelerated area filling and you're trying to draw a rectangle in which case the GDISP code will use the hardware acceleration interface instead of gdisp_lld_draw_pixel(). When implementing it's a good idea to disable all hardware acceleration first. An additional comment: I'd strongly recommend you to stick with the current existing naming conventions that are also used by the other drivers. You can see that the SSD1289 driver's board file functions are called write_reg() and write_data(). I hope that helps. Let us know when you have any additional questions. ~ Tectu

You can handle double buffering with uGFX but your hardware needs to support it too. For double buffering you actually need memory to store two entire frames - most microcontroller based systems don't offer this. If you can tell us which microcontroller and which display controller you are using we can give some more information. As you are only updating a small portion of the display area we would recommend using Pixmaps for this job. A pixmap is like a small virtual display to which you can draw. Then, you can just copy the contents of the pixmap to anywhere on your real display. The reason this increases performance is because the thing that's by far the slowest is writing pixels to the frame buffer in the display controller and especially if you don't write sequentially (continuous blocks of pixels) but single pixels at different locations instead. Rendering something like a font requires a lot of pixel i/o so this takes a lot of time. It's especially slow because many pixels get written twice (eg. cleared with a background color first, then the text on-top and maybe some third time for anti-aliasing). Doing the same in a pixmap is a lot faster because the pixmap is located in the microcontrollers RAM which is very fast to access. Further factors that will increase performance are the fact that each pixel gets just set once in the display controller (because we know what the end-result must look like) and also the fact that almost all external display controllers allow burst-writes where a continuous block of pixels can be transfered very quickly. There's an article on the wiki explaining pixmaps including a demo. You want to use the 'virtual display' method: http://wiki.ugfx.org/index.php?title=Pixmaps You could furthermore increase the performance by not re-writing the date each time as it won't change. If you really want to get everything out of your hardware then you could even split the time string into two piceses: one that contains the hours and minutes and once that only contains the seconds. This would further minimize the area that needs to be rerendered and redrawn. Hope that makes sense. ~ Tectu

Hello and welcome to the community! You will definitely be able to run uGFX on that hardware and it also makes sense to do so What display are you using? If the display module uses a controller that's already supported by the uGFX library then you don't have to do anything but implementing the board file. The board file contains a few functions which you have to implement so they send and receive data through SPI in your case. You can find a list of all implemented drivers here: http://ugfx.org/platforms In case of your display controller is not yet supported you'll have to implement the driver yourself. We recommend having a look at some of the numerous existing drivers. Everything we have to offer in terms of documentation can be found here: http://wiki.ugfx.org If you have any questions do not hesitate to ask. We are happy to help where we can. ~ Tectu

Is it possible for you to upload a *.zip of the entire project to this thread so we can give it a try over here? We will provide a working Keil project for the F7 discovery board eventually anyway, but we'd like to understand what's going wrong on your side. ~ Tectu

So with the latest master branch from the repository you still get that error about the assembly code? Can you please post your entire gfxconf.h file? May I ask where you got your STM32F7-Discovery Keil project from? It seems like there are some things broken. I think the easiest is if we create a new BareMetal project from scratch ourselves to confirm that there's nothing wrong inside the uGFX library. We can then upload the project so everybody can download it. We want to create a page where people can download pre-configured projects anyway so this might be a good start. Is this a high priority task for you? ~ Tectu

That's very odd. Can you please leave information about the compiler that you're using? We are using the STM32F7-Discovery board with Keil µVision 5 and Raw32 here every day and never had even the slightest problem. Is it possible that you're running an old uGFX version? We are constantly improving our software and there are nearly daily bugfixes. You might want check out the master branch of the repository to always be on the latest state. ~ Tectu

Add this to your configuration file: #define GFX_CPU GFX_CPU_CORTEX_M7_FP Should work like expected then ~ Tectu

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