ChinaCluster - Aufbau der Hardware

Mit dem ChinaCluster bin ich in den letzten Tagen recht gut vorangekommen. Der Aaron hat mir seine überragend gute Arbeit zugesendet. Und zwar einen Sockel mit bereits darauf aufgebauten Halterungen für die OrangePi - Nodes, das Netzteil, den Netzwerk-Switch, das Relais-Board und die Platinen zur Verteilung der Spannung des Netzteils zur Stromversorgung aller Komponenten.

Ich bin sehr begeistert von der Optik, der Verarbeitung und den vielen Details die Aaron eingearbeitet hat - sogar einen Dummy um die Abmessungen des Cubietruck nachzubilden hat er für den Aufbau hergestellt.

ChinaCluster

Hier ein paar Bilder von den Details.

Der Cubietruck-Dummy

Die Stromverteiler-Platine

Relais-Board

Netzteil

Die Halterungen für die Nodes

Netzwerk-Switch

Da Aaron bereits alle Komponenten fertig aufgebaut hatte konnte ich direkt mit der Verkabelung starten und die Position des Cubietruck - der noch zwei Zusatzplatinen aufgesteckt hat - festzulegen und einzurichten.

Aufgrund der enormen Abmessungen sitzt der Cubietruck doch an einer anderen Stelle als zuvor, wo er jedoch aufgrund der zusätzlich an diesen befestigten Platinen weniger Platz benötigt.

Neue Position vom Cubietruck

Die Verkabelung war insgesamt weniger spektakulär. Die Netz-Leitungen wurden mit entsprechend isoliertem flexiblen Kabel gelegt, dabei habe ich Kabelschuhe verwendet um den Netzschalter - in den auch gleich die Kaltgerätebuchse und eine 1A Sicherung integriert ist - an das Netzteil anzuschließen.

Kabel am Netzschalter/der Kaltgerätebuchse

Verkabelung am Netzteil

Die Platinen zum versorgen einzelner Komponenten sind mit jeweils zwei Adern an das Netzteil angeschlossen, die Verbindung wird auch hierbei über Schraubklemmen bewerkstelligt.

Stromverteiler-Platinen mit Verkabelung

Der Cubietruck und der Netzwerk-Switch sind direkt mit dem Netzteil verbunden.

Die OrangePis, der Cubietruck sowie der Netzwerk-Switch werden jeweils über DC-Stecker mit Spannung/Strom versorgt und erhielten jeweils einen Ground-Leitung. Die 5V führenden Zuleitungen werden für die OrangePis über das Relais-Board gesteuert. Die Steuerleitungen des Relais-Boards laufen von der Platine direkt auf eine der Erweiterungs-Platinen am Cubietruck. Nicht jedoch die Spannungsversorgung der Relais-Platine. Diese ist gesondert an 5V und GND angeschlossen.

Relais-Board mit Verkabelung

Der wohl am unhandlichste Teil der Verkabelung sind aktuell noch die Netzwerkkabel. Diese sind mit ihren 50cm drastisch zu lang. Auch ein aufrollen und wickeln hilft nicht darüber weg das diese übermäßig über die definierten Dimensionen des Innenlebens herausragen. Hier muss noch eine Lösung geschaffen werden, am einfachsten kürzt man die Kabel und Crimpt diese auf einer Seite neu.

Die maximale Länge welche noch zu verlegen wäre, aber nicht stören würde liegt bei etwa 15-20cm.

Netzwerkkabel-Größe

Auch das TFT-Display und das MX-Board haben bereits einen Anschluss gefunden und sind bereit um später, sobald die Wände des Gehäuses und der Deckel das Cluster fertiggestellt sind, eingebaut zu werden. Die Aktuelle provisorische Position sieht man im folgenden Bild.

MX-Board und TFT-Display

Zum Status der Software kann ich die folgenden Punkte nennen:

