Joel Bodenmann

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

Hello David, The display size is handled by the display driver (the GDISP driver). Either the display controller you're using has a fixed-size display size in which case it just returns a static number (like most do) or it's a configurable one like the SSD1963 or the STM32LTDC in which case there's a configuration define in the drivers configuration file. At the end of the day the display size is stored in the GDisplay structure.

Can you please tell us which compiler you're using? Also, are you trying to compile a demo or example project?

Hello David, That's explained here: https://wiki.ugfx.io/index.php/Using_PSoC_Creator#Adding_Drivers

Hello Josh, Did you bother actually reading the error message? It's pretty verbose: gwinAttachMouse() is a deprecated call. You don't need to call it yourself manually anymore. Just remove that call from your application code and you'll be ready to go.

If your driver doesn't support double buffering there's always the "workaround" of using pixmaps: You render your console into a pixmap and then blit that pixmap onto the real display. But as @inmarket said: Real double buffering is never easy. This is just a sneaky "workaround".

For more complex things you might want to copy the existing graph widget (which is a window) and make it become a widget. The difference between windows, widgets and containers are explained in the GWIN section of the wiki. The main difference that is helpful for you here is that a widget can process user input (eg. it gets touch events) and that it can redraw itself.