8000 utimeq overflows after reaching 0x3fffffff, while ticks_ms values will grow larger · Issue #232 · pycom/pycom-micropython-sigfox · GitHub
[go: up one dir, main page]

Skip to content
This repository was archived by the owner on Sep 16, 2024. It is now read-only.

utimeq overflows after reaching 0x3fffffff, while ticks_ms values will grow larger #232

Closed
martijnthe opened this issue Dec 5, 2018 · 3 comments

Comments

@martijnthe
Copy link
Contributor

utimeq is mostly used in conjunction with ticks_ms() in uasyncio, where "timestamps" generated by ticks_ms() are passed into the queue to sort the elements in the queue.

What the problem is depends a bit on what you deem "correct". The values returned from ticks_ms() can grow larger than utimeq's fields to hold the time values. peektime() can only return values up to 0x3fffffff ((1 << 30) - 1).

If one attempts to use uasyncio on a Pycom board, sooner or later (after 12.42 days when the overflow happens) mayhem will happen because of this wrap-around...

I guess one fix would be to make ticks_ms() wrap at 0x3fffffff as well and fix ticks_diff() to return serial distance (taking wrap-arounds into account) -- see #231. Another could be to change utimeq to be able to handle larger time values.

Related issues: #231, #112.

cc @robert-hh @iwahdan88

@martijnthe martijnthe changed the title utimeq overflows after reaching 0x3fffffff, while ticks_ms values will grows larger utimeq overflows after reaching 0x3fffffff, while ticks_ms values will grow larger Dec 5, 2018
@martijnthe
Copy link
Contributor Author

Part of the problem: micropython/micropython#4336

@robert-hh
Copy link
Contributor

See alsomy comment here: #231

@husigeza
Copy link
Contributor
husigeza commented Jan 5, 2019

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
0