Design Con 2015
Breaking News
View Comments: Threaded | Newest First | Oldest First
alex_m1
User Rank
CEO
Micropython
alex_m1   12/2/2013 6:44:16 PM
NO RATINGS
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.

Cuno
User Rank
Rookie
Re: Micropython
Cuno   12/3/2013 5:19:58 AM
NO RATINGS
168 MHz Cortex-M4 with 192 KB RAM similar to Arduino? Not really, at least not to the original kind of Arduinos.

Btw, Telit has shipped GSM modules with Python support for many years.

alex_m1
User Rank
CEO
Re: Micropython
alex_m1   12/3/2013 5:57:01 AM
NO RATINGS
@cuno Cortex-m4  + 200K ram/1mb external flash start at $3.3 using lpc43xx. Toghether with fast python, this could fit low/mid volume.

And certainly this could compete with arduino. And the telit python modules are pretty expensive and slow i believe.

Crusty1
User Rank
CEO
Re: Micropython
Crusty1   12/3/2013 7:02:48 AM
NO RATINGS
Just put in my pledge to back this, as it looks like a good starter platform and a bit more open than the Pi.

Should be a good schools project platform?

alex_m1
User Rank
CEO
Re: Micropython
alex_m1   12/3/2013 7:10:48 AM
NO RATINGS
@Crusty:I think it could be a good school platform project, but it will take some time for community buildup.

Cool you've backed it up. BTW , i'm not the owner just someone who,likes to see this sucseed.

 

 

Crusty1
User Rank
CEO
Re: Micropython
Crusty1   12/3/2013 8:30:26 AM
NO RATINGS
@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
User Rank
CEO
Re: Micropython
alex_m1   12/3/2013 4:54:56 PM
NO RATINGS
@Crusty , definetly , this could be a great learning tool.

Also ,This could let all kinds of people create unqiue stuff, and even sell it. This potential is what excites me the most.

Caleb Kraft
User Rank
Blogger
Re: Micropython
Caleb Kraft   12/3/2013 9:26:30 AM
NO RATINGS
Python is so easy to learn, I could see a lot of potential here.

Crusty1
User Rank
CEO
Re: Micropython
Crusty1   12/3/2013 9:34:27 AM
NO RATINGS
@Caleb: I think with it's instant on and Python on line, so to say, that this will be a very good way to get to grips with learning Python.

 

Victor Lorenzo
User Rank
Rookie
Re: Micropython
Victor Lorenzo   12/4/2013 2:39:45 AM
NO RATINGS
@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?

sa_penguin
User Rank
Manager
Re: Micropython
sa_penguin   12/4/2013 4:49:16 AM
NO RATINGS
Actually, I'd like to see this attached to a small custom keyboard, LCD display and battery. Provided you aren't limited to Python, you could probably make a pretty good calculator.

Check the DM-15CC (clone of HP-15C) to see what can be done with an ARM CPU.

alex_m1
User Rank
CEO
Re: Micropython
alex_m1   12/4/2013 5:56:46 AM
NO RATINGS
@Victor lorenzo:


>> But for this commercial products some other aspects dominate

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 ?


In some products , those factors might be more important than the $2 difference.

And you can always port to c in V2 , if it makes sense.

Victor Lorenzo
User Rank
Rookie
Re: Micropython
Victor Lorenzo   12/4/2013 6:03:40 AM
NO RATINGS
@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.

Victor Lorenzo
User Rank
Rookie
Re: Micropython
Victor Lorenzo   12/4/2013 6:07:44 AM
NO RATINGS
@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.

KarlS01
User Rank
Manager
Re: Micropython
KarlS01   12/4/2013 11:52:05 AM
NO RATINGS
@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
User Rank
CEO
Re: Micropython
alex_m1   12/4/2013 12:42:33 PM
NO RATINGS
@KarlS01:

My remark was more in the context of memory/cost.

Victor Lorenzo
User Rank
Rookie
Re: Micropython
Victor Lorenzo   12/4/2013 3:09:14 AM
NO RATINGS
@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.

Crusty1
User Rank
CEO
Re: Micropython
Crusty1   12/4/2013 3:27:39 AM
NO RATINGS
@All: At kickstarter they have reached thier 1000's backer and second streteched goal so it looks like it will have quite a support team when it lands on the ground.

TonyTib
User Rank
CEO
Hmmm, we'll see
TonyTib   12/3/2013 6:48:55 PM
NO RATINGS
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.

alex_m1
User Rank
CEO
Re: Hmmm, we'll see
alex_m1   12/4/2013 5:37:01 AM
NO RATINGS
@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.

TonyTib
User Rank
CEO
Re: Hmmm, we'll see
TonyTib   12/4/2013 12:13:58 PM
NO RATINGS
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.





