I noticed a blue <-> green color swap on my ST7789V display (other colors were also wrong). This shouldn't happen if it is a bit order problem, since green is centred. So in my case the bytes were swapped (16 bit color, RGB565).
I could resolve it by changing the SPI data size from 8 to 16 bit. This way 100 % red is transmitted as 0xF800 instead of 0x00F8.
However this messed with the initialisation commands, which are 1, 2 and 5 bytes in length. So I ended up starting with SPI set up in 8 bit mode (configured through CubeMX). Then after the initialisation I switch to 16 bit mode by copying the void MX_SPI3_Init() method from main.c and modifying the hspi3.Init.DataSize parameter (see pseudo code below).
For this particular display, the command 0x2C is sent before the pixel data. Luckily the display does not care, that this command is now 0x002C (probably since 0x00 = nop). So there is no need to constantly change between 8 and 16 bit mode. I am also using a full buffer (for now), so the drawing window can be during the initialisation.
// NOTE: Remember to manually update this function if your SPI settings change (e.g. prescaler etc.)
static void MX_SPI3_Init_16() {
// ...
hspi3.Init.DataSize = SPI_DATASIZE_16BIT;
// ...
if (HAL_SPI_Init(&hspi3) != HAL_OK) {
Error_Handler();
}
}
void ST7789V_Init() {
// Toggle reset, wake display etc.
// Set drawing area from (0, 0) to (319, 239)
MX_SPI3_Init_16();
}
The solution is not super elegant, but it works and I don't need to waste ~160 ms just for swapping 320*240*2 bytes for every frame.
