Docu: Multiple machine.Timer() instances on ESP8266
There is sadly only a little docu on the timer usage on ESP8266. It shows this example:
from machine import Timer
tim = Timer(-1)
tim.init(period=5000, mode=Timer.ONE_SHOT, callback=lambda t:print(1))
tim.init(period=2000, mode=Timer.PERIODIC, callback=lambda t:print(2))
As it uses the same timer only "2" is printed every 2 seconds, the one_shot "1" is never printed. I tried two instances of Timer(-1) but still only the last one was active. I just tried Timer(-2) and it worked, with Timer(1) and Timer(2) it also worked:
tim1 = Timer(1)
tim2 = Timer(2)
tim1.init(period=2500, mode=Timer.ONE_SHOT, callback=lambda t: print("once"))
tim2.init(period=1000, mode=Timer.PERIODIC, callback=lambda t: print("periodic"))
sleep(3.5)
tim2.deinit()
# expected printout:
# periodic
# periodic
# once
# periodic
There is one thing I'm not sure about I'd like to understand before starting a pull request on the docu:
- Is only one virtual (RTOS -based) timer possible on the ESP8266? machine docu mentions Timer(-1) creates a virtual timer - which sounds good as it doesn't affect hardware.
- If I create a timer with another ID, will it interfere with PWM or sleep() or time()?
By the way, great project, love it:)
stm32: add machine.Timer implemented as a 1ms resolution soft timer
This PR adds a very simple but useful implementation of machine.Timer to the stm32 port, providing a "software timer" with a 1ms resolution, allowing unlimited number of concurrent timers. They can be one-shot or periodic, have a Python callback, and can be cancelled.
It uses SysTick to implement the soft timer, so doesn't impact an existing hardware timer. There is a very small overhead added to the SysTick IRQ, which could be further optimised (eg by patching systick_irq code dynamically).
The Python-level API is intended to match esp8266 and esp32, like this:
from machine import Timer
t = Timer(-1, mode=Timer.PERIODIC, callback=lambda t:print(t), period=2000)
<wait a bit>
t.deinit()
Ultimately the Timer API will be refined further, see discussion at #2971, but for now this at least provides a starting point and something useful and portable.