mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Betriebssystem für AVR


Autor: Stoppel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Der Micha (steinadler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für was braucht man denn auf nem Microcontroller ein Betriebssystem?

Ist das nicht unnötiger Overhead?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Stoppel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

>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ß

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da gabs doch von PeDa mal so einen schönen Scheduler in der
Code-Sammlung.

Beitrag "Wartezeiten effektiv (Scheduler)"

Autor: Fabian Scheler (rosepeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Echtzeitkernel ist kein Windows, sondern ein Hilfsmittel zur 
Organisation parallel ablaufender Vorgänge.

Autor: ARM-Fan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Kleinwort (_sk_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stoppel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gibt es eigendlich auch eine Einfürung in RTOS oder irgendwelche 
Beispielprogramme wo einem das Prinzip und die Vorgehensweise beim 
programmieren erklärt wird?

Autor: Jörg B. (manos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: ARM-Fan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>...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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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."

Autor: Stoppel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: nop(); (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Roland (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: nop(); (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stoppel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,


könnt ihr mir einen Tip geben welches Betriebssystem ich für einen
ATmega 128 nehmen soll?

Danke

Autor: Michel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: ARM-Fan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stoppel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
 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?

Autor: duselbaer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..)

Autor: JÜrgen Grieshofer (Firma: 4CKnowLedge) (psicom) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.