• Alle Nodes verfügen über eine 8GB SD-Karte von denen das darauf installierte Linux gestartet werden kann (armbian basierend).
• Der Cubietruck bootet ebenfalls von einer 8GB SD-Karte ein Linux (armbian).
• Die ChinaCluster Management Software läuft auf dem TFT-Display und ist mit den Tastern auf dem MX-Board bedienbar.
• Die ChinaCluster Management Software kann die Nodes und den Cubietruck steuern (reboot shutdown reset), teils per SSH oder über das Relais-Board.
• Die ChinaCluster Management Softwareüberwacht den Zustand der Nodes per ICMP-Ping.
• Die Cluster-Nodes erhalten per DHCP-Server eine Cluster-Interne IP-Adresse (gesondertes Netzwerk).
• Der Cubietruck ist Firewall und Router für die Cluster-Nodes, welche per NAT auf das externe Netzwerk zugreifen können.
• Der Cubietruck stellt per NFSD für das Clustering spezifische Software (z.B. OpenMPI) für alle Nodes bereit.
• Beim Systemstart des Cubietruck wird eine Sequenz gestartet welche nach und nach die Nodes einschaltet und booten lässt.
• Die Netzwerkverbindung des Cubietruck in mein Intranet wird gerade über WLAN hergestellt. Mit dem ChinaCluster Manager ist es jedoch möglich auf die zweite LAN - Schnittstelle umzuschalten. Diese wird über einen USB zu LAN - Adapter bewerkstelligt da die Cubietruck-eigene bereits für das interne Netzwerk verwendet.

Aktuell arbeite ich daran mein Management-Tool - welches die Cluster-Nodes automatisch auf meine Anforderungen konfigurieren und aktuell halten soll. Ich werde bei Gelegenheit und nach entsprechendem Fortschritt darüber berichten.

Das aktuelle Gesamtsystem

ChinaCluster

Getrieben von der Begeisterung über die vielen im Internet kursierenden Projekte, bei denen aus diversen Embedded Systems ein Cluster zusammengebastelt wird habe ich mich dazu entschieden es ebenfalls zu tun. Ich baue einen Cluster. Allerdings sehe ich es nicht ein viel Geld dafür auszugeben. Und aus meiner Sicht ist das Thema insoweit bereits abgenutzt wenn man nur ein paar Raspberry Pi's dazu verwendet - das Projekt wird von der Community viel zu gut unterstützt! ;-)

Für meinen Cluster sollte das umsetzen/aufbauen im Vordergrund stehen und nicht der simple Aufbau durch einfaches zusammenstecken von Verbraucherfreundlichen Komponenten. Daher habe ich mich dafür entschieden alle Hauptkomponenten ausschließlich von chinesischen Händlern zu bestellen, daher auch der Name ChinaCluster:

• Switch (8Port 10/100 MBit)
• Netzteil 5V 12A
•  Netzwerkkabel 0.5M - Schirmung unbekannt aber das Kabel ist blau
• 5x OrangePi PC - ARM CPU (4 cores), 1GB RAM
• 5x SD Karten 8GB
• 230V Buchse mit Sicherung und Schalter
• 8 Port Releais-Platine
• ILI9341 2,2" TFT - Display

Aus anderen Quellen habe ich noch die folgenden Komponenten erhalten, bestellt oder in der Bastelkiste gefunden:

• MX-Board von Aaron - auf tindie verfügbar
• Diverse eigens entworfene Adapter-Platinen für den Cubietruck - auf oshpark verfügbar
• Eine eigens entworfene Platine für die Verteilung der 5V-Spannung des Netzteils an die einzelnen Komponenten
• Diverse Stecker und Buchsen welche hauptsächlich auf eBay geklickt wurden
• Ein 5 Jahre alter PC-Gehäuse-Lüfter

MX-Board von Aaron

Cubietruck Adapter - Platinen

