GPIOTE_IRQHandler interrupt delay using S110

[technicc]

We're making a height sensor with Bluetooth connectivity using a simple HC-SR04 ultrasonic module, which outputs the height as a pulse with certain width. The width of the pulse should be detected within 1 us, possibly even better. We're testing this on the PCA10001 development board.

We're using TIMER2 and GPIOTE interrupt handler to handle the pulse, measure the width an calculate the height. If the soft-device stack is not initialized, we're getting nice measurements with minimal difference. If the soft-device stack is initialized, the measurements are often way off, probably because of the higher priority of the soft-device.

What is the maximum delay caused by the soft-device before the GPIOTE_IRQHandler is ran? How can we minimize this delay (measure precise times)?

[RK]

What's the range of distances you're trying to measure? I see the pulse output is 58µs per cm of distance so knowing the range of distances narrows down the possible widths of the pulse and thus over how much time you need to make the measurement.

You can't interrupt the softdevice and you can't stop it getting in the way of interrupts. As you can see from the table you were pointed to, it can take control for milliseconds, which is going to entirely ruin your using interrupts to do this.

You have two options. One is to use the concurrent multiprotocol timeslot API to request a timeslot up to 100mS long during which you have sole use of the resources. You then wait for your slot, trigger the measurement, measure the pulse and clean up. Given the time taken to do the trigger, wait for the pulse to start, measure it, have it finish and clean up I'm reckoning you'd only be able to measure about 10m or so. P

The other way, much better, is to use PPI. Connect the output of the sensor to two separate pins and configure them in GPIOTE to trigger events, one when the first pin goes high, the other when the second pin (same signal) goes low. Then use two PPI channels to trigger TIMER2 START from the first event and TIMER2 STOP from the second event. Clear the timer, trigger the start of your measurement. The timer will count the length of the pulse, more accurately than with interrupts even (no interrupt overhead) and you can read the result afterwards. As PPI entirely bypasses the CPU it's unaffected by the softdevice and even if the CPU is busy when the measurement is complete, the value will sit there in the TIMER waiting for you to read it perhaps a millisecond later.

Using PPI should give you sub 1µs accuracy, you should get triggers within one clock cycle of the rising and falling edge of your pulse.

[technicc]

Yep, that's what we did now (I decided to post a new question as the title isn't relevant anymore). But in our application, we connected two events (hitolo and lotohi) on the same physical pin and it seems to be working fine. We clear the timer on lotohi and capture it on hitolo.