SD Card Speed

Using the Propeller development card that includes a microSD memory chip...how fast can the propeller write and read data from the device?

Sincerely,

Discovery

Comments

  • 7 Comments sorted by Date Added Votes
  • My application calls for writing one Mega words of data into the SD memory on the Propeller Activity Board at varying rates but the data must be read out at very high speed. I am looking for a read data rate around 500 kHz.

    I was wondering if anyone has experience using one Cog of the propeller to read out data as fast as it can. The data also must be uniformly spaced in time, i.e. no data bursts.

    My application is written in C.

    Sincerely,

    Discovery
  • Discovery wrote: »
    My application calls for writing one Mega words of data into the SD memory on the Propeller Activity Board at varying rates but the data must be read out at very high speed. I am looking for a read data rate around 500 kHz.

    I was wondering if anyone has experience using one Cog of the propeller to read out data as fast as it can. The data also must be uniformly spaced in time, i.e. no data bursts.

    My application is written in C.

    Sincerely,

    Discovery

    I can throw some numbers at you, but it will be apples to oranges at the moment. Are you writing raw blocks to the SD card (without regard for a filesystem), or do you need your SD card to be formatted as FAT 16/32 so that a computer or other system can read the data at a later point? The benchmark results are drastically different depending on your answer.

    Also, thank you for providing your application's language. The SD card and FAT routines that are shipped with PropGCC and the Simple Libraries are not very fast. No matter your answer to my above question, you will probably want to either use PropWare (if it's fast enough for you), convert an existing Spin object with Spin2cpp, or roll your own, highly-optimized version.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
  • Peter JakackiPeter Jakacki Posts: 6,087
    edited February 5 Vote Up0Vote Down
    Discovery wrote: »
    My application calls for writing one Mega words of data into the SD memory on the Propeller Activity Board at varying rates but the data must be read out at very high speed. I am looking for a read data rate around 500 kHz.

    I was wondering if anyone has experience using one Cog of the propeller to read out data as fast as it can. The data also must be uniformly spaced in time, i.e. no data bursts.

    Maximum clock speed for an SD card in SPI mode is 25MHz although the most that the Prop can do is 20MHz @80MHz clock. However SD cards by their very nature do not output a continuous regular stream of data, the Flash memory is managed by a controller chip on the card which maps and wear levels sectors etc. So at the SPI layer commands are issued to the SD card controller (SD we'll call it) and then waits for however long that SD needs after which the SD sends back a token to say it's ready. Then and only then do you get to read the sector. If the file is non-fragmented then the sectors or blocks can be addressed sequentially without having to read the FAT table.

    If you really want sustained high speed reads I suggest that you try dual QSPI Flash but then you might only have 256M bytes or so even with high density chips.

    I know that when I play back WAV audio files from an SD that you can't have any breaks so after one buffer is filled and being played back another buffer is being filled so that they alternate functions. This is fine as long as the playback or read out rate is slower than the average SD read data rate. So if you are able to ensure contiguous blocks in a FAT32 file which is normally the case anyway, you could write a highly optimized driver over a couple of cogs to do what you want and maybe run the Prop at 100MHz and maybe it might work.....maybe.

  • Very good. It then appears that getting data clocked out at 500 kHz should be possible. I have no idea what would be the right format on the SD. I just have raw numbers that will be stored in sequence at a rate depending upon the length of time it takes to complete the calculations. For cutting thick steel, the cutting speed will be about 15 inches per minute as opposed to 22 gauge steel at 822 inches per minute so I expect to change the clock rate to the SD for cutting materials.

    I will be out of contact with the Forum for February and a few days into March. Then I will get back and try to work with you on writing the spin code. I have never written spin programs only C.

    Sincerely,

    Discovery
  • Spin won't cut it, excuse the pun, but it's too slow for that. I have my own way of doing it but I'm sure the C guys will help you out.
  • Discovery wrote: »
    Very good. It then appears that getting data clocked out at 500 kHz should be possible. I have no idea what would be the right format on the SD. I just have raw numbers that will be stored in sequence at a rate depending upon the length of time it takes to complete the calculations. For cutting thick steel, the cutting speed will be about 15 inches per minute as opposed to 22 gauge steel at 822 inches per minute so I expect to change the clock rate to the SD for cutting materials.

    I will be out of contact with the Forum for February and a few days into March. Then I will get back and try to work with you on writing the spin code. I have never written spin programs only C.

    Sincerely,

    Discovery

    Sorry - I guess my real question got a bit lost in there. Do you need the SD card to be read by a computer or other system after the Propeller writes to it?
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
  • Discovery wrote: »
    Very good. It then appears that getting data clocked out at 500 kHz should be possible. I have no idea what would be the right format on the SD. I just have raw numbers that will be stored in sequence at a rate depending upon the length of time it takes to complete the calculations. For cutting thick steel, the cutting speed will be about 15 inches per minute as opposed to 22 gauge steel at 822 inches per minute so I expect to change the clock rate to the SD for cutting materials.

    I will be out of contact with the Forum for February and a few days into March. Then I will get back and try to work with you on writing the spin code. I have never written spin programs only C.

    Sincerely,

    Discovery

    You need 500KHz for a machine tool? Doesn't sound right.

    PropBASIC ROCKS!
Sign In or Register to comment.