SDCard Component Speed

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

  Hi,

   

I've used this component for a project in which I'm working on but I need to be able to write to the SD Card about 40 bytes in less than 2.5 ms. 

   

Using a 512MB class 2 card and what it seems to be 48Mhz of SPI clock (I Commented the part in the library where it changes the speed programatically and I've tested that when I decrease the speed of the SPI Clock the transmission speed decreases). when I look at the clock speed using an oversampling of 6 in the SPI I get 8Mhz  and then if I change the oversampling to 3 (The minimun it lets me use) I still get 8Mhz.

   

Anyway, I can "write" the 40 bytes in about 0.31ms but of course this just saves them in a buffer. Adn then when I fill the 512 bytes, the library physically writes the SD Card and it takes between 5.5 and 6.5 ms to do that and of couser that is more than the 2.5ms that I'm allowed to use so I loos samples.

   

So is there anyway to increase the writting speed? I guess that making a buffer would work for the SD but since I have to send the same that over bluetooth and it is shown in real time in the computer, making a buffer  would mean a non fluid reception or a delay in the display of the data so I would like to avoid that.

   

Also, would changing the SD card for a better class one would have any improvement in the speed?

   

Since this info my be useful for someone else, I will attach an Image of the delays. In channel 4 I toggle a pin everytime I write 40bytes and in Channel 5 you can see the SPI clock. In the top right side of the image you have the delays of writting the 512byte to the SD and the time it takes to the PSoC 4 @ 48Mhz to write the 40bytes to the SD library's buffer.

   

Thank you in advance.

0 Likes
15 Replies
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

You might wnat to file a case -

   

 

   

    

   

         

   

www.cypress.com

   

“Support”

   

“Technical Support”

   

“Create a MyCase”

   

 

   

I got the following from Cypress, not unrelated to your question -

   

 

   

Hello Dana,

Greetings!

I went through the documentation  of the SD card project, SDCard_V1_0.pdf present in the element14 website. Please click the below link to find the documentation: http://www.element14.com/community/servlet/JiveServlet/download/82632-115835/SDCard_V1_0.pdf

The paragraph 3 of "Functional Description" section present in page 4 of the SDCard_V1_0.pdf states that "During initialization, the SD_SCLK is set to use the 32kHz, then back to the userselected clock afterward. This is per the MMC/SD specification that initialization must be with a clock of less than 400kHz. Due to limitations of the SDCard User Module and the PSoC device itself, the full speed transfer rate of 20MHz for an MMC card or 25MHz for an SD card is not possible."

Let me know if this address your query and if you have need clarifications to be made.

Thanks!

Best Regards,
Goverdhan
 

0 Likes
Anonymous
Not applicable

 Hello Dana,

   

 

   

Thank you for your response. I'm sorry, I'm a bit new to cypress ecosystem. Why would I want to file a case? From what I've read is a limitation in the PSoC 4 Hardware so there is no way at least using SPI to get a better speed, right?

   

Thank you.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Using a buffer can speed up things a bit (or byte ) . Considering that the data-flow does not last for infinity (even the SD-card would get busted) you could try to use a circular buffer to store incoming data to and retrieve the SD-data from at the same time. 

   

 

   

So: How long are you collecting Data and what is the amount of data produced during one measurement cycle, how many cycles and at which frequency are you expecting.

   

 

   

Bob 

0 Likes
Anonymous
Not applicable

 Hello Bob,

   

Thank you for your advice. That is what of thought of doing since seems my only option at this moment but it introduces the lag as I said in my first post. Also, I don't know if I will have enough ram in the MCU since I've found that when I write continiously I don't always get the same writting times. Periodically I get writting times of about 17 ms which increase even more my problem. And not only that but also after several periods of 17ms I get a period of about 55ms. 

   

I will have to find an explanation to those.

   

 

   

Anyway, I read the data from an ADC that samples at 250Hz so every 4ms I get an interruption, read the data using SPI, then send a packet with the data through the UART and then I have to write the data to the SD Card before then next interrupt of the ADC occurs which gives me a pretty tight schedule. 

   

 

   

The problem with the circular buffer is that introduces delay in the data display which should be in real time in the computer (Data sent throught UART). Also this should be running for at least 24 hours straight.

   

 

   

Any other ideas?

   

 

   

Thanks!

   

Alex

   

 

   

Using a buffer can speed up things a bit (or byte ) . Considering that the data-flow does not last for infinity (even the SD-card would get busted) you could try to use a circular buffer to store incoming data to and retrieve the SD-data from at the same time. 

   

 

   

So: How long are you collecting Data and what is the amount of data produced during one measurement cycle, how many cycles and at which frequency are you expecting.

   

 

   

Bob 

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Writing to SD can be a complex process when looking into the inside of the chip: a controller is accepting the data and of course is internally optimizing write accesses to re-write complete rows instead of sinle bytes. This would explain the different times needed to perform the actions.

   

 

   

Assuming an 8-bit resolution of the ADC you have a datarate of 250Bytes/s which you can handle with 2400Baud via the UART. The same rules for the SPI-interface.

   

So the bottleneck seems to be on the SD-side. I would make a simple test:

   

Write a program that contineously writes data to the SD with maximum speed and take an analizer-picture again. Remember that you have got 4ms at 250Hz not 2.5. You may even use a pin to toggle after 512 bytes of data sent to measure the time needed exactly.

   

 

   

Bob

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

When you get only 250 bytes per second, why not collect 256 bytes (or maybe even 512) and then write them as one block to the SD card? That way you only have a single write call, maybe 100ms, every second. Having this process interrupted by the ADC ISR should not be a problem (you just need two buffers - one to collect and one to flush to the card). Just control the slave select line manually, and not by the SPI component.

0 Likes
Anonymous
Not applicable

 Hi Bob,

   

I understand the part of the controller side of the SD. But it seems that the bytes are sent to the SD by SPI in chuncks of 512Bytes which is understandable. The library doesn't send byte by byte. That's why I have the 6ms delay every 512 bytes "written" to the memory.

   

Also, from the ADC I don't get 1byte but 30 bytes because is a digital device and I read the data through SPI. I know I have 4ms but 1.5ms are already used to get the data from the ADC and send it over the UART. 

   

The image I attached to the first post is writting non stop to the SD.

   

Hi hli, thank you for your response. I would do that but I don't think that will work for me, since the ISR is from a pin that tells me data is ready from the ADC. So when the pin toggles the ISR activates a flag that then I check in the main loop and gather the data so if I'm writting the SD Card and I get the ISR call I won't be reading the data until the SD is finished writting which will make me miss many samples. 

   

Of course I could just read the data in the ISR which is not always a good idea but then that would men that I would have to send the data over the uart in chunck of 512 bytes too and all of that can be a problem at the end. I don't know I might just try to see what hapens.

   

 

   

Thank you both for your collaboration

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Your ADC sends you over 30 bytes just for a single conversion result? Strange. Which one is it?

   

And using the buffer should cause you not more problems than you already have: when you are right and the SD card component already sends 512 bytes to the SD card, it won't get slower by using a buffer. But by doing so you will be able to get the throughput you need.

   

Also, there is no reason not to send data via UART directly, while still using the buffer for the SD card.

   

Last but not least: yes, you should read the ADC in the ISR in your case. Since writing to the SD card is the time-consuming process, it needs to get interrupted. And when you already know that reading from the ADC takes 1.5ms every 4ms, you are fine. (and I think that 1.5ms to read 30 bytes is quite long, this should be much faster)

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

You are mixing up times in your system you have to wait for some event and times you are using CPU mips to perform some action. With the help of interrupt driving events you are able to perform the actions during a phase you have to wait for something. Stick to my suggestion to write a test-program. When the results show that you really can send the bytes to SPI at the desired rate (and I think that will work) you will be able to fulfill the required timings for your project.

   

HL is right: you should tell us some more about the data-flow.

   

Another helpful way is to post the complete project here, so that we can check everything. To do so: use Creator -> File -> Create Workspace Bundle (minimal) and the upload the resulting .zip-file here (DO NOT USE chrome, that will not work! Use ie or firefox)

   

 

   

Bob

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Sorry, Hli of course. Forum software prevents me from re-reading the posts while answering. Another thing to bite my nails on.

   

 

   

Bob

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

@bob: try Ctrl-Click the 'post reply' button. This opens the reply editor in a new tab (tested in FF, Chrome and IE11).

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

No need to nail-biting, this will end up ugly 🙂

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

"Why would I want to file a case?"

   

 

   

Just thinking the author of the SDCARD module may have some insights

   

the rest of us do not.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 Hi to all,

   

I'm already working in the test program using the buffers to see if I'm able to achieve what I want. At first, I thought of doing it with buffers which is the most common and usually the most sensible thing to do but since at first I didn't have the SD requirement and it is an "streaming-like" application because it doesn't matter if I loose a sample once in a while, I thought of doing it without the buffer so the program would be easier to understand and easier to debug since you always know where the cpu should be each moment.

   

Anyway, the ADC is actually many ADC's that work in parallel and they sample at 250Hz. I could get data faster but with the modified prototype that I'm working on the datarate I'm using works perfectly and if I don't need to go faster why would I? Now, I need to but even if I can read the data in 100uS, I would still be short in time with the SD without using buffer.

   

I'm sorry Bob but I can upload the project since is a work related project. Anyway, I will test the program using the buffers and reading the ADC data right from the interruption and see what comes out.

   

I will be posting results once I have them but I don't know when will that be, since I will be receiving PCBs from another project that has more priority than this one.

   

Thank you all.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

It should not be a problem when the SPI transfer to the SD card is stopped momentarily. As long as the select signal is active, the card should write for the transfer to continue. So you can do the SD card write in the main loop (from the buffer), and handle the ADCs in an ISR.

   

Btw: when you have 30 ADC each delivering data at 250 Hz, this amounts to 30*250=7.5kbytes/second which means you need to write 15 times per second. This is a little bit different to what we were talking about before...

0 Likes