Hello, On Thu, 25 Jun 2015 22:56:59 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 24 June 2015 at 21:38, Paul Sokolovsky <pmiscml@gmail.com> wrote:
On Wed, 24 Jun 2015 13:03:38 +0200 Antoine Pitrou <solipsis@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@gmail.com