|
Post by MangyDog on Jul 14, 2021 5:18:43 GMT -8
Just wondering if anyone managed to speed up asset loading with stm32f103 mcus?
Currently i cant seem to get SPI to go faster than 25000000. If I have a full memory asset it takes about 2-3seconds to load off the sd card.
I was hoping there might be a way to speed this up?
|
|
|
Post by tftlcdcyg on Jul 14, 2021 20:28:06 GMT -8
I imagine you are using the arduino environment with your F103. Which Core STM32 are you using?
The official Core for STM32 (2.0.0) in your SPI library, it doesn't have DMA options enabled, it's a shame. I remember that an alternative core, that of danieleff, if it has DMA and an improved SdFat version (https://github.com/danieleff/STM32GENERIC), maybe you could cut the loading time and account
I suggest you use the SdFat library in its most recent version, instead of the variants based on the SD library.
A couple of years ago we suggested to James that GD23X be able to work with SdFat, that's a good way to go for boards with better memory performance than the arduino UNO.
Regarding STM32 boards, I think there will be better results in loading times with boards like the F407, 429 or F767, which go well with the alternative core of danieleff
|
|
|
Post by MangyDog on Jul 15, 2021 4:58:59 GMT -8
Using f103 on rogers core. Hardwares locked down now, so no chance of any changes there.
Swapping to daniels core might be possible, if GD lib is compatible with it.
But also needs to have freeRTOS enabled...
|
|
mattp
Full Member
Posts: 37
|
Post by mattp on Jul 16, 2021 4:25:25 GMT -8
Because I'm using an FPGA I have a separate SD SPI interface running at 50mhz using my custom version of FATFS. I have the Dazzler SPI interface running as fast as it can. It loads superfast using that setup. I am considering amending the SD vhdl to use all 4 data lines into the SD Card but there is not much point as it is constrained by the speed of the GD copy command. hackaday.io/project/180536-merlin/log/195412-basic-bitmaps-in-basic
|
|
|
Post by jamesbowman on Jul 16, 2021 11:17:10 GMT -8
The bottleneck is not always SPI speed. The asset converter output is an EVE command stream to write an image into SRAM. It uses cmd_inflate() to do this, followed by compressed data. This is space-efficient. However the EVE itself is doing the inflate, and its maximum speed is 200-300 KB per second. So this matches 2-3 seconds for a full 1M load. Above a certain SPI speed (~3 Mbit/s, but it varies on the compression ratio) cmd_write() is faster than cmd_inflate(). I have opened an issue on gd2-asset to add a switch to use cmd_write(): github.com/jamesbowman/gd2-asset/issues/17
|
|