MicroPython • Re: time.sleep() oddities

Problem is probably due to this ... https://github.com/micropython/micropyt ... /modtime.c ... and we have millisecond granularity. I guess they don't expect folks to use time.sleep() for under 1 ms timings.

Perhaps so, but that's a ridiculous implementation if you ask me. And I am not sure exactly what it's doing with such random and unpredictable results.

Doing an alarm event delay for anything above a millisecond and more accurate cycle count or polled timer delay for less is common practice, and it's usually acceptable to round to four significant digits to avoid unnecessary cycle count or polled timer delays, so I don't know why they didn't do that.

I guess one problem is the MicroPython team aren't RP2 experts. They also have this dogmatic 'lowest common denominator' approach which is why we can't have float PWM frequencies even though the RP2 is quite capable of them.

Aren't print and format going to affect timings?

No, I note the time before and immediately after the sleep and only then do the slower and variable time 'print' and 'format'. I don't consider timer wraparound but do print both start and end values so I can tell when that has happened.

As a matter of curiosity do you get similar resukts using ... time.sleep_ms() ... instead?

The 'time_ms' doesn't allow sub-milliseconds so that's no use here, but 'time_us' does seem to work -That's in line with what I was expecting; a fairly accurate delay plus a few tens of microseconds of overhead.

I am guessing that for 2 ms, and probably above, it splits those into an alarm timer chunk and whatever is left over. That's what I would have expected for all the sleeps.

Thanks everyone.

Statistics: Posted by hippy — Fri Nov 07, 2025 7:23 am

---