Joel Bodenmann

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.

I'm sorry, I didn't mean to be offensive or to go down the "RTFM"-road. I just meant to post it here for completion when other people come around this topic in the future. Nothing personal at all!

Yeah. STM32F7 or F4 with an RA8875 connected over 16-Bit parallel bus is definitely going to give some amazing performance

The main idea behind the recommendation of using an F7 is that you don't need an external display controller. The F7 has an internal display controller to which you can hook up the bare panel. I'd recommend you to have a look at @cpu20's recommendation. The STM32F746G-Discovery board doesn't cost much but gets you a decent size&quality screen and tons of memory. For evaluation and playing around that's certainly a nice solution.

Yep... https://wiki.ugfx.io/index.php/Images#RAM_usage_2

How about \demos\tools\touch_driver_test ?

Hi, Before we start to dive into this - were you able to successfully run the /demos/modules/gwin/button and/or /demos/modules/gwin/sliders demo?