How to swap little-endian to big-endian in TouchGFX?

You can change order of bits in SPI, using the SPI_CR1.LSBFIRST bit, and MSB-first is the default setting.

Don't you by chance use SPI bytewise, rather than half-word-wise? That, combined with MSB-first, would indeed produce strange results, if you use RGB565 (i.e. the 16-bit format).

JW

Can you please let us know how did this solution work?

JW

Hi,

Unfortunately, the change SPI transfer wise doesn't solve my issue.

I use HAL_SPI_Transmit_DMA. And, I modified DMA parameter several pattern and modified SPI bit wise. However, I couldn't solve issue.

I made the software converter before transferring DMA.

The code is here;

static void ConvHL(uint8_t *s, int32_t l)

{

uint8_t v;

while (l > 0) {

v = *(s+1);

*(s+1) = *s;

*s = v;

s += 2;

l -= 2;

}

}

ConvHL(s, (int32_t)w*h*2);

HAL_SPI_Transmit_DMA(&hspi1, (uint8_t*)s, w * h * 2);

Also, I updated my GitHub.

Best regards,

Kotetsu

Hi.

I've been trying to solve the same problem for a while. But I didn't succeed. The ConHL function in the ILI9341 library seems not to work. Also, as stated in the ILI9341 datasheet, the parameters at address 0xF6 have endian settings. Although I changed these parameters, I could not get any results.I am using 2.4 inch spi tft with STM32H750. The color format is rgb565.

I look forward to your help. Thank you.

ConvHL would work, but it would modify your frame buffer, and you have to convert it back afterwards, which is time consuming and inconvenient.

You should try to leave the byteswapping to the hardware.

The ByteSwap configuration on the ILI9341 display does not work in SPI mode, unfortunately, as stated in the datasheet.

And sometimes you just have to stick to a particular byte order. Say if you are using Chrom-Art (DMA2D) for instance. While just copying a rectangle just works fine, the BS (ByteSwap) bit for DMA2D (if available at all) doesn't do a great job when blending fonts (A4) onto the background (RGB565). (It probably needs an additional bit for that in the future).

Anyway, the next method may help you solve your problem, by just leaving the byte swapping to the hardware, using the next trick.

For this to happen, you can temporarily configure the SPI bus for 16-bit mode, so when you transfer your buffer, the bytes would be send swapped 2-by-2, automatically.

So let's say you function to transfer your buffer would look something like this, sending byte for byte (but the wrong order for the display):

void ILI9341_WriteData(uint8_t* buff, uint32_t buff_size)
{
 SCB_CleanDCache_by_Addr((uint32_t*)(((uint32_t)buff) & ~(uint32_t)(__SCB_DCACHE_LINE_SIZE - 1U)), buff_size + __SCB_DCACHE_LINE_SIZE); /* Mem-to-Peri */
 HAL_GPIO_WritePin(ILI9341_DC_PORT, ILI9341_DC_PIN, GPIO_PIN_SET);
#if defined SW_CS_PIN
 HAL_GPIO_WritePin(ILI9341_CS_PORT, ILI9341_CS_PIN, GPIO_PIN_RESET);
#endif
 uint16_t buff_size_max = 65536 - 4;
 // Split data in smaller almost 64k chunks, because HAL can't send 64K at once.
 while (buff_size > 0)
 {
 uint16_t chunk_size = buff_size > buff_size_max ? buff_size_max : buff_size;
 HAL_SPI_Transmit(&ILI9341_SPI_PORT, buff, chunk_size, HAL_MAX_DELAY);
 buff += chunk_size;
 buff_size -= chunk_size;
 }
#if defined SW_CS_PIN
 HAL_GPIO_WritePin(ILI9341_CS_PORT, ILI9341_CS_PIN, GPIO_PIN_SET);
#endif
}

We could make a function like this, which also sends the data, but in the right byte order for the display:

void ILI9341_WriteData16(uint8_t* buff, uint32_t buff_size)
{
 SCB_CleanDCache_by_Addr((uint32_t*)(((uint32_t)buff) & ~(uint32_t)(__SCB_DCACHE_LINE_SIZE - 1U)), buff_size + __SCB_DCACHE_LINE_SIZE); /* Mem-to-Peri */
 HAL_GPIO_WritePin(ILI9341_DC_PORT, ILI9341_DC_PIN, GPIO_PIN_SET);
#if defined SW_CS_PIN
 HAL_GPIO_WritePin(ILI9341_CS_PORT, ILI9341_CS_PIN, GPIO_PIN_RESET);
#endif
 // Set SPI to 16-bit
 ILI9341_SPI_PORT.Init.DataSize = SPI_DATASIZE_16BIT;
 HAL_SPI_Init(&ILI9341_SPI_PORT);
 // Split data in smaller, less than 64k chunks, because HAL can't send 64K at once
 buff_size /= 2;
 uint32_t buff_size_max = 65536 - 4;
 while (buff_size > 0)
 {
 uint16_t chunk_size = buff_size > buff_size_max ? buff_size_max : buff_size;
 HAL_SPI_Transmit(&ILI9341_SPI_PORT, buff, chunk_size, HAL_MAX_DELAY);
 buff += chunk_size * 2;
 buff_size -= chunk_size;
 }
#if defined SW_CS_PIN
 HAL_GPIO_WritePin(ILI9341_CS_PORT, ILI9341_CS_PIN, GPIO_PIN_SET);
#endif
 // Set SPI back to 8-bit
 ILI9341_SPI_PORT.Init.DataSize = SPI_DATASIZE_8BIT;
 HAL_SPI_Init(&ILI9341_SPI_PORT);
}

Note, ILI9341_SPI_PORT is a just definition in a header file for your display, i.e. ILI9341_conf.h, used to confgigure the display IO:

#define ILI9341_SPI_PORT hspi4

In the code above, we only modify the DataSize of the SPI bus and leave the rest the same as when initally MX_SPI4_Init was called for example.

I have tried this for you, using an ILI9341 display, connected to a Nucleo-H7A3ZI-Q development board, and it works fine this way. You now do not have to loose time swapping bytes forth and back.

I added GPIO CS control too, in case you do it by software.

And never forget to set your window for the display.

You now can use DMA2D and nicely blend images.

Hope this helps.

Photo taken using my phone...

I'm trying to connect STM32F412 with SPI LCD (ILI9341. And, I'm trying to run TouchGFX on this combination.

The white and black color is correct. However, another colors are strange. I think that the endian is swapped. Might be, TouchGFX supports only little endian.

This ILI9341 device only support big-endian at using SPI port. If I use parallel port, it can choose both little-endian and big-endian. However, the target board supports only SPI.

Custom Bottled Water