ESP32 Forum

Dear ESP32ers.

Currently I am working on a low power solution where a peripheral sensor sends a signal (good for an interrup) as soon as an event has occured. Then I can fetch and pre-process the data from the peripheral and based on the pre-processing result I want to either wake up the main cores or send discard the event.
It would be ideal if I could have the event handling including the pre-processing done by the ULP without a need to wake-up the main cores unless the pre-processing produces a positive result.

According to the technical documentation the ULP can be woken up in two ways:
a) by software call
b) by timer
That would mean that either I can use the peripheral signal as an interrupt to wake up the main cores and do the pre-processing there or alternatively
I can wake up the ULP by a timer schedule and upon every wake up check if the interrupt signal from the periperal is set and then do the pre-processing.

Am I right that there is no 3rd option to directly wake up the ULP by a peripheral signal (without powering up the main cores and without regularly waking up the ULP even when there is no signal from the perpheral)?

Thanks in advance for a clarification.
Bernd

You're right about ESP32 ULP, but ESP32-S2 does add GPIO wakeup to ULP (though I don't think it's implemented yet).

A reasonably high wakeup interval will yield very low average current, if the interrupt latency is ok. Even 50ms should be <10uA.

If you want to push the envelope, you could implement a ULP GPIO wakeup by loading the program (without starting), setting a custom deep sleep wakeup stub, and going to sleep with EXT0/EXT1 wakeup configured for the interrupt pin. The deep sleep wakeup stub could start the ULP and return to sleep, or continue to full wakeup if the ULP has flagged that data is ready.
I've given this a try and it works really well (it's about 1ms from interrupt signal to ULP starting) but it's a little hacky/complex.

boarchuz wrote: ↑

Sat Jul 11, 2020 10:45 pm

You're right about ESP32 ULP, but ESP32-S2 does add GPIO wakeup to ULP (though I don't think it's implemented yet).

yeah as someone who uses solely the esp32-s2, I can confirm this and other things aren't implemented yet

@boarchuz
Thanks a lot for the interesting reply.
Using a wakeup stub is a brilliant idea that I didn't have on my radar. I will have to do more reading to understand how to elegantly swap between the different wakeup modes once I will call the ULP from the stub while sending the main cores back to sleep.

But as the purpose should drive the solution and as you already indicated it ultimately it boils down to a balance between power consumption and required reaction time. Perhaps tuning the ULP timer interval could also produce acceptable results.

As for the ESP32S2 I agree. I got the ULP working but after a couple of failed attempts to get ULP-I2C running (I hope the alleged bug from the ESP32 RTC_I2C has been resolved in the ESP32S2) I thought it might postpone further tests with it until the end of summer to give the software some more time to mature.

I have an example here now: https://github.com/boarchuz/HULP/blob/m ... p/main.cpp
I was having trouble with the ULP running at the wrong speed (150 kHz) and everything powering down when the stub ended (killing the ULP in the middle of its program), but simply keeping the ULP sleep timer on when it's running seems to have fixed everything.
There are bitbanging routines for ULP I2C floating around, including one in the linked library, if you're game to give it another try.