-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
shared-bindings/time: introduce time.monotonic_ns #1290
Conversation
This is intended to be compatible with Python 3.7's time.monotonic_ns. The "actual resolution" is 1ms due to this being the unit at which common_hal_time_monotonic ticks. Closes adafruit#519
I have been running the following program on my m4 for a few hours:
The time values have gotten big enough that differences of exactly zero are frequently seen in floating point timestamps, while differences of just 1ms can still be seen in the new integral timestamp:
The values shown are the nanosecond time, the float-seconds time, and the difference between consecutive times from each function. Because of the limited precision of FP numbers, the smallest time differences are nearly 4ms apart, and will later be 8ms apart starting at around 16384 seconds. Meanwhile, there's no rounding of the nanosecond timestamps (though the program can't print fast enough to print every millisecond timestamp, so differences of 2000000 are sometimes seen as well) |
I'm ok with this. My one concern is if there are any gotchas in our 3.4 support that will break with folks using 3.7 instead of 3.4. Anyone know of any of these? |
https://docs.python.org/3.7/whatsnew/3.7.html I think biggest deal in 3.7 is: "the insertion-order preservation nature of dict objects has been declared to be an official part of the Python language spec". In other words regular dicts behave like OrderedDicts. They already did before 3.x but were not defined to be so. This behavior is not true in MicroPython/CircuitPython, and already didn't match the (not specified but existing) behavior before 3.7. So I'd say this is not something to worry about. Other interesting discussions: I like this PR. It's a step in the right direction -- we might add more later (finer resolution, some kind of timer class, etc.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jepler! You are awesome as always!
Hi Guys, I'm still a bit of a newb. I'd like to try this, but have no clue how. Is that something you could explain or point me to, please? I just tried updating a current program on my Itsy M4 of time.monotonics() to time.monotonic_ns(). I think I need to update something before this is going to work. That's where I am stumped (Mechanical guy in a software guy's world). Thanks, -Parsko |
@parskofamily Thanks for wanting to help! This is actually a pull request where @jepler imlemented it. Take a look at the "Files changed" tab to see how things were changed to add it. |
This is intended to be compatible with Python 3.7's time.monotonic_ns. The "actual resolution" is 1ms due to this being the unit at which common_hal_time_monotonic ticks.
Testing performed: I built a firmware for metro-m4-express and flashed it. I then verified that
time.monotonic_ns()
returns a value 1e9 times larger thantime.monotonic()
, and the type is (long) integer.I did not do any testing that long enough to measure the increased precision vs CircuitPython floats.
Naturally, this function is only enabled on boards which have long integer support.
Closes #519