Quelle est la différence entre RTOS et Linux embarqué?
RTOS et Linux embarqué sont utilisés pour la programmation de systèmes embarqués. Est-ce que Linux embarqué lui-même est un RTOS? Quelqu'un peut-il énumérer la comparaison ou la différence s'il vous plaît?
Linux est un système d'exploitation polyvalent (GPOS); son application aux systèmes embarqués est généralement motivée par la disponibilité de la prise en charge des périphériques, des systèmes de fichiers, de la connectivité réseau et de la prise en charge de l'interface utilisateur. Toutes ces choses peuvent être disponibles dans un RTOS, mais souvent avec un support moins large, ou à un coût supplémentaire ou à un effort d'intégration.
De nombreux RTOS ne sont pas des systèmes d'exploitation complets dans le sens où Linux l'est, en ce sens qu'ils comprennent une bibliothèque de liens statiques fournissant uniquement la planification des tâches, l'IPC, la synchronisation et les services d'interruption et peu plus - essentiellement la planification noyau uniquement. Une telle bibliothèque est liée à votre code d'application pour produire un seul exécutable que votre système démarre directement (ou via un chargeur de démarrage). La plupart RTOS ne prennent pas directement en charge le chargement et le déchargement du code dynamiquement à partir d'un système de fichiers comme vous le feriez avec Linux - tout est là au démarrage et fonctionne jusqu'à la mise hors tension.
Critiquement, Linux n'est pas capable en temps réel. Un RTOS fournit des garanties de planification pour assurer un comportement déterministe et des événements de réponse et des interruptions en temps opportun. Dans la plupart des cas, cela se fait par le biais d'un algorithme de planification préventive basé sur la priorité, où la tâche de priorité la plus élevée prête à s'exécuter s'exécute toujours - immédiatement - préemption de toute tâche de priorité inférieure sans rendement spécifique ni abandon du processeur, ni achèvement d'une tranche de temps.
Linux a un certain nombre d'options de planification, y compris un planificateur en temps réel, mais c'est au mieux "doux" en temps réel - un terme que je n'aime pas car il est mal défini, et signifie essentiellement en temps réel, la plupart du temps, mais parfois non. Si votre application n'a pas besoin de temps réel "dur", c'est bien, mais les latences typiques dans Linux en temps réel seront de l'ordre de dizaines ou centaines de microsecondes, alors qu'un RTOS le noyau en temps réel peut atteindre des latences de zéro à quelques microsecondes.
Un autre problème avec Linux embarqué est qu'il a besoin de ressources CPU importantes, peut-être> 200MIPS, processeur 32 bits, idéalement avec une MMU, 4 Mo de ROM et 16 Mo de RAM à peu près au démarrage (ce qui peut prendre plusieurs secondes). Un RTOS d'autre part peut être en place en millisecondes, exécuté en moins de 10 Ko, sur des microcontrôleurs à partir de 8 bits. Cela peut avoir un impact significatif sur le coût du système pour la production en volume bien qu'il soit ostensiblement "gratuit".
Il existe de plus grands produits RTOS qui présentent certaines des fonctionnalités d'un GPOS tels que le chargement dynamique, les systèmes de fichiers, la mise en réseau, l'interface graphique (par exemple, dans QNX), et de nombreux RTOS fournit une API POSIX (généralement secondaire à leur API native en temps réel), par exemple VxWorks et encore QNX, de sorte qu'un grand nombre de code développé pour Linux et Unix peut être porté relativement facilement. Ces plus grands plus complets RTOS restent évolutifs, de sorte qu'aucune fonctionnalité non requise n'est incluse. Linux en comparaison a une évolutivité beaucoup plus limitée.