Are short sleeps useful?

[Christopher Mason]

I'm working on a product that integrates an nrF51822 talking over SPI to an external display. The display protocol involves a series of alternating 10 us sleeps and SPI sends at 16Mhz of small numbers of bytes (usually 2 but always < about 40). I'm currently implementing this via spinning for waits (NOPs as in nrf_delay_us) and for SPI_READY. I'm observing (not surprisingly) 4.4 mA current consumption during this process which takes a few seconds.

I'm trying to reduce current consumption.

I could perhaps use the TIMER to generate an interrupt for the 10 us delay and put the processor to sleep (WFE) for 160 cycles. And then similarly with the SPI_READY. I could maybe even use the PPI to link the SPI_READY and the TIMER_START events. I understand that the 16 Mhz oscillator has to run to drive the SPI and TIMER. But, according to the datasheet this is ~400 uA for the osc, and then 178 for the TIMER and 200 for SPI. This is about a 7x reduction...

The question is: would it be worth it to try? I'm not sure how to tell what the overhead of WFE is?

Thanks!

-c

[ovrebekk]

Hi Chris

There will always be a delay when waking up from sleep, which will limit the potential savings when the sleep period is as short as 10 us. By default the wakeup time from System ON mode is about 6us, but you can reduce this to about 2,5us if you enable the 'constant latency' mode before you enter sleep. In constant latency mode the sleep current will be quite high (around 1mA), but there might some minor savings to be had.

As mentioned by Wilhelmsen it's definitely worth a try :)

Regards Torbjørn