Muss ich mich dann nicht mehr um die Hardware kümmern oder wie funktioniert es? Bin im Moment an einem ARM Cortex-M von Atmel.
hello schrieb: > Muss ich mich dann nicht mehr um die Hardware kümmern oder wie > funktioniert es? Richtig. Die wird beim Download automatisch mit runtergezogen. :-) Spass beiseite. Was Du wohl meinst, ist ein HAL (Hardware Abstraction Layer). Das hat aber nichts mit FreeRTOS zu tun. Den kriegst Du normalerweise vom Prozihersteller. Cortex-M? Dann solltest Du mal nach CMSIS googlen. Aber achtung: Das ist ein Reizthema! ;-) Es wurde hier auch schon über dessen Sinn oder Unsinn diskutiert. FreeRTOS ist im Wesentlichen ein Scheduler. Google und Wikipedia werden Dir verraten, um was es da geht. Kurz gesagt: Es unterstützt Dich, wenn Du mehrere Tasks quasi parallel laufen lassen möchtest. Also z.B. eine LED blinken lassen, einmal pro Sekunde ein Display updaten, jedesmal, wenn eine Taste gedrückt wird, diesen Tastendruck entprellen und handlen, wenn über USB ein Requst kommt, den beantworten.... Stell Dir mal das Gewürge vor, wenn Du das alles irgendwie in eine grosse while{true}-Schleife würgen müsstest. Und das erspart Dir ein Scheduler. Aber eben, das war nur eine SEHR grobe Erklärung. Auf der FreeRTOS-Seite hat's aber eine gute Erklärung, die sollte Dir mit diesem Start-Schubs nun auch helfen können. Gruäss Simon
Es geht im Wesentlichen darum, wie kann man mit ein paar Duzend Megahertz ein paar Relais ansteuern. Wobei jedes eine eigene Funktionslitaet und Timing hat. Nee. Man kann mit einer Zustandsmaschine auch unabhaengige Prozesse ansteuern. Mit zunehmender Komplexitaet, resp Verzahnung der Prozesse wird die Zustandsmaschine immer komplizierter. Ab einer gewissen Komplexitaet ist dann ein RTOS wieder einfacher.
Simon Huwyler schrieb: > Cortex-M? Dann solltest Du mal nach > CMSIS googlen. Aber achtung: Das ist ein Reizthema! ;-) Es wurde hier > auch schon über dessen Sinn oder Unsinn diskutiert. Auch die nächste CMSIS Version 3 enthält selbst fast keinen HAL. Nur für die Core-Peripherie wie NVIC/Systick, nicht aber für die herstellerspezifischen Teile. Dafür enthält sie aber aber ein RTOS.;-) Andersrum, die HALs gibts vom Hersteller der Controller, und in diesen Paketen ist dann auch das CMSIS mit drin.
A. K. schrieb: > Andersrum, die HALs gibts vom Hersteller der Controller, und in diesen > Paketen ist dann auch das CMSIS mit drin. Das war eben der Streitpunkt. Die Idee von CMSIS war wohl, dass eben diese Controllerhersteller (die meinte ich mit Prozihersteller, habe mich ein wenig salopp ausgedrückt :-) ihre proprietäre peripherie anhand der CMSIS-Regeln unter einen Hut bringen sollten. Inwiefern das geklappt hat oder je klappen wird, steht auf einem ganz anderen Blatt. Und wurde in einem anderen Thread diskutiert. A. K. schrieb: > Dafür enthält sie aber aber ein RTOS.;-) Echt jetzt? Da frage ich mich aber dann noch mehr, inwieweit DAS denn Sinn macht... Die sollten doch lieber mal das (nicht triviale) Ziel der wirklichen herstellerunabhängigen HAL in den Griff kriegen, bevor sie auf ein "ARM-Cortex-RTOS" hinzielen....? Die für einen scheduler interessanten Teile wurden ja eh (glücklicherweise) auf dem Cortex festgenagelt! Also wird jedes RTOS, das auf Atmels läuft, auch auf SMT32 laufen. Warum jetzt da noch was zusätzliches festnageln? Wie gesagt, lieber dafür sorgen, dass auch Timer 3 von Atmel durch den spezifischen HAL gleich angesteuert werden kann wie den Timer 3 von STM32!
Simon Huwyler schrieb: > Echt jetzt? Da frage ich mich aber dann noch mehr, inwieweit DAS denn > Sinn macht... Ja, denn ein RTOS ist beim Cortex M unabhängig von der Herstellerperipherie implementierbar. > Die sollten doch lieber mal das (nicht triviale) Ziel der > wirklichen herstellerunabhängigen HAL in den Griff kriegen, bevor sie > auf ein "ARM-Cortex-RTOS" hinzielen....? Dass ARM sich sich diesen Schuh nicht anzieht kann ich verstehen. Das gibt bloss Stunk und Zankerei. Und jede Menge Spesen für Gremientagungen an den schönsten Stellen der Welt. ;-) Drin ist indes eine Definition für eine formale Spezifikation der existierenden Peripherie der Bausteine. Damit die Hersteller von IDEs ihre Debugger damit füttern können und nicht selbst jedes Bit jedes Registers jedes einzelnen Bausteins selbst zu Fuss einpflegen müssen.
A. K. schrieb: >> Echt jetzt? Da frage ich mich aber dann noch mehr, inwieweit DAS denn >> Sinn macht... > > Ja, denn ein RTOS ist beim Cortex M unabhängig von der > Herstellerperipherie implementierbar. Eben. Das ist für mich also eher ein Grund GEGEN ein "Cortex-Betriebssystem". Denn das Ziel ist schon erreicht. FreeRTOS wird auf Cortex laufen. Basta. Ich brauche eben KEIN "Cortex-Betriebssystem", um zumindest in dieser Hinsicht hardwareunabhängig zu bleiben.
Ist ja gut, trink deinen Tee und beruhig dich wieder... ;-) Zwingt dich ja niemand, dieses RTOS auch zu verwenden.
Der Kopf von Chibios will auf jeden Fall in diese Richtung zielen und sich den Vorschlägen der CMSIS anpassen. Sicher nur Nebenher - denn es spricht nichts dagegen mehrgleisig zu fahren. Allerdings sehe ich den Vorteil schon - man könnte ganze Funktionsgruppen lauffähig gestalten wenn man die Betriebssytsem - Aufrufe standardisiert. Gruß, Thilo
der FreeRTOS Entwickler hat sein System auch schon weitergebaut, siehe http://www.freertos.org/FreeRTOS-Plus/index.shtml Da ist dann schon mehr HW Support mit drin als im reinen RTOS Scheduler. Wie die verschiedenen Proz.Hersteller Varianten darin gehandhabt werden habe ich noch nicht gesehen. Die CMSIS enthält ja nicht viele Funktionen, darauf aufbauend habe ich bei NXP eine Treiber-Lib gefunden die dann auch Basisfunktionen für die Peripherie bereitstellt. Gefällt mir auch ganz gut, aber soweit wird der CMSIS Standard sicher niemals gehen...
Vorteil: Keine Task muß auf die andere Rücksicht nehmen. Nachteile: Keine Task nimmt auf die anderen Rücksicht. Alles kann sich bunt durcheinander unterbrechen und in beliebiger Reihenfolge ausgeführt werden. D.h. Hardware und globale Variablen können nicht mehr direkt zugegriffen werden, sondern nur über spezielle Funktionen. Z.B. einfach so aufs LCD schreiben geht nicht mehr. Werden Sachen mehrfach gelesen, muß man sich eine Arbeitskopie anlegen. Ansonsten kann ne andere Task die zwischendurch ändern. Geführchtet beim RTOS sind Deadlocks (Tasks blockieren sich gegenseitig), da sie schwer zu debuggen sind. Man muß also beim Programmkonzept deutlich mehr aufpassen. Daß mehr CPU-Zeit und RAM benötigt wird, ist auch klar (jede Task braucht ihren eigenen Stack). Es kann durchaus sein, daß ein 8Bitter mit Mainloop und Interrupts die Echtzeitanforderungen spielend einhält. Ein 32Bitter mit RTOS aber schon am Anschlag arbeitet und vielleicht sogar noch händische Optimierungen benötigt. Peter
hello schrieb: > Muss ich mich dann nicht mehr um die Hardware kümmern oder wie > funktioniert es? Bei all den RTOS'sen, die mir bislang begegnet sind, mußt du dich nach wie vor selber um die Hardware kümmern - und zusätzlich dafst du dich auch noch um die Befindlichkeiten des RTOS kümmern. Und obendrein auch noch obacht geben, daß deine diversen Tasks sich nicht gegenseitig in die Quere kommen. Das, was es bislang so unter dem Namen RTOS gibt, ist bei genauerem Hinsehen bislang immer nur ein mehr oder weniger simpler Scheduler mit ein bissel Semaphorenbehandlung gewesen. Ich weigere mich schlichtweg, so etwas ein "Operating System" bzw. Betriebssystem zu nennen. Dafür sind all diese Möchtegerne einfach zu wenig. Man sollte sowas besser "Scheduler" nennen. Solche Scheduler machen einen erheblichen zusätzlichen Aufwand und der Nutzen ist bestenfalls "diskutabel". Wenn überhaupt, dann müßte ein Betriebssystem für einen uC sehr viel mehr an Nutzen beinhalten als das bloße Task-Verwalten. Es müßte tatsächlich auch die Peripherie verwalten und sinnvoll den Tasks zuteilen, müßte ein wohldefiniertes API besitzen, auf das man sich beim Schreiben der Tasks (=Applikationen) verlassen kann und so weiter beinhalten. Das ist viel an Anspruch - jaja, ich weiß. Aber ohne all dies ist ein "Echtzeit"-Betriebssystem herzlich überflüssig - jedenfalls für diejenigen, die blockierungsfrei programmieren können. Wer dafür zu doof ist, für den so ein RTOS jedoch nützlich. So. genug gemeckert für heute.. W.S.
Ein RTOS ist natuerlich kein Betriebssytem. Was fehlt denn an einem RTOS zu einem Betriebssystem ? - ein Benutzerinterface, Commandline Interpreter, zB eine BASH - eine Art Filesystem, das Programme verwaltet - ein Loader, der Programme Lader und Starten kann Ein RTOS hat ueblicherweise genau eine Applikation, die laeuft beim Booten los. Diese Applikation besteht dann aus mehrere Tasks, die koennen auch dynamisch gestartet werden. Der Vorteil eines RTOS gegenueber einer Zustandsmaschine mit Interrupts ist die bereits integrierte Intertask Kommunikation. Deren einfachste Form sind Semaphoren, die dann mit Klassen auf Queues, Mailboxen und Events aufgebohrt werden koennen.
BeRTOS unterstuetzt den sam3x inkl treibern und einigen services. Hab drauf nen webserver laufen, implementierung war ein kinderspiel. Freertos ist fur mich keine option mehr, bertos auch open source
Was ist denn konkret besser am BeRTOS?
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.