Joel Bodenmann

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.

Hello and welcome to the µGFX community! I assume that you're using a parallel interface with the FSMC of your STM32F103. The symptoms you're getting indicate that your bus is not running stable. Try reducing the speed / increasing the different timing values.

The v3.0 source code will not be accessible before the first release. However, I think that it shouldn't be a problem for us to share the API sooner.

This sounds very odd... Can you please try to add another cout call with a static text? For example: while (1) { gfxSleepMilliseconds(100); load = dengine->GetLoad(); vpedal = dengine->GetVpedalActual(); rpm_de = dengine->GetRPM(); std::cout << "foo" << std::endl; std::cout << dengine->GetRPM() << std::endl; std::cout << "bar" << std::endl; } Also, what compiler optimization level are you using?

The first thing you need to do is deciding whether you want to run µGFX directly on the Linux framebuffer or not. In most embedded applications you do want to do that. Because otherwise you need a full blown window manager and usually even a desktop environment to run µGFX as an SDL application. In embedded applications you usually use µGFX on Linux because you want to avoid all of that so there's no way around the framebuffer. You can (and probably must) (re)compile your Linux kernel on a desktop computer if you want to enable framebuffer support. However, I haven't seen any development board that runs Linux that didn't get compiled with framebuffer enabled while still offering the ability to drive a display. Are you sure that your kernel doesn't support that?

Re-compile the kernel with framebuffer enabled Alternatively, you can run µGFX on top of the X window manager or as an SDL application. But whether you want that or not depends on your application.

I'm sorry, I do not know how to make it any more clear. Please don't hesitate to ask if you have any specific questions.

Interface: https://git.ugfx.io/uGFX/uGFX/src/master/src/gdisp/gdisp_driver.h Existing drivers: https://git.ugfx.io/uGFX/uGFX/src/master/drivers/gdisp Additional display driver documentation: https://wiki.ugfx.io/index.php/Display_Driver_Model

Hello David and welcome to the µGFX community! You can always write your own display driver. The interface is well documented and there's additional information in the wiki. Furthermore, there are dozens of existing drivers which you can use as examples.

Hello Tobi, Before we dig into this: Can you please give us detailed information about your system? What underlying system are you using? What compiler are you using? Who's managing the memory?

Glad to hear that everything is working!

Hello @poting and welcome to the µGFX community! That's not only fine but also correct. That's wrong - don't do that. You already included everything in the first step. Now you're including some stuff that is included in $(GFXLIB)/gfx.mk again manually. So you have some stuff twice. That's why you get the double definition errors.