picoweb

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
Post Reply
OutoftheBOTS_
Posts: 847
Joined: Mon Nov 20, 2017 10:18 am

picoweb

Post by OutoftheBOTS_ » Mon Nov 20, 2017 10:29 am

Thanks for the add to the forum :)

I know this issue has already come up that upip can't install picoweb on the ESP8266 enough there is enough flash to fit it the package there isn't enough memory for upip to do the install routine.

I believe the work around is to compile the package into firmware before flashing it to the ESP8266.

As a hobbyist with a windows PC this is a difficult procedure to do. The ESP8266 with micropython is such a great hobbyist platform as it does everything and is a pretty easy platform for a entry level.

Is it possible that the picoweb package be included standard in future firmware builds considering the ESP chip is a wifi enabled chip.

chrisb2
Posts: 28
Joined: Sat Apr 01, 2017 4:19 am

Re: picoweb

Post by chrisb2 » Tue Nov 21, 2017 7:33 am

My solution to this problem was to install Virtual box, then install Ubuntu as a guest VM in VirtualBox. You can then follow the STD instructions to build the firmware and copy it to Windows using a shared folder.

Chris

SpotlightKid
Posts: 463
Joined: Wed Apr 08, 2015 5:19 am

Re: picoweb

Post by SpotlightKid » Tue Nov 21, 2017 9:11 am

And ready-made images for Virtualbox with Ubuntu (or other distros) already installed (so-called appliances) can be downloaded as well, which makes this a breeze:

http://www.osboxes.org/ubuntu/

bitninja
Posts: 165
Joined: Thu Sep 15, 2016 4:09 pm
Location: Spring, Texas

Re: picoweb

Post by bitninja » Sun Nov 26, 2017 5:36 pm

I've been using the VirtualBox method for a while now on my Windows box, and while I have no problems building what I need (ESP8266), I think more can be done to make it more approachable to newcomers.

First, I think it would be nice if there was a single resource (at least for the ESP8266 version) that would take you through ALL the steps required to build the firmware. Jumping around Github for the ESP-SDK, MicroPython, MicroPython-Lib, etc... is ok for some, but I think a newcomer might get confused about how to put it all together.

Second, the idea of pre-built firmware does appeal to me. While I can build whatever I need, managing builds for multiple projects is a chore. Keeping up with new versions is also a challenge. The OP has a good example with PicoWeb. A pre-built PicoWeb image would be great if all you wanted to worry about was developing the PicoWeb app itself.

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: picoweb

Post by pythoncoder » Sun Nov 26, 2017 6:07 pm

The long term aim of the maintainers is to devise a way of freezing bytecode without the need to recompile. I believe this is under active development, but inevitably it has to compete with other tasks so implementation may take a little while.
Peter Hinch
Index to my micropython libraries.

SpotlightKid
Posts: 463
Joined: Wed Apr 08, 2015 5:19 am

Re: picoweb

Post by SpotlightKid » Sun Nov 26, 2017 6:25 pm

I guess it would also be rather easy to put together a cloud build service for MicroPython, using one of the existing CI services like Travis as a backend. Users could supply the scripts they want to freeze via a repository URL or by uploading a zip archive / tarball.

Any volunteers? :)

pidou46
Posts: 101
Joined: Sat May 28, 2016 7:01 pm

Re: picoweb

Post by pidou46 » Tue Nov 28, 2017 5:10 pm

Hello,

Today the mpy-cross tool is build together with the entire firmware. I think that, building it appart from it with a dedicated makefile and uploading it like it is done for the diverse firmware flavors (https://micropython.org/download) would not be a big deal (I guess but I'm not able to do it!)
This way, one could download the mpy_cross executable and freeze it's own module as an *.mpy file.

But to get the full benefit of the freezed module in term of free RAM, it should be embeded in the firmware (in the "module" directory).

To do so, would it be possible to embed the *.mpy file inside the firmware binary file without recompiling the entire firmware ?

I notice that esptool give the possibility to update some part of the firmware delimited by memory addresses:

Code: Select all

Manually assembling a firmware image

You can also manually assemble a firmware image from binary segments (such as those extracted from objcopy), like this:

esptool.py --chip esp8266 make_image -f app.text.bin -a 0x40100000 -f app.data.bin -a 0x3ffe8000 -f app.rodata.bin -a 0x
But I don't know if the firmware binary and the freezed module binary (*.mpy files) are the same kind to be able to assemble them ?
I assume that *.mpy are binary files because they are issued from a compilation process made by mpy_cross, but maybe I'm wrong ?

If yes I don't know where is the starting adress of the module directory in the firmware ?

So this is out of my scope, but maybe this could be an option ? who know ?
nodemcu V2 (amica)
micropython firmware Daily build 05/31/2016

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: picoweb

Post by pythoncoder » Wed Nov 29, 2017 7:19 am

The process of freezing files as bytecode is more complex than simply putting bytecode into flash. I'm no expert on this, but when a build is performed a file frozen_mpy.c is created which contains the bytecode, the qstrs (interned strings) used in the frozen modules together with constant data structures used in them such as (in my case) font files. This C file is compiled into the build. On my system frozen_mpy.c runs to 33,382 lines of code! I recommend taking a look at it (in ports/stm32/build-PYBV11 if you're using a V1.1 Pyboard). It's clever stuff ;)

Doubtless there are other complexities of which I'm unaware. If implementing dynamic modules were easy I think it would have been done. There has been much discussion of this on GitHub if you want to read further.
Peter Hinch
Index to my micropython libraries.

pidou46
Posts: 101
Joined: Sat May 28, 2016 7:01 pm

Re: picoweb

Post by pidou46 » Wed Nov 29, 2017 7:57 am

Thanks, I have a better understanding of the frozing process now, it's clear to me now that the output of mpy_cross cannot be merged with the firmware as it is.

Do you think the first part of my post is correct : It should be possible to build mpy_cross tool indepenently from the tool chain and uploaded as a binary executable ?

This would be a first step to help the average hobbyist to deal with RAM limit?
nodemcu V2 (amica)
micropython firmware Daily build 05/31/2016

SpotlightKid
Posts: 463
Joined: Wed Apr 08, 2015 5:19 am

Re: picoweb

Post by SpotlightKid » Wed Nov 29, 2017 10:32 am

pidou46 wrote:
Wed Nov 29, 2017 7:57 am
Do you think the first part of my post is correct : It should be possible to build mpy_cross tool indepenently from the tool chain and uploaded as a binary executable ?
Yes. But the format of the compiled modules produced by mpy-cross has changed a few times in the past. We're at version 3 now, I believe. So you'd have to make sure to get the correct mpy-cross binary that produces .mpy modules compatible with the MicroPython firmware version you use.

Post Reply