Joel Bodenmann

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?

Glad to hear that you guys managed to figure it out Thank you for your help, @cpu20!

Just FIY: That is documented here: https://wiki.ugfx.io/index.php/Getting_Started#Single_File_Inclusion (the Note)