Versionskontrolle für Open-Source-Hardware - Gunook

2024 Autor: John Day | [email protected]. Zuletzt bearbeitet: 2024-01-30 07:20

Das Team von Brainbow hat eine Reihe von Elektronikprojekten hinter sich und wir wollten unseren Prozess zur Verwendung der Versionskontrolle zur Verwaltung unseres Elektronikdesign-Workflows vorstellen. Dieser Workflow wurde für große und kleine Projekte verwendet, von einfachen 2-Layer-Boards bis hin zu komplexen 10-Layer-Giganten, und basiert auf Open-Source-Tools. Hoffentlich können andere unseren Workflow für sich übernehmen und die Vorteile der Versionskontrolle für ihre eigenen Projekte nutzen. Aber welche Vorteile bietet die Versionskontrolle einem Elektronikprojekt?

Schritt 1: Warum Versionskontrolle Ihrer Elektronik?

Versionskontrolle (auch bekannt als Quellcodeverwaltung oder Revisionskontrolle) ist ein gut verstandenes und weit verbreitetes Konzept in der Softwareentwicklung. Die Idee hinter der Quellcodeverwaltung besteht darin, Änderungen am Quellcode eines Programms oder einer Anwendung systematisch zu verfolgen. Wenn Änderungen die Anwendung beeinträchtigen, können Sie die Quellcodedateien in einen bekannten Arbeitszustand aus der Vergangenheit zurücksetzen. In der Praxis ermöglichen es Ihnen Quellcodeverwaltungssysteme, den Verlauf einer Sammlung von Dateien (normalerweise die Quellcodedateien für ein Computerprogramm, eine Website usw.) zu verfolgen und Änderungen an diesen Dateien zu visualisieren und zu verwalten.

Das Verfolgen des Änderungsverlaufs an einem Projekt scheint für Elektronikprojekte nützlich zu sein; Wenn Sie einen Fehler im Schaltplan machen oder den falschen Bauteil-Footprint im PCB-Layout verwenden, wäre es schön, den Überblick zu behalten, welche Fehler gemacht wurden und welche Korrekturen in verschiedenen Überarbeitungen eines Projekts implementiert wurden. Es wäre auch für andere Macher nützlich, diese Geschichte zu sehen und den Kontext und die Motivationen verschiedener Veränderungen zu verstehen.

Schritt 2: Die Tools: KiCad und Git

Wir verwenden in diesem Projekt zwei Hauptwerkzeuge: das Versionskontrollsystem (VCS) und das Elektronikdesign-Automatisierungsprogramm (EDA oder ECAD).

Es gibt VIELE Versionskontrollsysteme, aber wir verwenden das verteilte VCS Git. Wir verwenden es aus einer Reihe von Gründen, aber entscheidend sind, dass es Open-Source (check!), einfach zu bedienen (check!) und der De-facto-Standard VCS für Open-Source-Software ist (check!). Wir werden Git als VCS verwenden, um die Änderungen an den Dateien zu verfolgen, die unser ECAD-Programm verwendet. Dieses Instructable erfordert keine Vertrautheit mit Git, aber allgemeiner Komfort mit der Befehlszeile wird vorausgesetzt. Ich werde versuchen, bei Bedarf auf hilfreiche Ressourcen für die Verwendung von Git und der Befehlszeile zu verlinken.

Die meisten Quellcodeverwaltungssysteme funktionieren besonders gut für textbasierte Dateien, daher wäre ein ECAD-Programm, das Textdateien verwendet, großartig. Geben Sie KiCad ein, die quelloffene "Cross Platform and Open Source Electronics Design Automation Suite", die von Forschern am CERN unterstützt wird. KiCad ist auch Open-Source (check!), einfach zu bedienen (obwohl einige mir da nicht zustimmen würden) und sehr geeignet für fortschrittliche Elektronikdesignarbeiten.

Schritt 3: Installation

Um diese Programme zu installieren, befolgen Sie die Anweisungen auf den unten verlinkten Download-Sites.

• KiCad ist plattformübergreifend (und schwindelerregend; ihre Download-Seite listet 13 unterstützte Betriebssysteme auf und bietet einen Quellcode-Download, wenn keines davon zu Ihnen passt). Verwenden Sie die kicad-unified-Standardinstallation, nicht den nächtlichen Entwicklungsbuild. Siehe Schritt 4 für erweiterte optionale Details zur Bibliotheksinstallation.
• Git ist auch plattformübergreifend. Wenn Sie Windows verwenden, würde ich das beeindruckende Git für Windows-Projekt empfehlen, um eine nützlichere Erfahrung mit vollem Funktionsumfang zu erzielen.

