STemWin LCD Rotation on STM32F429 Discovery

[ralphj]

Posted on January 03, 2016 at 07:37

Hello,

I'm trying to rotate the display on an STM32F429 Discovery board by 90 degrees clockwise.  When I tried to place objects such as text, hline, and vline, the coordinates weren't quite what I expected (in fact, most of the pixels were being placed off the screen).  I'm using the driver GUIDRV_LIN_OSY_16.  Using this 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:&sharpdefine XSIZE_PHYS 240&sharpdefine YSIZE_PHYS 320I 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 I'll try to attach to illustrate 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'm using v5.22 of STemWin.  I read that the version is up to 5.26 so I'm going to try to locate that now.If anyone has any experience with this issue I would really appreciate any feedback.Thank you. #stemwin #orientation

[kecskesgery]

Posted on January 04, 2016 at 18:48 Hey! Under the Middlewares there is the LCDConf.c file, which contains all the necessary configs for your LCD. Now, in the function LCD_X_Config, you can set the default orientation of the STemWin, by giving the proper value to the

// Orientation
//
Config.Orientation

The values can be (either one of them, or combination of them): -GUI_SWAP_XY -GUI_MIRROR_X - GUI_MIRROR_Y You just gonna have to play around a little bit to get the setting you desire. Cheers!

[ralphj]

Posted on January 06, 2016 at 16:53

Update:

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:http://forum.segger.com/index.php?page=Thread&threadID=1672I 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.