Terkin-Datenlogger auf Vanilla MicroPython mit BLE-Erweiterungen von Ayke van Laëthem

Ich hab es jetzt geschafft die Micropython Version mit BLE zu kompilieren und auf den ESP32 zu wuchten. Nun braucht nur noch die Software drauf.
Ich hab mir die Quellen von hier Releases · hiveeyes/hiveeyes-micropython-firmware · GitHub gezogen. Nun weiß ich, was make so ungefähr macht, bin da aber auch nicht richtig drin. Es scheint, das da so einiges gebaut wird, was dann anders aussieht, als in dem release.
Beispiel aus main.py:
‘from terkin import logging’
Es gibt ein Verzeichnis ‘terkin’, aber kein Modul gleichen Namens. Da gibts dann natürlich sofort einen Fehler.

Bevor ich jetzt da anfange rumzubasteln, wollte ich fragen, wie das richtig funktionieren soll. :slight_smile:

2 Likes

Hi Markus,

wenn man sich ein Release-Paket von Releases · hiveeyes/hiveeyes-micropython-firmware · GitHub holt, spielt die Makefile-getriebene Sandbox keine Rolle mehr. Dort im .zip- oder .tar.gz-Archiv ist kein Makefile enthalten sondern ausschließlich die für einen Betrieb benötigen Quelldateien sowie Blaupausen für eine passende Konfigurationsdatei.

Die Archiv-Datei ist dafür gedacht, auf der Workstation entpackt und dann über nicht-Sandbox-Mechanismen auf den FiPy übertragen zu werden, also einfach per FTP, Pymakr oder Visual Studio Code.

Nur wenn Du Dir die Quellen direkt aus dem Repository per git clone https://github.com/hiveeyes/hiveeyes-micropython-firmware holst, bist Du im Sandkasten-Universum von make & Co.

Wir helfen gerne weiter, damit Du diese Firmwarevariante optimal auf das Gerät übertragen kannst. Dürfen wir fragen, ob Du Linux, macOS oder Windows auf Deiner Workstation benutzt?

Viele Grüße,
Andreas.

Ich wollte noch hinzufügen, dass die oben referenzierte Firmware bisher ausschließlich auf Pycom Geräten entwickelt und getestet wird. Daher wird sie kaum oder nur mit viel Glück “einfach so” auf einem generischen ESP32 losrennen. Wenn man jedoch ein wenig Hand anlegt, könnte man sie bestimmt mit ein paar Handgriffen kompatibel machen.

Auf jeden Fall ist da insgesamt noch so einiges in Bewegung, ja. Falls Du irgendwo Inkonsistenzen feststellst, freuen wir uns sehr über entsprechende Meldungen.

Fehler entdeckt. Ich habe angenommen, ich brauche den source code. Ist aber falsch - ich brauche die firmware Version (der Name ist etwas verwirrend).

Für den import braucht micropython ein ‘lib.’ präfix. Also statt:
from terkin import logging -> from lib.terkin import logging

Das ist etwas überraschend, da:

import sys
sys.path
[’’, ‘/lib’, ‘dist-packages’]

Gibt es da eine elegantere Lösung, als jetzt überall lib. davor zu schreiben?

Ich benutze Win10. Die firmware hab ich auf macos gebacken, weil die linux vm aus irgendeinem Grund nicht starten wollte. Ich bin da flexibel. :slight_smile:

Hi Markus,

vielen Dank für die Infos. Bevor wir in die Details gehen wäre es wirklich wichtig, zu wissen, in welchen Umgebungen wir jeweils unterwegs sind.

Dort sieht der PYTHONPATH mit den Werkseinstellungen einer aktuellen Pycom Firmware folgendermaßen aus:

Pycom MicroPython 1.20.0.rc11 [v1.9.4-0a38f88] on 2019-05-14; FiPy with ESP32
Type "help()" for more information.
>>>
>>> import sys
>>> sys.path
['', '/flash', '/flash/lib']

Zusammen mit der boot.py des Terkin-Datenloggers wird der PYTHONPATH dann folgendermaßen erweitert, um dem Layout Rechnung zu tragen, wie es innerhalb der Sandbox verwendet wird.

['/flash/lib-mpy', '', '/flash', '/flash/lib', '/flash/dist-packages', '/flash/terkin', '/flash/hiveeyes']

Diese Einstellungen tun auch der Sache keinen Abbruch, wenn die Firmware aus dem Release-Paket bezogen wird, wo einige Toplevel-Directories (terkin und hiveeyes) dann unterhalb von lib/ serviert werden.

Bitte mach Dir also nicht die Mühe, alle Quellen so anzupassen. Der Schlüssel zur ersten Tür ist auf jeden Fall die korrekte Anpassung des PYTHONPATH.

Viele Grüße,
Andreas.

Allerdings: Falls Du nicht auf Pycom MicroPython unterwegs bist, wirst Du vermutlich erstmal nicht viel weiterkommen. Entweder Du müsstest dann an einigen Stellen selbst Hand anlegen oder Dich noch ein wenig gedulden:

Wir werden vorr. die Möglichkeit haben, im Laufe der nächsten Woche ein pyboard-D in die Hände zu bekommen, um damit die ersten Schritte zu unternehmen, den Datenlogger auf ein aktuelles Vanilla MicroPython zu portieren.

Dort ist man gerade bei MicroPython 1.11 [1], während die Pycom-Firmware noch auf MicroPython 1.9.4 basiert.


  1. Releases · micropython/micropython · GitHub ↩︎

Ich lese gerade noch einmal BLE GATT auf ESP32 mit MicroPython nach. Vielleicht kannst Du uns auf den aktuellen Stand bringen, welche Art von Gerätschaft nun vor Dir auf dem Tisch liegt?

Zu Implementing BLE GATT ESS characteristics with MicroPython will ich in diesem Zug auch noch anmerken, dass das ebenfalls mit der BLE API von Pycom realisiert wurde und ich gerade nicht sicher sagen kann, ob das mit dem von Dir erwähnten

1:1 gut klappt – vemutlich ebenfalls eher nicht auf Anhieb sondern gleichfalls nur mit Nachhilfe.

Außerdem will ich dazu ebenfalls sicherheitshalber sagen, dass dieses Subsystem noch nicht im Datenlogger gestartet wird, es war nur ein erster Prototyp.

Wenn hier die Dinge gut zusammenwachsen, wäre es aber natürlich fein, wenn wir dieses Subsystem anschalten würden und es Dir zur Realisierung Deines Vorhabens helfen könnte.

Ich bin mit dieser firmware unterwegs:


Das ist Micropython 1.9.2 eben mit BLE

Direkt nach dem booten:

sys.path
[’’, ‘/lib’, ‘dist-packages’]

Fehler:
Traceback (most recent call last):
File “main.py”, line 30, in
ImportError: no module named ‘terkin.logging’

Bisher aller unverändert. Füge ich /flash & /flash/lib hinzu

sys.path
[’’, ‘/lib’, ‘dist-packages’, ‘/flash’, ‘/flash/lib’]
habe ich leider immer noch den selben Fehler. Obwohl das AFAIK funktionieren müsste.

Auf dem Tisch liegt ein ESP32 WROVER mit 4MB PSRAM und o.g. firmware.

1 Like

Vielen Dank!

Ahja, das ist die von aykevl (Ayke) · GitHub mit dem https://github.com/micropython/micropython/pull/4589, die Du bereits drüben bei BLE GATT auf ESP32 mit MicroPython erwähntest. Danke.

Interessant, also eine noch frühere Baureihe als Pycom MicroPython. Danke!

Versuche doch einmal, explizit /flash/dist-packages noch hinzuzunehmen.

… bzw. … – vergiss ggf. den Quatsch von gerade eben bzgl. /flash in Deinem Falle …

Auf dieser Plattform scheint das Dateisystem u.U. gar nicht nach /flash gemountet zu sein? Dann müsste es in der Tat eigentlich so reichen wie oben angegeben. [1]

