-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
py/port/esp32 support on esp32c3 for deepsleep wakeup with gpio pins #15498
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The machine
module, as much as possible, should contain port-agnostic functions. So the options here would be:
- Move these functions to the
esp32
module, 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: ***@***.***>
|
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.