Débuter avec Arduino etc : Interruptions et variables partagées - Utiliser volatile, cli, sei, SREG

[@youssefbenmouhou9030]

Merci beaucoup professeur Eric Je vous suis du Maroc, vous êtes le meilleur professeur qu'on puisse trouver sur youtube, il y a toujours quelque chose de nouveau et d'intéressant à apprendre, J'envie vos élèves.

[@fabiendel8367]

Bonsoir. Merci beaucoup pour tout ce que vous faites. J'aurai vraiment aimé faire parti de vos élèves, vous êtes super! N'arrêtez pas vos vidéos car j'apprends énormément avec vous ;)

[@jrioublanc]

Merci, j'apprécie beaucoup le mélange entre l'aspect programmation et l'aspect exécution. Cela permet d'avoir du code robuste, optimisé et adapté aux besoins.

[@jfmahe1407]

Une explication claire de volatile. Merci Eric.

[@EricPeronnin]

A ceci près que j'aurais du être insistant aussi sur la nécessité de sauvegarder immédiatement après les calculs faits sur la variable en question.

[@rdson1621]

C'est un pouce doré qu'il aurait fallut! C'est un des sujets qui font la différence du codeur compétant.

[@EricPeronnin]

Merci.

[@pplemoko5342]

Merci pour ces compléments très pertinents. J'avoue que même si la question de la coïncidence des interruptions avec des instructions m'avait traversé l'esprit, je n'avais pas les éléments de compréhension et de subtilité qui permettent de régler cela dans un programme. Lacune réparée, encore merci de nous permettre d'aller au fond des choses.

[@sylvainmasson4457]

Un complément très claires. Merci encore Eric.

[@stephaneshm3043]

tres bonne idée de sauvegarder SREG, merci pour cette info

[@mikl5228]

merci !!!! c'est super intelligent ca ! ca va améliorer la qualité de mes programmes!

[@EricPeronnin]

Merci Michaël.

[@mictu7509]

Bravo pour votre travail.

[@gizyfr]

Magnifique présentation. Et belle rigueur qui permet de comprendre les phénomènes transitoires qui auraient pu se produire lors de l'accès à une variable dans le prog principal, écrite dans le prog d'interruption :D

[@alainlaporte6824]

Bonsoir, j'attends toujours vos vidéos sur le monde Arduino avec impatience. J'y trouve un grand intérêt même si elles dépassent parfois mon niveau de compétence car je suis plus bidouilleur que programmeur. Je suis maintenant retraité et je me suis mis à l'Arduino depuis quelques mois et je trouve ces petits microcontrôleurs fantastiques! Merci pour ce que vous faites.

[@EricPeronnin]

L'intérêt de voir ces vidéos pour lesquelles vous vous sentez un peu dépassé, c'est que vous vous souviendrez les avoir vues 'au moment où vous rencontrerez la difficulté qu'elles évoquent et vous pourrez y retourner de façon beaucoup plus profitable à ce moment là.

[@antoinedevos3765]

Merci beaucoup pour ces explications car j'avais du mal avec les variables "volatile". Merci pour ces explications bienvenue et votre temps passé à concevoir une explications pour les nuls comme moi. Dans la vidéo, à 13'14'', il y a deux choses qui m'interpelle : - après le "uint8_t oldSREG = SREG;" il y a : "364: 8f b7 in r24, 0x3f ; 63 Question : à quoi sert le "in" ? - après le "SREG = oldSREG;" il y a : "378: 8f bf out 0x3f, r24 ; 63 Question : à quoi sert le "out" ? D'autre part, toujours un pouce bleu pour l'excellent professeur que vous êtes.

[@EricPeronnin]

SREG est un registre du microcontrôleur au même titre que les registres de périphérique. Ce n'est pas un registre au sens des registres du processeurs (R0 à R31 pour les AVR). Il se situe à l'adresse 0x3F dans la liste des registres de périphérique. Comme tous les registres de périphérique, son accès en lecture se fait un IN et son accès en écriture avec l'instruction OUT.