Die auf beiden Seiten verfügbare Installationsdokumentation ist vollständiger als jede Beschreibung, die ich hier anbieten kann. Sobald beide Programme heruntergeladen und installiert sind, können Sie die Projektvorlage von Brainbow aus unserem Github-Repository klonen. Der Befehl git clone nimmt die Struktur `git clone {src-Verzeichnis} {Zielverzeichnis}'; Verwenden Sie für unser Projekt `git clone https://github.com/builtbybrainbow/kicad-starter.git {target directory}`.

Das Klonen eines Git-Repositorys ist eine spezielle Form des Kopierens; Wenn Sie ein Projekt klonen, erhalten Sie eine Kopie aller im Repository enthaltenen Dateien sowie des gesamten von Git verfolgten Verlaufs des Projekts. Durch das Klonen unseres Repositorys erhalten Sie ein bereits strukturiertes Projektverzeichnis mit unseren Empfehlungen für die Verwendung von Git mit KiCad. In Schritt 6 werden wir mehr über die Projektstruktur behandeln, oder Sie können mit Schritt 7 fortfahren, wenn Sie Lust haben, mit der Arbeit zu beginnen.

Ein paar schnelle Reinigungsaufgaben - führen Sie `git remote rm origin` aus, um den Link zu dem Github-Projekt zu entfernen, aus dem Sie geklont haben. Führen Sie außerdem `git commit --amend --author="John Doe "` aus und ersetzen Sie den author-Parameter durch Ihren Namen und Ihre E-Mail-Adresse. Dies ändert den letzten Commit (der in diesem Fall auch der erste Commit ist) und ändert den Autor in Sie und nicht in Brainbow.

Schritt 4: Installationshinweis: KiCad-Bibliotheken

Eine kurze Anmerkung zur Bibliotheksstruktur von KiCad. KiCad bietet eine Reihe von Bibliotheken, die vom Entwicklerteam für eine Vielzahl von elektrischen Komponenten verwaltet werden. Es gibt drei Hauptbibliotheken:

• Schaltplansymbole: Symbole, die zur Darstellung elektronischer Komponenten in einer Schaltplanzeichnung verwendet werden.
• PCB-Footprints: 2D-Zeichnungen, die den tatsächlichen Footprint (Kupferpads, Siebdruck usw.) darstellen, der beim Layout der Schaltung auf einer PCB verwendet werden soll.
• 3D-Modelle: 3D-Modelle von elektronischen Komponenten.

Diese Bibliotheken werden zusammen mit der gerade installierten KiCad-Programmsuite heruntergeladen. Sie können KiCad ohne weiteren Aufwand nutzen. Für "Power-User" werden die Quelldateien für die Bibliotheken jedoch in einem Git-Repository auf Github gespeichert, sodass Benutzer, die über die neuesten Änderungen auf dem Laufenden bleiben möchten, die Bibliotheks-Repositorys auf ihren eigenen Computer klonen können. Das Verfolgen der Bibliotheken mit git hat eine Reihe von Vorteilen - Sie können wählen, wann Sie Ihre Bibliotheken aktualisieren möchten, und Updates müssen nur Änderungen an den Dateien einbeziehen, anstatt den gesamten Satz von Bibliotheksdateien erneut herunterzuladen. Sie sind jedoch für die Aktualisierung der Bibliotheken verantwortlich, was leicht vergessen werden kann.

Wenn Sie die Bibliotheken klonen möchten, beschreibt diese Site die verschiedenen Github-Repos, die KiCad anbietet. Git klont die Bibliotheken auf deinen Computer (zB: `git clone https://github.com/KiCad/kicad-symbols.git`), dann öffne KiCad, wähle den Menüpunkt „Einstellungen“in der Menüleiste und klicke auf „Pfade konfigurieren… . Auf diese Weise können Sie KiCad den Verzeichnispfad mitteilen, in dem nach jeder Bibliothek gesucht werden soll. Diese Umgebungsvariablen sind standardmäßig der Pfad zu den Bibliotheken, die mit der KiCad-Installation installiert wurden; Ich habe mir diese Werte notiert, damit ich bei Bedarf wieder zu den Standardbibliotheken wechseln kann. Der Pfad KICAD_SYMBOL_DIR sollte auf Ihre geklonte kicad-symbols-Bibliothek, KISYSMOD auf die geklonte kicad-footprints-Bibliothek und KISYS3DMOD auf die geklonte kicad-packages3d-Bibliothek verweisen.

