Pre-built firmware?

[tdamsma]

As there is no pre-built firmware available, and there are quite a few build dependencies, I think it would be nice to include that and lower the barrier to entry. If there is any interest, I would be willing to see if I can setup a CI pipeline to arrange that.

In the meantime, I have made a dockerfile that builds all dependencies and a firmware for the ESP32 based on this repo here. Building a formware is now as simple as

docker build -t pycopy https://gist.githubusercontent.com/tdamsma/b49359448924d7aa816d50be2170a610/raw/c12ffbf690fb56a5e9f327cdd2cb81b631db3d5d/Dockerfile
docker create --name pycopy pycopy
docker cp pycopy:/esp/micropython/ports/esp32/build-GENERIC/firmware.bin firmware.bin
docker rm pycopy

The only requirement is that you have docker installed (and a bit of patience)

Update:

The method above does not work anymore, a working dockerfile (as of 2020-07-16) with instructions can be found here: https://github.com/flusflas/micropython-builder

[pfalcon]

Thanks for the post.

I think it would be nice to include that and lower the barrier to entry.

Note that I consider the target audience of my work for MicroPython, and this fork in particular, to be proponents and adherents of Open Source, i.e. folks to whom building from source is a natural thing, something they do all the time, or take as a useful and cherishing to learn. I definitely would like to provide binaries and "lower the barrier to entry", but not at the expense of being flooded and needing to provide support to too-beginners which aren't interested to learn things themselves. Finding a good balance isn't easy.

if I can setup a CI pipeline to arrange that.

If you mean to modify existing Travis CI pipeline so it published built binaries via Github Releases or via some other viable mechanism, that would be helpful/useful (and is in my todo list either, though with more things in current priority on top of it). One concern is the security implications of such setup, as I believe github permissions aren't detailed enough, and publishing also implies various other permissions. So, if you'd go for it, please be prepared to point to docs/elaborate on these points.

Thanks!

[tdamsma]

Understand you point on this being not for noobs, but looking at myself there are people interested in programming microchips with the latest new and shiny asyncio micropython features and libraries (and contributing to the libraries) but have no interest in actually developing micropython itself. I don't know C and could care less for compiler toolchains etc. I hate how setting up my computer (pre-docker at least) for one off builds based on lengthy readme messes up everything.

Thanks for your (and others) hard work for making it possible that a python programmer like myself can hobby with actual microprocessors without any C knowledge!

Will have a look at the CI stuff, just noticed something like this was set up upstream the other day

[pfalcon]

Understand you point on this being not for noobs

I would not formulate it like that. MicroPython in general, and my subproject in particular, is for everyone who want to embrace and learn new things, being them a "pro" or a "noob". (Obviously, a "noob" would enjoy learning much more new things than a rusty "pro".)

[iBobik]

Btw I did something similar there: https://gitlab.com/janpoboril/micropython-docker-build

[iBobik]

I've updated it to support Pycopy: https://gitlab.com/janpoboril/micropython-docker-build/container_registry

[tdamsma]

great! Guess that everyone compiling their own with custom required modules installed is probably better than having just a prebuilt image anyways it would maybe suffice if the link to https://gitlab.com/janpoboril/micropython-docker-build/tree/master was made somewhat discoverable from the pycopy docs

[iBobik]

Yes, it makes sense to build it ourself, but it really takes time to compile all dependencies, so docket image with everything precompiled makes sense. Is just is huge (1,5 GB). I thing it could be optimized, by removing some artifacts from previous stages and keeping only what is needed for firmware make. If you tell me your guesses what is not needed for last step I can try to remove it. Or I can give you commit access so you can try to modify it in web editor and let CI try to build it. Jan Pobořil https://honza.poboril.cz/ 14. 8. 2019 v 10:04, Thijs Damsma <notifications@github.com>:

…

great! Guess that everyone compiling their own with custom required modules installed is probably better than having just a prebuilt image anyways it would maybe suffice if the link to https://gitlab.com/janpoboril/micropython-docker-build/tree/master was made somewhat discoverable from the pycopy docs — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[iBobik]

I've filed issue about optimization: https://gitlab.com/janpoboril/micropython-docker-build/issues/1

[BradenM]

Thought you guys might like something I have been working on for a bit here. Its a collection of different micropython branches (official/pycopy/pycom) for a couple of different ports (unix/esp32/esp8266) all built automatically via a github actions workflow (seen here) which makes use of 3 different Dockerfiles (one for each port). After each version is built, its auto published to github packages for anyone to pull. See the list of packages. Documentation is pretty sparse right now, but looking at the workflow should provide a general idea. Wish I had seen micropython-docker-build before I started working on this though, definitely would have helped!

[maho]

@BradenM I would love to give it a try, but I have no idea, how to build esp32 firmware of pycopy. You could give some oneliners in README.md

[pfalcon]

Since the release v2.12.0.3, binaries for unix port (Linux x86, x86-64) are provided: https://github.com/pfalcon/pycopy/releases

[maho]

Unix port is relatively easy to build. The problem is with ESP32 firmware (and probably - esp8266 too).

There should be links either to prebuilt firmwares, or to less or more blessed solutions like dockerfiles

[pfalcon]

Unix port is relatively easy to build.

That's already great news. And trust me, building any other port is no much complex than unix one ;-).

There should be links either to prebuilt firmwares, or to less or more blessed solutions like dockerfiles

I'm unable to provide support for (or even review) things outside the project. Contributions to the project are welcome. This kind of contribution would be based on existing parts of the project, like https://github.com/pfalcon/pycopy/blob/master/.travis.yml, which already builds esp8266, esp32, and bunch of other ports. Contribution guidelines, which are there to ensure that the contribution is actually helpful, and timely processed, are also available: https://github.com/pfalcon/pycopy/blob/master/CONTRIBUTING.md .

[psy0rz]

Thanks for the post.

I think it would be nice to include that and lower the barrier to entry.

Note that I consider the target audience of my work for MicroPython, and this fork in particular, to be proponents and adherents of Open Source, i.e. folks to whom building from source is a natural thing, something they do all the time, or take as a useful and cherishing to learn. I definitely would like to provide binaries and "lower the barrier to entry", but not at the expense of being flooded and needing to provide support to too-beginners which aren't interested to learn things themselves. Finding a good balance isn't easy.

I see where you're coming from, but i'm a developer myself. I just want to get on with my project, and now i've spended a few hours with finding the "perfect" micropython for my ESP32 project.

• "Vanilla" micropython: too incomplete, missing asyncio which i need for picoweb
• Loboris micropython: Seems dead since 2018, but trying it now.
• Pycopy: Seems very promising, but requires building myself. (im compiling it via provided docker image above right now. But i wont be surprised if its broken because something somewhere has changed in the meantime :)

I think setting up a good travis CI that build firmware can speed up development and actually reduce support requests: It helps if everyone uses "the standard" binary, so that we eliminate a bunch of factors that come into existence when everyone is compiling their own firmware.

I also helps verifying pull requests, because you can create an automatic "build/test" for every pull request. (I used this to streamline ESPEasy development) Now I understand if you dont have time to set it up yourself offcourse.

Project i'm working on: https://github.com/psy0rz/meowton/wiki . I want to provide a link to a page with a ESP32 binary and simple instructions, so people can build their own cat-scale. The project is already complicated enough, without adding the huge burden of compiling your own ESP32 firmware. :)

Edwin