Skip to content
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.

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

utime.ticks_diff() should handle wrap-arounds #231

Closed
martijnthe opened this Issue Dec 5, 2018 · 6 comments

Comments

Projects
None yet
4 participants
@martijnthe
Copy link

martijnthe commented Dec 5, 2018

The original utime.ticks_diff from micropython supports handling wrap-arounds / roll-overs using serial distance: https://docs.micropython.org/en/latest/library/utime.html#utime.ticks_diff

In the Pycom implementation this has been removed (in favor of supporting diffing usec-accuracy timestamps?).

This seem like a bad idea to me because it breaks API compatibility with micropython.
For example, uasyncio relies on utime.ticks_diff. Right now the uasyncio scheduler will start to malfunction after 12.42 days of uptime...

cc @iwahdan88 @robert-hh

@robert-hh

This comment has been minimized.

Copy link
Contributor

robert-hh commented Dec 8, 2018

ticks_diff() handles wrap-arounds. It's only that ticks_ms() and ticks_us() overflow at 0xffffffff. uasyncio expects the overflow at 0x3fffffff. In micropython.org, where utimeq comes form, ticks_ms() overlows at 0x3fffffff. So these two have to be matched. It seems easier to do that in the ticks domain, because ticks_ms() and ticks_us() are not guaranteed to overflow at a certain value. It's only certain that they will.

@martijnthe martijnthe closed this Dec 8, 2018

@martijnthe martijnthe reopened this Dec 8, 2018

@martijnthe

This comment has been minimized.

Copy link
Author

martijnthe commented Dec 8, 2018

ticks_diff() handles wrap-arounds

I don’t see anything in the code that accounts for it. I just see a substraction. What am I missing?

I ended up creating a work around in .py that masks the ticks_ms() time as well as forces the value to be a small int using the hash() function. Super gross hacky workaround but it works...

@martijnthe

This comment has been minimized.

Copy link
Author

martijnthe commented Dec 8, 2018

Tangentially: I think it would be better to change ticks_...() to also wrap at 0x3fffffff. Aside of the compatibility with original MicroPython another downside of the current implementation is that values above 0x3fffffff get heap allocated, instead of being efficient “small ints”.

@robert-hh

This comment has been minimized.

Copy link
Contributor

robert-hh commented Dec 10, 2018

It is relatively easy to revert back to the methods of the MicroPython.org version. The code is still there in extmod/utime_mphal.c and just has to be enabled. Add to mpconfigport.h the line:

#define MICROPY_PY_UTIME_MP_HAL                     (1)

and change the QSTR definition list at the end of esp32/mods/modutime.c into:

    { MP_OBJ_NEW_QSTR(MP_QSTR_localtime),           (mp_obj_t)&time_localtime_obj },
    { MP_OBJ_NEW_QSTR(MP_QSTR_gmtime),              (mp_obj_t)&time_gmtime_obj },
    { MP_OBJ_NEW_QSTR(MP_QSTR_mktime),              (mp_obj_t)&time_mktime_obj },
    { MP_OBJ_NEW_QSTR(MP_QSTR_sleep),               (mp_obj_t)&mp_utime_sleep_obj },
    { MP_OBJ_NEW_QSTR(MP_QSTR_sleep_ms),            (mp_obj_t)&mp_utime_sleep_ms_obj },
    { MP_OBJ_NEW_QSTR(MP_QSTR_sleep_us),            (mp_obj_t)&mp_utime_sleep_us_obj },
    { MP_OBJ_NEW_QSTR(MP_QSTR_ticks_ms),            (mp_obj_t)&mp_utime_ticks_ms_obj },
    { MP_OBJ_NEW_QSTR(MP_QSTR_ticks_us),            (mp_obj_t)&mp_utime_ticks_us_obj },
    { MP_OBJ_NEW_QSTR(MP_QSTR_ticks_cpu),           (mp_obj_t)&mp_utime_ticks_us_obj },
    { MP_OBJ_NEW_QSTR(MP_QSTR_ticks_add),           (mp_obj_t)&mp_utime_ticks_add_obj },
    { MP_OBJ_NEW_QSTR(MP_QSTR_ticks_diff),          (mp_obj_t)&mp_utime_ticks_diff_obj },
    { MP_OBJ_NEW_QSTR(MP_QSTR_time),                (mp_obj_t)&time_time_obj },
    { MP_OBJ_NEW_QSTR(MP_QSTR_timezone),            (mp_obj_t)&time_timezone_obj },

Also add the needed declarations to esp32/mods/modutime.c with:

#include "extmod/utime_mphal.h"

The respective ticks... and sleep... functions in esp32/mods/modutime.c can then be removed or undef'ed.
Note: That will also change back the argument order of ticks_diff. But that was changed in v1.20.0.rc0 anyhow.

@robert-hh

This comment has been minimized.

Copy link
Contributor

robert-hh commented Dec 14, 2018

There is just on "property" with these genuine implementations of ticks_diff() and ticks_add(). The "time" arguments must be short int's. There is no conversion in the functions which convert other int formats. So the arguments must either come from one of the ticks_xx calls, or be a constant smaller than 1,073,741,824. Since that is the intended use, it's not real limitation, and since these functions are often used in tight loops, there is a speed advantage. It just came to my eyes when testing the adapted code and puzzled me for a while.

@husigeza

This comment has been minimized.

Copy link
Contributor

husigeza commented Jan 5, 2019

Hello!
PR235 will fix this problem, thanks @robert-hh for the fix.

@iwahdan88 iwahdan88 closed this Mar 1, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.