3 Replies Latest reply on Aug 7, 2017 7:15 AM by epr_1639216

    FATFS Sdcard write speed

      Hi all,


      I'm currently working on a project that requires to datalog some data (64 bytes per packet) at 1kHz to a SDcard. For that, I have used on the FATFS code that Hackingday has kindly shared (https://github.com/hackingchips/PSoC_FatFs) and did some benchmarking. My chip is CYBLE-222014-00 running at 48 MHz and SPI master at 8 MHz. The sdcard I am using is 32gb and capable of 10+ Mbytes/s write and read speed when tested in my PC.


      In my test code, I wrote 4096 bytes of data (multi-block of 512 bytes) using f_write. However, my write speed is ~236kbytes/s. This is pretty far off from the benchmark illustrated http://elm-chan.org/fsw/ff/res/rwtest1.png.  I have even updated the FATFS to the latest version but to no better effect. I wonder if I'm missing anything?


      Appreciate any help.


      P.S. I have shared my test code. :)

        • 1. Re: FATFS Sdcard write speed

          There is generally a difference between randome read/write speeds and continuous read/write speeds; Perhaps this is causing the difference?


          Also, looking at your main code, it seems like you are checking the getUpTime() before running some operations, perhaps this is causing a delay in data being written/sent?


          It looks like you are using a 64int to hold your time difference, keep in mind that if this rollsover, it will screw up your calculations and give invalid values.


          Maybe change your test to run for a fixed amount of time, and see how much data/number of writes you can run in that period, and extrapolate it out to data/second?

          • 2. Re: FATFS Sdcard write speed

            Hi e.pratt_1639216,


            Thanks for the suggestion. the getUpTime() is just reading off my global variable counter value in timer.c. You see find it in the interrupt handler for the 1ms timer. It's volatile / non-optimized, so the value should be accurate enough for my calculation. 
            Yeah, I was using a uint64 for timekeeping and I typecasted all of my values to ensure it's uint64. So I shouldn't get rollover issue, unless I'm mistaken. I think, at most, my result is slightly off since I did a division with 2 integers, but should still be within reasonable accuracy.


            I also took your advise and did a data transfer for 20s. This was my result: 4628480 bytes written with 231 kB/sec. Not much different. Sigh. What else am I missing?

            • 3. Re: FATFS Sdcard write speed

              Huh, yeah; I guess I should have found that function in the timer pretty easily >.<


              Yeah, you're probably fine on the rollover issue, but it was a thought :)


              Hmmm, if you're getting the same results with a sequential data transfer, then it shouldn't be the access time varying based on the chip silicon then. One thing of note is that when I open your project in PSoC creator 4.1 it lists the chipset CYBLE-222014-01 as being trimmed from the cypress catalog. This could mean that either they had alot of issues with the chipset, or ran out of the parts for it.


              Some thoughts: under sdcard.c the function wait_ready() is waiting with 100 us delay between polling, potentially decreasing this polling time (while keeping the timeout time the same) might increase your data rates by reducing the latency on the sd card ready signaling.


              Same with rcvr_datablock(),xmit_datablock(),aend_cmd(), etc. If there are delays in the software, then it could be a delay caused by the software waiting for signaling when it doesn't need to. Basically, the less delay operations or the smaller the delay operations you can have, the more responsive/faster the SD card functions should go (assuming the delays aren't necessary or can be replaced with hardware signaling/polling)


              There are about 20~ delay operations for the SD card, mostly for a single millisecond delay; I would try removing those and seeing if that works. They seem to be used for handling multiple devices on the same hardware bus?


              Plus, based on your comments of "why?" I would guess that they serve no visible purpose.