RTEMS- Echtzeitbetriebssystem Name: Hussein Hammoud Matrikel- Nr.: 230768 Studiengang: Technische Informatik Fach: Projekt Eingebettete Kommunikation Technische Universität Berlin Sommersemester 2006
RTEMS- Echtzeitbetriebssystem 1) Allgemeines über RTEMS 2) Systemarchitektur von RTEMS 2.1) Manager -Modell 2.2) Kernel Features 2.3) Unterstützung offener Standards 3) Task-Modell 3.1) Tasks in RTEMS 3.2) Intertask Kommunikations- und Synchronisation- Mechanismen 3.3) RTEMS-Scheduler 3.4) Bibliotheksfunktionen aus der POSIX-API 4) Interrupt-Management 4.1) Bibliotheksfunktionen des Interrupt-Managers 5) Quellen
1) Allgemeines über RTEMS Real Time Executive for Multiprocessor Systems Ein Open-Source Echtzeitbetriebssystem; ursprünglich vom US-Militär unter dem Namen Real Time Executive for Missile Systems entwickelt Als Haupteinsatzbereiche gelten ressourcenarme tief eingebettete Systeme (Medizin, Militärtechnik) RTEMS wird kostenlos und royalty free lizenziert Unterstützung zahlreicher Plattformen: ARM, MC68K, PowerPC, Intel i386, Sparc, SH etc.
2) Systemarchitektur von RTEMS Anwender- Applikation Optionale Systemdienste (z.b. Netzwerk) Elementare Systemdienste (z.b. Scheduling) Abbildung 1: Systemarchitektur von RTEMS
2.1) Manager -Modell Hoch modularer Systemaufbau als Grundlage für den Einsatz in ressourcenarme tief eingebetteten Systemen Viele Systemkomponenten sind als separate Module, in RTEMS Manager genannt, verfügbar, die optional benutzt werden können: Network Support Manager, I/O-Manager, Timer Manager, Memory Pool Manager, Semaphore Manager etc. Eine typische RTEMS-Anwendung besteht aus der Anwender- Applikation, die nach dem Kompilieren zu den benötigten RTEMS-Manager gelinkt und anschließend an die Zielhardware übertragen wird
2.2) Kernel Features Der RTEMS- Kernel verfügt u.a. über folgende Features: Multitasking Unterstützung homogener / heterogener Multiprozessor- Systeme Ereignisbasiertes, prioritätsgesteuertes preemptives Scheduling Intertask Kommunikations- und Synchronisations- Mechanismen Prioritäts-Vererbung Dynamische Speicherallokation Hohe Konfigurierbarkeit Echtzeitgerechte Interrupt-Management
2.3) Unterstützung offener Standards RTEMS ist nicht zuletzt für die Unterstützung offener Standards weit verbreitet. Die Portabilität von Anwendungen wird insbesondere durch folgende unterstützte Standards erhöht: POSIX 1003.1b API inkl. Threads RTEID -API (Real-Time Executive Interface Definition) ORKID-API (Open Real-Time Kernel Interface Definition) TCP/IP-Stack uitron 3.0 API (Micro Industrial The Real-time Operating System Nucleus ) GNU-Toolset
3.1) Tasks in RTEMS In RTEMS gibt es genau einen Prozess, der aus mehreren Tasks bestehen kann Tasks in der Terminologie von RTEMS ähneln den aus der Unix-Welt bekannten Threads Tasks stellen also die kleinsten Ausführungseinheiten dar, die um Systemressourcen wie etwa die Rechenzeit konkurrieren können Alle Tasks in einem RTEMS-System teilen sich den gleichen Adressraum (kein Speicherschutz!) Ein Task befindet sich immer in einem der folgenden Zustände: executing (rechnend), ready (rechenbereit), blocked (blockiert), dormant (ruhend), and non-existent (nichtexistierend).
3.1) Tasks in RTEMS Abbildung 2: Übergänge zwischen den einzelnen Task- Zuständen
3.2) Intertask Kommunikations- und Synchronisation- Mechanismen Für zusammen kooperierende Tasks stellt RTEMS folgende Kommunikations- und Synchronisations-Mechanismen bereit: Semaphore Message Queue Event Signal
3.3) RTEMS-Scheduler Der Scheduler hat die Aufgabe die wertvolle Ressource Rechenzeit so auf die rechenbereiten Tasks zu verteilen, dass diese alle ihre Reaktionszeiten einhalten. Die Zuteilung der Rechenzeit erfolgt nach einem preemptiven prioritätsgesteuerten Algorithmus. Bei mehreren Tasks mit gleicher Priorität wird die Rechenzeit nach der Round-Robin- Strategie zugeteilt. Dadurch ist gewährleistet, dass stets der Task mit der höchsten Priorität die Rechenzeit erhält.
3.4) Bibliotheksfunktionen aus der POSIX-API Nachfolgend einige Funktionen der POSIX-API für Threads: // Starten eines Threads int pthread_create( pthread_t *thread, //für die Thread-ID const pthread_attr_t *attr, // Thread-Attribute(z.B. Stackgröße) void (*start_routine)( void *), // Thread-Startadresse void *arg // Parameter der Startroutine ); // Beenden eines Threads void pthread_exit( void *status); // status: Rückgabewert der Startroutine // Warten auf das Ende eines Threads int pthread_join( pthread_t thread, // Thread, auf dessen Ende gewartet wird void **value_ptr // Rückgabewert des Threads );
RTEMS unterstützt intern 256 Interrupt-Prioritätsklassen, die in Abhängigkeit der verwendeten Hardwareplattform eventuell nicht immer definiert sind 4) Interrupt-Management Die echtzeitgerechte Interrupt-Management wird vom Interrupt- Manager gewährleistet Der Interrupt-Manager erlaubt die Anbindung benutzerdefinierter Funktionen an Hardware-Interrupt-Vektoren Der Interrupt-Manager garantiert minimale Interrupt Latenzzeiten unabhängig von der Zielhardware Die Verarbeitung eines externen Ereignisses erfolgt in einer vorgesehenen Benutzer-ISR Der Interrupt-Manager garantiert geeignetes Verhalten hinsichtlich Scheduling und dispatching beim Verlassen einer ISR
4.1) Bibliotheksfunktionen des Interrupt-Managers Nachfolgend einige Bibliotheks-Funktionen des Interrupt-Managers: // Defnition eigener ISR rtems_isr user_isr( rtems_vector_number vector // Interrupt-Vektor-Nummer ); // Installieren von ISR's rtems_status_code rtems_interrupt_catch( rtems_isr_entry new_isr_handler, // Einsprungadresse der ISR rtems_vector_number vector, // Interrupt-Vektor-Nummer rtems_isr_entry *old_isr_handler // Adresse der zuletzt installierten ISR ); // Sperren von Interrupts: Alle maskierbaren Interrupts werden gesperrt void rtems_interrupt_disable( rtems_interrupt_level level // Zustands-Zwischenspeicherung ); // Interrupts enablen : Zustand vor dem letzten Sperren wiederherstellen void rtems_interrupt_enable( rtems_interrupt_level level // Vorzustand );
5) Quellen http://www.rtems.com http://www.sakamura-lab.org http://www.wikipedia.de