Python sur un système d'exploitation en temps réel (RTOS)

Question

Je prévois de mettre en place un système d’acquisition de données à petite échelle sur une plate-forme RTOS. (Sur un système QNX ou RT-Linux.)

Autant que je sache, ces travaux sont effectués à l'aide de C / C ++ afin de tirer le meilleur parti du système. Cependant, je suis curieux de savoir et de vouloir connaître l'opinion de personnes expérimentées avant de me lancer aveuglément dans l'action de codage pour savoir s'il serait réalisable et plus sage de tout écrire en Python (depuis un instrument de bas niveau s'interfaçant via une interface utilisateur graphique brillante). Si ce n'est pas le cas, mélanger avec des parties critiques de la conception avec "C", ou tout écrire en C sans mettre une ligne de code Python.

Ou au moins en enveloppant le code C à l’aide de Python pour faciliter l’accès au système.

Dans quel sens me conseilleriez-vous de travailler? Je serais heureux si vous signalez des cas de conception similaires et d'autres lectures.

Merci

NOTE1: Si nous mettons l'accent sur QNX, nous possédons déjà un système d'acquisition de données basé sur QNX 4.25 ( M300 ) pour nos expériences de mesure atmosphérique. C'est un système propriétaire et nous ne pouvons pas accéder à ses composants internes. En savoir plus sur QNX pourrait être avantageux pour nous puisque 6.4 propose une option de licence académique gratuite, livrée avec Python 2.5 et une version récente de GCC. Je n'ai jamais testé un système RT-Linux, je ne sais pas comment il est comparable à QNX en termes de stabilité et d'efficacité, mais je sais que tous les membres de Habitat Python et des outils non-Python (tels que Google Earth) sont compatibles avec le nouveau système. pourrait être développé sur des travaux la plupart du temps hors de la boîte.

Answer 1

Je ne peux pas parler pour chaque configuration d'acquisition de données, mais la plupart d'entre eux passent la plupart de leurs "opérations en temps réel". attendre que les données arrivent - du moins celles sur lesquelles j'ai travaillé.

Ensuite, lorsque les données entrent, vous devez immédiatement enregistrer l'événement ou y répondre, puis le jeu en attente est réactivé. C'est généralement la partie la plus critique d'un système d'acquisition de données. Pour cette raison, je dirais généralement que coller avec C pour les parties d'entrée / sortie de l'acquisition de données, mais il n'y a pas de raison particulièrement convaincante de ne pas utiliser Python sur les parties non critiques. .

Si vous avez des exigences assez lâches (une précision à la milliseconde peut-être, par exemple), cela ajoute encore plus de poids à tout faire en Python. En ce qui concerne le temps de développement, si vous êtes déjà à l'aise avec Python, vous auriez probablement un produit fini beaucoup plus tôt si vous deviez tout faire en Python et le refactoriser uniquement lorsque des goulots d'étranglement apparaissent. Faire le gros de votre travail dans Python facilitera également le test approfondi de votre code. En règle générale, il y aura moins de lignes de code et donc moins de place pour les bogues.

Si vous avez besoin de créer plusieurs tâches (et non plusieurs threads ), Stackless Python pourrait également être bénéfique. C'est comme le multi-threading, mais les threads (ou les tasklets, dans Stackless Lingo) ne sont pas des threads au niveau du système d'exploitation, mais au niveau de Python / application, de sorte que la surcharge de basculer entre les tasklets est significative. réduit. Vous pouvez configurer Stackless pour effectuer plusieurs tâches de manière coopérative ou préventive. L'inconvénient majeur est que le blocage des E / S bloquera généralement l'ensemble de vos tasklets. Quoi qu'il en soit, étant donné que QNX est déjà un système temps réel, il est difficile de penser si Stackless vaudrait la peine d'être utilisé.

Mon vote serait de suivre la voie la plus réaliste possible - je considère cela comme un faible coût et des avantages considérables. Si et quand vous avez besoin de réécrire en C, vous aurez déjà du code fonctionnel pour commencer.

Answer 2

J'ai construit plusieurs systèmes tout temps Python tout en douceur, avec des temps de cycle primaires de 1 ms à 1 seconde. J'ai appris certaines stratégies et tactiques de base en cours de route:

1. Utilisez uniquement le threading / le multitraitement pour décharger le travail non RT du thread principal, où les files d'attente entre les threads sont acceptables et le threading coopératif est possible (pas de préemptif discussions!).

2. Évitez le GIL. Ce qui signifie fondamentalement non seulement éviter les threads, mais aussi autant que possible les appels système, en particulier lors d'opérations critiques, à moins qu'elles ne soient pas bloquantes.

3. Utilisez les modules C lorsque cela est pratique. Les choses (généralement) vont plus vite avec C! Mais surtout si vous n’avez pas à écrire le vôtre: restez en Python à moins qu’il n’y ait pas d’alternative. L’optimisation des performances des modules C est un PITA, en particulier lorsque la traduction sur l’interface Python-C devient la partie la plus chère du code.

4. Utilisez les accélérateurs Python pour accélérer votre code. Mon premier projet RT Python a grandement profité de Psyco (oui, je le fais depuis un moment). PyPy est une des raisons pour lesquelles je reste avec Python 2.x: les choses toujours vont plus vite avec LLVM!

5. N'ayez pas peur d'attendre, attendez lorsqu'un moment critique est nécessaire. Utilisez time.sleep () pour vous faufiler à l'heure désirée, puis attendez-vous pendant les dernières 10 ms. J'ai pu obtenir des performances répétables avec un auto-chronométrage de l'ordre de 10 microsecondes. Assurez-vous que votre tâche Python est exécutée avec la priorité maximale du système d'exploitation.

6. Numpy ROCKS! Si vous effectuez des analyses «en direct» ou des tonnes de statistiques, il existe un NON moyen de faire davantage de travail plus rapidement et avec moins de travail (moins de code, moins de bugs) qu'avec Numpy. Pas dans d'autres langages que je connaisse, y compris C / C ++. Si la majorité de votre code consiste en des appels Numpy, vous serez très, très rapide. J'ai hâte que le port Numpy à PyPy soit terminé!

7. Sachez quand et comment Python effectue le garbage collection. Surveillez votre utilisation de la mémoire et forcez le GC si nécessaire. Assurez-vous de désactiver explicitement le CPG pendant les opérations critiques. Tous mes systèmes RT Python fonctionnent en permanence et Python adore exploiter sa mémoire. Un codage soigneux peut éliminer presque toute allocation de mémoire dynamique, auquel cas vous pouvez complètement désactiver le GC!

8. Essayez d’effectuer le traitement par lots autant que possible. Au lieu de traiter les données au débit d'entrée, essayez de traiter les données au débit de sortie, ce qui est souvent beaucoup plus lent. Le traitement par lots facilite également la collecte de statistiques de niveau supérieur.

9. Ai-je mentionné l'utilisation de PyPy? Eh bien, il vaut la peine de le mentionner deux fois.

L’utilisation de Python pour le développement RT présente de nombreux autres avantages. Par exemple, même si vous êtes à peu près certain que votre langue cible ne peut pas être Python, le développement et le débogage d'un prototype en Python peut s'avérer très avantageux, puis utilisez-le à la fois comme modèle et comme outil de test pour le système final. J'avais utilisé Python pour créer des prototypes rapides des "pièces dures". d'un système pendant des années, et pour créer des interfaces graphiques de test quick'n'dirty. C'est ainsi que mon premier système RT Python est né: le prototype (+ Psyco) était assez rapide, même avec l'interface graphique de test en cours d'exécution!

-BobC

Modifier: j'ai oublié de mentionner les avantages multiplates-formes: mon code est utilisé presque partout avec a) aucune recompilation (ou dépendances du compilateur, ou besoin de compilateurs croisés), et b) presque aucun code dépendant de la plate-forme (principalement pour diverses choses comme la gestion de fichiers et les entrées / sorties série). Je peux développer sur Win7-x86 et déployer sur Linux-ARM (ou tout autre système d'exploitation POSIX, tous dotés de Python de nos jours). PyPy est principalement composé de x86 pour le moment, mais le portage ARM évolue à un rythme incroyable.

