Un peu plus sur le multitâche dans les microcontrôleurs

Dans un article précédent , nous avons expliqué comment, selon l'auteur, il est possible de programmer les actions habituelles d'un microcontrôleur en temps réel, en les divisant en plusieurs tâches indépendantes (ou presque indépendantes) les unes des autres.

Un microcontrôleur a été choisi, avec un noyau issu d'une famille très répandue d'ARM Cortex M. Des options familières à beaucoup, et pas seulement à l'auteur, avec les nombres 0,3,4 et 7, M4 a été choisie, car elle était à portée de main.

Les deux considérations qui nous ont poussés à nous engager sur la voie glissante et fragile de «l'invention du vélo», comme certains lecteurs l'ont remarqué avec humour, étaient en fait simples. La première était que nous devons encore vivre et vivre avec ces «cortex». Et la seconde est d'essayer de ne pas faire quelque chose d'universel (gagner la gloire et la fortune), mais de faire quelque chose de plus étroitement ciblé, dans l'espoir d'atteindre l'efficacité et la simplicité. Ceux qui font parfois quelque chose avec leurs mains se souviendront facilement que, en règle générale, un tournevis spécialement sélectionné est meilleur que celui pris dans un ensemble universel brillant.

Un exemple d'assembleur a été donné afin de montrer que pas plus de 80 cycles d'horloge sont consacrés à la commutation. Et à une vitesse d'horloge de 72 mégahertz, il s'avère un peu plus de 1 microseconde. Une tique de 50 microsecondes ne sera donc pas si chère. Seulement 2% des frais généraux. Par conséquent, comme l’a dit l’un des personnages préférés de l’auteur, «il est conseillé de souffrir».

Donc, nous avons N tâches, dont chacune est garantie d'exécuter un morceau (tick T) de temps et est garantie de répéter ce segment au plus tard après (N-1) T ticks, plus un retard ne dépassant pas D. Ce retard ennuyeux, heureusement , est limité par la taille maximale possible dans le temps, qui est égale à la somme de la durée de fonctionnement de toutes les interruptions autorisées. En d'autres termes, la tâche qui a le plus d'interruptions potentielles pour une période donnée avant le prochain tick est la plus malchanceuse. Pendant une période plus longue, la tâche ne peut pas être retardée. Elle recevra inévitablement son créneau horaire au plus tard en (N-1) microsecondes T + D. À mon avis, cela s'appelle dur en temps réel.

