www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RTOS ??


Autor: mgiaco82 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Eine Frage, ich habe bisher noch nie ein RTOS eingesetzt und muss das
jetzt bei einem Projekt machen (Student). Bisher hatte ich nur meine C
und H Files und ein main mit einer while(1) schleife. Mit
Timerinterrupts usw. wurde der Softwareablauf realisiert.

Wenn ich jetzt zum Beispiel eine Betriebssystem wie µC/OS-II einsetzte
oder so, kann ich da Programmieren wie sonst auch. Ich habe ja im
Prinzip nur eine paar main´s (Task´s) die pseudo parallel laufen oder?
Wie schauts da mit interrupts aus, zum Beispiel die Serielle
Schnittstelle kann man die genauso verwenden wie ohne RTOS, oder die
Display ansteuerung usw. ?

µC/OS-II muss verwendet werden. Prozessor ARM7 LPC2138 bzw. LPC2148
Compiler Rowley Crossworks. ==> GNU Port müsst ja gehen oder?

mfg mathias g.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Interrupts sind so wie bisher. Aber es gibt schon kleine
Unterschiede in der Programmiertechnik.

So sind längere Warteschleifen im RTOS zumindest unhöflich, jedenfalls
wenn sie lang genug sind, um per RTOS-Scheduling abgewickelt werden zu
können. Also nicht 50ms Warteschleife, sondern RTOS-Timer.

Du musstest ja schon bisher darauf achten, dass Daten und Ports, die
sowohl in Interruptroutinen als auch im Hauptprogramm benutzt werden,
nicht beliebig "einfach so" von beiden verwenden werden
können.Preemptives Multitasking vorausgesetzt, gilt das nun auch für
Daten, die von mehreren Tasks benutzt werden. Und wenn du diese
Feinheit bislang irgendwo mal vergessen haben solltest - bei einem RTOS
wirst Du das merken.

Komplexe (lies: zeitraubende) Interrupt-Routinen wird man mit RTOS eher
nicht komplett als Interrupt abwickeln. Statt dessen macht der
Interruptcode nur das nötigste (top half) und stösst eine Task an an,
die den zeitraubenden Kram erledigt (bottom half). Auf die Art kann man
sich verschachtelte Interrupts oft ersparen und hat weniger Zoff beim
Debugging.

Was man dafür mit RTOS erst kennenlernt: Deadlocks.

Autor: Stefan Kleinwort (_sk_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Matthias,

für uC/OS-II gibt es das sehr gute Buch MicroC/OS-II. Kann ich sehr
empfehlen, allerdings auf Englisch (stört mich pers. nicht so).

Unter einem RTOS programmierst Du im Prinzip genauso wie bei kleinen
Programmen. Das heisst: Du musst Dir einfach keine Sorgen darüber
machen, dass dein mc mehrere Sachen gleichzeitig erledigen muss. Muss
z.B. auf den Anwender gewartet werden: kein Problem, die Wartezeit ist
ja nicht verloren, sondern kommt den anderen Tasks zugute. Oder, falls
es nichts zu tun gibt, geht der mc automatisch in den Idle-Task und
schaltet auf Stromsparen um.

Du solltest vorher Dein Programm in mehrere Teilbereiche aufteilen,
z.B.:
* Bedienoberfläche
* Maschinensteuerung
* Treiber
* sonstiges

Gerade bei der Bedienoberfläche ist es sehr praktisch, wenn man diese
einfach am Stück programmieren kann und nicht in kleine Teile
aufstückeln muss.

Interrupts und serielle Schnittstelle fallen unter Treiber. Solange
diese nur von einem Task angesprochen werden (z.B. ein Task, der
Befehlseingabe und Auswertung der RS232-Daten macht), kannst Du bei
Deiner gewohnten Arbeitsweise bleiben: UART-Interrupt speichert in
Puffer, und ein Task holt sich dort die Daten ab.

Sobald mehrere Tasks gleichzeitig auf eine Ressource zugreifen wollen,
musst Du diese Ressource gegen die gleichzeitige Benutzung schützen -
durch Semaphoren oder indem sie einen eigenen Treiber-Task bekommt, der
sie exklusiv verwaltet.

Übrigens, die oft gehörte Behauptung, ein RTOS-System reagiere
langsamer in zeitkritischen Bereichen, ist meiner Meinung nach
unzutreffend. Ein Interrupt in einem RTOS-System kann bei Bedarf sofort
auf einen hochprioren Task umschalten, während bei einem Mainloop-System
erst der gerade bearbeitete Bereich abgearbeitet werden muss, bevor
umgeschaltet werden kann.

> und muss das jetzt bei einem Projekt machen

sehe es nicht so negativ - natürlich ist Einarbeitung gefragt, aber
danach macht das Arbeiten mit einem RTOS oft richtig Laune :-)

