Hey gang, hope you are all doing well. I have a question about something I’m a bit stuck on.
I’m working with the Seed, and I’m attempting to write a driver for ST7789 displays. All appears to be working fine when sending small batches of pixel data to the screen, but when I try and send the entire framebuffer (uint16_t * 240 * 240 so about 115KB of data) it only sends about a quarter of the screens worth of pixels.
My question is: is there is a max size of data it can send via SPI? It’s not the end of the world if there is, but would be good to know what the max size I should be using is. I shoudl be able to have a second smaller buffer that is used to transmit a few lines of pixels at a time…
Thanks for your help, I’m so excited to be working with such an incredible set of devices.
Update: i’ve got it writing to the screen in 4 blocks of SPI transactions which seems ok - the only thing I notice is that the speed is pretty poor. The fact that it fails when trying to send the entire framebuffer means that DMA is of no help in terms of getting it working faster. I know these displays can handle very high speeds (60mhz+) so I wonder if the fixed 25mhz bus speed is going to let me down… I’ve set the baud scaler to 2, which I assume is the fastest available speed I can run it at.
Any info / insight from anyone would be much appreciated.
You should be able to double transfer amount per DMA transaction if you switch to 16 bit transfers. I wrote some details about this before. Note that you don’t have to use registers, there should be some equivalent functions in STM32 HAL libraries.
However, using 2 transfers vs 4 will actually not make that much difference. The problem why you get low throughput is that rendering and transfer process probably has pauses in it. To get anywhere close to maximum speed you would have to be able to send a buffer immediately after previous transfer is finished. This means that you would have to render it in advance (using 2 buffers instead of just one) and maybe have DMA priority for SPI higher than SAI, so that high audio DSP load won’t slow down display operations.