Diplomarbeit. zur Erlangung des akademischen Grades. Diplom-Informatiker (FH) an der. Fachhochschule Konstanz. Fachbereich Informatik.

Transkript

1 Diplomarbeit zur Erlangung des akademischen Grades Diplom-Informatiker (FH) an der Fachhochschule Konstanz Hochschule für Technik, Wirtschaft und Gestaltung Fachbereich Informatik Studiengang TI Thema: Analysetool für das Real-Time Operating System AMX Diplomand: Stefan Schnell Jägerstr Meßstetten 1. Prüfer: Prof. Dr. Michael Mächtel 2. Prüfer: Dipl.-Ing. (FH) Joachim Beck primion Technology AG Steinbeisstr Stetten a. k. M. Abgabedatum: 31. August 2006

2

3 Ehrenwörtliche Erklärung Hiermit erkläre ich, Stefan Schnell, geboren am in Rottweil, (1) dass ich meine Diplomarbeit mit dem Titel: Analysetool für das Real-Time Operating System AMX im Unternehmen primion Technology AG unter der Anleitung von Herrn Prof. Dr. Michael Mächtel und Herrn Dipl.-Ing. (FH) Joachim Beck selbständig und ohne fremde Hilfe angefertigt habe und keine anderen als die angeführten Hilfen benutzt habe; (2) dass ich die Übernahme wörtlicher Zitate, von Tabellen, Zeichnungen, Bildern und Programmen aus der Literatur oder anderen Quellen (Internet), sowie die Verwendung der Gedanken anderer Autoren an den entsprechenden Stellen innerhalb der Arbeit gekennzeichnet habe. Ich bin mir bewusst, dass eine falsche Erklärung rechtliche Folgen haben wird. Konstanz, den 31. August 2006 Stefan Schnell i

4 ii

5 Danksagung An dieser Stelle möchte ich mich bei allen Personen bedanken, die in irgendeiner Weise an dieser Arbeit mitgewirkt haben. Mein besonderer Dank gilt Herrn Prof. Dr. Michael Mächtel für die Betreuung meiner Diplomarbeit und für die hilfreichen Informationen und Vorschläge in der Planung und Realisierung dieser Arbeit. Mein weiterer besonderer Dank geht an Herrn Dipl. Ing. Joachim Beck für die zahlreichen, richtungsweisenden Anregungen und für die kritische und gründliche Durchsicht dieser Arbeit. Des Weiteren möchte ich mich bei den Mitarbeitern der Firma primion Technology AG für die stets bereitwillige Unterstützung und Hilfestellung bedanken. iii

6 iv

7 Zusammenfassung Thema: Diplomand: Firma: Analysetool für das Real-Time Operating System AMX Stefan Schnell Jägerstr Meßstetten primion Technology AG Steinbeisstr Stetten a. k. M. 1. Prüfer: Prof. Dr. Michael Mächtel 2. Prüfer: Dipl.-Ing. (FH) Joachim Beck Abgabedatum: 31. August 2006 Schlagworte: Die Entwicklung von Realzeitsystemen wird in der heutigen Zeit durch geeignete Softwarewerkzeuge weitreichend unterstützt. In der Fa. primion Technology AG wird für diesen Zweck das Real-Time Operating System AMX in Verbindung mit der Entwicklungsumgebung winidea eingesetzt. Die Aufgabe dieser Diplomarbeit besteht nun aus der Realisierung eines Analysetools für das RTOS AMX. Dieses Analysetool soll den Entwickler von Realzeitsystemen unterstützen und das Auffinden von Fehlern erleichtern. Dazu muss das Betriebssystem analysiert werden, um Möglichkeiten zu finden Systeminformationen aus dem laufenden Betrieb heraus dynamisch aufzuzeichnen. Diese automatisch gesammelten Informationen werden in geeigneten Datenstrukturen im Systemspeicher abgelegt. Da ein Realzeitsystem besonderen zeitlichen Vorschriften unterliegt, muss darauf geachtet werden, dass das eigentliche System nicht beeinträchtigt wird. Die gesicherten Informationen werden über eine von der Entwicklungsumgebung bereitgestellte Programmier-Schnittstelle aus dem Speicher abgeholt. Damit diese Informationen für den Benutzer in eine geeignete Darstellungsform gebracht werden können, müssen sie zuerst für eine Ausgabe umgewandelt werden. v

