uh, ok, well just reading your post I have no idea wtf you are talking about.
What chip? What library are you using, there is more than 1 sd lib out there.
Most likely to get the fastest speed would be to just dump the files on there in binary at known offsets. Forget about using a filesystem.
That would mean you need a pc tool to manage and move the files on and off the sd card for you.
Also if your sd card is using resistors as a voltage divider for the spi bus, dump that and get a hex buffer as a level changer (5v-3.3v). But you see, you gave no references, so we don’t have any idea what you are using.
I’m using the built in SD library - It might not be the fastest there is.
FAT16 is being used.
ET MINI SD Card reader is being used and is correctly wired up. No problems in reading.
Files are raw binary data.
I just figured I might be able to pack all data together and open the large file once, simply offsetting the read. I do want to keep the filesystem on the card for ease of use. The way my application is built only requires the same static SD card to be read as fast as possible. Initial opening time is of no concern, as long as the reading inside the loop is as fast as possible etc.
I figure it would also be possible to log the entry points of each file and store them in a lookup table by opening them all briefly during boot. Each read during the loop would simply check the lookup table.
Also - I read that the SPI connection is up to 10x slower than the native SD card communication protocol, which is licensed, I believe.
Thanks, your response gave me a couple of pointers to go for!
We implemented something along these lines for our lightwall at our local hackerspace. We have a full write up here: https://www.qccolab.com/LightWall There are links in there to our code, it is streamlined and rather custom, but we are able to get 40 fps reading from an SD card. It could give you a good code base to work from.
I have used 4D systems displays in the past that come with an onboard processor as well as an SD card. They explain the same thing that the licensed protocol is MUCH faster than the free one and as a result the best video speed on their smaller displays is about 12-15FPS but their is also no flicker and the resolution is great. As long as the data is stored in raw format and you are simply calling pointers, you are likely already at the best speed you are going to get reading the data.
So, can you use a page buffer to store the next image and “flip” the page between each image? Is it possible that the flicker is caused by something else? Obviously the longer it takes to redraw the screen the more apt the eye will notice but is it the read or is it other code issues? I only ask because preloading the next image won’t really do you much good if the problem is the refresh speed. What speed are you running the Arduino at? 8Mhz, 16Mhz? The ATMega 328 can run at 20Mhz. Have you considered trying it this way? that extra 4Mhz may make the difference.
In your original message you say you are using an LED display. I assume you mean LCD? mkruse’s example above is doing some cool stuff with LED’s but not LCD’s.
I’m building a pinball machine and it is using a LED (Light Emitting Diode) display.
Various shades are simulated by quickly turning each “pixel” on and off and the longer between the states, the darker the color. The problem is that in order to keep a flickerfree image it must be at least 70Hz and the framerate must be constant, or close to constant.
If I put each SD load/open inside a 12 ms time frame the image is constant and nice, but the screen refresh is slow so the display is flickering.
If I put each SD load/open inside a 6 ms time frame the image is flickering during the initial 11 ms open time, and steady for the rest of the frames (since they fit inside the 6 ms time slot). This way I get 80 Hz refresh (incl. display drawing).
The problem is that the SD card library seem to be reading a 512 KB chunk into cache when opened. I need it to quickly return etc before doing any reading in order to keep it under 6 ms. I have not yet succeeded with this. I managed to load one image by supplying the index for that file, but it must be a lucky shot since none of the other files’ indexes work.
To be honest, this is really only a problem when loading several different animations rapidly and might not even be visible during a game, I don’t believe anyone will actually notice the slight 6 ms image brightness decrease when the animation starts since the screen they were looking at is replaced by the animation anyway. But it’s annoying to have that extra was 6 ms that I could use for other stuff, it also prevents me from having a constant refresh rate. (well, sort of).
Is it possible to calculate the index in raw bytes somehow, so that I may seekSet to that position and start reading from there etc? Am I making any sense?
