EmbDev.net

Forum: ARM programming with GCC/GNU tools Speed SD card.


Author: Sevc Dominik (sevc)
Posted on:

Rate this post
0 useful
not useful
Hi all.
I'm interesting about real speed of dta transfer from SD card.
Have any practical experience to read data from SD card (Fat32 or
else,2GB max).
How many KB/s is real speed if I want read BMP picture from directory in
SD card???The board use AT91sam or LPC2148 ... .
any sugestion

regards

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
Sevc Dominik wrote:
> Hi all.
> I'm interesting about real speed of dta transfer from SD card.
> Have any practical experience to read data from SD card (Fat32 or
> else,2GB max).
> How many KB/s is real speed if I want read BMP picture from directory in
> SD card???The board use AT91sam or LPC2148 ... .
> any sugestion
>
> regards
It may depend on whether you are using SPI or SDIO to access the card.
SDIO uses a four bit parallel path rather than serial data. I only have
experience of using SPI using the commercial Segger emFile library (I
have some esperience with EFSL but have never done any performance
tests).

In my experience, the most critical part is the card itself. When I
first used emFile I got a disappointing write speed of 32kb/s, after a
lot of searching for the cause, I tried (at Segger's suggestion) a
different card (I actually used MMC cards, but they are compatible), and
achieved around 350Kb/s. Reading is typically faster.

To get good write performance it is essential to ensure that you write
'sector' sized blocks (512 bytes), writing one byte at a time in
separate I/O operations will severely impede performance because of the
manner in which flash memory works and the fixed overheads of the card
communications protocol. Preferably write all your data in one go (or as
much as possible) and make it a 512byte multiple. If the file system
supports write caching, (or you implement it yourself), it may handle
the necessary collation of small writes for you.

The speed of the SPI bus is not particularly significant in my
experience, the difference between 8 and 16 MHz for example is that at
16 there are more 'busy polling' transactions on the bus. This may of
course vary between cards, it is possible that for a high performance
card, the bus may become the bottle-neck. Also if your processor cannot
sustain a sufficiently high SPI clock, or service the SPI interrupts
quickly enough, you may find that is the limiting factor (I was using a
200MHz ARM9 part, so cannot speak for the AT91sam or LPC2148)

One thing I would suggest before suspecting poor performance of your
file system is to us a PC based card performance test to compare cards
and to find the theoretical performance.

Segger have published performance tests for their FS at
http://www.segger.com/emfile_performance.html, including AT91SAM
results. Note that the results for "MMC using SPI" are the ones
applicable in this case since emFile supports a number of media types. I
never got results close to those shown here (1000Kbps), but when pushed
Segger sent me more complete test figures that showed speeds ranging
from 32kbps to 1000kbps entirely dependent on the card manufacturer and
part. In the published tests the write results for the LH79520 with an
SPI clock of 12MHz were nearly half that of the AT91SAM7S with an SPI
clock of 24MHz, indicating that in this case perhaps the SPI speed was
critical. On the 'high performance' MMC card I used, any clock at or
above 8MHz yielded no performance gain.

Note also that read performance is usually at least as fast or faster
than write. In Segger's results the slower SPI clocked LH79520 read 160%
faster than it wrote, whereas on the AT91SAM7S read and write have the
same performance, and the read is slower than for the LH79520; I am not
entirely sure why that should be the case, but there it is.

So ultimately your mileage may vary, but up to 1Mbs write at least is
possible. To track down any bottle necks, try varying the SPI clock to
test for sensitivity, and test the card on a PC. This is not entirely
indicative since a PC will use SDIO rather than SPI, but it will allow
you to compare cards.



Clifford

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
Clifford Slocombe wrote:
> Segger have published performance tests for their FS at
> http://www.segger.com/emfile_performance.html, including AT91SAM
> results.

For some reason the forum included the comma in the URL, try this:

http://www.segger.com/emfile_performance.html

Author: Sevc Dominik (sevc)
Posted on:

Rate this post
0 useful
not useful
Clifford Slocombe wrote:
> Clifford Slocombe wrote:
>> Segger have published performance tests for their FS at
>> http://www.segger.com/emfile_performance.html, including AT91SAM
>> results.
>
> For some reason the forum included the comma in the URL, try this:
>
> http://www.segger.com/emfile_performance.html

HI.
I'm interesting only read speed. Data will be writen on PC.
A free code for FAT32???

regards

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
Sevc Dominik wrote:
> A free code for FAT32???

Yes of course; EFSL http://efsl.be/ That is what I assumed you were
using already.

EFSL is used in one of Martin's AT91 examples:
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm...

NXP have an app note for an MP3 player using an LPC2148 with EFSL:
http://www.nxp.com/acrobat/applicationnotes/AN10583_1.pdf

Clifford

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.