[Python-ideas] millisecond and microsecond times without floats

[Paul Sokolovsky]

Hello,

On Thu, 25 Jun 2015 22:56:59 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 24 June 2015 at 21:38, Paul Sokolovsky <pmiscml at gmail.com> wrote:
> > On Wed, 24 Jun 2015 13:03:38 +0200
> > Antoine Pitrou <solipsis at pitrou.net> wrote:
> >> 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 ;-).
> 
> We hadn't previously gotten to the fact that part of your motivation
> was helping folks learn the intricacies of low level fixed width time
> measurement, though.

Well, Python is nice teaching language, and a lot of embedded
programming can be done with just GPIO control (i.e. being able to
control 1/0 digital signal) and (properly) timed delays (this approach
is know as https://en.wikipedia.org/wiki/Bit_banging). Then if keeping
it simple and performant we let people do more rather than less with
that. So, yes, learning/experimentation is definitely in scope of this
effort.

People may ask what all that has to do with very high-level language
Python, but I have 2 answers:

1. Languages like JavaScript or Lua have much more limited type model,
e.g. they don't even have integer numeric type per se (only float), and
yet their apologists don't feel too shy to push to use them for
embedded hardware programming. Certainly, Python is not less, only more
suited for that with its elaborated type model and stricter typedness
overall.

2. When I started with Python 1.5, I couldn't imagine there would be
e.g. memoryview's. And yet they're there. So, Python (and people behind
it) do care about efficiency, so it shouldn't come as surprise
special-purpose Python implementation cares about efficiency in its
niche either.

> That's actually a really cool idea - HC11 assembly programming and TI
> C5420 DSP programming are still two of my favourite things I've ever
> done, and it would be nice if folks could more easily start exploring
> the mindset of the embedded microprocessor world without having to
> first deal with the incidental complexity of emulators or actual
> embedded hardware (even something like programming an Arduino directly
> is more hassle than remote controlling one from a Raspberry Pi or PC).

Thanks, and yes, that's the idea behind MicroPython - that people new
embedded programming could starter easier, while having chance to learn
really cool language, and be able to go into low-level details and
optimize (in my list, Python is as friendly to that as VHLL may be).
And yet another idea to make MicroPython friendly to people who know
Python and wanted to play with embedded. Making it play well for these
2 user groups isn't exactly easy, but we'd like to try.

> Unfortunately, I can't think of a good alternative name that isn't
> ambiguous at the CPython layer - embedded CPython is very different
> from an embedded microprocessor, utime is taken, and microtime is
> confusable with microseconds.

You mean POSIX utime() function, right? How we have namespacing
structured currently is that we have "u" prefix for all important
buildin modules, e.g. uos, utime, etc. They contain bare minimum, and
then fuller standard modules can be coded in Python. So, formally
speaking, on our side it will go into separate namespace anyway. It's
just we treat "utime" just as an alias for "time", and wouldn't like to
put there something which couldn't be with clean conscience submitted
as a PEP (in some distant future).

> I'm tempted to suggest calling it "qtime", and using TI's Q notation
> to denote the formats of numbers:
> https://en.wikipedia.org/wiki/Q_%28number_format%29
> 
> That would conflict with your notion of making the APIs agnostic as to
> the exact bitwidth used, though, as well as with the meaning of the
> "q" prefix in qmath: https://pypi.python.org/pypi/qmath

Yes, exact fixed-point nature of "Q" numbers doesn't help here, but as
a designator of a special format it's pretty close to the original idea
to use "_ms" and "_us" suffixes, so I treat that as a sign that we're
on the right track.

I however was thinking about our exchange with Antoine, and his
surprise that we don't want to use 64-bit value. I guess I nailed the
issue: I selected "monotonic()" because it seemed the closest to what we
need, and in my list, our stuff is still "monotonic" in a sense that it
goes only forward at constant pace. It just wraps around because so is
the physical nature of the underlying fixes-size counter. Apparently,
such "extended" treatment of "monotonic" is confusing for people who
know time.monotonic() and PEP418.

So, looks like we'll need to call our stuff different, I'm going to
propose ticks_ms() and ticks_us() for MicroPython (hopefully "ticks"
it's a well-known embedded term, and intuitive enough for other folks,
at the very least, it's better than Linux kernel's jiffies ;-) ).


> Cheers,
> Nick.

-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com