SPI performance on mono SSH1106 128x64 screen - bulk SPI transfer

Thanks @allObjects, your post gave me a clue to look at how the graphics array is allocated and it is in a flat data area, so I now use a simple memcpy at the start of my native "flip" routine to copy it to the DMA-capable transfer buffer. Profligate use of precious memory I know... but it does mean I can use the existing Graphics and the only custom part is the flip.

I now have a little Javascript app drawing and moving 16 rects and total execution time is around 35ms, ie. 28fps. Even this was interesting as I found things like rects.forEach(r => {g.drawRect(...)}), rather than a simple for loop based on rects.length added about 5ms per redraw.

Breadboard pic for interest...

1 Attachment

On most platforms you could just use the arraybuffer from graphics (it'll be allocated as a flat string of data if possible). There's just code in there to deal with the case where it can't be and has to be fragmented.

To be honest if you could write the SPI data out in one big buffer then you could change the JS driver, and with software SPI you'd still be looking at a pretty fast refresh speed. Faster than the display can handle anyway.

In the esp32 case you mentioned allocating memory in a certain way to use for Dma. Is there any downside to this, as the arraybuffer class in the esp32 case could allocate this type of continuous block, and then you would not need to the memcpy at all as the source would already be of the correct type.

Hi @Wilberforce I don't know to be honest, but I would assume it's not ok to allocate all memory blocks as DMA capable, ie. pvPortMallocCaps(size, MALLOC_CAP_DMA).