ESP32 Forum

How can I get a GPIO interrupt to pre-empt WiFi and RMT operations? I need high priority

I have tried using ESP_INTR_FLAG_LEVELn, but I get exceptions for even LEVEL1. Only the default flags, or IRAM flag work.

---

DETAIL:

We've got a 40 kHz clock running to an ESP32 GPIO pin, with an interrupt enabled. The interrupt reads data out of a bit buffer and sets another GPIO pin. It's to send raw data to a radio.

It is very important that this interrupt never be delayed, however I'm seeing occasional latency spikes in the interrupt on the order of ~1ms. I can only tolerate ~25us of jitter.

WiFi is connected in STA mode and I'm using RMT to transmit (to control some LEDs).

Here's how I'm enabling the interrupt. Note: rf_dclk_pin_callback and all functions it calls are declared with IRAM_ATTR (recursively).

static inline void IRAM_ATTR rf_enable_irq(bool enable)
{
gpio_config_t io_conf;
if (enable) {
//interrupt of rising edge
io_conf.intr_type = GPIO_PIN_INTR_POSEDGE;
io_conf.pin_bit_mask = (1ULL << RF_PIN_SI_CLK);
//set as input mode
io_conf.mode = GPIO_MODE_INPUT;
//enable pull-up mode
io_conf.pull_up_en = 1;
gpio_config(&io_conf);
//install gpio isr service
gpio_install_isr_service(ESP_INTR_FLAG_IRAM);
//hook isr handler for specific gpio pin
gpio_isr_handler_add(RF_PIN_SI_CLK, rf_dclk_pin_callback, (void*) RF_PIN_SI_CLK);
} else {
gpio_isr_handler_remove(RF_PIN_SI_CLK);
}
}

Here's one idea https://blog.hackster.io/this-sound-dri ... 5bd197e0cf

Thanks WiFive. Indeed we were considering ULP, but would prefer to use the XTENSA cores.

Update: We are exploring running FreeRTOS only on core 0 and putting our ISR on core 1.

Is there any chance you could e.g. use the I2S or SPI peripheral to do this? In general, the ESP32 is geared to have a bunch of peripherals that should cover most/all use cases that you'd normally use bitbanging for. Can you show what the protocol looks like?

Is there any chance you could e.g. use the I2S or SPI peripheral to do this?

We have tried, but no luck so far.

I2S seems to require a higher external clock speed. External protocol clock is 40kHz.

We need to continuously stream data from the GPIO into the application, and we don't see how to do this with SPI without glitches at the end of the transaction. Maybe we are wrong though, and the hardware can support it?

In general, the ESP32 is geared to have a bunch of peripherals that should cover most/all use cases that you'd normally use bitbanging for.

Understood, but, shouldn't we be able to bit-bang using Core1 while Core0 is busy? I thought that was the whole idea of dual-core Protocol Core vs Application Core !? --- Is there a problem with locks on the IO or RAM bus? (Any recommended reading here?)

Can you show what the protocol looks like?

Two lines:

CLOCK: 40kHz square wave from radio to ESP32.
DATA: binary data from radio-to-ESP32, or ESP32-to-radio (depending on mode)

ESP32 is required to stream data to/from DATA pin on every CLOCK rising edge.

There are some ideas here viewtopic.php?t=10006

Using a 240mhz 32-bit cpu for a 40khz bitstream makes me sad though

@WiFive: THANK YOU! HelWeb's work is just what we needed to see. It's amazing how well you know the ESP community. -- Will update when we have a full solution to our issue, and describe what we learned.