SST26VF064B Library… help?

So, image artifacts weren’t related only to the “ESC” byte detection on the script and sketch but also with some data loss on the serial connection.

Further investigation on the way: http://www.stm32duino.com/viewtopic.php … 985#p18985

After solving the issue with Seria.readBytes() that is missing data randomly (still going to try with Serial.read(data,len) ) by using Serial.read() instead and reading one byte at a time, the first image has arrived!!

Image

Performance is still not perfect (245ms to load the full image vs 34ms for a fillscreen) but I still have to add DMA to SerialFlash and try again. Still the minimum theoretical time would be 68ms (34ms loading from flash and 34ms writing to display) around 15fps. Then maybe 30fps with overclok. Should look ok

I also tried overclocking but I got “File not found” error with more than 8Mhz overclock. This shouldn’t happen unless for some reason the read command used is the “normal” read (cmd= 0x03 -> 40Mhz max SPI) which I’m not using (fast read cmd= 0x0B -> 104Mhz max SPI). Have to investigate…

rexnanet wrote: Still the minimum theoretical time would be 68ms (34ms loading from flash and 34ms writing to display) around 15fps.

There’s 2 approaches possible:
1 – use 2 SPI buses: SPI1 for the display and SPI2 for the flash.
This would allow to use direct DMA from one to another. But SPI2 runs at half the speed of SPI1 so this would slow down things a bit (18Mhz max).

2- use SPI1 for both display and flash.
This allows for faster SPI (36Mhz) but needs intermediate buffering and would take 2x as long.
Ultimately this would lead to half the speed being equal performance to (1) but I plan to try a different approach that takes advantage from the fast clock.

The 3rd approach
I’m planing to, after setting the display and point to the start of the file on the flash, redirect the SO of the Flash to the SI of the display and then issue a transfer to provide the clock signal for the transaction.
This will allow to transfer the image directly to the display at maximum speed (ultimately @64Mhz with overclock ) allowing almost 60fps speeds !!!

The only downside is that I have to add a multiplexer to the circuit.

You could see if you can get hold of a cheap GD32F103C. I added a setting for 120Mhz main clock, which would give 60Mhz on SPI (though I don’t know if the display would cope with this, I have had issues with the GD32 on SPI, which I think are related to it running to fast for a lot of devices)

Also GD32 runs the program from shadow RAM, not Flash, so code runs generally faster as well (I think the STM32 is running with 2 wait states between Flash read’s but the GD32 has none), In practice because of CPU core caching and pipelining and predictive branching etc, this doesn’t mean the GD32 runs 3 times as fast, but it is noticably faster

(I’m sure I posted the Dhrystone tests, which give an indication of the difference in speed)

But, GD32 boards seem to be difficult to get hold of, I can’t see any GD32 boards on AliExpress or eBay at all.

Yes, I’ve tried to get a hold of a board but it’s not easy… So I gave up.

With overclock I can get the STM32 to run at 128Mhz and SPI at 64Mhz
I’ve posted some videos on that :
https://www.youtube.com/watch?v=Dui-L7S7nS0
https://www.youtube.com/watch?v=VOxv87-hZt8

The display (ILI9341) handles that well. Only at 80Mhz I couldn’t get it to work (using ESP8266) but I’m still going to try with shorter wires. I was testing with 20cm dupont wires, I have some 10cm now.

My next chip test will be the ESP32… it has lots of everything RAM, speed, cores, flash, pins (…) ,WiFi, BT LE… and less of one thing: the price
It will smash everything else… lol

But for now continue with image loading

New results:

-Added DMA support on flash read. Now full screen image takes 90ms “more nicer”!

– Somehow Portrait and Landscape modes have different byte order… I was testing in Landscape and when I loaded a Portrait image the colors were all messed up. That’s not nice!!! Had to make some changes to detect the positioning and write to the display accordingly…

I’ve also made an example code that goes through all the memory and displays all the images available Will show some cool stuff later on

Didn’t make any video on this…but soon will be available

If my calculations are correct, 90 ms gives you 11.11 fps, which is pretty impressive.

And now the videos

Displaying a set of demo images:
https://www.youtube.com/watch?v=F2ZsxGfDOyc

And a loop I made from a demo video:
https://www.youtube.com/watch?v=bMKZ26XmYWQ

I haven’t speed up thing yet. Still have to test overclock again…
I’m getting around 88ms per image, around 11fps.