[Python-ideas] millisecond and microsecond times without floats

[Paul Sokolovsky]

Hello,

On Wed, 24 Jun 2015 13:03:38 +0200
Antoine Pitrou <solipsis at 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 at gmail.com