8 vi

9 Abstract Topic: Student: Company: Analysis Tool for the AMX Real-Time Operating System Stefan Schnell Jägerstr Meßstetten primion Technology AG Steinbeisstr Stetten a.k.m. 1 st Examiner: Prof. Dr. Michael Mächtel 2 nd Examiner: Dipl.-Ing. (FH) Joachim Beck Submission date: 31 st August 2006 Project details: Today, the development of real-time systems is supported to a large extent by specific software tools. For this purpose, primion Technology AG uses the Real-Time Operating System AMX together with the winidea development environment. The aim of this Final Year Project is to develop an analysis tool for the AMX RTOS. This analysis tool should support developers of real-time systems and facilitate the localisation of errors. For this purpose, the operating system has to be analysed in order to find ways to store system information dynamically, during live operation. This information, which is collected automatically, is stored in dedicated data structures in the system memory. As a real-time sytem must meet stringent timing criteria, special attention must be paid to ensuring that there is no negative impact on the performance of the system. The stored information is fetched from the memory using one of the programming interfaces made available by the development environment. The information has first to go through a conversion routine in order to get it into suitable format, for the user to be able to utilise it. vii

10 viii

11 Inhaltsverzeichnis 1 Einleitung Vorwort Motivation Eigenschaften eines Realzeitsystems Typische Hardware Eigenschaften des Entwicklungssystems Systemsicht Prozesssicht Besondere zeitliche Anforderungen Inbetriebnahme eines Mikrocontrollers bzw. Mikroprozessors Interrupt Interrupt Service Routine Exception Vector Table Timer - Der Zeitgeber Aufgaben eines Betriebssystems Die Schichtenarchitektur Das Real-Time Operating System AMX AMX Task Scheduling Kategorien von Echtzeit Scheduling-Algorithmen Prioritätenbasierendes Task Scheduling Time-Slicing Der nicht unterbrechbare Scheduling-Algorithmus Der unterbrechbare Scheduling-Algorithmus Benutzerdefinierte Tasks - Anwendungstasks AMX Interrupt Management AMX Timing Control Die AMX Kernel Task AMX Services Semaphor-Management Das Ressourcen Semaphor Das Zählsemaphor Event-Management Mailbox-Management Message Exchange Queues Speicherverwaltung ix

12 Inhaltsverzeichnis 6 Modellierung des Analysetools Anforderungen an das Tool Die Software-Architektur Die Informationssammlung Taskinformationen Mailboxinformationen Semaphorinformationen Eventinformationen Speicherinformationen Übersicht der Module Informationsdarstellung Modulimplementierung Modul Task Vorgehensweise / Überlegungen Lösung: Task Scheduling Hooks Probleme Modul Mailbox Vorgehensweise / Überlegungen Lösung: Modifikation der AMX RTOS Library Modul Semaphor Vorgehensweise / Überlegungen Lösung: Modifikation der AMX RTOS Library Modul Event Vorgehensweise / Überlegungen Lösung: Modifikation der AMX RTOS Library Modul Speicher Vorgehensweise / Überlegungen Lösung: Eingriffe in die bestehende Speicherverwaltung Anmerkungen Verändertes zeitliches Verhalten des Systems Die Informationsverarbeitung Die winidea Script Language ISL Die Benutzeroberfläche Das Analysetool Die Software Applikation Informationsausgabe Fazit 127 Abbildungsverzeichnis Tabellenverzeichnis Listingverzeichnis Abkürzungsverzeichnis Literaturverzeichnis A C E G I x

