Blog

RED Brick Zustandsbericht

Es ist nun schon über einen Monat her, dass wir über das RED Brick berichtet haben (RED Brick im EMV Labor). In der Zwischenzeit ist aber viel passiert. Im Blogeintrag Softwareinfrastruktur haben wir die verschiedenen Aufgabenbereiche vorgestellt. Wir möchten euch hier ein Update geben:

Stapelkommunikation zu anderen Bricks: Die Stapelkommunikation zwischen RED Brick und Bricks machte uns deutlich mehr Aufwand als angenommen. Das bisherige Protokoll konnten wir nicht weiter nutzen, daher mussten wir es umstellen. Dieses Protokoll haben wir in der Zwischenzeit mehrfach verworfen und quasi neu implementiert, da uns die Eigenheiten der DMA Controller auf dem RED Brick und auf den anderen Bricks immer wieder Probleme machten. Wir haben nun aber endlich ein Protokoll welches stabil funktioniert, Fehler korrigiert und dazu noch performant ist.

Ethernet und RS485 Extension: Diese beiden Extensions wollten wir zum Verkaufsstart unterstützen. Unsere Ethernet Extension ist mit einem Wiznet W5200 Ethernet IC ausgestattet. Für dieses gibt es keine Unterstützung im Linux Kernel. Auf Grundlage von Treibern für den ähnlichen IC W5500, die sich in der Entwicklung befinden, konnten wir unseren eigenen Linux Kernel Treiber entwickeln und somit aktiv an deren Entwicklung mitarbeiten. Wird nun eine Ethernet Extension auf das RED Brick gesteckt, kann diese, wie auf jedem anderen Rechner, als normale Ethernet Schnittstelle (”eth0”) genutzt werden.

RED Brick API Daemon und Brick Daemon: Der RED Brick API Daemon implementiert die RED Brick API und bildet die Schnittstelle zwischen der Außenwelt und dem RED Brick. Über diese API wird der RED Brick konfiguriert, Programme übertragen und zur Ausführung angewiesen. Der API Daemon ist mittlerweile nahezu vollständig implementiert und funktioniert. Der Brick Daemon wurde angepasst, so dass dieser neben USB Verbindungen auch Verbindungen direkt über serielle Schnittstelle (RS485 Extension) und SPI (Stapelkommunikation) zulässt.

Brick Viewer: Auf diesem liegt momentan unser Fokus. Wir schaffen Möglichkeiten das RED Brick über den Brick Viewer zu konfigurieren. Dazu zählen Netzwerkeinstellungen wie Hostname und IP Adresse oder Einstellungen für den lokalen Brick Daemon (Port, Authentication, Logging). Der Zustand des RED Bricks soll überwacht werden können (Prozesse, CPU-Auslastung, Speicherplatzbelegung). Es sollen Extensions verwaltet werden und Programme hochgeladen und konfiguriert werden können.

Einen Vorabeindruck, wie das ganze später im Brick Viewer aussieht könnt ihr im folgenden Screenshot bekommen:

https://www.tinkerforge.com/static/img/_stuff/screenshot_brickv_red.jpg

Der Fehlerteufel schlägt erneut zu: Wir haben ja bereits über einen Fehler im Design berichtet. Leider hat der Fehlerteufel erneut zugeschlagen. Im Datenblatt des Prozessors sind dessen Pins in einer Tabelle beschrieben. Eigenschaften, wie zum Beispiel, ob es sich um einen Input-Pin, einen Output-Pin oder einen konfigurierbaren Input-/Output- Pin handelt, sind hier genannt. Fast alle Pins sind sowohl als Input als auch als Output nutzbar. So auch laut der Tabelle für Pin “PG2”.

https://www.tinkerforge.com/static/img/_stuff/red_datasheet_table.jpg

Dieser Pin wird im Design von der zweiten Extension genutzt. Erst nachdem wir die Unterstützung für die Ethernet Extension programmiert haben fiel uns auf, dass diese an Position zwei nicht funktionierte. Grund ist, dass dieser Pin sich zwar per Software als “Output” setzen lässt, er seinen Zustand elektrisch aber nicht ändert. Datenblätter haben üblicherweise eine “Revision History”. In dieser werden Änderungen im Datenblatt festgehalten.

https://www.tinkerforge.com/static/img/_stuff/red_datasheet_history.jpg

Nach längerer Suche fiel unser Augenmerk auf diese Tabelle, in der angebliche Änderungen für Pin “PG2” notiert sind. In unserem Datenblatt wurden diese aber nicht übernommen! SHIT HAPPENS!

Was bedeutet dies nun? Wir hatten bereits die Leiterplatten für die Produktion der RED Bricks bestellt. Diese sollten nächste Woche ankommen. Eine Diskussion, ob wir den Fehler dokumentieren und die ersten RED Bricks mit dem Bug verkaufen, war schnell beendet. Wir wollen kein Produkt verkaufen, von dem von vornherein Fehler bekannt sind. Der Fehler hätte dazu geführt, dass nur eine Extension mit dem RED Brick benutzt werden könnte. Dies wäre für viele Anwendungen sicherlich nicht tragisch gewesen, entspricht aber nicht unseren eigenen Ansprüchen.

Die Leiterplatten waren zu diesem Zeitpunkt natürlich schon in Produktion, so dass wir diese abnehmen mussten oder hätten entsorgen lassen. Wir nutzen die Leiterplatten aber nun als Chance um noch einmal eine Testbestückung durchzuführen und diese dann ausgiebig testen zu können. Da nun ein Großteil der Software steht, ist das Testen auch ein ganzes Stück einfacher. Anschließend werden wir erneut Leiterplatten bestellen, bestücken und dann nach aktuellen Planungen Anfang Dezember mit dem Verkauf der RED Bricks beginnen.

Bleibt also gespannt wie es weiter geht! Wir werden euch wieder berichten…