Wir wollen in einem nächsten Produkt einen Cortex M und ein RTOS einsetzen. Da es eine kommerzielle Anwendung ist sind Lizenzgebühren kein Problem. Ich habe noch wenig Erfahrung mit RTOS, kenne nur Namen wie RTX, uC/OS-II, ThreadX oder embOS. Hat jemand Erfahrung mit einem kommerziellen RTOS und kann etwas empfehlen? Was setzt ihr in euren Produkten ein? Mir geht es hier nicht um private Projekte. Danke!!
Ich setze für einen STM32 ein Keil RTX ein und hab auch schon mit free RTOS experimentiert. Das Keil System war gefühlsmässig besser dokumentiert und verständlicher.Bin damit sehr zufrieden. Grüsse Gebhard
Wir nutzen ThreadX auf einem Cortex M4 mit 180 MHz (STM32). Läuft sehr stabil und ist einfach zu nutzen. Die Dokumentation ist gut und verständlich. Threads sind sehr einfach zu erstellen. Der Support ist flott, jedoch machen sich die 9 Stunden Zeitunterschied (San Diego) negativ bemerkbar. Durch den (optional?) offenen Quellcode kann man im Fehlerfall sehr gut debuggen. Kann es uneingeschränkt weiterempfehlen. Gruß Christian
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.
Danke für eure Antworten. Hat keiner Erfahrungen mit embOS? Spricht irgendwas dagegen? Sah für mich auf den ersten Blick richtig gut aus, https://www.segger.com/embos.html. Mehmet K. 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: "scmRTOS is the real time operating system with preemptive priority process scheduling. 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."
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.
Jain, das Problem sehe ich nicht darin das Datenstrukturen statisch angelegt sind. Das sollte auch so sein. Aber wenn ich zur Laufzeit keine Tasks erstellen oder beendeen kann ist das schon ein starke Einschränkung. 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. 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. Wie gesagt, die Task Control Blöcke wird man so oder so statisch anlegen aber wenn ich das bei z.B. embOS richtig sehe ist beim Kreieren der Task völlig egal wo der Speicher herkommt, entweder statisch oder auch vom Heap (was man normalerweise natülich nicht macht). Mich hatte auch einfach die 31 irritiert. Bei embOS steht z.B. was von Unlimited Tasks, das scheint mir sinnvoller. https://www.segger.com/cortex-m--ses.html Max. no. of tasks Unlimited (by available RAM only)
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.
Gerd E. schrieb: > 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. Das kann man so pauschal nicht sagen und hängt von der Implementierung ab. Generell sind Arrays nicht besser als verkettete Listen und können sogar mehr Aufwand bedeuten. Wenn man da Zweifel hat einfach mal Taskwechselzeiten vergleichen. Gerd E. schrieb: > Keine Ahnung wie tief diese 31 dort im Code verankert ist und wie schwer > es wäre das zu erweitern. Ich glauche der Threadersteller genauso wenig wie andere Industriekunden möchten selber an dem OS rumfummeln ;-). Das ist halt der Unterschied zwischen kommerziellen und privaten Einsatz. Gerd E. schrieb: > 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. Das kann man so allgemein auch nicht sagen. Es ist schon ein Preisunterschied, ob man z.B. einen Cortex A9 plus externen Speicher oder einen kleinen Mikrcontroller einsetzt. Bei großen Stückzahlen macht das schon einiges aus. Aber das sollten wir nicht weiter vertiefen. Der Threadersteller sagte ja schon, das er einen Cortex M und ein RTOS einsetzen möchte.
Habe in den 80er dieses RTOS professionel eingesetzt: https://www.hightec-rt.com/en/products/real-time-os.html Ist sehr stabil und performant.
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.