Kickstarter for funding Micropython port to ESP8266 | Hacker News Reader

Kickstarter for funding Micropython port to ESP8266

kickstarter.com

98 pointsSfabris41 comments

Definitely worth a look. One of the guys behind this is pfalcon who maintains the best open development environment for programming the ESP8266 directly[1].

I love the ESP as a platform. It's low cost but still pretty impressive. Having micropython running on it just increases its ease of use, but you've also got Arduino and NodeMCU (Lua) so there's a great budding ecosystem around it.

[1] https://github.com/pfalcon/esp-open-sdk

Thanks. I still can't believe that my little hack of a makefile became so popular ;-). I wish my other personal projects grew as popular as it. It started as personal "executable documentation" to keep sanity in the early days of esp8266 hacking, where there were lot of duplication and big binary blobs flying around (VMs, binary toolchains of questionable licensing). All the real kudos go to @jcmvbkbc who quickly implemented esp8266 support in GCC and maintains it well since then. My little project just makes his and other work accessible to almost everyone who can type few commands in a terminal, with as much as possible build from source (and thus available for tweaking). And the fact that it became popular means that OpenSource is not just an empty motto.

This got me looking into the Espruino JS project boards I like to use. I've seen announced[0] MicroPython for the micro:bit the bbc is making and a few weeks ago the Espruino JS engine was ported[1] to it. Nice to see this wifi chip also has a port[2]

[0]: http://ntoll.org/article/story-micropython-on-microbit

[1]: http://www.espruino.com/MicroBit

[2]: http://www.espruino.com/EspruinoESP8266

After trying to hold interest in an arduino club for young students, leaving that language for something that holds your hand a bit more is quite appealing. That and basically the UK curriculum is python. As we web developer I want to see JS get in here but I think the ships already sailed.

For what it is worth, pfalcon is a really incredible developer. I've built and ran micropython on one of my several ESP8622s and found the experience quite lacking.

Being a contributor of https://home-assistant.io/, I wanted to do a series of blog posts similar to balloob's on using the ESP for small home automation things ala: https://home-assistant.io/blog/2015/10/11/measure-temperatur...

but exclusively with micropython. Funding this will allow this vision to become a reality.

Thanks for your kind words and your project! I have no idea how I missed Home Assistant, written in Python3 and so popular (my usual complain about HA projects is "where're Python projects?" and "where's critical mass?"). I wish it would have caught my eye earlier.

My journey with MicroPython actually started with my smart home project needs - I wanted to use one of those small inexpensive Linux routers as a central controller. With only 4MB of flash, full Python wouldn't fit there, and USB port would be taken by Bluetooth dongle. I tried, really tried to get in love with Lua, but that didn't work, then I hacked on another small language called Squirrel, but when MicroPython campaign was announced, I really rejoiced. Well, that was more than 2 years, and since then, we had big progress with MicroPython, and I had much less progress with my home automation project ;-).

How I explained it to myself, is that, OK, I'll concentrate on uPy, to make it fairly complete and really cool, and that will enable other folks to make cool projects with it, which I myself will like, will be able to pick up, use, contribute to - instead of writing my own. Reading your message, I get a feeling that it might as well be true, and before I grow old ;-).

So, thanks again for your links, Home Assistant is at the top of my list to look into (and I have couple of dozen projects in it). And well, we'll try to do everything to uphold your hopes for MicroPython on ESP8266!

Balloob (HA maintainer) is an absolute machine about merging good PRs. Don't be a stranger if you need something enhanced :)

The Micropython board is pretty expensive (25€), porting it to to cheap ESP8266 (10% of the price) would make Python a top language for IoT.

Plus it provides interactive shell on a micro-controller.

This is awesome, I'm a huge fan of what Damien has done with micropython!

Some hackers might also be interested to know that there is a cellular module called a Telit[1] that can also run some python.

[1] http://www.telit.com

