Deep sleep edge wake-up
Deep sleep edge wake-up
In my new product, hardware use "static button" and keep your level until user press again. esp_sleep_enable_ext0_wakeup() only accepts LEVEL trigger and this cause esp looping in deep-boot-cycle until user dont press, but I need edge to wake ONLY ONE TIME, how do assign wake up with edge?
Re: Deep sleep edge wake-up
There is no hardware support for edge triggered wake up, however once wake up happens, you can invert GPIO wake up trigger and enter sleep again. Alternatively, you can implement edge trigger in a ULP program.
Re: Deep sleep edge wake-up
Yes, I did logic inversion but it does not look very good... I think about ulp early and it was the only way out, by the way you confirm it, thank you.ESP_igrr wrote:There is no hardware support for edge triggered wake up, however once wake up happens, you can invert GPIO wake up trigger and enter sleep again. Alternatively, you can implement edge trigger in a ULP program.
Could you explain why there is no support for waking up on edge if the code (with main core active) is possible? Does not seem to make much sense at first look...
Re: Deep sleep edge wake-up
Could you please expand the "does not look very good"?
As far as I know, edge wake up was not a requirement for the part of hardware responsible for deep/light sleep wake up.
As far as I know, edge wake up was not a requirement for the part of hardware responsible for deep/light sleep wake up.
Re: Deep sleep edge wake-up
If signal change between code invert logic or between GPIO_READ (to check signal level) and invert logic wakeup, this can not work very well and will miss one edge, I think. Correct?!ESP_igrr wrote:Could you please expand the "does not look very good"?
As far as I know, edge wake up was not a requirement for the part of hardware responsible for deep/light sleep wake up.
Re: Deep sleep edge wake-up
I also believe that having an either-edge trigger is ideal for wakeup scenarios.
A simple open/close sensor easily exhibits the issue with only having hi or low wakeup trigger:
1. I don't want an installer of my product to have to make sure the sensor is open or closed to begin with. If the code starts off in deep sleep then it MUST know ahead of time whether the sensor is open or closed for it to wake up properly.
Note this is also something you don't want to push into your provisioning since it's more code and more user interaction is necessary; and that usually means more complexity for end users and for potential errors.
Note that even if the install is provisioned correctly (we start knowing the sensor is open or closed) we still have to make sure we handle the wakeup-level problem before going to deep sleep (see #2 for issue with detecting wakeup level).
2. Being forced to toggle wakeup trigger hi<-->low is the largest issue. This easily becomes an edge case where timing/race conditions just before deep-sleep could easily render the wakeup level incorrect! The steps would be:
a. read sensor_state
b. set wakeup trigger to be !sensor_state
c. begin deep_sleep
d. ** while deep_sleep is executing, the external sensor is toggled and this state change is LOST
e. result is the ESP32 will not wake up on the next sensor toggle (aka the "missing one" scenario member: ubanze alluded to).
Some other notes:
1. When the ESP32 is awake, the SAME GPIO could now handle the same transitions as it did when in wakeup configuration! Note when out of deep-sleep, I can simply trigger on both-edges.
2. I don't want to have to consume multiple GPIOs for wake up (to cover hi and low scenario) or have the extra wiring code/logic etc... for multiple GPIO's
3. ULP is a big jump in complexity -- assembly coding and co-resident execution issues to work out is
alot for most developers to tackle.
I can understand the comment from ESP_igrr that edge triggering was not part of the HW req. for deep/light sleep wakeup, but that's doesn't mean there aren't many cases where it would be very beneficial.
A simple open/close sensor easily exhibits the issue with only having hi or low wakeup trigger:
1. I don't want an installer of my product to have to make sure the sensor is open or closed to begin with. If the code starts off in deep sleep then it MUST know ahead of time whether the sensor is open or closed for it to wake up properly.
Note this is also something you don't want to push into your provisioning since it's more code and more user interaction is necessary; and that usually means more complexity for end users and for potential errors.
Note that even if the install is provisioned correctly (we start knowing the sensor is open or closed) we still have to make sure we handle the wakeup-level problem before going to deep sleep (see #2 for issue with detecting wakeup level).
2. Being forced to toggle wakeup trigger hi<-->low is the largest issue. This easily becomes an edge case where timing/race conditions just before deep-sleep could easily render the wakeup level incorrect! The steps would be:
a. read sensor_state
b. set wakeup trigger to be !sensor_state
c. begin deep_sleep
d. ** while deep_sleep is executing, the external sensor is toggled and this state change is LOST
e. result is the ESP32 will not wake up on the next sensor toggle (aka the "missing one" scenario member: ubanze alluded to).
Some other notes:
1. When the ESP32 is awake, the SAME GPIO could now handle the same transitions as it did when in wakeup configuration! Note when out of deep-sleep, I can simply trigger on both-edges.
2. I don't want to have to consume multiple GPIOs for wake up (to cover hi and low scenario) or have the extra wiring code/logic etc... for multiple GPIO's
3. ULP is a big jump in complexity -- assembly coding and co-resident execution issues to work out is
alot for most developers to tackle.
I can understand the comment from ESP_igrr that edge triggering was not part of the HW req. for deep/light sleep wakeup, but that's doesn't mean there aren't many cases where it would be very beneficial.
Who is online
Users browsing this forum: Bing [Bot] and 82 guests