Joel Bodenmann

To save a lot of resources (especially RAM and also CPU time).

This is the relevant code taken from the µGFX-Studio v0.22.4: void UGfxWindow::setDisplay(GDisplay* g) { if (!_ghandle) { return; } // Nullptr means default/standard display if (!g) { g = GDISP; } gwinHide(_ghandle); _ghandle->display = g; gwinShow(_ghandle); } _handle is the GHandle.

There's no hacking involved. You just need to change the GDisplay* pointer. We did the same thing for the µGFX-Studio.

Hi, The most common solution is (as you mentioned) double buffer. However, proper double buffering is very hard to implement and also requires hardware support. While µGFX can fully support double buffering (with the multiple displays API) we do also provide you with a more flexible way: Pixmaps. You can simply render your widget into a pixmap and then blit that pixmap to your real display. Pixmaps have certain advantages over real double buffering. The most notable is that you don't need two times the memory for the entire display area - a pixmap can be just a small portion of the screen. Other than that there are other things which vastly improve these sort of things such as anti-tearing-effect flags and so on. But all of that needs to be supported by the hardware.

The SSD1963 has an R/S pin which is used to tell the display controller whether the incoming data is configuration data or actual pixel data. This is done so that you don't need to wire up all the address pins in order to address each pixel individually (and each configuration register). The two macros above are used to access the SSD1963's memory, one time with R/S set to 0 and one time set to 1 - essentially giving you the option to write pixel data or configuration using "stock FSMC" without having to manually control the R/S pin via a GPIO. You need to ensure that the macro which sets the R/S pin has the correct address. So if you hooked the R/S pin up to FSMC_A16 you need to sure that GDISP_RAM has address bit 16 (the 17th bit) set to 1. FSMC is usually extremely straight forward and there is little that can go wrong. Just make sure that you use low timings until everything is working. Then you can ramp them up. But usually you want to be somewhere in the range of 10k to 100k until everything works. Also make sure that your pins are setup correctly (that the correct pins are being set to alternate function and so on). The most difficult part with the SSD1963 is getting the panel parameters correct. Make sure that you always at least tripple-check them. Those parameters are different for each panel. You should get a table of values together with your panel. However, note that the parameters you get are not always the ones you need to enter into that parameter struct. They are often calculated differently. I know that this post isn't as helpful as you might have wished for but there's not much we can do. FSMC is pretty much self contained: It's all about accessing a memory region. Everything else is up to your hardware and proper pin configuration. Simply tripple-check everything, take a break and do it again. Also, you definitely want to use a scope or logic analyzer to have a peek at those FSMC pins. Keep in mind that you can test the FSMC outside of µGFX. All that FSMC is doing is accessing a memory region. Therefore, you can setup your pins and just try accessing the SSD1963 with the two macros above - no magic involved. You can then just make call to the one with R/S = 0 and one with R/S = 1 in the main loop and use a scope or logic analyzer to verify that the correct pin is toggling.

GWidgetObject is the base widget call: https://git.ugfx.io/uGFX/uGFX/src/master/src/gwin/gwin_widget.h#L109 You don't usually worry about those as you always access them using the GHandle. Edit: Yes, GWidgetObjset is definitely a spelling error.

Hello Bilymo, I don't understand what you're trying to say. The µGFX library is by far the most portable and agnostic library out there. You can run µGFX on virtually any platform and with any driver. The Keil guide clearly states that the example uses the SSD1289 driver but that it's the same process for any other driver: We cannot provide a guide / tutorial for every possible configuration out there. If you need to use the ILI9341 driver just follow the SSD1289 example but pick the ILI9341 driver. We're open to any kind of feedback regarding the documentation. If you feel that you have some improvements to share we're happy to hear them. But we surely aren't going to write guides for every possible combination.

I currently don't have access to a running Keil instance. Can you please show us screenshots of the relevant parts (file tree, compiler path settings, ...). The error message you're getting indicates that you didn't properly add the path to the driver directory to the compiler include path list:

as @inmarket already told you: You must not copy the driver directory. Please just follow the guide exactly step-by-step. It's well tested and used frequently.

I'd recommend you to import the project instead of copying into a workspace folder. That's how Eclipse is meant to be used.

May I ask what panel that is? (Just for personal records).

The STM32F469i-Discovery board files have been added a long time ago.

Is it possible that you forgot to include the driver (or just didn't do it accordingly)? Make sure that you follow that guide exactly. It's very well tested. Also, don't forget to set the compiler to GFX_COMPILER_KEIL in the configuration file when using Keil.

Something like this (untested): void myRendering(GWidgetObject* wo, void* param) { coord_t sx, sy; // Cast parameters img = (gdispImage*)param; if (!img) { return; } // Render background (use the specified portion of the specified image) if (img) { // Determine the coordinates relative to the parent if (wo->g.parent) { sx = ... sy = ... } else { sx = 0; sy = 0; } // Render the image gdispGImageDraw(wo->g.display, img, wo->g.x, wo->g.y, sx, sy, wo->g.width, wo->g.height); } // Render the label gdispGDrawStringBox(...); } When creating the label you assign that rendering function to it and you pass a pointer to the containers background image as the parameter.

Here's the corresponding API documentation: http://api.ugfx.io/group___g_o_s.html

Hi, Yes, this is definitely due to the transparent custom rendering function. There is no concept of transparency in µGFX (that will follow with µGFX v3). The GWIN window manager excepts that the widget always clears it's own area. You have the following options: Modify your label's custom rendering function so that it receives an image chunk that it will use to clear the widget area prior to rendering the new text. The image chunk you give it should be exactly the container's background image below the label area. Redraw the entire container Redraw the entire container but render it into a pixmap and then just blit it to the display to ensure flicker-free and fast updating Write your own GWIN window manager that can handle transparency: https://www.youtube.com/watch?v=xZKgp5XaxVE Which option you're choosing is mainly depending on your platform and the available resources.

Glad to hear that you managed to get it working I sense a bit of negativity in there - we're not trying to blame stack overflows for everything, but they are an extremely common issue that result in exactly that kind of behavior. However, stack overflows and concurrency issues often lead to very similar results. Also, I mentioned that I don't think that that's the problem in this case That's really difficult to do. 20k definitely sounds like fair amount of RAM then. Depending on what you're actually doing you can get way lower that that. We've systems that run with 5 kB or RAM and they do fancy-looking stuff. Usually you just start off with a very large number and once you're happy with your GUI you start making it smaller and smaller until shit hits the fan. Then you usually add a margin of 10 to 20% depending on the application. But keep in mind that that's a very "unsafe" approach as GUI memory usage often heavily depends on the user interactions. So while it might be enough for you and me it might still blow up if some dude starts pressing all the buttons at once or something

I wouldn't recommend that. As mentioned the FreeRTOS port that comes with v2.8 is well used by dozens of commercial customers, hundreds of makers and multiple universities. Of course there can always be bugs, but what you describe doesn't sound like a core port bug to me. 20kB stack is enough to do all the GDISP, GWIN and GINPUT stuff. But of course this heavily depends on what you do. If you're decoding a PNG image or if you keep stuff cached that obviously isn't enough. However, that shouldn't be an issue here anyway as you're not supposed to make any calls to the µGFX API prior to calling gfxInit() and the calibration is called by that init function. Could you provide us with a picture of the display? From what I'm reading I suspect an issue with the interface to the display controller or a wrong display controller initialization code. I would also highly recommend you to run the /demos/modules/gos demo(s) to check if your FreeRTOS stuff is working properly. Those demos don't use any display stuff.

@DPJones we understand your frustration but this is a public community forum which is managed by the µGFX developers in their spare time. We really don't have the manpower to just download an entire project and look through everything. Also, keep in mind that µGFX is quite big and complex. The issues are almost always in the board files or the driver initialization code on which we have almost no influence on. There's very little we can do on those ends - the rest of the quality of the software does not related to those parts.

Did you make sure that you're using the latest version of the µGFX library? When you go through the changelog you'll find that there has been a major FreeRTOS port rework at some point. Ever since then the FreeRTOS port is known to work extremely well and is well used & tested.

That is not a µGFX specific error. Either you're missing your definitions for _sbrk_r() or you're calling code that you should (eg. when you use something like the NATIVEFS option in GFILE but your underlying system doesn't offer any). All of the GDISP rendering functions come with the capital 'G' version like the one that you mentioned but they also come with a wrapper that has the exact same name but misses the capital 'G' and also doesn't have the first argument (the GDisplay pointer). When you're using the API without the 'G' it always uses the default display. The one with the 'G' is to specify which display you want to render to which is completely unnecessary when you're having just one display. That's explained here: https://wiki.ugfx.io/index.php/GDISP#Multiple_displays

There are two ready-to-run demo projects for the STM32F429i-Discovery board available: https://community.ugfx.io/files/category/2-example-projects/ However, they are both ChibiOS based. We don't have anything other than those projects. There are just way too many different configurations (IDEs, underlying systems, HALs, ...) that we could provide everything. When working with the CubeHAL I'd recommend you to have a look at the examples that ST provides. They tend to be quite verbose.

The error message is very clear: The underlying system has been defined more than once. This usually happens if you set your underlying operating system both in your configuration file (gfxconf.h) as well as your makefile. Just remove the declaration from your configuration file.

This is definitely most likely an issue with stack overflows. This piece of code is extremely well tested as almost everybody uses it. Along with what @inmarket said, keep in mind that 2k stack is not a lot for when you're doing graphics. That's surely enough to draw a few rectangles and so on but you'll quickly run out of memory when you start rendering fonts & images and when starting to dick around with the window manager. Usually you'd start way higher and then minimize the stack size until you have something that works in all conditions.

If the auto-detect fails you can always force it by setting GFX_COMPILER to GFX_COMPILER_KEIL in your configuration file: #define GFX_COMPILER GFX_COMPILER_KEIL