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.
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.
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
"Ü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.
"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.
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.
Kann mir jemand ein paar Tips geben. FreeRTOS, uCOS-II oder CTL von Rowley ? mfg mathias
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.
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.