Other interrupts delayed while playing

[mglazzari-qinmotion]

I'm trying to add IR remote control to the WebradioMP3PlusWebUI example (running on a Pi Pico 2 W)

I modified the example with the following code:

void remotControlISR(){
  digitalWrite(12, digitalRead(11));
}

essentially copying the interrupt triggering the input to an output pin

I modified the setup() as follows:

void setup() {
/* 
original setup code from example
*/
...
  web.on("/setvol", handleVolume);
  web.on("/seturl", handleURL);
  mp3.begin();
  
//New code added
  pinMode(11, INPUT_PULLUP);
  attachInterrupt(11, remotControlISR, CHANGE);
  pinMode(12, OUTPUT);
}

When I send an IR code to the sensor, this is the capture from the scope:

The bottom half of the screen is a zoom in of the full code capture (top). The yellow trace is the input, and the blue trace is the output pin. For the most part, the interrupts trigger properly, with the blue trace closely following the yellow trace. but a bit to the right of the middle of th escreen, there are 3 short pulses at the input that get essentially missed by the ISR. I guess that this is because the interrupts either get disabled or the audio play interrupt has higher priority than the GPIO interrupt.
Is there any way around this?
Thanks!

[mglazzari-qinmotion]

Well. running the ISR in Core 1 is working, but any other simple ideas are welcome.

void setup() {
/* 
original setup code from example
*/
...
  web.on("/setvol", handleVolume);
  web.on("/seturl", handleURL);
  mp3.begin();
  
//New code added
  pinMode(11, INPUT_PULLUP);
  pinMode(12, OUTPUT);
}

void setup1(){
  attachInterrupt(11, remotControlISR, CHANGE);
}

Thanks!

[earlephilhower]

Interesting problem, and thanks for the debug and clear explanation. This is pretty straightforward, actually. The ARM chips have a priority for IRQs, and in this case the DMA IRQ (which gets fired when the DMA engine finishes transferring a buffer to the PIO) seems to be higher priority than the GPIO IRQ. So, the GPIO IRQ can't actually fire until the DMA one completes.

On the ESP32 the IRQ completes almost instantly because it uses FreeRTOS to fire a message to a task and returns immediately. The actual MP3 decode happens at normal level (non-IRQ) so it doesn't block GPIO or other IRQs.

On the Pico, since we are bare metal, the DMA IRQ handler actually does a MP3 chunk decode before returning, which can take a bit of time.

I see 2 solutions.

One would be to the the NVIC to change the DMA IRQ priority below GPIO (or move GPIO priority up), but that might end up breaking tons of other stuff.

The other would be to do minimal work in the DMA IRQ handler, and then post another IRQ to a user-level IRQ (lowest priority IIRC) which would do the decode and buffer fill. That very low priority IRQ handler could be preempted by GPIO or other handlers.

Let me see if the 2nd option really is doable. I think they do something like that for USB tasks in the SDK...

[earlephilhower]

@mglazzari-qinmotion can you please try #85 with your IRQ timing test? Logically it should make GPIO IRQs happen just as fast as w/o BackgroundAudio, but I don't good equipment to verify that. I did test that WebRadio still works and seems unchanged.

[mglazzari-qinmotion]

That worked fine!
The two traces track closely, with no missed pulses:

The delay between the two signals was 18us average, with a range of 1.8us to 40.8us over 105 samples. I'd say plenty fast for most applications.

Thanks!

[earlephilhower]

Thanks for the update!