Joel Bodenmann

We'd need a bit more information to provide you with specific answers. In general, assuming that you have Linux running on your SOM it should be as easy as compiling an µGFX application for Linux: https://wiki.ugfx.io/index.php/Linux However, whether you can use the X, SDL or FrameBuffer driver or whether you need to use one of the other GDISP drivers depends on how your system is built (eg. how the display is connected), whether you're running a WM and so on. If you can provide more information we'll gladly point you towards the right direction.

Glad to hear that! Happy that we could help. Please don't hesitate to ask if you have any further questions.

Hello & Welcome to the µGFX community! Yes, it is possible (and very common) to do this with the µGFX library. The library has been designed to run on virtually any system/platform. Depending your system you can either use one of the "Linux" drivers (eg. X, SDL or framebuffer) or directly interface a display via GDISP (if you have a display not "integrated" into the OS).

It doesn't have "an advantage". It's just a variant of the string rendering function which also fills in the background whereas the other one doesn't. Which one is the "correct" one to use depends on what you are doing. Sometimes you don't want to override the background. Just as a side note, you can also use the various gdispGXxx() functions without the capital 'G' in them (for example just gdispFillString() or gdispDrawString()). This way you don't have to specify your display on every function call.

Glad to hear that

It's difficult to say anything helpful without getting any more details. If you call gdispGDrawString() repeatedly without clearing the area first it would be quite likely that your text will look jagged as you would basically "override" the "anti-aliasing pixels" every time further offsetting their true/apparent color values. Try to clear the area first. Alternatively, use another string rendering function (there are some variants that render with a box & background).

Hello & Welcome to the µGFX community! Can you explain a bit more what exactly you mean? One option is to use ROMFS. It comes with a little utility to convert any file into a C array essentially allowing you to "embed" files into your binary. The GFILE module allows to transparently load an image from any supported filesystem (including ROMFS). This means that you can develop your GUI on a desktop machine using one of the corresponding drivers (SDL2, X, Win32, ...) and load the files directly from the host's filesystem via NATIVEFS and if you build binaries for your embedded target you just switch over to ROMFS. All of this works without modifying a single line of your application code. I hope this helps. Please don't hesitate to ask if you have any further questions.

Hey, It seems like you just copied the same compiler output as in your initial post. Please provide a bit more information as requested in my first post.

Hello! Can you provide a bit more information regarding your environment? The errors you're getting certainly indicate that you didn't enable a GOS port (the main system abstraction layer). You can read more about that here: https://wiki.ugfx.io/index.php/GOS If you're using zephyr there is an existing port: https://wiki.ugfx.io/index.php/Zephyr If you're using another underlying operating system such as FreeRTOS there are also existing ports for those. If instead you're not using any underlying operating system (baremetal) you can use the Raw32 port: https://wiki.ugfx.io/index.php/BareMetal Also, which build system are you using?

Hey, Based on the compilation errors it seems like you didn't setup the inclusion paths properly. I haven't used Eclipse in a while, maybe someone else can chime in to help. But I'm fairly certain that it has (at least in part) to do with the paths setup. Is the use of ${ProjName} valid in those paths? And if so, does it make sense that the paths are prefixed with / ? Have you tried adding the paths exactly as they are shown in the documentation that you linked (here) ?

Hey Michael, Well, that is exactly what we are here for: To answer questions, help to guide along the way and most importantly: Improve upon feedback. If you can tell us in a little more detail which details are unclear, and to which questions you didn't find any answers we will gladly provide the necessary information and update the corresponding documentation Best regards, ~ Joel

Hello & Welcome to the µGFX community! In general, the µGFX library is known to work well on ESP32 platforms. There are plenty of customers and hobby-ists which reported quite satisfying results. Both porting and writing new display drivers is pretty easy and well documented. We're happy to help wherever we can. Do you have any specific questions we might be able to answer?

We don't know everything and we're always open for suggestions

Glad to hear that you got it working! Things like that are not as easy / as straight-forward as they might seem at first. For example, if the underlying system is configured to run in tickless mode, things start to look very different already. We try our best to add rules, checks and so on wherever sensible within the µGFX library but everything that is interface related, especially the port to the underlying OS (if any) is not easy to sanity check in a generic manner. After all, this is embedded. It's very easy to shoot yourself in the food and hard to prevent that without bloating everything or limiting use case scenarios.

Well yes, theoretically this is certainly possible. If your host has enough RAM and fast enough I/O you can certainly do this. The question would then be: why? I can only assume that this would be for educational purposes (which is fine). Traditionally, microcontrollers/CPUs are very bad at a task like this. Which is why you'd usually use a dedicated display controller. If you want to implement one yourself, you might have a much better time using an FPGA. All of that aside, usually physical display drivers (like yours) will have some minimum requirements regarding the main pixel clock. That should be your first thing to check whether you can keep up with that. Next, there are usually rather tight timing windows for the synchronization signals. Assuming that you can satisfy the I/O requirements your next consideration will be memory: For your 800*400 display you'll need 800*480*bytes-per-pixel of memory for your framebuffer. So for RGB565 that would be 768 kB. For RGB888 it would be around 1.15 MB. Does your STM32 have this much memory available? You'd most likely have to add external memory via the FSC/FSMC bus. Then you'll run into bandwidth limitations. Look at the specs of that driver chip. It will allow you to calculate the minimum bandwidth required to keep it working. Again, while potentially possible, in a real life scenario your MCU will simply not be able to keep up with it. I'm not trying to discourage you from doing this. I just want to roughly (!) explain the situation. You might be able to get this to work with an STM32 microcontroller but you'll not have a good time with it nor will you have much of it left to do anything else. This is why ST includes a dedicated display controller (LTDC) in some of their MCUs. Maybe if you can describe your intentions/ambitions/ideas/goals a bit we can be of more help here.

The HX8664/HX864 is just a display driver - it's not a display controller. The interface it offers appears to be a standard "raw" RGB interface where you have your parallel RGB input as well as signals for vertical & horizontal synchronization. That input basically needs to be driven constantly to "see" something on the actual display. That would be the job of the display controller. You cannot interface the HX8664/HX8264 in any meaningful way directly. What you seem to have is just a display panel with a display driver. You still need a physical display controller to generate those continuous RGB interface signals. Either you need another dedicated display controller OR you actually use the STM32 LTDC - which is a display controller built into some STM32 devices for exactly this situation. The µGFX library provides a driver for the STM32 LTDC display controller so you should be able to use that out of the box. I'm not sure why you want to explicitly avoid the STM32 LTDC peripheral but that's exactly what you'd need in this case (or any other display controller).

From the µGFX side of things: When using the public GDISP API (and therefore also the GWIN API), be sure to set GDISP_NEED_MULTITHREAD to GFXON in your config file. Other than that: Are you able to spawn multiple threads in the ESP32-modified-FreeRTOS version and things work as expected? i.e. is the problem specific to when you start using µGFX or are you already experiencing issues prior to that?

Hello & Welcome to the µGFX community! From the readme in the GDISP driver directory: framebuffer - Supports any non-palletized, non-bitpacked color display with a framebuffer Fb24bpp - Same as 'framebuffer' driver but supports RGB888 and BGR888 packed framebuffer formats. So to answer your question: They are technically the same thing. Fb24bpp just supports RGB888 and BGR888 packed formats whereas the regular framebuffer driver assumes non-packed formats. In general: The µGFX library is designed to support a vast number of different interfaces. To achieve this, we provide three different display driver models: https://wiki.ugfx.io/index.php/Display_Driver_Model We have yet to encounter a display/controller/module that doesn't fit into one of these categories. I'd recommend you to read the wiki page linked above and checking the datasheet if your physical display controller to figure out which mode applies. Please don´t hesitate to ask if you have any questions.

As of today, we did not commit any changes for this. Therefore, it's best that you apply the patch yourself. We're still planning to create a dedicated port for this but it's not there yet.

Would you be able to provide a diff/patch-file (as an attachment) so we can have a look at your "final" changes to the driver? This way we can more easily review them and decide whether the driver should be modified for the next release.

