RTAI und Hasenhorn: Unterschied zwischen den Seiten
(Unterschied zwischen Seiten)
Inhalt gelöscht Inhalt hinzugefügt
Keine Bearbeitungszusammenfassung |
AZ: Die Seite wurde neu angelegt. |
||
| Zeile 1: | Zeile 1: | ||
==Lage== |
|||
'''RTAI''' (Real Time Application Interface) ist eine Erweiterung von [[Linux]] zu einem [[Echtzeitbetriebssystem]]. |
|||
Das '''Hasenhorn''' ist ein Berg von 1058 m Höhe im [[Südschwarzwald]]. Der Berg liegt direkt bei der kleinen Stadt [[Todtnau]] (Nächste größere Städte: [[Lörrach]] und [[Freiburg]]). |
|||
Begründet wurde RTAI von Prof. Paolo Mantegazza vom ''Dipartimento di Ingegneria Aerospaziale'' der [[Politecnico di Milano|Technischen Universität Mailand]]. RTAI wurde vom Beginn an als Open-Source-Projekt von einer größeren Entwicklergemeinde weiterentwickelt, wobei heute neben dem weiterhin koordinierend tätigen Prof. Mantegazza vor allem Philippe Gerum als sehr |
|||
aktiver Mitarbeiter zu nennen ist. |
|||
Es gibt inzwischen auch eine Reihe diverser verwandter oder kooperierender Projekte, wie zum Beispiel [[RTnet]] (ein Echtzeit-Netzwerk-Protokoll) und [[Linux Trace Toolkit]]. |
|||
==Geschichte== |
|||
Ein großer Pluspunkt von RTAI ist, dass es mit der Variante [[LXRT]] möglich ist, Hard-Realtime-Tasks im [[Userspace]] laufen zu lassen und damit die Schutzmechanismen von Linux zu nutzen. Dies erfolgt ohne größere Einbußen im Bereich der [[Latenz]]zeiten und ohne großen [[Overhead]]. Bei anderen Echtzeit-Systemen, welche ausschließlich im [[Kernelspace]] laufen, kann sich ein Fehler im Programmablauf verheerend auswirken. |
|||
Im Jahr 2004 wurde die bereits am Hasenhorn vorhandene Einer-Sesselbahn entfernt und durch eine moderne Doppel-Sesselbahn der Firma Doppelmayr ersetzt. Zugleich wurde am Hasenhorn die bislang längste '''Allwetterrodelbahn''' (Coasterbahn) Deutschlands errichtet. Hersteller dieser Bahn ist die Firma '''Wiegand'''. Besitzer sowohl des Liftes als auch der Coasterbahn ist der Investor '''Adolf Braun''', dem unter anderem auch der [[Steinwasen-Park]] gehört. |
|||
==Daten zum Lift== |
|||
RTAI wird von einer großen Zahl von Entwicklern in vielen Ländern als Basis für ihre Entwicklungen im Realtime-Bereich verwendet, hat aber ebenso wie [[RTLinux]] naturgemäß für den Standard-Büro-Desktop-Computer-Anwender keine direkte Bedeutung. |
|||
Der Doppelsessellift verfügt über '''89 Sessel''', kann also maximal 178 Personen fassen. Die Fahrt von der Talstation (direkt am Ort Todtnau) zur Bergstation (1026 m ü. NN) dauert 13 Minuten, die maximale Förderleistung beträgt also 410 Personen pro Stunde (Bergfahrten) Die reguläre Fahrtgeschwindigkeit beträgt 1,2 m/s. Jweils zwischen zwei Sesseln ist ein '''Lastengehänge''' angebracht, an dem neben den Rodeln der Allwetterrodelbahn Mountainbikes (Downhill-Bikepark am Hasenhorn) sowie sonstige Lasten transportiert werden können (Rucksäcke, Gleitschirme, Kinderwagen etc). |
|||
==Daten zur Rodelbahn== |
|||
== Architektur == |
|||
Die Coasterbahn ist 2,9 km lang. Die ca. 80 kg schweren Schlitten sind fest mit den Edelstahlschienen verbunden, ein Herausfallen ist also nicht möglich. Die Geschwindigkeit kann der Fahrer selbst regulieren, maximal sind ca 40 km/h möglich, anschließend bremsen die integrierten Fliehkraftbremsen den Schlitten automatisch ab. |
|||
Die Grundlange von RTAI-Linux ist ein normaler Linux-Kernel, der mit dem RTAI-Patch (Realtime Application Interface) erweitert wird. Wie in der Abbildung zu sehen ist, fügt der Patch einen Echtzeit-Kernel zwischen der Hardware (Prozessor) und dem Linux-Kernel ein. Dieser übernimmt die Interruptverwaltung des Prozessors. Das heisst Software auf der Kernel-Ebene kann keine Interrupts mehr blockieren oder freigeben. Die dafür verwendeten Befehle cli() und sti() ersetzt RTAI durch Makros und ist somit in der Lage den Kernel-Code zu unterbrechen. |
|||
==Bilder== |
|||
[[Bild:http://www.hausbergquell.de/Bilder/Schatten/Coaster1gr.jpg]] |
|||
[[Bild:Architekturrtai.jpg|500px|RTAI-Architektur]] |
|||
[[Bild:http://www.freiburg-schwarzwald.de/fotos06maerz/hasenhorn3-060320.jpg]] |
|||
Der Linux-Kernel selbst ist ebenfalls ein Echtzeit-Task. Er besitzt jedoch die kleinste Priorität (Idle-Task) und wird immer nur dann ausgeführt, wenn die Echtzeit-Tasks nichts zu tun haben. Nach dem Ausführen eines Echtzeit-Tasks werden alle Register wiederhergestellt, so dass der Kernel die Unterbrechung nicht bemerkt. |
|||
== Realtime Hardware Abstraction Layer RTHAL == |
|||
Damit deterministische Interrupt-Latenzzeiten erzielt werden können, muss die Interruptverwaltung an RTAI übergeben werden. Die Umleitung der Interrupt-Kontrolle wird mit Hilfe des Realtime Hardware Abstraction Layers (RTHAL) realisiert. RTHAL wird mit dem RTAI-Patch in den Source-Code des Linux-Kernels integriert. |
|||
In der folgenden Abbildung sind die möglichen Kommunikationswege innerhalb eines modifizierten Kernels dargestellt. Im Fall A ist die Abstraktion transparent, dass heisst die Interrupt-Kontrolle liegt nach wie vor beim Linux-Kernel, was der Nutzung eines Standard-Kernels entspricht. Bei B wird dem Linux-Kernel die direkte Kontrolle über die Interrupts entzogen und der Echtzeiterweiterung zugewiesen. |
|||
[[Bild:RTHAL.jpg|250px|RTAI-Architektur]] |
|||
RTAI arbeitet autonom von Linux auf der Hardware. Abgefangene Interrupts werden auch an RTHAL weitergegeben, damit der Kernel darauf entsprechend reagieren kann. RTAI wird durch verschiedene Kernel-Module implementiert. Solange diese Module nicht geladen sind, behält der Linux-Kernel die Interrupt-Kontrolle (Fall A). Erst beim Laden der RTAI-Module wird die direkte Interrupt-Kontrolle an RTAI übertragen (Fall B). So kann die Echtzeiterweiterung während der Laufzeit nach Belieben in den Kernel eingefügt und wieder entfernt werden. Dank dieser modularen Struktur lassen sich Fehlerquellen leichter isolieren. Arbeitet z.B. ein RTAI-System fehlerhaft, kann man einfach die RTAI-Module entfernen, um zu Testen, ob der Fehler bei Linux oder RTAI liegt. |
|||
RTHAL besteht im Wesentlichen aus einer Struktur von Funktionspointern, welche beim Systemstart auf die Interrupt-Handling-Funktionen des Linux-Kernels zeigen. Beim Laden der RTAI-Module werden die Funktionspointer auf RTAI interne Funktionen umgelenkt. So übernimmt RTAI die Interrupt-Kontrolle, ohne dass der Linux-Kernel etwas davon bemerkt. Nach dem Entfernen der RTAI-Module zeigen die Pointer der Struktur rthal wieder auf die Standard-Kernel-Funktionen. |
|||
== Interrupt-Handling == |
|||
Wenn RTAI die Interrupt-Kontrolle übernimmt, werden interruptspezifische Funktionsaufrufe des Linux-Kernels mit Hilfe von RTHAL an RTAI interne Funktionen umgeleitet. So implementiert RTAI z.B. einen Ersatz für das Funktionspaar <code>sti()</code> und <code>cli()</code>. Diese RTAI-Funktionen setzen Flags in RTAI internen Datenstrukturen, um festzuhalten, ob Linux über eingehende Interrupts informiert werden möchte (<code>sti</code>) oder nicht (<code>cli</code>). So wird sichergestellt, dass der Kernel keine Interrupts mit Hilfe der Funktion <code>cli()</code> deaktivieren kann. RTAI gibt die mit der Funktion <code>sti()</code> angeforderten Interrupts nach dem Ausführen der Echtzeit-Interrupt-Handler an den Linux-Kernel weiter. |
|||
In der folgenden Abbildung wird mit Hilfe eines Flussdiagramms dargestellt, wie ein eingehender Interrupt von RTAI verarbeitet wird. Zuerst prüft der RTAI Dispatcher, ob eine Echtzeit-Applikation einen Handler für diesen Interrupt registriert hat. Falls entsprechende Interrupt-Handler vorhanden sind werden diese ausgeführt. |
|||
[[Bild:Rtaiinterrupts.jpg|500px|Interrupt-Handling]] |
|||
Danach prüft RTAI anhand der internen Datenstrukturen, ob der Linux-Kernel den Interrupt ebenfalls mit sti() aktiviert hat. Bei einem positiven Prüfergebnis wird der Linux Dispatecher gestartet und somit die Verarbeitung des Interrupts auf der Kernel-Ebene eingeleitet. Falls der Linux-Kernel den betreffenden Interrupt nicht aktiviert hat, verlässt RTAI sofort den Interrupt-Kontext und führt das unter-brochene Programm wieder aus. |
|||
== Scheduler == |
|||
RTAI unterstützt drei verschiedene Scheduling-Varianten. Diese sind entweder für den Einsatz auf Uni- oder auf Multiprozessor-Systemen spezialisiert. Alle Scheduler können sowohl im so genannten Oneshot- oder Periodic-Mode betrieben werden. Die verschiedenen Scheduler werden in den Modulen <code>rtai_sched_up.ko</code>, <code>rtai_sched_smp.ko</code> und <code>rtai_sched_mup.ko</code> implementiert. Das entsprechende Scheduler-Modul wird jeweils nach dem RTAI-Modul rtai_hal.ko mit insmod in den Kernel eingefügt. |
|||
=== Uni-Prozessor-Scheduler (UP) === |
|||
Dieser Scheduler ist für Plattformen mit einem Prozessor vorgesehen, welche den 8254 als Timer benut-zen. Der Aufbau des Schedulers ist recht einfach. Er besteht im Wesentlichen aus mehreren Listen mit verschiedenen Prioritäten, welche er linear abarbeitet. Dabei erhält jeweils der Task mit der höchsten Priorität Zugriff auf die CPU. Der Linux-Kernel selbst ist ebenfalls ein Echtzeit-Task, allerdings mit der geringsten Priorität. |
|||
=== SMP-Scheduler (SMP) === |
|||
Der SMP-Scheduler (Symetric Multiprocessing) ist für Multiprozessor-Systeme gedacht, die entweder 8254 oder APIC basiert sind. Der APIC ist der so genannte Advanced Programmable Interrupt Controller in Multiprozessor-Systemen. Dieser hat unter anderem die Aufgabe, die auftretenden Interrupts den einzelnen CPUs zuzuteilen. Tasks können an eine CPU gebunden werden oder symmetrisch auf einen Cluster von CPUs laufen. Der Scheduler kann auch auf Systemen eingesetzt werden, die nur einen Prozessor haben, aber deren Kernel mit SMP-Option kompiliert wurde. |
|||
=== Multi-Uni-Prozessor-Scheduler (MUP) === |
|||
Wie es der Name schon sagt, sieht dieser Scheduler ein Multiprozessor-System als eine Ansammlung von mehreren Einzelprozessoren. Dies hat den Vorteil, dass im Gegensatz zum SMP-Scheduler jeder Prozessor seine Timer unabhängig von den anderen programmieren kann. Also können die Timer-Modi Periodic- und Oneshot-Mode abhängig von der CPU verschieden sein. |
|||
== Timer == |
|||
Die Ausführung von Echtzeit-Tasks in RTAI ist timergesteuert. RTAI bietet die Wahl zwischen den beiden Timer-Modi Periodic- und Oneshot-Mode. Periodisch bedeutet, dass der Timer in regelmäßigen Intervallen ein Interrupt auslöst, der ein Rescheduling veranlasst. Im Gegensatz dazu steht das Oneshot-Verfahren. Hierbei wird der Timer so programmiert, dass er nach einer festgelegten Zeitspanne genau einen Interrupt auslöst, der den Scheduler aufruft. Für die Generierung eines weiteren Interrupts muss der Timer neu programmiert werden, was einen grösseren Aufwand bedeutet, als beim periodischen Verfahren. Jedoch sind so auch unterschiedlich lange Intervalle möglich, nach denen ein Rescheduling erfolgen kann. |
|||
Bei der Initialisierung des Programms muss ein Modus gewählt werden. Dies geschieht indem eine der beiden folgenden Funktionen aufruft: |
|||
* <code>rt_set_periodic_mode()</code> Timer läuft im Periodic-Mode. |
|||
* <code>rt_set_oneshot_mode()</code> Timer läuft im Oneshot-Mode. |
|||
== Intertask-Kommunikation == |
|||
Für die Kommunikation und Synchronisation zwischen Echtzeit-Tasks im Kernel-Space stellt RTAI die für ein Echtzeitbetriebsystem üblichen Mechanismen zur Verfügung. Diese werden in den Kernel-Modulen der Scheduler implementiert: |
|||
* Mailboxen |
|||
* Semaphoren |
|||
* Nachrichten und Remote-Procedure-Calls |
|||
=== Mailboxen === |
|||
Mit Hilfe von Mailboxen ist eine asynchrone Inter-Prozess-Kommunikation möglich. Ein Task kann Nachrichten asynchron an die Mailbox eines anderen Tasks senden. Wenn der Empfänger bereit ist die empfangenen Nachrichten zu bearbeiten kann er sie aus der Mailbox holen. In diesem Fall arbeitet die Mailbox wie eine FIFO (first in first out), deren Funktionalität vollständig vom jeweiligen Task entkoppelt ist und keine Synchronisationsmechanismen benötigt. |
|||
Hier die wichtigsten RTAI-Funktionen zum Arbeiten mit Mailboxen: |
|||
* <code>rt_mbx_init()</code> Initialisiert eine Mailbox mit einer definierten Grösse. |
|||
* <code>rt_mbx_delete()</code> Löscht die von einer Mailbox genutzten Ressourcen. |
|||
* <code>rt_mbx_send()</code> Sendet eine Nachricht mit definierter Grösse an die Mailbox. |
|||
* <code>rt_mbx_receive()</code> Empfängt eine Nachricht mit definierter Grösse von einer Mailbox. |
|||
=== Semaphoren === |
|||
Eine Semaphore ist eine Art Schlüssel, den ein Task z.B. benötigt, um auf eine gemeinsame Ressource zuzugreifen. Wurde die Semaphore bereits von einem anderen Task geholt, wird der anfragende Task in den Wartezustand gesetzt, bis der aktuelle Besitzer die Semaphore wieder zurückgibt. Eine Semaphore beinhaltet eine geschützte Variable (binär oder counting), welche die noch freien Zugriffe auf eine Ressource angibt. In einer Queue werden die Tasks vermerkt, die auf die Semaphore warten. Wird die Semaphore zurückgegeben erhält sie der erste Task in der Queue. |
|||
Folgende Funktionen stehen zum Arbeiten mit Semaphoren in RTAI zur Verfügung: |
|||
* <code>rt_sem_init()</code> Initialisiert eine Semaphore mit gegebenem Wert. |
|||
* <code>rt_sem_delete()</code> Löscht die gegebene Semaphore. |
|||
* <code>rt_sem_signal()</code> Gibt die Semaphore zurück. |
|||
* <code>rt_sem_wait()</code> Wartet auf eine Semaphore. |
|||
== Kommunikation mit Linux-Prozessen == |
|||
RTAI stellt mit FIFOs und Shared Memory auch zwei Mechanismen zur Verfügung, die es den Echtzeit-Tasks ermöglicht mit normalen Linux-Prozessen im User-Space zu kommunizieren. |
|||
=== FIFOs === |
|||
Ein FIFO ist ein Puffer-Speicher, über den Daten zwischen einem RTAI-Task und einem normalen Linux-Prozess im User-Space ausgetauscht werden können. Theoretisch ist ein FIFO bidirektional. In der Praxis wird jedoch meistens nur eine Richtung benutzt. Zum gegenseitigen Austausch von Daten verwendet man zwei FIFOs, einen zum Senden von Befehlen und einen weiteren zum Empfangen der entsprechenden Antworten. |
|||
[[Bild:rtaififo.jpg|450px|RTAI FIFO]] |
|||
Linux-Prozesse können auf einen FIFO wie auf eine normale Datei zugreifen. Anstelle einer Datei öffnet man mit der Funktion <code>open()</code> einen speziellen Device-Node im <code>/dev</code>-Verzeichnis (<code>rtf0</code> bis <code>rtf63</code>). Anschliessend kann man mit den Funktionen <code>read()</code> und <code>write()</code> Daten lesen und schreiben. Im Kernel-Space stellt die RTAI-API folgende Funktionen zum Arbeiten mit FIFOs für die Echtzeit-Tasks zur Verfügung: |
|||
* rtf_create() Erzeugt einen FIFO mit gegebner Grösse und Nummer. |
|||
* rtf_destroy() Löscht einen FIFO. |
|||
* rtf_reset() Löscht den Inhalt eines FIFO. |
|||
* rtf_put() Schreibt Daten in den FIFO. |
|||
* rtf_get() Liest Daten aus dem FIFO. |
|||
* rtf_create_handler() Registriert einen Handler, der beim Eintreffen von Daten ausgeführt wird. |
|||
=== Shared Memory === |
|||
Shared Memory ist wie es der Name schon sagt, ein Speicherbereich, der sich Linux-Prozess und RTAI-Task teilen. Shared Memory wird hauptsächlich dann eingesetzt, wenn mehrere Linux-Prozesse Zugriff auf die Daten eines RTAI-Task benötigen oder eine grosse Datenmenge in kurzer Zeit von einem RTAI-Task an einen Linux-Prozess übertragen werden müssen. |
|||
== LXRT == |
|||
Um die Entwicklung von Echtzeit-Tasks zu erleichtern, wurde in RTAI das LXRT-Modul eingeführt. Dieses Modul erlaubt die Entwicklung von Echtzeit-Tasks im User-Space, mit der Möglichkeit, auf die API von RTAI zuzugreifen. |
|||
Dies ist eine Besonderheit, die nur in RTAI existiert und die Entwicklung sehr vereinfachen kann, da sich Fehler in einem User-Space Prozess in der Regel nicht auf die Stabilität des Gesamtsystems auswirken. Fehler in Kernel-Modulen können oft zum Absturz des gesamten Systems führen. Zudem kann man im User-Space im Gegensatz zum Kernel-Space mit einem normalen Debugger (z.B. GDB) arbeiten. |
|||
LXRT ist nur als Testwerkzeug gedacht und kann keine Echtzeiteigenschaften garantieren. Deshalb portiert man LXRT-Programme nach der Testphase in normale Kernel-Module. Da das LXRT-Modul die RTAI-API im User-Space zu Verfügung stellt, kann der Code des LXRT-Programms ohne grosse Änderungen für das Kernel-Modul übernommen werden. |
|||
== Weblinks == |
|||
*[http://www.rtai.org RTAI] (englisch) |
|||
*[http://www.captain.at RTAI Beispielprogramme] (englisch) |
|||
*[http://www.fdn.fr/~brouchou/rtai/rtai-doc-prj/ RTAI 3.0 Documentation page] (englisch) |
|||
*[http://rtai.dk RTAI-Wiki] (englisch) |
|||
*[http://www.rts.uni-hannover.de/rtnet/ RTnet] (englisch) |
|||
== Literatur == |
|||
*Yaghmour, Karim: The Real-Time Application Interface, 2001 [http://www.opersys.com/publications/rtai-ols-2001.pdf] |
|||
*Blattner, Jörg: Hart im nehmen? Linux in Echtzeit, Hochschule Zürich Winterthur 2005 [http://www.ictnet.ch/docs/articles/blattner_zhw.pdf] |
|||
*Abbott, Doug: Linux for Embedded and Real-time Applications, Burlington (USA) 2003, Elsevier Science, ISBN 0-7506-7546-2 |
|||
*Düding, Dirk: Ein Beitrag zum Einsatz von echtzeitfähigen Linux-Varianten in der Automatisie-rungstechnik, Dissertation, Dortmund 2003, Universität Dortmund [https://eldorado.uni-dortmund.de/bitstream/2003/2822/1/dueding2.pdf] |
|||
[[Kategorie:Echtzeitbetriebssystem]] |
|||
[[Kategorie:Linux]] |
|||
[[en:RTAI]] |
|||
[[fr:RTAI]] |
|||
[[ko:RTAI]] |
|||
Version vom 31. Dezember 2006, 13:54 Uhr
Lage
Das Hasenhorn ist ein Berg von 1058 m Höhe im Südschwarzwald. Der Berg liegt direkt bei der kleinen Stadt Todtnau (Nächste größere Städte: Lörrach und Freiburg).
Geschichte
Im Jahr 2004 wurde die bereits am Hasenhorn vorhandene Einer-Sesselbahn entfernt und durch eine moderne Doppel-Sesselbahn der Firma Doppelmayr ersetzt. Zugleich wurde am Hasenhorn die bislang längste Allwetterrodelbahn (Coasterbahn) Deutschlands errichtet. Hersteller dieser Bahn ist die Firma Wiegand. Besitzer sowohl des Liftes als auch der Coasterbahn ist der Investor Adolf Braun, dem unter anderem auch der Steinwasen-Park gehört.
Daten zum Lift
Der Doppelsessellift verfügt über 89 Sessel, kann also maximal 178 Personen fassen. Die Fahrt von der Talstation (direkt am Ort Todtnau) zur Bergstation (1026 m ü. NN) dauert 13 Minuten, die maximale Förderleistung beträgt also 410 Personen pro Stunde (Bergfahrten) Die reguläre Fahrtgeschwindigkeit beträgt 1,2 m/s. Jweils zwischen zwei Sesseln ist ein Lastengehänge angebracht, an dem neben den Rodeln der Allwetterrodelbahn Mountainbikes (Downhill-Bikepark am Hasenhorn) sowie sonstige Lasten transportiert werden können (Rucksäcke, Gleitschirme, Kinderwagen etc).
Daten zur Rodelbahn
Die Coasterbahn ist 2,9 km lang. Die ca. 80 kg schweren Schlitten sind fest mit den Edelstahlschienen verbunden, ein Herausfallen ist also nicht möglich. Die Geschwindigkeit kann der Fahrer selbst regulieren, maximal sind ca 40 km/h möglich, anschließend bremsen die integrierten Fliehkraftbremsen den Schlitten automatisch ab.
Bilder
Datei:Http://www.hausbergquell.de/Bilder/Schatten/Coaster1gr.jpg Datei:Http://www.freiburg-schwarzwald.de/fotos06maerz/hasenhorn3-060320.jpg