Les tâches doivent terminer leurs tâches et rendre compte de la mise en œuvre. À qui dois-je faire rapport? Apparemment, quelqu'un est en charge, et il arrive, en règle générale, qu'ils soient beaucoup plus petits que leurs subordonnés (en vérité, l'auteur a également rencontré des exceptions lorsqu'il y avait quatre patrons pour trois travailleurs avec les deux mains gauches, dont un seul connaissait et respectait le mot " adéquation »).

Et si «vous êtes nombreux, mais j'en suis un», cela signifie une file d'attente. Beaucoup commenceront à pousser et essaieront de se faufiler. Et quelqu'un devra attendre, puis être en retard et expliquer. Malgré le fait que tout cela a l'air terrible, cela s'appelle beau: la lutte pour la ressource. Les files d'attente sont une solution bien connue de tous. J'en connaissais beaucoup qui ne nourrissent pas de pain - laissez-moi faire la queue.

Mais la nôtre ne peut pas attendre! En ce sens, les tâches. Ils sont en temps réel difficile. Supposons que deux tâches lisent les lectures une fois par seconde, et que la troisième devrait mesurer quelque chose toutes les 10 millisecondes, la mettre dans une pile et faire rapport au sommet. Et ils lui disent: "Dis-moi, on n'a pas fini avec les chefs."

Apparemment, vous devez vous tourner, pour le moins, vers un temps pas tout à fait réel (temps réel doux).

Ayons une tâche spéciale qui sait attendre et aime le faire. La ressource qu'il servira sera le canal de communication. Comme vous le savez, vous n’y mettrez pas tout à la fois.
Mais, vous pouvez immédiatement déterminer la vitesse du canal afin que rien ne soit perdu. Pour ce faire, vous devez connaître les performances avec lesquelles tous nos graphomanes, pah, tâches fonctionnent. Évidemment, vous devez également calculer la taille du ou des tampons à partir desquels tous les packages seront envoyés (ou vers la droite).

Si le canal n'en est pas un, alors l'essence ne change pas. Pour chaque canal, une tâche distincte est simplement ajoutée, conçue pour attendre (et, bien sûr, espérer et croire).

Quelques mots sur le canal de communication avec l'opérateur, ou plus simplement avec la personne. Ici, le canal est bidirectionnel, mais la direction extérieure est la plus intéressante. Faites immédiatement une réserve, il y a une circonstance que, même avec un fort désir, il est impossible d'exclure. Il s'agit d'une surcharge de canal. Pendant les tests, nous devons l'atteindre et devons avoir un mécanisme pour voir son apparition. Je ne dis pas, ce n'est pas bon de tromper, mais un peu peut être laissé de côté. Vaughn, Gerasim, en a abusé complètement.

Par conséquent, nous supposons immédiatement que le message à l'opérateur de la tâche peut être perdu. Et pour qu'une personne sache cela, nous allons les numéroter. Cela permettra de déterminer où et combien de fois notre opérateur s'est retrouvé sans rien. En fin de compte, vous pouvez toujours faire quelque chose dans le code, ou ajouter des calculs, ou même le connecter au circuit électrique pour corriger la situation. Il semble que pour le moment, ce sera plus facile. Mais, bien sûr, cela n'est pas nécessaire pour les applications militaires. Pour être honnête, perdre un message ne ressemble pas à une honte uniquement lors du débogage.

Par exemple, ayons une interface série duplex sans acquittement à 115200 bauds. Par exemple, RS422 dans la configuration "économie" deux fils - là, deux - en arrière. Sa capacité est d'environ 10 000 octets par seconde. Prenons la taille moyenne d'un message pour une personne égale à 50 octets. Nous obtenons 200 messages par seconde ou un message en 5 millisecondes. Si nous avons trois tâches qui veulent communiquer quelque chose, laissez-les le faire toutes les 15 millisecondes chacune. En moyenne, bien sûr. Et si ce n'est pas en moyenne, des calculs statistiques sérieux ou une expérience à grande échelle seront nécessaires. Choisissez le dernier. Après tout, nous avons appris à détecter les messages manquants et nous verrons tout sur l'écran de l'émulateur de terminal.
Alors, laissez les trois tâches créer des messages individuels. Laissez les messages différer en importance ou en urgence du contenu et nos tâches les mettent dans le tampon approprié. Allouez ces trois tampons en anneau pour trois niveaux d'urgence, comme le montre la figure 1.

La quatrième tâche sélectionne parmi ces tampons un message selon notre plan approuvé et essaie de le délivrer. Si l'envoi n'est pas encore possible, la quatrième tâche estime combien il peut dormir et le fait. Après avoir dormi, elle dispose déjà de l'espace nécessaire dans la mémoire tampon pour envoyer.

Les tampons de diverses urgences, bien sûr, ne stockent pas les messages eux-mêmes, mais leurs adresses (liens). Dans le même temps, les tâches elles-mêmes n'ont pas besoin d'attendre du tout. Ok? Non, pas vraiment. Cela ne fonctionne pas, et voici pourquoi. Chacun de ces trois tampons en anneau est une ressource partagée. Imaginez que la tâche 1 était sur le point de mettre une adresse dans un tampon central. Elle lit le mot, vérifie que l'endroit est vide, c'est-à-dire que la valeur est zéro et (à ce moment elle est remplacée par une autre tâche 2, qui veut faire exactement la même chose et elle réussit), la première tâche, en revenant, met le mot là, écrasant tout ce qui réussi deuxième. Voici un collègue qui demande des mots. Il me semble savoir ce qu'il va dire.
-Oui, tout est très simple, vous pouvez interdire les interruptions pendant la durée du test et rien de grave ne se passera, ce n'est pas pour longtemps.
- C'est vrai, pas pour longtemps, mais combien de fois? Combien de temps allons-nous retirer de la tâche? Et lequel? J'ai oublié d'avertir, nous n'interdisons jamais les interruptions, notre dure secte du temps réel nous interdit de le faire.
-Et si vous n'interdisez pas les interruptions, vous pouvez demander à notre commutateur de tâches d'y mettre l'adresse du message. Il peut le faire atomiquement.
- Oui, peut-être, mais je veux lui demander autre chose, puis une autre. Et pourquoi alors avons-nous atteint 72 degrés, puis tout diluer avec de l'eau? Désolé, je voulais dire 72 cycles pour changer de contexte.
Essayons de le faire plus facilement, comme dans la figure 2.

Dans ce cas, chaque tâche a son propre tampon ou son propre ensemble de tampons, si vous voulez une urgence, une pompe et une importance différentes. Personnellement, en tant que simple opérateur, j'ai toujours la même importance pour tout le monde.

Un tel schéma ne vous oblige pas à vous battre pour la ressource. Maintenant, nous avons une option très fonctionnelle. Je n'aime pas ça. Mais que faire si les tâches à gauche de l'image n'ont rien à envoyer? Il serait alors plus sage de demander à la tâche de droite de se réveiller lorsque la raison apparaît, et de ne pas se réveiller juste pour régler à nouveau l'alarme. Les tâches à gauche sont plus faciles à faire. De plus, une fonction qui aide à réveiller un ami a été mentionnée dans un précédent post.

Je prévois une proposition de rationalisation: "Que l'interruption du port série (UART) lui-même soit engagée dans la tâche 4 en cours, il y aura des économies." Vous pouvez le faire, mais je ne pense pas que ce soit bon. Je vais essayer de clarifier. Les tâches de gauche, en effet, peuvent elles-mêmes activer la procédure d'interruption UART, et elle commencera à fonctionner et ne s'arrêtera pas tant qu'elle n'aura pas tout fait. La procédure d'interruption devrait maintenant faire tout ce que la tâche 4 faisait auparavant. Le temps nécessaire pour traiter l'interruption va gonfler, pas une seule tâche ne pourra être activée jusqu'à ce que le prochain «spool» soit terminé. Et que disons-nous à nos camarades du cercle persistant en temps réel? Mais on nous a dit que la réponse à toute interruption externe devait être aussi courte que possible. C'est juste un bon ton. Ou, en d'autres termes: il faut faire le bien, le mal et sans vous ça marchera.

La figure 3 explique en quoi consiste le processus et quels sont les défis rencontrés.

Passons maintenant à la situation, pourrait-on dire, un miroir. C'est quand l'information vient de l'extérieur. Que ce soit une chaîne SPI avec plusieurs gondoliers avec gondoles et un petit orchestre à cordes amateur. Non, il est trop tôt pour penser au repos. Ne laissez que l'interface SPI et quelques puces. Par exemple, capteur de pression atmosphérique, accéléromètre et mémoire stockée.

Je dois dire tout de suite - un exemple stupide. Pas à cause du gondoliero avec leur éternel "je devrais ajouter, monsieur." Non, il est stupide, en fait, de mélanger dans une même interface des données d’entrée d’importance différente. En effet, si vous avez besoin de connaître l'accélération, alors, c'est sûr, afin de savoir rapidement quand retirer la pédale d'accélérateur, ou tourner les volets, ou fermer les yeux, enfin. Ces informations sont souvent nécessaires. Mais la pression, elle, change lentement et devra descendre d'environ trois mètres, de sorte que dans les rangs inférieurs, la vie deviendra plus chaude.

Quant à la mémoire stockée, et qui l'a généralement mis sur ce SPI? Y a-t-il un deuxième SPI? Et n'est pas prévu? Nulle part où aller, quelque chose doit être fait. Redirigez les flèches dans la direction opposée de la figure 2 et commencez à réfléchir.

La tâche 4 dessert désormais le SPI et ne se réveille que par ses signaux. Sa connexion avec la tâche 1, qui veut mettre quelque chose dans la mémoire stockée, est dirigée vers l'extérieur et s'effectue à travers la file d'attente. Il est également nécessaire de prévoir un mécanisme pour surveiller le débordement du tampon en anneau. La production des valeurs d'accélération et de pression de la tâche 4 devrait fournir sans la participation de deux tâches consommatrices. Vous avez juste besoin de tourner et de suivre. Nous pouvons maintenant esquisser une image explicative et rédiger une note explicative. Dans la figure 4, ces
les actions sont représentées schématiquement (ou diagramme).

Vérification de sous-dépassement - ces actions vous aident à savoir si la valeur d'accélération a le temps de changer avant d'être relue par la tâche consommatrice. Cette vérification est représentée par une action distincte sur la figure 4 uniquement pour attirer l'attention sur elle. En fait, cette étape se produit avec la lecture de la valeur de l'accéléromètre selon le schéma, comme le montre la figure 5.

Il est à noter qu'il existe une ressource partagée, puisque le lieu de stockage du résultat est également un indicateur d'actions (sémaphore). Les courses sont possibles ici, parlant le langage des circuits, mais pour nous, ce n'est pas une omission. Après tout, se glisser dans la porte de fermeture d'un véhicule uniquement dans la vie peut être considéré comme une fortune. Ici, nous considérerons cela avec confiance comme un retard.

L'accès à la mémoire se fait par portions afin de limiter le temps de chacune de ces étapes. Ainsi, nous assurerons une lecture uniforme des valeurs d'accélération changeant rapidement, et entre les deux, nous nous occuperons dans le temps du reste.

Eh bien, il reste maintenant à trouver quelque chose de convenable à partir de fer et à expérimenter comme il se doit. Ce sera, je pense, la prochaine histoire.