Hi,
I am using STemWin on a ST32F429 in combination with a ST7735S connected to the cpu over an 8 bit interface. My pixel are 16 bit with color format RGB=565. My controller expects the bytes to be transferred R5G3, G3B5.
The problem I am running into is that if eg i work with a memdev the 16bit pixel data in that memdev is not in the correct order for that transfer order.
Eg a red pixel that should be
0xF8 0x00
is stored as
0x00 0xF8
Then when transferring this data to the screen it seems the memdev memory buffer is first copied to an intermediate swap buffer so that the order becomes 0xF8 0x00 before the bytes are presented to the low level 8 bit transfer functions.
I have 2 problems with that:
1. I want to eliminate the overhead of the extra swap+copy action
2. I have source images in a raw format with the bytes in the correct order that I copy directly into the memdev memory region. However with the swapping operation my colors become corrupt.
I can 'solve' the first issue by faking a 16 bit interface to the controller by use the 16 bit low lever interface functions (in that case the memdev memory region is passed directly to the low level functions without the intermediate swapped buffer) , and if i change the order in which the bytes are transferred in the low level functions i can fix the the colors of my raw images but then any drawing functions i do in stemwin have the wrong colors .
Is it possible to get a stemwin build where the bytes are stored in memory in the correct order ?
I dont know if the LCD_ENDIAN_BIG compile flag has an effect on this , or that is just activates the swapping function at the end.
(note: i could either create my raw images in the incorrect order too, or pass colors to emwin that are 'wrong' but that will come out correct after the swapping but the latter wont work if i let stewmwin calulcate color gradients)
