extmod/utime_mphal: Factor out implementations in terms of mp_hal_* for reuse. #2514
Conversation
|
I had this refactor in mind for a year or so. Now that zephyr port is in queue, there's no excuse to not make it (indeed, proposed implementation of zephyr's utime module duplicates all standard implementations). |
|
How shall we handle negative args to sleep_XX functions? stmhal treats negative sleep as zero sleep. Is it up to the utime wrappers to check for negative values, or the port's mp_hal_sleep functions? Otherwise +1. But mind the build error, the file will need to be guarded by MICROPY_PY_UTIME, or something like that. |
Let's move them in here (as a next step), I'm happy to drop "undefined behavior" idea for them. |
Ok! |
…or reuse. As long as a port implement mp_hal_sleep_ms(), mp_hal_ticks_ms(), etc. functions, it can just use standard implementations of utime.sleel_ms(), utime.ticks_ms(), etc. Python-level functions.
|
Fixed and merged. |
As long as a port implement mp_hal_sleep_ms(), mp_hal_ticks_ms(), etc.
functions, it can just use standard implementations of utime.sleel_ms(),
utime.ticks_ms(), etc. Python-level functions.