Der Red-Brick als USB-Blackbox - auf Wunsch

Grundsätzlich ist mit einem stabilen Linux-Kernel und dem riesigen Reservoir an verfügbaren Debian-Software-Paketen der Red-Brick bereits betriebs- und einsatzfähig. Doch der Red-Brick soll mehr sein als noch ein weiterer Kleinrechner. Anwender des Tinkerforge-Baukastens sollen sich nicht mit dem Linux des Red-Brick auseinandersetzen müssen, wenn sie es nicht wollen.

Ähnlich wie der bisherige Masterbrick per USB an einen Rechner angesteckt und die Steuerbefehle von einem Programm von diesem Rechner umgesetzt wurden, soll auch der Red-Brick als Gerät erscheinen, auf dem Programme einfach per Mausklick hochgeladen werden können. Aus diesem Grund muss Olaf Lüke an einer weiteren Softwarekomponente arbeiten: einem speziellen USB-Treiber auf dem Red-Brick, einem sogenannten Composite USB Gadget Driver.

Mit Hilfe dieses Treibers erscheint der Red-Brick beim Anschluss an einen anderen Rechner als USB-Gerät (daher "Gadget") - vergleichbar einem angeschlossenen Handy. Der Begriff "Composite" wiederum verweist darauf, dass der Treiber mehr als einen Betriebsmodus unterstützt. Mit Hilfe des Treibers stellt der Red-Brick über USB nicht nur eine API zur Ansteuerung bereit, sondern auch eine serielle Konsole.

Maschinenkommunikation

Beim bisherigen Tinkerforge-System übernimmt der Masterbrick die Kommunikation zwischen einem angeschlossenen Rechner und den einzelnen Bricks. Die notwendige Vermittlerlogik läuft exklusiv auf einem ARM-Cortex-M3-Microcontroller, die Ansteuerung der Bricks erfolgt über SPI (Serial Peripheral Interface).

Auf dem Red-Brick ist die Angelegenheit komplizierter. Die Ansteuerung der Bricks muss weiterhin über SPI erfolgen, um die Kompatibilität zu gewährleisten. Es ist aber nicht mehr möglich, die Kommunikationslogik auf dem "blanken Metall" laufen zu lassen, sondern sie erfolgt innerhalb der Grenzen und der Abstraktionen des Betriebssystems.

Olaf Lüke musste also nicht nur einen Treiber für die SPI-Kommunikation schreiben, sondern dabei auch hoffen, dass das Linux-System schnell genug ist, um den Anforderungen zu genügen.

Beim ersten Versuch gelang das nicht. Die Lösung war ein Umbau der Kommunikation. Mit dem überarbeiteten Protokoll können die empfangenen Daten, zum Beispiel Sensormesswerte, von Bricks per DMA (Direct Memory Access) im Speicher abgelegt werden. Der Prozessor muss nicht mehr explizit angewiesen werden, selbst die empfangenen Daten in den Arbeitsspeicher zu kopieren.

Einziger Nachteil des Umbaus am Kommunikationsprotokoll ist, dass ein Update der Firmware in den Bricks nötig wird, das aber vom Anwender keine speziellen Werkzeuge erfordert.

Durch den Einsatz von DMA wird das System kaum belastet. Laut Lüke benötigt der Tinkerforge-Software-Unterbau zusammen nicht mehr als sechs Prozent der Systemleistung und trotzdem können bis zu 1.000 Messpunkte pro Sekunde ausgewertet werden. Dabei läuft ein Großteil der Software bislang im Userspace, also außerhalb des Kernels. Sollte es sich während der weiteren Entwicklung herausstellen, dass das System ausgebremst wird, besteht immer noch die Option, Code in den Kernel zu verlagern.