Vorlesung Echtzeitbetriebssysteme III. Entwurf von Echtzeitsystemen

1. VorlesungEchtzeitbetriebssysteme III. Entwurf von Echtzeitsystemen Dr.-Ing. Frank Golatowski

2. Ziele der Vorlesung • Aufzeigen, welche Möglichkeiten es gibt, ein Echtzeitsystem zu konstruieren. • Sowohl ohne Betriebssystem • als auch mit Betriebssystem

3. 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. Gliederung • Polling in einer Endlosschleife (Polled Loop Systems) • Phase/ State Driven Code • Coroutine • Interrupt Driven Systems • Foreground / Background Systems • RTOS

5. 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. Unendliche Pollingschleife Anwendung • Wenn ein einzelner Prozessor für die Behandlung wenigerschneller Geräte vorgesehen ist. • Wenn Ereignisse sich nicht überlappen bzw. wenn die Überlappung minimal ist oder minimal gehalten werden kann

7. 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. 9600-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. 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++; } } main() { for (;;){ CheckInputs(); CheckDigitalInterfaces(); Application(); } } <Existierender Code> <Aufgesplitteter Code>

9. 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. 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. Unendliche Pollingschleife mit Interrupt Schalterposition On Off Zeit 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

12. Unendliche Pollingschleife mit Interrupts • Beispiel Serial_ISR() { ReadCharFromPort(); PutCharIntoBuf(); if(CompleteLine){ SendBufToAppl(); GetNewBuf(); } } digital_ISR() { event = ReadDigitalInterface; time = ReadSystemClock; EnqueueEvent(event, time); } main() { for (;;){ ServiceOperator(); UpdateTimeOnDisplay(); HandleQueuedEvents(); } } 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. 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. 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. 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. Gliederung • Polling in einer Endlosschleife (Polled Loop Systems) • Phase/ State Driven Code • Coroutine • Interrupt Driven Systems • Foreground / Background Systems • RTOS

17. Phasen- und Zustandsgesteuerter Code • Verwendet verschachtelte • Statements • 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 If ... then case

18. 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. 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 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;} } } }

20. State machine specification in1=1/x=a A B r=0/out2=1 r=1/out1=0 in1=0/x=b C D s=0/out1=0 s=1/out1=1

21. 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. C state table while (TRUE) { switch (state) { case state1: ... } } C state machine structure 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;

23. Phasen- und zustandsgesteuerter CodeZusammenfassung • 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. Gliederung • Polling in einer Endlosschleife (Polled Loop Systems) • Phase/ State Driven Code • Coroutine • Interrupt Driven Systems • Foreground / Background Systems • RTOS

25. 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. Coroutine: Eigenschaften • Ähnlich wie Unterprogramm, jedoch bestimmt der aufrufende Programmabschnitt die Rücksprungadresse. • Coroutinen geben die Steuerung freiwillig ab. • Erfordert disziplinierte Programmierung

27. 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. Steuerfluß von zwei CoroutinenARM-Prozessor R15 ist Befehlszähler ADR r14,co2a co1a ADR r0, a LDR r1, [r0] ADD r1,#5 STR r1, [r0] ADR r13,c01b MOV r15,r14 co1b ADR r3, b LDR r4,[r3] BNE r4, #2 ADR r13,c01b MOV r15,r14 co1c . . . co2a ADR r3, w LDR r4, [r3] STR r4, r0 ADR r13,c02b MOV r15,r13 co2b ADR r3, x LDR r4,[r3] BNE r5, y STR r4, r5 ADR r13,c02c MOV r15,r13 co2c . . . R14 enthält die Rücksprung-adresse der Coroutine2 R13 von Coroutine1 Coroutine 1 Coroutine 2

29. 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. Zyklische Exekutive • Besteht nur aus einer Co-Routine

31. 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. 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. Kooperatives Multitasking • 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 einScheduler verwendet yield_CPU() cswitch

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

35. 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. Kooperatives MultitaskingZusammenfassung • Andere Begriffe: non-preemptive, round-robin • Windows 3.1, Windows 9x

37. Gliederung • Polling in einer Endlosschleife (Polled Loop Systems) • Phase/ State Driven Code • Coroutine • Interrupt Driven Systems • Foreground / Background Systems • RTOS

38. Interrupt gesteuerte Systeme • Interrupt-driven • MS/DOS, Mikrocontroller • Das Hauptprogramm ist eine Endlosschleife

39. 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. 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); } RTS besteht aus einem einfachen Main-Programm und drei Interrupthandlern, die den Context auf dem Stack speichern void int3(void) /* Inthandler 3 */ { save(context); task3(); restore(context); }

41. Preemptives Multitasking CPU TIMER • 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

42. Preemptives Multitasking 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

43. Gliederung • Polling in einer Endlosschleife (Polled Loop Systems) • Phase/ State Driven Code • Coroutine • Interrupt Driven Systems • Foreground / Background Systems • RTOS

44. Foreground/Background- Systeme 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); } • 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

45. 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. 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 BGCoroutine = komplizierter BG-Prozess • Nur interruptgesteuert = FG/BG System ohne BG

47. Background Processing 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 t= • Beispiel1: 6 / 0,15 = 40 • Beispiel2: 10 / 0,45 = 22,22

48. 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. 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 ... 0 2 4 6 8 10 12 14 16 18 20

50. 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 ... 0 2 4 6 8 10 12 14 16 18 20