Wenn Sie die Bibliotheken aktualisieren möchten, können Sie im Bibliotheks-Repository einen einfachen `git pull`-Befehl ausführen, der Git anweist, auf Unterschiede zwischen Ihrer lokalen Kopie des Bibliotheks-Repositorys und dem Github-„Remote“-Repository zu prüfen und Ihre lokale Kopie, um Änderungen zu übernehmen.

Schritt 5: Git-Grundlagen

Git ist ein komplexes und facettenreiches Programm, dessen Beherrschung ganze Bücher gewidmet sind. Es gibt jedoch ein paar einfache Konzepte, die Ihnen helfen zu verstehen, wie wir Git in unserem Workflow verwenden.

Git verfolgt Änderungen an Dateien mithilfe einer Reihe von Phasen. Im Arbeitsverzeichnis finden normale Änderungen statt. Wenn Sie mit den Änderungen, die Sie an einer Reihe von Dateien vorgenommen haben, zufrieden sind, fügen Sie die geänderten Dateien dem Staging-Bereich hinzu. Nachdem Sie alle geplanten Änderungen vorgenommen und alle Dateien, die Sie verfolgen möchten, in Git bereitgestellt haben, übergeben Sie diese Änderungen an das Repository. Commits sind im Wesentlichen Momentaufnahmen des Zustands der Dateien in einem Repository zu einem bestimmten Zeitpunkt. Da Git Änderungen an Dateien verfolgt und diese Änderungen in Commits speichert, können Sie ein Projekt jederzeit wieder in den Zustand zurückversetzen, in dem es sich bei jedem vorherigen Commit befand.

Es gibt komplexere Themen wie Verzweigungen und Remotes, aber wir müssen diese nicht verwenden, um die Vorteile der Quellcodeverwaltung zu nutzen. Alles, was wir brauchen, ist, Änderungen an unseren KiCad-Designdateien mit einer Reihe von Commits zu verfolgen.

Schritt 6: KiCad-Projektstruktur

Werfen wir einen genaueren Blick auf die Struktur des KiCad-Starter-Projekts, das Sie zuvor geklont haben. Es ist zur einfachen Organisation in eine Reihe von Unterverzeichnissen unterteilt:

• Circuit: Dieser Ordner enthält die aktuellen KiCad-Projektdateien (Schaltplan, PCB usw.). Ich benenne diesen Ordner nicht um, benenne jedoch alle darin enthaltenen Dateien mit dem Namen des Projekts um (Circuit.pro => ArduinoMini.pro).

  • Circuit.pro: die KiCad-Projektdatei
  • Circuit.sch: die KiCad-Schaltplandatei.
  • Circuit.kicad_pcb: die KiCad-PCB-Layoutdatei.
• Dokumentation: Dieser Ordner dient zum Speichern der Dokumentation zum Projekt. Wir haben Pläne, diesen Bereich in Zukunft zu verbessern, aber im Moment enthält er eine einfache README-Datei. Verwenden Sie es, um Notizen zum Projekt zu speichern, damit Sie sie später überprüfen können.
• Herstellung: In diesem Ordner speichern Sie die Gerber-Dateien, die die meisten Fabrikhäuser für die Herstellung Ihrer Leiterplatte verwenden. Wir verwenden es auch, um Stücklistendateien und andere Dokumente zu speichern, die für die Herstellung und Montage benötigt werden.
• Bibliotheken: Dieser Ordner dient zum Speichern projektspezifischer Bibliotheksdateien (wir werden dies in einigen Schritten näher behandeln).

Vielleicht sind Ihnen auch noch ein paar andere Dateien aufgefallen (besonders wenn Sie das Verzeichnis `ls -a` haben). Das.git-Verzeichnis ist der Ort, an dem Git seine Magie ausführt und den Verlauf des Repositorys speichert. Die.gitignore-Datei wird verwendet, um Git mitzuteilen, welche Dateien ignoriert und nicht in der Quellcodeverwaltung gespeichert werden sollen. Dies sind hauptsächlich Backup-Dateien, die KiCad erzeugt, oder einige andere "generierte" Dateien, wie Netzlisten, die nicht in der Quellcodeverwaltung gespeichert werden sollten, da sie aus der Quelle, der Schaltplandatei, generiert werden.