alex_m1
User Rank
CEO
Re: Hmmm, we'll see
alex_m1   12/4/2013 12:49:12 PM
NO RATINGS
@TonyTib


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.

TonyTib
User Rank
CEO
Re: Hmmm, we'll see
TonyTib   12/4/2013 1:22:18 PM
NO RATINGS
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).

alex_m1
User Rank
CEO
Re: Hmmm, we'll see
alex_m1   12/4/2013 2:06:58 PM
NO RATINGS
@TonyTib,

>> the last 10% takes 50% of the time!

You are lucky. For us the last 10% of the time takes 90% of the time!


:)

Max The Magnificent
User Rank
Blogger
Re: Hmmm, we'll see
Max The Magnificent   12/4/2013 3:03:36 PM
NO RATINGS
@alex_m1: For us the last 10% of the time takes 90% of the time!

How very Zen of you :-)

alex_m1
User Rank
CEO
Re: Hmmm, we'll see
alex_m1   12/4/2013 3:33:04 PM
NO RATINGS
@Max , it's not zen, it's from the monty python four yorksheermen sketch.

https://www.youtube.com/watch?v=Xe1a1wHxTyo

Max The Magnificent
User Rank
Blogger
Re: Hmmm, we'll see
Max The Magnificent   12/4/2013 3:49:27 PM
NO RATINGS
@Alex_m1: @Max , it's not zen, it's from the monty python four yorksheermen sketch.

On what planet? I am a Yorkshire man -- we used to dream of 10%... LOL

alex_m1
User Rank
CEO
Re: Hmmm, we'll see
alex_m1   12/4/2013 4:06:24 PM
NO RATINGS
LOL.

Max The Magnificent
User Rank
Blogger
Re: Hmmm, we'll see
Max The Magnificent   12/4/2013 12:53:48 PM
NO RATINGS
@TonyTib: I'm also curious about size...

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

TonyTib
User Rank
CEO
Re: Hmmm, we'll see
TonyTib   12/4/2013 1:11:06 PM
NO RATINGS
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.

TonyTib
User Rank
CEO
Re: Hmmm, we'll see
TonyTib   12/11/2013 12:30:30 PM
NO RATINGS
Some more feedback:

I'm still a bit skeptical, but Bogdan Marinescu (one of the principal eLua developers) has a high regard for Damian the MicroPython developer.

eLua has already been ported to mbed (although it really needs a mbed targer with >= 64K SRAM), and you should see better eLua on mbed support in the future.


Sometime (yeah, maybe next year) I'll have to check out the mbed ecosystem.

ewertz
User Rank
Manager
Re: Hmmm, we'll see
ewertz   12/4/2013 7:37:59 PM
NO RATINGS
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).

 

 

alex_m1
User Rank
CEO
Re: Hmmm, we'll see
alex_m1   12/5/2013 5:01:45 AM
NO RATINGS
@ewertz  I wonder how much percentage of designs are low/medium speed real-time, and how many are really fast,faster than what micro python might offer.

And If what is needed is hard and fast realtime , Something like a dual core microcontroller like the lpc43xx look usefull:

Big core runs python and complex software,second smaller core runs the real-time section written in c.

TonyTib
User Rank
CEO
Re: Hmmm, we'll see
TonyTib   12/5/2013 12:55:19 PM
NO RATINGS
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.


Too many fun options, too little time.

alex_m1
User Rank
CEO
Re: Hmmm, we'll see
alex_m1   12/5/2013 3:38:32 PM
NO RATINGS
@TonyTib, Those all seem like interesting  and useful architectures. It would be interesting to run something like micro python on a beagle bone for example.

Yes dynamic capabilities are helpfull. But there are many other things that make python so simple and powerfull and many of them could apply even in simpler code.


For example: http://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers/posts/675393

EdwinBland
User Rank
Rookie
uPython close to C speeds
EdwinBland   12/6/2013 10:08:22 AM
NO RATINGS
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.

 

 

alex_m1
User Rank
CEO
Re: uPython close to C speeds
alex_m1   12/6/2013 10:56:16 AM
NO RATINGS
@EdwinBland: MicroPython is not about extension.It's about compiling python to near c speed. Have a look at the kickstarter.

EdwinBland
User Rank
Rookie
Re: uPython close to C speeds
EdwinBland   12/6/2013 12:21:50 PM
NO RATINGS
@alex_m1

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. 

Tx for the clarification Alex.

 

 

 

Charles.Bagnall
User Rank
Rookie
further comments
Charles.Bagnall   1/9/2014 1:25:49 PM
NO RATINGS
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.

Radio
NEXT UPCOMING BROADCAST
EE Times Senior Technical Editor Martin Rowe will interview EMC engineer Kenneth Wyatt.
Top Comments of the Week
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Flash Poll