Auf einem kleinen Embedded-System-Projekt haben wir einen Code, den wir gerne in einem Thread ausführen würden, also entscheiden wir uns, oben auf einem eingebetteten RTOS (eCos) zu bauen.
Zuvor haben wir in main () eine zyklische Exekutive verwendet, die Aufgaben ausführte, die jeweils als Zustandsmaschine implementiert waren. Bei einigen Aufgaben traten Probleme auf, bei denen die Aufgabe in viele feinkörnige Zustände aufgeteilt werden musste, wodurch der Code besonders komplex wurde.
Beim Wechsel zu einem RTOS haben wir festgestellt, dass die Speicherbelegung für jeden Thread-Stack schnell summiert, wenn wir jeder einzelnen Task einen eigenen Thread zuweisen. (Wir haben nur 64k und brauchen den Speicher für unsere Kommunikationspuffer)
Wir denken darüber nach, ein Profil für unsere Kommunikationsaufgabe und ein anderes Thema für eine zyklische Führungskraft zu verwenden. Die zyklische Exekutive steuert die anderen logischen Aufgaben.
Macht es Sinn, ein RTOS und einen zyklischen Manager so zu mischen?
Das ist ein absolut gültiges Design.
Bei einem unserer Produkte verwendeten wir ein ähnliches Design, bei dem die asynchronen I / O-Kanäle (TCP / IP, 2 serielle Ströme) ihre eigenen Aufgaben hatten und wir eine "Haupt" -Aufgabe hatten, die für mehrere Funktionsbereiche verantwortlich sein würde .
Stellen Sie sich Aufgaben einfach als Partitionierungsmechanismus vor, mit dem Sie Ihr Design vereinfachen können.
Ja, eine zyklische Exekutive in einem OS-Thread, die mehrere "Aufgaben" ausführt, kann sinnvoll sein. In der Tat, es sei denn, zwei Aufgaben widersprechen Planungsanforderungen (eine muss blockiert werden, eine hat höhere Priorität als die andere, und die niedrige Priorität benötigt viel Zeit für die Ausführung usw.), ich würde empfehlen, sie in denselben Thread einzufügen.
Dies gilt insbesondere für den Fall, dass Sie ein leichtes RTOS ohne Speicherschutz verwenden: separate Threads sind nicht sicherer als ein Thread (kein MMU-Schutz von Adressräumen), tatsächlich sind sie potentiell gefährlicher wegen der größeren Notwendigkeit für Parallelitätsschutz. Selbst wenn Ihr IPC-Schema robust und nicht anfällig für Missbrauch durch Programmierer ist, ist der Overhead in der Regel nicht Null, daher kann die Vermeidung von Bedarf zu Leistungssteigerungen führen.
Wenn Sie sich FreeRTOS anschauen , führen sie tatsächlich einen anderen Scheduler in einer Aufgabe aus, etwa:
Und um andere zu wiederholen, klingt im Design nichts falsch. Kein Grund (einige von) Ihre Aufgaben können nicht State-Maschinen sein, wenn es eine klare Möglichkeit gibt, etwas auf diese Weise auszudrücken.
Es ist ein gültiges Design, aber ich denke, ich habe den Grund für das Betriebssystem überhaupt nicht verstanden.
Welche Einrichtungen des Betriebssystems möchten Sie verwenden?
Aus den verfügbaren Informationen scheint es, dass Sie am Ende die Komplexität der Aufgaben in Ihre neue Hauptschleife verschieben werden.
Tags und Links multithreading embedded rtos