Weiterhin ist als Master-Einheit des Clusters ein Cubietruck angedacht. Auf dem Cubietruck ist ein armbian.com installiert - jedoch ohne X11. Dieser wird das Herzstück des Clusters sein und die folgenden Aufgaben übernehmen:

• Default-Gateway in ein externes Netzwerk per LAN/WLAN - für die Cluster-Nodes
• Firewall zum Schutz der Cluster-Nodes von außen
• Cluster Master-Einheit
• Die Clustering-Software wird zunächst OpenMPI 1.10.0 sein
• DHCP-Server für das Cluster-eigene Netzwerk
• Steuerung des ILI9341 2,2" TFT - Displays
• Abfrage der Tasten des MX-Boards sowie Steuerung derer Beleuchtung
• Bereitstellung des User-Interfaces auf dem TFT-Display (python curses Implementierung)
• NFS-Server
• Konfiguration und Überwachung der Cluster-Nodes

Im Moment arbeite ich an der Software für das User-Interface, Steuerung per MX-Board und die Anzeige auf dem TFT funktionieren bereits. Inhaltlich, was die möglichen Konfigurationseinstellungen und Anzeigen wie z.B. der Cluster-Auslastung angeht müssen noch implementiert werden. Die Automatisierungsscripte für das Management und die Konfiguration der Cluster-Nodes ist soweit implementiert das diese getestet werden können, sobald die Hardware fertig aufgebaut ist.

curses based python user interface

Das Gehäuse dafür wird aktuell von Aaron gebaut - es wird wirklich sehr schick, man kann darauf gespannt sein. Die Ersten Bilder lassen bereits erahnen wohin die Reise bzw. das Design gehen wird. An dieser Stelle möchte ich Aaron nochmals dafür danke dass er sich darum kümmert!

Skizze und Gehäuse

Für das Gehäuse fehlen - aus meiner Sicht - noch die Adapter-Platinen für das Ausführen der Cubietruck-Spezifischen Anschlüsse, wie USB/LAN und HDMI. Diese werden dazu benötigt um den Cluster direkt als Desktop-Rechner verwenden zu können, falls man diese nicht in das eigene Netzwerk einbinden kann oder möchte.

Auch angedacht ist eine Beleuchtung des Systems hinzuzufügen, welche beispielsweise die Systemauslastung oder den Fortschritt von Aktivitäten darstellen kann und zudem noch den optischen Gesamteindruck deutlich verbessert.

Meine Pläne für Implementieren von Software, welche meinen Cluster unterstützt haben sich aktuell noch nicht auf ein Thema spezialisiert. Interessant ist aktuell für mich rein der Aufbau von einem solchen System und dieses dann zunächst mit Beispielen der Implementierung unter Verwendung von OpenMPI zu testen.

Das Projekt ist aktuell nur im privaten Git auf www.okoyono.de verfügbar, bei Gelegenheit werde ich dieses jedoch auf github einstellen.

ILI9341 2,2" TFT - Display am Cubietruck

Vor ein paar Wochen habe ich mit bei AliExpress ein 2,2" TFT Display für meinen Cubietruck bestellt. Der Display-Controller auf bzw. hinter dem Display ist ein ILI9341. Leider gab es in der Lieferung des Displays und auch auf der Webseite des Shops keine
weiteren Informationen zu dem Produkt.

Ich bin während meiner Recherche auf diverse Seiten und Youtube-Videos gestoßen, bei denen entweder nur von Problemen berichtet wurde, unvollständig verschiedene Einrichtungsmöglichkeiten dargestellt, oder einfach nur simpel das Ergebnis - ein Display in Aktion - gezeigt wurde.

Um es kurz zu fassen... Das Display kann im Linux-System als Framebuffer-Device eingerichtet werden. Der Zugriff auf das Display geschieht mittels SPI-Bus. Auch ich werde an dieser Stelle nicht auf alle Details eingehen, aber zumindest die Punkte versuchen abzudecken die mir persönlich bei der Einrichtung gefehlt haben.

