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

[irsla]

…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]

[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]

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

[peterhinch]

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]

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

[projectgus]

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.