Joel Bodenmann

As the graph doesn't keep track of the data itself (for various reasons) clearing the graph and then manually redrawing the actual data points is the correct way. Decoupling the data acquisition and the rendering of the data as per your method is also a very good idea. The flickering occurs because gwinClear() will clear the graph (fill the entire area with the background color, then draw axis and grids) and then some time passes until you write your new data. This time in-between those two operations cause the flickering. Ideally, the rendering of the entire graph would happen off-screen and the result is copied in one operation to the frame buffer. This can be archived by using Pixmaps which provide dynamic virtual off-screen displays to which you can render just as to any display and once everything has completed it can be blitted into the frame buffer. However, note that depending on your hardware (memory bandwidth, coupling between framebuffer memory and RAM, ...) can cause to actually lower the performance. Another solution is to write your own graph widget which would maintain a list of the data-points as per your needs. The graph widget that comes with the uGFX library is very old and doesn't provide many features. Also, it is hard to write such a specialized widget that is still generic and universal usable. Can you tell us which scope demo you mean? Over the time many users have written a lot of different, very awesome oscilloscope demos If you are referring to the demo that samples an audio input via GAUDIO and draws the volume line/graph, then that demo can be found under /demos/modules/GAUDIO/oscilloscope. However, that demo is very old and it was created even before the graph widget existed, so I assume that you are referring to another demo? If you tell us which one we might be able to tell you who wrote the demo and what the trick was to get such amazing performance out of it. ~ Tectu

The frame widget sends the following event when it gets closed: GEVENT_GWIN_CLOSE So in your event loop, just listen for that event as you do for any other event (button press, slider value change, ...) and you should be good. The overlapping that containers manage is the overlapping between the parent and the child, not between individual children. So everything mentioned about the window manager above still is the case. ~ Tectu

There's currently no drop-down widget that comes with the uGFX library. Neither are we aware that any user ever created one. Which demo are you referring too? ~ Tectu

Thank you very much for bringing this to our attention. We just fixed that Note that in general we recommend having a look at the demos that can be found in the /demos/ directory of the uGFX library. The ones on the wiki are easy to get outdated and usually just show the most basic usage possible. ~ Tectu

Great! As inmarket mentioned the default window manager that comes with the uGFX library doesn't handle overlapping widgets unless they are in a parent/child relation ship (containers). This is one of the limitations the window manager has but in return it is a very small and fast window manager that only uses very little resources. However, if you have more complex needs that's no problem: The GWIN API allows to use a different window manager. You can write your own window manager that properly supports overlapping widgets and use that one instead of the default built-in one by calling gwinSetWindowManager(). Writing your own window manager is not as difficult and complex as it might sound at first. So if you would like to have a go on that feel free to use the current one as an example/reference. We are also happy to help wherever we can. ~ Tectu

Calling gwinSetText() invokes a redraw of the corresponding widget and therefore invokes calls from the GDISP module that access the display. The GDISP API is only multi-thread safe is GDISP_NEED_MULTITHREAD has been set to TRUE in your configuration file. ~ Tectu

More information about this can be found here: http://wiki.ugfx.org/index.php/GFILE#STDIO_emulation ~ Tectu

More information on this can be found here: http://wiki.ugfx.org/index.php/GOS#Emulating_Malloc ~ Tectu

To actually answer your question: The way you added interrupt support is fine. Given that uGFX currently doesn't provide a proper interrupt driven mouse driver (as per the reasons listed by inmarket) there's no official / better way of doing this. Adding this to the driver is the most proper way as it keeps the libraries core code unchanged. Compared to having interrupt support directly built into the GINPUT module you don't loose much as the overhead of calling read_xyz() is very little compared to doing the actual I2C read. This is also the reason why we didn't bother adding an interface for this so far: Most touchscreen controllers provide a proper penDown signal that can be hooked up to a pin. Checking a GPIO pin is a lot faster than doing the actual I2C/SPI reading so the performance lost by polling is not that big. Anyway, things like this are on our ultra-low priority ToDo list and are something we will definitely tackle in the future. Most likely stuff like this will be completely reworked for the 3.x release. ~ Tectu

