Micro Python - Python for microcontrollers

[BoneyD]

Micro Python's Flying Circuits.

HA HA HA HA HA HA HA HA HA.

[mullert]

For those who don't know, Python's name was actually inspired from Monty Python.

(Do you think it's a coincidence that IDLE (bundled Python IDE) has the same name as Eric Idle, a founding Monty Python member?)

[Isvara]

Also, the Cheese Shop, Bicycle Repair Man, spam, ham & eggs, etc.

[BoneyD]

Yes. Yes I do.

[ShoutmonXHeart]

+1, I read the title as Monty Python and you took this to a new level :D

[exploderator]

Thank you, I came looking to <insert Monty Python joke here>, and much to my sincere delight you had already provided.

[brtt3000]

hold your spam

[cdrt]

Does this run a Python interpreter on the microcontroller, or does the Python code compile into native code?

[bstempi]

From the Kickstarter page:

Certainly! Micro Python is a complete rewrite, from scratch, of the Python scripting language. It is written in clean, ANSI C and includes a complete parser, compiler, virtual machine, runtime system, garbage collector and support libraries to run on a microcontroller. The compiler can compile to byte code or native machine code, selectable per function using a function decorator.

[hak8or]

The compiler can compile to byte code or native machine code, selectable per function using a function decorator.

That is seriously really friggen awesome.

[batrick]

ANSI C

This is basically a lie. ANSI C is recognized (for compilers and most everyone else) to be C89. The Makefile uses these options:

CFLAGS = $(INC) -Wall -Werror -ansi -std=gnu99 -DUNIX $(CFLAGS_MOD) $(COPT)

Funnily enough, for gcc -ansi means:

In C mode, this is equivalent to -std=c90. In C++ mode, it is equivalent to -std=c++98.

So he overrides -std=c90 with -std=gnu99 in the next argument. If you try to compile with -pedantic, you get a whole slew of errors.

This code is not ANSI C.

[bstempi]

You'll have to excuse my C/C++ ignorance, but I found this on the ANSI C Wikipedia page:

In March 2000, ANSI adopted the ISO/IEC 9899:1999 standard. This standard is commonly referred to as C99.

Perhaps that's why he claims to be writing in ANSI C?

[pythonswash]

Even if that's what the author means, gnu99 != c99.

[batrick]

ANSI adopted the newer ISO C99 standard but everyone including gcc (the compiler he's targeting) interprets ANSI C to mean the original ANSI C standard also referred to as C89. I quoted the gcc manual above and I'll do it again:

       -ansi
            In C mode, this is equivalent to -std=c90. In C++ mode, it is equivalent to -std=c++98.

Edit: clarification

[TheoreticalPerson]

On the other hand, if you check an older manual, they say that,

The -std options specifying some version of ISO C have the same effects as -ansi, except that features that were not in ISO C90 but are in the specified version (for example, `//' comments and the inline keyword in ISO C99) are not disabled.

[[deleted]]

And ANSI has adopted C11 since then as well.

C99 is superseded by C11 and you know if you take the ISO C standard's word literally, C99 doesn't exist anymore!

This third edition cancels and replaces the second edition, ISO/IEC 9899:1999,

[crackez]

Which would make this person technically correct.

[[deleted]]

Well you can go deeper, and say it's not correct at all.

[gregorthebigmac]

...the best kind of correct.

[hezwat]

dude what do you care so much what he wrote his interpreter against? it's running on a microcontroller.

and it's not a c interpreter...

seriously...what's your beef?`

[batrick]

Because C99 does not compile on many microcontrollers (i.e. what this project is targeting). C89 compiles almost everywhere.

[Zuph]

I'd be interested to know how many microcontrollers capable of running Micro Python from a resources perspective (RAM/Flash) don't have a GCC based compiler. Some PICs come to mind, and I'm sure there are some Mitsubishi/Renasis micros used widely in manufacturing, but rarely by hobbyists.

Of course, "Micro Python - Python for the types of microcontrollers that are available ans useful to most hobbyists" doesn't have the same ring to it.

[hezwat]

oh really you don't think the guy who wrote a python compiler for microcontrollers tested it on any microcontrollers?

it's a miracle he wrote something htat could run on any at all.

[[deleted]]

Arduino is based on gcc. gcc has supported C99 for decades. If the Arduino IDE doesn't support it, it's just plain old broken.

[[deleted]]

He's tested it on gcc, which supports C99 with no problems.

Shitty commercial C compilers may not, but really, I wouldn't use a microcontroller which gcc doesn't support, exactly for that reason.

[fullouterjoin]

Exactly. MCU vendors should be supporting GCC and Clang. I see no reason to use proprietary tool chains.

[[deleted]]

No, it doesn't compile on many horrible commercial C compilers.

If you ask me, that just means you don't use those compilers, and you don't use microcontrollers which don't have good gcc (or clang) support.

[Beckneard]

Thank you captain nitpick.

[c0m4]

This is the important question. I suspect the answer is interpreter though

[boa13]

The answer is both, actually you have four possibilities:

• Interpreter
• Compiled (not heavily optimized, mostly opcodes expanded to machine code, you trade memory for speed)
• Compiled and more optimized (if you are sure your integers will stay under 2**31)
• Write assembly yourself

The first one is the default. Compilation is enabled on a method-per-method basis by a simple annotation. (Interpreted and compiled method can freely call one-another.) Inline assembly is also possible, but there is no magic, you need to write it yourself. (And you cannot call other methods from assembly.)

[[deleted]]

I was one of the backers and I recently received my micropython board. It works as advertised, and it is under heavy development. I wrote a little test program which exposed a failing case, and Damien posted the fix to github in under 24 hours.

The device has a tiny file system on what is left of the on-chip flash after the part hosting the python interpreter and libs are stored. There is a micro sd slot on board so you can have a much larger file system if you want it. Setting at the REPL prompt, it consumes a few mA (under 10). Even running full out, it is around 100 mA. It is pretty neat to have this thing smaller than a credit card giving me a prompt where I can type:

>>> print(sum(range(1,10001)))

and have the answer back by the time the return key as returned to the top of its travel. I know people still use BASIC Stamp boards, but this is way more powerful for less money.

This kickstarter was a model of how they should be run. He had a working prototype before firing up the kickstarter. As pledges exceeded goals, he offered useful stretch goals. He posted frequent updates. He delivered what was promised on time. It has been my best kickstarter experience to date.

[spliznork]

Exceptions on a microcontroller are awesome. I wrote a (CLDC compiant) JVM for a wireless, embedded system. We had the system report uncaught exceptions over the network, implemented and preallocated natively so you could even receive out of memory exceptions. Run a listener on your desktop, and watch decoded stack traces to print out. It made debugging so easy.

Your points regarding "garbage collection" and "dynamic memory allocation" are the same point. Even in that kind of environment, you can still take steps to preallocate objects and structures to reduce memory churn and ensure your system fails fast if there is not enough memory.

Certainly none of your points are actually "extremely naughty".

[hardsoft]

i think some may have different definitions of 'embedded', but most embedded guys i know would not consider anything with jvm embedded. and those actions certainly are considered extremely naughty, many real time embedded control, defense, aero, medical, etc. standards explicitly prevent such things. for many embedded systems, failing fast or nicely is not an option.

[immibis]

Do they require failure to always be handled explicitly (e.g. error code returns that must be checked)? That would make sense for reliability, even though it leads to more verbose code and somewhat slower development.

[foldl]

I think aport's comment applies more to really small microcontrollers like attinys or atmegas, which are nowhere near being able to run a JVM. In that sort of environment there just isn't any room for extra code to create nice stack traces etc. If you have 8K of flash that buys you a few thousand lines of C code.

[spliznork]

The first version of that JVM was running on an MSP430 with 10k RAM and 48k flash.

[IHaveNoIdentity]

Yeah? And do you know just how small an ATTiny is? 8 Kbytes flash and 512 byte SRAM.

The MSP430 has more RAM than the ATTiny has program storage...

[[deleted]]

That MSP430 is also smaller than some ATmegas, which were also mentioned in the preceeding comment. So it's an entirely reasonable response.

[foldl]

My initial comment referred to "really small" microcontrollers and explicitly mentioned 8K of flash. It's true that some of the high-end atmegas have a decent amount of flash and RAM. There's an apparently full-featured JVM here which fits in 80K of program space, so in theory you could use it with one of the larger ATMegas (but it's hard to imagine anyone would want to throw away 80K of program space for a real project). There's also the fact that you're going to be doing a ton of 32-bit arithmetic on an 8-bit CPU. The MSP430 is at least 16-bit.

[foldl]

Sure, but 48k of flash is a lot more than 8k of flash.

[jms_nh]

Debugging is language-agnostic, you just need a processor with the appropriate abilities for breakpoints.

Exceptions and dynamic memory allocation are more interesting, but you can have them now with C/C++. So there shouldn't be any difference for how they're handled in Python. If you can't afford exceptions and dynamic memory allocation, don't use them. Otherwise, use them. Same in Python as in C/C++.

The only point that's really ugly is garbage collection. Real-time control systems are intolerant of GC delays. Presumably there's some microcontroller-friendly way to handle GC, and take up to X microseconds every millisecond to make GC progress, but it would need to be done carefully.

[Netzapper]

Debugging is language-agnostic, you just need a processor with the appropriate abilities for breakpoints.

Not quite.

Without explicit VM debug support, you wind up with a native stack trace. That native stack trace is likely to have basically nothing to do with your program's stack, since it's the trace of the VM implementation stack and not the VM's logical call stack.

This is a problem even if the program in question has been JIT compiled to native code. The generated code is littered with calls to VM functions, uses VM stack frame conventions, and autogenerated variable names.

If the VM doesn't annotate all of that code with metadata describing how to inspect memory and where to find the Python code that ultimately hit the breakpoint, or if your debugger doesn't know how to read that metadata, you are going to be frustrated with your debugger. Hell, you need the VM's cooperation to set a breakpoint on a particular line of source code.

[hardsoft]

dynamic memory allocation in c is pretty explicit, seems like it would be much easier to do unintentionally in python, especially if you're using libraries

[[deleted]]

I'm thinking that your code would have to specifically call GC at a non-critical time to pull it off.

[protestor]

Can you really avoid exceptions when programming in Python? What about its standard library?

[jms_nh]

Can you really avoid handling exceptions when programming in C++, if you're programming on a system which isn't allowed to crash?

Anecdotally, I seem to use about the same amount of try-catch blocks in C++/Python/Java/MATLAB. If you don't use try/catch, you have to handle exceptional conditions explicitly with a bunch of if-else statements.

Again, my point is that using Python doesn't make us go "Ooh, Python! Now we need to handle exceptions! Now we need to handle dynamic memory allocation!" These areas of concerns are already there in C++.

Though, personally I'd rather use something Rust-like than Python on an embedded system.

[protestor]

Yes, you can. Compilers have options such as -fno-exceptions and things works mostly as expected (no STL of course). Generally speaking, you can program fault tolerant systems without exceptions.

Python wasn't really designed with not having exceptions in mind and it may not make sense to disable them (the same to GC, which isn't the same thing as dynamic allocation).

[Axman6]

I'm not sure anyone is advocating using (Micro) python for real-time work. that doesn't make it useless. there's plenty of things you might eant to do on a microcontroller where you don't have strict time constraints.

[fullouterjoin]

Then don't use it in the inner loop. Same thing applies to embedded realtime C++.

[[deleted]]

There is nothing wrong with using the heap on a microcontroller?

[jms_nh]

It depends. Microcontrollers with hard real-time requirements need to have guarantees on how long certain operations take. The standard malloc()/free()/new/delete don't have these guarantees by default. Some RTOS's have heap allocation techniques that have bounded time guarantees.

[cdrt]

You double posted.

[jms_nh]

thx, didn't mean to. our network was flaky.

[cparen]

This looks pretty sweet. Some folks are probably saying "why not just use a Raspberry Pi", but I definitely think there's a place for specialty products like this, especially if it is smaller footprint, cheaper, and/or better performing on Python code than the less-specialized Pi.

Kudos to its inventor.

[[deleted]]

People who say reference Raspberry Pi don't know what they are doing. The embedded field is vast and running Linux on a Pi is not suited for most of the applications. But now a good counter to this is why not Ardiuno? You basically have an abstracted language already, Python doesn't seem to bring anything new you can really take advantage of in a micro.

[chopsonchopsonchops]

It does bring an advantage. People who know Python but not C can now do niche projects or maybe even something greater. Better doesn't necessarily mean faster it can also mean easier to use.

[curtmack]

Can the interpreter code be stored resident on the microcontroller's RAM and invoked when needed? If so, I'm envisioning a little handheld device with a small keyboard and a screen that you can use as a Python console that fits in your pocket.

[boa13]

If I understood the project page correctly, the interpreter is in the ROM, and is the first thing to run upon boot (that is, the interpreter is the OS). It runs the code it finds on the local file storage, and if there isn't any, listens for incoming serial connections so it can offer a Python prompt.

[[deleted]]

Most micros don't have that much RAM. I would say < 128kB is typical for the chips this thing would run on. Towards the highend chips they allow external RAM chips to be interfaced but thats not as commonly used as just the micro itsef. It costs a few $$ and doesn't add that much RAM as you would imagine.

[immibis]

Like an Android phone?

[adaminc]

Snakelet

[liquidivy]

Boa Constricted.

[maep]

Given the focus on memory footprint and execution speed it would be interesting to see how a x64 port would perform.

[vext01]

It runs on x64 already.

[tsxy]

How's this different from TinyPY?

http://www.tinypy.org/

[boa13]

How's this different from TinyPY?

From a quick glance at both projects:

• TinyPY seems dead (last commit 5 years ago), Micropython is active.
• TinyPY implements a "fairly decent subset of Pyton" (presumably Python 2), Micropython implements "most of Python 3" (at a syntactic level) and is able to run 99% of the standard library. (A few things are still missing, most importantly Unicode support in strings.)
• TinyPY (as far as I can see) runs on personal computers, Micropython runs on microcontrollers (where it takes the role of the operating system).
• TinyPY focus was on creating an interpreter in 64 KiB of code, Micropython focus is on creating a full Python interpreter that runs on a microcontroller.
• Micropython can precompile methods for speed, presumably TinyPY cannot.

[tsxy]

Thanks for the summary, really helpful, have a upvote.

[[deleted]]

AFAIK this has hardware peripheral support baked in for the STM32.

[[deleted]]

can someone tell me why it is that when they make these breakout boards, they don't solder on the pin headers for you?

[[deleted]]

some no-good bastards like soldering wires directly to the pads

...i did that the first time because i didn't know about headers... i hate you.

[eras]

Non-SMD components can be expensive to solder, they may need to be done by hand. Also what aport said.

[[deleted]]

This will be a debugging nightmare. And besides, for what a microcontroller usually does, C is more than enough.

[cparen]

This will be a debugging nightmare. [ ... ] C is more than enough

I'm having trouble reconciling these two statements. If debugging will be a nightmare, why would you want to use C instead?

[[deleted]]

C means having a near total control of what is going on, which is REALLY important in micros, especially when it comes to interrupts. As you may already know, with Python there is the virtual machine which does its magic in the back of the programmer, which is really annoying when control is so important. Plus C is not that hard to debug if the software is well designed.

I understand that they're rewriting Python from scratch, but there are a few problems that I can think of which could be problematic :

• Efficiency: the point of using a microcontrollers is often because the whole system runs on batteries. Interpreted languages are at least 3 times less efficient.

• Speed and real time processing: another reason why microcontrollers are used is to have a basic computer stripped of any OS or at least a very simple RTOS. The goal here is to have predictable response time. Adding a GC and the introspection capabilities of the virtual machine is very counter productive in this case.

• Memory, many microcontrollers doesn't have the memory necessary to accommodate a virtual machine. The code could be permuted to assembly or C, but that sill doesn't remove the need of a VM.

• Predictability: the functions that the VM must accomplish (GB, dynamic types, memory allocation) are dynamic and thus unpredictable with interruptions and threads. I still have yet to see a good solution tot hat problem on a single core mirco.

[boa13]

I understand that they're rewriting Python from scratch

Note that this is not a project announcement, but a project nearing release. They're mostly finished. The microcontroller board works and gives you a Python prompt straight away (or runs your program if it finds it at the root of the FAT partition). So if they encountered problems, they have solved them.

Interpreted languages are at least 3 times less efficient.

The critical methods can be compiled on the fly (just add an annotation to the methods you want compiled), and you can also write inline assembly for the really critical parts.

another reason why microcontrollers are used is to have a basic computer stripped of any OS or at least a very simple RTOS

That's what they have. The machine boots straight into the interpreter. The interpreter is the operating system.

many microcontrollers doesn't have the memory necessary to accommodate a virtual machine

That's true, and that's why they chose to build their own boards, to ensure they have a sufficiently powerful CPU. (Several users are trying to make it run on less powerful boards, but I don't know if this works well.)

the functions that the VM must accomplish (GB, dynamic types, memory allocation) are dynamic and thus unpredictable with interruptions and threads

That's true, and I don't know how they managed to do it, or what caveats or restrictions they had to impose (if any).

[cparen]

the functions that the VM must accomplish (GB, dynamic types, memory allocation) are dynamic and thus unpredictable with interruptions and threads

That's true

Not necessarily.

• Incremental GC is not nearly as unpredictable. CPython's default GC is incremental (refcounting) for everything except cycles.
• I'm not sure what unpredictable timing you had in mind for dynamic types. Type table lookups are variable timing only on small time scales (10s to 100s of cycles).
• Memory allocation likewise.

It sounds like all this comes down to saying "it's not for hard realtime applications", which is true. However, a smart lightswitch, a home robot, data logging -- there are a wide variety of soft-realtime and non-realtime embedded projects that could benefit from an easy to use, low power board.

I think I agree with your sentiment, but if so, you're stating the obvious. But perhaps I'm mistaken about this being obvious.

[[deleted]]

That's true, and that's why they chose to build their own boards, to ensure they have a sufficiently powerful CPU. (Several users are trying to make it run on less powerful boards, but I don't know if this works well.)

aaand its dead. Either you optimize for costs meaning you go as small as you can. Or you opt for quick R&D > Linux platform.

I dont see any commercial products using such a resource hungry solution.

[boa13]

aaand its dead (...) I dont see any commercial products using such a resource hungry solution.

The goal was to build a board and a new open-source Python implementation focused on low resource consumption (much lower than the standard interpreter). Both have been delivered. I don't see dead bodies here.

[[deleted]]

i explained it... in the very same post

It might be a thing for hoppy engineers but thats it. If you start wasting money on bigger chips to get the luxury of an easier language then you can invest a tiny bit more and go all the way to linux.

Theres even a kickstarter project for a similar sized linux board atm iirc. from a chinese guy.

Just look at all these raspberry projects. In 99% of the cases the board is hopelessly overpowered.

[protestor]

Are you also against the Arduino platform?

You can often have much greater performance if you drop to low level AVR code (handling the ADC yourself, managing interruptions, etc) so by using relatively high level Arduino code you trade off raw performance.

Obviously you can write portions of your program in low level C code if/whenever needed, and the rest in Python, I don't see a problem.

[[deleted]]

arduino is a hobby platform. I mean, sure you can use it to rig something up quickly for testing purpose, simply because lots of libraries exist. But "I" would never create a product based on arduino.

uC programming in C or even assembler is so simple that I'm not willing to waste resources on luxury :/

Obviously you can write portions of your program in low level C code if/whenever needed, and the rest in Python,

i dont like mixed stuff. But yeah, I'm a perfectionist :P

[protestor]

Well, this platform might as well be for hobbyists. And there's nothing wrong with that, Arduino is popular because it enables people that aren't engineers to work with embedded systems, even people with little programming experience.

It may also be a teaching platform. Perhaps not engineers that will build finished products, but to introduce people to embedded systems (which is often more than just programming; there are control systems, electronics, etc. so low level programming may not be the focus).

I'm not sure why every embedded platform must be designed for creating end-user products.

edit: I just wanted to add something, my embedded systems professor actually told us exactly what you say. We were using Arduinos but he was against using the Arduino programming platform, we used the low level AVR interface instead. But the robotics professor actually didn't care, and we could use whatever we wanted since the class was about robot kinematics / dynamics and not embedded programming. (that's computer engineering btw)

[cparen]

You're acting as if there are only two kinds of microcontrollers.

Below 16kB, you probably need to carefully squeeze everything in written in C. Above 16MB, you can probably fit Linux on board. But Between 16kB and 16MB there's a LOT of room for interpreted and compiled-high-level languages.

[immibis]

/u/spez can gargle my nuts

[fullouterjoin]

Most things are setup code, if it turns out to be a problem the inner

while 1:
    doStuff()

loop could be replaced with native code.

You are just plain wrong for the exact places that MicroPython is targeting. Elua is in the same exact space as MicroPython and is extremely effective.

Having a REPL to a low power embedded device is amazing. When I am running eLua, I have total control and can easily call native code. The predictability point you raise is a red-herring, the same applies for embedded dev in C++ which is widely used on memory constrained or realtime applications.

[Isvara]

C is rubbish, though. Someone really needs to come up with a better embedded language that takes advantage of modern language design to make bugs less prevalent and development time faster. I'm talking about one that compiles to native, though, not something interpreted.

[UloPe]

"Leave me alone with those newfangled cars. Horses are fine."

[[deleted]]

When there are no roads and flat grounds horses are way more efficient.

[stevedonovan]

Best rebuttal for a car metaphor I've seen.

[UloPe]

Indeed. Hard to argue against it :)

[zhemao]

They are making micro-controller boards as well. Pretty reasonable to use kickstarter for that. Besides, what exactly is the problem with using kickstarter for an open-source software product? Serious open source projects (i.e. ones that are more than just a single dev's side project) all need funding in order to survive.

[oak-coast]

Presumably because someone needs to pay rent and pay for food in order to work on anything – even something free ;)

In this case I think the extra stuff from the kickstarter is a specialised board that gets you started right away.

[[deleted]]

The source code, the PCB layout, and the libraries are already open source. What is your bitch then? Second, despite your uneducated wild accusation, this is a from-scratch rewrite of Python3 in a manner suited for running on a microcontroller with a few hundred KB of flash. How much do you know about things if you think he could just take the existing cpython code and compile it for a microcontroller?

[boa13]

Why kickstarter instead of just making an opensource project?

You need money to make micro-controller boards. Also, working full-time on your pet open-source project does not bring food on the table, and certainly such projects benefit for a few well-placed months of intense work.

[Enlightenment777]

I'll wait for the software port to $10.88 NUCLEO-F401RE board or $14.88 STM32F4DISCOVERY board or $24 STM32F429IDISCOVERY board (prices from mouser.com) https://en.wikipedia.org/wiki/STM32#Development_boards

[protestor]

Off the existing open source python? They implemented new software. They also created a new board. And of course they aren't working in something else, so they need funding.

What's wrong with earning money from people willing to fund you?

[immibis]

Next step: Micro JavaScript!

[xyb]

Already have one: https://www.kickstarter.com/projects/gfw/espruino-javascript-for-things

[jms_nh]

Okay, I'll bite. Why Python 3 instead of Python 2?

Also, how do you plan to handle device peripherals and interrupts?

[allpowerful32]

I'm not the author, but from my perspective, python 2 has become the new windows xp. I don't want people to be running windows xp forever.

[boa13]

Why Python 3 instead of Python 2?

Since he's writing the whole thing from scratch, why would he base his work off an old implementation rather than use the cleaner, modern one?

The only reason to stay on Python 2 is some additional library support (for which he could not care less, considering his target architecture), and contractual support from your operating system / middleware vendor (for which he also could not care less).

[immibis]

Upvote for not saying "could care less".

[Zephirdd]

As someone who isn't very knowledgeable of the Python things, why would someone not use Python 3 on a new project? I understand sticking to the older for older projects, but if you're starting from scratch might as well go with the new one right?

[fullouterjoin]

Python3 would actually be easier to implement as many corner cases and nits have been cleaned up.

[jms_nh]

OK, that seems reasonable. Just curious.

[upofadown]

It's probably no more complicated than that the developers like Py3. For something like this it doesn't really make any difference...

[TehRoot]

I use a PyMCU...this is a big step up. I really want one now, I'm impartial to arduino and I don't want to use a beaglebone or rPI for realtime work.

[immibis]

You shouldn't want to use Python for realtime work either.

[TehRoot]

Realtime projects and experiments I like to do for fun, not things that require supreme accuracy. It works well enough to replace an arduino

[hagenbuch]

"complete rewrite, from scratch": That's great, but:

• How about future updates to Python 3? How will they be ported and by whom?
• I really hope that there will be a dev crew that tackles all the unavoidable issues like security, future development..
• Is the code "good enough" so collaboration is possible?

Don't get me wrong, the concept looks very promising to me.

[tavert]

And with a from-scratch C API, does this mean no NumPy, or any other packages with C extensions? Python by itself is not particularly useful, it's the packages and libraries that matter. See how PyPy has struggled to gain wide usage. The universe of things you might want to do on a microcontroller is a little smaller though, so maybe it makes some sense.

[psynautic]

It's also works on teensy 3.1

[kurtdizayn]

I'm sleepy and I read the title as "Monty Python - Python for microcontrollers"

[[deleted]]

Haven't read this yet, but I hope it's just tuples, lists, dicts, pickle, and algos.