Answer 3

Généralement, la raison avancée contre l'utilisation d'un langage de haut niveau dans un contexte en temps réel est incertitude - lorsque vous exécutez une routine une fois, cela peut prendre 100us; la prochaine fois que vous exécuterez la même routine, il pourra décider d'étendre une table de hachage en appelant malloc, puis Malloc demandera au noyau plus de mémoire, ce qui pourrait éviter de revenir instantanément en millisecondes plus tard en secondes . plus tard à l'erreur, dont aucune n'est immédiatement visible (ou contrôlable) à partir du code. Alors que théoriquement, si vous écrivez en C (ou même plus bas), vous pouvez prouver que vos chemins critiques resteront "toujours" (sauf grève de météores) courir dans le temps X.

Answer 4

Notre équipe a effectué des travaux en combinant plusieurs langues sur QNX et a rencontré un vif succès avec cette approche. L'utilisation de python peut avoir un impact important sur la productivité et des outils tels que SWIG et des types de code facilitent l'optimisation du code. et combinez les fonctionnalités des différentes langues.

Cependant, si vous écrivez quelque chose de critique du point de vue temporel, cela devrait presque certainement être écrit en c. Cela signifie que vous évitez les coûts implicites d'une langue interprétée telle que la GIL ( Verrou d'interprète global ). et conflit sur de nombreuses allocations de mémoire de petite taille. Ces deux éléments peuvent avoir un impact important sur les performances de votre application.

Python sur QNX a également tendance à ne pas être compatible à 100% avec d’autres distributions (c’est-à-dire / il manque parfois des modules).

Answer 5

Remarque importante: Python pour QNX est généralement disponible uniquement pour x86.

Je suis sûr que vous pouvez le compiler pour ppc et autres arcs, mais cela ne fonctionnera pas immédiatement.