Hello,


I'm using the STemWin graphics libraries in an STM32F429 to drive a controller-less, 480x272 LCD (landscape orientation). The libraries work fine, if I keep the LCD in the landscape position and use GUIDRV_Lin_16_API as the driver. However, in the final product the LCD will be oriented in the portrait mode, 90 degrees clockwise from the default landscape position.


I am using STemWin version 5.22; I've listed the available drivers below and commented with the results that I get.



#define GUIDRV_LIN_16 &GUIDRV_Lin_16_API //Landscape. Default orientation.
#define GUIDRV_LIN_OY_16 &GUIDRV_Lin_OY_16_API //Landscape. Bottom is now the top. And mirrored.
#define GUIDRV_LIN_OX_16 &GUIDRV_Lin_OX_16_API //Landscape. Mirrored version of the default orientation.
#define GUIDRV_LIN_OXY_16 &GUIDRV_Lin_OXY_16_API //Landscape. Normal screen turned upside down.
#define GUIDRV_LIN_OS_16 &GUIDRV_Lin_OS_16_API //Portrait. 90 degrees clockwise from default. And mirrored.
#define GUIDRV_LIN_OSY_16 &GUIDRV_Lin_OSY_16_API //Portrait? Pushes image off the screen...to the right of GUIDRV_LIN_OSX_16.
#define GUIDRV_LIN_OSX_16 &GUIDRV_Lin_OSX_16_API //Portrait. 90 degrees counter-clockwise from default.
#define GUIDRV_LIN_OSXY_16 &GUIDRV_Lin_OSXY_16_API //Driver isn't available in the current library? v5.22

Another thing that I should mention is that the text works fine in every orientation (well, mirrored in some cases). However, the graphics functions, such as GUI_DrawVLine, only work correctly when I use GUIDRV_Lin_16_API. When using any other driver, the lines tend to get shifted around a bit.


Are there working drivers available so that I can use my display rotated clockwise 90 degrees? Or is this a case where I need to write some additional code?


Thank you!

It turns out that STemWin isn't supported by Segger, and though I've never had good luck with ST Support, I tried them and so far haven't received more than a link to an app note.


I've had time to get back to this over the Christmas holiday. I've found that GUIDRV_LIN_OSY_16 seems to be the right driver for my orientation (90 degrees clockwise). One of the things that was throwing me off was the coordinates. I assumed that if I placed text or graphics at a particular x,y location in one orientation it would maintain that same location no matter which orientation was selected. In the case of GUIDRV_LIN_OSY_16, the pixels were pushed off the screen when I tried to place text at 20,20, for example. I'm not sure if that tells me that my assumption is bad, or if I still may have something configured incorrectly. To me, it looks like the fact that the display is mirrored requires an alternate set of coordinates to reach a desired location. I don't know yet whether that is due to incorrect setup of the driver, or if that is something I need to account for when I make a call to the graphics functions.


Another thing that I've noticed is that in this orientation, text and vertical lines are placed at different locations when their functions are passed identical coordinates.

Update:

Using the GUIDRV_LIN_OSY_16 driver, it seems that because the x and y axis are swapped, then mirrored about the y axis, that my problems were being exacerbated. So I took a step back and used GUIDRV_LIN_OS_16 which just swaps the x and y axis. So the problem that I'm having is that the vlines are displayed correctly, but hlines place pixels on several different horizontal lines (as viewed in the new orientation). It's as if the libraries don't know the correct number of pixels in a horizontal scan of the LCD to get to the next pixel in the rotated horizontal line. I'm hoping that this is only because I have something configured incorrectly.

I left the dimensions of the screen the same as the original cube Discovery board project:
#define XSIZE_PHYS 240
#define YSIZE_PHYS 320

I thought that perhaps in LCD_LL_LayerInit where the layers are initialized that I should reverse the xsize and ysize when the window is configured, but this made the display completely jumbled.

I have a test case that illustrates my problem; it uses the following calls:
GUI_DispStringAt("Test Text", 5, 150);
GUI_DrawVLine(15,100, 200);
GUI_DrawHLine(100,15, 20);

The text isn't placed exactly where I thought it would be, but I'm pleased that text works so well.



I also found that in the call to LCD_X_Config(), the following lines of code swap x and y if the driver is configured for swapping (it is, because I am using GUIDRV_LIN_OS_16 for this test ).

if (LCD_GetSwapXYEx(0))
{
LCD_SetSizeEx (0, YSIZE_PHYS, XSIZE_PHYS);
LCD_SetVSizeEx(0, YSIZE_PHYS * NUM_VSCREENS, XSIZE_PHYS);
}
else
{
LCD_SetSizeEx (0, XSIZE_PHYS, YSIZE_PHYS);
LCD_SetVSizeEx(0, XSIZE_PHYS, YSIZE_PHYS * NUM_VSCREENS);
}

However, if modify so that XSIZE_PHYS and YSIZE_PHYS are not swapped, then the horizontal problem is fixed. But now the text string is all jumbled.

To me it looks like the problem is that when the x size and y size are swapped the libraries treat the LCD frame buffer as if it should also correspond to those rotated dimensions. If I'm thinking of this correctly, the frame buffer should be, and has to stay mapped to the actual default orientation of the LCD, because that's the way the LTDC module pulls the pixel data from memory.

As a possible work around I tried changing the x and y size at various times depending on whether I was writing text or lines. This sort of worked, except that the size of the lines that I could write was limited to the un-rotated dimensions of the LCD. I also wouldn't have much hope that other widgets could be rendered correctly, but I haven't tried it yet.

Confirmed that this behavior is the same in STemWin v5.28.

Segger has a forum post about rotation:
STemWin stm32F429 Disco Lcd rotation of 90 degrees

I may be able to get around this on the Discovery board by calling the GUI_SetOrientation() function. My first try at this didn't work, but perhaps I'm not calling it in the right spot. I don't think I can use this approach on my custom board because it doesn't have nearly the amount of RAM that the Discovery board has.