Proper structure of MicroPython package

[danielm]

Recently I realized that the MicroPython code which is used to build firmware for our products got too big and hardly readable - almost 2000 LOC. Current structure is very simple - there is single module file which defines main application class. The class is then imported from this module in _main.py, then instantiated and consequently run() method is called. On top of that there are several 3rd party modules located in /lib directory (umqtt, urequests, ...) which are imported as well. All modules are frozen in custom firmware build.

We would like to re-write the code to become better structured.

1. The structure should allow flexible building of custom firmware which may be different for each customer with build configuration described in a single file (Python script, JSON, ...)

2. The package should contain directories for modules with similar functionality - low-level sensor/IC drivers, IoT platform client implementations, etc.

3. Several attributes and functions should be available for all modules - e.g. current configuration (Python dictionary), logging function, etc.

What are the best practices when designing and building such MicroPython package?
What is the best way to share data between modules? E.g. using global statement/namespace, passing object names as arguments, etc.

[andreas]

Dear @danielm,

we are conceiving a medium-sized MicroPython codebase [1] called Terkin for MicroPython [1b] for the Bee Observer project, which might well resonate with your questions and requirements.

So, we want to humbly point you to the terkin folder [2] within that repository which might spark some ideas for your development process on how to structure a codebase appropriately by using object oriented programming.

Similar to what you are describing, the datalogger program also uses quite a bunch of 3rd party modules which will get populated into a dist-packages folder through make setup [3] after cloning the repository. Thus, these packages are not part of the repository itself but will be acquired at development/build time.

Maybe this helps on giving you some ideas around what you have been asking for.

With kind regards,
Andreas.

P.S.: Just recently, our datalogger program started to spark interest with others and we got support from @poesel to integrate support for BLE [4,5] (thanks!) as well as LoRa/TTN telemetry [6] from other contributors. Saying this, we will be happy to accept further contributions from the community as we are aiming to make this more generic beyond its original scope of beehive monitoring.

[1] https://github.com/hiveeyes/hiveeyes-micropython-firmware
[1b] https://community.hiveeyes.org/t/developing-terkin-for-micropython/233
[2] https://github.com/hiveeyes/hiveeyes-micropython-firmware/tree/master/terkin
[3] https://github.com/hiveeyes/hiveeyes-micropython-firmware/blob/master/tools/setup.mk
[4] https://community.hiveeyes.org/t/ble-fur-hiveeyes/2637
[5] https://community.hiveeyes.org/t/ble-gatt-auf-esp32-mit-micropython/2371
[6] https://community.hiveeyes.org/t/hiveeyes-micropython-datalogger-goes-lorawan-ttn/2691