13 Kapitel 1 Einleitung 1.1 Vorwort Der Mikroprozessor zählt zu den wenigen Erfindungen, die das Leben der Menschheit entscheidend geprägt haben. Nachdem im Jahr 1971 der erste auf den Markt kam, ist ihre Entwicklung im Laufe der Jahre rasch vorangeschritten. Sie wurden immer billiger und kleiner und deshalb wesentlich interessanter für Produkte, die elektronisch gesteuert werden. In der heutigen Zeit sind Millionen von elektronischen Schaltelementen auf kleinstem Raum auf einem Chip zusammengefasst und erledigen mit unvorstellbarer Geschwindigkeit gewaltige Mengen an Arbeitsschritten (Operationen). Ebenso war es im Zuge der fortschreitenden Miniaturisierung möglich, neben dem Mikroprozessor auch zusätzliche Peripherie auf dem Chip zu implementieren. Es entstand ein funktionsfähiges System auf einem Chip, der Mikrocontroller. In Zusammenhang mit diesen mikroelektronischen Steuerungen spricht man auch von sogenannten Embedded Systems, da ein Mikroprozessor in das System eingebettet ist. Diese Rechensysteme sind in Produkten unsichtbar für den Menschen integriert und werden meistens nicht einmal bemerkt. Sie werden im alltäglichen Leben angetroffen und befinden sich beispielsweise in Waschmaschinen, Aufzügen, Digitaluhren und in jedem Auto. Etwa 98 Prozent aller programmierbaren Prozessoren werden in Embedded Systems verwendet. Dies zeigt die Wichtigkeit dieser Systeme in der heutigen Zeit. Ein großer Teil dieser Embedded Systems sind Echtzeitsysteme (Realzeitsysteme), die auf besondere zeitliche Einflüsse reagieren müssen. Um ein Realzeitsystem einsetzen zu können, benötigt es ein Betriebssystem, das für die Verwaltung aller Aufgaben zuständig ist. Dieses wird Real-Time Operating System (RTOS) genannt. Diese Art von Betriebssystem unterliegt besonderen zeitlichen Anforderungen, die bei der Entwicklung beachtet werden müssen. 1

14 Kapitel 1 Einleitung 1.2 Motivation In der Fa. primion Technology AG werden Realzeitsysteme eingesetzt, um Geräte für Zutrittskontrollen und für Zeiterfassungen zu produzieren. Das Ziel der im Rahmen dieser Diplomarbeit durchgeführten Analyse ist es, einem Systementwickler ein komplexes Analysetool zur Entwicklung eines Realzeitsystems in Verbindung mit der eingesetzten AMX Multitasking-Software zur Verfügung zu stellen. Da die in der Firma primion Technology AG verwendete Entwicklungsumgebung winidea kein fertiges Werkzeug zur Darstellung von Betriebssysteminformationen mitliefert, bestand schon länger der Wunsch nach einem Softwaretool, welches diese Aufgaben übernimmt. Das Tool soll in jedem Entwicklungssystem eingesetzt werden können, das in Verbindung mit der Entwicklungsumgebung winidea, dem Real- Time Operating System AMX und einem von winidea unterstützten Mikroprozessor steht. Das Analysetool soll jederzeit die Möglichkeit bieten, an gewünschte Statusinformationen zu gelangen. Diese Informationen sollen das Entwickeln eines Echtzeitsystems unterstützen. Des Weiteren soll es eine bessere und schnellere Fehlererkennung ermöglichen. Der Inhalt dieser Diplomarbeit ist so strukturiert, dass zu Beginn erst grundlegende Begriffe im Zusammenhang mit Realzeitsystemen erklärt werden. Des Weiteren wird beschrieben, wie das verwendete Entwicklungssystem (die Hardware - der Mikrocontroller) für einen Einsatz mit dem Real-Time Operating System AMX vorbereitet wird. Im Anschluss wird die Funktionalität dieses Betriebssystems analysiert. Mit diesen Informationen wird ein Modell für das Analysetool erstellt. Dieses soll die Grundlage für das zu erstellende Tool bilden. Bereits während meiner Studienzeit habe ich mich für das Arbeiten mit Betriebssystemen und vor allem für die Anwendung von Realzeitsystemen interessiert. Deshalb war diese Aufgabenstellung sehr reizvoll für mich. Die Planung und Realisierung eines Projekts vom Beginn bis zur Fertigstellung ist eine besondere Herausforderung für mich. 2