Das Display verfügt über 9 Pins, davon werden zwei für die Spannungsversorgung verwendet, vier für den SPI-Bus (MISO, MOSI, SCK und CS) und die restlichen drei werden für die Steuerung der LED-Beleuchtung, eine RESET-Leitung und eine Register-Select-Leitung verwendet.

Diese Pins müssen an einen passenden Pinheader des Cubietruck angeschlossen werden.
Im folgenden Bild habe ich dies für meine Hardware eingezeichnet.

Damit ist es das jedoch nicht gewesen, denn der Cubietruck weiß noch nichts davon das an den definierten Pins ein Display angeschlossen ist. Dies teilt man dem Kernel des Cubietrucks über eine Datei im /boot - Verzeichnis mit. Die Datei heißt script.bin. Um in diese die Konfiguration für das Display einzutragen muss man diese zunächst von ihrem Binären Format in ein menschen-lesbares Format umwandeln. Dies geschieht mittels einem normalerweise vorinstalliertem Tool - bin2fex.

root@cubietruck:/boot# bin2fex script.bin script.fex

Öffnen man nun die Datei mit einem Editor seiner Wahl sollte man nach den folgenden beiden Inhalten suchen und diese entsprechend den Beispielen unten anpassen.

Suchen nach spi2_para und die folgenden Anpassungen durchführen.
 
[spi2_para]
spi_used = 1
spi_cs_bitmap = 1
spi_cs0 = port:PC19<3>
spi_cs1 = port:PB13<2>
spi_sclk = port:PC20<3>
spi_mosi = port:PC21<3>
spi_miso = port:PC22<3>

Damit ist nun der SPI-Bus zum Display deklariert, es fehlen noch die übrigen Pins.

Suchen nach gpio_para und ebenfalls die folgenden Anpassungen durchführen.

[gpio_para]
gpio_used = 1
gpio_num = SET THE NUMBER OF DEFINED GPIO PINS
...
gpio_pin_3 = port:PB03<0><0>
gpio_pin_4 = port:PB04<0><0>
gpio_pin_5 = port:PB02<0><0>
...

Um das Display mit dem Cubietruck zu verbinden habe ich mir eine kleine Adapter-Platine erstellt (siehe Bild), diese kann man bei OSHPark.com ansehen und bestellen.

Achtung es kann sein das bereits gpio_pins deklariert sind, diese sollte man nicht anfassen sondern ggfls. die Nummerierung der neuen Pins anpassen. Zudem muss die Anzahl der zu verwendenden Pins im Kopf des Blocks korrigiert werden.

Wurden alle Änderungen durchgeführt muss die Fex-Datei wieder in sein binäres Pendant
umgewandelt werden. Dies geschieht mit dem Tool fex2bin.

root@cubietruck:/boot# bin2fex script.fex script.bin

Damit ist nun der Kernel und die Cubietruck-Hardware - nach einem Reboot - bereit auf das Display zuzugreifen.

Nun muss das Kernel-Modul geladen werden. Es handelt sich dabei um das fb_ili9341 von GitHub welches nun auch Bestandteil der Linux-Kernels ist.

root@cubietruck:/boot# modprobe fbtft dma=1
root@cubietruck:/boot# modprobe fbtft_device custom name=fb_ili9341 buswidth=8 \
                                                       gpios=reset:4,led:5,dc:3 busnum=2 rotate=270 bgr=1 \
                                                       mode=0 speed=64000000 txbuflen=64 fps=25 debug=1

Zunächst wird DMA aktiviert und daraufhin das Kernel-Modul mit einer Standard-Konfiguration geladen. Wichtig hierbei ist das der Parameter gpios die korrekten Pin-Nummern angegeben werden. Der LED-Pin kann bei Bedarf auch weggelassen werden.

