Embedded-Systeme sind in der heutigen technologiegetriebenen Welt allgegenwärtig. Sei es ein internetverbundener Rasierer oder ein komplexes Automobil, eingebettete Geräte sind das Herzstück der meisten elektronischen Geräte, die wir heute verwenden. Bestehend aus einem oder mehreren Mikroprozessoren, können eingebettete Systeme die Elektronik vereinfachen, indem sie die Komplexität auf die Software auslagern. Da eingebettete Geräte größer und komplexer werden, gilt dies auch für die gedruckten Schaltungen (PCBs). Oft wachsen diese Geräte zu mehreren Platinen heran und werden zu größeren Baugruppen, als ursprünglich beabsichtigt.
In diesem Artikel werden wir die Architektur-Abwägungen und Überlegungen für eingebettete Systeme, die aus mehreren PCBs bestehen, näher betrachten. Wir werden die Vorteile, Designüberlegungen und Herausforderungen, die mit Mehr-PCB-Systemen verbunden sind, behandeln.
Obwohl es ideal ist, Ihr Gerät auf einer einzigen PCB zu halten (sowohl aus Gründen der Einfachheit als auch der Kosten), müssen wir manchmal den Schritt machen, unser Design auf zwei oder sogar mehr PCBs aufzuteilen, um unsere Designziele zu erreichen. Einige Gründe, warum wir unser Produkt auf mehrere Platinen aufteilen möchten, sind:
Aus diesen Gründen (und mehr) betrachten wir das Design einer Baugruppe, die aus mehreren PCBs besteht, aber die Herausforderungen auf der Seite der eingebetteten Firmware sind nicht ohne ihre Komplexitäten.
Jetzt, da wir den Fall für die Verwendung mehrerer PCBs (wo anwendbar) dargelegt haben, ist es wichtig, die Designüberlegungen beim Architektieren des eingebetteten Systems zu verstehen. Sowohl aus Hardware- als auch aus Softwareperspektive gibt es Nuancen, die wir nicht so sorgfältig abwägen, wenn wir alles auf eine einzige Platine setzen.
Die erste Überlegung, die uns in den Sinn kommen sollte, ist die Kommunikation zwischen den Platinen. Wie werden die einzelnen Platinen miteinander kommunizieren? Welche Art von Rechenleistung (wenn überhaupt) befindet sich auf jeder Platine? Vielleicht besteht eine Platine aus dem Gehirn, während die anderen aus Sensoren bestehen? Während wir unsere Übertragungsprotokolle sorgfältig auswählen, sei es I2C, SPI, UART, Ethernet usw., müssen wir auch die Übertragungsleitungen, Signalintegrität und vor allem den Signaltransfer durch Verbindungsstecker zwischen den Platinen abwägen. Das Schlimmste, was einem Designer passieren kann (und glauben Sie mir, ich war schon dort), ist, das gesamte System zu entwerfen und die PCBs vom Hersteller zurückzuerhalten, nur um festzustellen, dass ein oder zwei Taktssignale fehlen. Wir vergessen auch oft, Ersatzpins an unseren Verbindungssteckern zwischen den Platinen vorzusehen, und versuchen, die Pinanzahl maximal auszureizen. Das ist etwas, das uns am Ende wirklich beißen kann. Ein Design mit einem Multi-Board-Projekt im Sinn, wie die Multi-Board Assembly-Funktion in Altium Designer, ist ein Muss, wenn so viele Kommunikationsleitungen zwischen PCBs verlegt werden.
Wir müssen auch darüber nachdenken, wie wir die Stromversorgung verteilen, besonders wenn wir Stromschienen mit unserem Mikroprozessor überwachen werden. Wir möchten Zugänglichkeit zum „Gehirn“ ermöglichen, damit es auf katastrophale Ereignisse überwachen kann, aber wir müssen auch Schaltnetzteilrauschen, Stromverteilung für schwere Lasten und ob unsere Verbindungssteckerpins für diese Art von Leistung ausgelegt sind, berücksichtigen.
Zuletzt, obwohl es nicht direkt mit der Software des eingebetteten Systems zusammenhängt, spielt auch das mechanische Design eine wichtige Rolle. Druckknöpfe, Touchscreens und andere physische Schnittstellen zum Benutzer sind immer noch mit dem Mikroprozessor verbunden und müssen berücksichtigt werden. Kann die Verkabelung so verlegt werden, dass der Mikroprozessor auf seine Eingänge zugreifen kann? Haben wir die Signalintegrität des hochgeschwindigkeitsdigitalen Ausgangs berücksichtigt, während wir ihn von einer Platine zur anderen führen? Das sind Dinge, die wir bedenken müssen, wenn wir unser eingebettetes Gerät entwerfen.
Eine der am meisten unterschätzten Herausforderungen, die ich immer wieder in wachsenden Startups (und sogar großen Unternehmen) gesehen habe, war die Plage der Versionskontrollsysteme zwischen Software und Hardware. Die Verwaltung von Software-Releases gegenüber PCB-Revisionen ist zu einem nie endenden Kampf geworden, der oft zu Verwirrung, Verzögerungen und sogar Produktfehlern führt.
Beispielsweise erforderte in einem Startup, mit dem ich gearbeitet habe, eine geringfügige Modifikation der PCB eine Neufertigung und somit ein Update der Firmware (wenn auch minimal). Aufgrund schlechter Versionskontrolle hat das Engineering-Team die neue Firmware auf älteren PCB-Versionen eingesetzt, was zu unerwarteten Brownouts und einer periodischen Rauchwolke führte. Glücklicherweise haben wir es bemerkt, bevor das Produkt verschickt wurde, aber es war tagelang ein absoluter Albtraum.
Um diese Fallstricke zu vermeiden, ist es entscheidend, ein solides Versionskontrollsystem zu etablieren und eine klare Kommunikation zwischen den Hardware- und Software-Teams sicherzustellen. Selbst ein einfaches Versionskontrollsystem wie ein Git-Hash (oder semantische Version) für die Firmware, zusammen mit einer grundlegenden unterstützten Lookup-Tabelle für Hardware-Revisionen, kann ausreichend sein, um zu beginnen. Mit der Zeit reduzieren ausgefeiltere Mechanismen wie die Hardware-Revisionserkennung in der Firmware (und somit die Überprüfung der Kompatibilität) ebenfalls Verwechslungen.
Neben der Softwareversionierung ist es auch wichtig, über die Modularität des Codes nachzudenken. Bei Spaghetti-Code könnte das Austauschen einer Sensorplatine mit neuen Chips oder Sensoren zu einem Refactoring-Albtraum werden. Das Modularisieren Ihrer Gerätetreiber und das Erstellen von Hardware-Abstraktionsschichten ermöglicht es, Komponenten über Jahre hinweg leicht auszutauschen. Dies ist etwas, das mit der Zeit immer beliebter geworden ist, da eingebettete Systeme an Komplexität zugenommen haben.
Wenn wir über die Architektur eingebetteter Systeme nachdenken, müssen wir nicht immer klein denken. Raumfahrzeuge und Automobile sind extrem komplexe eingebettete Systeme, aber auch Smartphones. Ob wir einen internetverbundenen Löffel oder den nächsten Satelliten entwerfen, das Verständnis der Kompromisse für die Architektur eingebetteter Systeme ist äußerst wichtig, wenn man für mehrere PCBs entwirft. Wir haben viele Konzepte in diesem Artikel erkundet, aber es gibt noch viele mehr, die Sie zweifellos auf Ihrer Reise finden werden.