SENT protocol driver using nRF Timer captures

[mchartier]

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?

[mchartier]

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?

[ovrebekk]

Hi Michael

Do you have a specification document for the SENT protocol?

A possible solution to your problem is to use the SAADC periheral to sample the 1-wire data line. The SAADC uses easyDMA to allow sampled data to be stored in RAM automatically, and uses double buffering to ensure that you can switch from one buffer to the next even if the buffer fills up in the middle of a SoftDevice interrupt. 

This use case has been tried out earlier in order to emulate a UART RX line without needing a dedicated UART peripheral, and your use case seems quite similar. You just need to set the ADC sample rate according to the maximum frequency of your signal. 

mchartier said:

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?

The 'Processing at the end of a connection event' interrupt will be shorter when you are only sending 20 bytes, but it will still be longer than 36us. 

The 'Processing when preparing the radio for a connection event' is also longer than 36us, and is not as much affected by how much data is being sent or not. 

Best regards
Torbjørn