MicroPython is an lightweight implementation of Python 3 that runs on ARM Cortex-M micro-controllers such as STM32 or Texas Instruments CC3200, and since ESP8266 is so popular, work has started to port MicroPython on the Tensilica Xtensa LX106 based WiFi SoC.
The current ESP8266 port comes with some API callss specific to ESP8266, but is quite basic, uses the execution model provided by Espressif, requiring callbacks to process WiFi requests, and doesn’t include support for many of the chip’s interface such as SPI, nor support WiFi fully.
That’s why Damien George, the project lead, has launched a Kickstarter campaign to help fund development of the port, aiming to raise at least 6000 GBP (~$8,500 US). The goal is to develop “proper” Berkeley sockets for MicroPython on the ESP8266, in order to provide a true Python socket API to make development easier, optimize RAM usage, and implement the missing parts on the current port.
Since there are so many ESP8266 modules on the market, they decided to do a software only crowdfunding campaign. Backers will receive MicroPython ESP8266 firmware for their development board – It will be developed on Adafruit HUZZAH boards -, as well as tutorials and documentation, with the source code released 6 months later, unless the 12,000 GBP stretch goal (~$17,000 US) is reached, in which case they’d just release the code at the end of the campaign.
Pledges start at 7 GBP ($10) and go up to 700 GBP (~$1,000), and the more you spent the higher support and influence (vote on modules) will be. MicroPython ESP8266 v1.0 firmware is expected to be released in May 2016.
Thank you John!
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
What’s with this insanity, python, LUA, even JavaScript for micro controllers ? Seriously folks, is it that hard to program in C/C++ ?
Why wast precious resources with such languages ?
This is fantastic, thumbs up! I might have to chip in on this.
@Cirsta, it’s about workflows and libraries, mainly. And you shouldn’t evaluate this as a standard “compiled c vs an interpreted language” discussion inherited from the unix world. It really isn’t. It’s not like you’re bringing the interpreter itself to the esp.
Sure, doing C for µCs isn’t too hard, but learning C and related C apis for this specific device, porting all your application specific libs to it, etc, takes time. Having language specific compilers like Micropython enables regular python devs to produce working code and port existing libraries in a familiar environment within minutes. Micropython in general is also exceptionally well optimized and this reworked port will hopefully further minimise the performance gap between raw C and the binaries produced by mp.
Thanks Jean-Luc! I wanted to ask if you would be interested to review the current state of MicroPython (after all, not every project is up and kicking 2 years after the initial Kickstarter campaign), but was too shy to ask. I mean, you can do it even with “unix” port (there’s package manager, web microframework, sample web app to try) if you don’t have a compatible embedded board (but that can be arranged too). My initial interest for MicroPython was exactly in having powerful and pleasant language for all those 4MB routers, where even OpenWRT could hardly fit. Over time, it of course got more and more viable to run it on “deeply” embedded bare-metal boards.
I wonder the same about Lua and JavaScript. But Python, Python just rules! 😉
Seriously speaking, the precious resource is human time, user time. And vendors are happy to churn out more and more chips, and there’re no (not enough) portable APIs to program them (because portability means wasting precious resources again – right? Well, not exactly, other reasons play role too.)
All in all, you can compare popularity of C++ project to make both portable *and* efficient API for programming MCUs: https://github.com/pfalcon/PeripheralTemplateLibrary , and MicroPython (portable to desktop, efficient as much as possible for a scripting language, and very efficient for user time): https://github.com/micropython/micropython . You can even make your choice where to put your time to ;-). I made mine: I put *my* project on backlog (1st) and started to contribute to another guy’s (2nd).
For ESP8266 you can just use the Arduino stuff and libraries for which you’ll find loads of code. I really don’t think it takes much more to code using that or some C++ libs than it does with python.
I’ve seen python, it’s not bad but for me uC programming is a C/C++ only deal and anything that doesn’t compile to machine code has no place on my uC.
For that matter while I’m not a big fan of Apple but you can clearly see the difference between iOS compiled to native stuff and Android with their Dalvik or ART or whatever.
For some scripting or a desktop app anything goes but where performance counts no interpreted and virtual machine stuff can handle things as well as native.
Python is a scripting language and while you can do much more with it than scripting it was never designed to do uC and stuff. C and C++ on the other hand were.
I really don’t agree with their “much quicker than C”. It’s the idea and the concept of the app that takes time, the programming itself is usually not much of a problem if you know the language well.
> I’ve seen python, it’s not bad but for me uC programming is a C/C++
It’s already a big progress – couple of years ago many people had that “C++ and microcontrollers?? Wwwhat??” 😉
> For ESP8266 you can just use the Arduino
Ok, so you’re ok with Arduino, even though it’s well known that many operations (including I/O) aren’t efficient – just because it uses subset of C++? Well, but then it’s just natural next step to go to a scripting language. If you didn’t make that step or made an oath to never do, that’s all ok. Just don’t be surprised that other people are passing it fast.
> you can clearly see the difference between iOS compiled to native stuff and Android with their Dalvik or ART or whatever.
Here’s a big software development secret – how well something works depends not on language or how “native” it is, but on how software is written. I’m sitting on a box with 16Gb/2.5GHz box with software written in C/C++, and it gets slow regularly. My Android phone works well, as long as don’t install bloat apps in there (or remove them promptly). Ditto for Apple stuff – everyone who looked closely, see weirdly misbehaving apps. And MicroPython can do useful things, and fast in 128K RAM / 160MHz.
> For some scripting or a desktop app anything goes
Again, it’s just one notch to include “embedded” there.
> where performance counts
Right, but again, oftentimes in our world, “performance” is ability to write or test something quickly, or change something existing quickly to suit your needs (the latter is the main selling point of VHLLs, IMHO). But execution performance is important of course, that’s why MicroPython allows you to go to … Assembler for critical parts of your code. (You of course can write modules in C).
> Python is a scripting language and while you can do much more with it than scripting it was never designed to do uC
Correction: MicroPython was specifically designed for uCs. And the Python language is pretty good for that purpose – it’s strictly typed language (while still being dynamic). So, e.g. if you want to work with int’s, your work with them, and if you want float’s, you can be sure you work with them.
All said, I don’t argue that there’s something wrong with sticking to C/C++, just trying to answer your original question how it happened that people run scripting lingos on uCs. Otherwise, I can only appreciate C/C++ programmers – there’re lot of things to write in them yet (for uCs in particular). Heck, we write MicroPython in C ;-).
It would be interesting to have a poll about what developers on this site think about using scripting languages on uC vs. C. I personally side with Marius on this…
There will be a talk at ESC Boston about exactly that Micro Python vs C: http://www.embeddedconf.com/boston/scheduler/session/real-time-software-using-micro-python
@Marius Cirsta
I agree – all that is happening here is that people are limiting what they can do. There isn’t enough RAM to do serious stuff unless you use a compiled machine-like language such as C. No amount of development will change that because the RAM can’t be expanded on the ESPs. There are environments on both Linux and Windows and the API is well documented. There are also many examples of code. I don’t see this one flying.
> because the RAM can’t be expanded on the ESPs
Sorry, but if you write in C, you still can’t expand RAM on ESPs. And that’s one the points – as a long-time esp8266 hacker, I know of ways to get more RAM to user, and those ways aren’t secret – they’re well discussed in hacker community. But I don’t see that ideas be tested and tried, and implemented for users’ benefits. All that “C/C++” programming evolves around munging with a weird proprietary vendor API (so if the chip is gone (or better one appears) – and that happens regularly, most work put into it was useless). This project is exactly to stroll in the direction of getting more of the chip.
> serious stuff
Depends on what you mean by “serious stuff”. You can’t do rocket science on esp8266, even in C. But most people don’t even need “serious”, they need “useful”, “easy”, and “portable”. Because IoT is all about diversified devices, if you bet on single chip or vendor, it’s fail. (A chip with which I started my IoT jorney (it barely was called IoT then) is a complete waste now).
> I don’t see this one flying.
It literally does – there’s project on MicroPython forum for a quadrocopter (for original uPy board, which is much more powerful than esp8266 of course). I myself think it’s crazy – for me, most MicroPython’s value is exactly in IoT area (I’m a boring “serious” guy, doing that “serious things” you talk about), but there’re for sure working crawling and swimming bots. And regarding esp8266, NodeMCU showed that it can fly, maybe a bit too low, but we exactly want to make it fly higher and more pleasantly.
> people are limiting what they can do.
At least they don’t limit their imagination! Being myself a serious boring guy, I find that really exciting!
They’ve already raised over 6000 GBP, so it will happen.
@Paul
I’m glad there are people like Paul who have both the skills to improve the esp8266 port and the perspective to realize that there are people without those skills who will benefit from his effort.
As for the idea that people are limiting what they can do if they use micropython on an esp8266. What nonsense. A lot of the people who use python don’t consider themselves programmers or software developers. They consider themselves scientists, architects, etc, and they use python because it provides them a good way to do what they need to do. If micropython on an esp8266 lets them do what they need to do because of a combination of low price and accessible programming environment, they aren’t going to feel limited at all.
I programmed an ESP8266 by taking advantage of the community-contributed Arduino support. I’m pretty confident that I’d be able to do everything I needed to do, and more, in micropython. I have some other projects that I plan to try on micropython as the esp8266 matures. Maybe my applications aren’t serious enough for you but thats not what matters.
I’m glad there is a way for me to help fund further development of the esp8266 micropython port.
I had attempted to port upython to an 8051 microcontroller but couldn’t get it to work.. the documentation on using upython is great, but nowhere near that level for putting it on a different platform.
Perhaps it’s gotten better since I looked into it.. anyone have any experience with the porting process to a different microcontroller (specifically the steps involved in compiling, since the 8051 compiler is non-gcc, so can’t make use of the makefile )
ESP8266 Micropython campaign has now raised over 18,000 GBP, so the code will be released on day one, and they’ve added several stretch goals.
As a status update, the port (https://github.com/micropython/micropython/tree/master/esp8266) shapes up nicely. There’s pretty complete support for sockets and hardware protocols (I2C, SPI) now. More work is under way of course!
General availability version of ESP8266 port has been released on schedule: https://www.kickstarter.com/projects/214379695/micropython-on-the-esp8266-beautifully-easy-iot/posts/1568461 . Everyone is welcome to build it from the github repository!