pyboard - deepsleep wake pins
I have just switched to pyboard for a project which has been on the esp32 and I need to be able to wake from deep sleep by either time or a pin edge.
https://github.com/micropython/micropython/blob/master/docs/library/machine.Pin.rst
https://docs.micropython.org/en/latest/pyboard/library/machine.Pin.html
These pages indicate that the syntax for enabling a wake-up pin is:
import machine as mc
door = mc.Pin('X1',mc.Pin.IN)
door.irq(handler=None, trigger=(mc.Pin.IRQ_FALLING | mc.Pin.IRQ_RISING),wake=mc.DEEPSLEEP)
However this results in an error:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'DEEPSLEEP'
What's the solution ?
py/port/esp32 support on esp32c3 for deepsleep wakeup with gpio pins
Adding support on esp32c3 port for deepsleep wakeup with gpio pins and retriving the pin(s) that triggered the wakeup
<!-- Thanks for submitting a Pull Request! We appreciate you spending the
time to improve MicroPython. Please provide enough information so that
others can review your Pull Request.
Before submitting, please read:
https://github.com/micropython/micropython/blob/master/CODEOFCONDUCT.md
https://github.com/micropython/micropython/wiki/ContributorGuidelines
Please check any CI failures that appear after your Pull Request is opened.
-->
Summary
<!-- Explain the reason for making this change. What problem does the pull request
solve, or what improvement does it add? Add links if relevant. -->
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
<!-- Explain what testing you did, and on which boards/ports. If there are
boards or ports that you couldn't test, please mention this here as well.
If you leave this empty then your Pull Request may be closed. -->
I created a new version of the firmware for a project of mine and it has been working since months.
Trade-offs and Alternatives
<!-- If the Pull Request has some negative impact (i.e. increased code size)
then please explain why you think the trade-off improvement is worth it.
If you can think of alternative ways to do this, please explain that here too.
Delete this heading if not relevant (i.e. small fixes) -->
No tradeoffs that I am aware of.