does time.monotonic() have a unit?

[ericwertz]

I cannot tell from the documentation for time.monotonic() if it has units or not -- like seconds or milliseconds, etc.

I'm wondering if this function can be used for measuring time deltas (like Arduino's millis()) or if it can only be used for ordering events time relative to each other. It seems like the former since it has gone to the trouble of being a float, whereas integers would suffice were it (only) the latter.

[ladyada]

its in seconds and fractions thereof. good for both cases, its monotonic, like millis() since last hardware reset :)

[tannewt]

Note, we also support time.monotonic_ns() which will be a long int. In practice it will have millisecond resolution due to the way we track time internally.

[stevewells20]

It seems very strange to choose the function monotonic_ns() when you cannot achieve nanosecond resolution. What is the point of using ns, rather than ms. monotonic_ns() gives the user the immediate impression that the function provides nanosecond resolution; what else could it mean? Why else does it exist?

A compounding issue is that the resolution restriction is not documented in the circuitpython docs, along with the unit that time.monotonic() yields.

[dhalbert]

These functions also exist in "regular" Python: https://docs.python.org/3/library/time.html?highlight=monotonic_ns#time.monotonic. The documentation is similarly vague 🙂. Please do open a new issue if you would like improved documentation. In practice, the resolution is not going to be nanoseconds, but it depends on the particular board.

[stevewells20]

Ah, thank you! I actually have never seen time.monotonic_ns() in Python3 before, so I assumed it was a CircuitPython specific function. I was just using it to benchmark a sampling rate, and realized the output was too chunky by about 3 orders of magnitude. Yes, I'll open an issue shortly about the documentation; as CircuitPython is geared more towards beginners, it seems important to equip them with details of function inputs and outputs.

[dhalbert]

In general, any module in CircuitPython whose name matches a CPython (regular Python) module has an API that is the same or a subset of the CPython API. This way people can write programs in CircuitPython and expect them to run on CPython if they use the standard CPython modules. This is unlike MicroPython, which feels free to alter the CPython API. In the past, MicroPython prefixed their modules with "u" (like ujson) to indicate they were not compatible with CPython, but they are moving away from that naming scheme.

[stevewells20]

I've used MicroPython quite a bit, which is probably why I was confused. Very unfortunate that they are moving away from that; It makes sense that a domain specific language (or branch) would provide different functionality and toolsets than one for general computing, but this comes with the requirement that nomenclature indicates the difference between the parent language and the domain specific language. As I'm just starting to look into CircuitPython, I find it an interesting middle ground, that instead of branching out with additional functionality specifically for microcontrollers, filters the parent language's functions to provide a smaller and more focused set of tools. Very good environment for learning and focusing on core algorithm design! Thank you for your information and responsiveness, dhalbert.