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

SENT protocol driver using nRF Timer captures

SENT protocol uses a 1-wire interface to transfer data using time intervals. To receive data you simply measure the time between pulses on the wire. The transmitter never stops sending data so you must design the receiver to run continuously and record the length (time) for each pulse. 

How to implement this driver with nRF52? 

Our solution is to use GPIO pin, one Timer peripheral, and interrupt handler. One of the Timers is enabled and running continuous. We use PPI to start a timer capture task every time the GPIO is asserted. The GPIO also drives an interrupt to the CPU. The CPU copies the timer value to a buffer and runs the protocol. Works great. 

The problems begin when you enable the SoftDevice because our interrupt handler is blocked from running whenever the SD is running. Our interrupt handler only needs to run a few instructions: Just copy the CC register to a buffer, increment the buffer index, and return. Would it be possible to run this interrupt handler at a higher priority than SD? 

Another idea is to find a way to copy the CC register without CPU involvement. We looked into the PPI but could not find a way to do this. 

Any other ideas?

Parents
  • Some more background:

    Our interrupt handler is running at level-2 which is the highest allowed when the SD is running. The shortest time between interrupts is 36us. If the SD runs at a higher IRQ level for 36us we could miss a data bit. 

    This chart from the SD spec tells us the maximum latency at IRQ-0 is much longer than 36us, however these numbers are for different use cases. In our case the nRF is a BLE peripheral connected to just 1 central. There are no read or write operations. The nRF is only sending 20-byte notification packets. Do you have latency numbers for sending notifications?

Reply
  • Some more background:

    Our interrupt handler is running at level-2 which is the highest allowed when the SD is running. The shortest time between interrupts is 36us. If the SD runs at a higher IRQ level for 36us we could miss a data bit. 

    This chart from the SD spec tells us the maximum latency at IRQ-0 is much longer than 36us, however these numbers are for different use cases. In our case the nRF is a BLE peripheral connected to just 1 central. There are no read or write operations. The nRF is only sending 20-byte notification packets. Do you have latency numbers for sending notifications?

Children
No Data
Related