
Kickstarter for funding Micropython port to ESP8266 - Sfabris
https://www.kickstarter.com/projects/214379695/micropython-on-the-esp8266-beautifully-easy-iot?ref=discovery
======
bjpirt
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](https://github.com/pfalcon/esp-
open-sdk)

~~~
pfalcon
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.

------
Already__Taken
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](http://ntoll.org/article/story-micropython-on-microbit)

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

[2]:
[http://www.espruino.com/EspruinoESP8266](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.

------
SEJeff
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/](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...](https://home-
assistant.io/blog/2015/10/11/measure-temperature-with-esp8266-and-report-to-
mqtt/)

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

~~~
pfalcon
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!

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

------
okso
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.

------
schappim
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](http://www.telit.com)

------
wiradikusuma
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](https://github.com/esp8266/Arduino)). How
will Micropython be be better?

~~~
robert_foss
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

~~~
pfalcon
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!

------
RossBencina
> 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?

~~~
pfalcon
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.

------
stryk
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.?

~~~
unwind
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).

~~~
stryk
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]

~~~
davelnewton
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.

------
unwind
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.

~~~
pfalcon
MicroPython is fully open-source and available at
[https://github.com/micropython/micropython](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.

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

~~~
pfalcon
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).

------
ithkuil
Shameless plug: Embedded JavaScript VM, ported to ESP8266 port

[https://github.com/cesanta/smart.js](https://github.com/cesanta/smart.js)

~~~
pfalcon
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.

~~~
ithkuil
yes I work for Cesanta.

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

------
rplnt
Why not use something like this?
[https://salt.bountysource.com](https://salt.bountysource.com)

~~~
pfalcon
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.

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

------
bobinator606
why downgrade from an asychronous API to a synchronous one?

~~~
carbon12
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).

