One interesting claim made by damien is that you can accelerate parts of your code to a speed pretty close to C. Another claim is that this fits some real time applications even thought this has a garbage collector.
If this all works out , this might an interesting platform for low/mid volume production. Maybe.
@alex-m1 : I think it could be a good school platform project, but it will take some time for community buildup.
I like the idea of it working with just a connection to the PC, even down to the command line capability.
For me as a dedicated bit banger of Atmel chips and home brew computers along with salvaging BBC B and Acorns of all types, I have been uninspired by the Raspberry Pi. It is probably just me, but the Pi has not got me going. This Micropython sits well with what I like to do with electronics, especially as it will sit on a breadboard.
Arduino boards are good and I await my Microduino kit with excitement ( another kickstarter project).
I will try to give both these boards a blog on how easy they are to use via EE-Times if Max or one of the other editors are interested?
Likewise I am not connected with Damien George but I do want to see good easy to use electonic kits available to the beginners in Electronics.
I had World War II government surplus electtronics, to play with as a kid growing up.
I was rubbish at academic studies, but could learn anything if I could work with it hands on, this gave me the chance I needed to get into electronics. I want to see other kids get the same start.
@alex_m1: "If this all works out , this might an interesting platform for low/mid volume production"
I'm pretty certain that for education this kind of boards+Python will find a way in for helping students in the programming skills development process, or even for pushing their creativity to new limits. But for commercial products some other aspects dominate, not the possibility of running Python.
If you can get the performance you need with one sub-1.5$ 25MHz microcontroller (programming natively in optimized 'C'), why should you move to one bigger and power hungry over-3$ MCU running at over 100MHz just for being able to program in Python?
@alex_m1: "What about reliability, time to market, cost of development , risk minimization(when you don't know how much first version would sell), ability of domain experts to develop . Aren't those important ?"
Yes, I agree with you on that, they are all also of great importance. In fact those factors constitute also key aspects to take into account before even typing the first key for the first line of code.
Deciding which target platform, programming language and development environment to use in the project is part of the first stage in the development cycle.
@alex_m1: "And you can always port to c in V2 , if it makes sense" but Python is so different from C that 'port' in this case means 'rewrite'.
Anyway, programming in Python is some times so easy that you could use it for testing part of an algorithm or for writing one test-bench that could be of great help while testing or debugging bigger or more complex systems.
I agree with you, it could fit some applications and products.
@alex_m1: "And you can always port to c in V2 , if it makes sense."
Do you mean to rewrite C? This project involved rewriting Python from scratch, so just study C and realize that a uC takes too many cycles to do anything useful for C execution and then consider what is necessary to actually execute C syntax.
The claim is lean and fast enough to run on a micro, but still not as fast as C.
C already runs on practically all uC's, but is not really fast. If you want a lean fast C, look at the fundamental structure of C and you will find that a uC is not needed if you have an FPGA with true dual port block RAM. Then apply some bit significant micro-code and with 4 rams and a couple of hundred LUTs a design that minimizes the number of clock cycles can out run any embedded uC.
@alex_m1. "Another claim is that this fits some real time applications even thought this has a garbage collector". It's a little bit hard/difficult to see how it could fit in real-time applications. Real-time specifications are sometimes difficult to achieve even for skilled developers programming in C.
I'm tempted to back it just to see how well the developer can deliver on his promises; for one, he seems to have a physics background, not a programming background, and it takes a fair amount of knowledge to write a good programming language implementation. It's not the first Python on a microcontroller project (PyMite was first), but it's definitely the most ambitious.
I like Python, and have used it on production systems. It has a comfortable syntax, a lot of support, interfaces well with many other programming languages (C or C++ plus a higher level language such as Python or Lua is a good way to develop) and "batteries are included".
But Python is a bit of a pig: it's pretty big and not too fast; to get an idea, have fun at the Computer Language Shoot, e.g. for Python vs C and Python vs Lua, and here's Lua vs LuaJIT. I don't think you're going to get C speeds from Python any time soon.
I've played a bit with eLua, and I'm curious to see how eLua on, say, a STM32F4 Discovery board compares to MicroPython.
Another issue "price compression" from boards such as the RPi and especially the Beagle. At its current backer price, the MicroPython board is ~$40, while the BeagleBone Black is $45, and can run full Python or LuaJIT, has some pretty nice peripherals, and an expanding ecosystem.
@TonyTib Price compression is an issue, but if you look at component costs , the components for a minimal beagle cost at aroung $20 while for a micro python minimal components costs are less than $5(for an optimized mcu), And it's much it's easier/cheaper to design the circuit for micro python.
Elua: The micro python developeer claims an option to be close to c speed. I don't think elua is close to that. But benchmarks would be interesting , sure.
Regarding elua: i always thought it was a very interesting project, but they were not very sucsessfull at building a community, and collaborating with other communities. My guess is that if they had ported elua over the mbed libraries , with an easy to use c++ api , and define themself as the glue language , there might have been more sucsessfull in building a community. But that's just my 2 cents.
I'm very doubtful that MicroPython will be anywhere close to C speeds for real world applications. Regular Python isn't, although it can be fast enough, especially when used with other languages (e.g. NumPy, where most of the time is spent in optimnized C code or on my machine: Python is the flexible, top level; the real time stuff is done on dedicated DSPs programmed in C).
I'm also curious about size; if you use something like Py2exe, the result is typically in the multi-megabyte range. Maybe a SD card will be required...
eLua was started way before the mbed existed, and it does have a pretty wide reach (TI Stellaris & Tiva, Atmel AVR32 & SAM7, ST STM32, etc), so while it hasn't taken off like Arduino (what else has?), it's still alive and kicking, and has its place, as does the PicAxe, .NET MF chips, and such.
This is a special version of python so you can't compare it to standard python. Author claims no need for external memory using the stm32f405.
By reading the technical details , the author seems to know what he is talking about, and he explains in detail including assembly code how can this achieve c like speed. Regarding real world usage, of course will have to see.
I think author has good intentions, but I still suspect the real world is more complicated than expected; after all, in software development, the last 10% takes 50% of the time! So I have sneeking suspicion that it'll be hard to implement ALL Python 3 features (although Python is simple compared to C++, it's complex compared to compact languages such as Io or Lua).
I'd be more optimistic if he had a visible track record, although I give him credit for some realism ("close to C speed in tight loops with integers..." -- like I've said, standard Python can get close to C speed (e.g. matrix math in NumPy), if it spends most of its time calling optimized C routines).
I don't know about this -- but I do know that the folks at Synapse Wireless use Python to create applications for their low-power wireless modules, and that they say their wireless stack, including the Python virtual machine, has a memory footprint of only ~40KB
SNAPpy is more like PyMite: only the VM in on chip (no interepreter, so not at all comparable to full Python, MicroPython, or eLua) and it's a very limited subset of Python -- the same nice syntax, but missing (IMHO, since I love lists, functional programming and metaprogramming) most of the good parts.
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).
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.
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.
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.
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.