Versionskontrolle von Schaltplänen und Quellcode

12

Ich entwickle ein elektronisches Gerät, das aus zwei Teilen besteht: Hardware (Eagle-Schaltpläne) und Firmware (C ++ - Quellcode). Ich möchte Änderungen sowohl im Quellcode als auch in den Schaltplänen verfolgen, aber es gibt einige Punkte, an denen ich nicht sicher bin, wie ich meine Arbeit organisieren soll:

  • Für den Quellcode würde ich definitiv Git verwenden. Aber sind Schaltpläne eine Versionierung wert, wenn es sich tatsächlich um Binärdateien handelt (neue Eagle-Versionen verwenden ein XML-Format, sind aber nicht so gut lesbar ...)?

  • Ist es eine gute Idee, Quellen und Schaltpläne in einem Git-Repository abzulegen? Es wäre sinnvoll, aber andererseits würde mein Protokoll sowohl Software- als auch Hardwareänderungen enthalten. Auch die Software kann mehrere Zweige haben, Hardware aber wahrscheinlich nicht ...

  • Wie gehe ich mit Hardware-Revisionen um? Kennzeichnen oder in separaten Verzeichnissen speichern?

  • Es kann auch einige Abhängigkeiten zwischen Hardware-Revision und Firmware-Version geben. Wie gehe ich mit ihnen um?

Könnten Sie mir bitte Ihre Best Practices mitteilen?

eagle hardware c++ klasyc
quelle
Würde eine kommerzielle Lösung funktionieren?
Eugene Sh.
5
Ich würde nie wieder ein kommerzielles Versionskontrollsystem anfassen. Meine Erfahrung mit ihnen sind schreckliche Workflows, die weitaus schwieriger zu verwenden sind als SVN oder sogar Git.
pjc50
Unabhängig davon, welche Versionssoftware Sie verwenden, stellen Sie sicher, dass sie die gesamte Datei ersetzt, wenn Sie mit Schaltplänen arbeiten und nicht auf den Text schauen. Ich hatte das in der Vergangenheit ein Problem. Bei den meisten Schaltplandateien möchten Sie niemals einen Unterschied machen.
Spannungsspitze

Antworten:

19

Das meiste davon hängt von persönlichen Vorlieben ab.

Ich verfolge alles, was ich für ein Projekt in Git mache. Zumal Git die meisten Dateitypen, auch Binärdateien, ausreichend effizient verarbeitet. (Anstelle des eingebauten Altium SVN-Unsinns)

Einer meiner Hauptgründe dafür ist, dass meine Kunden nicht alle der Meinung sind, dass Dropbox sicher genug ist, und ich ein Backup-System benötige, auf das ich weltweit zugreifen kann, mit einem gewissen Versionskontext für die meisten meiner Aktivitäten. Also habe ich einen privaten Git-Server und ein verschlüsseltes Backup-System eingerichtet und es funktioniert ein Vergnügen. Boards, Schaltpläne, Code, Dokumentation, Berichte, manuelle Änderungen, alles wird verfolgt.

Normalerweise würde ich ein Repository für Hardware erstellen, eines für Software und eines für Firmware, wenn es sich um ein großes, möglicherweise lang laufendes Projekt handelt, aber für kleine Serviceprojekte, Beispiele oder kleine Experimente habe ich seitdem oft alles in einem Repository zusammengefasst Das Chaos wird nicht groß sein.

In Git können Sie auch Unter-Repositorys verwenden, um die Firmware in das Hardware-Projekt zu integrieren, oder umgekehrt, selbst wenn es sich um separat verwaltete Repositorys handelt.

Bei größeren Projekten verwende ich häufig auch Bug-Tracking-Systeme, um Probleme und Lösungen zu verfolgen. Auch für HW und SW ist Mantis eine nette Version, die kostenlos verwendet werden kann.

Für Hardware-Revisionen generiere ich Gerbers oder was auch immer Sie haben, die mit dem Git Hash für diese Revision markiert sind. Diese Gerbers sind dann die einzigen diskreten "altmodischen" versionierten Inhalte in Ordnern von R01, 02 usw. Da Sie dies nicht möchten Generieren Sie sie die ganze Zeit neu, aber es handelt sich um resultierende Dateien. Sie sollten daher eigentlich nicht in Git selbst versioniert werden (da Ihre Design-Software beim Generieren von Produktionsinhalten deterministisch sein sollte, oder sonst ...).

Wenn es in R01 etwas Interessantes gibt, das in R02 nicht passiert (oder umgekehrt), haben Sie zwei Git Hashes, mit denen Sie Quelldateien vergleichen können, keine Sorge.

Abschließend möchte ich sagen, dass ein konzeptionelles Beispiel für ein Projekt ein Hardware-Repository enthält, in dem sich auch eine "BoardPinout.h" -Datei befindet. Diese Datei wird als remote versionierte Datei in das Firmware-Repository aufgenommen, das einige Schnittstellendefinitionsdateien enthält, die remote in das Software-Repository aufgenommen werden.

Das heißt, jedes Mal, wenn ich ein paar Signale ändere, ohne die allgemeine Funktionalität zu ändern, "aktualisiert" das HW-Projekt das BoardPinout, das dann aktualisiert und in der Firmware verwendet werden kann, und so weiter.

