Joel Bodenmann

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!

Yes, it's located under /tools/mcufontencoder/src

Have a look at some of the application demos. You'd want to do something like this instead: switch(event->type) { case GEVENT_TOGGLE: // Here you know it's a toggle event // You can cast the event to GEventToggle* and retrieve information which toggle triggered the event and the true/false state break; } No worries! We try our best to work together - Language has never been a problem 😉

Hello and welcome to the µGFX community! That is indeed the correct/expected behavior Depending on your application design, you can just keep the font open and re-use it later. So during initialization, open your font and keep it open. You can create and destroy any number of widgets & containers you want without having to close the font if you plan to re-use it later. Glad to hear that - sorry for the late response. Please don't hesitate to ask if you have any other questions!

Hey! Unfortunately, I have no real understanding of the cyrillic glyphs. While this might sound silly to you: Could you tell us what appears "wrong" in the picture that you showed? In general the font converter utility can convert any TTF or BDF font. If your source font is fine, it should work. When working with small font sizes, make sure that the source font gets converted to a size where the smallest 1-pixel resolution is actually working. What I mean to say: Can you try to re-convert your font but this time with a larger font size and see whether that yields better results? The idea is to check whether the tools work properly.

UC8175 datasheet seems to be publicly available from the good-display.com website. I'll attach the actual PDF to this post for preservation: UC8175-1.pdf

I think that's a typo in the readme that you're mentioning. Unfortunately, I am unable to share the datasheets of the UltraChip controllers I have as they were acquired under NDA While I don't know for sure, experience would certainly say that you can use the one driver as a starting point for the other driver you're intending to make. As usual: Don't hesitate to ask if you have any questions. We're happy to help wherever we can.

Hello & Welcome to the µGFX community! Those ILIxxxx chips are known to have "problems" with different default configurations and incorrect reset values across different versions and revisions. This is especially bad with clones. Given that everything else is working this might be as simple as flipping the scan direction bit(s) in the display controller's control register. Check the SS bit in the Display Function Control Register (0xb6). That controls one of the scan directions. There is another such register value to control the other scan direction somewhere. These two values allow you to "flip" the display. Please don't hesitate to ask if you have any further questions - we're happy to help wherever we can!

The function in question is named snprintg(): https://git.ugfx.io/uGFX/ugfx/src/branch/master/src/gfile/gfile.h#L378

@lijian100 Welcome to the µGFX community! We need more information in order to help you out. Please open a new topic and describe the problem you're facing with the necessary code snippets.

Glad to hear that you're making progress Feel free to ask if you have any more questions. We're happy to help wherever we can!

Hello & welcome to the µGFX community. Given that the library currently doesn't ship with a GDISP driver for the ST7789 I assume that you wrote your own. We'll try to address your issues as best as we can: Speed: Make sure that your driver is setup correctly and that your host's SPI is configured to run at a decent speed. Check the corresponding datasheet(s) to determine the maximum allowed bus frequency that your physical driver and display module can handle. Brightness: Not every display module uses features built into the physical controller for screen brightness control. Often you get a simple set of LEDs with which you can control the brightness via PWM. Check whether this is the case in your scenario. If so, changing any of the physical display driver configuration registers won't have any effect on the display brightness. You can setup a PWM peripheral in your GDISP driver's board file in order to still be able to use gdispSetBacklight() to control the brightness. Full image: I'm not sure what you mean by this. However, this sounds again like an issue with your GDISP driver. I do not know which "LCD image converter tool" you're talking about. Image formats supported by µGFX are listed here: https://wiki.ugfx.io/index.php/Images It's difficult to help without being able to review the driver. If you're unable to share the driver publicly, you can get in touch with us for paid support.

Hello & welcome to the µGFX community! Regarding your first compilation output: It seems like the corresponding features are not enabled in the configuration file (gfxconf.h). Most notably it seems like GDISP_NEED_TEXT and GWIN_NEED_TABSET. Did you use the configuration file that ships with the demo? If they are not enabled in there we certainly need to update that demo. The same seems to be the case with your second compilation output. It seems like some features such as text, circles and GINPUT are not enabled. Useful resources: Example configuration file: https://git.ugfx.io/uGFX/ugfx/src/branch/master/gfxconf.example.h Wiki article: https://wiki.ugfx.io/index.php/Configuration

We're currently in the process of adding support for the CMake build system. The current master branch of the git repo contains the current efforts. One can easily include the µGFX library into a consuming cmake project using find_package(). We're still in the process of adding support for all the currently available boards & drivers.

As long as you can avoid modifying library code that's certainly the way to go. Can you share the code of how you create the container? See the section regarding "Border": https://wiki.ugfx.io/index.php/Container#Border

Yes, the window manager will resize a widget to fit into the parent. This is where the inner size (inner width & inner height) come into play. Check the return values of gwinGetInnerWidth() and gwinGetInnerHeight() of the parent container. This will most likely return the values you initially reported. The WM has no other option but to resize the widget to fit those dimensions. If your child needs to have those exact dimensions, either make the parent container larger or implement a container which handles this the way you need it. I think the default built-in container has a border vs. no-border option (check the docs). I think if you disable the border the inner size will not be reduced by the border size.