utime: ticks_diff() raises an exception with large values returned by ticks_us() or ticks_ms()

[robert-hh]

The functions utime.ticks_us() and utime.ticks_ms() may return values, which then cannot be used as input for utime.ticks_diff(). Example:

>>> time.ticks_us()
3636776263
>>> time.ticks_diff(time.ticks_us(), time.ticks_us()+1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: overflow converting long int to machine word
>>> 

The reason is, that the return values are not stripped to values which can be representef by a MP_SMALL_INT, or at least 31 bit.
Edit: Funny enough, the utime module is mostly implemented twice, in esp32/mods/modutime.c and in py/extmod/mphal_utime.c, where the latter seems to have proper value/overflow handling.

[robert-hh]

Made a PR attemting to fix that issue.

[robert-hh]

This simple script will trigger an exception latest after about 35 minutes.

import utime

new = utime.ticks_us()
while True:
    utime.sleep(1)
    old = new
    new = utime.ticks_us()
    print(new, utime.ticks_diff(old,new))

[robert-hh]

Actually the minimal change to fix that is to modify ticks_diff() as:

STATIC mp_obj_t time_ticks_diff(mp_obj_t start_in, mp_obj_t end_in) {
    int32_t start = mp_obj_get_int_truncated(start_in);
    int32_t end = mp_obj_get_int_truncated(end_in);
    return mp_obj_new_int((end - start));
}
STATIC MP_DEFINE_CONST_FUN_OBJ_2(time_ticks_diff_obj, time_ticks_diff);

This change will also return a reasonable behavior, if the arguments of the call are swapped - sign change. The only deviating result is achieved with ticks_diff(0x80000000, 0), and ticks_diff(0, 0x8000000), which return the same value -2147483648

[robert-hh]

Thanks for merging.