MicroPython module freezing

Hier geht es um das Einfrieren von generischen Python Modulen für den effizienteren Betrieb unter MicroPython.

Introducing external frozen modules

Wir bereiten gerade die ahead-of-time Bytecode-Kompilierung von .py-Dateien in .mpy-Dateien per mpy-cross vor, also die Erstellung von frozen modules [1]. Wir versprechen uns davon Effizienzzugewinne bei der Dateiübertragung und zur Laufzeit [2]. Dafür wäre es fein, wenn wir gemeinsam prüfen, ob das auf allen bei uns verwendeten Betriebssystemen gut klappt.

Der Einstieg wäre ungefähr folgender threeliner. Bei mir auf macOS geht das gut, während man unter Linux – naja… – kurz nachhelfen muss [3].

# Virtualenv benutzen, um System nicht zu verschmutzen
virtualenv --python=python2 .venv2
source .venv2/bin/activate

# pip auf den aktuellen Stand bringen
pip install pip --upgrade

# mpy-cross für MicroPython 1.9.4 plattformneutral installieren
pip install mpy-cross==1.9.4

# Permission-Probleme unter Linux beheben
chmod +x "$(dirname $(python -c 'import mpy_cross; print(mpy_cross.__file__)'))/mpy-cross"

# Run pre-flight checks
python -m mpy_cross
no input file

Wenn das auf allen gewünschten Plattformen (Linux, macOS, Windows) gut klappt, müssen wir im weiteren Verlauf keine krummen Sonderwege einbauen. Daher will ich hiermit kurz vorfühlen und freue mich über Eure Berichte.

:warning: Während mpy-cross für MicroPython 1.11 bereits gut unter Python3 installiert, sind wir für die Installation von mpy-cross für MicroPython 1.9.4 noch auf Python2 angewiesen. Das wiederum brauchen wir, weil das Pycom MicroPython weiterhin auf MicroPython 1.9.4 basiert – siehe MicroPython quo vadis.

Viele Grüße,
Andreas.


  1. ↩︎
  2. 30 sec boot time vs deep sleep | Pycom user forum ↩︎

  3. Invoking mpy_cross.run() gives "Permission denied" on Linux (#3) · Issues · alelec / mpy_cross · GitLab ↩︎

libero läuft nun wieder als Testgerät für die letzten Änderungen und ist wieder auf dem Programm Teststände / [amo] FiPy Testbench Power zu sehen.

Bisher sahen wir durch die ahead-of-time Kompilierung per mpy-cross keine der erwarteten Effizienzsteigerungen zur Laufzeit. Die Übertragung auf das Gerät geht jedoch geringfügig flotter und nach unserem Gefühl auch wesentlich stabiler über die Bühne – es gibt nun keine der beobachteten 500/550er Fehler bei der Übertragung per FTP mehr.

Der Unterschied in der Datenmenge ist nicht insignifikant, er beträgt knapp die Hälfte gegenüber der nicht-kompilierten Variante.

$ du -sch dist-packages terkin hiveeyes lib
612K	total
$ du -sch lib-mpy/
372K	total

Startup ist auch nicht schneller?? Bei mir braucht er gerade nach einem Aufwachen aus dem deep sleep oder reset 17 Sekunden bis die erste log-message kommt. Ist das der erste Punkt wo nach dem Kompilieren was passiert oder müsste man von den 17 Sekunden noch Zeit abziehen?

Initializing filesystem as LittleFS!
   16.9251 [terkin.configuration     ] INFO   : Starting TerkinConfiguration on path "/flash"

Oben hast du ja auch auf 30 sec boot time vs deep sleep | Pycom user forum verlinkt. Dort vermuten die meisten ja, dass es mit pro-compiling ggf. nicht getan ist, sondern das Problem wo anders liegen könnte:

as 30 seconds really is abnormally long

Eine Vermutung:

it’s likely not just loading, but also a lot of code execution performed.

Der thread-Ersteller meint dann aber:

Pretty sure. I measured before and after the imports in boot.py and main.py and that’s where the time is going. The imports themselves don’t “do” anything but declare classes and functions. There’s very little to no processing going on.

Ein anderer hat schon kapituliert:

My own code is too large to deep sleep,

Letzte Vermutung:

Sounds like you wait a lot for the network inits and other stuff.

Kann es sein, dass die Zeit gar nicht fürs kompilieren, sondern für andere Dinge gebraucht wird?

R A N T

TLDR; Hab gestern schon an den Kuhzaun g’langt. Hat’s mir sauber eine g’wischt. Müssen andere ja nicht nachmachen.

Kontext: Freezing modules

Einleitung

Gestern habe ich die Buildumgebung für Pycom-MPY-Firmwares pycom-docker-fw-build bei uns per Add tools for building firmware images for ESP32 based on Pycom Micro… · hiveeyes/hiveeyes-micropython-firmware@74c2415 · GitHub eingebaut und wollte in den letzten Zuckungen noch ne komplette Firmware draus gießen, damit wir endlich OTA-Rodeo reiten können.

Da gibts aber noch Notizen dazu:

Jetzt aber

MIGHT NOT SUPPORT SUB-DIRECTORIES

This effectively means: “Never heard of Python module namespaces” anyway.

This is abs… fu… craz… ridiculous!

– Why does this always happen to me.

1 Like

Maybe GitHub - Akrog/pinliner: Python Inliner merges in a single file all files from a Python package. will come to the rescue here.