Skip to content

modify deepsleep to allow wakeup on X1 or X18 on a STM32F7 (SF2/3/6W) #6482

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

modify deepsleep to allow wakeup on X1 or X18 on a STM32F7 (SF2/3/6W) #6482

wants to merge 2 commits into from
+76 −1

Conversation

irsla
Copy link

@irsla irsla commented Sep 24, 2020

…F2/6W

example
machine.deepsleep([time_ms | 0 for infinity], [WKUP_PINS_X1/X18], [WKUP_PINS_X1/X18_RISING/FALLING])

machine.deepsleep()
machine.deepsleep(20000)
machine.deepsleep(10000, machine.WKUP_X1, machine.WKUP_X1_RISING)
machine.deepsleep(0, machine.WKUP_X1, machine.WKUP_X1_RISING)
machine.deepsleep(0, machine.WKUP_X1, machine.WKUP_X1_FALLING)

Prior to this commit only the timer wakeup would work for a deepsleep.
This was the case because for the STM32F7 all wakeup pins were cleared out before
entering in deepsleep

this commit is a work in progress for technical discussions.

@irsla
modify deepsleep to allow wakeup on X1 or X18 (to be tested !) on a S…
7220862 
…F2/6W

example
machine.deepsleep([time_ms | 0 for infinity], [WKUP_PINS_X1/X18], [WKUP_PINS_X1/X18_RISING/FALLING])

machine.deepsleep()
machine.deepsleep(20000)
machine.deepsleep(10000, machine.WKUP_X1, machine.WKUP_X1_RISING)
machine.deepsleep(0, machine.WKUP_X1, machine.WKUP_X1_RISING)
machine.deepsleep(0, machine.WKUP_X1, machine.WKUP_X1_FALLING)

Prior to this commit only the timer wakeup would work for a deepsleep.
This was the case because for the STM32F7 all wakeup pins were cleared out before
entering in deepsleep

this commit is a work in progress for technical discussions.
@peterhinch
Copy link
Contributor

peterhinch commented Sep 25, 2020 •
edited
Loading

[EDITED]
This is STM specific. If a C solution is to be used, pyb would be preferable to machine which is cross-platform.

It may be worth also considering a Python solution as speed is not an issue.

Alas, as you have identified, a Python solution to X1 wakeup is currently not feasible because of this line. With that line commented out I have tested a Python solution which wakes on X1 or X18.

@irsla
Copy link
Author

irsla commented Sep 28, 2020

Ok now we have a duplicate for this issue, which is good, it means that it will be solved one way or another.

So now we need to discuss the solutions.

Solution 1 (time based): PR 6482 (this one):

  • provide full control over X1 and X18 wake up pins in the machine/pyb module in an "easy way"
    - full control:
    - set wake up pin
    - set trigger on falling/raising wake up
    - get the reset_cause
    Solution 2 (time based): PR 6494
  • handle full control over X1 and X18 to the user
    - full control:
    - set wake up pin in python
    - set trigger on falling/raising wake up in python
    - get the reset_cause in python

Both solution have advantages and drawbacks.

Drawbacks:
Solution 1:
a lot of C code as we will need to break the calling of machine_deepsleep from pyb_standby in order to control the pins and will have to duplicate the reset_cause and have a fall-through machine_reset_cause if pyb_reset_cause is not X1/X18

Solution 2:
the complexity is moved to the user/developer

How can we have this discussion ?

Duplicate: #6494

@irsla irsla mentioned this pull request Sep 28, 2020
Closed
@peterhinch
Copy link
Contributor

peterhinch commented Sep 28, 2020 •
edited
Loading

The latest release of my micropower repo requires only this #6494 small change to the firmware. It supports the Pyboard D in a way that has been in use for some time on the Pyboard 1.x. User code will only need minor changes to migrate to the D series. Further this very simple PR doesn't preclude supporting micropower functions in C. It merely provides to the D series functionality available on the Pyboard 1.x. In my opinion it is a bug fix.

