Hallo, gibt es für einen AVR ein Echtzeitbetriebssystem? Es gäbe da z.B. Nut/OS kennt sich jemand damit aus oder gibt es noch andere Betriebssysteme für einen AVR Controller? gruß
Für was braucht man denn auf nem Microcontroller ein Betriebssystem? Ist das nicht unnötiger Overhead?
@Stoppel: Such mal im Forum nach RTOS. @Micha: 1,5KB für AvrX finde ich nicht wirklich schlimm. Dafür kann das Programm übersichtlicher werden, sofern man mit der nebenläufigen Arbeits/Denkweise von RTOS zurecht kommt.
>Für was braucht man denn auf nem Microcontroller ein Betriebssystem? >Ist das nicht unnötiger Overhead? Brauch ein Betriebssstem um später flexibler zu sein. Fals ich neue Funtionen haben will, füge ich einfach neu Tasks hinzu die dann vom Betriebssystem aufgerufen werden. gruß
Das kann man auch selber schreiben: eine Art Scheduler, der die Unterprogramme entsprechend aufruft und auswertet. Normal arbeitet eigentlich jedes etwas komplexere Programm auf die Weise.
Da gabs doch von PeDa mal so einen schönen Scheduler in der Code-Sammlung. Beitrag "Wartezeiten effektiv (Scheduler)"
> Das kann man auch selber schreiben: eine Art Scheduler, der die > Unterprogramme entsprechend aufruft und auswertet. Normal arbeitet > eigentlich jedes etwas komplexere Programm auf die Weise. Genau, das macht man am besten jedesmal selbst - wozu, genau das leistet ein Betriebssystem. Jedesmal das Rad neu erfinden, also Unterbrechungsbehandlung und -snychronisation, Kontextwechsel, Scheduler, Fadensynchronisation ... neu implementieren und erneut mit denselben Problemen kämpfen, mit denen sich auch der Betriebssystementwickler in den meisten Fällen befasst hat. Dabei machen die meisten Leute natürlich nochmal dieselben Fehler, was in vielen Fällen richtig böse ist: der Betriebssystementwickler weiß z.B. um die Problematik einer Unterbrechungssynchronisation, derjenige, der das jedes mal neu strickt, weil er das ja ach so viel besser kann, in der Regel nicht oder nur rudimentär. Man braucht sich über die Aussage, dass der größte Teil von Betriebssystemen Eigententwicklungen sind, nicht wundern, auch wenn sich das komisch anhört, aber wenn man die oben genannten Mechanismen implementiert, entwickelt man zumindest Teile eines Betriebssystems. Ciao, Fabian
Ich frage mich bei diesen Betriebsystemhabenwollern immer, wie komplex und dynamisch (im Sinne von ständigem Wechsel) die Aufgabe eines Mikrocontrollers sein soll, dass man ein Betriebssystem auf dem armen Kerl laufen lassen muß. Ein µC wird i.d.R. in eine Schaltung eingebaut, um immer das gleiche zu machen. Man kann die Funktionen, die so ein Betriebssystem zur Verfügung stellt ("Bildschirmtreiber", "Eingabeinterface" etc.) auch wunderbar in Bibliotheken packen und die dann zur Compile-Zeit dazuholen. So spart man sich unnötigen Ballast, der nur Resourcen frisst und den man für die aktuelle Anwendung gar nicht braucht. Sieht man ja auch an aktuellen "Betriebssystemen" von gewissen Herstellern aus Redmond: braucht man diesen Klickibunti-Kram wirklich? Ich nicht... Aber wer's haben will, soll damit glücklich werden.
Ein Echtzeitkernel ist kein Windows, sondern ein Hilfsmittel zur Organisation parallel ablaufender Vorgänge.
Ich würde mal sagen, wer noch kein RTOS auf nem µC benutzt hat, kann hier ganz schlecht mitreden. Die Vergleiche mit Windows oder anderen "Betriebssystemen" hinken nicht nur. Sie entbehren jeder Grundlage. Es geht hier um Realtime Operating Systems (RTOS), worunter allenfalls ein Windows CE fallen würde.. Ich arbeite schon lange mit Echtzeitbetriebssystemen und würde sie nie mehr missen wollen! Selber schreiben sehe ich auch als völlig sinnfrei an. Wenns nix kosten soll dann FreeRTOS oder ähnliches nehmen, im Job einfach das passende kaufen. Wozu das leben schwer machen, wenn man sich doch einfach nur auf die eigentliche Problemstellung / Applikation konzentrieren will!? Klar, wenn man mit nem Tiny nur 3 Taster abfragt und eine LED zum blinken bringt, braucht man sicher keines. Aber jedem größeren Projekt kann ich es nur empfehlen. Und die Footprints sowie die µC-"Belastung" durch das RTOS sind lang nicht so groß, wie manch einer denkt.
Nur mal als Frage.. der AVR kann ja keine Programme aus dem RAM ausführen. Wie will man dann sinnvoll etwas "dazuladen?".. Muss doch eh alles ausführbereit im Flash stehen. Gruß, Christian
> Wie will man dann sinnvoll etwas "dazuladen?"
Du hast eine völlig falsche Vorstellung von einem RTOS. Trenn dich vor
der Vorstellung die du von einem "Betriebssystem" hast. Ein RTOS
organisiert Programmabläufe, in Form von Prozessverwaltung und
-Synchronisation, Speicherverwaltung. Da werden keine Programme geladen,
gibt es keine Anwenderoberfläche, in einfacheren RTOS nicht einmal
irgendeine Form von Filesystem.
Fabian Scheler wrote: > Unterbrechungsbehandlung und -snychronisation, Kontextwechsel, > Scheduler, Fadensynchronisation ... neu implementieren und erneut mit > denselben Problemen kämpfen, mit denen sich auch der > Betriebssystementwickler in den meisten Fällen befasst hat. Ganz genau deshalb mag ich kein RTOS, weil es diese vielen genannten Probleme bereitet. Der Mensch ist ein Single-Task Denker und es fällt schwer, so zu programmieren, das in jedem Augenblick eine andere Task dazwischen hauen kann und einem die Variablen oder nur ein Byte davon unterm Hintern weg verändert und nur noch Mist rauskommt. Ich nehme da lieber meinen Scheduler, der genau wie die anderen Tasks in der Mainloop eingereit ist und für die ganzen Zeitvernichter-Tasks zuständig ist. Dann hat jede Task alle Variablen für den ganzen Taskkontext exklusiv und stabil und alles ist in Butter. Nur die Variablen der Interrupthandler muß man natürlich beachten (atomarer Zugriff, cli+sei). Peter
Mal kurz skizziert der Sinn eines RTOS: Man nehme eine typische Controller-Anwendung wie sie hier schon öfter auftauchte. Heizungssteuerung beispielsweise. So ein Ding hat dann vielleicht: - ein Benutzerinterface mit Tasten, LCD und irgendwelchen Menus, - diverse Sensoren für u.A. Temperatur, - die eigentlichen Steuerungsfunktion, - und Kommunikation mit anderen Controllern für Anzeige, Bedienung, Datenabruf, - und nicht zuletzt eine Überwachung ob das alles läuft und Sinn ergibt. Man kann das über die klassische Mainloop realisieren, das gibt dann entsprechend viele Statemachines. Man kann diese Abläufe aber auch in eigenständige Prozesse trennen, die dann ohne sichtbare Statemachine weitgehend "on oben nach unten" ablaufen. Ein Vorteil davon liegt im weit übersichtlicheren Programmablauf und weitgehend verzögerungsfreier Reaktion auf Eregnisse (Tasten). Ein Auswirkung ist, dass diese Prozesse sich an den unmöglichsten Stellen unterbrechen können und man dafür sorgen muss, dass dies nicht zu Problemen führt. Ein RTOS verwaltet solche Prozesse, liefert Mechanismen zur Kommunikation zwischen diesen Prozessen, wie Synchronisation, Puffer/Warteschlangen und stellt Software-Timer für regelmässige Abläufe oder einfache Wartezeiten zur Verfügung usw. Natürlich muss man sich an diese Programmiertechnik und insbesondere die verwendeten Konzepte auch erst einmal gewöhnen. So realisiert auf einem Mega32, mit AvrX. Kein dicker Hobel nötig.
PS: Suum cuique. Wer Mainloops bevorzugt mag gern dabei bleiben. Aber anders als PeDa fällt mir die Programmierung nebenläufiger Prozesse in separaten Prozessen nicht sonderlich schwer, finde ich sie naheliegender als die Verhackstückung von Abläufen wie sie für Mainloops typisch ist. Mag daran liegen, dass ich damit schon recht lange Erfahrung habe.
Wie ARM-Fan richtig bemerkt: wer einmal mit RTOS programmiert hat, will es nie mehr missen. Und ein Scheduler ist dafür kein Ersatz. MfG
Der Nachteil bei dem Statemachine-Ansatz ist: Alle Vorgänge müssen so kurz werden, dass das Gesamttiming nicht beeinträchtigt wird. Deshalb müssen manche Programme unnatürlich zerhackt werden, damit die Ablaufzeiten nicht zu lange werden. Ich habe ich z.B. ein Graphikdisplay angeschlossen (am SPI-Bus) und gebe darauf ein Bild aus. Das Ganze dauert 10ms. Entweder die 10ms sind akzeptabel oder ich muss die Ausgabe in mehrere Teile zerhacken. Bei einem RTOS hat der Task, der die Displayausgabe bedient, einfach eine niedrigere Priorität. Sobald wichtige Tasks anstehen, können die SOFORT ihre Arbeit erledigen. Probleme mit Variablen, die sich gegenseitig beeinflussen, habe ich noch nie gehabt. In einem RTOS werden Informationen typischerweise per Messages ausgetauscht. Das hat gegenüber "normalen" Variablen den Vorteil, dass der Empfänger automatisch informiert wird, dass neue Daten vorhanden sind. Ich würde jedem raten, ein RTOS wenigstrens mal auszuprobieren. Viele Grüße, Stefan
gibt es eigendlich auch eine Einfürung in RTOS oder irgendwelche Beispielprogramme wo einem das Prinzip und die Vorgehensweise beim programmieren erklärt wird?
Andreas Kaiser wrote: > Ein Vorteil davon liegt im weit übersichtlicheren Programmablauf und > weitgehend verzögerungsfreier Reaktion auf Eregnisse (Tasten). Mit Interrupts für I/O-Port-Änderung wird es noch "verzögerungsfreier". Wir sprechen doch wahrscheinlich immer noch von AVR's die ja teilweise nicht so üppig RAM und Flash haben... wie sieht es da mit der Platzbelegung durch das OS aus? "ARM"-Fan mag recht haben dass man so ein System nicht mehr missen will wenn man es mal benutzt hat, aber wie der Name vermuten lässt hat er wahrscheinlich weniger Platzprobleme. Wie viel "Programm" könnte ich denn z.B. noch auf einem Mega8 mit RTOS laufen lassen?
>...hat er wahrscheinlich weniger Platzprobleme ;-) Jein! ARM ist mein neues "Steckenpferd". Bisher habe ich jedoch jahrelang nen 8051er mit RTX51 von Keil gequält. Und der hat den Platz eben auch nicht üppig. Da ist man mit nem AVR unter Umständen sogar noch besser dran (Flash >64kB). Mega8 ist vielleicht wirklich etwas knapp. Der Footprint des Kernels ist in der Regel nur wenige kB. Jedoch hängt der RAM-Bedarf von der Anzahl der Tasks, Speicherpools, etc. ab. Knappes RAM ist kritischer zu sehen als zu kleiner Flash.
> Mit Interrupts für I/O-Port-Änderung wird es noch "verzögerungsfreier". Benutzerinteraktion in Interrupts? > Wie viel "Programm" könnte ich denn z.B. noch auf einem Mega8 mit RTOS > laufen lassen? Am Beispiel AvrX: Code: "About 700-1000 words of code space needed for all features." Daten: "The minimum context is the 32 registers, SREG and the PC, for a total of 35 bytes."
Hallo, kann mir jemand eine Antwort auf die Frage geben? >gibt es eigendlich auch eine Einfürung in RTOS oder irgendwelche >Beispielprogramme wo einem das Prinzip und die Vorgehensweise beim >programmieren erklärt wird? Danke
Vergiss das RTOS. Das ist ein Betriebssystem. Sowas geht nicht mit einem Flashcontroller. Allercode muss im Flash sein. Was aber geht ist ein zugelinkter Echtzeitkernel. Der hat dieselbe Funktionalitaet minus das Betriebssystem. Das heisst, es gibt keine Shell, keinen Loader. Es gibt Semaphoren, pipes, tasks, plus noch ein paar debugging features.
Ich verwende mit den AVR Controlern das MicroC/OS-II von Jean J. Labrosse (http://www.micrium.com). Mit einem ATMega32 (2K Ram) habe ich problemlos 5-6 Tasks am laufen. Das MicroOS läuft sehr stabil und ich möchte es nicht mehr missen.. :-) Gruß Roland
>Vergiss das RTOS. Das ist ein Betriebssystem. Sowas geht nicht mit einem >Flashcontroller. Allercode muss im Flash sein. Was aber geht ist ein >zugelinkter Echtzeitkernel. Hast du mal eine Definition von Betriebssystem oder Realtime-Betriebssystem? Denn im Vergleich zu allen anderen Meinungen stehst du mit der Behauptung recht alleine da. Und der zugelinkte Echtzeitkernel verteilt ja auch die Rechenzeit, kümmert sich (teilweise) um die Contextwechsel... Warum muss man denn immer alle Programme (Unterprogramme) dynamisch laden können, damit es ein Betriebssystem ist ?? Gast.
Ein Betriebssystem hat eine Shell, mit einen Commandprompt zB : c:\> Dort kan man Befehle eingeben, und Programme werden darauf geladen und ausgefuehrt. Ein Kernel wirkt in einem festen Umfeld. Alles wurde mal geladen und der Kernel verteilt nur noch die Rechenzeit. Wenn ein Kernel und ein Betriebssystem dasselbe waeren, wuerde es nicht zwei Bezeichnungen brauchen. Nein ?
nop(); wrote: > Ein Betriebssystem hat eine Shell, mit einen Commandprompt zB : Das ist schon deshalb falsch, weil Echtzeitbetriebssysteme spätestens in der Zielanwendung nur selten über einen solchen Prompt verfügen. Da heute RTOS-Anwendungen fast nie auf der Zielhardware entwickelt werden, ist ein Command-Prompt ohnehin nicht zwingend. Empfehlung: http://en.wikipedia.org/wiki/Real-time_operating_system Aufgabe eines Betriebssystems ist Kontrolle von Prozessen/Tasks und Resourcenverwaltung. Im Fall einfacher RTOS sind das beispielsweise , CPU(s), einer oder mehrere Speicher sowie Devices. Benutzerinteraktion kann Bestandteil eines Betriebssystems sein, muss es aber nicht. Begrifflich ist der Übergang von Betriebssystem zu Betriebssystemkern/Kernel fliessend und die Abgrenzung durchaus umstritten. Selbst bei Systemen wie Windows ist das nicht leicht auseinander zu halten, da dessen Kernel selbst aus etlichen getrennt geladenenen Komponenten besteht und die diversen Personalities (DOS, OS/2 1.x, NT, Posix) von unten gesehen Anwendung, von oben gesehen Kernel sind. In der Praxis wird in kleinen Systemen ohnehin nicht zwischen Betriebssystem und Betriebssystemkern unterschieden.
nop(); wrote: > Dort kan man Befehle eingeben, und Programme werden darauf geladen und > ausgefuehrt. Damit beschreibst du einen PC mit Betriebssystem, aber kein Betriebssystem. Wenn du einen PC spezialisiert, indem du aus einem Windows und einigen Platten ein NAS (Network Attached Storage) System bastelst, das aus Anwendersicht nur noch eine einfache Weboberfläche zur Konfiguration bietet, hätte es aus deiner Sicht kein Betriebssystem mehr. Ebenso Settop-Boxen, HD-Videorecoder, SAT_Receiver usw. Die Art wie eine Anwendung gestartet wird ist für den Begriff Betriebssystem irrelevant. Ob nun per Prompt, Startup-Folder, Shell-Script oder alles zusammengelinkt und direkt vom Startup-Code aufgerufen.
Hallo, könnt ihr mir einen Tip geben welches Betriebssystem ich für einen ATmega 128 nehmen soll? Danke
Ich habe die Definition von Betriebssystem in etwo so gelernt: Ein Betriebssystem besteht aus Programmen (Sequenzen von Anweisungen für den Prozessor, die direkt ausführbar sind) und Bibliotheken (Sequenzen von Anweisungen, die in Programmen genutzt werden können), die für Abarbeitung und Überwachung anderer Programme auf einem Rechner zuständig sind. Betriebssysteme verwalten die Hardware-Ressourcen des Rechners (CPU-Zeit, Speicher, E/A).
Versuchs doch mal mit FreeRTOS. Das ist recht verbeitet und da solltest du Hilfe und Beispiele im Netz finden können. Ich habs spaßeshalber mal auf nem 128er laufen lassen. War mit wenigen Handgriffen angepaßt.
ARM-Fan danke für die Antwort! Wie ist es mit dem Speicher, wie groß kann das Programm werden? Bist du schon an die grenze gestoßen?
Der Betriebssysteme-Guru Andrew S. Tanenbaum schreibt in seinem Buch "Moderne Betriebssysteme": "Editoren, Compiler, Assembler, Binder und Kommandointerpreter sind definitiv nicht Teil des Betriebssystems, auch wenn sie bedeutsam und nützlich sind." (Ich hab das jetzt mal aus Wikipedia zitiert, weil das Buch daheim steht..)
@stoppel: ein RTOS ist generell aus verschiedenen "Baugruppen" aufgebaut, die du je nach Anwendungsfall hinzufügen kannst... sprich du kannst es bis auf den kernel und einige treiber reduziern... mit dem mega128 ist da schon einiges möglich...
Bitte 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.