Joel Bodenmann

All of these things sound like issues in the board files that you're using. As the library doesn't come with board files for that setup I guess you're using some 3rd-party board file, is that correct? We need to see your board files as well as images that show the problem in order to further help you with this. Please attach these things to your next forum post.

Hello @ronan_rt, We contacted you via e-mail to further discuss the quotation/offer on this.

It's correct that the RA8875 itself integrates a touchscreen controller. However, in many modules that one isn't used but a dedicated one instead. This also depends on whether you're using a parallel or serial interface to talk to the display controller. It's up to the manufacturer of the module that you're using and your own configuration. Currently the µGFX library only provides the basic display driver for the RA8875 - not for the corresponding touchscreen. However, it works well and is easy to implemented. We implemented a complete RA8875 driver for a commercial customer project that implements both the touchscreen controller as well as the advanced hardware acceleration - it works very well. Unfortunately we're not allowed to put the driver into the public µGFX library. Long story short: You have to write the driver yourself - but it's very easy as the interface of µGFX is very simple and there are tons of examples. Furthermore, we're happy to help if you have any questions. Alternatively, we can implement the driver for you as this is part of the services that we offer.

That is very interesting to know. I put this on our ToDo list.

Yes, @inmarket updated that demo. You have to grab the latest master branch of the repository. This is the corresponding commit: https://git.ugfx.io/uGFX/uGFX/commit/9360b2725035727262df05ae720654a48d620c69

ADS7843 / XPT2046 / TSC2046 / UH7843 , STMPE811, STMPE610 and the MAX11802 are the classic resistive touchscreen controllers which are all supported by µGFX. Additionally we have the "ADC driver" which is a driver that can be used when the four wires of the resistive touchscreen panel are connected directly to the ADC peripheral of a microcontroller. Is there something that you misunderstand or didn't you find something you were looking for?

Initializing the required peripherals is the job of the init() function in the driver and the init() function in the board file. The driver has to take care of doing driver specific initialization. In this case that means setting up the LTDC and other things that are required to use that driver no matter what actual board is used (eg. the pin configuration from one board to the other can be different although both use the LTDC driver). The board file init() on the other hand is responsible for initializing things that are specific to that board. Those are usually just the pin configurations. The images you're showing definitely suggest an issue with the clock setup. However, unfortunately I don't have time right now to dive into the datasheet and corresponding examples - that would take a lot of time. Could you simply have a look at the example that @Maytham and/or @inakto created? They have a working setup - it's just not properly integrated in terms of the driver level of uGFX but they are able to properly display things which means that they set up the clocks correctly.

Don't even think about doing that. That is a part private to the display driver itself. You must never touch that. There's a lot of stuff hidden that you don't necessarily see. Stuff like synchronization, grouped flushing, different redrawing modes and so on. If you tell us why you want to do that we'd be happy to tell you how to solve your problem or how to archive what you want correctly without breaking anything.

@vrollei Sorry for the late reply, currently having too much on our plate. As @inmarket mentioned it's very interesting to see that it appears to only happen with the '0' glyph. If you could print some A - Z and 0 - 9 set of that font (and a different font) to confirm whether it's just with the '0' or not that would be very helpful. At first I thought this might be an issue with the first read-back being inaccurate which would indicate requiring a dummy read. However, this really just happens with externally connected framebuffers where the parasitic charges haven't been discharged properly. Also, this can't be the case because your manual gdispSetPixel() / gdispGetPixel() test was successful.

Hello @viji s, We're happy to help you resolving this issue but we require a bit more information to do so. When I understand you correctly you're using the existing framebuffer driver, is that correct? Are you using pre-made board files for a known target/hardware or did you write your own board files? -> What hardware are you using? Additionally, pictures that show the problem would be very helpful. The framebuffer driver handles rotation internally by simply modifying the pixel address mapping and therefore there really shouldn't be any issues. However, bugs are always possible. A couple of pictures would be very helpful for us to see what is going on.

The rotation/orientation handling is not part of the board file - the driver is responsible for that. The board file is really just for sending the correct bytes over the used interface, physically controlling the backlight and things like that. Board files have no effect on orientation and other stuff like that. When I understand you correctly you get "correct" or "sane" output on the display but with the wrong orientation or even mirrored, is that correct? If so, look at the driver initialization sequence inside of the driver code (inside gdisp_lld_init()). The ILI9325 display driver has two bits called AM and ID (when I recall correctly) that are used to control the display orientation and mirroring/inverting. They are very well documented with good illustrations in the corresponding datasheet. Most likely you just have to change one byte value in the initialization sequence to get your display up and running. The reason for these problems is because it depends how the manufacturer of the display module connects the actual display panel to the ILI9325 display controller. The order of the physical wires dictate the correct settings for these AM and ID bits. As there are different ways to connect these wires different settings are required. For the SSD1963 driver we simply added an INVERT_X and INVERT_Y configuration macro. For µGFX 3.0 we will be using a different, more versatile display interface that allows coping with these problems. For now you simply have to adjust the AM and ID bits in the driver. I hope that helps.

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.