You can't go 4bit, these display allow 12-bit as lowest, that would be even slower as you have a weird pixel arragement (a pixel is 1.5bytes) needing a lot of cpu power and limiting a lot the dma capabilities.
Anyways, the problem is the spi bus itself, a parallel LCD would do the same transfer at least 16x faster, if not even more when using the memory controller peripheral (no spi clock limitations).
Thus, it's impossible to wipe the screen and redraw it fast enough, it will always cause a small flickering.
Don't expect this ever on cfw, I was only being curious, drawing some stuff!
Some numbers so you can see clearly the limitations:
Oled 128x64:
- Frame buffer size 1024bytes
- Can be stored in the ram, and quickly transferred in a single shot.
- Theorical speed with 18MHz SPI: 2197fps
LCD 160x128:
- Frame buffer size 40960bytes
- Needs a lot of RAM, most mcus won't be able to store it, requiring modifying the LCD memory, slow and causes artifacts.
- Theorical speed with 18MHz SPI: 55fps
Of course, theorical speed is nowhere from real. You must process the fonts, address the pixels... there's a lot of overhead.
Clearing the LCD is also a frame, so, you can transfer in the best case 27 "real" fps, the screen will show the black frame due the slowness and look terrible.
That's why I laught at these Arduino projects where you see the screen drawing taking 3 seconds! It's so crappy
There're some tricks, but doesn't worth the time with spi and crappy LCDs.
Yelkvi, didn't arrive yet. No news since 26-february.