Python auf einem Echtzeit-Betriebssystem (RTOS)

https://stackoverflow.com/questions/1402933

05-07-2019
|

Frage

Ich plane ein kleines Datenerfassungssystem auf einer RTOS-Plattform zu implementieren. (Entweder auf einem QNX oder ein RT-Linux-System).

Soweit ich weiß, sind diese Arbeitsplätze C / C ++ durchgeführt unter Verwendung den meisten aus dem System heraus zu bekommen. Allerdings bin ich neugierig zu erfahren, und einige erfahren Leute Meinungen lernen will, bevor ich blind in die Codierung Aktion springen, ob es möglich wäre, und klüger alles in Python zu schreiben (von Low-Level-Instrumente durch eine glänzende grafische Benutzeroberfläche Schnittstelle). Wenn nicht, Mischen mit zeitkritischen Teilen des Designs mit „C“ oder dem Schreiben allem in C und nicht einmal eine Zeile von Python-Code setzen.

Oder zumindest das Einwickeln des C-Code mit Python einen einfacheren Zugriff auf das System zu liefern.

Welchen Weg würden Sie mir raten, auf zu arbeiten? Ich würde mich freuen, wenn Sie auch einige ähnliche Design Fälle und weiterführende Literatur verweisen.

Danke

Hinweis 1: Der Grund, auf QNX hervorzuheben ist aufgrund uns bereits ein QNX 4.25 basierten Datenerfassungssystem ( M300 ) für unsere atmosphärische Messung Experimente. Dies ist ein proprietäres System, und wir können die Interna nicht darauf zugreifen. Suchen Sie weiter auf QNX könnte uns da 6.4 von Vorteil sein, hat eine freie akademische Lizenzierungsoption, kommt mit Python 2.5 und einer aktuellen GCC-Version. Ich habe nie ein RT-Linux-System getestet, nicht wissen, wie vergleichbar es zu QNX in Bezug auf die Stabilität und Effizienz, aber ich weiß, dass alle Mitglieder von Python Lebensraum und nicht-Python-Tools (wie Google Earth), dass das neue System die meiste Zeit out-of-the-box könnte man auf Werke entwickelt werden.

Lösung

ich kann nicht sprechen alle Datenerfassung Setup gibt, aber die meisten von ihnen verbringen die meisten ihrer "Echtzeitbetrieb" warten für Daten kommen -. zumindest die, die ich gearbeitet habe auf

Dann, wenn die Daten hat kommt, müssen Sie sofort das Ereignis aufzeichnen oder darauf reagieren, und dann auf das Wartespiel geht es zurück. Das ist in der Regel die meisten zeitkritischen Teil eines Datenerfassungssystems. Aus diesem Grund würde ich im Allgemeinen sagen Stick mit C für die E / A-Teile der Datenerfassung, aber es gibt keine besonders zwingenden Gründen nicht Python auf die nicht-zeitkritischen Teile zu verwenden, .

Wenn Sie ziemlich lose Anforderungen haben - nur Millisekunde Präzision braucht, vielleicht - das etwas mehr Gewicht, alles zu tun, in Python erstellt. Soweit die Entwicklungszeit geht, wenn Sie mit Python bereits vertraut sind, würden Sie wahrscheinlich ein fertiges Produkt deutlich früher, wenn Sie alles in Python zu tun sind und Refactoring nur als Engpaß auftreten. Doing den Großteil Ihrer Arbeit in Python wird es auch einfacher macht gründlich Ihren Code zu testen, und als allgemeine Faustregel wird es weniger Code-Zeilen und damit weniger Raum für Fehler sein.

