1 2 Previous Next 15 Replies Latest reply on Jan 8, 2014 1:45 PM by HeLi_263931

    SDCard Component Speed



      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.

        • 1. Re: SDCard Component Speed

          You might wnat to file a case -












          “Technical Support”


          “Create a MyCase”




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




          Hello Dana,


          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.


          Best Regards,

          • 2. Re: SDCard Component Speed

             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.

            • 3. Re: SDCard Component Speed

              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.





              • 4. Re: SDCard Component Speed

                 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?










                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.





                • 5. Re: SDCard Component Speed

                  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.





                  • 6. Re: SDCard Component Speed

                    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.

                    • 7. Re: SDCard Component Speed

                       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

                      • 8. Re: SDCard Component Speed

                        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)

                        • 9. Re: SDCard Component Speed

                          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)





                          • 10. Re: SDCard Component Speed

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





                            • 11. Re: SDCard Component Speed

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

                              • 12. Re: SDCard Component Speed

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

                                • 13. Re: SDCard Component Speed

                                  "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.

                                  • 14. Re: SDCard Component Speed

                                     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.

                                    1 2 Previous Next