I heard the Lua implementation in NodeMCU/ESP8266 is not good for "anything serious", that's why C is still the way to go (or at least use Arduino 'API', https://github.com/esp8266/Arduino). How will Micropython be be better?

That kinda surprises me a bit, I'd figure if any interpreted language would work on embedded it'd be Lua.

Back when I was in games we ran the whole AI for a PSP game in an single 400kB block and it worked fantastically.

If you think that Lua is good for that, you'd be surprised how MicroPython is good - it's written purposedly for microcontrollers. And Lua was written for "desktop" scripting and found its stronghold in gaming industry. Its usage on deeply embedded systems is attempt at downscaling. Which works. How well?..

MicroPython can work in 128K of "ROM" (80K for language core, rest for modules/user code). In 400K, you can do a lot with it.

I think MicroPython has a really good clean codebase, more so than NodeMCU. But NodeMCU has been getting a lot better in that respect the past few months, and now has a solid foundation.

The current MicroPython support for the ESP8266 platform is very basic, albeit good. I would love to see broader hardware support for the ESP8266 on MicroPython.

I guess the real question is which of these project will support both ESP32 and ESP8266.

Full disclosure: I'm a NodeMCU contributor

I appreciate your comment. I keep an eye on other projects' progress, and I agree that few last months were active in ESP8266 community. Is my observation right that many changes in NodeMCU (finally upgrading from 0.9.6, switching from Lua to eLua) happened after original Chinese guys creators of the projects stepped back and let "western" guys do more maintenance?

Regarding hardware support in MicroPython (first hardware protocols, the specific hardware devices), it's coming - Damien did a lot of work on that preparing to the Kickstarter, and some of it already seen in the KS video. Mind that MicroPython runs on many platforms, and providing portable and consistent API is one of our top goals. And that requires good design work, from many people (to cover different usecases and PoVs), and that takes time and committee-stuff ;-). But we now have solid foundation, so further progress is imminent.

All in all, we always welcomed contributors (and have almost 100 of them), and exactly want to reach critical mass of functionality for ESP8266 port, so it made good sense to come by and contribute gazillion of smaller things people want ;-). So, please keep watching our space!

Regarding ESP32 - one of my concern is to avoid typical situation of moving target, when software never works well enough, with constant promises that next generation of hardware resolves it, but vicious cycle only repeats. Otherwise, I guess it's fair to say that all active projects are going to support ESP32 too!

Depends on what you consider "serious". You can watch a Kickstarter video, at least the beginning. A gadget which shows you weather. Is it serious? I dunno. But I find it useful. Well, perhaps I don't need to know weather in Tokyo if I'm too far away from it. Just knowing meteo report for my area, and actual temperature outside would be good. But wait, if I have an upcoming trip to Tokyo, I'm actually interested in weather in Tokyo during next couple of weeks. Easy customization and changes like that (literally, "on spot") is the biggest selling point of scripting languages.