Wenn Sie müssen speziell multi- Aufgabe (nicht multi- Thread ), Stackless Python könnte auch von Vorteil sein. Es ist wie Multi-Threading, aber die Fäden (oder Tasklets, in Stackless Lingo) nicht OS-Level-Threads, aber Python / Anwendungsebene, so dass der Aufwand zwischen Tasklets Schalt ist deutlich reduziert. Sie können Stackless konfigurieren kooperativ oder präventiv Multitasking. Der größte Nachteil ist, dass die Blockierung IO wird in der Regel den ganzen Satz von Tasklets blockieren. Wie dem auch sei, wenn man bedenkt, dass QNX ist bereits ein Echtzeit-System, ist es schwer, darüber zu spekulieren, ob Stackless lohnen würde, verwendet wird.

Meine Stimme würde die so-viel-Python-as-mögliche Route nehmen - ich es als niedrig Kosten und hohe Leistung zu sehen. Falls und wenn Sie in C neu zu schreiben brauchen, haben Sie bereits funktionierenden Code starten aus.

Andere Tipps

habe ich mehr all-Python weiche Echtzeit (RT) Systeme, mit primären Zykluszeiten von 1 ms bis 1 Sekunde gebaut. Es gibt einige grundlegende Strategien und Taktiken ich auf dem Weg gelernt haben:

Einfädeln / Multiprozessing Verwenden nur nicht-RT Arbeit aus dem primären Thread abzuladen, wobei Warteschlangen zwischen Threads sind akzeptabel und kooperatives Einfädeln möglich ist (kein preemptive Fäden!).
die GIL vermeiden. Das bedeutet im Grunde nicht nur Einfädeln zu vermeiden, sondern auch System vermieden werden Anrufe an die soweit wie möglich, vor allem bei zeitkritischen Operationen, es sei denn, sie nicht blockierend sind.
Verwenden von C-Module, wenn praktisch. Dinge (in der Regel) gehen schneller mit C! Aber vor allem, wenn Sie Ihre eigenen nicht schreiben müssen: in Python bleiben, wenn es wirklich keine Alternative. C Modulleistung zu optimieren, ist ein PITA, vor allem wenn es über die Python-C-Schnittstelle zu übersetzen wird der teuerste Teil des Codes.
Mit Python-Beschleuniger Code zu beschleunigen. Mein erstes RT Python Projekt stark von Psyco profitiert (ja, ich habe dies eine Weile tun). Ein Grund, warum ich heute mit Python 2.x zu bleiben ist PyPy: Things immer geht schneller mit LLVM
Haben Sie keine Angst zu Belegt warten, wenn kritische Zeitpunkt benötigt wird. Verwenden time.sleep () auf ‚heranzuschleichen‘ von der gewünschten Zeit, dann busy-Warten während der letzten 1-10 ms. Ich habe in der Lage gewesen, in der Größenordnung von 10 Mikrosekunden wiederholbare Leistung mit Selbst Timing zu bekommen. Seien Sie sicher, dass Ihre Python Aufgabe bei max OS Priorität ausgeführt wird.
Numpy ROCK! Wenn Sie ‚live‘ Analytik oder Tonnen von Statistiken tun, gibt es NO Art und Weise mehr Arbeit schneller und mit weniger Arbeit (weniger Code, weniger Fehler) als durch Numpy Verwendung zu erhalten. Nicht in jeder anderen Sprache, die ich kenne, einschließlich C / C ++. Wenn die Mehrheit des Codes von Numpy Anrufe besteht, werden Sie sehr, sehr schnell. Ich kann nicht für die Numpy Port PyPy warten abgeschlossen werden!
Beachten Sie, wie und wann Python tut Garbage Collection. Überwachen Sie Ihre Speichernutzung und GC erzwingen, wenn nötig. Achten Sie darauf, explizit GC während zeitkritische Operationen deaktivieren. Alle meine RT Python-Systemen laufen kontinuierlich, und Python liebt hog Speicher. Eine sorgfältige Codierung kann fast alle dynamische Speicherzuweisung, wobei in diesem Fall können Sie vollständig zu deaktivieren GC!
Versuchen Verarbeitung in Chargen so weit wie möglich durchzuführen. Anstelle der Verarbeitung von Daten an der Eingangsrate, versucht, Daten mit der Ausgangsrate zu verarbeiten, die oft viel langsamer. Die Verarbeitung in den Reihen macht es auch bequeme höhere Ebene Statistiken zu sammeln.
Habe ich erwähnt, mit PyPy? Nun, es ist erwähnenswert, zweimal.

