Joel Bodenmann

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!

Regarding the warnings of GOS_NEED_X_THREADS and GOS_NEED_X_HEAP: It would seem like we're missing the default definitions of those. But I need to look into this more properly. I'm a bit thrown off by the fact that we haven't encountered this issue before and we're working on STM32 + ChibiOS projects every day. For now, you can simply define them to GFXOFF in your gfxconf.h to be safe. Are you able to debug your system properly now?

I can't spot anything that would be deemed "obviously wrong" in your configuration file. I'm mainly confused by this: This should only be the case if you use the raw32 port (GFX_USE_OS_RAW32). This doesn't appear to be the case based on your config file. Is there any chance that you're overriding some config options directly from your build system? Did you try to do a proper clean build? Because even if you'd set GFX_USE_OS_RAW32 elsewhere the compilation should fail due to the GFX_USE_OS_xxx being mutually exclusive. Can you please do a proper clean build and share your entire build output log? Alternatively, is this an open-source project with a public repo that we can access? There's not much that can be wrong here. Both STM32 and ChibiOS are first-class citizens in the world of µGFX.

We'll add the missing driver.mk file in the next couple of days. Awesome! Can you please share your gfxconf.h? Just attach the bare file to your next post. When using ChibiOS, those should not be needed. I do assume that you set GFX_USE_OS_CHIBIOS to GFXON? You can find some of them documented here: https://wiki.ugfx.io/index.php/Configuration And for the rest there is the API documentation: https://api.ugfx.io If there's anything missing in terms of documentation will will rectify that ASAP. Exactly, so something seems wrong. The ChibiOS port is used heavily by DIYs and commercial customers. While that doesn't mean that there isn't any bug I do think that in this case it's more likely to be a configuration issue. Please share your config file(s) as mentioned above. When changing options (eg. in the gfxconf.h) don't forget to do a proper clean build. When you're using the ChibiOS port, µGFX doesn't do anything memory related. All memory management related functions are mapped to the underlying ChibiOS system.

That is actually the case! All drivers are separate components. You can use them, or you can not use them. You can do that with µGFX too. You can make a simple wrapper driver which uses the Point and Block interface. Then you only need to implement this function: gdisp_lld_draw_pixel(GDisplay *g); Where g is a pointer to the GDisplay structure which will hold x, y and color information. Let us know if you have any questions. We'll gladly help wherever we can

Just get back to this whenever it fits you. We'll be right here 😉

Hello & Welcome to the µGFX community! Honestly didn't yet get time to test with ChibiOS 21 but ChibiOS 20 support was added a few months ago. You might want to consider using the master branch of the official µGFX repository: https://git.ugfx.io/ugfx/ugfx That appears to be a "bug". That driver is indeed missing the driver.mk file. I can´t test this right now but the driver.mk file should be as simple as: GFXINC += $(GFXLIB)/drivers/gdisp/SSD1322 GFXSRC += $(GFXLIB)/drivers/gdisp/SSD1322/gdisp_lld_SSD1322.c Would be awesome if you could let us now if that worked out so we can patch the driver (adding the missing file). That's actually mishandling of the C standard by the compiler you're using (I assume it's GCC). This was something that has been going on for years. You can find some discussions of that online (and also on this forum). We eventually caved in. This was also patches in the master branch of the official µGFX git repo. First of all: Can you please provide more information regarding your setup (exact STM32 MCU that you're using, which compiler etc)? Please also share (as attachments) your gfxconf.h and your board_SSD1322.h. The SSD1322 driver uses the framebuffer model. As such, it needs to allocate a buffer large enough to serve as a framebuffer. This happens at line 69 of the driver. gfxAlloc() is used to allocate memory. The first thing you should check is whether the framebuffer allocation was successful. The driver would fail to initialize if the underlying system couldn't provide the memory needed but we have to start somewhere plus you'll need to know the framebuffer address for the next step below. The fact that your debugger cannot access memory at that location as well as your "crash" happening when accessing that framebuffer memory might indicate that it is located in an inaccessible memory section/area. To further dive into this, we really need to know the exact type of STM32 MCU you're using. The datasheet/reference-manual contains the memory map which tells you in which memory section your framebuffer got allocated. These days, microcontrollers got rather complex. They contain a lot of different memory sections with different accountabilities, policies and so on. It's not unlikely that your framebuffer got allocated in a memory section that cannot be accessed the required way. We can continue looking into this after you provided more detailed information.