Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Institut für Angewandte Mikroelektronik und Datentechnik Fachbereich Elektrotechnik und Informationstechnik, Universität Rostock Vorlesung Echtzeitbetriebssysteme.

Ähnliche Präsentationen


Präsentation zum Thema: "Institut für Angewandte Mikroelektronik und Datentechnik Fachbereich Elektrotechnik und Informationstechnik, Universität Rostock Vorlesung Echtzeitbetriebssysteme."—  Präsentation transkript:

1 Institut für Angewandte Mikroelektronik und Datentechnik Fachbereich Elektrotechnik und Informationstechnik, Universität Rostock Vorlesung Echtzeitbetriebssysteme III. Entwurf von Echtzeitsystemen Dr.-Ing. Frank Golatowski

2 Institut MD Universität Rostock Ziele der Vorlesung Aufzeigen, welche Möglichkeiten es gibt, ein Echtzeitsystem zu konstruieren. –Sowohl ohne Betriebssystem –als auch mit Betriebssystem

3 Institut MD Universität Rostock Gliederung: Mögliche Wege, ein Echtzeit-System zu konstruieren Polling in einer Endlosschleife (Polled Loop Systems) –Polled Loop ohne Interrupts –Polled Loop mit Interrupts Phase/ State Driven Code Coroutine –Kooperatives Multitasking –Spezialfall: Zyklische Exekutive Interruptgesteuertes Systems Multitasksysteme –Kooperatives Multitasking (non-preemptive Multitasking) –Preemptives prioritätsbasiertes Multitasking

4 Institut MD Universität Rostock Gliederung Polling in einer Endlosschleife (Polled Loop Systems) Phase/ State Driven Code Coroutine Interrupt Driven Systems Foreground / Background Systems RTOS

