Embedded Technologies

Die einfachsten technischen Systeme nutzen eine Hauptschleife (Run-Loop), sind also recht einfach und schnell zum Laufen gebracht. Vorausgesetzt, wir können mit JTAG-Adapter, Emulator und Bootloader umgehen. Eine kurze Einführung in diese Themen ist im Kap. 2 gegeben. Die nächste Stufe der Expertise wird erreicht, wenn wir es mit technischen Systemen zu tun haben, auf denen ein Betriebssystem läuft oder eigentlich laufen sollte. Zwei wichtige Betriebssysteme in der embedded Welt sind Linux und QNX. Sie sind in manchen Eigenschaften sehr ähnlich, an anderen Stellen unterscheiden sie sich stark. Speziell im Interrupt-Handling und in der Architektur der Treiber weichen sie voneinander ab.

Die Hauptschleife (Run-Loop) ist die einfachste Methode, ein embedded System zu betreiben. In dieser Schleife werden nacheinander Unterprogramme aufgerufen, die zur Kommunikation, Steuerung oder für andere Aufgaben dienen. Tatsächlich gibt es das Hauptschleifenkonzept auch als Prinzip in Betriebssystemen. Apple hat in seinen Dokumentationen zum iOS-Betriebssystem (iPhone, iPAD) lange die Run-Loop gegen Multithread-Programmierung verteidigt. Wir nutzen das Hauptschleifenkonzept, wenn für unser System keine Betriebssysteme erhältlich sind oder sich nicht leicht bauen lassen oder wenn der Speicher zu knapp für ein OS ist. Abgesehen von möglicher Interrupt-Programmierung ist dieses Hauptschleifenprogramm nicht nebenläufig, sondern streng sequenziell. Das reicht für überschaubare Probleme oft aus und ist sehr kompakt. Am Beispiel dieser Nische können wir gut studieren, wie wir ein solches System zum ersten Mal in Betrieb nehmen können. Für einen ersten Start eines Prozessorsystems bei der Inbetriebnahme braucht man einen Minimal-Lader, der in einer Schleife ein Programm von einer Schnittstelle (z.B. seriell) in den RAM-Speicher lädt und dort schließlich startet. Läuft dieser Bootloader, dann können alle weiteren Funktionen wie zum Beispiel die Flash-Programmierung,weitere HW-Settings etc. programmiert werden. Anschließend können wir ein erstes Hauptschleifenprogramm starten und dieses schrittweise aufbauen und mit Unterprogrammen ergänzen.

In frühen embedded Systemen war kein Betriebssystem (OS) notwendig. Das Gerät basierte auf einer einfachen Hauptschleife, die nacheinander Bedienelemente abfragte und entsprechende Gerätefunktionen ansteuerte. Wegen zunehmender Funktionalitäten, sich ändernder Hardware-Plattformen und wegen der hohen Anforderungen an gefühlte Bedienbarkeit kam man bereits früh zur Notwendigkeit von Betriebssystemen, die eine scheinbare Parallelität erlaubten, so dass nun, wenn zum Beispiel in einer Applikation auf eine Tastatureingabe gewartet wird, eine andere inzwischen weiterarbeiten konnte.

QNX ist ein von der Firma QNX (derzeitiger Eigentümer RIM) entwickeltes, proprietäres Betriebssystem, welches hauptsächlich auf den Markt der embedded Systeme ausgerichtet ist.

Linux ist ein monolithischer Betriebssystem-Kern, der durch eine Gemeinde von Entwicklern implementiert und gepflegt wird und damit eines der größten kooperativen Software-Projekte ist. Es ist vollständig quelloffen. Oftmals werden mit dem Begriff Linux auch vollständige Betriebssysteme bezeichnet, was zusätzliche Systemwerkzeuge und Benutzerapplikation mit einschließt. Um an dieser Stelle den Kernel von einem vollständigen Betriebssystem abzugrenzen, bezeichnet die Free Software Foundation (FSF) Unix-ähnliche Systeme, welche auf dem Linux-Kernel und zusätzlicher GNU Software basieren, als GNU/Linux. Monolithische Kernel haben eine lange Tradition und waren ursprünglich vollständig in einem einzigen Prozess in einem Speicherraum implementiert. Dadurch ist die Kommunikation zwischen Services sehr einfach und Funktionsaufrufe genügen. Mittlerweile wurde auch Linux modularisiert, allerdings als Threads in einem (oder wenigen) Prozessen und der Kernel selbst ist unterbrechbar und zu schedulen. Das dynamische Laden von Modulen wird erlaubt und oft genutzt.

Unter Systemstart oder auch Boot ist die Bootphase des Systems zu verstehen. Dies ist der Zeitraum, der sich vom Anlegen der Betriebsspannung bis zu Funktionsfähigkeit aus Sicht des Benutzers erstreckt. Die Startzeit eines Rechnersystems ist aus der Anwendersicht Wartezeit, in der das System genutzt werden soll, die Funktionalität jedoch noch nicht abrufbar ist. Hier unterscheiden sich embedded Systeme grundsätzlich nicht von anderen Rechnersystemen. Embedded Systeme sind jedoch für einen konkreten und speziellen Einsatzzweck vorgesehen. Hierfür lassen sich diese anpassen und optimieren. Auch in eingebetteten Systemen wird immer mehr Funktionalität eingebaut, was Einfluss auf die Komplexität dieser Systeme hat. Zusätzliche Abstraktionsschichten wie Betriebssysteme, Bibliotheken und Frameworks helfen, diese Komplexität zu beherrschen und gleichzeitig Qualitätsansprüchen zu genügen. Die zusätzlichen Abstraktionsschichten, die das Entwickeln und das Warten der Systeme erheblich vereinfachen, wirken sich jedoch oft negativ auf Startzeiten aus. Gerade für Systeme und Geräte, die historisch nicht durch Rechnersysteme unterstützt wurden, fällt es schwer, lange Startzeiten in Kauf zu nehmen. Beispiele hierfür sind unter anderem Kameras, Autoradio/ICM-Systeme, Walkman/MP3-Player und Fernsehgeräte/Set-Top-Boxes. Aber auch aus technischen Gründen sind schnelle Startzeiten wichtig, wenn zum Beispiel die zu startenden Systeme im Verbund mit anderen interagieren sollen. Gerade im Echtzeitbereich gibt es Szenarien, in denen ein System innerhalb eines definierten Zeitfensters auf Nachrichten antworten muss, die über ein Feldbussystem eingehen.

Nach dem vollständigen Hochfahren des Systems können die Applikationen starten. Im Speichermodell eines Systems gibt es vier zur Verfügung stehende Speichersegmente.

Jedes SW-getriebene System sollte regelmäßig Resets zu definierten Zeiten bekommen, damit eventuelle Verklemmungen gelöst werden können. Eine gute Praxis ist, das System beim Starten (On) per Einschalten der Spannung oder per Hauptschalter mit einem Reset zu beaufschlagen. Systeme, die niemals einen planmäßigen Reset bekommen, sind sehr kritisch zu hinterfragen und auch ist zu fragen, ob sich nicht die HW- und/oder SW-Entwickler überschätzen. Zudem gibt es mögliche Störungen durch EMV-Einstrahlung, die außerhalb des eigenen Einflussbereiches sind.

Flash-Bausteine sind die heute üblichen Festwertspeicher im Computer, die ihren Inhalt über Power-off hinweg persistent speichern. Dort werden die Bootloader und die Boot-Images aufgehoben sowie bei embedded Systemen auch die einzigen persistenten File-Systeme (FS). Sämtliche Settings, Last-Modes und Pin-Codes werden in einem solchen FS aufgehoben, die Partition nennt man oft efs-Persistence. Das Speicherprinzip von Flash-Bausteinen ist ein Kondensator, in dem eine Ladung den logischen Pegel darstellt (Bitspeicher). Im Gegensatz zum dynamischen Speicher muss beim Flash die Ladung nicht zyklisch aufgefrischt werden, da die Ladung in einer hochisolierenden Schicht eingebracht ist. Dementsprechend kann diese Ladung auch nicht mit neuem Schreiben des alternativen Pegels verändert werden, die Zelle muss durch erhöhte Spannung gelöscht werden. Bei realen Flash-Speichern sind die Zellen in Blöcken und Sektoren organisiert und können zwar einzeln geschrieben, aber immer nur Sektor-weise gelöscht werden. Übliche Flash- Speicher besitzen eine Wortbreite von Byte oder von Word und eine Sektorgröße von 256 oder 512 kByte. Einzelne Speicherstellen werden deshalb zunächst nur als gelöscht markiert („stale“). Das Überschreiben z. B. des Wertes einer Variablen erfordert demnach das gelöscht Markieren des alten Speicherplatzes und den Eintrag der Variablen in einer neuen Zelle und in der File-Verwaltung. Erst wenn Speicherplatz gebraucht wird, werden Blöcke, in denen alle Speicherstellen leer oder als „stale“ markiert sind, komplett auch physikalisch gelöscht, „reclaim“. Nach dieser Art Garbage-Collection sind die Sektoren als „free“ markiert. Gegebenenfalls müssen dafür auch Speicherstellen vom Treiber und dem Betriebssystem umgelagert werden.