Yes, the background color of the built-in WhiteWidgetStyle is supposed to be straight white. You can see that the generated code uses HTML2COLOR(0xFFFFFF) for that. It doesn't get more white than that Eventually, yes. We will release v0.13 on the 15th of February. Right now we are working on adding the possibility to add custom fonts. If we have enough time we will also add support to provide a temporary cure solution to use custom widgets in the studio (just dummy place-holders). We'll see what we can do. I can imagine that adding graph support should be very easy and that we can get some preliminary version going for 0.13. Frame support can be done quite easily too as it's the same code as the container widget - just with a different rendering. However, the question about the frame widget is how to treat that in the studio. This will usually be used as a pop-up dialog menu. Therefore, the user must be able to define that outside of the actual display page. Adding indirect items is currently not supported at all (but obviously will be) and therefore requires some major changes. I am pretty confident that the frame will be there at least as soon as v0.14 rolls out. If you have any questions, feedback, bug reports or feature requests please do not hesitate to let us know in the corresponding uGFX-Studio section on this forum. We are happy to hear all about them! ~ Tectu

A background is nothing else but a container that spans the whole display area. The background designer just generates a custom rendering routine for that container. Let's have a look at some generated code. The following is the custom rendering code that will be applied to the page container. The background is called MyBackground: static void containerDraw_MyBackground(GWidgetObject* gw, void* param) { (void)param; // Clear container area gdispGFillArea(gw->g.display, gw->g.x, gw->g.y, gw->g.width, gw->g.height, gw->pstyle->background); // Draw the elements gdispImageDraw(&companyLogo, 500, 10, 121, 60, 0, 0); } As you can see the first thing that happens is that the entire container area gets cleared with the background color specified in the widget style. That is always the first thing that happens. When you make your own background by adding a huge rectangle in the background designer it will add another gdispFillArea() call to the rendering function. This means that the container area gets cleared twice which doesn't only waste a lot of performance, but will also lead to render artifacts when the two colors are not exactly the same. In the background we added an image (companyLogo). As you can see that is a bare GDISP image that gets rendered directly. Not an imagebox widget (as you couldn't use them in a rendering routine anyway). The difference between putting an image in the background instead of an imagebox is, that the imagebox adds overhead. It it's a widget, this means that it has to maintain position, styles, fonts, text and so on. The image added to the background is a simple gdispImage object without any overhead at all. Another advantage of putting an image into the background is that you can use the same background on multiple display pages. If you want to show your company logo on all display pages using imagebox widgets you'd have to place individual imageboxes on each display page. This multiplies the overhead mentioned above by the number of display pages. Having the image in the background means that all display pages that use that background use the same rendering function and therefore the same image object. Not only no overhead but also no additional overhead for additional pages. Regarding your question about using a container to apply a style to an entire page: No, the proper way is to use the 'GWIN default style' property in the settings or to assign a style to each widget individually. As per the reason(s) above, never put a container that covers the entire display area. This means that you are doing something wrong (as in not following the intended usage). I hope that helps. ~ Tectu

Thank you for providing this detailed information! Hopefully this will help BenjyC to get his project up and running. But I have to ask again, just to be sure: Did you use the project from the bitbucket repository or the one I attached to a forum post on the previous page? If you used the latter, can you please let us know what modifications were required to get it working (because currently it seems like it hardfaults) and/or provide a ZIP with the modified, working project? ~ Tectu

Interesting, underscores shouldn't have an effect as long as the name starts with a letter (specified by the C standard). I pulled your project before you edited your post so I will have a look anyway to figure out what needs to be fixed. The upcoming 0.13 release already contains a lot of fixes to prevent generating invalid variable and function names. A general comment: Use the Background property of the WidgetStyle to change the background color. Drawing a huge rectangle in the background designer is the wrong approach and will not only have worse performance but will also lead to unexpected problems as some parts of de GWIN module need to know the background color. ~ Tectu

This seems to be a very odd problem. Those color macros are very well tested and no issues are known to exist. I expect the issue to be somewhere in the code generated by the uGFX-Studio. Most likely you have some invalid characters in your color name (eg. spaces or special characters) that don't get filtered properly. Can you please attach your uGFX-Studio project directory as a ZIP archive to your forum post so we can have a look? Can you also give information about the version of the studio, your operating system and which compiler throws this error? ~ Tectu

If he's using the project I attached in a post above then he's not using our makefiles. The baremetal project for the STM32F746-Discovery currently uses one of my own makefiles (to keep stuff easy to understand for people who want to use this as a starting point) and doesn't use the ones that come with the uGFX repository. I guess we have to wait until CShark provides us with his fixed version of the project that actually works. ~ Tectu

I'm afraid we can't really help with that. Try the EmBitz forum Technically you don't. However, the LTDC needs sufficient memory to put the framebuffer somewhere. For small displays the internal SRAM might be enough, but you won't have much RAM left. But for anything bigger than 320x240 this will most likely not work out. That is the reason why all LTDC designs use external SDRAM: It's a cheap way of adding a lot memory to your design. So technically no, you don't need external memory but practically you are forced to because you don't have enough internal one. Yeah, LTDC and DMA2D give a huge performance boost! ~ Tectu

The demo uses the Makefile build system. Therefore, it doesn't use the single-file inclusion system. I'd recommend you to try building and running that demo outside of EmBitz first. Then you will have a base project that will help you to understand which files you need. You can then work on creating an EmBitz project from that. ~ Tectu

Nope, the hardware acceleration is part of the driver and therfore controlled in the drivers configuration file (/drivers/gdisp/STM32LTDC/gdisp_lld_config.h in your case). You can see that DMA2D is already enabled by default. The gfxconf.h configuration file only controls application stuff. ~ Tectu

Once again: The demo that comes with the uGFX library is supposed to run with the plain, standard ChibiOS/RT that you can download. No special versions, no community stuff, just the plain ChibiOS/RT. I just took the time to verify whether everything still works and indeed the supplied demo worked out of the box without any problems. I uploaded a ZIP to the uGFX homepage that you can download. The demo contains everything you need (including uGFX and ChibiOS). Just download, unzip and execute 'make' and everything should work out of the box. Note that ChibiOS 16 is just a bundle that contains ChibiOS/RT, ChibiOS/NIL and ChibiOS/HAL. Therefore, you should be able to run the exact same demo without any modifications by just swapping the ChibiOS directory (and modifying the path in the Makefile if the directory hierarchy changed). Please give the project that you can download here a try and let us know if it worked. ~ Tectu

I just realize that this board file can be found in the uGFX directory. I have no idea who put it there. But that board file is definitely NOT a good example. We'll either clean it up get rid of it. Sorry for the inconvenience! As an example on how to talk to a display controller via SPI using ChibiOS/HAL you might want to look at this: /boards/addon/gdisp/board_SSD1306_spi.h ~ Tectu

Hello Dolence and welcome to the community! There are many things that can go wrong here so let's go through a short list: Make sure that your SPI pins are initialized properly. It's a good manner to initialize ALL pins in the board_init() function. So do the same as you did for the Reset, CS and DS pins for the MOSI, MISO and SCK pins. Use the ChibiOS/HAL API for handling the SPI. Currently you are manually accessing some of the SPI registers which is NOT recommended when working with ChibiOS. You can find plenty of examples on how to use the ChibiOS/HAL API to interface an SPI client in the various ChibiOS examples, demos and testhal as well as for some other displays and touchscreens in the uGFX boards directory. Make sure that you use spiSelect() as well as spiUnselect() inside the acquire_bus() and release_bus() functions. Use the synchronous API (spiSend() if I remember correctly) to send the actual data. Check your SPI modes. Make sure that the clock polarity etc. is set properly. Your ChibiOS/HAL SPI config struct seems a bit odd. Usually the ILI9341 should work with all default settings. Just limit the clock speed but don't touch the SSE, SSI and so on (I might be wrong here). Check the SPI signals with an oscilloscope or a logic analyzer. Lastly: We have had multiple issues with the ILI93xx drivers where a supplier claimed that it's one display but in fact it was another one. While commonly this usually happens with the ILI9325 vs. ILI9320 we have seen the same with the ILI9341. If none of the above fixed your issue I'd recommend trying all the other ILI93xx drivers. This should be very straight forward as the board files for all those drivers are exactly the same. I hope that helps to resolve your issue. ~ Tectu

That's nice! Can you upload your project so everybody can benefit? At the end we want heavily extend the 'ready-to-use' projects that can be downloaded from the uGFX homepage. Just to clarify: Did you get this working based on the project I posted a couple of posts earlier? ~ Tectu

Very interesting. I guess we have some reading ahead of us I guess that this will depend a lot on the used memory (speed) and the used resolution. Anyway, my statement "Adding su pport for the second layer is fairly easy" was from the actual implementation point of view. uGFX already implements everything required to handle a second layer. The required changes only have to happen in the STM32LTDC driver. But let's not get too off-topic in MobileWill's thread. We can always open a new discussion thread in the Development section ~ Tectu

This is a bit a problem with the STM32F429i-Discovery board: The people who designed this board decided to use a display that has an internal controller (ILI9341). The entire purpose of having the LTDC (and DMA2D) peripherals is that you can directly hook up the bare display panel without any dedicated controller in between. The ILI9341 can do this but it needs to be put into this mode first. This is a configuration step that happens through the SPI interface. So when uGFX is initializing the driver, it will first tell the ILI9341 display driver via SPI that it should stop bothering and just directly route the RGB interface through. This is why the board file of the STM32F429i-Discovery is so cluttered and full of stuff. You can compare it to other board files. Usually its just a matter of a couple of lines of code. I have no idea what the issue with SPI5 would be. Maybe ChibiOS/HAL changed something. As mentioned I currently can't give it a try as I am on the road and most likely I won't find time for this before next week. All I can tell you is that the Makefile based example projects that can be found in the STM32F429i-Discovery board directory were known to work very well. Very happy to hear that We are indeed very keen to make uGFX become the best embedded GUI library available while keeping the sources open and maintaining an active community. Actually those where some of the main reasons why I started uGFX. DMA2D is supported by uGFX. If you have a look at the STM32LTDC driver you can see that the driver config has a corresponding define for that to enable or disable DMA2D. The performance gains are HUGE! As of now you can't use the second LTDC layer, that is correct, but the DMA2D hardware acceleration works on one layer. Adding support for the second layer is fairly easy and it's on our ToDo list, just currently not that high important. What basically needs to be done is initializing the second layer. Then, use a gdispControl() command to return a GDisplay* pointer of the second layer and you're done. Now you have two separate displays you can talk to. Once can then proceed by adding more API to switch the currently active layer and so on. ~ Tectu

Hello MobileWill and welcome to the community! king2 has already answered most of your questions so I'm just being a bit more specific here: 1. The /boards directory doesn't contain any drivers. It only contains what we call board files. The board files contain functions which uGFX uses to communicate with your hardware. For example, there can be a function to write a byte, another to read a byte and another function to change the intensity of the backlight. These are things that we can't do for you because it heavily depends on the user hardware. The board files are a very flexible way of providing the user with the possibility to run the same software on any platform. So in you case, if you have a look at /boards/base/STM32F429i-Discovery you will see that it doesn't contain a single line of actual uGFX code. The code in there is mostly 3rd party code to work with the RAM and so on. The board.mk Makefile includes the actual drivers which are located in /drivers. 2. The last time we checked the examples for ChibiOS/RT 2.6 and ChibiOS/RT 3.x that are located in the board directory of the STM32F429i-Discovery board worked out of the box. ChibiOS 16 just seems to be a new way to give the entire bundle (HAL, OS, ...) a version number so you are still using ChibiOS/RT 3.x and therefore the examples should work. Sadly we can't test that right now. 3. Regarding your question about the window stuff: uGFX comes with a full window manager. We also provide widgets to create dialog boxes and so on. Furthermore, it's possible to completely modify how a widget looks from the actual user space application code. This means that you can change the default look of our slider widget without modifying the actual uGFX library code. Most widgets also come with a built-in rendering function that can handle images in case of you have some more advanced needs. It is also possible (and comparably quite easy) to write your own widgets. You can read more about this stuff in the following locations: http://wiki.ugfx.org/index.php/GWIN http://wiki.ugfx.org/index.php/Widgets http://wiki.ugfx.org/index.php/Creating ... ng_routine You might also want to talk to king2 about that as he recently worked a lot with modifying how widgets look 4. Any display panel will work with the hardware acceleration provided by the STM32F429 microcontroller as long as you can hook it up to the LTDC interface. This means that in general any panel with an RGB interface will work. I hope that helps a bit. Please do not hesitate to ask any further questions. And let us know when you had any issues getting the examples for ChibiOS that are located in the board directory for the STM32F429i-Discovery working. ~ Tectu