Entscheidung für ein RTOS

Auch beim besten Support der Welt würde ich immer darauf bestehen, den 
vollen Sourcecode zu bekommen. Ansonsten erschwert man sich das Debuggen 
wesentlich.

Und falls man in vielen Jahren, der Supportvertrag ist schon lange 
abgelaufen, doch nochmal was ändern muss und dann nicht versteht was da 
wirklich passiert, ist man ohne vollständigen Source ziemlich 
aufgeschmissen.

Falls man einen Bug findet oder irgendeine Änderung an der Schnittstelle 
vornehmen muss um eine bestimmte Funktion implementieren zu können, 
sollte man auch das Recht haben Änderungen am Source des RTOS vornehmen 
zu können und dieses veränderte Programm dann an die Kunden zu 
verteilen. Das ist nicht bei allen Anbietern erlaubt (oder kostet 
manchmal extra).

Meine RTOS-History (STM32):
scmrtos: http://scmrtos.sourceforge.net/ScmRTOS
Sehr einfach gehalten; man hat schnell ein Aha-Erlebnis. Weil lange Zeit 
daran nicht mehr weitergearbeitet wurde (z.Bsp. war kein Support für 
STM32F0xx), habe ich kalte Füsse gekriegt und habe mich andersweitig 
umgeschaut.
Seit Maerz 2015 wird wieder daran gearbeitet und STM32F0xx scheint 
unterstützt zu werden. Was mir besonders daran gefallen hat: es ist in 
C++ geschrieben, weshalb ich es ohne Klimmzüge verwenden konnte.

Dann habe ich mir FreeRTOS angeschaut; hatte aber Probleme, es in meine 
C++ Programme einzubinden.

NutTX: konnte damit überhaupt nichts anfangen. Was aber bestimmt an mir 
und nicht an NutTX lag.

ChibiOS: Auch hier hat man sehr schnell ein Aha-Erlebnis. Aber irgendwie 
war mit das zu überladen. Hin und wieder schaue ich dort noch vorbei. 
Seit der letzen Version scheint dort das RTOS auch ohne HAL verwendbar 
zu sein.

Z.Zt. verwende ich RTX von Keil und bin damit zufrieden. Auch hier hat 
man ein schnelles Aha-Erlebnis.

Erik schrieb:
>> scmrtos: http://scmrtos.sourceforge.net/ScmRTOS
>
> Ich habe mal in das Manual geschaut und war schon etwas über die
> Limitierungen überrascht, daher wohl leider für mich kommerziell nicht
> einsetzbar:

Ich hab es mir jetzt das scmRTOS nicht angeschaut, aber bei dem was Du 
hier zitiert hast, sehe ich kein Problem welches kommerziellen Einsatz 
verhindert oder fraglich macht.

> The RTOS supports up to 32 processes (including system process
> IdleProc, i.e. up to 31 user processes), each process has its own unique
> riority. All processes are static that means a process number is defined
> at compile time and no one process can be added or deleted on run time."

Brauchst Du wirklich mehr als 31 Prozesse/Threads? Müssen die wirklich 
dynamisch anglegt werden können?

Es gibt viele Systeme, vor allem kommerzielle, die ganz bewusst 
Ressourcen statisch allokieren und nicht dynamisch. Das betrifft Dinge 
wie Prozesse, aber oft auch den Speicher. Denn wenn der Speicher fest 
zur Compilezeit allokiert wurde, kann es keinen "out of memory"-Fehler 
geben. Mit den Prozessen ist es genauso - irgendein Limit gibt es immer 
und mit einem Bug, der zu einer "Forkbombe" oder etwas ähnlichem führt, 
killst Du Dein System.

Der bewusste Verzicht auf Funktionen schont also zum einen Ressourcen, 
erhöht aber zum anderen die Zuverlässigkeit und eliminiert eine ganze 
Klasse von Fehlermöglichkeiten.

Erik schrieb:
> Aber wenn ich zur Laufzeit keine
> Tasks erstellen oder beendeen kann ist das schon ein starke
> Einschränkung.

Naja, wenn die zur Compilezeit festgelegt werden, dann vermute ich mal 
daß die dann ihren eigenen Speicher, Stack und ihre 
Basis-Datenstrukturen festgelegt bekommen. Aber höchstwahrscheinlich 
wird der Startmoment und das Beenden (oder Abschalten) eines Tasks schon 
zur Laufzeit irgendwie steuerbar sein.

> Denk einfach mal an einen Webserver der bei einer neuen Connection eine
> oder meherer Webserver Child Tssks kreiert. Wieviele hängt davon ab
> wieviele Connections der Browser aufmacht und ist zur Compilezeit nicht
> bekannt.

Bei einem µC mit begrenzten Resourcen sollte aber zur Compilezeit die 
Maximalzahl an Child Tasks bekannt sein. Du könntest also z.B. 5 Tasks 
für Webserver Childs reservieren. Und die werden dann bei Bedarf 
gestartet und beendet. Wenn ein 6. Client eine Anfrage macht, wird die 
abgewiesen.

> Es gibt auch anscheind RTOS, bei denen ich in irgendwelchen
> Headerdateien konfigurieren muss wieviele Tasks ich benutzen möchte und
> andere, die das über verkettete Listen machen.

Generell würde ich sagen gilt desto komplexer die Taskstrukturen, desto 
mehr Overhead beim Taskswitch. Daher finde ich eine Definition der Tasks 
in einer Headerdatei gar nicht so schlecht.

> Mich hatte auch einfach die 31 irritiert.

Keine Ahnung wie tief diese 31 dort im Code verankert ist und wie schwer 
es wäre das zu erweitern. Aber aus meiner Erfahrung würde ich sagen, daß 
man mit 31 Tasks schon ziemlich weit kommt.

Ab einer gewissen Komplexität und Rechenleistungsbedarf würde ich eh auf 
ein Embedded Linux wechseln und nur wenige ganz zeitkritische Tasks von 
einem separaten µC mit RTOS erledigen lassen. Die Preisdifferenz 
zwischen großen µC und linuxfähigen Embeddedprozessoren ist in den 
letzten paar Jahren so deutlich geschrumpft, daß oft die einfachere 
Entwicklung und der fertige OpenSource-Stack mehr wiegt als der etwas 
günstigere µC. Gerade im Bereich Crypto musst Du mit regelmäßigen 
Änderungen rechnen (z.B. werden die Browser bald kein SSL mit SHA1 mehr 
akzeptieren). In ein paar Jahren nen neues OpenSSL-Package von der 
Distribution nehmen und compilieren ist simpel, in nem µC kann das nen 
richtiger Knochenjob werden oder sogar an Hardwarelimits scheitern.