Original-URL des Artikels: https://www.golem.de/news/tinkerforge-linux-anpassen-fuer-ein-neues-prozessorboard-1407-108174.html    Veröffentlicht: 30.07.2014 12:05    Kurz-URL: https://glm.io/108174

Tinkerforge

Linux anpassen für ein neues Prozessorboard

Neue Hardware erfordert oft auch neue Software. Wie aufwendig die Programmierung ist und wieso Open Source dabei eine große Hilfe sein kann, erklärten uns die Macher von Tinkerforge anhand ihres RED-Brick.

Wie ein neues Prozessorboard entsteht, haben uns die Macher von Tinkerforge bereits im Mai erklärt. Doch ohne Betriebssystem, ohne Treiber und ohne passende Programme ist selbst die beste Elektronik nur ein nutzloser Staubfänger. Deswegen sprachen wir mit Olaf Lüke nun darüber, welche Softwarekomponenten für den Red-Brick notwendig sind und wie sie entwickelt werden.

Lüke ist einer der Gründer von Tinkerforge und zuständig für die Softwareentwicklung. Bislang umfasste dies vor allem die Mikrocontroller-Programmierung auf den Bricks, die Pflege des Brick-Daemons für die Hostrechner sowie die Betreuung der APIs zur Einbindung der Bricks in eigene Programme. Das notwendige Wissen und die Erfahrung sammelte er schon seit seiner Studienzeit: sei es bei der Programmierung von Fußballrobotern oder dem einzig echten, aber längst vergessenen Open-Source-Handy Openmoko.

Als die Entscheidung zur Entwicklung des Red-Brick und dessen Funktionen fiel, wussten die Macher deshalb schon, welche Softwarekomponenten ausgesucht beziehungsweise entwickelt werden mussten. Lüke ist dabei nicht allein. Als zweiter Programmierer steht ihm Matthias Bolte zur Seite.

Das Betriebssystem

Dass Linux zum Einsatz kommen sollte, stand von vornherein fest. Auch bei der Wahl der Basis für die Distribution gab es keine Diskussion: Debian. Ergänzt wird es um zusätzliche Pakete des Sunxi-Projektes. Sunxi stellt Treiber und Patches speziell für Allwinner-SoCs bereit, die sowohl von Allwinner selbst als auch von der Community stammen. Es wird von anderen Allwinner-basierten Kleinrechnern ebenfalls als Basis für ihre Distribution genutzt, wie zum Beispiel bei den Olimex-Boards. Damit steht von vornherein eine große Anzahl ARM-kompatibler Softwarepakete zur Verfügung. Zudem existiert eine große Community, von deren Erfahrungen die Tinkerforge-Macher profitieren können.

Mit der Auswahl der Distribution ist es aber nicht getan. Der Bootloader und der Linux-Kernel müssen an die Hardware des Red-Brick angepasst werden. Da die Softwareentwicklung schon begann, als noch am Schaltungsentwurf des Red-Brick gearbeitet wurde, nahmen wir an, dass zur Softwareanpassung eine Form von Emulator oder virtueller Maschine zum Einsatz kommen würde.

Doch weit gefehlt. Die Macher nutzten ein bestehendes Olimex-Board mit dem A10 und passten es per Lötkolben an die eigene geplante Hardware an. So wurde zum Beispiel der Flashspeicher des Olimex-Boards entfernt, so dass das Board nur noch von der SD-Karte booten konnte - oder eben abbrach, wenn eine Fehlkonfiguration vorlag. Durch die Debugmöglichkeiten des Boards über eine serielle UART-Schnittstelle war es möglich, die Fehlerausgabe des Kernels auszulesen.

Lüke baute nun den Linux-Kernel schrittweise um, so dass er auf der geänderten Hardware lauffähig war. Die Kompilierung des Kernels erfolgte über einen Desktoprechner. Zum Testen wurde das neue Kernel-Image auf eine SD-Karte aufgespielt und versucht, das Olimex-Board zu starten.

Nachdem der Kernel erfolgreich gebootet werden konnte, ging es an die Entwicklung der Treiber und Softwarekomponenten, die speziell für den Red-Brick und die Tinkerforge-Bausteine notwendig waren.

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.

Copy'n'Trial

Der dritte Treiber, den Lüke entwickeln muss, hat nichts direkt mit Tinkerforge zu tun, die Arbeit ist aber trotzdem notwendig: Für die Ethernet-Anbindung wird ein WIZnet-W5200-Chip eingesetzt, der derzeit aber noch nicht vom Linux-Kernel unterstützt wird.

Anhand dieses Treibers erläutert Lüke etwas überspitzt, wie die typische Treiberentwicklung unter Linux abläuft: "Man nimmt einen Treiber, der etwas Ähnliches macht und passt ihn dann schrittweise an die eigenen Anforderungen an." Ohne die Offenheit des Open-Source-Modells, sagt er, hätte die Entwicklung nicht so schnell umgesetzt werden können. Das gilt nicht nur für den Treiber, sondern auch für die Einrichtung des Betriebssystems an sich. Eine Einschränkung macht er allerdings: Seine jahrelange Erfahrung in der C-Programmierung sei Voraussetzung gewesen, den bestehenden Code schnell zu verstehen und auch zielgerichtet anzupassen.

