đź“— ESPuino in Platformio anlegen und mit git aktuell halten

Du hast Visual Studio Code zusammen mit Platformio als Plugin gemäß dieser Anleitung installiert und fragst dich nun, wie du ESPuino als Projekt dort reinbekommst? Und du fragst dich auch, wie du es mit wenig Aufwand aktuell hältst? Dann bist du hier richtig!

Grundsätzlich ist ESPuino bereits ein Platformio-Projekt, was für dich den Vorteil hat, dass du es nur runterladen musst, um es dann als Projekt zu öffnen:

  1. Klicke ganz links in die vertikale Leiste auf den Alienkopf (1)
  2. Klicke nun auf „Open“ in der Spalte daneben.
  3. Es öffnet sich nun rechts ein Fenster, in dem du „Open Project“ (3) findest. Dort klickst du drauf und wählst den Ordner, in dem du deine ESPuino-Kopie gespeichert hast, aus. Damit sollte ESPuino via Platformio verfügbar sein.
  4. Du musst nun das Profil festlegen, für das du kompilieren möchtest. Im vorliegenden Fall ist (4) „lolin_d32_pro_sdmmc_pe“ ausgewählt. Klickst du dort drauf, so kriegst du für alle Projekte, die du in Platformio angelegt/importiert hast, alle Profile angezeigt. Wähle hier das Passende aus. Welches du benötigst, hängt davon ab, mit welcher Platine du arbeitest. „lolin_d32_pro_sdmmc_pe“ ist z.B. das richtige Profil, wenn du mit ESPuino/settings-lolin_d32_pro_sdmmc_pe.h at ae1fddac70f5b13ca58f68f32422f658aa852b9c · biologist79/ESPuino · GitHub arbeiten möchtest.
  5. Wenn du alles konfiguriert hast, dann klicke das im oben gezeigten Bild markierte „Upload und Monitor“ an. Es sorgt dafür, dass der Quellecode kompiliert und auf den ESP32 geladen wird. Im Anschluss wird automatisch das serielle Monitoring aktiviert. Dieses Monitoring kannst du ansonsten auch jederzeit mittels „Monitor“ aktivieren.

Gut soweit. Nur wie kriegt man das ESPuino-Projekt eigentlich auf seinen lokalen Rechner?

a) Man lädt es als ZIP-File von GitHub runter.


Problem daran: Wenn sich Teile des Codes ändern, und das tun sie ja öfter mal, dann muss man das ganze ZIP-File neu runterladen oder man muss die Änderungen händisch übertragen. Ist lästig bzw. fehleranfällig.

b) Man verwendet git, welches man sich zuerst installieren muss. Man geht dann in Visual Studio Code und drückt, genäß dieser Anleitung, STRG+SHIFT+P und wählt dann „Git:Clone“ aus. Es öffnet sich dann ein Fenster, in das man die URL eingeben muss, die man clonen möchte. Für ESPuino wäre das: https://github.com/biologist79/ESPuino.git. Wenn man nun auf Enter drückt, wird man gefragt, wohin man das Projekt lokal speichern möchte. Hat man die Auswahl getroffen, so wird das Projekt runtergeladen (geclont). Im Anschluss öffnet sich in Visual Studio Code rechts unten ein Fenster, in dem sowas Ähnlichs steht wie „Möchten Sie das geclonte Projekt zu ihrem Arbeitsbereich hinzufügen?“ Das tust du dann und schon ist das Projekt verfügbar.

Der größte Vorteil der Variante b ist jedoch, dass man den Quellcode aktualisieren kann, ohne jedes Mal das ganze Repository runterladen zu müssen. In Visual Studio Code drückt man hier wieder STRG+Shift+P und wählt dann „Git: Pull“ aus. Da klickt man drauf und wird man nach dem Projekt gefragt. Üblicherweise wird dies dann „ESPuino master“ sein. Das bestätigt man und schon wird der Sourcecode aktualisiert.

Mögliche Probleme beim Aktualisieren:

  1. Du hast Settings-Dateien angepasst und nicht im Repository gepeichert. Git verweigert den Checkout, weil es die Änderungen überschreiben würde. Hier musst du vor dem Checkout deine Änderungen entweder rückgängig machen oder mit Stash arbeiten. Für die meisten Leute wird’s vermutlich einfacher sein, die Änderungen rückgängig zu machen und im Anschluss, nach dem Checkout, neu zu setzen.
  2. Du hast zwar deine Änderungen im Repository per Commit abgespeichert, jedoch treffen deine Änderungen einen Bereich, in dem durch den Checkout auch weitere Änderungen reinkommen. Git ist bestrebt, das Ganze möglichst automatisch zu vereinigen „mergen“, wird dir jedoch ggf. sagen, dass ein automatisches Merge nicht möglich war und du (punktuell) selbst entscheiden musst, was jetzt übernommen werden soll. Das finale Ergebnis wird man, nachdem man es getestet hat, dann üblicherweise per Commit ins Repository überführen wollen.

Ein paar Sätze zum Arbeiten mit git:
Wichtig zu verstehen ist: Wenn du Änderungen gemacht hast und diese in deinem lokalen Repository nicht gespeichert hast (commit), dann gelten diese als temporär und ein git checkout würde diese normalerweise überschreiben. Tut es jedoch nicht, sondern wirft dir einen Fehler, dass du deine Änderungen zuerst comitten (oder stashen) sollst, bevor du den Befehl ausführen darfst.

Klingt total kompliziert und ist es vielleicht auch, aber du kannst in Visual Studio Code auch schön sehen, welche Dateien du verändert hast:

Im Bild siehst du die Zahl 13, welche besagt, dass ich in verschiedenen Projekten, an insgesamt 13 Dateien Änderungen gemacht habe. Unter Änderungen sieht man nun welche Dateien ich im Projekt ESPuino verändert habe (M steht für modified; auch neue Dateien etc pp werden hier aufgeführt). Man kann so eine Datei einfach anklicken und kriegt dann eine sehr schöne Gegenüberstellung angezeigt:

Im Bild sieht man, dass ich die main.cpp markiert habe. Klicke ich auf diesen gebogenen Pfeil zurück, so mache ich alle Änderungen an der Datei sofort rückgängig. Es ist dann wieder die Version aktiv, die im Repository als letzter Stand gespeichert wurde. Klicke ich auf +, so überführe ich diese Datei ins „Staging“. Was ist das nun wieder? Beispiel: Ich (@biologist) habe lokal ein Feature programmiert, das Änderungen an 11 Dateien mit sich bringt. Ich musste für meine lokalen Tests aber auch die settings.h anpassen, weil das für meine Testhardware notwendig war. Die Änderungen der settings.h sollen jedoch nicht ins Repository, da dies gewisse Voreinstellungen überschreiben würde. Daher überführe ich nur solche Dateien ins Staging, die auch im Repository landen sollen.

stage

Hier sieht man nun, dass ich drei Dateien ins Staging überführt habe. Hinweis: Änderst du an einer gestageten Datei nachträglich nochmal was, so landen diese Änderungen nicht mehr im Staging. Du musst die Dateien durch Klicken auf „-“ wieder aus dem Staging rausholen und wieder neu reinnehmen, damit die Änderungen aktiv werden.

Ist man nun soweit, dass man alle Änderungen beisammen hat, alle zugehörigen Dateien im Staging sind und nun in einem Commit landen sollen, so trägt man eine Commit-Nachricht ein, was ich im Bild mal exemplarisch getan habe. Man drückt dann „Shift+Enter“ und deine Änderungen sind im Repository abgelegt. Keine Angst: Sie landen dadurch nicht automatisch bei GitHub oder sonstwo. Sie sind wirklich nur bei dir lokal.

Fazit: Mit git lässt sich komfortabel arbeiten, aber zugegebenermaßen bedarf es einiges an Wissen, damit das möglich ist. Aber auch wenn man sagt, dass man seine lokalen Änderungen (im Endeffekt reden wir bei den meisten Leuten ja eh nur von den Settings-Dateien) halt vor dem Checkout rückgängig macht, weil man Angst hat, etwas kaputt zu machen, ist es immer noch komfortabler, als es per ZIP runterzuladen.

Das Ganze reißt das Thema git nur ganz oberflächlich an. Aber ich hoffe mal, dass es für den ein oder anderen User hilfreich ist. Schreibt gerne in weiteren Kommentaren, wenn ihr Tipps / Meinungen / Anregungen habt.

1 „Gefällt mir“