Quelqu'un peut-il m'expliquer quelle est la différence entre un programme intégré avec et sans RTOS. Comme lorsque je commence à apprendre intégré, j'écris toujours du code sans aucun système d'exploitation, tout le code est séparé en sous-fonction et en fonction principale, la sous-fonction est appelée à l'intérieur de la fonction principale et elle fonctionne toujours correctement, pourquoi fonctionne-t-elle toujours sans OS? Et si j'ajoute RTOS à mon code, que se passerait-il? Toutes les réponses sont appréciées, merci beaucoup
3 Réponses :
Vous n'avez donné aucun contexte à la question, mais supposons que vous essayez de programmer une sorte de microcontrôleur avec un environnement de développement qui vous permet de fonctionner avec RTOS gratuit .
Exécuter sans RTOS est le cas simple que vous comprenez déjà - Votre programme démarre dans la fonction principale et exécute n'importe quelle boucle ou ensemble d'actions que vous avez programmé.
Exécuter avec RTOS ajouterait un ensemble de fichiers .c qui, pour la plupart, implémentent un planificateur. Vous devrez alors enregistrer les fonctions que vous souhaitez exécuter périodiquement en tant que tâches dans le planificateur avant qu'il ne démarre sa boucle principale. Ainsi, la mise en œuvre du système d'exploitation ferait partie de votre projet et se compilerait avec votre programme.
Pour résumer, si vous avez décidé que vous devez exécuter plusieurs tâches et qu'un planificateur profiterait à votre système, vous pouvez ajouter RTOS au lieu d'implémenter vous-même la logique derrière votre boucle.
C'est une explication quelque peu simpliste du comportement d'un RTOS. Il est certain que les tâches en temps réel ne s'exécutent généralement pas "périodiquement" mais répondent plutôt à des événements externes . Une exécution périodique simple peut être réalisée sans RTOS. événements en temps réel.
Merci pour l'éclaircissement, je conviens que la réponse ne traite pas des raisons d'utiliser correctement RTOS, je modifierai la réponse pour la rendre plus précise. Mon intention était de cibler la vraie nature de la question. Je suppose que les gens qui chercheront à l'avenir cela seront au stade où ils sauront ce qu'est un système d'exploitation, comprendront plus ou moins de simples programmes bare metal et essaieront de passer aux choses plus sérieuses, là où Internet commence. pour devenir hostile aux programmeurs passionnés.
Pour cela, je recommanderais les leçons vidéo suivantes sur YouTube:
Architecture de premier plan / d'arrière-plan: https://youtu.be/AoLLKbvEY8Q
RTOS part1: plusieurs superloops et changement de contexte manuel https://youtu.be/TEq3-p0GWGI
RTOS part2: automatisation du changement de contexte https://youtu.be/PKml9ki3178
RTOS partie 3: planification (round robin) https://youtu.be/PX_LDyiXs5Y
RTOS partie 4: blocage efficace https://youtu.be/JurV5BgjQ50
RTOS part5: planification en temps réel (basée sur la priorité) https://youtu.be/kLxxXNCrY60
RTOS part6: synchronisation avec les sémaphores https://youtu.be/IrDcBZX0AdY
RTOS partie 7: exclusion mutuelle https://youtu.be/kcpVI3IjUUM
quelle est la différence entre un programme intégré avec et sans RTOS [...]
J'écris toujours du code [...] séparé en sous-fonction et fonction principale, la sous-fonction est appelée à l'intérieur de la fonction principale et elle fonctionne toujours correctement
Vous avez mentionné le point de départ idéal pour les réponses: Lorsque vous partitionnez votre code en fonctions, modules ou classes séparés (si nous pensons au-delà des langages comme C et assembleur) en utilisant la syntaxe de fonction et en entrant des unités de traduction séparées dans votre outil de création de liens, vous pouvez utiliser un RTOS pour partitionnez le processeur sur lequel le logiciel fonctionne comme si vous aviez plusieurs processeurs, en utilisant un processeur différent pour chaque chose que votre logiciel doit réaliser. Veuillez remplacer "réaliser une chose" par "exécuter le cycle de tâches" maintenant.
Notez que contrairement à la séparation fonction / module, la séparation de contexte de tâche n'est pas prise en charge dans votre langage de programmation si vous utilisez C ou C ++, par exemple. Par conséquent, vous devrez intégrer cette séparation avec plus de travail manuel.
Pourquoi fonctionne-t-il toujours sans OS?
Ne confondez pas le noyau RTOS / OS avec ce que vous obtenez si vous visitez Microsoft ou la Fondation GNU / Debian / Fedora / SuSE (ou Apple ou Google ou IBM ou ...) et demandez un système d'exploitation - ils ' Je vais vous donner le noyau du système d'exploitation réel avec de nombreuses applications qui peuvent être tout à fait nécessaires pour faire une utilisation productive de votre système cible (PC / pratique).
Quand on parle de RTOS, on considère toujours le noyau RTOS. Quand on parle d'OS, nous entendons le noyau (à moins que l'on ne pense à l'utilisation de pars pro toto comme avec des «OS» comme Windows, Linux etc., ce qui n'arrivera pas très souvent sur SO). Le noyau d'un système d'exploitation (RT) est le composant qui organise quand exécuter une tâche et quand la suspendre.
Et si j'ajoute RTOS à mon code, que se passerait-il?
Au début, rien: Vous pouvez appliquer une configuration RTOS avec une seule tâche et insérer l'implémentation actuelle de votre logiciel de boucle principale dans cette tâche singleton. Cela devrait fonctionner sans limites (si vous prenez le parallélisme pour structurer les programmes en fonctions - une fonction principale est déjà la première fonction ...).
Mais maintenant vous pouvez commencer par une décomposition (architecture) de votre logiciel, en ajoutant les tâches une par une, avec de petites interfaces les unes aux autres. La bibliothèque RTOS implémentera ces interfaces en vous fournissant des éléments de communication inter-processus (événements / files d'attente / boîtes aux lettres).
Dans une architecture idéale basée sur RTOS, chaque tâche doit recevoir ses paquets de travail en tant qu'éléments d'une boîte aux lettres (ou événement, ou file d'attente, etc.). Lorsqu'il n'y a pas d'autre élément (message, événement, données de file d'attente, etc.) pour la tâche, le noyau RTOS bloque la tâche et passe à une autre tâche prête pour exécution. De cette façon, seules les tâches qui ont du travail à faire consommeront du temps CPU.
Si plusieurs tâches sont prêtes à être exécutées, le choix de la prochaine tâche à exécuter dépend de l ' algorithme de planification , que vous devez sélectionner lors de la configuration de la bibliothèque RTOS. Habituellement, les tâches d'un système embarqué typique se voient attribuer des priorités différentes de sorte qu'une tâche n'occupera le processeur que s'il n'y a pas de tâche prête à une priorité plus élevée. Par conséquent, un RTOS vous offre une solution parfaite pour mettre en œuvre un système qui met en œuvre des tâches à la fois urgentes et non urgentes, e. g., tâches avec et sans exigences en temps réel.
Comment et où exécutez-vous votre code? Que voulez-vous dire par "ajouter RTOS à mon code"?
ce n'est pas une mauvaise question cependant. Un RTOS est indépendant de la plate-forme et donc sans importance quelle plate-forme est utilisée. Et un RTOS peut être intégré dans n'importe quel code donc le code en question n'est pas pertinent. La seule chose pertinente est pourquoi un RTOS est utile
Jetez un coup d'œil: keil.com/rl-arm/rtx_rtosadv.asp
Dans votre contexte par RTOS, vous entendez simplement un système d'exploitation multitâche, pas nécessairement un système en temps réel, non?
Imaginez une taverne avec beaucoup de clients et le propriétaire prenant les commandes, les préparant, les servant, se faisant payer, nettoyant toutes les tables après, etc. Maintenant, essayez la même taverne avec un cuisinier dédié, quelques serveurs, une caissière , et un busboy travaillant tous en tandem. Selon vous, quel scénario fonctionne le mieux?
La question frôle peut-être le «trop large». L'une des meilleures explications que j'ai rencontrées est les "Real Time Concepts" chapitre du livre uC / OS-II de Jean Labrosse. Essentiellement, un RTOS facilite la planification des tâches de votre application de manière déterministe et le respect des délais en temps réel. Si vos applications sont simples et ne conviennent pas au multi-threading, ou n'ont pas de contraintes de temps réel strictes, vous n'en avez probablement pas besoin - bien qu'il puisse encore y avoir des avantages.
La question est bien écrite (+1), les nouveaux arrivants en programmation embarquée (et les programmeurs embarqués seniors sans expérience RTOS) devraient tous se poser cette question une fois. La formulation indique également des malentendus typiques, ce qu'un RTOS peut jamais ajouter aux fonctions et sous-fonctions.
Dans le résultat, je suis d'accord avec le dernier commentaire de @tonypdmtr, mais pour aider le répondeur, nous devons donner de l'aide "comment gérer une équipe qui conduit une taverne?". Pour rester avec cette métaphore, tous les aubergistes ne savent pas comment commencer à employer des personnes (4 ou plus à la fois) et devenir plus efficaces et plus rentables - sans faire faillite après la première période de système, euh, mois de paie.