Can you do it in Arduino? Yes, you can. Arduino is kind of subset of C++ to make it more like scripting language, but still compiled (because AVR microcontroller used in the original Arduino couldn't host an advanced scripting language, but people didn't care even back then, and wanted to run it nonetheless: https://github.com/billroy/bitlash). So, just keep that compiler/IDE around (on your tablet? phone?) if you want to tweak it. Is it big problem? Nope, but should give an idea why people look towards scripting languages which allow to have even less problems.

How MicroPython will be better? Well, we seriously consider Python to be more advanced language overall (while more suited for hardware programming). And I'm a long-time esp8266 hacker with bunch of ideas how to get more from the chip, just looking for a good excuse (like, people actually needing it) to implement them.

> We aim to provide a true Python socket API to make development a pure joy.

Compatibility with standard Python makes sense, if not joy. However the world has long ago moved on to async event-driven APIs. (e.g. asyncore, Twisted, libuv, boost::asio, Netty, etc.)

Perhaps they intend to support asyncore?

asyncore (if you mean it) is old and deprecated by now. MicroPython does support asyncio (subset of it to be exact), which is the default async framework in Python 3.

What are the advantages of using something like the ESP8266 vs using a microcontroller such as the ATmega series found in things like Arduino boards, etc.?

The ESP8266 has on-board WiFi and is a much more capable microcontroller (32-bit, as opposed to the 8 bits the ATmega wields).

A typical ESP8266 module is around $5, which is much cheaper than an Arduino (I know you mentioned the "bare" ATmega, but that's going to have to go on some board, whereas the ESP8266 is already a PCB module, at $5).

I see, thanks for the info! It sounds like (to me, someone just starting down the microcontroller rabbit hole) like the 8266 might be something to aspire to use down the road. I'm not sure if the ESP8266 is as easy to use? The big advantage to the Arudino boards seems to be ease of use, ie; there are so many pre-built libraries to use for components, and "programming" them after that involves issuing it basic commands, not a whole lot of deep code (the way I understand it so far, that is). [e: typos]

The aim of MicroPython port for ESP8266 is exactly to make it very easy to use, even for beginners/people coming from "desktop". (Other people will answer that ESP8266 already has easy enough tools to use, and I won't argue with that either.)

You can use the same Arduino IDE now.

Which makes more sense depends on your needs; if you're heavily invested in the Arduino ecosystem (primarily add-on boards) it might not be a great fit.

But for a GP board with enough GPIO to get small things done, it's a great board, and just as easy to use. For example, I have a number of lights hooked up to it using SSRs. I use it more as a peripheral chip rather than a main controller, because it's so ridiculously cheap and easy to use.

Where I used to use IR comms to hook together small devices (light/power controllers, sensors) I use these now.

I had to look it up, but it seems MicroPython is MIT-licensed.

That of course makes some of the rewards make more sense, but I think it feels oddly strange to pitch in only to get binary blobs and no source.

MicroPython is fully open-source and available at https://github.com/micropython/micropython . The ESP8266 port of it, developed within Kickstarter campaign, will be open-sourced too: either immediately, if enough funds will be collected to ensure its support and maintenance for a reasonable time (until it becomes self-sustained by the community); or in few months otherwise, to let us to have a chance to pitch it to commercial vendors and get needed funding in such way.

The fact that it's MIT licensed means that if you want to make your own products with it, you'll be able to do it, with minimal hassle for you and your customers.

How do we get involved if we would like to contribute to this project?

The github link is above (that's where the development happens). If you're interested in ESP8266 port specifically, currently the best way to contribute is to back Kickstarter campaign, and spread the word about it. (We ran ESP8266 as community project for some time, and that code is available in the git right away, and few people got quite far with it, but as a co-maintainer of MicroPython, I have to admit that it lacks many things, and have some issues - that's why we started a Kickstarter, to develop it in professional manner).

Shameless plug: Embedded JavaScript VM, ported to ESP8266 port

https://github.com/cesanta/smart.js

How does this compare to the follow?

https://github.com/espruino/Espruino

https://www.kickstarter.com/projects/gfw/espruino-javascript...

You had me until the part where I need your cloud service.

You don't need it.

It's an option, and obviously we'd like people to use that and hence are likely to talk about it and show how cool it is etc, but you definitely don't need it.

We have HTTP, WebSocket. Soon we'll also expose MQTT and mDNS to the JS layer; with that you can build whatever you want with the tools and services you love and trust.

Thanks for the response! I'll try to dig through your site to find the docs on how to make it work with my servers. MQTT would be a bonus to be able to push data, that's my preferred method at this point.

Here are the links, to save you from the digging:

- https://www.cesanta.com/developer/smartjs#_http - https://www.cesanta.com/developer/smartjs#_websocket

MQTT API is on it's way, it's already implemented by the underlying networking library (https://github.com/cesanta/mongoose)

For fair comparison, that's GPL-licensed. To get that part out, I'm great proponent of FSF and GPL, and use GPL for most of my "desktop/server" code. But we know that in embedded it's a bit different, and being a good GPL citizen does require some efforts from both vendor and their users. For MicroPython there's actually no choice - we do compete with other well-known small embeddable languages, and MIT/BSD is a norm there, and we don't want people not to select us because some other project has more liberal license.

And I'm not sure if you're yourself from Cesanta, but I definitely heard about them and keep an eye on their progress after they got VC. Actually, I heard about them when Sergey Lyubka switched Mongoose server licensing from MIT to GPL as a result of the company formation. Nothing wrong, that happens.

I actually bring up this matter because it relates very well to the current campaign. We see that MicroPython useful, people like it, it has potential, so we think how to move it forward (the main developer is already full-time on uPy). And this Kickstarter campaign is exactly an attempt at community funding of further development, keeping liberal license, and developing in the open. Because if the main author decides to go for VC, I'm not sure what licensing changes may ensue, and when all the cool features will appear in the open-source version.

yes I work for Cesanta.

BTW thank you for https://github.com/pfalcon/esp-open-sdk, very useful.

Why not use something like this? https://salt.bountysource.com

Well, the page you linked to actually "looks better" than a typical page you get on bountysource.com, but even it shows that only handful projects receive good funding, other mostly "motivational pack", and clicking around, there will be lots of zeros. So, I guess it lies more on well-known and wide-scope projects to promote such services and make them popular, whereas Kickstarter is an already popular platform with active community around.

In our case, Kickstarter was just the right choice overall - we're aware that there're well known competitors, and we want to see if there's enough community interest to back development and support for a reasonable time (half-year, better a year). Starting a KS campaign requires a lot of preparation, but I guess it's good again, because it allows to sanity-test earlier exciting ideas, to see if you really can pledge to implement them.

I'm currently using Lua on the same platform. 'tis a true joy!

why downgrade from an asychronous API to a synchronous one?

The problem is that the underlying vendor "operating system" forces you to use events and callbacks for everything. Disregarding sockets for the moment, we currently can't even run a basic Python script that loops flashing an LED and pausing for 10 seconds. That's because the vendor OS expects you to return very quickly from any user code.

So, the first thing we need to do is make the entire system compatible with the Python execution model, ie no callbacks. As part of this it just so happens that sockets become synchronous as well.

Once this is done we have a solid (and conventional, not forced upon us by the vendor) foundation to work from. Then we can build the Python way of doing async IO if needed using the asyncio framework (and perhaps the new async/await keywords).

We upgrade from proprietary "callback mess" API to a de-facto standard socket API. There will be non-blocking sockets support, and thus portable way for async socket programming. I'd love to say that we'll support Python asyncio, but that's pretty high-level framework, and thus have somewhat higher memory requirements than I'd like. We keep optimizing it, but some simpler custom async scheduler may be due.

And for people who want to solve C1M/100/100 problem ("Serve one million clients on a 100MHz device with 100KB of RAM", pun at https://en.wikipedia.org/wiki/C10k_problem), up to going to callback-based API, we may offer that later, but it will be at least based on open and more or less known lwIP API, not on a proprietary vendor shim.

YMMV, but for the things I use these boards for, async is overkill--I use these as "peripheral controllers": some sensors, some GPIO, and reporting. Overkill for almost all of that, even with sync-only.

You need a lot more expertise to use an asynchronous programming model. It is much simpler to just busy loop with timed waits. If micropython is going to be easily accessible it needs to support the old school BSD socket API. Beginners and non professional developers want to be able to cut and from other peoples network code and have it work.

100% it is a downgrade. Every experienced developer knows the async model is more performant, at the cost of complexity. My micropython fork is super quick and super stable, it's just not easy to use for beginners. For the ESP micropython port to succeed they need to create groundswell of people using the more compatible APIs. Until now, with the cost of the board subsidising the development there has not been much motivation to even put even posted bug fixes into the port. Using the kickstarter and maybe more community support will maybe bring the ESP port up to a first class citizen.

Personally, my port is a hell of a lot of fun to work with and async is a total win on this board.