Hello, On Wed, 24 Jun 2015 13:03:38 +0200 Antoine Pitrou <solipsis@pitrou.net> wrote: []
Because MicroPython stays close (== may stay close) to hardware and does not depend on any OS (even those smaller embedded OSes, which are called RTOS'es). Then, it's usual case for embedded hardware to have hardware timers of the same size or smaller as the architecture machine word. For example, on a 32-bit CPU, timers are usually 32-, 24-, or 16- bit. On 16-bit CPUs, timers are 16- or 8-bit.
I don't think such timers have a place in the CPython standard library, though.
They don't, that was said in the very first message. They do have their place in MicroPython's stdlib and arguably in any other embedded Python's stdlib. There're number of embedded Python ports, I don't know if they tried to address to wider Python community regarding aspects peculiar to them. As you can see, we try to do the homework on our side.
Don't you have an additional namespace for micropython-specific features?
I treat it as a good sign that it's ~8th message in the thread and it's only the first time we get a hint that we should get out with our stuff into a separate namespace ;-). But of course, digging own hole and putting random stuff in there is everyone's first choice. And MicroPython has its "catch-all" module for random stuff imaginatively called "pyb", and in (user-friendly) embedded, the de-facto API standard is Arduino's, so that's what taken as a base for function names. So, MicroPython currently has: pyb.delay(ms) pyb.udelay(us) pyb.millis() pyb.micros() pyb.elapsed_millis() pyb.elapsed_micros() As can be seen, while these deal with time measurement/delays, they have little in common with how Python does it. And the main question we seek to answer is - what's more beneficial: to keep digging own hole or try to take Python's API as a close affinity (while still adhering to requirements posed by embedded platforms).
Regards
Antoine.
-- Best regards, Paul mailto:pmiscml@gmail.com