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
Oliver hat recht, ja. Allerdings sind das dann RTOSse, die für einen Atmega zwei Nummern zu groß sind.
Da mich das Thema auch interessiert: http://www.amazon.de/MicroC-OS-II-Real-Time-complete-preemptive/dp/1578201039/ref=sr_1_2?ie=UTF8&qid=1321019098&sr=8-2 Kennt das Buch jemand? Ist das empfehlenswert? Oder ist das zu sehr auf das uCos zugeschnitten? Mir würde es mehr um Konzepte, Hintergründe gehen was man beachten muss. Oder hat da sonst jemand Literatur zu, welche geeignet ist?
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.
Schau dir mal das an: http://www.freertos.org/implementation/index.html da ist genau erklärt wie es funktioniert (beim AVR)
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.