Wieder ein neues Thema - ist bei der Verwendung meines ChinaClusters aufgekommen. Es passiert das die Node2 und Node4 nicht bei Einschaltvorgang starten. Warum ist mir momentan noch unbekannt, dem muss ich noch nachgehen. Wie stellt man das nun aber richtig an?
Jedes der OrangePi PC- und OrangePi One-Systemen besitzen jeweils über einen 3-Pin-Header an dem ein UART-Anschluss (3,3V LVTTL) mit jeweils einer Rx-/Tx und GND-Leitung ausgeführt ist. An diesem Port kann mit einer adäquaten Gegenstelle der Bootprozess des Linuxsystems, sowie den zuvor ausgegebenen Meldungen des Bootloaders etc. empfangen werden. Sollte also an einer Stelle - innerhalb der ersten Sekunden - des Bootvorgangs ein Problem auftreten kann dies dort, zumindest Theoretisch oder auch mit Glück, abgelesen werden.
Nun ist der Aufbau des Clusters aber nicht unbedingt so gestaltet dass man ohne Probleme die Hand hinein stecken kann um ein Kabel auf einen 3-Pin-Header aufstecken zu können.
Es wird also ein Kabel benötigt das dort dauerhaft angebracht bleiben kann. Nun man könnte jeweils umstecken, sollte ein Problem auftreten sein.
Da aber die Probleme nicht wiederholt sondern jeweils nur einmal ausgegeben werden, müsste man nun bei jedem Start je ein Gerät und auch nacheinander und über einen Adapter, vor dem Einschalten der Node anschließen und die BootUp-Meldungen einzeln beobachten.
Da mir persönlich aber solche wiederkehrenden und immer gleichen Aktivitäten furchtbar großen Spaß machen, kam mir die passende Idee.
Ich benötige nicht nur eine Möglichkeit mit der die UART-Verbindungen der Embedded-Systemen einzeln aus dem Cluster-Gehäuse heraus verfügbar zu machen, sondern auch gleich intern automatisch mitloggt und für einen späteren Zeitpunkt zur verfügbar stellt.
Nun soll dabei das zuverlässigste Teil im Cluster der Master sein, welcher im idealen Fall nicht beobachten muss. Das definiere ich mal so, unabhängig davon ob der Cubietruck tatsächlich das stabilste System ist in dem Rechner-Verbund.
Da dieser aber nicht über die benötigten sechs U(S)ART-Eingänge verfügt, muss auch hier noch eine Lösung gefunden werden.
Man könnte nun sechs USB zu UART-Wandler kaufen und diese mittels einem USB-Hub an den Master anschließen was aber leider nur zu noch mehr Kabel im Gehäuse führt und ich absolut vermeiden möchte (man denke an den Platzmangel).
Die nächste Alternative, welche mir sehr schnell in den Sinn gekommen ist, ist eine Art Multiplexer für UART zu benutzen. Also ein Gerät dass in der Lage ist zwischen mehreren U(S)ART-Leitungen umzuschalten oder parallel puffern zu können.
Die Letztere Variante bedeutet jedoch deutlich mehr Aufwand bei der Umsetzung und beide Varianten sind am Markt schlicht nicht verfügbar.
Der nächste Schritt ist es nun also gewesen eine Elektronik zu entwerfen die in der Lage ist den eben genannten ersten Fall umzusetzen. Ein Gerät das in der Lage ist zwischen mehreren U(S)ART-Schnittstellen umzuschalten und am besten gleich noch mit integrierter USB-Schnittstelle, über die das System auch steuerbar ist.
Dabei herausgekommen ist meine USB2SerialMux - Schaltung. Auf diesem befindet sich ein AVR ATMega32U4 Mikrocontroller von ATmel, ein Spannungsregler, diverse Kondensatoren, LEDs und zwei HCT7451 8-Kanal Multiplexer.
Die Multiplexer sind jeweils mit acht Pins einer Pinheader-Reihe verbunden, eine weitere Reihe von 8 Pins ist für den GND-Anschluss vorhanden.
Einer der Muxe ist mit der USART-RX-Leitung des Mikrocontrollers verbunden und der andere Mux mit der TX-Leitung des AVR.
Weiter sind die beiden Multiplexer jeweils parallel mit insgesamt drei Steuerleitung des AVR verbunden. Damit sind die 8 Steuerleitungen der Muxe einzeln auswählbar.
Auf der ersten Version der Platine ergaben sich trotz der einfachen Schaltung ein paar grobe Fehler welche vermieden hätten werden können. So hatte ich schlichtweg den ISP-Header nicht eingeplant, die Ground-Leitungen des AVR gar-nicht erst verbunden und an dern Multiplexern einen weiteren Spannungs-definierenden Eingang mit VCC statt GND verbunden.
Diese Fehler waren jedoch schnell korrigiert, das Ergebnis kann sich trotzdem sehen lassen.
Auf dem neuen Layout der Platine sind diese Fehler natürlich allesamt behoben. Weiter habe ich diverse optionale Widerstände verschiedene Leitungen eingeführt um die Multiplexer ggfls. etwas schützen zu können.
Die Software des Mikrocontrollers besteht im wesentlichen aus einem LUFA Dual VirtualSerial Demo-Programm, welches ich so angepasst habe dass man auf dem einen virtuellen seriellen Port die empfangenen Daten meiner Nodes sehen kann, und auf einem zweiten seriellen Port mittels Steuerkommandos den Multiplexer-Kanal auswählen und die benötigte Baudrate festlegen kann.
Da die Bedienung per Terminal-Programm und der Verwendung eines binären Kommunikationsprotokolls - welches ich dazu implementiert habe - jedoch nicht ganz komfortabel ist, habe ich zudem ein Python-Script geschrieben mit dem die Einstellungen problemlos per Kommandozeile vorgenommen werden können.
Der findige Windows-Anwender kann sich die entsprechenden Script-Aufrufe natürlich auch in verschiedenen Batch-Files per Klick verfügbar machen. Hier die Ausgabe der verfügbaren Parameter:
Wie im vorhergegangenen Screenshot zu sehen ist kann mittels diesem Script die Baudrate der Verbindung zu den angeschlossenen Systemen verändert werden, sowie die aktuell zu verbindende Multiplexer-"Leitung" gesetzt und jeweils ausgelesen werden. Damit sind auch unterschiedliche Baudraten möglich, indem man vor dem umschalten bereits die Baudrate auf die benötigte umstellt.
Für den Cluster bedeutet dies nun das lediglich die sechs 3-Pin-Header mit der USB2SerialMux - Platine verbunden werden müssen und diese dann mit dem Cluster-Master. Und dieser kann dann mit Hilfe von verschiedenen Tools - zeit-gesteuert ab dem Zeitpunkt des Einschaltens der ersten Node - durch die einzelnen Kanäle des Multiplexers schalten und die empfangenen Daten entsprechend für die spätere Verwendung loggen. Auch hierzu existiert bereits ein kleines Shellscript welches ebenfalls im Tools-Ordner im Repository liegt.
Das Projekt ist wie gewohnt auf git.okoyono.de verfügbar. Ebenfalls ist die aktuelle Version des benötigten des Bootloaders verfügbar und diverse Screenshots wie die Fuses des AVR über den ISP-Header gesetzt werden müssen, NACHDEM der neue Bootloader per ISP auf den AVR übertragen worden ist.
Die Platinen können direkt von OSHPark bestellt werden. Eine Liste der benötigten Bauteile kann dem Schaltplan (KiCAD) entnommen werden.
Hier noch ein Bild der fertigen Platine in der ersten Version, mit den oben genannten Korrekturen...
Und hier noch eine 3D-Darstellung der aktuellen Version v0.2, welche bei OSHPark bestellt werden kann.
Eine fertig aufgebaute Version inklusive aller Bauteile und deren Aufbau und Test kann ich aus zeitlichen Gründen leider nicht anbieten.