15 Kapitel 2 Eigenschaften eines Realzeitsystems Bis zur heutigen Zeit haben sich unterschiedliche Arten von Echtzeitsystemen entwickelt. Diese lassen sich vor allem durch ihre Hardware unterscheiden. Vorhandene Ausprägungen sind Speicherprogrammierbare Steuerungen (SPS-Steuerung), Realzeitapplikationen auf Standardarchitekturen aufgesetzt, Realzeitkommunikationssysteme und eingebettete Systeme mit besonderen zeitlichen Anforderungen. In dieser Diplomarbeit wird die Ausprägung als eingebettetes System behandelt, da diese Art von Realzeitsystem in der Firma primion Technology AG eingesetzt wird. Deshalb wird im weiteren Verlauf der Begriff Embedded System einem Realzeitsystem gleichgestellt. 2.1 Typische Hardware Zur Realisierung eines Realzeitsystems wird gewöhnlich ein Mikrocontroller (MCU) verwendet (vgl.[wiki]). Ein Mikrocontroller ist eine CPU mit Peripherie auf einem einzigen Chip bzw. in einem einzigen Schaltkreis integriert. Neben der Verarbeitungseinheit sind noch Interruptcontroller und Ansteuerbausteine für die Peripherie miteingebunden. Meist können Signalleitungen direkt an einem Portausgang bzw. Porteingang angeschlossen werden. Auf einer modernen MCU befinden sich häufig auch spezielle Peripherieblöcke, wie Taktgeneratoren, LCD-Controller, Touch Screen Controller, hochauflösende Analog-Digital-Wandler sowie USB-, Serielle- oder Ethernet Schnittstellen. Tatsache ist, dass nur die Komponenten verwendet werden, die auch wirklich benötigt werden, damit das zu erstellende Produkt so kostengünstig wie möglich produziert werden kann. Deshalb wird größtenteils auf Tastaturen, diverse Laufwerke, Lautsprecher und ähnliche Dinge verzichtet, die nicht gebraucht werden. Die wichtigsten Bestandteile eines Realzeitsystems sind der Microcontroller und der Speicher.Was für eine Art von MCU verwendet wird, hängt von den Anforderungen der jeweiligen Applikation ab. Eine MCU variiert in der Busbreite, der möglichen maximalen Größe des externen Speichers, der Anzahl von internen Peripheriegeräten (DMA channels, serial ports etc.) und der Arbeitsgeschwindigkeit (MIPS). Der Speicher hingegen wird für zwei Dinge benötigt: Zum einen, um Programmdaten 3

16 Kapitel 2 Eigenschaften eines Realzeitsystems des Systems zu speichern und zum anderen, um Anwendungsdaten zu sichern. Aufgrund der Tatsache, dass Realzeitsysteme meist keine Festplatte besitzen, von der sie ihre Programmdaten laden können, benötigen sie einen speziellen Speicher, der die Daten nicht abfließen lässt, wenn das Gerät ausgeschaltet ist. Deshalb wird für eine dauerhafte Speicherung von Software in elektronischen Geräten mit Mikrocontrollern, auch Firmware genannt, ein sogenannter Flash Speicher verwendet. Diese Art von Speicher ermöglicht eine persistente (nicht flüchtige) Sicherung von Daten, ist jedoch wegen seiner komplexen Ansteuerung für Anwendungsdaten nicht geeignet. Hier wird ein regulärer Speicher, wie zum Beispiel RAM verwendet (vgl.[sim99]). Abbildung 2.1: Vereinfachter Aufbau eines Mikrocontrollers (vgl.[lau99]) Eigenschaften des Entwicklungssystems Das zu erstellende Analysetool wird als eine sogenannte Host-Target Entwicklung realisiert. Dies hat den Grund, dass Software für ein zu erstellendes Realzeitsystem nicht auf dem Zielsystem selbst entwickelt werden kann. Daher wird ein Entwicklungsrechner, der Host, benötigt. Als Host-Rechner wird ein auf Microsoft Windows basierendes Rechensystem eingesetzt, da nur ein Windows-Betriebssystem zur Entwicklungssoftware kompatibel ist. Hier wird die Software winidea (windows Integrated Development Environment Advanced) der Fa. isystem AG verwendet. Das Zielsystem besteht aus einer MCU der Fa. Freescale Semiconductor. Es handelt sich hierbei um den Chipsatz MC68332 (CPU32) mit einer maximalen Taktfrequenz von 25 MHz und einem 24-bit Adressraum. Dieser Mikroprozessor ist auf einem Active POD gesteckt und steht über einen ic4000 Active Emulator, einen Power Emulator und einen Power Analyzer (ebenfalls alle von der FA. isystem AG) mit 4