Diese Projektstruktur ist nur ein Ausgangspunkt. Sie sollten es an Ihre Bedürfnisse anpassen und bei Bedarf Abschnitte hinzufügen. In einigen Projekten haben wir einen Softwareordner oder einen Beilagenordner eingefügt, in dem wir Modelle für 3D-Druckbeilagen für das Projekt gespeichert haben.

Schritt 7: Git für KiCad-Projekte verwenden

Wir sind endlich bereit zu sehen, wie Sie Git zum Verfolgen Ihrer Projekte verwenden können. Dieses Instructable soll Ihnen nicht beibringen, wie man KiCad verwendet (obwohl ich in Zukunft eines tun kann, wenn die Nachfrage besteht), also werden wir einige triviale Beispiele durchgehen, um Ihnen zu zeigen, wie der Workflow abläuft. Es sollte leicht verständlich sein, diese Ideen in ein reales Projekt umzusetzen.

Öffnen Sie das Verzeichnis kicad-starter und führen Sie dann `git log` aus, um den Commit-Verlauf anzuzeigen. Hier sollte es einen Commit geben, die Initialisierung des Repos durch Brainbow. Wenn Sie `git status` ausführen, erfahren Sie den Status der Dateien in Ihrem Repository (nicht verfolgt, geändert, gelöscht, bereitgestellt).

Im Moment sollten Sie keine Änderungen in Ihrem Repo haben. Nehmen wir eine Änderung vor. Öffnen Sie das KiCad-Projekt und fügen Sie dem Schaltplan einen Widerstand hinzu, dann speichern Sie. Wenn Sie jetzt `git status` ausführen, sollte Ihnen angezeigt werden, dass Sie die Schaltplandatei geändert haben, diese Änderungen jedoch noch nicht für den Commit bereitgestellt haben. Wenn Sie neugierig sind, was KiCad beim Hinzufügen des Widerstands genau gemacht hat, können Sie den diff-Befehl in der modifizierten Datei `git diff Circuit/Circuit.sch` ausführen. Dadurch werden die Änderungen zwischen der aktuellen Version der Datei im Arbeitsverzeichnis und dem Status der Datei beim letzten Commit hervorgehoben.

Nachdem wir nun eine Änderung vorgenommen haben, versuchen wir, diese Änderung in unseren Projektverlauf zu übernehmen. Wir müssen die Änderungen aus unserem Arbeitsverzeichnis in den Staging-Bereich verschieben. Dadurch werden die Dateien im Dateisystem nicht wirklich verschoben, sondern konzeptionell eine Möglichkeit, Git mitzuteilen, dass Sie alle geplanten Änderungen für eine bestimmte Datei vorgenommen haben und bereit sind, diese Änderungen zu übernehmen. Hilfreicherweise bietet Git einige Hinweise, wenn Sie `git status` für die nächste Aktion ausführen. Beachten Sie die Meldung `(verwenden Sie "git add …", um zu aktualisieren, was festgeschrieben wird)` unter `Änderungen nicht für Commit bereitgestellt:`. Git sagt Ihnen, wie Sie die Änderungen in den Staging-Bereich verschieben. Führen Sie `git add Circuit/Circuit.sch` aus, um die Änderungen bereitzustellen, und dann `git status`, um zu sehen, was passiert ist. Jetzt sehen wir die Schaltplandatei unter zu übertragenden Änderungen. Wenn Sie diese Änderungen noch nicht übernehmen möchten, bietet Git hilfreich einen weiteren Tipp: `(use "git reset HEAD …" to unsstage)`. Wir wollen diese Änderungen übernehmen, also führen wir `git commit -m "Added resistance to scheme"` aus. Dadurch werden die Änderungen mit der bereitgestellten Nachricht festgeschrieben. Das Ausführen von git log zeigt diesen Commit im Projekt-Commit-Verlauf an.

Noch ein paar Tipps zu Commits.