µC/OS-II ist übrigens als Student sicher keine schlechte Wahl, ich habe
es dann aber doch nicht benutzt, nachdem ich die Preise angefragt hatte,
die bei kommerzieller Nutzung fällig werden.

Viel Spass, Stefan

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Übrigens, die oft gehörte Behauptung, ein RTOS-System reagiere
langsamer in zeitkritischen Bereichen, ist meiner Meinung nach
unzutreffend."

So ganz falsch ist diese Aussage nicht, bei sehr engen zeitlichen
Rahmenbedingungen stimmt sie.

In Mainloop-Programmen sind Interrupts ziemlich nackt, kein
überflüssiger Wasserkopf. In einem preemptiven RTOS wird jedoch in
Interrupt-Handlern meist erst einmal der komplette Kontext gesichert,
vergleichbar zu einem Task-Switch - weil ja genau dies passieren kann.
Und das braucht Zeit.

Wenn man also die Reaktionszeit auf ein Interrupt-Ereignis schon in
Takten rechnen muss damit das System funktioniert, braucht man mit
solchen RTOS-integrierten Interrupts u.U. zu lang. Ein Lob dem ARM,
dessen Interrupt-Architektur zwar sonst nicht preisverdächtig ist, aber
für sowas taugt sie dank dem FIQ.

Autor: Jürgen Schuhmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Komplexe (lies: zeitraubende) Interrupt-Routinen wird man mit RTOS
eher nicht komplett als Interrupt abwickeln"

Das empfiehlt sich auch, in proprietären C Programmen so zu handhaben.
Das Vollstopfen von Interruptroutinen, die sich womöglich noch
gegenseitig unterbrechen ist eine Unsitte die von sehr schlechter
Programmiertechnik zeugt. Eine ISR empfängt nur den event und setzt ein
flag, ansonsten wird das rechnen und Verarbeiten dem Hauptprogramm
überlassen. Dann sind jene auch schnell, flüssig und effektiv. Tasks
sind dann einfacher synchronsierbar, so dies aus logischer Sicht
möglich und geboten ist. Dann vor Allem sind C-Progrogs auch effektiv
vor allem gegen overheadlastige C++ und RTOS basiete Systeme.

Autor: mgiaco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super, danke erstmal.

mfg mathias

Autor: mgiaco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So habe jetzt mal ein wenig nachgelesen und gegoogelt. Nun ich kann
jetzt selbst entscheiden welches RTOS, es gibt keine vorgabe mehr.

Also was würdet ihr nehmen? Compiler Crossworks-ARM, LPC2148.

FreeRTOS, oder uC/OS-II oder Crossworks Tasking Libary?

Hat jemand schon uC/OS-II auf Crossworks umgeschrieben, gibts den Port
irgendwo zum download?

Besten Dank

mfg mathias g.

Autor: mgiaco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann mir jemand ein paar Tips geben.

FreeRTOS, uCOS-II oder CTL von Rowley ?

mfg mathias

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir ein paar davon angesehen, und bin zum Schluss gekommen,
dass mir hier nur Selbstgekochtes wirklich schmeckt. Die Tatsache dass
es ein ziemliches Sammelsurium an RTOSs gibt, deutet darauf hin, dass
ich mit dieser Einstellung nicht alleine stehe.

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.