17 2.2 Systemsicht dem Host-Rechner in Verbindung. Zur Speicherung von Programmdaten werden 1 MB Flash-Speicher verwendet und für die Sicherung von Anwendungsdaten 6 MB RAM. Aufgrund der Tatsache, dass das Zielsystem einen anderen Prozessor als der Host verwendet, muss ein so genannter Cross-Compiler eingesetzt werden. Dieser muss den Maschinencode für das Zielsystem erzeugen. Hierfür wird der Microtec C/C++ Compiler der Fa. Mentor Graphics verwendet. 2.2 Systemsicht Betrachtet man ein Echtzeitsystem genauer, so ist es nur ein Teil eines Gesamtsystems. Dieses Gesamtsystem wird in drei Untersysteme aufgeteilt (vgl.[mae05]) und ist auf Beispiel einer Zeiterfassung gestützt: Das Benutzersystem, in dem der Mensch als Teil des Systems betrachtet wird. Hier findet die Verarbeitung, Transformation und der Transport von Informationen aus der Sicht des Benutzers statt. Der User benutzt das System, um an die an das System gestellten Forderungen zu gelangen. Zum Beispiel bucht er seine Arbeitszeiten oder ruft Informationen über sein Urlaubskonto ab. Das interne System, eingebettet in die Umgebung (Embedded System), steuert das Gesamtsystem. Es nimmt die Eingaben des Benutzers entgegen und leitet die entsprechenden technischen Vorgänge ein, wie zum Beispiel einen Datenbankeintrag oder eine Datenbankabfrage. Das externe System beschreibt die natürliche oder technische Umwelt. Die Steuerung des internen Systems ist bestrebt, die vorgegebenen Bedingungen einzuhalten und somit einen korrekten Ablauf sicher zu stellen. Abbildung 2.2: Anwendungsfall-Diagramm: Zeiterfassungsterminal 5

18 Kapitel 2 Eigenschaften eines Realzeitsystems 2.3 Prozesssicht Betrachtet man das Gesamtsystem aus einer anderen Perspektive, nämlich aus der Prozesssicht, wird das System in drei Prozesse unterteilt (vgl.[lau99]). Zuerst zur Bedeutung des Begriffs Prozess: Ein Prozess ist im Allgemeinen ein Vorgang, ein Ablauf, ein Geschehen (vom lateinischen procedere = voranschreiten). Dieser Vorgang bewirkt eine Zustandsänderung von materiellen Dingen, Energien oder Informationen. Der technische Prozess ist ein Vorgang, durch den Materie, Energie oder Information in ihrem Zustand verändert wird. Diese Zustandsänderung kann beinhalten, dass ein Anfangszustand in einen Endzustand überführt wird. Es ist auch ein Prozess, bei dem physikalische Größen mit technischen Mitteln (Sensoren, Aktoren) beinflusst werden. Durch den Rechenprozess wird auf die Zustandsinformationen des technischen Prozesses reagiert. Die Aufgabe des Rechenprozesses ist die Umformung, Verarbeitung und der Transport der gewünschten Information. Es ist ein Programm, welches die Abfolge von Befehlen beschreibt. Ebenso ist es die Schnittstelle zwischen dem Benutzer (Eingaben) und den Mess- und Stellgliedern des technischen Prozesses. Anstelle des Begriffs Rechenprozess wird auch oft der Begriff Task verwendet. Unter Benutzerprozess versteht man die Verarbeitung, die Transformation und den Transport von Informationen aus der Sicht des Bedieners. Durch eine Mensch-Maschine-Schnittstelle (HMI, Human-Machine-Interface) kann der Benutzer Einfluss auf die Rechenprozesse und direkt auf die technischen Prozesse nehmen. 6

19 2.4 Besondere zeitliche Anforderungen Abbildung 2.3: Prozesssicht (vgl.[lau99]) 2.4 Besondere zeitliche Anforderungen Bei einem Realzeitsystem handelt es sich um ein System, das in der Lage sein muss, eine Aufgabe innerhalb eines spezifizierten Zeitfensters abzuarbeiten. Ein wichtiges Merkmal ist daher die Pünktlichkeit oder Rechtzeitigkeit. Dies hat zur Folge, dass nicht nur ein richtiges Ergebnis (Richtigkeit) geliefert werden muss, sondern dieses auch zum richtigen Zeitpunkt bereit gestellt werden muss. Damit ist ein System dieser Art insbesondere mit der Eigenschaft verbunden, dass es zeitlich deterministisch (zu jeder Zeit berechenbar, oder zumindest vorhersehbar und vorhersagbar) ist. Eine oftmals notwendige Eigenschaft, aber keinesfalls kennzeichnend, ist die Schnelligkeit eines Echtzeitsystems (vgl.[qua06]). 7