1. Verpflichte dich nicht bei jedem Speichern. Verpflichten Sie sich, wenn Sie das Gefühl haben, dass Sie einen Punkt erreicht haben, an dem sich Ihre Änderungen etwas verfestigt haben. Ich begebe mich, nachdem ich einen Schaltplan fertig habe, nicht nach jedem Hinzufügen von Komponenten. Sie sollten sich auch nicht zu selten festlegen, da es schwierig sein kann, sich an den Kontext zu erinnern, warum Sie die Änderungen, die Sie 3 Wochen später vorgenommen haben, vorgenommen haben. Herauszufinden, wann ein Commit erforderlich ist, ist eine kleine Kunst, aber Sie werden sich wohler fühlen, wenn Sie Git mehr verwenden.
2. Nur Quelle speichern (meistens). Dazu gehören die Projekt-, Schaltplan- und Layoutdateien sowie projektspezifische Bibliotheken. Dies kann auch Dokumentationsdateien umfassen. Seien Sie beim Speichern abgeleiteter Objekte vorsichtig, da sie leicht mit der ursprünglichen Quelle nicht mehr synchronisiert werden können, was später zu Kopfschmerzen führt. Stücklisten- und Gerber-Dateien werden besonders leicht desynchronisiert und sollten daher besser vermieden werden (obwohl eine detailliertere Anleitung in Schritt 9 behandelt wird).
3. Commit-Nachrichten sind sehr nützlich, aber gut strukturierte Commit-Nachrichten sind von unschätzbarem Wert. Dieser ausgezeichnete Artikel enthält einige Richtlinien zum Schreiben klarer, prägnanter und nützlicher Commit-Nachrichten. Dies kann die Verwendung eines Befehlszeilen-Texteditors erfordern, was für Anfänger kompliziert sein kann (`git commit` ohne die Nachrichtenoption -m öffnet einen Texteditor). Für die meisten Leute empfehle ich den Nano-Editor. StackOverflow hat eine gute Erklärung zum Ändern Ihres Editors

Schritt 8: Fortgeschritten: Semantische Versionierung für Elektronik

Für abenteuerlustige Seelen sind die folgenden Tipps fortschrittliche Ideen, die aus vielen Stunden der KiCad-Entwicklung gewonnen wurden. Sie sind bei kleineren Projekten nicht besonders nützlich, aber sie können Ihnen wirklich Kummer ersparen, wenn Ihre Projekte komplexer werden.

In der Software gibt es ein Konzept der semantischen Versionierung (semver). Semver definiert eine gemeinsame Benennungsmethode, um Software-Releases anhand der "Versionsnummer" zu identifizieren, die einem Muster von "Major. Minor. Patch" folgt. Um die Spezifikation von semver anzugeben, erhöhen Sie die Versionsnummer gemäß den folgenden Änderungskategorien.

1. MAJOR-Version, wenn Sie inkompatible API-Änderungen vornehmen,
2. MINOR-Version, wenn Sie Funktionen abwärtskompatibel hinzufügen,
3. PATCH-Version, wenn Sie abwärtskompatible Fehlerkorrekturen vornehmen.

Wir bei Brainbow verwenden unsere eigene Version von semver, die an die Bedürfnisse von Hardwareprojekten angepasst ist. Unsere Spezifikation folgt dem gleichen "Major. Minor. Patch"-Muster, obwohl sich unsere Definitionen, welche Änderungen in welche Kategorie fallen, offensichtlich unterscheiden.

1. MAJOR-Version: Wird für wesentliche Änderungen der Kernfunktionalität der Schaltung verwendet (z. B.: Umschalten des Prozessors von ATmegaa auf ESP8266).
2. MINOR-Version: Wird für Komponenten-Swaps verwendet, die den Schaltungsbetrieb beeinträchtigen könnten (z. B. SPI-Flash-Swap mit einem pinkompatiblen Teil, der möglicherweise einen anderen Befehlssatz hat) oder für das Hinzufügen einiger kleinerer zusätzlicher Funktionen (z. B. hinzugefügter zusätzlicher Temperatursensor).
3. PATCH-Version: Wird für kleinere Bugfixes verwendet, die den Schaltungsbetrieb nicht ändern (z. B. Siebdruckanpassung, geringfügige Anpassung des Leiterbahnlayouts, einfacher Komponententausch wie 0603-Kondensator auf 0805).

In Hardware-Semver wird die Versionsnummer nur bei der Herstellung aktualisiert (genauso wie bei Software ändern sich Versionsnummern nur mit Releases, nicht jeder einzelne Commit zu einem Projekt). Daher haben viele Projekte niedrige Versionsnummern. Wir haben noch kein Projekt haben, das mehr als 4 Hauptversionen verwendet.

