mircopython virtual timer

[yfyungit]

Is the virtual timer in mircopython a hardware timer? Is there a limit on the number of timers created?

machine.Timer(-1)

Is there a software timer similar to rtos?

[robert-hh]

That varies among ports. When the id of the Timer(id) call is omitted or -1, it iI is a soft timer, and the number is not per se limited.

[yfyungit]

All ports, When the id of the Timer(id) call is omitted or -1, Are they all software timers?
The ports I am currently using : RP2040 / ESP8266 / ESP32-C3 / ESP32-S3

[robert-hh]

When the id of the Timer(id) call is omitted or -1

Should be: When the id of the Timer(id) call can be omitted or -1.
.
RP2040: Software timer. The ID argument is optional, but must be -1, if present.
ESP32: 1 to 4 hardware timers. The ID argument must be present.
ESP8266: Software timer; the ID argument must be present, but the value ignored.

[mendenm]

Of course, on the RP2040 (etc.) you can use the PIO system to create hardware timers, since they can count and raise interrupts. I think on a 120 MHz machine, the can run as slowly as 5 kHz, and the counter is 32 bits, so they can time as long as about 1 million seconds (2 weeks, or so).

Added note later: You can actually go a lot longer, without wasting more spacing with extra instructions, since you can put delay cycles on the instructions in the loop. With a few more instructions, of course, you can use a nested loop, and it will run for the age of the universe, approximately.

[yfyungit]

OK, thank you very much

[ma261065]

Is there a difference between virtual timers and hardware timers if the timer callback runs for longer than the timer period?

For example if I have an callback that takes 20ms to run, but I set the timer to call it every 10ms will a "queue" of pending calls build up? Is it different between virtual and hardware timers?

I know that callbacks should run as quickly as possible, but this question is more to understand how the callbacks are scheduled, and any differences between the two timer types.

[robert-hh]

Is there a difference between virtual timers and hardware timers if the timer callback runs for longer than the timer period?

Yes. With timers you have to look at both the hardware mechanism of the timer and the way, the callback is executed.
Hard timers use dedicated timer hardware, one for each timer, which is set to cause an Interrupt after the configured time. Soft timers use the existing ticks interrupt, which is usually executed every ms. In this interrupt - hardware timer ISR or ticks ISR, the callback is initiated by either scheduling the callback to be executed ASAP or calling it immediately. That is controlled by the keyword option hard=True|False. Soft timers usually only support scheduled callbacks, while hard timers may support directly executed callbacks. That depends on the port.
With scheduled callbacks these can queue up. So if the callback takes longer that the period of the timer, the next execution of the callback is initiated while it is still running, and it will either run as soon as the first scheduled instance is finished or while it is still running.
With "hard" callbacks the next execution is usually blocked until the callback finishes. But since these run in ISR context and execution of other Python code is usually blocked during this time, these callbacks should anyhow finish very fast.

[ma261065]

Thanks Robert. I didn't see any reference to the hard keyword in the documentation, so this is useful to know

In terms of scheduled callbacks queuing up, is there any way to see the length of this queue?

[robert-hh]

I do not know.

[ma261065]

Just out of interest I ran this as a stress test:

import time
from machine import Timer
timer = Timer(0)

def wait(_):
    print(time.ticks_ms())
    time.sleep(30)

timer.init(period=1, mode=Timer.PERIODIC, callback=wait)

So, it is a 1ms timer calling a function that takes 30s to execute. I ran this for hours on an ESP32C6 without running out of memory (which I would expect it to if it was indeed adding all the callbacks to a queue), so I imagine the queuing must check if the function is already scheduled and if so it will not add a new one to the queue?

[robert-hh]

Yes and no. I modified your test slightly and added a print statement to machine_timer.c which every time the timer schedules the task it prints a line, and added the schedule time as argument to the scheduled function.

import time
from machine import Timer, idle
timer = Timer(0)

def wait(_):
    print("Callback at", time.ticks_ms(), "Scheduled ", _)
    time.sleep_ms(1000)

timer.init(period=200, mode=Timer.PERIODIC, callback=wait)

stop = time.ticks_ms() + 10000
while time.ticks_ms() < stop:
    idle()

timer.deinit()

Here it starts. The lines schedule at xxx/y are printed in the timer interrupt, and 1 or 0 tells whether the schedule was successful. You see that initially more tasks as scheduled while the first callback is running. If a certain limit of scheduled tasks is reached, the call to schedule() returns False..

schedule at 10429/1
Callback at 10430 Scheduled  10429
schedule at 10629/1
schedule at 10829/1
schedule at 11029/1
schedule at 11229/1
schedule at 11429/1
Callback at 11430 Scheduled  10629
schedule at 11629/1
schedule at 11829/1
schedule at 12029/1
schedule at 12229/1
schedule at 12429/0
Callback at 12430 Scheduled  10829
schedule at 12629/1
schedule at 12829/0
schedule at 13029/0
schedule at 13229/0
schedule at 13429/0
Callback at 13430 Scheduled  11029
schedule at 13629/1
schedule at 13829/0
schedule at 14029/0
schedule at 14229/0
schedule at 14429/0
Callback at 14430 Scheduled  11229
schedule at 14629/1
schedule at 14829/0
schedule at 15029/0
schedule at 15229/0
schedule at 15429/0
Callback at 15430 Scheduled  11429
schedule at 15629/1
schedule at 15829/0
schedule at 16029/0
schedule at 16229/0
schedule at 16429/0
Callback at 16431 Scheduled  11629
schedule at 16629/1
schedule at 16829/0
schedule at 17029/0
schedule at 17229/0
schedule at 17429/0
Callback at 17431 Scheduled  11829
schedule at 17629/1
schedule at 17829/0
schedule at 18029/0
schedule at 18229/0
schedule at 18429/0
Callback at 18431 Scheduled  12029
schedule at 18629/1
schedule at 18829/0
schedule at 19029/0
schedule at 19229/0
schedule at 19429/0
Callback at 19431 Scheduled  12229
schedule at 19629/1
schedule at 19829/0
schedule at 20029/0
schedule at 20229/0
schedule at 20429/0
Callback at 20431 Scheduled  12629
schedule at 20629/1
schedule at 20829/0
schedule at 21029/0
schedule at 21229/0
schedule at 21429/0
Callback at 21431 Scheduled  13629
>>> Callback at 22432 Scheduled  14629
Callback at 23433 Scheduled  15629
Callback at 24443 Scheduled  16629
Callback at 25453 Scheduled  17629
Callback at 26463 Scheduled  18629
Callback at 27473 Scheduled  19629
Callback at 28483 Scheduled  20629

[ma261065]

Thanks for the test .

So it looks like the queue tops out at 8 entries. This aligns with the #define MICROPY_SCHEDULER_DEPTH (8) entry in mpconfigport.h

From my understanding the mp_sched_schedule queue is used for a bunch of other stuff in MicroPython (e.g. I2S callback) so filling this queue up with useless timer callbacks is definitely a bad thing.

[robert-hh]

You can start the timer in ONE_SHOT mode and restart it in the callback again in this mode. Then you do not have to de-init it. Note that the argument to the timer callback is the timer instance, which can be used for that purpose.