Welches RTOS für STM32F4?

Privat oder kommerziell?

embOS von Segger, http://segger.com/embos.html.

Artjomka schrieb:
> Sehe ich das richtig, dass jedes RTOS auf die Zielhardware angepasst
> werden muss? Oder gibt es ein RTOS, welches z.B. für alle Cortex M4 ohne
> Änderungen genutzt werden kann?

In der Regel ist das OS vom Hersteller schon auf deine CPU und Compiler 
portiert. Die Frage ist dann eher, ob es passende Startprojekte für dein 
Device bzw. Evalboard gibt, mit denen du out of the box arbeiten kannst.

Bei embOS gibt es es diverse Portierungen für Cortex M, z.B. embOS 
Cortex M IAR oder embOS Cortex M GNU. Darin enthalten sind dann viele 
Startprojekte für diverse Evalboards, also z.B. STM32F4 Discovery oder 
STM32F4G-EVAL.

Ansonsten unterstützt embOS auch CMSIS, sprich es ist ein generisches 
CMSIS Projekt enthalten, welches auf jedem Cortex M0/M1, M3/M4 und M4F 
läuft.

Eine Trial Version kannst du einfach unter 
http://segger.com/downloads.html?pid=27 herunter laden. Einzige 
Einschränlung der Trial Version: Es läuft nur 12 Stunden nach Reset, 
wenn du mehr als 3 Tasks erzeugst.

Wir setzen embOS seit Jahren in diversen Produkten ein. Funktioniert 
einfach und macht was es soll.

>Eine Trial Version kannst du einfach unter
>http://segger.com/downloads.html?pid=27 herunter laden. Einzige
>Einschränlung der Trial Version: Es läuft nur 12 Stunden nach Reset,
>wenn du mehr als 3 Tasks erzeugst.

Guter Witz, da nimmt man besser ein wirklich freies System wie FreeRTOS 
oder CoOS...

Hallo

schau dir doch mal ChibiOS unter http://www.chibios.org an. Die Doku von 
dem System ist gut an mann kann als Anfänger auch dahinter kommen wie 
das OS eigendlich funktioniert. Das System ist GPLv3 also frei, es ist 
schnell und für den F4 gibt es schon eine gute HAL mit API so wie für 
das F4Discovery ein paar nette How To's.

mfg

CalM

Ja ChibiOS war auch mein erstes RTOS überhaupt. Bin mit dem F4 Discovery 
prima zurecht gekommen. Schaus Dir an.

Vielen Dank für eure Antworten, ChibiOS hört sich ja schonmal ganz gut 
an.

Ich war auf der Suche nach einem freien OS.

Das man für das OS richtige Treiber einbindet hätte ich nicht gedacht. 
Das abstrahiert die Hardware aber ganz schön extrem (ein Informatiker 
wird sich darüber sicherlich freuen, wenn man aus der AVR und Co Welt 
kommt wirkt das etwas befremdlich :-/).

Werde mir das ChibiOS mal anschauen, wenn ihr das für Anfänger geeignet 
haltet :)

>Auf dem ST-Seminar sagte der Keil-Mensch, dass RTX frei und kostenlos
>nutzbar wäre.

Heisst das, ich darf den RTX Sourcecode nehmen und z.B. in ein CooCox 
CoIDE Projekt integrieren? Da wäre die 32kB Begrenzung von Keil weg!

Peter schrieb:
>>Eine Trial Version kannst du einfach unter
>>http://segger.com/downloads.html?pid=27 herunter laden. Einzige
>>Einschränlung der Trial Version: Es läuft nur 12 Stunden nach Reset,
>>wenn du mehr als 3 Tasks erzeugst.
>
> Guter Witz, da nimmt man besser ein wirklich freies System wie FreeRTOS
> oder CoOS...

Nein, kein Witz. Du musst lernen zu unterscheiden zwischen kommerziellen 
und privaten Projekten. Bei einem kommerziellen Projekt werden die 
wenigsten z.B. FreeRTOS einsetzen wollen. Privat ist das natürlich etwas 
ganz anderes.

Deswegen hatte ich ja auch gefragt ob privat oder nicht. Hat ja auch 
keiner behauptet das embOS frei ist und die Trial Version dient 
natürlich auch nur zum Evaluieren und nicht für den privaten Gebrauch.


