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.
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.
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.
Ich lese gerade noch einmal BLE 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.
… 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?
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.
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.
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,…).
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.
Mit der make-Version arbeiten geht nicht. Ich kann zwar selektiv syncen, aber dann fehlen mir die ganzen Sachen aus dem dist-package.
Also bleibt nur 1). Wie machst Du denn aus der make- die release-Version? Mit make? Wenn ja, wie? Oder was anderes?
Danke!
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.
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.
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?
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.
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/terkin-datalogger · GitHub.
