Question: how many time to start the ESP3 core from ULP interrupt ?

[Vorms]

Hello,
I deveopp an application that receive infra red slave.
I would like to know if the TSOP (infra red receiver) Can start the ESP32 via ulp and if the ESP32 will be able to decode the infra red trame ?

I can send the infra red trame 3 times with a small time between.
Do ou think it is reallistic to wake up the ESP32 by the ULP and decode the trame ?
Is ther some example to wake up the ESP32 by the way of the ULP GPIO ?

Many thanks for your help.

[boarchuz]

Hi @Vorms,
Yes, if I understand the timings in the datasheet correctly then it shouldn't be a problem. I would have the ULP polling the TSOP output until it goes low, decode the signal using the ULP, and then conditionally wake up (or decode the signal while the SoC is waking).
If you wanted lower power, you could use the wakeup stub to start the ULP only when the pin goes low.
You could even avoid the ULP entirely and do all of this in the wakeup stub.

[Vorms]

Many thanks for your reply I have no experience with the ULP. Now the code is written for the Esp core and it work well. My question is: if the tsop produce an interrupt on the ULP and the ULP start the esp core, what is the time for starting the esp core? Is the infra red trime will be missed? Is the oscillator for the clock of the esp core take time to start? Is that other component that take time? I did the the code for the emitter and each trame is repeated 3 times so it will be not a problem. Thierry Le dim. 14 janv. 2024, 21 h 57, boarchuz ***@***.***> a écrit :

…

Hi @Vorms <https://github.com/Vorms>, Yes, if I understand the timings in the datasheet correctly then it shouldn't be a problem. I would have the ULP polling the TSOP output until it goes low, decode the signal *using the ULP*, and then conditionally wake up (or decode the signal while the SoC is waking). If you wanted lower power, you could use the wakeup stub to start the ULP only when the pin goes low. You could even avoid the ULP entirely and do all of this in the wakeup stub. — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6QD4KJAG7S66G3WFE4FL3YOSZL7AVCNFSM6AAAAABBZQXJKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJRGMYDGMZWHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[boarchuz]

Typically it takes a few hundred ms to app_main. If you tweak the build configuration, you can easily reduce this to 20-30ms, which is probably far too long still for your application.
If the ULP remains on at all times, polling the pin, it won't miss anything. The downside is that you would need to program a decoder for the ULP.
Stub takes about 1ms, which is probably quick enough, so you could go the stub+ULP or stub-only route too.

Another option, given you control the transmitter, would be to send a 'wakeup' preamble to prompt the receiver to exit deep sleep, wait ~50ms to allow the receiver to initialise, and then send the command.

[Vorms]

Hello, Many thanks for your tips ! I will do it ! Best regards Thierry Vorms Le mar. 16 janv. 2024 à 00:46, boarchuz ***@***.***> a écrit :

…

Typically it takes a few hundred ms to app_main. If you tweak the build configuration, you can easily reduce this to 20-30ms, which is probably far too long still for your application. If the ULP remains on at all times, polling the pin, it won't miss anything. The downside is that you would need to program a decoder for the ULP. Stub takes about 1ms, which is probably quick enough, so you could go the stub+ULP or stub-only route too. Another option, given you control the transmitter, would be to send a 'wakeup' preamble to prompt the receiver to exit deep sleep, wait ~50ms to allow the receiver to initialise, and *then* send the command. — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6QD4NYNTEV2YTJW4EG4DLYOYH2XAVCNFSM6AAAAABBZQXJKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJTGEYDMNBTGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Thierry Vorms Québec Canada