Hard-Disc-Drives sind die heute üblichen Festwertspeicher im Computer, die ihren Inhalt über Power-off hinweg persistent speichern. Dort werden persistente Daten und Programme aufgehoben, die erst nach dem Booten zur Verfügung stehen müssen.

Man kann Treiber in drei Kategorien unterteilen:

• HW-Treiber dienen als Abstraktionsschicht zwischen einer Applikation und der Hardware.

• SW-Treiber dienen als Abstraktionsschicht zwischen einer Applikation und z. B. dem Betriebssystem.

• Int-Treiber dienen als Abstraktionsschicht zwischen einer Applikation und der Interrupt-Hardware.

Oft stellt sich die Frage, wie man in einem Prozessorsystem mit vielen Threads oder Prozessen und einem darunter liegenden Betriebssystem Echtzeitanforderungen von außen aus der HW sicherstellt. Die Antwort ist normalerweise: mit Interrupts. Mit einem HW-Signal (IRQ) direkt am Prozessor wird ein höchstpriorer und schnellstmöglicher Kontextwechsel in einen eigenen Kontextmit eigenen Registersätzen und einer spezielle Routine ausgelöst. Das HW-Signal kann die Interrupt-Routine mit einer Flanke oder mit einem Pegel auslösen. Welchen Unterschied das macht, wird später erläutert. Das spezielle Unterprogramm, das aufgerufen wird, bezeichnet man als Interrupt-Service-Routine, ISR. Übliche Prozessoren besitzen ein Vektorfeld am unteren Ende des Adressbereichs, in dem Reset- und Interrupt-Vektoren hinterlegt sind. Bei Auftreten eines Reset- oder Interrupt-Signals wird der Inhalt der zugeordneten Adresse als Sprungziel der Bearbeitungsroutine verwendet. Entsprechend werden für die Implementierung dieser Vektortabellen Strukturen von Funktionszeigern verwendet.

Linux kennt verschiedene Kontexte, in denen eine Bearbeitung stattfinden kann, siehe Abb. 13.1 und [Qua]. Dieser Kontext ist wichtig, um entscheiden zu können, welche Kernelfunktionen sich für die aktuelle Bearbeitung eignen. Auf der User-Ebene (User-Kontext) stehen alle Dienste des OS zur Verfügung. Hier laufen normale Benutzeranwendungen im Userspace. Der Code ist jederzeit unterbrechbar, durch Interrupts in HW oder SW. Userspace-Programme haben keinen Zugriff auf den Adressraum des Kernels, sie können aber SoftIrqs auslösen und darüber Kernel-Funktionen aufrufen.

Auch hier hat die ISR folgende Aufgaben:

• Feststellen, welches Device den Int ausgelöst hat.

• Die HW bedienen.

• Gegebenenfalls als Primary-ISR detektieren, welcher Shared-Int aktiv ist und dessen Handler aufrufen.

• Gegebenenfalls Daten aus der HW abholen und diese aus der ISR in eine Applikation transportieren.

• Der Applikation signalisieren, dass neue Daten verfügbar sind.

In den letzten Jahren entstanden, getrieben von Intel und AMD, zunehmend Systeme mit mehreren Prozessoren (Cores) auf einem Chip. Diese teilen sich Peripherie, Speicher und andere Ressourcen. Zunächst waren das nur Konzepte, um bei nicht immer weiter erhöhter Taktrate und Verlustleistung die Gesamtrechenleistung zu erhöhen und damit die Energieeffizienz zu optimieren. Es folgten in Software und Hardware Strategien, wie Aufgaben parallelisiert werden können, Stichworte seien Hyperthreading „HT“ und Simultaneous Multi Threading „SMT“. Es entstanden verschiedene Betriebssystem-Optionen wie AMP, SMP und BMP, die im Folgenden erläutert werden.

