2024-04-11 12:25 AM
Hello all
I know there have been plenty of posts about TouchGFX not providing the full set of display rotation options usually found in other GUI systems such as emWin (0, 90, 180, 270 degrees). But I wanted to ask ST / TouchGFX if there any plans to add this functionality in the future?
As an embedded engineer we often have to provide solutions for problems, and being presented with a display that had to be mounted upside down or rotated 90 degrees is not un common, usually enclosure or PCB connector constraints demand the display is orientated so the FPC connector tail is in a pre-set position. In the real world we are not creating firmware for DISCO or NUCLEO development boards.
As a long time user of emWin, being able to rotate the display image was assumed. Its an essential feature, just like displaying a text string.
I know there is a ugly 'solution' offered that involves swapping all the pixels in the frame buffer, but as suggested this is 'expensive' in terms of bandwidth and power, and far from ideal.
I really hope TouchGFX have this feature the on their development roadmap for the near futrure.
2024-04-11 05:14 AM
Hello @David George ,
Thank you very much for your feedback! I'll elevate that internally to our team We appreciate suggestions like yours as they help us to understand the needs of our customers and on what we can focus on to enhance the TouchGFX experience. I can't promise anything but I will let you know as soon as I have more on this subject.
Best regards,
2024-04-11 05:28 AM
I appreciate that Osman.
TouchGFX is a great package, from the few projects we have done I can say it's a big improvement over emWin. Just be nice to have our lovely screen designs the right way up!
2024-04-11 09:05 AM
Hi David, i understand your idea, when i start with TGFX i have project on DSI display , that require 180 swap and i create all gui upside down. Hard to see harder todo. But i mean this isnt part of TGFX job. Orientation on 90% displays is hw issue and registers or hw setup control this over driver. And drivers isnt part of TGFX.
2024-04-11 09:41 AM
But often you have no "driver" between the frame buffers and the display.
If you are using a LCD Display with a RGB interface like STM's LTDC (using VSYNC, HSYNC, DOTCLK) then the current frame buffer is transferred directly from memory to the display, i.e. copied word for word.
The DMA2D can only copy from/to memory with a positive memory address increment, so you can't flip the display image.
There are no registers in LTDC or DMA2D that can rotate or flip an image in a frame buffer that I know of.
If you want to flip or mirror your image, the only way is to write code to move the pixel data in the frame buffer, hardly an elegant solution.
Yes TGFX offers a 0, 90 rotation, but what about the other two - 180 and 270, you'll need to mirror the frame buffer.
2024-04-11 10:22 AM
I work with many displays , and all have hw control for orientation, then your explain isnt real.
2024-04-11 10:26 AM
@MM..1 wrote:I work with many displays , and all have hw control for orientation, then your explain isnt real.
Okay great, I'd like to understand - can you explain how I can mirror a screen in hardware on a STM32H7xx device?
Display connected by RGB565 Interface, LTDC, DMA2D, double buffering, TGFX.
Thanks.
2024-04-11 10:42 AM
You require Driver IC info and controller bus connection to display registers setup. Some displays have two pin on connector , that by sel high or low level rotate etc. You as designer have job to choice right display.
2024-04-11 10:55 AM
The registers you are talking about (Row, Column address increment control) are only used when transferring display data from the internal display RAM in the display controller. The display data in this internal RAM is usually sent using a slower I2C, SPI or a 8/16/18 bit MCU interface.
But when using a RGB video VSync, HSync, DotClk interface the display data bypasses the internal RAM and goes straight to the pixels at the frame rate its clocked in at.
So changing the Row, Column address increment registers will have no effect on the displayed image.
Why do we choose a RGB interface? Because its fast and allows 60Hz frame rates, and this is also the interface required by the LTDC in the STM32.
Sure not all displays are the same, but I bet in RGB video mode they all operate the same way.
2024-04-11 11:11 AM - edited 2024-04-12 06:45 AM
Show your display info and dont waste time with this theory. RGB dont define, that display skips internal memory, and some displays dont have internal memory and accept setups for rotation...
One example ST7262 800x480