Asmyldof
quelle
1
Ist es wirklich jemals sinnvoll, Hardware und Firmware in verschiedenen Repos zu speichern? Wie wäre es ein Problem, sie in einem zu haben? Ich würde eher erwarten, dass es ein Problem ist, wenn Sie Änderungen an den zusammengehörigen Komponenten nachverfolgen müssen (z. B. müssen ausgetauschte E / A-Pins in verschiedenen Firmware-Zuweisungen berücksichtigt werden, und das Auschecken inkompetierbarer Versionen würde zu Chaos führen).
links um den
@leftaroundabout Zunächst einmal ist es nicht immer das, was Sie wollen, Ihr schnell wechselndes FW-Repo mit dem Großteil eines komplexen CAD-Entwurfs aufzublasen, aber Sie möchten möglicherweise auch die Bits über Sub-Repos und die Verknüpfung zwischen ihnen erneut lesen. Mit Git überhaupt nicht schwer zu machen und das behebt genau dieses Problem, ohne alle Arten von unangemessener Intimität zwischen Design-Trakten zu verursachen.
Asmyldof
1
"Meine Kunden sind nicht der Meinung, dass Dropbox sicher genug ist." Für die Versionierung von Dateien haben sie 100% Recht. Es ist besonders gefährlich, wenn mehrere Benutzer gleichzeitig Dateien ändern können, und noch mehr, wenn Sie mehrere Dateien haben, die wirklich eine einzige Ressource umfassen. Ich habe gesehen, dass binäre "Dateigruppen" auf diese Weise beschädigt werden (ESRI-Datei-Geodatabases, wenn Sie neugierig sind).
jpmc26
1
@ jpmc26 Das war ein überstürzter Kommentar, die Versionierung begann zunächst eher aus Sicherheitsgründen. Mit ein paar cleveren GitIgnore-Vorlagen lässt sich die Versionierung jetzt problemlos und mit allen damit verbundenen Vorteilen umhüllen. Ich stimme Ihnen in Bezug auf die freigegebene Dropbox voll und ganz zu. Bei einem Kunden verursacht dies endlose Probleme. In der Entwicklung befindliche Dateien, die endlose, in Konflikt stehende Kopien auf Computern erzeugen, wurden ausgeschaltet, während Teile von dev zu den nervigsten gehörten.
Asmyldof
@leftaroundabout: Dies hängt von der Beziehung zwischen Hardware und Firmware ab. Nehmen wir eine Analogie zu normalen Softwareprojekten. Würden Sie GIF- und JPG-Dateien zusammen mit Ihrer Website festschreiben? In diesem Fall ändern sich sowohl die Binärdatei als auch die Quelle miteinander, auch wenn sich die Bilder nicht so oft ändern. Aber ... würden Sie Apache- oder Nginx-Quellcode mit Ihrem Projekt festschreiben? Würden Sie den Quellcode des Linux-Kernels festschreiben? In diesem Fall sind Apache oder Nginx und der Linux-Kernel analoger zur Hardware - sie ändern sich, aber unabhängig von dem Code, den Sie schreiben, der auf ihnen ausgeführt wird
slebetman
5

1) Es lohnt sich auf jeden Fall, Schaltplan- / Board-Dateien zu versionieren. Auch wenn Sie Unterschiede nicht so einfach nachverfolgen können, haben Sie eine saubere Möglichkeit, zu einer bestimmten Hardwareversion zurückzukehren, wenn Sie mit einer alten Geräteversion arbeiten müssen.

2) Wir haben die folgende Struktur in unserer SVN.
/ tag
/ branch
/ trunk / hardware
/ trunk / software / firmware

Falls zutreffend, mit mehr Unterordnern wie vielleicht / Firmware und / ConfigTool für Software und / Mainboard und / Tochterboard oder so ähnlich für Hardware.

2) Tags werden aus Unterordnern erstellt, die nicht aus dem gesamten Trunk stammen, wie z. B. Tag / Mainboard-v1.2.345. Die Hardware (nämlich die Leiterplatte) enthält immer die SVN-Revision im Siebdruck oder in Kupfer, um einen direkten Bezug zu haben.

4) Abhängigkeiten zwischen Hardware und Firmware können komplex sein. IMO macht es nicht so viel Sinn, auf Repository-Ebene damit umzugehen, außer nützliche Kommentare zu Commits zu hinterlassen.
Ziehen Sie in Betracht, Hardwareänderungen mithilfe von Ersatz-E / A-Pins zu codieren. So etwas wie die Verwendung von 4 Pins zum Codieren von 16 verschiedenen Hardwareversionen. Wir haben auch einen einzelnen ADC-Eingang mit unterschiedlichen Widerstandswerten verwendet, um Versionen zu codieren. Auf diese Weise kann die Software "wissen", auf welcher Hardware sie ausgeführt wird, und bestimmte Funktionen ändern / deaktivieren / aktivieren.

Rev1.0
quelle
Genau. Ich habe auch eine gute Praxis beim Erstellen eines "Release-Bundles" gesehen - Schaltpläne, Stücklisten, Gerber, das ganze Los - anlässlich jeder Veröffentlichung für die Produktion. Sie nennen diese A, B, C usw. und archivieren sie dann irgendwo, wo das Team auf sie verweisen kann. Vergessen Sie auch nicht, zu verfolgen, welche Kabelmodifikationen Sie auf welchen Prototyp-Boards durchgeführt haben.
pjc50
@ pjc50: Eigentlich "bauen" wir auch Release-Bundles, aber außerhalb der Quellcodeverwaltung (aber mit einer Revisionsreferenz). Im Wesentlichen handelt es sich um eine exakte Kopie von allem, was der Hersteller erhalten hat. Wenn Sie die Hardwareentwicklung professionell mit Massenproduktion durchführen, ist es sehr wichtig, dass alle Informationen verfügbar sind, falls etwas schief geht. Wenn Sie sich nicht erinnern, ob Sie dem Board House "dieses eine wichtige Dokument" senden, in dem möglicherweise die benutzerdefinierte Kupferdicke der Leiterplatte angegeben ist, können Probleme auftreten.
Rev1.0