Virtualisierungskonzepte gibt es seit 1967. Während Virtualisierungen bereits seit vielen Jahren intensiv in Servern genutzt werden, finden sie erst jetzt auch allmählich Verwendung in embedded Systemen.

Selten wird die Anzahl der gewünschten Domänen, die mit eigenen Prioritätsstrategien laufen sollen, zu der Anzahl der Cores passen. Es ist möglich, sich mithilfe eines VM-Konzeptes die passende Anzahl von Cores zu schaffen. Eine mögliche Architektur könnte wie in Abb. 17.1 aussehen.

Die Interaktion mit elektronischen Geräten, insbesondere mit Computern, ist aus dem heutigen Alltagsleben kaum mehr wegzudenken. Nur wenige Geräte funktionieren heute noch ohne Mikroprozessor. Selbst im Auto, in der Waschmaschine oder in der einfachen Personenwaage wird Software eingesetzt, um das Gerät zu steuern. Der Benutzer sieht meist nur die hoffentlich intuitiv gestaltete Benutzerschnittstelle, die sich dem Benutzer z. B. durch Tasten, Displays oder sogar Touch-Screens präsentiert. Derartige embedded Systeme unterscheiden sich stark von Systemen wie z. B. Desktop-Computern. An Systeme im embedded Bereich werden weit höhere Anforderungen gestellt. Die Rechenleistung solcher Systeme ist meist geringer, auch Arbeits- und nichtflüchtige Speicher sind oft stark begrenzt im Vergleich zu normalen Systemen. Gleichzeitig muss das System zu 100% verlässlich sein, wenn z.B. hoch komplexe Berechnungen in Echtzeit durchgeführt werden müssen. Das Verhältnis der Rechenleistung zwischen technischen Systemen und Desktop-Systemen hat sich in den vergangenen Jahren jedoch stark verändert. Rechenleistung, die vor einigen Jahren nur auf High-End Computer-Systemen verfügbar war, ist heute auch in embedded Systemen verfügbar. Hardware wurde billiger, die Funktionalität der Systeme umfangreicher. Software, die zuvor nur für Desktop-Computer entwickelt wurde, wird immer häufiger auch auf embedded Systeme portiert. An erster Stelle steht hier die grafische Animation der Bedienungsführung.

Die Programmiersprache Java wird zunehmend auch für embedded Systeme eingesetzt. Sie ist leichter zu erlernen und zu beherrschen als C/C++ und die Produktivität der Entwickler ist höher. Zudem verspricht sie eine bessere Plattformunabhängigkeit.

Auch wenn die Erzeugung von Sound und das Abspielen von Medien in unserem kleinen embedded Kontext eigentlich nicht Thema sind, so ist doch mittlerweile auch bei kleinen Systemen das Abspielen einiger Quittungs-Beeps und vielleicht sogar einiger aufgezeichneter gesprochener Texte erforderlich. Wir setzen im Folgenden eine funktionsfähige Audio-Ausgabe voraus, ein Sound-Chip-Treiber ist installiert und funktionsfähig. Eine eigene Audioverarbeitung zu implementieren ist für die kleine Aufgabenstellung zu aufwendig. SDK-Lösungen aus der Desktop-Welt wie MPlayer oder VLC sind zu groß.

Das folgende Kapitel beschäftigt sich mit Fehlern. Der Umgang mit Software ist naturgemäß immer auch der Umgang mit Fehlern. Dem Autor war es in den letzten Jahren möglich, im Rahmen von Kooperationen und Task-Forces zur Rettung von großen Produkt-Anläufen, Einblick in eine Vielzahl von Fehlern und Fehlerursachen zu bekommen. Daraus ließen sich einige Erkenntnisse abstrahieren.

Beispiel der Übertragung von Daten mit /proc und einer Interrupt-Routine. Mit jedem Druck auf den User-Button des Boards wird ein Interrupt-Zähler inkrementiert. Mit der read()-Funktion des procfs kann der Zählerstand ausgelesen werden. Da der Zugriff auf den intZähler atomar ist, braucht er nicht synchronisiert zu werden.