Joel Bodenmann

Usually that shouldn't be necessary. First of all, the µGFX makefiles have certain variables that you can modify in your own application specific makefile. Furthermore, there are platform specific makesfiles if the variables are not enough. But you certainly shouldn't modify anything else.

Cool, great work!

Maybe this helps: https://wiki.ugfx.io/index.php/BareMetal#SysTick

Yep, @cpu20 is correct. That's the reason why the FreeRTOS looks different from the ChibiOS port. Are you sure that you are doing everything exactly as shown in the wiki article? The FreeRTOS port is used by dozens of commercial customers, hundreds of makers and even quite a few Universities. There shouldn't be any fundamental problem with that. I used it myself without any problems about half a year ago.

The connection of the physical signals definitely needs to map 1:1 as that wouldn't only have an impact on the color values but also on any other values you write such as initialization values and other commands. I don't have another explanation for this at the moment. What you experienced happens often and so far it was always related to a mismatching config between the display controller and the µGFX configuration. But I guess the most important thing is that you have it working - that makes investigating a lot less frustrating

Well, glad to hear that you got it working! RGB vs BRG is really just a different order of the bytes representing the color value. It's up to the display controller to decide which of the two will be used and µGFX simply adapts to that. With display controllers like the one you're using it's usually possible to configure that during initialization. You might want to have a look at that. The 24 bit thing is most likely a packed vs. non-packed issue. But it's hard to say without knowing the exact details. This again is something that can often be configured on more advanced display controllers.

There are three ways to run µGFX on Linux: Directly on the framebuffer On top of the X window manager As an SDL2 application Which one you choose depends on your needs. If you want to run µGFX directly on the framebuffer then you certainly need a Linux kernel with framebuffer support. The µGFX GDISP driver will simply render into the framebuffer device provided by Linux.

Hello Steffen, As you mentioned yourself the default window manager doesn't handle overlapping windows at all. However, it's possible to write your own window manager. Our community member @Steffan made a demo once:

Don't hesitate to ask if you have any further questions - we're happy to help

Hello @jano, The pricing on shown on the current version of the website is correct. The $5/device option has been removed.

Hi, The workflow usually looks like this: Create a bare hello-world project on your target that runs without any µGFX stuff at all Integrate µGFX into the build system. Therefore, creating a bare hello-world project for your target that runs with µGFX. It's important to disable all the modules (no GDISP, no GINPUT, ...) Enable the GDISP module. Use the TestStub driver to test the compilation process. Then determine whether you have to write your own display driver or whether you can use an existing one and just modify the board files. Enable the GINPUT module (if required). Determine whether you have to write your own mouse/touch driver or whether you can use an existing one and just modify the board files. Enable GWIN, enjoy. Most of the stuff that happens is outside of µGFX (eg writing the board files, setting up peripherals and so on). The goal is to create an environment that already does everything (correct peripherals initialization and so on) and then just put µGFX on top of that.

Hello @jano and welcome to the µGFX community! Thank you very much for sharing your experience with us - we appreciate it greatly and I'm sure other uses will do too in the future

Hello & welcome to the µGFX community! There are currently no official examples for that. However, it should be very straight forward to get that working. The FSMC vs. FMC stuff does not concern µGFX at all - that only affects the changes in the board file which are always hardware/platform/target specific. FMC doesn't work that different from FSMC. It's basically just more features. You should be able to take one of the existing FSMC examples and adapt it to your FMC needs. It's always good practice to make sure that your peripherals are working outside of µGFX prior to writing the board files for µGFX.

Glad to hear that you managed to get it working! The best solution is to pre-render everything into an off-screen area called a pixmap. Once everything has been rendered you can simply copy the pixmap contents to the real display. Therefore, there won't be any flickering at all. You can find the documentation about pixmaps here. I'd also recommend you to think about writing a custom widget. That would allow you to better control the way the widget is being rendered and you could manually cache the parts of the images that are going to be overwritten by the texts on top of it. You can find an entire guide on how to create a custom widget here. I hope that helps!

Hello @Simon, Did you make sure that you use the latest version of the µGFX library? There have been a few changes/improvements in the last release. gfxInit() not returning indicates that some part of the initialization failed. The easiest way to track it down is by stepping through the code. One other think you can try is forcing the usage of the built-in memory manager that comes with µGFX. You can do that by setting GFX_OS_HEAP_SIZE to a non-zero value. All µGFX heap allocation calls are then managed by µGFX internally. If it's set to 0, the memory manager of the underlying system will be used (in this case FreeRTOS). There are different heap managers that you can use with FreeRTOS and this test would certainly help to find out whether there might be a problem with that. But I'd recommend you to get started by stepping through the gfxInit() code to find the source of the problem. Your code looks good in general - nothing rings the alarm bells right now. EDIT: One thing that just came to my mind: Are you sure that you want to call the GUIThread from the uGFXInit() thread? It has been quite a while since I worked with FreeRTOS the last time but I could imagine that that is a problem due to nested stack spaces (eg. uGFXInit would need all its stack + the stack of the new thread) and probably also scopes. Did you try following the example given in the wiki?

Glad to hear that you managed to get it working! Thank you for your suggestion. This surely sounds interesting. I added as task to our ToDo list - we'll look into it.

One thing that helps is using the widget tags. This way you can simply switch-case every widget based on an uint16_t that gets added to each widget. More information: https://wiki.ugfx.io/index.php/Widgets#Tag

Like any other module, sub-system and feature you can enable the GWIN module in the configuration file by setting GFX_USE_GWIN to TRUE. Just make sure that you use the gfxconf.h file that is part of the demo and everything will be fine. Those demos are supposed to run out-of-the-box.

It seems like you're not including the GWIN module when compiling. Please make sure that you're using the gfxconf.h supplied with the demo when compiling a demo from /demos.

When using the makefile build system, you need to make sure that your $(GFXLIB) variable is pointing to the µGFX library top-level directory. @inmarket is trying to tell you that that path is wrong because obviously the make build system is not finding the corresponding make files that get included from the µGFX library.

Hello guys, Thank you for bringing this to our attention. As you probably guessed there has been an issue with the server. This has been fixed now. No data has been lost or leaked. It was a simple out-of-disk-space issue which was not caught by the monitoring software. We are sorry for the inconveniences.

As a passionate Arch user I can confirm that that's true I'm not sure if you just use that as a comparison or if you actually want to compile for Windows too. But there's a complete guide for Windows on the wiki.

Do you need to use a 4D-Systems display? You can use any kind of display and touchscreen with µGFX.

What's the problem there? The existing GINPUT Linux event driver has been successfully used with touchscreens in many projects. Keep in mind that every Linux distribution tends to use different device paths (eg. /dev/event0 and so on) so minor modification is necessary. If I remember correctly there's a proper #define for that in the board file.

Thanks a lot for testing, @cpu20. Much appreciated!