• State Verified Answer
  • Replies 6 replies
  • Subscribers 70 subscribers
  • Views 3543 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 226724
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52810 SPI and duration of CS after last byte transferred

Skols

In my attempt of learning the nRF52 "eco system" (nRF52 DK, nRF15.3 SDK, SES and pca10040e project  for nRF52810), I have combined the GATT_C, GPIO and SPI examples to make an application for streaming CAN data over BLE. CAN is a mcp2515 chip with SPI, and I use SPI with DMA to transfer data to and from the mcp2515.

Everything works fine wrt SPI. However, it seems to me that the CS goes systematically high (or with other words, the SoftDevice releases the SPI) ~15 us after last byte is transferred over the SPI bus.  

My question is if there is a way to reduce the time from the SPI SCK goes inactive to the CS goes high (CS is active low on the mcp2515)? 



In the picture the red is the CS and the blue is the SPI SCK.

Parents
  • +1

    Hi,

    The SPIM peripheral in the nRF52810 does not implement chip select, so this is handled by the driver by controlling a GPIO pin. Looking at the implementation in nrfx (modules\nrfx\drivers\src\nrfx_spim.c) you can see that it is cleared by the finish_transfer() function, which is called as the last thing when handling the NRF_SPIM_EVENT_END. If you use on-deferred logging you might be able to save a bit of time by moving the call to finish_transfer()  before the log line, but other than that there is not much optimization to be done as far as I can see.

Reply
  • +1

    Hi,

    The SPIM peripheral in the nRF52810 does not implement chip select, so this is handled by the driver by controlling a GPIO pin. Looking at the implementation in nrfx (modules\nrfx\drivers\src\nrfx_spim.c) you can see that it is cleared by the finish_transfer() function, which is called as the last thing when handling the NRF_SPIM_EVENT_END. If you use on-deferred logging you might be able to save a bit of time by moving the call to finish_transfer()  before the log line, but other than that there is not much optimization to be done as far as I can see.

Children
Related