Can you please let us know the datarates that you are getting when reading/writing to the SD Card? Also, can you confirm that the SD Card supports the expected datarates? Is this behavior observed irrespective of the SD Card used?
Can you try measuring the time interval after disabling all the other code/components and just having emFile and let me know if that makes a difference?
Thanks and Regards,
Rakshith M B
I appreciate your comment!
>Can you please let us know the datarates that you are getting when reading/writing to the SD Card?
I hope reach 600 Kbyte/s.
>can you confirm that the SD Card supports the expected datarates?
And, I know it will be not reach to realize perhaps.
with this in P20 https://www.cypress.com/file/135136/download
and, by my result of benchmark(Attached excel)
But, I slightly wonder why they didn't show that performance of 24 MHz of SPI Clock in PSoC 5LP.
My first question too!
>Is this behavior observed irrespective of the SD Card used?
I think we can observe irrespective of the SD Card.
Because, we have same question by other person.
>Can you try measuring the time interval after disabling all the other code/components and just having emFile and let me know if that makes a difference?
I had already confirmed in all interrupter and component removed.
it Referenced to the previous questioner
Transfer Speed emfile.xlsx 17.0 K
Can you try sending a larger bulk of data and let me know if that makes any difference?
Regarding the SD Card compatibility, as LePo_1062026 mentioned in the previous thread, the SD Card should be able to support the data writes too.
Can you also confirm if you are getting the right data rates for the performance specification mentioned in the datasheet? Also, apologies if I have missed this information, but can you also let me know the CPU speed?
I do not have the setup and thus I am not able to recreate the results at my end. I also checked internally if there are any known issues and I could not find any. I will forward the query to our internal team to confirm the same. If it turns out to be a component issue, we will make sure to release it as a KBA so that it would help others as well.
Thanks and Regards,
Rakshith M B
1 of 1 people found this helpful
If I understood your original question you are looking to reduce the time between SPI data transfers from 4.64us to something significantly lower. Is this correct?
I believe the issue with the Segger emFile library code is that they are using an ISR to process the next queued SPI byte to read or write. If the SPI driver code can be converted to DMA transfer, it might help. Using the interrupt is a early form of multitasking. The 4.64us may be the "cost" of "task context switching".
However there are potential limitations. There might be a SD card media transfer limitations. During writes in particular, the media sectors need to be erased and then programmed. This takes time.
The SD max data rate is 12.5MBs which means that this SD type can possibly transfer at 80nsec per byte.
The SDHD max is 25Mbps which translate to 40nsec per byte.
What is your BUS_CLK frequency?
If I am correct about the ISR byte transfer latency as the reason for the 4.64us delay between bytes, there is a very quick test.
Make sure the CPU bus clock (BUS_CLK) is set to the highest value the system will tolerate. On some PSoC5LPs it is 80MHz. On others it is only 66MHz.
If the CPU processes code faster, the delay between byte transfer in the ISR will be smaller.