Joel Bodenmann

You can find a demo with cyrillic fonts under /demos/modules/gdisp/fonts_cyrillic. There's also a wiki page: https://wiki.ugfx.io/index.php/Cyrillic Does that help?

Thank you for getting back to us on that If we look at the current implementation, that is already the case, right? See here: https://git.ugfx.io/uGFX/ugfx/src/branch/master/drivers/ginput/touch/FT5336/gmouse_lld_FT5336.c#L59

Hello & Welcome to the µGFX community! Glad to hear that you got it working! I'm a bit confused tho. ft5336ReadXYZ() seems to already return gTrue. Did you modify the driver or am I missing something?

Glad to hear that you got it working! Thank you for reporting back

Before we move any further, can you try using the latest `master` branch from the µGFX git repository? https://git.ugfx.io/ugfx/ugfx

I am a bit confused by this error. The ILI9488 driver does not implement gdisp_lld_draw_pixel() which is correct. However, the GDISP API should not call that if it's not available. Some questions: Can the compiler/linker tell you the file & linenumber where this reference occurs? Are you calling gdisp_lld_draw_pixel() manually in your application code? Does your main() do anything (µGFX related) other than gfxInit()? Did you modify the ILI9488 configuration file? Are you using the latest master branch of the µGFX git repository?

Hello & Welcome to the µGFX Community! Unfortunately, we don't speak Russian. I hope that google translate will work for you. I will try to use simple wording. Can you please show the complete compilation output when you do a clean build?

@Rafael Zingler Did you have any chance to check whether you can reproduce the crash on the Win32 or SDL port?

@Rafael Zingler Would you be able to share a minimum reproducible example (including the image and everything) which triggers the crash? Does running the same code on a desktop computer using the µGFX port for SDL or Win32 also result in the crash?

Can you reproduce the crash by just calling pvPortMalloc(2); (i.e. outside of µGFX)?

The gfxAlloc() function is simply a wrapper macro around pvPortMalloc() if you use the FreeRTOS GOS port. Could you tell us which architecture/platform you're running on? If it's Cortex-M based system, we might be able to get a bit more information out of this by printing out register values etc. in the hardfault handler. FreeRTOS has a resource on this: https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html @inmarket Any insights into this?

Assuming your image is available via the GFILE module, you can just use the gdispImageXxx() API from here: #include "gfx.h" int main(void) { gImage myImage; // Initialize uGFX and the underlying system gfxInit(); // Set up IO for our image gdispImageOpenFile(&myImage, "my_image.bmp"); gdispImageDraw(&myImage, 0, 0, gdispGetWidth(), gdispGetHeight(), 0, 0); gdispImageClose(&myImage); while(1) { gfxSleepMilliseconds(1000); } return 0; } You can find a ready-to-run demo under /demos/modules/gdisp/images.

Hey @cheater - Nice to hear from you again! We're all still looking quite forward being able to have a look at your awesome work! The µGFX-Studio does exist. However, we're currently not handing it out. The plan was to release the first public version together with the v3.0 release of µGFX. After an initial dead blow during the COVID-19 pandemic we got drowned in support requests as everybody was scrambling to migrate their products to whatever silicon was available during the semiconductor shortage and right now we're engaged in larger customer projects. The question of when the µGFX-Studio will be released has therefore become a question of when µGFX v3.0 will be released. Most of the work around µGFX v3.0 has been completed by now. The "only thing left to do" is migrating the higher-level GWIN module to the new GDISP changes as well as updating all examples & documentation. The µGFX library v2.10 is certainly due for a release. You might want to upgrade your application to the latest `master` branch of the git repo to get all the new goodies. Especially the STM32LTDC driver got improved quite a bit.

One of them is a binary representation of an actual file (Target_whiteBG_20x20.bmp in your case) whereas the other one is most likely raw decoded pixel data. The file2c utility just creates a C array of the binary representation of any file you pipe into it. You'd use its output to include into ROMFS and then draw the actual image via the high-level GDISP API with all the bells and whistles (color conversion, rotation, palette stuff, RLE and so on). Your "LCD image converter" on the other hand provides a raw pixel values tied to a specific format and resolution. Two entirely different things. You don't see an RGB666 option for the LTDC pixel format because that is not supported by the LTDC peripheral found in the STM32F429.

The file2c utility simply creates a C array of the byte-content of the file you feed into it. It doesn't perform any conversion. In fact, it doesn't even know whether you feed it a picture, an audio file or an SQL database dump. It just wraps binary data into a C array and adds some entries to use it with ROMFS. If you need to do conversions you'll have to make them before feeding the file through file2c. @inmarket An STM32F4 with LTDC and external SDRAM via FMC can actually handle a 320x240 display with two layers and RGB565. I think it can also handle 320x480. I was working on a project not so long ago with a 480x480 display, dual layer LTDC and RGB565. But yes, this is definitely true: Bandwidth considerations need to be part of the hardware design phase. If your application needs a lot of I/O bandwidth then LTDC can be a real show stopper - especially when paired with SDRAM