20 Kapitel 2 Eigenschaften eines Realzeitsystems Definition von Echtzeitbetrieb: Echtzeitbetrieb ist ein Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, dass die Verarbei- tungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die Daten können je nach Anwendungsfall, nach einer zufälligen zeitlichen Verteilung oder zu vorbestimmten Zeitpunkten auftreten [DIN 44300]. Abbildung 2.4: Unterschied einer Echtzeit-Datenverarbeitung (vgl.[saw05]) Realzeitsysteme werden praktisch in allen Bereichen eingesetzt. Prinzipiell verarbeiten sie Eingangswerte (z. B. Zustandsgrößen technischer Prozesse) und berechnen zeitgerecht die zugehörigen Ausgangsgrößen (Werte für Stellglieder). Die Ein- und Ausgangsgrößen werden dem Echtzeitsystem über Wandler (z. B. Aktoren und Sensoren eines technischen Prozesses) zugeführt (vgl.[qua06]). Steuert bzw. regelt das Echtzeitsystem einen technischen Prozess, ohne dass ein Benutzer direkt damit in Berührung kommt (eingebettete mikroelektronische Steuerung), spricht man von einem eingebetteten Realzeitsystem. In der Automobilbranche finden sich eingebettete Realzeitsysteme beispielsweise zur Steuerung des Motors (Motormanagement), zur Ansteuerung eines Anti-Blockier-Systems (ABS) oder zur Überwachung der Airbags (vgl.[qua06]). In vielen Fällen werden Realzeitsysteme in sicherheitskritischen Umfeldern (z. B. ABS) eingesetzt. Zur Anforderung nach Rechtzeitigkeit kommen deshalb auch die Forderungen nach Sicherheit (das System muss zwingend das richtige Ergebnis liefern) und Verfügbarkeit (das System darf unter keinen Umständen ausfallen) hinzu (vgl.[qua06]). Aus diesem Grund wird auch zwischen der sogenannten harten und weichen Echtzeit unterschieden (vgl.[pom04]). 8

21 2.4 Besondere zeitliche Anforderungen Harte Echtzeitsysteme In diesen Systemen gilt die strenge Einhaltung von Zeitschranken (deadlines), die unter gar keinen Umständen verletzt werden dürfen. Besipiele hierfür sind Regelungen in Flugzeugen, Kraftfahrzeugen und Kraftwerken. Hier führt eine Verletzung der Zeitschranken zu erheblichen Schäden. Weiche Echtzeitsysteme Die weitaus größere Anzahl von Systemen sind diejenigen, bei denen eine Verletzung der Echtzeitbedingungen hin und wieder toleriert wird. Beispiele hierfür sind Kaffeemaschinen oder Audio- und Video-Streaming. Ein kurzes Ruckeln kann hin und wieder verschmerzt werden, ohne dass dabei ein Menschenleben auf dem Spiel steht und höhere Kosten durch diese Verursachung entstehen. Abbildung 2.5: Realzeitsysteme und ihre Zeitanforderungen [TiMo97] Gemäß der obigen Definition sind also alle Systeme mit zeitlichen Anforderungen Echtzeitsysteme. Die Abbildung 2.5 spiegelt entsprechend den zeitlichen Forderungen sinnvolle Realisierungstechnologien wieder. Dabei wird erkennbar, dass Echtzeitsysteme sogar von Hand betrieben werden können, wenn nur sehr langsame Reaktionszeiten gefordert werden. Muss auf zeitliche Anforderungen im Minutenbereich reagiert werden, können auch mechanische Steuerelemente eingesetzt werden. Mit Standard-Betriebssystemen ist es bereits möglich, Realzeitanforderungen im Sekundenbereich zu bedienen. Sind zeitlich strengere Eigenschaften gefordert, muss ein Realzeitbetriebssystem eingesetzt werden, solange Anforderungen im Mikrosekunden-Bereich liegen. In diesem Zeitbereich lassen sich Probleme zwar noch mit Software lösen, entsprechende Reaktionen müssen aber innerhalb der sogenannten Interrupt Service Routine (ISR) erfolgen. Um noch stärkere Anforderungen zeitlicher Natur zu befriedigen, muss letztendlich eine Hardware-Realisierung gewählt werden (vgl.[qua06]). Zusammenfassend lauten die wichtigsten Eigenschaften der Echtzeitsysteme: Pünktlichkeit Rechtzeitigkeit Determinismus Sicherheit Verfügbarkeit 9

