Dass die Entwicklung mit ESP_IDF unter Linux sehr bequem von der Hand geht, sollte universal bekannt sein. Seit einiger Zeit ist es auch möglich, Linux auf ESP32-Varianten mit Xtensa-Prozessor auszuführen. Hier ein kleiner Praxistest, der die Kompilation vorstellt.
Gleich zum Geleit sei angemerkt, dass die Ausführung eines grafischen Benutzerinterfaces am ESP 32 auf absehbare Zeit noch Zukunftsmusik sein wird. Schon jetzt lässt sich das System allerdings gewinnbringend einbringen, als es Duplikation und Koppelung reduziert.
Zur Motivation hierzu das in der Abbildung gezeigte Flussdiagramm, das aus einem – kommerziell erfolgreichen – Beratungsprojekt des Autors stammt.
Bildquelle, alle: Autor
Ob der Nutzung der selben Java-Codedateien sowohl am Prozessrechner als auch am Server fallen viele Friktionspunkte weg – unter’m Strich entsteht eine wesentlich geringere TCO. Zudem gilt, dass Espressif die hauseigenen Controller ja permanent aufrüstet – es ist nicht klar, was in einigen Jahren in den Controllern an Ressourcen zur Verfügung stehen wird.
Eine Frage der Hardware.
Die ESP32-Linux-Varianten basieren durch die Bank auf dem unter https://github.com/jcmvbkbc/linux-xtensa und https://docs.kernel.org/arch/xtensa/index.html bereitstehenden Linux für XTENSA. ESP32-Varianten, die einen RISCV-Prozessor benutzen, sind nicht benutzbar. Der Autor wird in den folgenden Schritten auf das unter https://www.olimex.com/Products/IoT/ESP32-S3/ESP32-S3-DevKit-Lipo/open-source-hardware bereitstehende Evaluationsboard setzen, das sich in der Welt der Linux-ESP32-Nutzer als Quasistandard etabliert hat und rund zwölf US-Dollar kostet. Die Speicherausstattung beträgt dabei 8 MB RAM und 8 MB Flash – alte Knochen (wie meine Wenigkeit) haben mit 4 MB-Workstations angefangen.
Zu beachten ist, dass die XTENSA-Portierung derzeit keinen offiziellen Branch Kern es darstellt – insbesondere wer nicht (perfekte) Linux-Kenntnisse auf Entwicklerebene aufweist, ist gut beraten, zuzuwarten.
Erste Experimente
Im Repositorium unter der URL https://gist.github.com/jcmvbkbc/316e6da728021c8ff670a24e674a35e6 findet sich ein mehr oder weniger „schlüsselfertig ausführbares“ Skript, dass die Bereitstellung einer WLAN- und einer Nicht-WLAN Variante von Linux für den ESP32 verspricht. Der Autor wird in den folgenden Schritten mit einer auf Ubuntu 22.04 LTS basierenden virtuellen Maschine experimentieren, um den Bring-Up aus dem Cold and Dark-Zustand heraus zu demonstrieren. Die Abbildung zeigt die in VirtualBox zugewiesenen Ressourcen.
Angemerkt sei, dass die Nutzung einer VM nur zur Ermittlung der zur Kompilation notwendigen Dependencies sinnvoll ist. Im “Normalbetrieb” ist eine reale Maschine wesentlich produktiver, auch weil das Durchreichen der seriellen Ports in der Praxis nur leidlich funktioniert.
Im „nächsten Schritt“ ist es empfehlenswert, eine Gruppe von Dependencies herunterzuladen. Ob der vergleichsweise „langen“ Ausführungszeit der Datei – Cross-Compiler sind ressourcenteuer – ist es empfehlenswert, alle vom Autor als „theoretisch relevant“ gekennzeichneten Objekte auf den Rechner zu laden:
1
ucnet@ucnet–VirtualBox:~$ sudo apt–get install gcc libtool–bin libtool–doc gperf bison flex texinfo libtool flex texinfo help2man rsync bc make git
2
ucnet@ucnet–VirtualBox:~$ sudo apt–get install build–essential gcc llvm python3
3
ucnet@ucnet–VirtualBox:~$ sudo apt–get install gawk
4
ucnet@ucnet–VirtualBox:~$ sudo apt–get install cmake
5
ucnet@ucnet–VirtualBox:~$ sudo apt–get install python–is–python3
6
ucnet@ucnet–VirtualBox:~$ sudo apt–get install pip
Zwecks Hardwarezugriff ist das Hinzufügen zu dialout und ein Reboot erforderlich:
1
ucnet@ucnet–VirtualBox:~$ sudo adduser ucnet dialout
2
Adding user `ucnet‘ to group `dialout‘ …
3
Adding user ucnet to group dialout
4
Done.
Der Modem Manager sorgt für Probleme bei der Kommunikation mit dem Board, und muss deaktiviert werden:
ucnet@ucnet–VirtualBox:~$ sudo apt purge modemmanager
Selbiges gilt füpr brltty:
1
ucnet@ucnet–VirtualBox:~/build/esp–hosted/esp_hosted_ng/esp/esp_driver/esp–idf$ sudo systemctl mask brltty.path
2
Unit brltty.path does not exist, proceeding anyway.
3
Created symlink /etc/systemd/system/brltty.path → /dev/null.
4
5
6
ucnet@ucnet–VirtualBox:~$ systemctl stop brltty–udev.service
7
8
ucnet@ucnet–VirtualBox:~$ sudo systemctl mask brltty–udev.service
9
Created symlink /etc/systemd/system/brltty–udev.service → /dev/null.
10
ucnet@ucnet–VirtualBox:~$ systemctl stop brltty.service
11
ucnet@ucnet–VirtualBox:~$ systemctl disable brltty.service
Auch hier ist nach den Änderungen ein Reboot erforderlich. Nächste Amtshandlung ist dann das Setzen des Executable-Bits für das heruntergeladene Skript:
1
ucnet@ucnet–VirtualBox:~$ wget https://gist.githubusercontent.com/jcmvbkbc/316e6da728021c8ff670a24e674a35e6/raw/8ffd2e759814612a7c210ddb0b1580855e529b5f/rebuild-esp32s3-linux-wifi.sh
2
ucnet@ucnet–VirtualBox:~$ chmod +x rebuild–esp32s3–linux–wifi.sh
3
ucnet@ucnet–VirtualBox:~$ ./rebuild–esp32s3–linux–wifi.sh
Während der Durchführung der Kompilation ist es empfehlenswert, dass Evaluationsboard über den in der Abbildung gezeigten Port mit dem Rechner zu verbinden.
Der direkte Hardwarezugriff aus VMWare setzt dann das Rechts-Anklicken USB-Option voraus, wo sie das Gerät QinHeng Electronics USB to Serial verbinden mit der VM verbinden. Nach Ansicht des Autors ist es auch empfehlenswert, wie in der Abbildung gezeigt eine Regel zum automatischen Wiederverbinden einzupflegen.
Fehlerbehebung, zur Ersten
Ärgerlich ist, dass beide Skripte ihre Buildordner bei jedem Neustart komplett abtragen. Selbst beim Bereitstellen aller Dependencies kommt es am Ende zu einem nach folgendem Schema aufgebauten Fehler – dass das System trotzdem einen Flashprozess anbietet, ist zu ignorierien:
1
fatal: No names found, cannot describe anything.
2
WARNING: Git version unavailable, reading from source
3
ESP–IDF v4.4.1
4
+ cp sdkconfig.defaults.esp32s3 sdkconfig
5
+ idf.py build
6
The following Python requirements are not satisfied:
7
setuptools>=21
8
pyserial>=3.3
9
pyparsing>=2.0.3,<2.4.0
10
pyelftools>=0.22
11
idf–component–manager~=1.0
12
gdbgui==0.13.2.0
13
pygdbmi<=0.9.0.2
14
python–socketio<5
15
jinja2<3.1 # See https://github.com/espressif/esp-idf/issues/8760
16
itsdangerous<2.1
17
kconfiglib==13.7.1
18
reedsolo>=1.5.3,<=1.5.4
19
bitstring>=3.1.6
20
ecdsa>=0.16.0
21
construct==2.10.54
22
Please follow the instructions found in the “Set up the tools” section of ESP–IDF Getting Started Guide
23
Diagnostic information:
24
IDF_PYTHON_ENV_PATH: (not set)
25
Python interpreter used: /usr/bin/python
26
Warning: python interpreter not running from IDF_PYTHON_ENV_PATH
27
PATH: /home/ucnet/.espressif/tools/xtensa–esp32–elf/esp–2021r2–patch3–8.4.0/xtensa–esp32–elf/bin:/home/ucnet/.espressif/tools/xtensa–esp32s2–elf/esp–2021r2–patch3–8.4.0/xtensa–esp32s2–elf/bin:/home/ucnet/.espressif/tools/xtensa–esp32s3–elf/esp–2021r2–patch3–8.4.0/xtensa–esp32s3–elf/bin:/home/ucnet/.espressif/tools/riscv32–esp–elf/esp–2021r2–patch3–8.4.0/riscv32–esp–elf/bin:/home/ucnet/.espressif/tools/esp32ulp–elf/2.28.51–esp–20191205/esp32ulp–elf–binutils/bin:/home/ucnet/.espressif/tools/esp32s2ulp–elf/2.28.51–esp–20191205/esp32s2ulp–elf–binutils/bin:/home/ucnet/.espressif/tools/openocd–esp32/v0.11.0–esp32–20220411/openocd–esp32/bin:/home/ucnet/build/esp–hosted/esp_hosted_ng/esp/esp_driver/esp–idf/tools:/home/ucnet/autoconf–2.71/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin
In diesem Fall müssen sie die Skriptausführung durch Senden von Ctrl+C beenden, und danach die heruntergeladene ESP32-Umgebung zur Vervollständigung des Python-Paketcaches der Workstation heranziehen:
1
ucnet@ucnet–VirtualBox:~/build/esp–hosted/esp_hosted_ng/esp/esp_driver/esp–idf$ ./install.sh esp32s3
2
ucnet@ucnet–VirtualBox:~/build/esp–hosted/esp_hosted_ng/esp/esp_driver/esp–idf$ ./install.sh esp32s3
Sodann ist ein Abbruch und ein Neustart des Skripts erforderlich, der leider wieder rund 50 Minuten in Anspruch nimmt.
Auslieferung der Kompilate
Ob der unzuverlässigen Verbindung zwischen VM und ESP32 müssen Sie das Programm nach dem erfolgreichen Durchlauf vor dem Deployment der Firmware durch Drücken von Ctrl+C abbrechen. Danach stehen im Ordner /home/ucnet/build/build-xtensa-2023.02-fdpic-esp32s3/images fertige Images bereit.
Die eigentliche Auslieferung erfolgt partitionsweise – beachten Sie, dass der letzte Befehl, der etc überschreibt, optional ist:
1
ucnet@ucnet–VirtualBox:~/build/esp–hosted/esp_hosted_ng/esp/esp_driver/network_adapter/build$ cd ~/build/esp–hosted/esp_hosted_ng/esp/esp_driver/esp–idf
2
ucnet@ucnet–VirtualBox:~/build/esp–hosted/esp_hosted_ng/esp/esp_driver/esp–idf$ . export.sh
3
ucnet@ucnet–VirtualBox:~/build/esp–hosted/esp_hosted_ng/esp/esp_driver/network_adapter$ idf.py flash
4
ucnet@ucnet–VirtualBox:~/build$ parttool.py $SET_BAUDRATE write_partition —partition–name linux —input build–xtensa–2023.02–fdpic–esp32s3/images/xipImage
5
ucnet@ucnet–VirtualBox:~/build$ parttool.py $SET_BAUDRATE write_partition —partition–name rootfs —input build–xtensa–2023.02–fdpic–esp32s3/images/rootfs.cramfs
6
ucnet@ucnet–VirtualBox:~/build$ parttool.py $SET_BAUDRATE write_partition —partition–name etc —input build–xtensa–2023.02–fdpic–esp32s3/images/rootfs.jffs2
Je nach Laune des Board sind ein oder mehrere Ansteck-Absteckzyklen und/oder das Drücken des Resettasters erforderlich. Im nächsten Schritt können sich über den ESP-Monitor als Root anmelden:
ucnet@ucnet–VirtualBox:~/build/esp–hosted/esp_hosted_ng/esp/esp_driver/network_adapter$ idf.py monitor
Spiele mit der Kommandozeile
Trotz der vergleichsweise geringen Ressourcen bringt BusyBox am ESP32 eine brauchbare Shell mit. Die erste Abbildung zeigt die Ausgabe von top.
df ermöglicht eine Abschätzung des verfügbaren Festwertspeichers.
Nächste Amtshandlung ist an dieser Stelle die Einrichtung eines Cross-Compilers, um Binärdateien auf den ESP32 zu bringen.
Fazit und Ausblick
An dieser Stelle haben wir Linux am ESP32 zur Ausführung gebracht. Der Autor wird in den folgenden Tagen weiter experimentieren. Wer in der Zwischenzeit eigene Versuche anstellen will, kann die rund 30GB große VM haben – der Autor stellt sie auf Anfrage per Privatnachricht zur Verfügung (Username und Passwort lauten ucnet und ucnet).
Zuerst erschienen bei Mikrocontroller.net News
Quelle: Read More