P2 - GPIO and Interrupt Latency

Firmware Device OS
1

I was testing the P2 and dev board that Particle so graciously sent me to see what the GPIO speed and interrupt latency were.

To do this, I used an external wave generator set to output a 1KHz 3.3v 50% duty cycle square wave on pin D2 and ran a simple piece of code. I connected my oscilloscope to pin D7 and used the waveform generator output as the trigger (falling edge).

//SYSTEM_MODE(MANUAL);
SYSTEM_THREAD(ENABLED);

void p2_isr()
{
    digitalWrite(D7, HIGH);
//    pinSetFast(D7);
    digitalWrite(D7, LOW);
//    pinResetFast(D7);

}

void setup() {

//    WiFi.off();
    
    pinMode(D2, INPUT);
    pinMode(D7, OUTPUT);

    attachInterrupt(D2, p2_isr, FALLING);
}

void loop() {
}

I tested with Cloud and WiFi both enabled and disabled to see if there were any impacts. Threading was enabled in all tests. I measured the time between the trigger waveform falling edge to the rising edge of D7 for interrupt latency, and between the rise and fall of D7 for the GPIO speed. Here are my observations:

  • Cloud and WiFi connectivity did not affect the results
  • Changing priority of interrupt from default 13 to 5 had no affect
GPIO Speed Measured Time
digitalWrite 2.8uS - 3.8uS
pinSetFast/resetFast 6uS
ISR Latency Measured Time
using D2 40-70uS

Though the GPIO speed could/should be faster, it is no bad. Interestingly, using the “fast” GPIO functions actually produced worst results! There may need to be more tweaking of the low-level code.

A latency of 40-70uS is actually pretty good. It would be interesting to see what happens with Bluetooth enabled and more system resources being used.

3 Likes
2

@peekay123 We are aware of fast pin APIs being slower than the regular ones, this will be fixed in the upcoming 5.x release. We are most likely however unable to achieve better timings due to the GPIO peripheral clock speed, which we have no control over.

1 Like