22 Kapitel 2 Eigenschaften eines Realzeitsystems 10

23 Kapitel 3 Inbetriebnahme eines Mikrocontrollers bzw. Mikroprozessors Vor der eigentlichen Realisierung des Analysetools für das Realzeitsystem AMX muss als erstes die Hardware für den Gebrauch als Realzeitsystem vorbereitet werden. Es muss sichergestellt werden, dass mit dem im System eingesetzten Mikroprozessor kommuniziert werden kann, um damit die Peripherie im System ansteuern zu können. Dies bedeutet, dass die Register des Mikroprozessors und der eingesetzte Speicher initialisert werden müssen. Da in jedem Realzeitsystem die Zeit eine wichtige Rolle spielt, benötigt das System eine Arbeitsgeschwindigkeit, den sogenannten Systemtakt. Dieser zentrale Systemzeitgeber (Timer) definiert den System Tick eines Realzeitsystems, ist jedoch nicht mit der Arbeitsgeschwindigkeit der CPU zu verwechseln. Genauso wird in jedem Realzeitsystem mit Interrupts gearbeitet. Jeder Interrupt erhält eine zugehörige Interrupt Service Routine (ISR), die alle in einer Tabelle definiert werden müssen, damit sie vom System zu jeder Zeit gefunden werden können. 3.1 Interrupt In der Informatik versteht man unter einem Interrupt (lat. interruptus, Unterbrechung) eine kurzfristige Unterbrechung eines Programmes. Die Aufgabe eines Interrupts ist es, schnell auf Ein-/Ausgabe-Signale (z. B. Touch Screen, Netzwerk, Chip-Leser etc.) oder einen Zeitgeber (Timer) zu reagieren. Interrupts sind nötig, um auf zeitkritische Ereignisse reagieren zu können und sind deshalb in Echtzeitsystemen besonders wichtig. Aus diesem Grund haben MCU s, welche in diesen Systemen üblicherweise verwendet werden, meist mehrere Interrupteingänge. Diese Eingänge werden über Interrupt-Leitungen des Systembusses angesprochen, welche die sogenannten Interrupt Requests (IRQ, Unterbrechungsanfragen) über diese Leitungen an den Prozessor senden und diesem somit mitteilen, dass Informationen 11

24 Kapitel 3 Inbetriebnahme eines Mikrocontrollers bzw. Mikroprozessors zur Weiterverarbeitung bereitstehen. Diese Interrupt-Leitungen könnte man ebenso als prozessorexternen Datenbus bezeichnen. Die an die CPU angeschlossene Hardware (Serial Port, Netzwerkkarte etc.) muss demnach ebenfalls interruptfähig sein. Ausgelöst werden Interrupts durch eine Elektronikkomponente, den Interrupt Controller. Dieser ist die Funktionseinheit, die für die Entgegennahme und Verteilung von Interrupts zuständig ist. Sie signalisiert der CPU einen IRQ. Ein an die CPU angeschlossenes Gerät erzeugt beim Eintreffen eines bestimmten Ereignisses einen Interrupt und bewirkt ein Ausgangssignal (eine elektrische Spannung) an einem Ausgangs-Pin. Die CPU besitzt im einfachsten Fall einen entsprechenden Eingangs- Pin. Erscheint an diesem Pin eine elektrische Spannung, so startet innerhalb der CPU eine Sequenz von Befehlen, die eine entsprechende ISR einleitet. Hardware Interrupts sind im Normalfall (ausgenommen Timer, Quarzuhren etc.) grundsätzlich asynchron, d. h. sie treten zu einem unbestimmten Zeitpunkt auf. Aus diesem Grund dürfen Interrupts ohne besondere synchronisierende Maßnahmen keinen direkten Einfluss auf Programme (oder Programmvariablen) ausüben (vgl.[sim99]). Abbildung 3.1: Hardware Interrupt (vgl.[sim99]) Prozessoren kennen auch spezielle Befehle, welche sogenannte Software-Interrupts aus einem laufenden Prozess heraus auslösen. Diese wirken wie Unterprogrammaufrufe und sind daher nicht asynchron. Das gleiche gilt für Traps, die von der CPU bei schweren Ausnahmefehlern (geschützte Zugriffe, verbotene Instruktionen, Division durch Null etc.) selbst ausgelöst werden und sich den gleichen Mechanismen bedienen (vgl.[wiki]). 3.2 Interrupt Service Routine Bemerkt ein Mikroprozessor, dass ein Signal an einem seiner Interrupt Request Pins anliegt, stoppt er die Ausführung der aktuellen Ablaufsequenz, sichert die Adres- 12

