Hallo,
ich möchte mich mit dem Thema Betriebssystem (auf eingebetteten
Systemen) etwas näher beschäftigen, aber irgendwie möchte mir der
Einstieg nicht gelingen. Ich hab schon x-mal gelesen was so ein
Betriebssystem macht, was für tolle Sachen man damit machen - ich kanns
schon fast auswendig runterbeten, aber verstanden hab ichs noch nicht...
vor allem WIE macht es bestimmte Sachen (Scheduling etc.)
Ich muss wohl son Teil selbst auf einem Mikrocontroller zum laufen
bringen und damit rumspielen um es zu verstehen.
Ich hoffe das alle RTOS im Grunde gleich funktionieren und es ausreicht
einmal die Funktionsweise die dahinter steckt zu verstehen.
Lange Rede kurzer Sinn:
Mit welchem OS kann ich das am besten? Am liebsten wäre mir was für
AtMega Prozessoren & AVR Studio, da ich damit schon viel gearbeitet
habe.
Grundlage eines RTOS ist üblicherweise ein sogenannter Scheduler, ein
Mechanismus, der Rechenzeit an Prozesse verteilt und die Umschaltung
zwischen Prozessen "Context switching" regelt.
Natürlich kann ein RTOS auch weitergehende Funktionalität behandeln, so
wie die Netzwerkunterstützung im FreeRTOS zum Beispiel.
Übrigens, ein RTOS wird mit dem Anwendungsprogramm zusammen gelinkt, man
kann nicht wie bei einem echten OS die Applikation austauschen, ohne das
System neu zu übersetzen.
Sebastian schrieb:> Übrigens, ein RTOS wird mit dem Anwendungsprogramm zusammen gelinkt
Das ist so pauschal nicht richtig. Selbstverständlich gibt es auch
RTOSse (VxWorks, QNX, Real time linux, ...), die nicht mit der Anwendung
zusammengelinkt werden.
Oliver
Sebastian schrieb:> Grundlage eines RTOS ist üblicherweise ein sogenannter Scheduler, ein> Mechanismus, der Rechenzeit an Prozesse verteilt und die Umschaltung> zwischen Prozessen "Context switching" regelt.
danke für die Erklärung, aber davon rede ich ja: Ich kann das alles
schon runterbeten, aber ich würde das ganze mal gern in Aktion "sehen"
um zu verstehen wie das nun wirklich abläuft in µC
Ist dieses "AvrX" (http://www.barello.net/) geeignet als Einstieg in das
Thema?
Anfänger schrieb:> Ist dieses "AvrX" (http://www.barello.net/) geeignet als Einstieg in das> Thema?
Kommt drauf an worum es geht. Es ist geeignet für Aufgaben mit wenig
Speicher. Aber um einen Durchblick zu gewinnen ist es - weil in
Assembler implementiert - nicht optimal.
Das kommt, dass es seit langer Zeit nicht gepflegt wird und sich im
Bereich Debug-Konsole per UART Probleme mit Controllern jenseits der
Mega8/16/32-Klasse ergeben können.
Anfänger schrieb:> danke für die Erklärung, aber davon rede ich ja: Ich kann das alles> schon runterbeten, aber ich würde das ganze mal gern in Aktion "sehen"> um zu verstehen wie das nun wirklich abläuft in µC
Im Prinzip:
Das OS kriegt alle heilige Zeiten die Kontrolle über einen Interrupt.
Interrupt ist wichtig, damit die Stelle an der ein Task unterbrochen
wurde dokumentiert ist. In diesem Fall dann eben als Returnadresse am
Stack.
Es speichert den aktuellen Zustand der CPU (für diesen Task)
in einer Datenstruktur
Aus derselben Datenstruktur wird der gespeicherte Zustand eines
anderen Tasks geholt, das System in diesen Zustand gebracht
und ein Return ausgefühjrt
Das alles ist mit heftigen Manipulationen am Stack verbunden, ist also
rein in C nicht machbar. Da muss man auf Assembler runtergreifen um die
Stackmanipulationen zu machen.
D.h. tief im Kern gibt es in jedem derartigen Betriebssystem einen
Schedulerkern, der zumindest zum Teil in Assembler implementiert ist.
Aber im Prinzip geht es darum, dass aus einem Interrupt der Return an
eine andere Stelle zurück erfolgt als der, die durch den Interrupt
unterbrochen wurde.
Allerdings ist Scheduling nur ein kleiner Teil eines OS (wenn auch der
spektakulärste). Da gibt es viel interessantere Probleme.
ISBN: 978-0136006633
Andrew S. Tanenbaum : "Modern Operating Systems".
Steht alles drinn was man wissen muss. Zwar nicht speziell auf Embedded
abgestimmt aber sicher DAS Standardwerk in Sachen OS internas.
cyblord schrieb:> ISBN: 978-0136006633> Andrew S. Tanenbaum : "Modern Operating Systems".> Steht alles drinn was man wissen muss. Zwar nicht speziell auf Embedded> abgestimmt aber sicher DAS Standardwerk in Sachen OS internas.
und schon hab ich es aus der Bibliothek ausgeliehen :-)
Danke für die Antworten bisher, ich werd mir diese FreeRTOS mal angucken
Ein RTOS schaltet mittels Timerinterrupt zwischen den einzelnen Tasks
um.
Dazu muß es den CPU Status einer Task komplett sichern und die Sicherung
der nächsten Task restaurieren.
Damit das klappt, hat jede Task ihren eigenen Speicher für Variablen und
Stack und CPU-Status Sicherung.
Hat der MC z.B. 1kB SRAM und man will 10 Tasks ausführen, dann kann jede
Task nur max 65Byte (1024 / 10 - 32Register - SREG - SP - PC) an SRAM
benutzen.
Das Umschalten kostet natürlich auch CPU-Zeit.
Zusätzlich können die Tasks nicht einfach über globale Variablen oder
Aufrufparameter Daten austauschen. Durch die jederzeitige Unterbrechung
währen die Daten unweigerlich inkonsistent.
Auch dürfen 2 Tasks nicht gegenseitig auf Daten der anderen warten
(Deadlock).
Daten können nur über spezielle OS-Funktionen (Semaphoren) übergeben
werden.
Man hat also einen ziemlich prallen Rucksack an Nachteilen und
Umständlichkeiten, um genau einen Vorteil zu erzielen.
Der Vorteil ist, man kann blockierende Tasks programmieren, die ewig auf
irgendwas warten.
Der Vorteil macht sich daher erst dann bezahlt, wenn man sehr viele
Tasks ausführen muß, die sogar von verschiedenen Leuten programmiert
wurden und man nicht mehr sicher sein kann, daß jede Task rücksichtsvoll
ist und keine Blockierungen enthält.
Peter
Hier wird ja anscheinend von präemptivem Multitasking ausgegangen. IMHO
ist aber kooperatives Multitasking für Embeddedanwendungen besser
(geringerer Overhead, geringere CPU-Last). Da man ja selbst alle
Prozesse schreibt und diese nicht austauschbar sind, sind hier schlecht
programmierte Anwendungen kein Thema (so wie es z.B. bei Win16 oder
MacOS Classic war).
Die Funktion eines einfachen RTOS wird hier beschrieben:
http://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Software
Peter Dannegger schrieb:> Ein RTOS schaltet mittels Timerinterrupt zwischen den einzelnen Tasks> um.
Auch, aber nicht nur. Dafür kommt jeder Interrupt in Frage.
Ich hab hier in der Codesammlung vor einiger Zeit ein
sehr kleines und primitives System fuer M16C veroeffentlicht.
Das sollte man eigentlich ganz gut lesen und verstehen koennen
weil es wirklich nur die Basisfunktionalitaet bietet.
Und wenn man will kann man natuerlich auch den Scheduler auf diese
rueckstaendigen AVRs umschreiben und wird danach wirklich gelernt haben
wie es funktioniert. :-)
Olaf
Noch eine (sehr wahrscheinlich blöde) Frage:
Wenn jemand einen APPLICATION für ein OS schreibt, programmiert der dann
sozusagen eine der TASKs die das OS dann gescheduled?
TASK(T1)
{
...
}
ich hab da dauernd dieses AUTOSAR-Schichtmodell Bild im Kopf wo diese
SWC's so schön abgetrennt im Application-Layer gezeichnet sind
daher frag ich mich: APPLICATION == TASK ?
Gruß
Anfänger
Anfänger schrieb:> Noch eine (sehr wahrscheinlich blöde) Frage:>> Wenn jemand einen APPLICATION für ein OS schreibt, programmiert der dann> sozusagen eine der TASKs die das OS dann gescheduled?> daher frag ich mich: APPLICATION == TASK ?
Grundsätzlich ja.
Das nennt man dann eigentlich Prozess. Das OS teilt jedem Prozess
Rechenzeit zu und das Programm wird auf der CPU ausgeführt. Nach Ablauf
der Rechenzeit wird das OS per Interrupt von der CPU geweckt, nimmt
einen Kontextwechsel vor, und lässt den nächsten Prozess laufen.
gruß cyblord
