Joel Bodenmann

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.

Hey, I was just about to respond to your posts from yesterday - they seem to be deleted now. Also your initial post appears to be edited. Did you managed to get it working?

Hello & Welcome to the µGFX community! It's difficult to get any information from just a picture of a display module. In general, any display can be interfaced with µGFX due to the flexible interface design. ILI9341 based displays are certainly very common and used by plenty of individuals and commercial customers. Could you please provide more detailed information such as: The physical interface used (i.e. parallel 4-bit, parallel 8-bit, parallel 16-bit, RGB, SPI, I2C, ...) The GDISP board file(s) you're using Your gfxconf.h Datasheet of the display module itself (or link to where you purchased it from) Details on how you hooked up that display module to your host controller In general, if only colors are incorrect you're almost there. This indicates that the system is overall working. Common sources of problems regarding colors: Incorrectly configured color format Incorrect color handling in GDISP board file (if any) Incorrect display controller initialization Incorrect wiring if using a parallel interface The last point is unfortunately very common with ILIxxxx display controllers. What we observed over the years is that often you get a different chip than advertised, differences in silicon revisions, knock-offs and so on. Often you'll be supplied with a display controller initialization sequence from your dispaly module vendor. This sequence can sometimes look different than the sequence of the official ILI9341 driver found in gdisp_lld_init() here: https://git.ugfx.io/uGFX/ugfx/src/branch/master/drivers/gdisp/ILI9341/gdisp_lld_ILI9341.c The logo should actually be white on back

Hi! The µGFX GDISP module provides different kinds of driver interfaces. These are listed explained here: https://wiki.ugfx.io/index.php/Display_Driver_Model The framebuffer model is only one of them. If your display controller doesn't provide direct access to the framebuffer it's usually not the right model to use. Please don't hesitate to ask if you have any questions!

Also: Hello & Welcome to the µGFX community

Hey! Yeah that is indeed one possibility. However, right now we're more tending towards creating a dedicated port for the ESP32 FreeRTOS version. The reason is maintenance. When someone (in this case Espressif) is willing to modify something like FreeRTOS it's not unlikely that other changes can follow in the future. Furthermore, it's not unlikely that we want to update the µGFX FreeRTOS port to support newer FreeRTOS version in the future while the ESP32 modified version might not have been updated by Espressif. Having a dedicated port just makes this a lot easier to maintain. In case you want to help on that effort: inside the /src/gos folder the existing FreeRTOS port can be copied, renamed to freertos_esp32.[ch] and modified for this version. There are a few more bits & pieces that need to be modified (eg. new configuration macro to use this GOS port, adding it to the GOS port list and so on).

Thank you for all the information you provided. We're still discussing this internally. Personally, I have no idea why anybody would do this but I guess it is what it is. We'll most likely not have a choice other than providing a dedicated GOS port (µGFX operating system abstraction) for this modified version of FreeRTOS...

Thank you for sharing - we will review this in the next couple of days. Just to be sure here: Those modifications, are they to support a newer version of FreeRTOS or is the FreeRTOS used on the ESP32 modified by Espressif themselves? If so, I'd wonder why.

Ideally you'd provide us with a patch file (eg. by running git diff). This way we can look at the changes you propose and review them. If for whatever reason that is not an option you can also send us the modified files and we will generate the patch file ourselves.

Very nice! Keep it up!

Hello & welcome to the µGFX community! It's always nice to see when people write drivers & board files for new hardware/kits. Nice! If you're willing to share your efforts (drivers, board files, ...) we'd gladly review those and potentially add them to the library so new users can get started with µGFX on this platform very easily thanks to you!