Joel Bodenmann

Other than that, you might want to consider using a display controller that too offers an SPI interface but that offers hardware acceleration along that. Even if it can just draw rectangles you'll get a HUGE performance improvement. Have a look at the RA8875 as an example.

Can you please check whether the pixel read-back is actually working? You can do that by setting a pixel to a specific color using gdispDrawPixel() and then using gdispGetPixel() to retrieve the color value again. They must be the same. If that doesn't work, then there's an issue somewhere in the driver.

Hello @vrollei and welcome to the µGFX community! First of all: The gdispFillString() and the gdispFillStringBox() functions don't require pixel read-back as one of the parameters is the background color. The other string rendering functions require pixel read-back in order to render the text anti-aliased. The STM32LTDC driver already implements pixel read-back so everything should work out of the box. Most likely you simply forgot to use a font that comes with anti-aliasing. In order to minimize the memory requirements regular fonts don't have anti-aliasing support. You can enable anti-aliasing support when converting the font. Alternatively, you can use one of the built-in fonts that support anti-aliasing. I hope that helps. Please don't hesitate to ask if you have any further questions.

To extend/elaborate/explain what @inmarket mentioned: The GFILE module has a settings named GFILE_MAX_FILES that specifies the maximum number of files that can be opened at once. Emphasis on the at once part. You can use an unlimited number of files but only GFILE_MAX_FILES files can be opened simultaneously. Therefore, you might want to close images (and other resource files) that you don't access frequently. Please check the documentation for more information on things like GFILE_MAX_FILES, image caching and more. Anyway, hitting the limit of GFILE_MAX_FILES definitely doesn't cause a hardfault. The corresponding gfileOpen() function would simply return an error code but there is nothing that causes a hardfault. The system is very robust: Even if you're trying to cache or draw an image that comes from a file that couldn't be opened successfully nothing will happen. As @inmarket mentioned images are never stored in RAM. However, there are small overheads which depend on the image format. Most likely you are simply running out of memory. Note that "running out of memory" doesn't mean that your microcontroller has no more RAM left but that probably your context is out of memory. For example, when you're drawing an image in a thread, it uses the thread stack. If the thread doesn't have a sufficient stack size you'll end up causing a stack overflow which almost always results in a hard fault. If you're running bare metal (with no underlying operating system by using the Raw32 port) you might want to adjust GFX_OS_HEAP_SIZE as discussed in the corresponding documentation. That's what we can give you right now. If you have more questions, please don't hesitate to ask.

Hello @lampii and welcome to the µGFX community! You can find @Constantine's remaked driver here: Please don't hesitate to ask if you have any questions. We're happy to help wherever we can.

Hello and welcome to the µGFX community! GOS (the core part of µGFX) works on ChibiOS without any issues at all, not changes or tweaks required - it just runs out of the box. Yes, that combination is working. We have several customers and even community members here who are running that setup. However, the board files for the display that come as part of the µGFX library are incompatible with the ST headers that are used by ChibiOS. Unfortunately we still didn't get to updating the board files as we are literally drowning in work. It works well but you have to modify the board files slightly. This can be done by simply following the compiler errors. It is important that you understand that µGFX runs on ChibiOS out of the box without modifications. It's really just the specific board files of the STM32F746G-Discovery board that are slightly incompatible. Even the actual display driver is running - just the board files are a small problem. Our community member @Smd has this setup running and he wanted to share his modified board files so we can include it as part of the official library. However, he's unfortunately very busy lately with his company and he simply couldn't get the time to clean them up. Maybe we can get him to provide us with some un-cleaned-up board files

Please don't hesitate to ask if you have any other questions. We're happy to help wherever we can. In this case it's just simply a case of giving your widgets the correct coordinates as @inmarket mentioned.

A happy new year to you as well My bad, gfxClear() indeed doesn't exist. It's gdispClear() (that takes a color parameter) that I was referring to. It's simply a typo due to writing on the phone and not re-reading the text afterwards. That's expected when using a serial interface. However, you still want to make sure that your SPI peripheral is set up correctly to use the highest possible clock frequency and so on. But the real game changer is called hardware acceleration: The RA8875 display controller provides certain hardware accelerated drawing operations. For example, you can tell it the coordinates, dimensions and color of a rectangle and it will automatically draw it for you. This means that you only have to sent a couple of bytes via SPI instead of one or multiple bytes for each pixel. You really want to implement hardware acceleration. Unfortunately the current driver that comes with the µGFX library doesn't implement these. We implemented them but that was for a commercial customer with a support contract that paid us to do it without giving us the permission to include it into the library afterwards. It's really easy and you can have a look at the other drivers that implement hardware acceleration. The available interfaces are defined in /src/gdisp/gdisp_driver.h. Most notably you want to implement hardware clears, hardware fills and similar. That sounds like you're not sending the proper color format to the display controller. Have a look at the display controller datasheet. They usually support different color formats and the color format you choose comes with a definition of how the colors have to be packed when sent over each interface. Make sure that you set up the display controller to use the correct color format and that you sent them correctly. The driver configuration file contains a macro that specifies the color format that uGFX will use as well. Everything has to match up or you'll have to translate the colors. Usually you want to wrap everything in HTML2COLOR() anyway. Please don't hesitate to ask if you have any additional questions. We're happy to help wherever we can.

It looks like the memory (framebuffer) access gets disrupted. Is it possible that you're writing to the display from multiple threads without having GDISP_NEED_MULTITHREAD set to TRUE in your configuration file? Other than that, is it possible that your I2C pins are shared with the FMC pins? It really seems like the panel synchronization signals are getting screwed up.

I'm really not sure what your actual question is. Can you try to be more specific and/or to rephrase your actual question?

@inmarket just added the new function named gwinListItemSetText() to the library. You can grab the latest master branch of the repository to use this new feature. Please let us know if there are any problems.

Great, Thanks!

You're welcome. One thing though: Can you please stop quoting the previous post all the time? It makes it very hard to read through a topic. You can reply to a topic without quoting the previous message. Quoting is really just helpful if you refer to just a specific part of a previous message or a message that was mentioned quite a few posts ago.

My question is why you're doing the "already rotated with other software" part. Just let µGFX handle the orientation, it is doing that very well. What are your reasons to rotate externally? You can just use gdispSetOrientation() to change your screen orientation.

Hello @topsecret9x and welcome to the µGFX community! @inmarket pretty much said everything there is to say. However, just for completeness I'd like to point you towards this solution which uses a slightly modified pixmap to work with alpha: Whether or not that is useful depends a lot on your application & platform.

Please don't hesitate to ask if you have any further questions. We are happy to help wherever we can. We have just been exceptionally busy the past two weeks due to Christmas vacation and moving to a new office.

Hello @nquantum and welcome to the community! Sorry for the long response time. We're currently on Christmas vacation and we used that time window to move to a new office which took a lot of our time. I'm on the run to catch a train to get to a meeting right now but I'll get back to you in a few hours.

For completeness: It's gdispAddFont() that was added recently (it's already part of µGFX 2.7).

Hi there, We are currently both on vacation & currently moving to a new office. Sorry for the longer-than-expected delay on this. We should be fully operational by next week.

I took a look at your configuration file and there's nothing wrong with it. GFX_OS_EXTRA_INIT_FUNCTION is documented here. All it does is allowing you to register a function that will be called before all the other things of the µGFX library get initialized when calling gfxInit(). Raw32OSInit() is a function defined in the board files for the STM32F746G-Discovery board that initializes the SDRAM and all other things required to run µGFX on that board without depending on any other things such as CubeHAL or similar. You don't need to use that if you have your own initialization functions. The function is there so we can run any demo on the STM32F746G-Discovery board without modifying the application code.

We have solved this problem. It's working well in our test projects. Putting together an official demo that we can provide as ready-to-run project from the download section is a different matter - it takes time to do that. We appreciate it that you brought this to our attention.

As mentioned a couple of times we will put together an official demo within the following days. If this is urgent for you due to a project deadline, please consider contacting us for priority support. This is a free support forum that the µGFX developers maintain in their spare-time.

1. Please don't modify the µGFX library source files. The moment you modify one of the source files from the µGFX library that is not part of your own project directory/code you are doing something horribly wrong. The µGFX library direction is created and maintained in a fashion that allows using the same directory on any system and upgrading at any time by simply replacing the directory. Changing the code if gfx.c or any other µGFX library directory file is completely destroying all of these things. Keep your project specific stuff in your project. Do never ever modify µGFX code unless you know what you're doing. You will face issues in the future otherwise and every time you ask something we will loose a lot of time because you are not using the version of the library that we provide. Seriously, I cannot stress this enough: Never ever modify µGFX library files. Everything inside the /ugfx directory is off-limits. The Raw32 implementation code for the systicks is totally application/platform/target specific - hence you want to put that code somewhere in your own project scope. 2. Please use code-boxes if you want to paste code as part of your forum post (like I will below). That helps not only to keep everything nice, clean & easy to read but also allows optimizing search engine results. 3. The primary goal of you right now is to get your display up and running. Trying to directly run a full blown GUI, complex demo or µGFX-Studio project is simply a bad idea if you don't know that your display is working already. Build up from simple things. There's absolutely no reason why you would want to try rendering texts, images, widgets and other things if you can even change the color of the entire display. Just run something like this to make sure that your display stuff is working properly: #include "gfx.h" void main(void) { gfxInit(); while (1) { gfxClear(Blue); gfxSleepMilliseconds(500); gfxClear(Red); gfxSleepMilliseconds(500); } } Alternatively you can run any of the demos in the /demos directory. Again, start with the simple stuff. In that case we'd recommend getting /demos/modules/gdisp/basics up and running first. Please don't hesitate to ask if you have any other questions.

@inmarket just pushed a fix to the master branch of the repository. Can you please grab that, try it and let us know whether everything is working as expected now?

We'll put together an official ready-to-run project for the STM32F746G-Discovery project using the SW4STM32 / AC6 IDE. It should be ready for download within a week.