Glad to hear that you got it working! This is non-trivial. The µGFX library has been designed to run on virtually any system with a broad range of configuration options which have compile-time impact in an effort to reduce the required resources (including RAM) to a bare minimum. How much memory is needed is really depending on not just the application overall but also your configuration & underlying system. Especially when it comes to the GWIN module (the window manager, widgets etc.), you can choose to either use heap OR stack. The various `gwinXxxCreate()` functions accept a pointer as the first parameter. If that is NULL, then the necessary memory is dynamically allocated from the heap automatically. If you pass in a pointer, no heap allocation happens and you can instead use your stack memory (or whatever other memory you want). I know that the above is not helpful to you but it is what it is. To give you some rough estimates, a small application with a few display pages, buttons, navigations, slider, different fonts, images and so on can work with less than 1kB of RAM. The various demos are just that: demos. The idea is to keep code complexity as low as possible to maintain the focus on the aspect of whatever the demo is supposed to be demonstrating. As such, those demos try to reduce the code size as much as possible. For example, the various widget demos use heap allocation for the widgets (see above - first parameter to gwinXxxCreate() is NULL). But we don't check the returned pointer for NULL which would indicate allocation failure - eg. due to insufficient heap capacity. Any real world application would either not use the auto-allocation mechanism or properly check the returned pointer for NULL. This applies to most of the µGFX API. Error codes are returned everywhere where reasonable. Places which require (or offer) dynamic allocation typically return NULL if allocation failed. Any real wold application should check for those error codes etc.

We've added the missing driver.mk file to the SSD1322 driver: https://git.ugfx.io/uGFX/ugfx/commit/143a3a884755577fd6e5bfbece01614512f840ca

Does this also happen if you lower the FSMC frequency? Can you please elaborate on the method you used to interface the GDISP driver interface? Did you write a custom driver? If so - and you only implemented the set-pixel functionality - please make sure that your driver config file doesn't enable advanced features like hardware filling, streaming etc. The GDISP module of the µGFX library will automatically use the "best" method available to accomplish any given rendering task. This is why in general you don't want to have a driver that only implements the set-pixel function as this greatly reduces performance for more complex scenarios. But we can revisit that once you have everything working as per expectations The µGFX Studio is currently not publicly available.

Flushing is indeed required by display drivers using the framebuffer approach: https://wiki.ugfx.io/index.php/Display_Driver_Model If you don't like (or want to) flush manually, there is also built-in capabilities for flushing: GDISP_NEED_AUTOFLUSH To flush automatically GIDPS_NEED_TIMERFLUSH To flush periodically (based on a timer) Thank you for your feedback! I've added this to our ToDo list. We'll add/expand the documentation accordingly. If I kept track of your messages correctly you're basically all set now, is that correct? We certainly have to look into the SSD1322 driver at some point to determine whether this is a bug in the driver itself or simply a scenario depending situation in which case we'd need options/settings for that.

Hello & welcome to the µGFX community! The µGFX library has been designed to run on virtually anything. So pretty much any scenario you'll encounter will work. For convenience, there is a baremetal implementation which has been tested & is being used extensively on the STM32 platform. It's called RAW32. See https://wiki.ugfx.io/index.php/BareMetal As shown in the linked wiki article, this should be as easy as setting GFX_OS_USE_RAW32 to GFXON in your configuration file. Everything else happens automagically under the hood when calling gfxInit(). Additionally, you might want to set GFX_CPU, GFX_COMPILER and the memory management related options explained in the wiki article linked above. While all of this is configurable, by default this shouldn't be necessary. The corresponding documentation would be: https://wiki.ugfx.io/index.php/GWIN#Redrawing_mode Nothing special is required. The demos should work out of the box. Just make sure that you're not only using the various source files (eg. main.c) but also the corresponding configuration file (gfxconf.h). When changing values in the configuration file, be sure to perform a clean build. Other than that: You might want to give the current git master branch a try. It contains various fixes that didn't make it into the v2.9 release. However, nothing specific to your situation. Just generally a good idea. This way you'll also be ready for the upcoming v2.10 release. Given that your system is already up and running this should be easy to debug. Somewhere in your createWidgets() function there should be a call to gwinButtonCreate(). Assuming that the first parameter to that call is 0 / NULL, the µGFX library will allocate the memory dynamically. If this fails, the returned pointer would be NULL. If that is the case, your stack/heap settings might be incorrect. Refer to the settings explained in the wiki article linked above. If you continue experiencing problems after correctly setting the various options in your gfxconf.h please share your configuration file (by attaching it to your next post). Please don't hesitate to ask - we're happy to help where we can!