Vielleicht ist aber der “leading slash” notwendig, also /dist-packages?


  1. Layout des Release-Pakets
    image ↩︎

terkin liegt ja unter lib. Ich habs trotzdem ausprobiert. Für lib und dist-packages mit und ohne ‘/’ - leider ohne Erfolg. Es geht nur mit explizitem Pfad.
Sehr seltsam.

Ich bau morgen mal die aktuelle firmware ohne BLE. Mal sehen, ob das dann geht.

Dass das Micropython 1.9.2 ist, wundert mich ein wenig.

Offiziell brachte erst MicroPython 1.9.4 » Parser size reduced, new Python stack, stm32 improvements, new esp32 port.

Wir sind gespannt, ob und wie das weitergeht.


Ein Hinweis zum Schluß: Das per Implementing BLE GATT ESS characteristics with MicroPython erschlossene und per hiveeyes-micropython-firmware/ble.py at master · hiveeyes/hiveeyes-micropython-firmware · GitHub implementierte wird vermutlich noch nicht klappen, wenn man dort auf das kanonische Codebeispiel schaut:

import bluetooth
bt = bluetooth.Bluetooth()
bt.active(1)
bt.advertise(100, 'MicroPython')
print('----')
tx = bluetooth.Characteristic('6E400002-B5A3-F393-E0A9-E50E24DCCA9E', bluetooth.FLAG_READ|bluetooth.FLAG_NOTIFY)
rx = bluetooth.Characteristic('6E400003-B5A3-F393-E0A9-E50E24DCCA9E', bluetooth.FLAG_WRITE)
s = bt.add_service('6E400001-B5A3-F393-E0A9-E50E24DCCA9E', [tx, rx])
tx.write('foo')

Da das aber vermutlich das neue designierte BLE-Interface für Vanilla MicroPython werden wird, wäre es schön, wenn das die Datenlogger-Software ebenfalls unterstützen würde.

Mit der aktuellen uPy Version funktioniert das Importieren der Module. Das scheint also ein Problem dieser alten Version zu sein. Kann man nur hoffen, das BLE zeitnah in Main wandert.

Ich schau mal, wie weit ich ohne BLE komme. Dazu dann weiter bei Terkin-Datenlogger 0.5.1 mit uPy v1.11 auf ESP32 WROVER.

1 Like

Hmm, da gibt es noch ein Problem. Aber erstmal Begriffsklärung:
Die release-Version ist das, was hinterher auf der MCU im flash liegt (also /lib, /dist-packages, boot.py & main.py)
Die make-version ist die mit allem (/doc, /examples,…).

  1. Für die Arbeit mit VSC wäre die release-Version ideal. Datei editieren, projekt syncen und sofort sehen, obs läuft. Nur bekomme ich diese Version nicht ins git - da müsste ich die geänderten Dateien zu Fuß ins repository schieben.

  2. Mit der make-Version arbeiten geht nicht. Ich kann zwar selektiv syncen, aber dann fehlen mir die ganzen Sachen aus dem dist-package. :frowning:

Also bleibt nur 1). Wie machst Du denn aus der make- die release-Version? Mit make? Wenn ja, wie? Oder was anderes?
Danke!

Hi Markus,

arbeiten tue ich mit der Sandbox-Variante direkt im working tree des Repositories, anders wäre eine Publikation der Änderungen zwar möglich, aber aufwendiger.

Bei Operate the MicroTerkin firmware sandbox haben wir einige Dinge zum Umgang damit zusammengestellt.

Die Kurzversion wäre in etwa

git clone https://github.com/hiveeyes/hiveeyes-micropython-firmware
cd hiveeyes-micropython-firmware
make setup
export MCU_PORT=/dev/cu.usbmodemPy001711
make install

um die Quelldateien 1:1 auf den FiPy zu laden.

Eine fortgeschrittenere Variante gibt es rund um "make recycle-ng MPY_CROSS=true". Damit überträgt man 1. nur Bytecode und 2. über FTP. Dafür wiederum braucht es die IP-Adresse des Geräts und einen dort laufenden FTP-Server. Da ich nicht weiß, ob das das Vanilla-MicroPython bereits implementiert, spare ich erst einmal mit weiteren Details dazu.

Generell müssen wir schauen, ob die Sandbox auch bereits 1:1 für das Vanilla MicroPython gut tut, oder ob noch irgendwo Pycom-spezifische Dinge implementiert sind. Im Großen und Ganzen sollte es aber funktionieren – ggf. müssen noch ein paar Pfade angepasst werden, da es die Konvention mit dem /flash-Präfix scheinbar nur bei Pycom gibt.


Die bekommst Du über o.g. make setup. Aufs Gerät übertragen wird dann alles per make install.

make build-release

erstellt die Release-Ordner unter ./build und die korrespondieren Archiv-Dateien unter ./dist.

Viele Grüße,
Andreas.

1 Like

wäre es schön, wenn wir unabhängig von den oben aufgezeigten Möglichkeiten eine entsprechende Konfigurationsdatei ins Repository legen könnten, die beschreibt, welche Dateien für den Synchronisationsvorgang vorgesehen sind, damit nicht die vollständigen Inhalte des working trees (z.B. ./doc, ./tools) übertragen werden, sondern nur die relevanten Quelltextdateien.

Damit könnte man u.U. auch im working tree elegant mit den Quellen im VSC arbeiten, so wie ja auch im Sinne des Erfinders.

Mit @clemens hatten wir das schon einmal besprochen und – wenn mich nicht alles täuscht – dabei herausfinden können, dass man damit u.U. sogar bestimmte Mapping-Verdrahtungen vornehmen kann. Da ich aber weder VSC noch Pymakr nutze, konnte ich eine solche IDE-Konfiguration bisher noch nicht beisteuern. Vielleicht könnt Ihr nachhelfen?

Vermutlich handelt es sich um die pymakr.conf, wie sie auf Tools/Features beschrieben ist.

Hm. Da bin ich mir grade nicht sicher, ob so ein beliebiges Mapping von Verzeichnissen damit möglich wäre. Wir müssten also vermutlich die terkin und hiveeyes Verzeichnisse unterhalb von ./lib platzieren. Dann würde jedoch immer noch – wie angesprochen – das Verzeichnis ./dist-packages fehlen, das ich aus Repository-Sicht weiterhin gerne leicht separat untergebracht sähe.

Man kommt also u.U. nicht so leicht um den Layout-Mismatch der Ordnerstruktur herum. Wir hatten das Thema bereits ein andermal anderswo auf dem Tisch.

Man kann eine pymakr.conf im Projektverzeichnis anlegen und damit selektiv synchen.
Z.b.:

{
    "sync_file_types": "py",
    "sync_folder": "lib", "hiveeyes", "terkin"
}

Damit erwischt man schon die wesentlichen Sachen. Solange aber die Sachen in dist-packages nicht im Repository sind, kommt man damit nicht weiter.
Ich will da jetzt auch nicht zuviel Wirbel veranstalten. Mit make build-release komm ich schon weiter.

Exzellent! Das sieht von den Optionen her umfangreicher aus, ja!

Verstanden. Versuche es doch gerne noch einmal mit dieser Variante nach einem beherzten make setup (auf Linux, macOS/Homebrew oder Win10/WSL2). Das ist dafür vorgesehen, das ./dist-packages-Verzeichnis zu befüllen.

Kein Problem – im Gegenteil: Es wäre wirklich toll, wenn wir das Repository selbst strukturell fit für den out-of-the-box Einsatz mit VSC bekommen würden.

Damit wäre das so halb-hybrid, ja. Nutze gerne alles so, wie es für Dich gut funktioniert. Persönlich verwende ich diesen Schritt nur zur Erzeugung der Release-Artefakte (Assets) für Releases · hiveeyes/hiveeyes-micropython-firmware · GitHub.