Möchte man Problemen auf den Grund gehen kann man beispielsweise den Parameter debug auf den Wert 7 setzen, um die Detailtiefe der Debug-Ausgaben im Syslog drastisch zu erhöhen. Die Bildwiederholrate reduziert sich bei höheren Debug-Leveln jedoch sehr stark. So dauert es beispielsweise auf meinem System um die 35 Sekunden um ein Bild auf dem Display anzeigen zu lassen, wenn die Option debug auf den Wert 7 eingestellt ist.

Ist das Modul korrekt geladen wird unter /dev ein neues Framebuffer-Device eingefügt. Die LED-Beleuchtung wird nach dem erfolgreichen Ladevorgang ebenfalls eingeschaltet, sofern man den LED-Pin im gpios-Parameter angegeben hat. 

Der Parameter rotate gibt in Grad an wie das Display ausgerichtet sein soll. Mit der Option busnum wird angegeben welcher SPI-Port für die Kommunikation mit dem Display verwendet werden soll.
Im Beispiel oben ist der Wert 2 angegeben, dies liegt daran das oben in der Konfiguration der GPIO-Ports für die Hardware SPI2 konfiguriert wurde.

Der Wert 64 bei dem Parameter txbuflen gibt an wie groß der Byte-Buffer zur Datenübertragung an das Display verwendet werden soll. 
ACHTUNG, hier darf der Wert 64 nicht überschritten werden, da die Kommunikation sonst nicht funktioniert. Zumindest nicht mit meiner Hardware - diese hat dedoch auch geneu 0 kB DMA-Buffer zur Verfügung.

Ein Forums-Thread zu dem Problem existiert bereits.

Um zu testen ob das Display korrekt arbeitet kann man z.B. mit dem Tool fbi ein Bild darauf anzeigen.

root@cubietruck:/boot# fbi -d /dev/fb2 -T 1 -noverbose -a

Interessanterweise funktioniert das korrekte Laden des Kernel-Moduls per /etc/modules.conf - Datei nicht. Zumindest nicht auf meinem Armbian Linux. Ich habe die oben stehenden Aufrufe von modprobe in die /etc/rc.local eingetragen.

Möchte man nun noch ein Terminal auf das Display binden kann man das mit der folgenden Zeile einrichten. Auch diese habe ich in die rc.local eingetragen.

root@cubietruck:/boot# con2fbmap 1 2

Damit wird tty1 auf das Framebuffer-Device /dev/fb2 gebunden. !!!ACHTUNG nachdem das Kernel-Modul geladen wurde muss einige Zeit gewartet werden bis con2fbmap aufgerufen werden darf, da das Laden des Moduls einige Zeit im Hintergrund benötigt bis das Laden abgeschlossen ist!!!

Das Ergebnis wird dann in etwa wie auf dem folgenden Bild aussehen.

Wenn jemand mit hier einen Tipp hat wie oder was man verbessern könnte, dann bitte gerne einen Kommentar auf diesen Beitrag hinterlassen. Diese werden aber nicht direkt hier im Blog freigegeben. Ich werde diese dann bei Gelegenheit durch gehen und entsprechend manuell freigeben.

Ich hoffe das dieser kurze Artikel anderen weiter helfen wird und das Mysterium um das ILI9341 - Display etwas deklassiert. Im Nachhinein muss ich jedoch auch sagen das es deutlich einfacher gewesen ist alles einzurichten und das es auch dieses mal deutlich einfcher hätte sein können wenn die bereits vorhandenen Dokumentationsbeispiele detailierter und etwas mehr über den "Tellerrand" beschrieben worden wären.

Die Größte Hilfe bei der Einrichtung bot mit ein in russischer Sprache geschriebener Kommentar zu einem Youtube-Video welches das Display in Aktion zeigt. Dank dem Google-Translator war die sprachliche Hürde an dieser Stelle zu meistern.