Für den Anwender

Neben den vorgestellten Treibern, von denen der Anwender nichts direkt mitbekommen soll, sind noch zwei weitere Komponenten in der Entwicklung: der Brick-API Daemon und ein neuer Brick Viewer.

Der Brick-API Daemon dient als zentrale, abstrahierende Schnittstelle für die Brick-Ansprache auf dem Red-Brick durch Benutzerprogramme. Aber selbst davon soll ein normaler Nutzer nichts mitbekommen, wenn er die jeweiligen API-Bindings von Tinkerforge benutzt.

Die neue Version des Brick Viewer läuft auf einem Hostrechner und erlaubt die Inbetriebnahme und Konfiguration des Red-Brick, ohne dass sich der Anwender mit dessen Linux auseinandersetzen muss. Er soll darüber außerdem seine Quelltexte auf den Red-Brick hochladen können. Auf dem Red-Brick selbst sollen die erforderlichen Entwicklungswerkzeuge und Interpreter bereitstehen, damit die Quelltexte automatisch kompiliert beziehungsweise ausgeführt werden können.

Geht es ein bisschen flotter?

Das Betriebssystem muss auf der SD-Karte die notwendigen Werkzeuge mitbringen, damit diese Automatik funktioniert. Tinkerforge will deshalb fertige Images dafür anbieten. Bei der Konzeption des Images gibt es aber ein Problem: Ein Masterbrick benötigt aktuell nur wenige Sekunden, um einsatzbereit zu sein. Ein Linux-System kann dafür mehrere Minuten benötigen.

Die Deaktivierung möglichst vieler Kernelmodule ist der einfachste Weg, Linux schneller booten zu lassen. So werden aber auch die Fähigkeiten des Systems reduziert. Je nach Einsatzzweck kann das akzeptabel sein - auf der anderen Seite stellt sich die Sinnfrage, warum ein vollwertiger Rechner, wie es der Red-Brick darstellt, allein wegen der Bootdauer künstlich eingeschränkt werden sollte.

Olaf Lüke will dem Problem auf zwei Wegen begegnen: Zum einen sollen die notwendige Toolchain und die erforderlichen Skripte frei verfügbar sein, damit sich erfahrene Anwender ihr eigenes Image bauen können. Zum anderen wird es zwei verschiedene Arten von fertigen Images geben.

Das Full-Image wird die Hardware des Red-Brick vollständig unterstützen. Wird ein Monitor per HDMI angeschlossen, dazu eine Maus und Tastatur per USB, lässt er sich wie ein normaler Computer benutzen. Beim Fast-Image hingegen sind eine Reihe von Kernelmodulen deaktiviert, unter anderem wird die Grafikeinheit abgeschaltet. Die Bootzeit soll dann unter zehn Sekunden liegen.

Der aktuelle Hardwarestand

Als unser Artikel zur Hardwareentwicklung des Red-Brick selbst herauskam, hatte Tinkerforge einen Auftrag zur Fertigung von Red-Brick-Prototypen in Auftrag gegeben. Im Juni hielten sie die ersten zwölf Prototypen in ihren Händen. Doch der Bootvorgang schlug fehl. Nach intensivem Software-Debugging kamen sie zu dem Schluss, dass tatsächlich ein Fehler im Schaltungsentwurf die Ursache sein musste - und tatsächlich war ein PIN des A10 falsch verbunden.

Es gab eine Lösung dafür, die allerdings viel Fingerspitzengefühl erforderte. Eine Leiterbahn musste mit einem sehr kleinen Bohrer aufgetrennt werden. Da die Leiterplatte des Red-Brick sechs Lagen umfasst, war das Risiko sehr groß, dabei andere Leiterbahnen zu beschädigen. Tatsächlich überlebte nur die Hälfte der Boards die Operation, doch auf diesen Boards funktionierten sowohl der Bootvorgang als auch die ersten Softwareentwicklungen ohne Probleme. Tinkerforge demonstrierte die Lauffähigkeit öffentlich auf der Maker Faire in Hannover Anfang Juli.

Damit kann nun nicht nur die Softwareentwicklung weitergehen, sondern es sind auch die ersten Tests zur elektromagnetischen Verträglichkeit der Boards möglich.  (am)


Verwandte Artikel:
Tinkerforge: Wie ein Prozessorboard entsteht   
(06.05.2014, https://glm.io/106156 )
Nouveau: Nvidia versucht, alles zu verstecken   
(04.02.2018, https://glm.io/132571 )
LLVM 6.0: Clang bekommt Maßnahme gegen Spectre-Angriff   
(09.03.2018, https://glm.io/133241 )
AMDs Embedded-Pläne: Ein bisschen Wunschdenken, ein bisschen Wirklichkeit   
(23.02.2018, https://glm.io/132925 )
Bilderkennung: Roboter löst Rubik's Cube in 380 Millisekunden   
(08.03.2018, https://glm.io/133228 )

© 1997–2019 Golem.de, https://www.golem.de/