5 Institut MD Universität Rostock Unendliche Pollingschleife Polled Loop Systems Einfachster RT-Kernel Schnelle Reaktion auf einzelne Ereignisse In einer einzelnen sich wiederholenden TEST-Operation wird auf das Vorhandensein bzw. Nichtvorhandensein eines Ereignisses getestet In Abhängigkeit vom Vorhandensein des Ereignisses wird eine bestimmte Funktion ausgeführt. (Hier: ProcessData()) Es ist keine IPC und kein Scheduling erforderlich, da nur eine einzelne Task existiert main() { FLAG flPacketFlag; for (;;){ if (flPacketHere == TRUE) { ProcessData(); // Daten verarbeiten flPacketHere=FALSE); // reset Flag } Max 1 Datenpaket erreicht im Abstand von 1s das System Ein Flag PacketHere wird durch das Netzwerk gesetzt, wenn ein Paket eintrifft. Daten werden per DMA in den Speicher der CPU geschrieben Daten sind verfügbar, wenn Packethere = 1

6 Institut MD Universität Rostock Unendliche Pollingschleife Anwendung Wenn ein einzelner Prozessor für die Behandlung weniger schneller Geräte vorgesehen ist. Wenn Ereignisse sich nicht überlappen bzw. wenn die Überlappung minimal ist oder minimal gehalten werden kann

7 Institut MD Universität Rostock Unendliche Pollingschleife ohne Interrupts Eine Hauptschleife bedient alle I/O-Anforderungen sequentiell 1. Zum Auffinden eintreffender Ereignisse werden alle I/O- Leitungen / Geräte getestet 2. Als Reaktion auf die eintreffende Ereignisse werden Funktionen ausgeführt –Gut für sich regelmäßig (vorhersagbar) ändernde Eingaben z.B Baud serieller Port –Schlecht für sich unregelmäßig ändernde Eingaben, die schnelle Reaktionen erfordern Systeme mit einer großen Anzahl von Eingängen z.B. Alarm-Signale, asynchrone Eingaben z.B. von einer Tastatur

8 Institut MD Universität Rostock main() { for (;;){ CheckInputs(); CheckDigitalInterfaces(); Application(); } Unendliche Pollingschleife ohne Interrupts als zyklische Exekutive (ZE) Beispiel für Codeabschnitte main() { i =0; for (;;){ CheckInputs(); CheckDigitalInterfaces(); switch (i){ case 0 : application0();break; case 1 : application1();break; case 2 : application2();break; case 3 : i=0;break; } i++; }

9 Institut MD Universität Rostock Unendliche Pollingschleife ohne Interrupts mit zykl. Exekutive Das Problem der zyklischen Exekutive liegt im Code- Splitting –I/O-Polling verschwendet CPU-Zeit –Test auf Korrektheit des Algorithmus und des Zeitverhaltens nach der Aufsplittung –Immer wenn der Code verändert wird, ist ein Neuaufsplitten mit nachfolgendem Test auf Korrektheit erforderlich –Wartung und Pflege solcher Software sehr schwierig Code schwer lesbar Bei Wechsel der Hardware u.U. Neustrukturierung der Software erforderlich Tests der Algorithmen und des Timings

10 Institut MD Universität Rostock Unendliche Pollingschleife mit Interrupt Diese Variation der Pollingschleife nutzt einen festen Uhren-Interrupt Es wird eine bestimmte Zeitdauer abgewartet, zwischen dem Erkennen, dass das FLAG = TRUE ist und dem erneuten Rücksetzen auf FALSE –Wird zum Schalter-Entprellen verwendet: Eine Verzögerungszeit kann z.B. mit programmierbaren Timer realisiert werden, der einen Interrupt auslöst nachdem ein Zählerwert heruntergezählt wurde.

11 Institut MD Universität Rostock Unendliche Pollingschleife mit Interrupt main() { int FLAG; for (;;){ // Endlosschleife if (FLAG == TRUE){ // Ereignis erkannt counter = 0; while (counter < 3); // Warte FLAG = FALSE; ProcessEvent(); } Counter_ISR() // tickert alle 10 ms { counter++; } Pollingsystem verarbeitet ein Ereignis, das zufällig eintrifft. Jedoch erreicht max 1 Ereignis/s das System Ereignis prellt (Schalterprellen 20ms) Das Ereignis wird durch ein externes Gerät gesetzt, das ein Flag im Speicherbereich des Systems auf TRUE setzt genutzt wird ein 10ms fixed rate interrupt zur Synchronisation Schalterposition Zeit Off On

12 Institut MD Universität Rostock main() { for (;;){ ServiceOperator(); UpdateTimeOnDisplay(); HandleQueuedEvents(); } Unendliche Pollingschleife mit Interrupts Beispiel Serial_ISR() { ReadCharFromPort(); PutCharIntoBuf(); if(CompleteLine){ SendBufToAppl(); GetNewBuf(); } digital_ISR() { event = ReadDigitalInterface; time = ReadSystemClock; EnqueueEvent(event, time); } ISR wird jedesmal aufgerufen, wenn ein Zeichen am Seriellen Port eintrifft ISR wird jedesmal aufgerufen, wenn eine Übertragung an einem der parallelen Schnittstellen festgestellt wurde

13 Institut MD Universität Rostock Unendliche Pollingschleife mit Interrupts Eine Hauptschleife bedient alle I/O-Anforderungen sequentiell, aber die Verarbeitung kritischer I/O wird nicht in der Schleife bedient Typische Herangehensweise, die verändert werden sollte. –Z.B. häufig verwendet MS/DOS-basiertes System: Steuerschleife und mehrere Interruptserviceroutinen (TSR) –häufig verwendet in Steuerungen, die Mikrocontroller nutzen –Nutzung von MS/DOS-Betriebssystemfunktionen in einer ISR nicht möglich, wegen fehlender Wiedereintrittsfähigkeit

14 Institut MD Universität Rostock Unendliche Pollingschleife mit Interrupts Probleme –Es treten die gleichen Probleme wie beim Endlos-Polling ohne Interrupts auf, wenn viele Ereignisse zu verarbeiten sind. –Performanceanalyse schwierig. Muß Laufzeiten der ISR´s berücksichtigen und Häufigkeit des Auftretens der Ereignisse. –Die Behandlung einiger Ereignisse kann sich unnötig verzögern. Funktionen der Hauptschleife werden in einer vorbestimmten Reihenfolge aufgerufen, die nicht übereinstimmt mit dem aktuellen Auftreten der Ereignisse

15 Institut MD Universität Rostock PLS Anwendung Einfach zu schreiben und zu debuggen Reaktionszeit einfach zu bestimmen (ohne Interrupts) Gut für die Behandlung von High-Speed Datenkanälen mit Arbeiten fehlerhaft, wenn das Eintreffen von Ereignissen im Burst nicht berücksichtigt wurde Nicht in komplexen und komplizierten Systemen Nutzen CPU-Zeit (aktives Warten) –Insbesondere dann, wenn das Ereignis das abgefragt (gepollt) wird häufig auftritt.

16 Institut MD Universität Rostock Gliederung Polling in einer Endlosschleife (Polled Loop Systems) Phase/ State Driven Code Coroutine Interrupt Driven Systems Foreground / Background Systems RTOS

17 Institut MD Universität Rostock Phasen- und Zustandsgesteuerter Code Verwendet verschachtelte – Statements –Zustandsautomat (FSA) eine solche Unterteilung der Prozesse ermöglicht es, dass jeder Abschnitt vor dem Ende temporär suspendiert werden kann, ohne dabei kritische Daten zu verlieren Umsetzung des Multitasking mittels Coroutinen Es gibt einige Prozesse, die sehr gut mittels FSM implementiert werden können. FSA-Implementierung gut für Compilier-Prozess besteht aus mehreren Phasen: lexikalische Analyse, Parsing, Codegenerierung, Optimierung Kommunikationsprogramme, wie z.B. Netzwerkpakethandler sind meist unterteilt in mehrere Phasen case If... then

18 Institut MD Universität Rostock Software Zustandsmaschine (FSM) Zustandsmaschinen speichern interne Zustände in einer Variablen. Zustandswechsel erfolgen, wenn Eingänge sich ändern. Verwendet in: –control-dominated code; –reactive systems.

19 Institut MD Universität Rostock main() { int flag =1; for (;;){ switch (flag){ case 1 : { PerformPart1();flag=2; break;} case 2 : { PerformPart2();flag=3; break;} case 3 : { PerformPart3();flag=1; break;} } Phasen- und Zustandsgesteuerter Code Beispiel: Einfacher Prozeß, der drei Zustände einnimmt. Am Ende jedes Prozesses wird der Zustand des Flags gesetzt Bei einem Neustart des Systems arbeitet das System an der Stelle weiter, an der es unterbrochen wurde Eine andere Möglichkeit eine FSM umzusetzen besteht in der Nutzung einer Tabelle

20 Institut MD Universität Rostock AB C D in1=1/x=a in1=0/x=b r=0/out2=1 r=1/out1=0 s=1/out1=1 s=0/out1=0 State machine specification

21 Institut MD Universität Rostock Wie eine solche Struktur in C aussieht (C code structure) Aktueller Zustand wird in einer Variablen gespeichert Zustandstabelle als Switch implementiert –Cases definieren die Zustände –Zustände können Eingänge testen Switch wird in einer While-Schleife wiederholt

22 Institut MD Universität Rostock C state table switch (state) { case A: if (in1==1) { x = a; state = B; } else { x = b; state = D; } break; case B: if (r==0) { out2 = 1; state = B; } else { out1 = 0; state = C; } break; case C: if (s==0) { out1 = 0; state = C; } else { out1 = 1; state = D; } break; C state machine structure while (TRUE) { switch (state) { case state1:... }

23 Institut MD Universität Rostock Phasen- und zustandsgesteuerter Code Zusammenfassung State-Driven Systems können in vielen Sprachen kodiert werden: Nutzung der IF-THEN bzw. CASE -Anweisungen. Für komplexe Systeme wird eine Umsetzung über Tabellen vorgezogen Können in Verbindung mit Polling-Schleife verwendet werden: –Der erste Zustand testet Flags –Der zweite Zustand verarbeitet die Daten, wenn das Flag gesetzt ist Nicht alle Applikationen sind geeignet, in mehrere Zustände aufgeteilt zu werden. Tabellen, die zur Implementierung dieser Technik erforderlich sind, können groß werden. Manuelle Translation von FSM Tabelle fehlerbehaftet.

24 Institut MD Universität Rostock Gliederung Polling in einer Endlosschleife (Polled Loop Systems) Phase/ State Driven Code Coroutine Interrupt Driven Systems Foreground / Background Systems RTOS

25 Institut MD Universität Rostock Coroutine Die Coroutine ist eine Programmiertechnik, die in den Anfängen der Embedded Systeme häufig verwendet wurde, um Prozesse zu verarbeiten Wird heute kaum noch verwendet Ist jedoch ein gutes Beispiel, um Probleme aufzuzeigen, die sich ergeben, wenn versucht wird diverse komplexe Steuerungen zwischen mehreren Prozesse zu realisieren, ohne Prozesse zu verwenden Kombination mit phasen/zustandsgesteuertem Code

26 Institut MD Universität Rostock Coroutine: Eigenschaften Ähnlich wie Unterprogramm, jedoch bestimmt der aufrufende Programmabschnitt die Rücksprungadresse. Coroutinen geben die Steuerung freiwillig ab. Erfordert disziplinierte Programmierung

27 Institut MD Universität Rostock Zeitlicher Ablauf von zwei Coroutinen Wenn eine Routine die Steuerung übergeben möchte, dann lädt sie ihre Return- Adresse in ein entsprechende Register (ist vom Prozessortyp abhängig) und lädt den Befehlszähler mit dem Returnwert der anderen Co-Routine Vorsichtiges Verwenden von Registern, die evtl. von anderen Co-Routinen verwendet werden.

28 Institut MD Universität Rostock Steuerfluß von zwei Coroutinen ARM-Prozessor ADR r14,co2a co1aADR r0, a LDR r1, [r0] ADD r1,#5 STR r1, [r0] ADR r13,c01b MOV r15,r14 co1bADR r3, b LDR r4,[r3] BNE r4, #2 ADR r13,c01b MOV r15,r14 co1c.. R15 ist Befehlszähler Coroutine 1 co2aADR r3, w LDR r4, [r3] STR r4, r0 ADR r13,c02b MOV r15,r13 co2bADR r3, x LDR r4,[r3] BNE r5, y STR r4, r5 ADR r13,c02c MOV r15,r13 co2c.. Coroutine 2 R14 enthält die Rücksprung- adresse der Coroutine2 R13 von Coroutine1

29 Institut MD Universität Rostock Zeitlicher Ablauf von zwei Coroutinen Es sind allgemeinere Steuerflüsse programmierbar, als nur mit Subroutinen. Minimale Vereinfachung des Softwareentwurfs, der Zeitforderungen erfüllen muß. Nicht geeignet, um komplexe Programme mit signifikanten Zeiteigenschaften zu konstruieren Kann auch ohne Zeitforderungen unangenehm zu programmieren sein. Schwer zu debuggen

30 Institut MD Universität Rostock Zyklische Exekutive Besteht nur aus einer Co-Routine

31 Institut MD Universität Rostock Coroutine mit Betriebssystemunterstützung: Kooperatives Multitasking Nach jeder Phase wird zentraler Dispatcher aufgerufen Dispatcher verwaltet die Befehlszähler für eine Liste von Prozessen, die entsprechend RR ausgeführt werden. Er wählt den nächsten Prozess aus, der ausgeführt werden soll. Kommunikation zwischen den Prozessen mittels globalen Variablen. –Alle Daten, die zwischen den Dispachtes benötigt werden, müssen in globalen Variablen gespeichert werden.

32 Institut MD Universität Rostock Kooperatives Multitasking Context-Switch von Tasks –Wenn ein Multitasking-System sich entscheidet eine andere Task auszuführen, dann wird einfach der Kontext der aktuellen Task auf seinem Stack gesichert –Der Kontext der neuen Task wird wiederhergestellt, indem die zuvor auf dem Stack gespeicherten Daten von dort geholt werden

33 Institut MD Universität Rostock In einem kooperativen Multitaskingsystem gibt ein Prozeß die CPU freiwillig an einen anderen ab. Er ist kooperativ. Kann ähnlich wie in Unterprogrammen umgesetzt werden, enthält aber keinen Rücksprung Anstelle des Rücksprungs wird eine spezielle Kontextwechselfunktion aufgerufen. Ein Systemruf für Context-switch Ähnlich zur Coroutine: Hauptunterschied: hier wird ein Scheduler verwendet Kooperatives Multitasking yield_CPU() cswitch

34 Institut MD Universität Rostock if (x>2) sub1(y); else sub2(y,z); proca(a,b,c) yield_CPU(); Zwei kooperative Multitaskingprozesse ProcData(r,s,t) if (val1==3) abc(val2); rst (val3); Task1Task2 SaveState(current); p = ChooseProcess; Scheduler LoadAndGO(p); yield_CPU();

35 Institut MD Universität Rostock Round-Robin Systeme Prozesse werden sequentiell, bis zu ihrem Ende ausgeführt RR mit fester Zeitscheibe (time slice) –Systemuhr mit fester Rate –Wenn Prozess Zeitscheibe überschreitet, wird er unterbrochen. –Wenn er nicht beendet wurde muss sein Kontext gespeichert werden. –Prozess wird am Ende der Warteschlange platziert.

36 Institut MD Universität Rostock Kooperatives Multitasking Zusammenfassung Andere Begriffe: non-preemptive, round-robin Windows 3.1, Windows 9x

37 Institut MD Universität Rostock Gliederung Polling in einer Endlosschleife (Polled Loop Systems) Phase/ State Driven Code Coroutine Interrupt Driven Systems Foreground / Background Systems RTOS

38 Institut MD Universität Rostock Interrupt gesteuerte Systeme Interrupt-driven MS/DOS, Mikrocontroller Das Hauptprogramm ist eine Endlosschleife

39 Institut MD Universität Rostock Contextwechsel Kontextwechsel hat maßgeblich Einfluss auf die Reaktionszeit Muss minimal sein Kontext eines Prozesses –Inhalt der Register –PC –Inhalt der Coprozessorregister –Memory page register –Spezielle Variablen

40 Institut MD Universität Rostock Contextwechsel void main(void) { init();/* Initialisierung des Systems, Laden d. Int.Handler*/ while (TRUE); } void int1(void) /* Inthandler 1 */ { save(context); task1(); restore(context); } void int2(void) /* Inthandler 2 */ { save(context); task2(); restore(context); } void int3(void) /* Inthandler 3 */ { save(context); task3(); restore(context); } RTS besteht aus einem einfachen Main- Programm und drei Interrupthandlern, die den Context auf dem Stack speichern

41 Institut MD Universität Rostock Interrupts sind der ideale Mechanismus, um einen Kontextwechsel in einem preemptiven Multitasking- System umzusetzen. Timer-Driven preemption: Ein Timer generiert periodisch Interupts: –Herzschlag eines Betriebssystems Preemptives Multitasking CPU TIMER

42 Institut MD Universität Rostock Ein Interrupt-gesteuerter (interrupt-driven) preemptiver Kontextwechsel erzeugt einen allgemeinen Programmfluß, der ähnlich dem Prozedur-gesteuerten (procedure-driven) kooperativen Taskwechsel ist Zur Implementierung können gleiche Techniken, wie beim kooperativen Multitasking eingesetzt werden. Unterschied liegt im auslösenden Ereignis des Kontextwechsels: –freiwillige Abgabe der CPU bei kooperativem MT –Timer-Interrupt beim preemptiven MT Preemptives Multitasking

43 Institut MD Universität Rostock Gliederung Polling in einer Endlosschleife (Polled Loop Systems) Phase/ State Driven Code Coroutine Interrupt Driven Systems Foreground / Background Systems RTOS

44 Institut MD Universität Rostock Foreground/Background- Systeme FG/BG-Systeme sind Erweiterungen zu reinem Interruptgesteuerten Systemen: –PLS (s. main() ) = Dummy BG-Prozess ersetzen durch sinnvolle Prozessausführung FG/BG-Systeme sind die häufigste Lösung in embedded Systemen void main(void) { init(); while (TRUE); } void int1(void) /* Inthandler 1 */ { save(context); task1(); restore(context); } void int2(void) /* Inthandler 2 */ { save(context); task2(); restore(context); } void int3(void) /* Inthandler 3 */ { save(context); task3(); restore(context); }

45 Institut MD Universität Rostock FG/BG-Systeme sind die häufigste Lösung in embedded Systemen Enthalten einige interruptgesteuerte Prozesse oder Real-Time-Prozesse (FG) und einige nicht interruptgesteuerte Prozesse (BG) FG Tasks laufen als RR oder preemptive prioritätsbasierte Prozesse oder Kombinationen aus diesen. BG Tasks sind voll unterbrechbar durch FG- Prozesse =Task mit niedrigster Prio. Alle RT-Lösungen sind Spezialfälle der FG/BG- Systeme

46 Institut MD Universität Rostock Alle RT-Lösungen sind Spezialfälle der FG/BG-Systeme PLS = FG/BG ohne FG, Polling in BG Hinzufügen von Int.s zur Synchronisation vollständiges FG/BG-System Phasen gesteuerter Code = FG/BG ohne FG, PD in BG Coroutine = komplizierter BG-Prozess Nur interruptgesteuert = FG/BG System ohne BG

47 Institut MD Universität Rostock F: Was sollte im Hintergrund ausgeführt werden? A: Alles was nicht zeitkritisch ist. BG-Prozess wird immer ausgeführt, außer das System ist überlastet. –Überlast = Die Vordergrundprozesse lasten das System voll aus. Rate mit der BG ausgeführt wird, ist abhängig von Auslastung und kann sehr gering sein. Rechenzeit des BG-Prozesses 1 – Auslastung aller FG-Prozesse Background Processing t= Beispiel1: 6 / 0,15 = 40 Beispiel2: 10 / 0,45 = 22,22

48 Institut MD Universität Rostock Background Processing F: Welche Prozesse sind nicht zeitkritisch und können im BG ausgeführt werden? Häufig: Zähler im BG inkrementieren. Zum Messen der Auslastung bzw. zum Detektieren, ob der FG sich aufgehängt hat. Z.B. für jeden FG-Prozess individuellen Zähler im BG-Prozess, die dekrementiert werden müssen durch FG. = Software-Watchdog

49 Institut MD Universität Rostock Berechnung der Periode des BG- Prozesses A: C=1, T=4, U=0,25 B: C=1, T=5, U=0,2 C: C=8, T=20, U=0,4 BG: C=6 A B C BG

50 Institut MD Universität Rostock Berechnung der Periode des BG- Prozesses A: C=1, T=4, U=0,25 B: C=1, T=5, U=0,2 BG: C=10 A B BG

51 Institut MD Universität Rostock Initialisierung Initialisierung ist erste Aufgabe des BG-Prozesses –Disable Interrupts –Setzen (des) der Interruptvektor(en) und Stack initialisieren –Selbsttest ausführen –Systeminitialisierung ausführen –Enable Interrupts

52 Institut MD Universität Rostock Real-Time Operationen Werden i.A. im Vordergrund ausgeführt. Die real-time oder FG-Operationen sind die gleichen, wie in reinen Interrupt-Systemen. D.h. was im Vordergrund (FG) ausgeführt werden soll, ist identisch mit dem, was in Interruptsystemen ausgeführt wird.

53 Institut MD Universität Rostock Zusammenfassung FG/BG Beschriebene RT-Lösungen lassen sich in Modifikationen als FG/BG-Prozesse beschreiben. Häufig verwendet Entscheidender Nachteil: –Interfaces zu komplizierten Geräten und Netzwerken müssen geschrieben werden. Am besten, wenn die Anzahl der FG-Prozesse apriori bekannt und fest. Anfällig gegenüber Zeitvariationen, Wettlaufbedingungen, Hardwarefehler... einige Firmen gestatten keine Designs, die Interruptgesteuert sind.

54 Institut MD Universität Rostock Entwurf von Echtzeitsystemen & Zyklische Exekutive (noch einmal)

55 Institut MD Universität Rostock Rate-Monotonic Systeme Rangmonoton (Rang=Priorität), Ratenmonoton (Rate=Periode) Liu/Layland 1973 Periodische Prozesse Periodische Prozesse erhalten entsprechend Ihrer Periode eine Priorität zugewiesen: –Kleine Periode große Priorität Wenn die Auslastung des Gesamtsystems bei einer ratenmonotonen Prioritätenzuweisung < 69 % ist, dann halten alle Prozesse ihre Deadlines ein. –vorausgesetzt die Periode ist gleich der Deadline. Es gibt noch weitere Voraussetzungen (kommt später dran)

56 Institut MD Universität Rostock Die Entwicklung harter Echtzeit Drei Stufen der Entwicklung harter Echtzeit –von der einfache zyklische Exekutive –... über major/minor zyklischen Scheduling –... zum pre-emptiven RTOS Scheduling –dynamisches Scheduling (Forschungsgegenstand)

57 Institut MD Universität Rostock void main (void) { init(); while (TRUE) { task_1(); task_2(); task_3(); task_4(); busy_wait_cycle(); } Freie Zeit Interruptzeit Einfache zyklische Exekutive

58 Institut MD Universität Rostock ZE Einfach –Worst-Case-Verhalten leicht zu bestimmen –Leicht zu implementieren Aber nicht sehr effizient –Worst Case Verhalten leicht abzuschätzen –Sporadische Ereignisse können nur umständlich behandelt werden (Polling mit hoher Rate)

59 Institut MD Universität Rostock Major / Minor Cycle Häufige Terminologie, die in periodischen Systemen und in zyklischer Exekutive verwendet wird. In periodischen Systemen und in zyklischer Exekutive wiederholt sich die Ausführungsreihenfolge der Tasks nach einer bestimmten Periode. Diese Periode wird als Major Cycle (Hauptzyklus) bezeichnet. Falls sich innerhalb des Hauptzyklus kleinere Sequenzen wiederholen, werden diese als Minor Cycle (innerer Zyklus) bezeichnet.

60 Institut MD Universität Rostock void main (void) { init(); while (TRUE) { task_1();/**/ task_2(); /**/ busy_wait_minor(); task_1(); /**/ task_3(); /**/ task_4(); /**/ busy_wait_minor(); task_1(); /**/ task_2(); /**/ busy_wait_minor(); task_1(); /**/ busy_wait_minor(); } 0123 Interruptzeit Freie Zeit ZE mit Minor und Major-Zyklus

61 Institut MD Universität Rostock ZE mit Minor und Major-Zyklus Einfach –Worst-Case-Verhalten bleibt leicht bestimmbar –Effizienter als einfache zyklische Exekutive Aber nicht sehr effizient –Behandlung sporadische Ereignisse und Interrupts schwierig –Zielt auf die Verwendung harmonische Frequenzen kompliziertes Arbeiten –erfordert die Aufsplittung des Programm-Codes in Teilabschnitte

62 Institut MD Universität Rostock Pre-emptives Multitasking RTOS-Scheduling

63 Institut MD Universität Rostock Pre-emptives Multitasking RTOS-Scheduling Effiziente Verwendung der verfügbaren CPU-Zeit –nicht nur harmonische Frequenzen –schnelle und effiziente Behandlung sporadischer Ereignisse Leichte Entwicklung von Anwendungscode –es ist nicht notwendig, den Code in Teilcodeabschnitte zu zerteilen und auch der Kommunikationsaufwand zwischen diesen Teilen mittels globaler Variablen

64 Institut MD Universität Rostock... aber Das wirkliche Echtzeitverhalten muß bestimmbar sein Der Overhead eines RTOS muß klein sein RTOS muß fehlerfrei sein –Wenn ein RTOS Designfehler enthält, dann kann das Gesamtsystem nicht die Anforderungen an die Zuverlässigkeit erfüllen Systemverhalten zur Entwurfszeit untersuchen

65 Institut MD Universität Rostock Unterteilung in Tasks / Prozesse Multi-Tasking in einem Datenverarbeitungssystem Wait for I/O Event Event in DB eintragen Auf Kdo. warten DB DB durch- suchen Daten anzeigen AD-Wandler

66 Institut MD Universität Rostock Datenverarbeitungssystem ServiceOperator() { while(TRUE){ WaitForCmd(); SearchDatabase(); } Update TimeOnDisplay() { while(TRUE){ WaitOneSecond(); DisplayTime(); } HandleQueuedEvents() { while(TRUE){ WaitForEvent(); EnterEventInDatabase(); }

67 Institut MD Universität Rostock Was ist preemptives Scheduling Die Task mit der höchsten Priorität erhält die CPU Wenn eine höher priorisierte Task bereit wird, wird die aktuelle Task verdrängt (preempted) und die höher priorisierte Task erhält die Steuerung (CPU) Ein preemptiver Kern wird verwendet, wenn Reaktionszeit wichtig ist Wird in den meisten kommerziellen Betriebssystemen verwendet READY RUNNING ASLEEP À Á Â Ã

68 Institut MD Universität Rostock Vereinfachtes Prozeßmodell: Zustandsmodell eines Prozesses READY RUNNING ASLEEP À Á

69 Institut MD Universität Rostock Multitasking

70 Institut MD Universität Rostock C=1, T=4, U=0,25 C=1, T=5, U=0,2 C=8, T=20, U=0,4 A B


Herunterladen ppt "Institut für Angewandte Mikroelektronik und Datentechnik Fachbereich Elektrotechnik und Informationstechnik, Universität Rostock Vorlesung Echtzeitbetriebssysteme."

Ähnliche Präsentationen


Google-Anzeigen