Ist es sinnvoll, ein RTOS und zyklisches Executive zu mischen?

Question

Auf einem kleinen Embedded-System-Projekt haben wir Code, den wir in einem Thread ausführen möchten, also wählen wir oben in einem eingebetteten RTOS (eCos).

Zuvor haben wir eine zyklische executive in main() verwendet, die Aufgaben ausgeführt hat, die jeweils als Zustandsmaschine implementiert wurden. 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 Speichernutzung für jeden Thread-Stack schnell summiert, wenn wir jeder einzelnen Task einen eigenen Thread zuweisen. (Wir haben nur 64k und benötigen den Speicher für unsere Kommunikationspuffer)

Wir erwägen die Verwendung eines Profils für unsere Kommunikationsaufgabe und eines anderen Threads für eine zyklische Exekutive. Die zyklische Exekutive steuert die anderen logischen Aufgaben.

Macht es Sinn, ein RTOS und eine zyklische Steuerung so zu mischen?

Answer 1

Dies ist ein perfekt gültiges Design.
In einem unserer Produkte verwendeten wir ein ähnliches Design, wo die asynchronen I/O-Kanäle (TCP/IP, 2 serielle Ströme) in ihren eigenen Aufgaben waren und wir hatten eine "Haupt" -Aufgabe, die für mehrere Bereiche zuständig wäre von Funktionalität.

Stellen Sie sich Aufgaben einfach als Partitionierungsmechanismus vor, mit dem Sie Ihr Design vereinfachen können.

Answer 2

Es ist ein gültiges Design, aber ich denke, ich habe den Grund für das Betriebssystem überhaupt vermisst.

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.

Answer 3

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 eine höhere Priorität als die andere, und die niedrige Priorität dauert sehr lange, 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 mehr gefährlich 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 Leistungssteigerungen zu Leistungssteigerungen führen.

Answer 4

Wenn Sie look at FreeRTOS, sie tatsächlich einen anderen Scheduler in einer Aufgabe ausführen, Art :)

Und andere Echo, klingt nichts mehr im Design falsch. Kein Grund (einige von) Ihre Aufgaben können nicht State-Maschinen sein, wenn es eine klare Möglichkeit gibt, etwas so auszudrücken.