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
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
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
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
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_projects/efsl_arm/index.html NXP have an app note for an MP3 player using an LPC2148 with EFSL: http://www.nxp.com/acrobat/applicationnotes/AN10583_1.pdf Clifford
Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.