I’m using Decawave’s DW1000 API, and I wonder if the microcontroller core is occupied when the receiver is turned on to listen for a packet.
More specifically, I’d like to having something in FreeRTOS where there’s a higher priority task for transmitting and receiving packets, and a lower priority task for doing some calculations based on TX and RX timestamps and sending the result out through serial. The question I’d like to ask is, in the higher priority task, when I have the receiver listening for a packet using dwt_rxenable(DWT_START_RX_IMMEDIATE), before a packet arrives, will the CPU be occupied by the higher priority task or will it be able to automatically switch to the lower priority task?
The DW1000 API and all dwt_ functions are simply a wrapper to the SPI calls, therefore non blocking or at least returns as soon as the SPI transaction is done.
I’m using the TWR examples as basis with Zephyr RTOS and in this case, there is a higher level function that is blocking mp_receive
Below it, the rx_poll is blocking with active polling of the DW1000 status register through spi calls
If you want to run a lower prio task while waiting for reception you need to use the DW1000 interrupt mode that gets triggered on uwb receprion and in your isr you enable your task with a semaphore.
Blocking forever or interrupt mode might not be needed if the uwb network design knows when to expect a receprion.
Keep in mind that your os reaction time to isr and toggling to task context might be critical, in case of latency and if you don’t read the uwb packets asap you might have rx overrun if your system have more than one unpredictable sender, and worst, if you make TWR ranging with fixed delay between rx and tx, any reaction latency might miss your answer tx target time.