How to improve the speed of writing data to SD card?

Susie

I hope the SD card be capable of storing up to 100 records,，but it only stores up to 46 records currently.

The input terminal data get into PROPELLER up to 500 records.

The SD card its specification which I use is 30MB/second.

The attachment is my code and the CSV file.

code and csv file.rar

Mike Green

You're probably running into trouble by starting up FSRW from one cog and then accessing it from another cog. Also, when you open a file for writing, you have to close the file or some of the data may be discarded.

I don't really understand why you are splitting up the functionality into two cogs. How about describing what you're trying to accomplish?

FSRW normally is able to use the entire SD card and files can be several GB in size. You won't see write speeds anywhere near 30MB/second. That specification is based on ideal conditions and uses a technique for reading and writing that's not available for use with the Propeller.

g3cwi

Susie

You may get more responses if you attach files in the standard format used by the Propellor Tool. This has an "archive" option on the file menu that wraps up everything neatly into a zip file.

Rar files are not normally used here so less people will be able to read them.

Regards

Richard

Susie

Thanks for your reply.I split up functionality into two cogs because I hope the rate of storing data could be increased up to

100 records.
I am trying to increase the data storing rate,I need to store each input signal which are from another chip that get into propeller at 100 signal inputs per-second.
In other words,I need to store "100 inputs data" from another chip in "one" second.But now I just save only "46 inputs data" in a second and another problem is that there are some signals missed in those "46 inputs. data".
How could I store the "100 inputs data" completely in a second?

Mike Green

How much data (bytes) in one measurement? Remember that SD card I/O is in blocks of 512 bytes. There are uncontrollable delays in writing to an SD card that can be as much as a sizable fraction of a second as the SD card's internal controller moves blocks around to minimize wear. You probably need to have enough buffering for about one second of data. You can increase the size of the serial input buffer. The standard buffer for FullDuplexSerial is only 16 bytes. There are other serial I/O drivers in the Object Exchange that have provisions for buffers as large as 256 (512?) bytes. I would suggest something like that. You should have all of the disk I/O in one cog, use .pwrite instead of .pputc and write 512 byte blocks. You may find that this is fast enough. If not, I would set up a pool of 512 byte buffers and use another cog to read from the serial I/O, format the data, and fill the 512 byte blocks as needed, queuing them up for writing to the SD card. The main cog would wait for buffers to be filled, write them to the SD card, and place the buffers back on the empty queue.

Susie

Thank you Mike.I still have a question that is the input data which is "character" format ,if I use .pwrite there may appear some bugs in my code.
Because Propeller receive the data which are "character string" format and that is why I use .pputc.
May you give more information or suggestion for me?Maybe my viewpoint about using .pputc is wrong.

Mike Green

A "character" is just a byte of information that you say represents a character. Neither Spin nor the Propeller care ... it's all bytes. .pputs is a little different in that there is a convention that a "string" can be represented as an array of bytes where the last byte contains zero and the address of the first byte is what is passed around. There are some functions like STRSIZE that use this convention and .pputs calls .pwrite after using STRSIZE to compute the length of the string.

You want to use .pwrite instead of .pputc because there's less overhead per byte and you're concerned about throughput when writing to the SD card.