Ich glaube nicht, dass es ein Analogon zum täglichen Build für Hardware gibt. Es kann möglich sein, das Einchecken eines Schaltplans nicht zuzulassen, wenn er DRC (oder möglicherweise Simulation) nicht besteht, aber das ist ungefähr alles, was mir einfällt. Software-Leute haben den Vorteil, dass sie das fertige Produkt (größtenteils) sofort ausführen können und viele automatisierte Tools erhalten. Schematische Erfassungsprogramme und Simulatoren sind in Bezug auf Automatisierung, Versionierung usw. größtenteils nicht auf dem neuesten Stand, und es ist wirklich eine Schande. Ich würde gerne sehen, dass der Software-Design-Prozess für Hardware so gut wie möglich nachgeahmt wird, aber ich bezweifle, dass dies durchaus möglich sein wird.

Ein kleiner Fehler: Nur wirklich schlampige Entwickler verwenden tägliche Builds, da ein Build pro Tag bedeutet, dass Sie bis zu einem Tag warten müssen, um herauszufinden, ob Sie den Build gebrochen haben.

Die beste Lösung ist das Erstellen von und Testen Sie jede einzelne Änderung einzeln, bevor sie in den öffentlichen Zweig gelangt, und setzen Sie die Änderung zurück, wenn der Build in irgendeiner Weise beschädigt wird.

Es kann sehr schwierig sein, automatische Tests an einem Schaltplan oder einem Board-Layout durchzuführen unmöglich, aber alles, was Sie automatisieren können, sollte über etwas wie Hudson automatisiert werden. Dinge, die Ihnen in den Sinn kommen, sind:

• ERC
• DRC
• Stücklistenaktualisierung (Überprüfen Sie, ob die Teile vorhanden sind, verfügbar sind, und berechnen Sie die Gesamtkosten.)
• Generieren Sie Gerbers und andere Herstellungsdateien.
• Generieren Sie PDFs der Schaltplan- und Leiterplattenebenen sowie 3D-Renderings der PDB, Stücklistendifferenz und andere Dokumentationen.
• Legen Sie eine E-Mail mit der Festschreibungsnachricht und den Links zu den Ausgabedateien an die Entwickler-Mailingliste, damit Entwickler die Änderung problemlos überprüfen können. L. i>

Die Anzahl der Fehler, die automatisch abgefangen werden können, ist möglicherweise nicht besonders hoch. Wenn das CI-System jedoch die Ausgabedateien generiert, bedeutet dies, dass dies jedes Mal korrekt geschieht und Sie einige dumme Fehler nicht vergessen Einstellung bei manueller Ausführung.

Ich nehme an, wenn Ihre Tools dies unterstützen, können Sie Netzlisten exportieren und etwas damit tun, das Sie als sehr repetitiv und banal empfinden.

Eine nützliche Sache, die ich mir vorstellen kann, ist die Erstellung der Stückliste. Ich habe in einer kleinen Firma gearbeitet, die die Hardware-Schaltpläne und Netzlisten entworfen und die Teile spezifiziert hat, und dann haben wir das Layout an PCB-Design-Experten ausgelagert.

Wir hatten ein sehr hilfreiches Excel VBA-Programm zum Einlesen die Netzliste und generieren Sie die Teileliste aus einer Datenbank von Teilen.

Die Idee eines täglichen Software-Builds besteht darin, Probleme zu erkennen, die durch Änderungen verursacht werden.

Wenn Sie den Schaltplan ändern, müssen Sie die Leiterplatte vor der Herstellung testen. Sie können die Risiken durch reduzieren Protokollieren und Überprüfen aller Änderungen.

Ich denke, das nächste Äquivalent besteht darin, das Produktionstestgerät und das Testskript für Ihre Schaltung so schnell wie möglich zu entwickeln. Stellen Sie sicher, dass Sie alle wichtigen Funktionen testen. Die Testvorrichtung emuliert, welche Benutzeroberfläche und Sensorhardware an der Schaltung angebracht sind. Das Testskript "Design Verification" wird wahrscheinlich mehr Tests haben und länger dauern als das Produktionstestskript, bei dem Sie hauptsächlich testen, ob die Teile ordnungsgemäß miteinander verbunden sind.

Wenn Sie also Änderungen an der Firmware oder vornehmen Auf der Schaltung selbst können Sie gelegentlich den Entwurfsüberprüfungstest durchführen, um sicherzustellen, dass Sie keine Regressionen verursacht haben. Es ist auch hilfreich, reduzierte Testskripte zu erstellen, um einen Aspekt der Leistung der Schaltung zu testen, z. B. das Testen der Reaktion über Liefervariationen hinweg oder eine besonders knifflige Zustandsmaschine, für deren Versuch ein Mensch zwei Seiten mit Anweisungen benötigt. Diese Kurzskripte sollen Zeit sparen und eine bessere Testabdeckung bieten als das Vollskript. Sie führen den Überprüfungstest jedoch immer durch, bevor Sie Änderungen am Schaltplan oder an der Firmware vornehmen. Führen Sie für das endgültig freigegebene Design den Verifikationstest über die Temperatur hinweg durch.