SPI inter-byte duration

[Henry Choi]

Hello, I've been working on porting a bit-banged control of a peripheral to use nRF51 SPI--which is just SPI rather than SPIM (therefore no DMA). Observe the SPICLK waveform when I choose 4 MHz:

The byte itself is emitted at 4 MHz. But the huge inter-byte distance remains constant down to about 1 MHz CLK speed. I guess that's just how it is with SPI (not SPIM). In the waveform above, one can see that the maximum effective SPI speed is roughly 14 us / 1 B => 570 KHz, which is only slightly faster than the maximum effective SPI speed when I bit-bang using GPIO on an STM32L1 (Cortex M3) ~ 400 KHz. It nearly negates the arguments for using the SPI peripheral over bit-bang (except for some battery savings by using WFE).

I doubt there is anything I can do to improve the situation, but thought I'd check with experts just in case. Thanks for reading.

[Henry Choi]

Thank you for the reply Wojtek and Hung, you were right: I was taking much too long in my checking for the nrf_spi_event_check(p_spi, NRF_SPI_EVENT_READY). There is still some ~4 us until I see the EVENT_READY flag in the register, but the effective BW is now up to 1.23 MHz (when using the 4 MHz SPI speed). BTW, why can't I call sd_app_evt_wait() (which just calls WFE) while waiting for NRF_SPI_EVENT_READY? I find this to be true even while waiting for NRF_UART0->EVENTS_TXDRDY (in another context) as well. Shouldn't these events wake up the nRF that is sleeping on WFE?

[Henry Choi]

Thanks for the example code Hung. Yes, that is essentially what I am doing. It's strange because calling sd_app_evt_wait() for the SPI0 is working fine--and it was working fine even BEFORE I put in the SCB_SCR_SEVONPEND_Msk or NVIC_ClearPendingIRQ(SPI0_TWI0_IRQn). So WFE() returned for SPI0 when it shouldn't have, and now UART0 WFE is NOT returning when it should?!

The production code is quite a bit more complex, so I really can't isolate it effectively--nor do I have the time to undo all the debugging setup. This is not the 1st time where I had this kind of predicament --unable to run small isolation code due to the complexity of the full setup. I should just buy another nRF51 DK board and set it up as an isolation bed.

I need to solve a more pressing problem, so I'll come back to this later (perhaps when I get another nRF51 DK). Thanks Hung.