[@antoinedevos3765]

@@EricPeronnin Merci pour ce complément d'information si rapide.

[@Victurf]

Excellent!

[@jck7398]

Au delà de cet intéressant complément concernant les interruptions et après avoir saisi il y a quelques semaines l'intérêt des variables "static", je crois avoir bien mieux compris aujourd'hui la notion et l'utilité des variables "volatile". Jusqu'ici pour moi, variable était forcément synonyme de RAM.

[@EricPeronnin]

Les variables sont toujours dans la RAM (rectification, ce n'est pas systématique avec les variables locales non statiques qui peuvent être stockées dans un registre du uC) Si elles sont déclarées statiques, elles ne sont initialisées qu'au moment du premier passage sur la déclaration et conservent ensuite leur valeur. Si elles sont volatile, toute lecture de la variable implique une consultation de sa valeur dans la RAM; toute écriture implique une mise à jour immédiate dans la RAM. Quand elles ne sont ni statique, ni volatile, elles n'existent que là où elles sont créées et disparaissent lorsqu'on sort de la fonction où elles ont été créées.

[@jck7398]

@@EricPeronnin Merci de votre réponse. Je pense que je n'ai pas encore tout bien saisi ! j'ai cru comprendre que le compilateur, dans certains cas, pouvait "décider" de n'utiliser que des registres du µC. Je vais revoir tout ça à tête reposée !

[@EricPeronnin]

Et vous avez raison. Mea culpa. Pour les volatiles, c'est la RAM sans ambiguïté. Pour les variables locales à une fonction, non statiques, le compilateur peut se limiter à un registre. Exemple d'ailleurs montré dans la vidéo, sans le citer, avec oldSREG qui est stocké dans r24 seulement et pas en RAM. Le même programme recompilé avec oldSREG en statique implique une mémorisation dans la RAM.

[@jck7398]

@@EricPeronnin C'est bien ce que j'avais cru comprendre au vu de l'exemple "décompilé" que vous présentez et qui montre bien l'intérêt que peut avoir la curiosité bien placée !! Je ne m'y suis pas encore aventuré, mais je sens que ça ne va pas tarder, quand j'aurai regardé la vidéo dans laquelle vous traitez le sujet. Merci

[@fredfoka260]

😉😉😉😉😉😉😉c'est parfais, mais pas facile á comprendre du premier coup

[@jccr-mipmoi1599]

Bonjour, si j'ai bien compris lors de la copie de la variable les interruptions sont bloquées. Donc si il se produit une interruption à ce moment là elle ne sera pas prise en compte ?

[@EricPeronnin]

Bonjour. J'aurais du apporter la réponse à votre question. Les demandes d'IT restent en attente. Elles sont traitées dans leur ordre de priorité lorsqu'elles sont à nouveau autorisées. S'il y a plusieurs demandes sur un même source alors que les IT sont interdites, seule la première sera traitée au moment de la restitution de l'autorisation des IT. C'est bien pour cela qu'il faut limiter le temps de traitement dans une IT.

[@tanguymarion6368]

La qualité est toujours au rendez-vous ! Vaste sujet les interruptions, bientôt le sleep_mode ?

[@EricPeronnin]

Merci Tanguy. Le sleep_mode ? C'est justement l'objet des prochaines vidéos.

[@cedricserieys9768]

Bonsoir et merci pour la vidéo. J'ai une question à ce propos : Pendant la manœuvre cli/sei est-ce qu'il y a une mémorisation de la levée d'une éventuelle interruption qui permettrait APRES sei de déclencher ladite interruption ? En d'autre termes est-ce que cli masque les éventuelles levées de flags d'interruption ou est-que qu'il empêche seulement l'appel à la sous-routine (qui se déclencherait "automatiquement" sitôt le retour dans le contexte) ?

[@EricPeronnin]

Bonjour. Je n'en ai effectivement pas parlé. Une demande d'IT, c'est d'abord un indicateur qui est mis à 1 et qui le restera tant que l'utilisateur ne l'aura pas remis à 0 (en écrivant un 1 logique dessus) ou tant que le processeur ne l'aura pas traité : c'est à dire en lançant la fonction d'IT associée et en le remettant à 0. Donc toute demande qui se présente lorsque les IT ne sont pas autorisées sera traitée avec la priorité qui lui correspond au moment où les IT seront à nouveau autorisées.

[@elisonabraham8136]

Bonjour. Félicitations et merci votre disponibilité. Je me posais la question d 'une "imbrication multiple " de la même interruption, dans le cas ou son traitement est plus long que la durée entre 2 évènements déclencheurs. Est ce que (i) c'est gérer automatiquement par les PICS ou bien (ii) il faut le suivre/traiter avec une variable volatile spécifique ? merci beaucoup

[@richardt73]

Bonsoir Eric et merci Je suis dans le même cas qu'Alain Laporte et les pouces bleu sont bien insuffisants... J'ai réalisé quelques jolies réalisation que je partage et que j'améliore en suivant vos conseils éclairés. Je souhaitait faire une remarque constructive sur vos vidéos. En effet je rencontre régulièrement des problèmes de chronologie entre les différentes vidéos et de reconstitution des codes sources puisqu'ils peuvent évoluer souvent en fonction de la chronologie des vidéos. Sur KZbin elles sont datées, mais il manque les codes source et la pub pose un problème de concentration. Sur geii.eu il y a souvent les codes source, il n'y a pas de pub, la chronologie me semble compliquée puisque non datées et qu'il y manque beaucoup de vidéos. Ainsi il me parait utile de mettre les codes source sur KZbin dans la description qui éviteront bien de pause, retour sur image, saut de PUB ... pour reconstituer ce code. Encore un immense merci pour votre travail et vous encourage particulièrement au partage de connaissances.

[@EricPeronnin]

Bonsoir. La remarque est constructive et j'ai conscience de ça. Je tente depuis quelque temps de mettre à jour mon site geii.eu pour que toutes les vidéos y soient référencées et donner ainsi de la structure aux cours proposé. Malheureusement, je fais avec le temps que j'ai... C'est à dire pas suffisamment. A noter que les playlistes que je propose sur KZbin permettent de suivre l'ensemble des vidéos en respectant la bonne chronologie pédagogique. Elles constituent le point d'entrée à privilégier. Pour les sources, j'ajouterai les petits codes dans les zones de commentaires ou ajouterai tout simplement un lien vers les pages web respectives qui les hébergent.

[@richardt73]

@@EricPeronnin super merci Eric. Je suis sure qu'un simple copier coller devrait faire monter la chaine !

[@richardt73]

Par ailleurs je ne suis pas certain que votre intérêt financier soit d'emmener les gents de KZbin vers geii car la bas il n'y a pas de pousse bleu , pas de pub ni commentaires, qui sont pour le moment le seul moyen de développer votre chaine, en terme de visibilité et de revenu... En tout cas bon courage et quelque soit votre solution pour les codes source, l'effort serra apprécié.

[@richardt73]

Et re bonsoir, Il peut être bien utile de gérer un appuis long sur un BP de manière non brocante. Quelles serrait votre approche? Ceci complèterait bien le sujet non ?

[@EricPeronnin]

Semblable à l'anti-rebond en ajoutant un délai supplémentaire pour valider l'appui basé cette fois sur le front montant lié au relâchement du bouton poussoir. Cela suppose d'utiliser l'option BOTH de la mise en place des IT pour réagir à la fois aux fronts montants et descendants.

[@marcmandret5239]

Pourquoi ne pas faire un test sur SREG pour voir si les interruptions sont désactivées, et si oui copier simplement la valeur de la variable sans recours à sei() et cli()?

[@EricPeronnin]

On pourrait mais les interruptions sont toujours actives par défaut dans l'environnement Arduino puisque les valeurs de millis et micros sont comptabiliser par un timer traité par interruption.

[@richardt73]

Bonsoir Eric J'espère ne pas abuser de votre temps. Concernant les interruptions: En fonction de son utilisation, il pourrait être utile de reprendre le programme après l'interruption, non pas là où en était le programme avant l'interruption mais au début du loop. Est ce possible et si oui comment le mettre en œuvre? La mise a jour d'une variable lors de l'interruption puis vérifier cette variable après l'interruption et gérer l'histoire avec cette vielle commande goto? Ou un goto pendant l'interruption? Quelles sont les bonnes pratiques ? Je suis conscient que cela dépend du contexte.

[@EricPeronnin]

Bonjour Richard. Je ne vois pas trop l'intérêt que cela pourrait avoir étant donné que les interruptions se déclenchent à des moments non prévisibles. Pour un traitement particulier lié à une IT, il suffit de positionner un indicateur et de le tester dans la boucle principale du programme. Au delà de cette remarque, un tel comportement pauserait plusieurs problèmes. D'abord, on peut avoir interrompu un calcul. Le non achèvement du calcul amenant tôt ou tard à des erreurs imprévisibles. Ensuite, l'interruption pouvant se produire également lors d'appels de fonctions/méthodes imbriquées, l'état de la pile n'est pas connu et le risque de pertes de données et évident. Donc ce n'est pas prévu/possible et dangereux.

[@richardt73]

@@EricPeronnin Merci Eric. Il aurait fallu que je précise le contexte et effectivement j'ai fait les mêmes conclusions que vous sur cette méthode d'interruption. Alors je précise le contexte: J'ai réalisé un dataloger GPS qui enregistre sur carte SD un fichier csv et un fichier kml. Avant que l'utilisateur n' éteigne l'instrument, Je lui demande de faire un appuis long d'une seconde pour qu'il confirme qu'il veut bien arrêter l'appareil. A la suite de quoi j'écris les 3 dernières lignes qui clôtures le fichier kml et le rendent ainsi valide. Si l’appui sur le B.P. est accidentel et dure moins d'une seconde, les enregistrements continuent et le fichier serra clôturé plus tard. Entre temps une partie des variables déjà mis à jour ne sont plus valables et pour éviter d'enregistrer un point non valide, je souhaite reprendre le loop depuis le début sans enregistrement en perdant un point qui serrait certainement non valide. Ainsi positionner un indicateur et de le tester dans la boucle principale du programme ne résoudrait pas mon problème. Alors peut être que dans mon cas le déclenchement d'un reset lors de l'interruption serra préférable car j'ai déjà prévu un arrêt d'activité sur cet appareil, puis une reprise d'activité en le rallumant simplement.

[@richardt73]

Je viens de trouver ma solution en même temps que je validais mon message précédant. J'ai déjà prévu que le point ne soit pas enregistré si la vitesse est inférieur à un minimum paramétrable, pour éviter entre autre de cumuler des distances lors d'un arrêt à un feu rouge ou une courte pose. Lors de l'interruption je met la vitesse à 0, et je met en première ligne du loop la mise à jour de la variable vitesse.

[@danielroibert5631]

Bonjour, encore merci pour vos formidables vidéos. J’ai une petite suggestion au sujet du format du type int en C. Comme vous abordez des points importants sur l’intégrité des données, ne serait-il pas intéressent de dire un petit mot sur les formats des types int qui ne sont pas systématiquement les mêmes sur tous les compilateurs et toutes les plateformes ? Par exemple, le type int est stocké sur 32 bits sur un raspberry Pi et sur 8 bits sur mon compilateur préféré sur PIC (12F à 18F) :-) . En gros, il me semble qu’un programmeur devrait se documenter sur les formats des types en fonction de la plateforme et du compilateur avant de commencer à coder. (C’est un point important de la portabilités du C.) Encore merci. :-)

[@EricPeronnin]

Bonjour Daniel. Oui, ce serait pertinent. Il serait surtout pertinent de proscrire l'utilisation de ce type int au profit des types uint8_t, uint16_t ... ou encore u8, u16, u32... lorsqu'il existe de façon à savoir précisément ce qu'on manipule.