Maximum possible machine.Timer period

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
User avatar
pythoncoder
Posts: 3538
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Maximum possible machine.Timer period

Post by pythoncoder » Tue Sep 04, 2018 5:39 pm

With soft timers the rules for hardware interrupts don't apply: callbacks occur when the VM is idle. Using .schedule won't do any harm and will enable you to use a hardware timer without changing code.
Peter Hinch

jickster
Posts: 629
Joined: Thu Sep 07, 2017 8:57 pm

Re: Maximum possible machine.Timer period

Post by jickster » Tue Sep 04, 2018 5:41 pm

pythoncoder wrote:
Tue Sep 04, 2018 5:39 pm
With soft timers the rules for hardware interrupts don't apply: callbacks occur when the VM is idle. Using .schedule won't do any harm and will enable you to use a hardware timer without changing code.
That doesn't help him solve his problem.

jickster
Posts: 629
Joined: Thu Sep 07, 2017 8:57 pm

Re: Maximum possible machine.Timer period

Post by jickster » Tue Sep 04, 2018 5:45 pm

pythoncoder wrote:
Tue Sep 04, 2018 5:39 pm
callbacks occur when the VM is idle
They occur when the bytecode is "jump" which is not the same as "idle".

jickster
Posts: 629
Joined: Thu Sep 07, 2017 8:57 pm

Re: Maximum possible machine.Timer period

Post by jickster » Tue Sep 04, 2018 6:44 pm

neurino wrote:
Tue Sep 04, 2018 3:30 pm
jickster wrote:
Mon Sep 03, 2018 10:20 pm

Those numbers don't stand out to me.
I think something else is going on.

Do you have access to a C-debugger?
Sorry, no debugger,

haven't anyone out there been able to reproduce the issue?

I mean someone with an ESP8266 ruing these few lines and seeing if he gets timer_cb called or not after 6 minutes (480000ms)

Code: Select all

import machine
import micropython

def timer_cb(timer):
  print('here', timer)

period = 480000
timer = machine.Timer(-1)
timer.init(period=period, 
  callback=lambda timer: micropython.schedule(timer_cb, timer),
  mode=machine.Timer.PERIODIC)
On my side, I started relying on a DS3231 alarm to trigger my hourly job, however getting this fixed would really help in other projects.
I looked in the C-source.

(1) a virtual timer isn't supported. Note how the code below doesn't care about your (-1).

Code: Select all

STATIC mp_obj_t esp_timer_make_new(const mp_obj_type_t *type, size_t n_args, size_t n_kw, const mp_obj_t *args) {
    mp_arg_check_num(n_args, n_kw, 1, 1, false);
    esp_timer_obj_t *tim = m_new_obj(esp_timer_obj_t);
    tim->base.type = &esp_timer_type;
    return tim;
}
This probably isn't related to your problem.

User avatar
vdb_peter
Posts: 6
Joined: Mon Feb 11, 2019 12:51 am
Location: Melbourne

Re: Maximum possible machine.Timer period

Post by vdb_peter » Mon Feb 11, 2019 1:03 am

Hi. Was a maximum Period value found (It needs to be added to the documentation!)? I'm experiencing the same with the difference of using a hw timer. I started off with the equiv of 12 hours (callback function not called), and then 21610000 (~6 hours) with the same result. It works when I use a short period such as the equiv of a few minutes. Thanks

User avatar
vdb_peter
Posts: 6
Joined: Mon Feb 11, 2019 12:51 am
Location: Melbourne

Re: Maximum possible machine.Timer period

Post by vdb_peter » Wed Feb 13, 2019 4:19 am

Hi all
The MAXIMUM value is 6870947 (1:54:30.947). I tested and verified on uPython 1.9.4 ESP8266. >=6870948 does NOT work. (My source came from Lua: https://nodemcu.readthedocs.io/en/maste ... mer-module. Lua Timer (tmr.interval) initialises in a similar way to uPython.)

I wanted a 12 hour timer (~42610000).

What I'd like to know and understand is what is limiting it.

By my reading (and I'm not a C coder), "period" is defined as a 32bit integer. That makes the decimal number approx 4.3G, somewhat larger than necessary.

https://github.com/micropython/micropyt ... dmachine.c

STATIC mp_obj_t esp_timer_init_helper(esp_timer_obj_t *self, size_t n_args, const mp_obj_t *pos_args, mp_map_t *kw_args) {
enum {
ARG_mode,
ARG_callback,
ARG_period,
ARG_tick_hz,
ARG_freq,
};
static const mp_arg_t allowed_args[] = {
{ MP_QSTR_mode, MP_ARG_KW_ONLY | MP_ARG_INT, {.u_int = 1} },
{ MP_QSTR_callback, MP_ARG_KW_ONLY | MP_ARG_OBJ, {.u_obj = mp_const_none} },
{ MP_QSTR_period, MP_ARG_KW_ONLY | MP_ARG_INT, {.u_int = 0xffffffff} },
{ MP_QSTR_tick_hz, MP_ARG_KW_ONLY | MP_ARG_INT, {.u_int = 1000} },

So, perhaps there's a hardware limit somewhere, but I couldn't find anything about it at Espressif or their forums. Hopefully someone knows the significance of this hard limit, and is willing to explain.

Looking at the MicroPython C code for the ESP32 Timers, looks like the Timer Periods are 64 bit integers:
https://github.com/micropython/micropyt ... ne_timer.c
typedef struct _machine_timer_obj_t {
mp_obj_base_t base;
mp_uint_t group;
mp_uint_t index;

mp_uint_t repeat;
// ESP32 timers are 64-bit
uint64_t period;

mp_obj_t callback;

intr_handle_t handle;

Has anyone discovered a hard limit to the Timer Period on the ESP32?

Peter

Post Reply