I see no conflict between the different approaches. My solution exists now and (with this bug fix) works on the D series. If there is a case for a C solution I see no reason why this cannot be developed independently.

@irsla
Proposal micropython#2
5072df0 
this includes patch for PR6494 and allows both patch to co-exists

Users can then choose between 2 ways
   machine.deepsleep([ms])
   pyb.standby([ms], [wakeup Pins X1|X18], [wakeup trigger FALLING|RISING])

-- tested 1.13
machine.deepsleep(2000) # OK
machine.deepsleep(5000) # OK
machine.deepsleep(10000) # OK
machine.deepsleep(20000) # OK
machine.deepsleep() # OK waited 2 minutes

-- tested new firmware
machine.deepsleep(2000) # OK
machine.deepsleep(5000) # OK
machine.deepsleep(10000) # OK
machine.deepsleep(20000) # OK
machine.deepsleep() # OK waited 2 minutes

pyb.standby(0) # OK waited for 2 minutes
pyb.standby(2000) # OK
pyb.standby(5000) # OK
pyb.standby(10000) # OK
pyb.standby(20000) # OK
pyb.standby() # OK waited for 2 minutes

pyb.standby(0, pyb.WKUP_X1, pyb.WKUP_X1_FALLING) # OK wake up on interrupt within 10 sec
pyb.standby(2000, pyb.WKUP_X1, pyb.WKUP_X1_FALLING) # OK wakes up after 2sec
pyb.standby(5000, pyb.WKUP_X1, pyb.WKUP_X1_FALLING) # OK wakes up after 5 sec
pyb.standby(10000, pyb.WKUP_X1, pyb.WKUP_X1_FALLING) # OK wakes up after 10 sec and wakes up on interrupt within 10 sec
pyb.standby(20000, pyb.WKUP_X1, pyb.WKUP_X1_FALLING) # OK wakes up after 20 sec  and wakes up on interrupt within 20 sec

pyb.standby(0, pyb.WKUP_X18, pyb.WKUP_X18_FALLING) # OK wake up on interrupt within 10 sec
pyb.standby(2000, pyb.WKUP_X18, pyb.WKUP_X18_FALLING) # OK wakes up after 2sec
pyb.standby(5000, pyb.WKUP_X18, pyb.WKUP_X18_FALLING) # OK wakes up after 5 sec
pyb.standby(10000, pyb.WKUP_X18, pyb.WKUP_X18_FALLING) # OK wakes up after 10 sec and wakes up on interrupt within 10 sec
pyb.standby(20000, pyb.WKUP_X18, pyb.WKUP_X18_FALLING) # OK wakes up after 20 sec  and wakes up on interrupt within 20 sec

-- TO TEST
pyb.standby(0, pyb.WKUP_X1 | pyb.WKUP_X18, pyb.WKUP_X1_FALLING | pyb.WKUP_X18_FALLING) #
machine.deepsleep with upower.py
@irsla
Copy link
Author

irsla commented Oct 1, 2020

So here is V2, where I had to cut the link between pyb.standby and machine.deepsleep to keep PR6494

I would love to have the opinion of a maintainer, so that I know if there's any good in pursuing into this direction

RetiredWizard pushed a commit to RetiredWizard/micropython that referenced this pull request Feb 9, 2023
@dhalbert
Merge pull request micropython#7538 from gneverov/issue_6482
9e242bf 
Fixes micropython#6482
@Gadgetoid Gadgetoid mentioned this pull request Feb 29, 2024
Merged
@projectgus
Copy link
Contributor

This is an automated heads-up that we've just merged a Pull Request
that removes the STATIC macro from MicroPython's C API.

See #13763

A search suggests this PR might apply the STATIC macro to some C code. If it
does, then next time you rebase the PR (or merge from master) then you should
please replace all the STATIC keywords with static.

Although this is an automated message, feel free to @-reply to me directly if
you have any questions about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
port-stm32
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@irsla @peterhinch @projectgus @dpgeorge