MicroPython points in an interesting and long overdue direction in the embedded field: Simplicity and Directness! I'm thinking of the benefits of interpreted execution. And I believe this could be positive not only for hackers, makers, students and all the "new brew" folks in this field, but even the hard-boiled professionals, who - by all reports - could use a hand in getting the job done right!
So, kudos to Damien George for getting this project going, and thanks to Caleb for the article bringing some attention in this direction.
Hey... that's promising from the FAQ: "Micro Python also includes a complete compiler (which is why we can do the CALL_METHOD trick), whereas PyMite does not. Micro Python can compile to native machine code."
ref: Update #12. The C API appears to be very similar to normal Python's C extensions.
ref: Update #7. Inline assembler is a nice concept.
So in concept(python extension code reuse)... a bunch of methods which previously were residing in a python extension (written in C) could be directly compiled to run within the MicroPython environment... Assuming of course no hardware dependencies/incompatibilities...etc.
I'd like to play with this... it sounds promising.
I suspect the author is referring to writing python extensions. In the linux environment this is often compiled as a shared library with a glue layer interface written in C to bridge the environments. It's conceivable this could also be implemented on a uC. The code which needs to be optimized for speed could be compiled into the extension code library. I suspect there's a fair amount of effort for this.
Well, the BeagleBone has some real time options such as real time Linux (LinuxCNC has been ported), and no OS (using TI's StarterWare, although I haven't heard of anyone doing that.)
It also has a 200MHz co-processor (the PRU) that can toggle I/O's in the multi-megahertz range; several projects are using it for stepper motor control. On the other hand, I'm sure programming the PRU isn't as easy as Python.
If the Beagle group creates a new 'Bone based on TI's upcoming AM5x MPU,it'll have dual core ARM goodness.
Another interesting option (and one I'll probably try, since I already have a RPi) is combining the RPi with the XMOS startKit, which can definitely do very high speed bit-banging but should be easier to program than the PRU.
Frankly, for simple bit-banging pretty much any language will do; Python's advantages come when you take advantage of its dynamic capabilities.
This seems like it has the potential to run faster than current Python on something like the Pi/Beagle*. In the latter case, one is running Python in userspace and having to go through the kernel and/or filesystem to get at the pins (and probably the peripherals). MicroPython doesn't seem to have this (methinks substantial performance) limitation.
For 95+% of hobbyist/education applications either implementation is probably perfectly fine (most of which could probably run on a 1MHz 8080). For high-speed control, neither Python-based system would probably be able to cut it. It would depend entirely how any given application is partitioned, especially those that are running on top of an general-purpose OS. In these cases, MicroPython may have the edge. Moderate to high-speed control loops are probably iffy in both cases if the control comes back up into Python. However, if the on-chip peripherals (or support circuitry) can do all of the "real" control work autonomously, then it pretty much doesn't matter what's running on top of it.
One could almost certainly bit-bang stuff faster with MicroPython, but beyond that, I'm unsure that it's a clear winner for much else other than its lower-power operation. As is always the case, there are plenty more tools (debuggers, etc) that are going to run on the more PC-like Pi/Beagle* platforms than on the more deeply-embedded implementations -- which makes them substantially more usable for relative newbies.
The same basic argument holds for why the Pi won't/can't kill-off the Arduino -- for some things the latter just fits the problem better (at "1/500th of the performance" and 1/3 the price).
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.