Reduce the time delay between each SPIM transfer

RE: Reduce the time delay between each SPIM transfer

MinhDuc — Wed, 30 Aug 2023 09:02:00 GMT

Thank you Susheel. Now I understand the difference between lib/driver and direct access of the peripheral register.

I write SPIM again with fully direct access of the peripheral register. The result looks so great.

Best,

RE: Reduce the time delay between each SPIM transfer

Susheel Nuguru — Wed, 30 Aug 2023 05:58:32 GMT

I do not think that the application is supposed to write to EVENTS_XXX.

You are using the SPI libs and drivers that we provide and so, I do not suggest to experiment anything with the SHORTS while using the lib/driver API. This might confuse them.

If you want to use shorts, then it is best to handle the whole transaction and events through direct access of the registers. I strongly suggest you not to mix driver/library API use with direct access of the peripheral register.

Have you tried to figure out where the bottleneck is when using the nrfx_spim_xfer? Have you tried using the Segger Systemview as I recommended to see which contexts are running between your SPI transfers?

RE: Reduce the time delay between each SPIM transfer

MinhDuc — Wed, 30 Aug 2023 00:59:40 GMT

Hello Susheel.

I have play around register for SPIM and I reach 3us interrupt between each SPI transfer.

I followed the sugggestion of Haakonsh from the similar topic.

What I have done is call TASKS_START then EVENTS_END then update the content of spi_tx_buf then call TASKS_START again...

I realize that the main delay come from everytime I call nrfx_spim_xfer().

nrfx_spim_xfer(&spi, &xfer_desc_rd, flags);

NRF_SPIM3->TASKS_START = 1;
NRF_SPIM3->EVENTS_END = 1;
spi_tx_buf[1] = false << 7 | false << 6 | channel_begin+1;
nrfx_spim_xfer(&spi, &xfer_desc_rd, flags);
NRF_SPIM3->TASKS_START = 1;
NRF_SPIM3->EVENTS_END = 1;

.....

Please kindly explain the suggestion from Haakonsh above. What should I do with SHORTS?

Best,

RE: Reduce the time delay between each SPIM transfer

Susheel Nuguru — Mon, 28 Aug 2023 10:46:43 GMT

I would suggest you to run Segger SystemView and get an overview on all the contexts you are running to see what that 8us time is spent on. If this is another peripheral interrupt context or if this is still in the SPI peripheral context. Without knowing where that 8uS are spent, it is hard to optimize it.