Neben den Vorteilen in Bezug auf Konsistenz und Verständlichkeit, die Sie durch den Wechsel zu einem klar definierten Namenssystem erhalten, profitieren Sie auch von der Firmware-Kompatibilität und der Kundenzufriedenheit. Firmware kann unter Berücksichtigung der angestrebten Board-Version geschrieben werden, und es kann einfacher sein zu debuggen, warum ein bestimmtes Programm auf einem bestimmten Board nicht funktioniert ( richtig, die 2.4.1-Firmware läuft nicht auf 1.2 Boards, weil wir keine haben …“). Kunden haben auch von unserem Hardware-Semver profitiert, da der Kundenservice und die Fehlersuche mit einem definierten Standard viel einfacher sind.

Schritt 9: Erweitert: Verwenden der semantischen Versionierung der Hardware

Um Hardware-Semver in Ihren eigenen Projekten zu verwenden, verwenden wir eine Git-Funktion namens Tagging. Wenn Sie zum ersten Mal ein Board herstellen, ist dies die 1.0.0-Version dieses Boards. Stellen Sie sicher, dass Sie alle Änderungen in Ihrem Projekt übernommen haben, und führen Sie dann `git tag -a v1.0.0` aus. Dadurch wird ein Editor geöffnet, in dem Sie eine Anmerkungsnachricht für dieses Tag schreiben können (sehr ähnlich einer Commit-Nachricht). Ich füge Details über die Herstellung hinzu (wer die Leiterplatte hergestellt hat, wer die Platine montiert hat), die später nützliche Informationen sein können.

Das Release-Tag wird dem Commit-Verlauf hinzugefügt und zeigt den Status der Dateien bei der Herstellung von 1.0.0 an. Dies kann nach mehreren Überarbeitungen besonders nützlich sein, wenn Sie zur Fehlerbehebung auf diesen Punkt zurückgreifen müssen. Ohne ein angegebenes Release-Tag könnte es schwierig sein, herauszufinden, welcher Commit zum Zeitpunkt der Herstellung aktuell war. Mit einem Tag 1.0.0 (und 1.1, 1.1.1 usw.) können Sie angeben, dass diese spezifischen Quelldateien diejenigen waren, die in einem bestimmten Fertigungslauf verwendet wurden.

Eine Anmerkung zu Gerbers. Einige Fab-Häuser benötigen Gerber-Dateien, um Ihr Board zu erstellen, und Sie können sie mit KiCad generieren. Dies sind abgeleitete Objekte, die aus der Quelldatei.kicad_pcb generiert werden, und wir führen normalerweise keine Versionskontrolle abgeleiteter Dateien durch. Wir bei Brainbow speichern keine Gerber in der Versionskontrolle, AUSSER wenn wir ein Release markieren. Wenn wir zum Erstellen bereit sind, generieren wir die Gerber-Dateien, speichern sie im Fabrication-Ordner, übertragen und markieren sie. Dann entfernen wir die Gerber und führen die Löschung durch. Dies mag auf den ersten Blick etwas verwirrend erscheinen, stellt aber sicher, dass normale Commits nur Quelldateien speichern und die getaggten Releases auch die genauen Dateien speichern, die zur Herstellung der Boards verwendet wurden. Dies hat sich als bemerkenswert nützlich erwiesen, um Fertigungsfehler Wochen später aufzuspüren.

Schritt 10: Nächste Schritte

Hoffentlich hat Ihnen diese Einführung genug beigebracht, um Versionskontrolle in Ihren eigenen Elektronikprojekten zu verwenden. Wir sind nicht zu einigen der fortgeschritteneren Themen gekommen, z. Dennoch ist die Versionskontrolle wie das Essen von Gemüse: Sie bekommen vielleicht nicht das, was Sie denken, dass Sie sollten, aber jedes bisschen, das Sie bekommen, zählt.

Brainbow arbeitet an einer detaillierteren Anleitung zu einigen der fortgeschritteneren Funktionen unseres Workflows. Wir hoffen, es irgendwann in den nächsten Monaten veröffentlichen zu können. Folgen Sie uns hier auf Instructables, und wir werden Sie sicher informieren, wenn Sie es lesen können.

Vielen Dank fürs Lesen und wir können es kaum erwarten zu sehen, was Sie machen!