Mythos Nr. 6: Ein RTOS erschwert das Portieren von Applikationen.
Anwendungen mit RTOS greifen über ein API auf ihre Dienstfunktionen zu, wodurch das RTOS plattformunabhängig wird. Der Wechsel auf einen anderen Prozessor wird vereinfacht, da keine der Dienst-Referenzierungen der Applikation geändert werden muss. Anders ausgedrückt: die Applikation läuft überall dort, wo auch das RTOS läuft, und das heißt bei den meisten kommerziellen und Open-Source-RTOS-Produkten, dass sie auf praktisch jeder 32bit-Prozessorarchitektur lauffähig ist. Bei nur geringen Änderungen an ihrem Code profitieren Entwickler also von der Portierbarkeit ihrer Applikationen.
Mythos Nr. 7: Ein RTOS belegt zu viel Speicher.
Ein RTOS benötigt für seinen Betrieb sowohl Befehlsspeicher (meist Flash) als auch Datenspeicher (RAM). Ein gutes kommerzielles RTOS aber braucht nur wenig von beidem: meist sind es rund 2KB Befehlsspeicher und 1KB RAM. Selbstverständlich sind diesbezüglich auch die Anforderungen der Applikation zu erfüllen, wodurch es noch vorteilhafter ist, wenn das RTOS mit wenig Speicher auskommt.
Mythos Nr. 8: Ein RTOS benötigt zu viele Verarbeitungszyklen.
Tatsache ist, dass ein RTOS Verarbeitungszyklen für Kontextwechsel, API-Aufrufe usw. benötigt, jedoch stehen diese Zyklen in direktem Zusammenhang mit dem, was die Applikation verwendet. Wenn etwa eine bestehende Polling-Schleife unverändert aus einem einzigen Thread in einem RTOS ausgeführt wird, entsteht keinerlei Mehraufwand, und die Schleife wird genau so verarbeitet wie zuvor. Zusätzlicher Verarbeitungsaufwand durch das RTOS entsteht erst dann, wenn RTOS-Dienste genutzt werden. Hinzu kommt, dass ohne ein RTOS die Applikation selbst für alle erforderlichen Verarbeitungsaufgaben verantwortlich ist, einschließlich der Zyklen, die für das Polling, die Funktionsaufrufe und die Interruptverarbeitung aufgewendet werden. Wenn man also von ganz einfachen Anwendungen absieht, ist es wahrscheinlich, dass das RTOS weniger Zyklen benötigt als die Applikation, wenn sie alle Aufgaben allein bewältigen müsste.
Mythos Nr. 9: Ich habe nicht die Zeit, die Verwendung eines RTOS zu erlernen.
Der Aufwand zur Einarbeitung in ein RTOS ist proportional zu dem, was von der Applikation genutzt wird. Z.B. würde für das Verlegen einer bestehenden Polling-Schleife in einen einzelnen Thread praktisch kein zusätzlicher Lernaufwand entstehen. Die Fallstricke, die bei der Verwendung einer Polling-Loop-Architektur lauern, sorgen aber dafür, dass das Studieren und erneute Untersuchen der Leistungsfähigkeit der gesamten Firmware den Aufwand zum Erlernen eines RTOS sehr schnell bei weitem übersteigt, besonders wenn man den ursprünglichen Code nicht selbst geschrieben hat. Die meisten Anbieter guter kommerzieller Echtzeit-Betriebssysteme bieten außerdem Vor-Ort-Schulungen und äußerst umfangreiche Dokumentation an. Abgesehen davon ist ein gutes kommerzielles RTOS auch einfach zu verstehen und anzuwenden.
