MicroPython is a Kickstarted project that brings Python to small, embeddable devices. As part of the terms of the Kickstarter, supporters were to get exclusive access to binary builds, with a few exceptions. Now it looks like the ESP8266-version is going to be added to the binary list. This is awesome news for anyone who enjoys playing around with the popular WiFi chip.
But even more heartwarming is the overwhelming response of the Kickstarter’s backers for making the binary builds public. Basically everyone was in favor of opening the binaries up to the general public, and many wrote that they wanted public binaries all along. People can be so giving.
But there’s also something in it for them! The more people get behind MicroPython, the more (free and paid) development support it will warrant, and the more bug reports it will garner. Wins all around. So keep clicking refresh on the binary list until you see it live. Or better yet, if you’re interested, head over to the forum. (Or just wait for us to cover it here. You know we will.)
The Kickstarter message board was wall to wall “Yes, release them!” It’s a win-win all round and everyone could see that.
Another victory for the open source community.
How can binaries be open source ?
I haven’t read into it, but I think the binaries are mostly just startup code, like Interrupt Vector Tables, clock setup and peripheral initialization (all of which is tiny), and then Micropython sitting on top. I’m sure the ASM for the binaries is available (if not, it’s as you say, not open source).
You can download the ESP8266 toolchain and micropython source code and build your own complete binary right now if you like. The procedure is relatively straightforwards and you’ll find plenty of documentation on how to do it.
One of the perks provided to the backers of the kickstarter was early access to this binary so that they don’t have to build it from source i.e. as a convenience. It looks like they’ll be releasing these binaries to the public soon.
Strictly speaking saying that one will ‘open sourcing the binaries’ is wrong, because the project is already open sourced….It’s just that they don’t release pre-made binaries to the public….yet.
What kind of processor horse power can we hope for dedicated to the python code, once micropython and the esp8266 wifi are running ?
Micropython has a native compiler (python -> machine code) so you can (technically) get the best speeds that the ESP supports. Of course, the compiler can only optimize so much in such a small package, and python still introduces some overhead itself, so properly hand-coded assembly will beat it every time (but that’s always the case). Of course, you can’t really hand-code assembly Over-The-Air, so it’s a fair tradeoff IMO.
ESP8266 Basic is all I have needed. Its been around for a while and has been completely community developed.
Nice! I can include them in Flasher.js :)
there is something special about the ‘I use 80MHz SoC so I can toggle pins slowly in scripting language’ crowd
You can enable 160 MHz mode, but I am still not a fan of mixing design paradigms.
If people don’t want to port efficient c/c++ code, than the work is likely not that important in the long term.
Maybe people just ignore the new version of Visual Basic because we are old, and 50 languages later we still don’t know what we’re talking about… even if we had to write compilers for awhile… ;-)
However, Python was progressively worse after 2.7 in my opinion, as the issues of its threading-deprecation/100%-cpu-sleep-feature is epic troll bait. Tried it out for a few projects, and thought about how the authors likely missed the lessons offered by Lua/Perl/Prolog/Scheme/Java. Use a dictionary instead of switch? that is just too cheeky…
I don’t really understand your mindset.
There are lots of applications, where being able to query something over SPI, and throw a solid request out over wifi to a server has big implications. It doesn’t have to be done in C or C++ for the same reason that it doesn’t need to be shielded against a nuclear blast. What’s the cost going to be, slightly higher running power draw from less efficient code? On the flip-side to that, I got the whole lot deployed and running in a few hours, including the physical build.
And you completely miss the point. Guess you’re writing 100% hand tuned assembly for everything.
If you have a good set of macros, you can program in assembler almost like in Basic.
Remember, all that object oriented bullshit wasn’t invented because computers need it, it’s just to overcome the limitations of our brains. And I frequently get the impression, that it doesn’t even help so much, but people keep using it, because they’ve been told in university that it’s the best thing since sliced bread.
So a lot of time, memory and computing power is wasted programming around the limitations of an oh-so 1337 modern programming language, that would be better spent actually solving the problem.
I think most people just don’t like having to learn an entire instruction set + architecture just to do simple things like blinking LEDs (and let’s not get started on coding something like a TCP/IP stack in ASM). Interpreted languages have the benefit of providing a mostly-consistent coding experience, which reduces a lot of the cognitive load inherent to programming. However, you are correct in stating that they have the downside of being bulkier, slower, and less efficient than hand-coded assembly, so I guess it all depends on what you’re trying to do.
P.S. Check out Micropython’s native assembler (I’ve mentioned it maybe 3 times on this page already haha).
Python is one of the slowest programming languages (more than 30x slower than C/C++ in most cases) out there yet it has the largest ecosystem of libraries than any other programming language out there. Why is that? Because it’s easy to use and allows other programmers to abstract all the bare metal / OS layer complexity. This is same reason why Arduino and other high level apis are so successful.
95% of the time no one cares about maximizing GPIO toggle speed. Most people just want to get s**t done. The performance boosts that many newer microcontrollers have means that you don’t need as much ’embedded systems optimization’ skills as we did before with 8-bit micros….you know, things like optimizing code, using assembly, writing custom minimalist printfs, avoiding floating point numbers, e.t.c. Sure there’s still room for this stuff….it’s just becoming less relevant.
I’d stay with a FORTH https://github.com/CraigLindley/ESP8266Forth Repl, it has more memory left and makes better use of it. (And my ESP/WS2812 lamp, should do a bit more than being a lamp only…)
Oh man, FORTH is a wonderful language for interpreted, near-assembly language speeds. I love how simple it is to just add and redefine words on the fly on the smallest systems. The only issue with FORTH is that it doesn’t work as well on processors with branch prediction (or so I hear), but it does extremely well on the smallest micros, which rarely have such branch prediction capabilities anyway.
However, Micropython’s native assembler does give me FORTH-like butterflies in my stomach, even if the whole package is a lot larger in code and RAM size. I think it’s like a somewhat beefier brother to FORTH if anything.
Horses for courses. The main advantage of any Python is that you get a whole bunch of libraries that will work, or nearly-work with it straight out of the box. You don’t want to code up an HTML parser or webserver if you don’t have to.
If all you want is a pushbutton that communicates its state over websockets (most ESP apps are of this flavor?) then you don’t need speed or memory efficiency.
(BTW: the ESP binary is out. Time to go testing.)
The “whole bunch of libraries” are useless if you haven’t enough memory. Got the Lua on the ESP but too little memory left after a lib was added…
I like C based FORTH interpreters because it’s so easy to add C/Arduino libraries or only parts from them.
Give it twice of memory and wouldn’t argue.
So the binaries are there: https://micropython.org/download/#esp8266