Joel Bodenmann

I don't think that that is true. The last time I used EmBitz with Makefiles it worked like a charm - no issues debugging. Note that the debugger just relies on parsing files. Makefile just controls how these files are built. Once all files are there the debugger is happy.

Yes that is correct. You never ever want to call gwinDrawXxx(), gwinFillXxx() or similar functions inside a GWIN rendering routine as that would cause the widget to be updated again and therefore creating an endless-loop. If you are using EmBitz with a Makefile then just integrate uGFX into that makefile! uGFX comes with a built-in Makefile system. You just have to include the main makefile and add a variable to your sources and include path lists. That is explained here: http://wiki.ugfx.org/index.php/Getting_Started#Makefiles And for a real-world example thake a look at the ChibiOS/RT example: http://wiki.ugfx.org/index.php/Using_ChibiOS/RT

I'd recommend to write your own graph widget (it's actually a window, not a widget so it's even way simpler). That custom graph widget will contain a list of whatever it needs to keep track of. Then in the rendering routine you clear the area, draw your own axis, grid, labels and so on and then render your data on top of that. This gives you maximum flexibility at the highest possible performance (from the GWIN point of view). For example, if you need a rolling-graph feature then you can have a push_back() function in your graph widget that will append a new point and shift all existing ones to the left. Possibilities are (nearly) endless From the architecture point of view you should not care of rendering the widget internally itself first and then show the result at the end. That is what the GWIN and the GDISP module take care of. If you want to optimize this then Pixmaps are definitely the way to go. Note that the single-file-inclusion mechanism is just a mechanism we provide for stating quickly. It has a couple of limitations such as the pixmaps and support for custom fonts that have not been resolved yet. It is ALWAYS possible not to use the single-file-inclusion and therefore being able to use the pixmap feature.

No, you don't have to increase the display count. All you have to do is enabling the pixmap in your configuration file by setting GDISP_NEED_PIXMAP to TRUE. Note that there's currently a nasty bug/limitation that prevents you from using pixmaps when using the single-file-inclusion method. More information can be found here: ~ Tectu

Here you go, from naftilos76: ~ Tectu

That's a custom widget, not an existing one I am afraid. As mentioned in the other thread I'll ask the guy to share the sources as this was meant to become an open source project anyway. ~ Tectu

I know that guy, he's an awesome and very friendly person. I'll ask him to share the source files Might take a couple of times until he answers, tho. ~ Tectu

Thank you, we will have a look at the demo and fix whatever needs to be fixed :ugeek: ~ Tectu

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