How to reduce clock intervals in emfile

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.
koMi_4274846
Level 1
Level 1
First question asked First reply posted First like received

Hi, I'm using emfile in PSoC 5LP

I would like to reduce interval of clock in communicating.

Do you know anyone why is it need interval???

I show that waveform image.

You can confirm interval 15 times the clock  

I know we have had a similar question

emFile writing is inefficient, any ways to speed it up?

I already had checked effect of interrupt.

It was not enough to me.

Now,

I have succeeded reading SDcard that like shown in the code below.

with reference to the following site.

GitHub - holla2040/psoc5EmFileConsoleExample: PSoC5 SD Read example project using emFile component

sorry, don't care the blue under line.

This code is a part of for asking here.

Master clock 48MHz. Max SPI frequency in emfile setting is 24MHz.

There are component in Topdesign that emfile and USBUART.

Thank you for your support!


pastedImage_9.png

1 Solution
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

koMi,

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.

Len

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.

Len
"Engineering is an Art. The Art of Compromise."

View solution in original post

5 Replies
Rakshith
Moderator
Moderator
Moderator
250 likes received 1000 replies posted 750 replies posted

Hi koMi_4274846​,

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

Thanks and Regards,
Rakshith M B
0 Likes
lock attach
Attachments are accessible only for community members.

Hi, RakshithM_16

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

Thanks!
RakshithM_16

0 Likes

Hi koMi_4274846,

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

Thanks and Regards,
Rakshith M B
0 Likes
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

koMi,

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.

Len

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.

Len
"Engineering is an Art. The Art of Compromise."
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

koMi,

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.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes