Den entpackten Ordner per Atom/Pymakr auf das Gerät übertragen
Wir haben gerade überlegt, wie wir das mit dem aktuellen Entwicklungsstand im Repository bei GitHub - hiveeyes/hiveeyes-micropython-firmware: Hiveeyes MicroPython Datalogger - data logging for humans ebenso machen können, solange es noch nicht in ein Release gegossen ist. Das Problem ist hier, dass die Dateistruktur im Repo nicht der Struktur auf dem FiPy entspricht, sondern erst mit make setup / mkae install “zusammengebastelt” wird.
Pymakr bietet dafür eine projektbezogene Datei pymakr.conf an, mit der man Verzeichnisse oder Dateitypen angeben kann, die synchronisiert werden sollen. Das entspräche einer rezeptartigen Beschreibung als Schwester von upload-all.lftprc.
Ich hab mich bemüht, den vsc über die bisherige Struktur zu ‘mappen’.
TL;DR: es geht nicht
Zwei Ansätze:
die Workspaces des VSC so zu konfigurieren, das es hinterher so aussieht, wie auf der MCU. Das ginge wohl - leider hat der upload vom pymakr-plugin von Workspaces keine Ahnung und lädt dann stumpf doch wieder alles mühselig ausgefilterte mit hoch.
über die pymakr.conf die richtigen Verzeichnisse auswählen. Das hat den einen Nachteil, das man dann die Struktur im Verzeichnisbaum nicht sieht (kann man aber über die Workspaces hinbiegen). Viel gravierender ist aber, das man Verzeichnisse nicht ineinander schachteln kann. D.h. ich bekomme /terkin nicht unter /lib sondern immer nur in /.
So wie es momentan ist, kommt man an make nicht vorbei. Ist zwar irgendwie schade, das das nicht einfach so geht. Ich glaube aber nicht, das sich der Aufwand lohnt, deswegen alles umzustellen.
Für Linux&Mac kann man sich eh alles zusammen symlinken und für Win braucht man halt WLS oder Docker oder eine VM.
Mit den releases geht es. Was ich gemacht habe ist ein Release von Releases · hiveeyes/hiveeyes-micropython-firmware · GitHub zu nutzen, da sind die Dateien / Verzeichnisse ja schon richtig zugeordnet das geht gut: Einfach das gewünschte Release runterladen, entpacken, im Atom das entsprechende Verzeichnis auswählen und auf dem xPy hochladen.
Was als workaround für nicht-releaste Versionen / commits auch geht:
latest and greatest code von git herunterladen und wie gehabt mit make in der Linux-Umgebung auf dem Py aufspielen
mit Atom oder ftp den “richtig sortierten Code” herunterladen und damit in Atom weiterarbeiten.
Das sind aber alles nur Lösungen für “Konsumenten”. Wenn jemand etwas beitragen möchte und in die aktuelle git-Struktur committen möchte, dann ist das Vorgehen oben nicht wirklich praktikabel.
Das ist in der Tat genau das Problem, das wir hier haben: Markus würde das Git-Repository gerne unter Windows nativ (ohne WSL2) mit Visual Studio Code nutzen und etwas zur Entwicklung beitragen, nämlich die Portierung der Codebase auf einen Vanilla ESP32.
Ich hoffe wir kriegen das bald hin – zusammen mit Markus haben wir neulich bereits eine weitere Alternative besprochen.
Es ist möglich mit VSC über ein Plugin (glaube ‘remote WSL’ ) das WSL einzubauen. Man hat dann die WSL unten in einem Fenster und überträgt dann damit.
Man kann auch das Git in ein Windowsverzeichnis Clonen und im WSL dort hin mappen.
Mann kann dann ganz normal mit VSC arbeiten und überträgt dann mit Make im WSL.
Ohne WSL (Win 10) Klappt das aber leider nicht. Ein kostenloses Update auf Win 10 ist für private aber immer noch möglich.
Ich habe derzeit (3 Wochen! ) kein Internet zu Hause, da sie mir bei Baggerarbeiten die Glasfaser aus dem Boden gerissen haben. Kann daher nur mit Handy ins Netz. Kann aber gerne versuchen das Mal aufzuarbeiten.
Was das Synchronisieren angeht, taugt das pymakr plugin im VSC nicht besonders. Das ist recht buggy und auf meine Anfragen im Forum kam auch nicht wirklich viel.
Meine Lösung unter Win10 ohne WSL sieht momentan so aus, das ich per Docker ‘make setup’ aufrufen kann. Das baut mir dann einmal die Struktur. Danach kann ich mir updates per git beziehen.
Für den VSC hab ich mit ein verlinktes (“mklink /J …”) Verzeichnis gebaut, das ich komplett mit dem pymaker plugin auf die MCU syncen kann.
Das funktioniert - kann ich aber nicht wirklich zum Nachbau oder gar allgemeinen Gebrauch empfehlen.
Wie schon geschrieben läuft ein WSL- Bash- Terminal in VSC ausgezeichnet mit dem Remote-WSL Plugin die Verzeichnisse befinden sich dabei im Win 10 Dateisystem.
Das ist aktuell meine eleganteste Möglichkeit mit der Sandbox und VSC zu arbeiten.
Die andere Möglichkeit Die Dateien in einem Win 10 Verzeichnis zu haben und mit VSC dort normal zu Arbeiten. Nur die Uploads in einem 2. Fester (WSL) zu machen indem man dort ins Windowsverzeichnis mountet ist aber auch nicht verkehrt und hat bei 2 Monitoren auch seinen reiz.
Hast du einen bestimmten Grund, das du auf WSL Verzichten möchtest/mußt, da bei dir ja eh schon Win10 läuft?
in VSC mit Remote-WSL Plugin mountet er automatisch sobald man ein Verzeichnis im WSL-Modus öffnet. mann muß dann nur noch manuell den COM Port offnen.
Ja - ich habe eine Backup Lösung, die mit der WSL nicht funktioniert. Das wäre generell auch ein Grund, sich nach einer anderen Backup Lösung umzusehen. Aber ehrlich gesagt, möchte ich das Fass momentan nicht aufmachen.
Ich lass jetzt erst mal alles wie es ist. Funktioniert ja.
Haben wir eigentlich bereits irgendwo eine Handreichung, wie man die Sandbox innerhalb einer VirtualBox unter Windows betreiben kann, wie @roh auch schon einmal vorgeschlagen hatte?
Vielleicht ist diese Variante universeller und für alle besser geeignet, die mit der Sandbox arbeiten wollen.