Es gibt viele andere Vorteile für die Verwendung Python für RT Entwicklung. Zum Beispiel, auch wenn Sie sich ziemlich sicher, Ihre Zielsprache sind, können nicht Python sein, es kann enorme Vorteile zahlen zu entwickeln und einen Prototypen in Python debuggen, es dann sowohl die Verwendung als Vorlage und Test-Tool für das endgültige System. Ich hatte Python wurde mit schnellen Prototypen der „harten Teile“ eines Systems seit Jahren zu schaffen, und quick'n'dirty Test GUIs zu erstellen. Das ist, wie mein erstes RT Python System entstanden: Der Prototyp (+ Psyco) war schnell genug, auch mit dem Test GUI läuft

-BobC

Edit: Vergessen Sie die plattformübergreifende Vorteile zu erwähnen: Mein Code läuft ziemlich überall mit a) keine Neuübersetzung (oder Compiler Abhängigkeiten, oder müssen für Cross-Compiler) und b) so gut wie keine plattformabhängige Code (hauptsächlich für misc Sachen wie Datei-Handling und serielle I / O). Ich kann auf Win7-x86 entwickeln und bereitstellen auf Linux-ARM (oder jede andere POSIX OS, von denen alle Python haben in diesen Tagen). PyPy ist in erster Linie x86 für jetzt, aber die ARM-Port ist in einem unglaublichen Tempo weiterentwickelt.

Im Allgemeinen ist der Grund vorgeschoben gegen die Verwendung einer Hochsprache in einem Echtzeit-Kontext ist Unsicherheit - wenn Sie eine Routine einmal ausführen es 100us nehmen könnte; das nächste Mal, wenn Sie die gleiche Routine führen Sie es malloc können entscheiden, ob eine Hash-Tabelle zu erweitern, nennt, dann fragt malloc den Kernel für mehr Speicher, die sofort etwas tun konnten Millisekunden später zurückkehren Sekunden auf der Rückkehr von der Rückkehr späterer erroring, von denen keine unmittelbar erkennbar ist (oder steuerbar) aus dem Code. Während theoretisch, wenn Sie in C schreiben (oder sogar weniger) können Sie nachweisen, dass Ihre kritischen Pfade „immer“ (abgesehen von Meteoriteneinschlag) in X Zeit.

Unser Team haben einige Arbeit die Kombination mehrerer Sprachen auf QNX getan und hatte ziemlich viel Erfolg mit dem Ansatz. Python kann einen großen Einfluss auf die Produktivität haben, und Tools wie SWIG und ctypes machen es wirklich einfach, den Code zu optimieren und kombinieren Merkmale aus den verschiedenen Sprachen an.

Wenn Sie jedoch etwas Zeit kritisch schreiben, sollte es mit ziemlicher Sicherheit in C geschrieben werden. Dadurch bedeutet, dass Sie die impliziten Kosten einer interpretierten Langauge wie die GIL vermeiden ( Globale Interpreter Lock ) und Konkurrenz auf vielen kleinen Speicherzuordnungen. Beide Dinge haben einen großen Einfluss darauf, wie Ihre Anwendung führt.

Auch Python auf QNX neigt nicht mit anderen Distributionen zu 100% kompatibel zu sein (dh / es manchmal ist Module fehlt).

Eine wichtige Anmerkung:. Python für QNX ist in der Regel nur für x86

Ich bin sicher, dass Sie es für ppc und andere Archs zusammenstellen können, aber das ist nicht aus der Box zur Arbeit zu gehen.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow