py/port/esp32 support on esp32c3 for deepsleep wakeup with gpio pins #15498
Conversation
…d retriving the pin(s) that triggered the wakeup
|
To publish this PR I had to learn git, GitHub, and a bunch of other things like ssh keys, tokens, etc etc |
There was a problem hiding this comment.
Thanks @m-cas for picking up this long-standing feature PR.
As mentioned on some of the earlier incarnations, I feel like there's an opportunity here to add ESP32-C3 pin wake functionality via the existing machine.Pin.irq(wake=) argument (see `esp32/machine_pin.c). This is the standard non-port-specific way to do wakeup. It's actually a good fit for the C3 because there isn't the weird distinction between EXT0 and EXT1.
What do you think about this idea?
| @@ -166,6 +166,24 @@ Power related functions | |||
|
|
|||
| Availability: ESP32, WiPy. | |||
|
|
|||
| .. function:: wake_ext1_pins() | |||
There was a problem hiding this comment.
The machine module, as much as possible, should contain port-agnostic functions. So the options here would be:
- Move these functions to the
esp32module, as they're port specific. - Make a generic
wake_pins()function and document it as only available currently on the ESP32 port. This creates the possibility that other ports can support it in the future.
I don't know if returning only the EXT1 wake pins as a wake_pins() result would be too misleading or not, but I assume the function could be extended to include EXT0 pins if there were any?
Unfortunately the CI logs have been cleaned up, but if you rebase this commit and push again then it'll refresh. The general docs for contributing are here: https://github.com/micropython/micropython/blob/master/CODECONVENTIONS.md My guess is what you'll need to do is:
You should be able to use |
|
Hi. Firstly thanks for all the work you guys did.on this but im still confused as to the current status. Simply put if i use the latest micropython build for an esp32 c3 and want to use deepsleep and wake on the state change of a gpio pin..(doesnt matter which one and it doesnt matter to my program which one woke it) , my application just needs to wake and connect to wifi and send some data... will it work? |
|
Hiit should. The work, started by others much more gifted than me, that I consolidated in my pull request aims at making this thing work better, with the right pins, and to know who did wakeup the chip.But the 'just wake up and so something if one pin goes up or down' wakeup was already there if I eemember correctly...-From my phone while mobile, please excuse any errors.On 11 Feb 2025, at 12:21, damian-barker ***@***.***> wrote:
Hi. Firstly thanks for all the work you guys did.on this but im still confused as to the current status. Simply put if i use the latest micropython build for an esp32 c3 and want to use deepsleep and wake on the state change of a gpio pin..(doesnt matter which one and it doesnt matter to my program which one woke it) , my application just needs to wake and connect to wifi and send some data... will it work?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
I'm completely ok as long as we don't lose functionality!-From my phone while mobile, please excuse any errors.On 24 May 2025, at 22:05, Meir Armon ***@***.***> wrote:meirarmon left a comment (micropython/micropython#15498)
@projectgus as far as I can tell, using machine.Pin.irq(wake=) does not always work for deepsleep, so this would be a better solution.
Thanks @m-cas for picking up this long-standing feature PR.
As mentioned on some of the earlier incarnations, I feel like there's an opportunity here to add ESP32-C3 pin wake functionality via the existing machine.Pin.irq(wake=) argument (see `esp32/machine_pin.c). This is the standard non-port-specific way to do wakeup. It's actually a good fit for the C3 because there isn't the weird distinction between EXT0 and EXT1.
What do you think about this idea?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@projectgus @m-cas
All of these should use the capability definitions and not port definitions. @projectgus please confirm that this makes sense to you, as I don't want to put effort into this and then have it go stale |
|
@m-cas I don't think that your PR can be merged any more ( I do see that in your PR you also have wake pins to see which pins triggered the waking up, I am happy to open a PR that will add those as well. |
|
@meirarmon Good job! Please add the pin check on wake, it is as important as the wake function itself!-From my phone while mobile, please excuse any errors.On 20 Jun 2025, at 13:53, Meir Armon ***@***.***> wrote:meirarmon left a comment (micropython/micropython#15498)
@m-cas I don't think that your PR can be merged any more (wake_on_ext1 is now not available on ESP32C3 as EXT1 is not supported by the chip). I have here a PR that add an interface for wake_on_gpio in a similar manner, I tested this on my C3, and it should work.
If you can compile from my branch, and test it as well, that would be very much appreciated.
I do see that in your PR you also have wake pins to see which pins triggered the waking up, I am happy to open a PR that will add those as well.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Hi, do you mean |
|
Correct!-From my phone while mobile, please excuse any errors.On 20 Jun 2025, at 15:08, Meir Armon ***@***.***> wrote:meirarmon left a comment (micropython/micropython#15498)
@meirarmon Good job! Please add the pin check on wake, it is as important as the wake function itself!-From my phone while mobile, please excuse any errors.On 20 Jun 2025, at 13:53, Meir Armon @.> wrote:meirarmon left a comment (micropython/micropython#15498) @m-cas I don't think that your PR can be merged any more (wake_on_ext1 is now not available on ESP32C3 as EXT1 is not supported by the chip). I have here a PR that add an interface for wake_on_gpio in a similar manner, I tested this on my C3, and it should work. If you can compile from my branch, and test it as well, that would be very much appreciated. I do see that in your PR you also have wake pins to see which pins triggered the waking up, I am happy to open a PR that will add those as well. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.>
Hi, do you mean wake_gpio_pins and wake_ext1_pins?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
NP, I will probably have a PR in the next couple of days.
As I don't want to couple the two features, they will be separate PRs, but
I don't mind giving you a unified branch for testing (but then please try
it out and give me feedback).
On Fri, Jun 20, 2025 at 5:39 PM Massimo Castelli ***@***.***>
wrote:
… *m-cas* left a comment (micropython/micropython#15498)
<#15498 (comment)>
Correct!-From my phone while mobile, please excuse any errors.On 20 Jun
2025, at 15:08, Meir Armon ***@***.***> wrote:meirarmon left a comment
(micropython/micropython#15498)
@meirarmon Good job! Please add the pin check on wake, it is as important
as the wake function itself!-From my phone while mobile, please excuse any
errors.On 20 Jun 2025, at 13:53, Meir Armon @.> wrote:meirarmon left a
comment (micropython/micropython#15498) @m-cas I don't think that your PR
can be merged any more (wake_on_ext1 is now not available on ESP32C3 as
EXT1 is not supported by the chip). I have here a PR that add an interface
for wake_on_gpio in a similar manner, I tested this on my C3, and it should
work. If you can compile from my branch, and test it as well, that would be
very much appreciated. I do see that in your PR you also have wake pins to
see which pins triggered the waking up, I am happy to open a PR that will
add those as well. —Reply to this email directly, view it on GitHub, or
unsubscribe.You are receiving this because you were mentioned.Message ID:
@.>
Hi, do you mean wake_gpio_pins and wake_ext1_pins?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are
receiving this because you were mentioned.Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub
<#15498 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA6BYMA6QZOMGJAGN4WJMYL3EQMKTAVCNFSM6AAAAABLEZRIKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJRHA3DSMRZHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@m-cas I have an open PR for the |
Adding support on esp32c3 port for deepsleep wakeup with gpio pins and retriving the pin(s) that triggered the wakeup
Summary
The current support for the ESP32C3 platform contains errors preventing the usage of deep sleep wakeup with pins. Two older PRs (#13333 and #7990) were created to fix this using gpio pins and to add the necessary calls to retrieve the pin(s) that triggered the wake. I have refactored the code, updated to the latest master (e.g. STATIC -> static) and tested.
Testing
I created a new version of the firmware for a project of mine and it has been working since months.
Trade-offs and Alternatives
No tradeoffs that I am aware of.