> Gibt es bei den gängigen RTOS Einschränkungen in Bezug auf
> Interrupt-Fähigkeit (ich werde wohl ein paar Hardware-Interrupts
> benötigen welche nicht durch das RTOS gestört werden sollten) oder
> Einschränkungen der Hardware-Funktionen?
Das hängt davon ab, ob ein OS die Interrupts global sperrt oder mit 
Interrupt Prioritäten arbeitet. Bei embOS z.B. ist es so, das Interrupts 
nie global gesperrt werden, sondern z.B. beim Cortex M das BASEPRI 
Register auf den Wert 128 gesetzt wird. Damit gibt es Interrupts mit 
einer Priorität 0..128, die nie vom OS gesperrt werden und daher keine 
zusätzliche Latenz bekommen.

Sven S. schrieb:
>> Bei einem kommerziellen Projekt werden die
>> wenigsten z.B. FreeRTOS einsetzen wollen. Privat ist das natürlich etwas
>> ganz anderes.
>
> Das würd ich jetzt nicht sagen. Viele Firmen benutzen die kommerzielle
> Variante von FreeRTOS -> OpenRTOS (das gleiche, nur mit Support) und
> falls SIL benötigt, kann man das auf SafeRTOS upgraden.

Ja, ok klar, aber ich habe ja auch von FreeRTOS gesprochen und nicht von 
OpenRTOS oder SafeRTOS, denn für die zahlst du auch wieder Geld. Ist 
aber auch bei FreeRTOS die Ausnahmen, das eine Variante mit Support 
gibt.
Die Entscheidung für ein RTOS in einem kommerziellen Projekt hängt ja 
aber von noch mehr Faktoren ab (Lizenz, Kosten, Support, Training, 
weitere Middleware, usw...).

>RTX von Keil .. da klickst du drei Optionen an,
>importierst die Header und es funktioniert (sogar mit FPU)!

Bist Du Dir da sicher mit der FPU? Ich habe mich vor einigen Wochen 
durch den RTX-Code gewühlt (mal nebenbei bemerkt, viel zu viel ASM für 
meinen Geschmack) habe aber vergeblich nach dem Code-Abschnitt gesucht, 
der die FPU-Register beim Task-Wechsel sichert! ==> Solange mir keiner 
zeigen kann ob bzw. wo das geschieht, ist wohl nicht viel mit 
FPU-Unterstützung.

Natürlich geht es theoretisch gut, solange FPU-Operationen nur in einem 
Task verwendet werden, aber wer kann schon sicher sein, dass der 
Compiler nicht irgendwo z.B. in einem printf() noch eine FPU-Berechnung 
reinschiebt?

Prinzipiell gibt es da zwei Möglichkeiten:
1. Man sichert immer alle FPU Register beim Task Wechsel auf den Task 
Stack.
Dies hat den Nachteil, das dies auch für Tasks gemacht werden würde, die 
gar keine FPU benutzen.

2. Man hat wie bei embOS die Möglichkeit über einen einfachen API Aufruf 
den Task Kontext um genau diese FPU Register zu erweitern. Damit kann 
man selber bestimmen, welche Tasks die FPU Register rettet und welche 
nicht.



Ich mein aber schon, das auch RTX FPU unterstützt, ich kann jetzt nur 
nicht sagen, welche von beiden Varianten.

Meine private Wahl ist FreeRTOS, weil

- gibt es mittlerweile für Cortex-M4 mit FPU-Unterstützung.
- kann das "Lazy-Save" der FPU voll ausnutzen
- speichert den FPU-Context nur, wenn er auch verwendet wird
- recht übeschaubarer Umfang, so dass man sich auch mal durch die 
Sourcen wühlen kann
- große Community
- liegt im Sourcecode vor (weiß nicht, ob das bei den ganzen 
kommerziellen Dingern auch so ist?)
- unterstützt so viele Architekturen, dass ich wahrscheinlich nie was 
anderes brauche
- Abstarktionsgrad ist für mich persönlich angenehm (empfand ich bei 
ChibiOS als befremdlich)

sollte für privat reichen ;-)
Falls es mal kommerzieöö werden sollte, gibt es Upgrademöglichkeiten.

Karl schrieb:
> - liegt im Sourcecode vor (weiß nicht, ob das bei den ganzen
> kommerziellen Dingern auch so ist?)

Klar ist das bei kommerziellen auch so, aber dafür zahlt man dann 
natürlich auch mehr als bei der Obj Variante.