25 3.2 Interrupt Service Routine se des unterbrochenen Programms auf dem Stack und springt zur angeforderten, zugehörigen Interrupt Service Routine. Diese Interrupt Routinen, auch Interrupt Handler Routinen genannt, sind Unterroutinen, die der Entwickler eines solchen Systems in der jeweiligen Programmiersprache schreibt. Sie erledigen die eigentlichen Aufgaben des jeweiligen Interrupts. Wenn beispielsweise ein serieller Port ein Zeichen durch einen Interrupt sendet, hat die ISR die Aufgabe diesen zu lesen und im Speicher abzulegen. Darüberhinaus muss sie noch eine weitere wichtige Aufgabe erfüllen, nämlich den angelegten Interrupt auf der Hardware Seite des Mikroprozessors zurücknehmen (Reset), damit weitere Interrupts erkannt werden können. Der letzte Befehl, der in einer Interrupt Service Routine ausgeführt wird, ist eine Assembler-Anweisung, ein sogenannter Return from Interrupt. Wird dieser Punkt erreicht, so erhält der Mikroprozessor die Adresse der durch den Interrupt unterbrochenen Programmsequenz vom Stack und nimmt dessen Ausführung wieder auf. Des Weiteren benötigt der Mikroprozessor beim Eintreffen eines Interrupts keinen CALL- Befehl, sondern führt die Unterbrechungsroutine automatisch aus (vgl.[sim99]). Im nachfolgenden Beispiel (vgl.[sim99]) ist ein Ausschnitt eines Programms zu sehen, welches Gradwerte in Fahrenheit umwandelt. Betrachtet wird ein beliebiger Mikroprozessor, der einen Interrupt erhält, welcher gerade beschäftigt ist, Task Code zu bearbeiten (die eigentliche Berechnung), der nicht Teil der ISR ist. Das eigentliche Programm lädt Temperaturwerte in Grad nach Register R1, tätigt die benötigte Arithmetik und speichert das fertige Ergebnis. Wird dem Mikroprozessor jetzt ein Interrupt gemeldet, unterbricht er die eigentliche Berechnung und springt zur Interrupt Service Routine. Er bearbeitet sämtliche Instruktionen der Unterbrechungsroutine, bis er zur RETURN-Anweisung am Ende der ISR gelangt. Danach wechselt er wieder zur eigentlichen Berechnung, dem Konvertieren von Werten in Grad nach Fahrenheit. 1 / Task Code / / ISR / MOVE R1, ( igrad ) 4 MULTIPLY R1, 9 > PUSH R1 5 PUSH R !! Lese Wert von der Hardware i n R e g i s t e r R1 8!! S i c h e r e Wert von R1 i n den S p e i c h e r !! S e t z e den s e r i e l l e n Port zurück 11!! S e t z e I n t e r r u p t Hardware zurück POP R2 14 POP R1 15 DIVIDE R1, 5 < RETURN 16 ADD R1, MOVE ( i F a h r e n h e i t ), R1 18 JCOND ZERO, 109A1 19 JUMP MOVE R5, PUSH R5 22 CALL Skiddo 23 POP R9 24 MOVE ( Antwort ), R1 25 RETURN Listing 3.1: Beispiel einer Interrupt Service Routine - Pseudocode 13