This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SPI VS UART For Minimal Data Transfer & Sleep

Hi devs,

I'm using the NRF52810 to occasionally reprogram a PIC16F15 series chip on boot using SPI. It's working well.

Once the NRF main routine is entered I periodically need to transfer a single byte to the PIC (TX only no confirm) using a timer and have a choice between SPI or UART.

The PIC16F supports both but UART has an advantage in that it's so slow I can sleep the PIC CPU, wake-up on INT and still capture the byte. SPI always needs the PIC clock running.

As such I'm leaning towards UART. My question is when UART EasyDMA is triggered by a timer via PPI will the sd_sleep routine get in the way? I also read UART RX takes 2.3mA of power which I certainly want to avoid, but I assume it can be shut off for TX only. Is there any other aspects I should be aware off before implementing?

Essentially what I'd like to do is for PPI to enable UART, transfer, then disable UART. If I can't enable/disable without CPU intervention and it adds quite a current penalty then the merits over sticking with SPI are less apparent.

Thanks,

Andrew

Parents
  • Hi

    UART with EasyDMA will draw quite a bit of current as you say, so I think I would lean towards SPI in this case as well. If you, by sd_sleep routine, mean the nRF's sleep, then that will indeed be interrupted if you're triggering UART I believe, so you won't be able to stay asleep while the UART is running. Indeed, the SPI will keep the HF clock running until it is finished.

    Best regards,

    Simon

Reply
  • Hi

    UART with EasyDMA will draw quite a bit of current as you say, so I think I would lean towards SPI in this case as well. If you, by sd_sleep routine, mean the nRF's sleep, then that will indeed be interrupted if you're triggering UART I believe, so you won't be able to stay asleep while the UART is running. Indeed, the SPI will keep the HF clock running until it is finished.

    Best regards,

    Simon

Children
No Data
Related