ESP32 manifest.py and directory structure ?

[karfas]

Hi everybody,

I'm having trouble to understand the intended use of the FROZEN_MANIFEST Makefile variable and the manifest files already existing in the ports/esp32 tree.

There I find
- boards/manifest.py
- boards/manifest_release.py

ports/esp32/Makefile defines FROZEN_MANIFEST ?= boards/manifest.py.
OK, this is the default for any ESP32 build.
However, this freezes the entire modules/ directory.
The only *important* modules there are inisetup.py, flashbdev.py and _boot.py.
I don't know (and don't want to know) what a "neopixel" is.

The TINYPICO board overrides FROZEN_MANIFEST with it's own manifest.py. This includes boards/manifest.py as well as some TINYPICO-specific(?) library and drivers from TINYPICO/modules.

The function of the above is clear to me.

Is manifest_release.py only an example ?
Why does everybody need the neopixel driver ?

1) Assuming I want to create a board with some specific drivers and definitions, how is this SUPPOSED be used ?
Do I create some board-directory out of the micropython tree, pointing BOARD+BOARD_DIR to it and FROZEN_MANIFEST to a (maybe) new manifest.py ?

2) When I want to contribute this new board back to Micropython, where should the new drivers go ?
I assume that $(TOP)/drivers - $(TOP) from esp32/Makefile - is the correct location.
Is this correct or is some directory below ports/esp32 better for an i2c-connected sensor ?


Thank you very much,

Thomas

[jimmo]

The function of the above is clear to me.

Yep, everything you said is correct.

Is manifest_release.py only an example ?

What's not clear from looking at the main repository is that when the firmware is built for release on micropython.org/download the build script sets FROZEN_MANIFEST to manifest_release.py for the generic and generic_spiram builds.

But I think this means that tinypico release firmware doesn't get the extra modules.

We're working on a way to pass arguments to the manifest.py scripts, so this way "release mode" could be an argument passed on the command line. See https://github.com/micropython/micropython/pull/6888 for a first step towards this.

Why does everybody need the neopixel driver ?

They don't... but on ESP32 we're not too squeezed for flash space so the benefit of providing it outweighs having to provide lots of different firmware releases.

1) Assuming I want to create a board with some specific drivers and definitions, how is this SUPPOSED be used ?
Do I create some board-directory out of the micropython tree, pointing BOARD+BOARD_DIR to it and FROZEN_MANIFEST to a (maybe) new manifest.py ?

Yes, exactly that.
I'd like to fix the thing where you have to set both BOARD+BOARD_DIR (it should be sufficient to just set BOARD_DIR, and it's an easy fix).

Your mpconfigboard.mk is free to choose any manifest.py file you like, and then you can choose whichever ones to include. You'll need at least the base manifest.py as you say (for inisetup, flashbdev, _boot).

2) When I want to contribute this new board back to Micropython, where should the new drivers go ?
I assume that $(TOP)/drivers - $(TOP) from esp32/Makefile - is the correct location.
Is this correct or is some directory below ports/esp32 better for an i2c-connected sensor ?

I don't think we have a complete answer for this yet (it's hard to figure out just how much the main repo should take on). If the driver is specific to this particular board, then like TinyPico the drivers can belong in board/modules, but common drivers should either belong in TOP/drivers, or perhaps micropython-lib.

(On the topic of micropython-lib, my plan is to make it a more useful place generally for drivers and other shared code and libraries. See https://github.com/micropython/micropython-lib/pull/376 -- Damien has indicated that he's keen to go ahead with this)

[karfas]

karfas wrote: ↑
Sun Feb 14, 2021 6:13 pm
Why does everybody need the neopixel driver ?
They don't... but on ESP32 we're not too squeezed for flash space so the benefit of providing it outweighs having to provide lots of different firmware releases.

OK, I just wondered as the credo of micropython seems to be "smaller, smaller, smaller".

Thank you very much for the clarification and the PR pointers.

My out-of-tree build now works well with make, but I can't get CMake (using yesterday's micropython-master) to build anything else than the GENERIC board.

I will play a while with it and then report my results in your announcement thread.

Regards,

Thomas