Interruptions avec bouton (Arduino)
Bonjour,
l'arduino quitte temporairement la fonction loop (peu importe l'endroit ou il en est) pour traiter ta fonction, puis revient dans loop pour reprendre exactement ou il s'était arrêté.
Si je veux que l'arduino exécute ma fonction d'interruption mais apr contre qu'il revient au début de la fonction main() je fais comment ?
Cordialement
Je débute aussi, mais je ne crois pas qu'il existe de méthode toute faite pour cela. Toutefois une façon simple serait de faire en sorte que ta fonction retourne une variable contenant l'information d'interruption, puis que tout le reste du programme soit précédé par un if
Code:void setup() { Stop=0; } void loop() { Stop=mafunction(ettoutcequilfautdedans); if(Stop=0) { mesautresfonctions(blabla); } }
Bonjour,
Il faudrait connecter une sortie de l'arduino sur l'entrée "reset" de la carte (en option: un transistor et une résistance en pull-up en s'assurant que la sortie soit au niveau 0 par défaut ou 1 s'il n'y a pas de transistor et de résistance, sinon la carte fera une boucle de "reset"). Ensuite en la passant à 1, la carte redémarre, elle recommence au début de main().
Bonsoir,
Déplacé en électronique.
Deux pattes c'est une diode, trois pattes c'est un transistor, quatre pattes c'est une vache.
Classique avec une carte arduino, on fait sans comprendre renflement ce que 'on fait.
Le microcontrôleur est certainement capable de gérer les interruptions.
Change de logiciel de programmation!!!
Il n'y a pas de fonction main() en langage Arduino. Il y a void setup() puis void loop(). Et avant void setup(), il peut y avoir des variables qui reçoivent des valeurs.Envoyé par AiMaxTht
Si tu fais un reset, tu vas revenir au tout début du programme, pas au début de void loop()
Un civet, un plat de côtes et puis, glissez-moi une petite paupiette avec.( Lino Ventura)
De toutes façons c'est quoi cette manie d'utiliser les interruptions pour lire des boutons ?
Les interruptions c'est fait pour traiter des événements rapides, l’appui sur un bouton n'est pas un événement rapide.
Tout projet flou conduit à une connerie précise !
C'est utile, et parfois même indispensable.
Il n'a pas dit le contraire, et, personnellement, je suis assez d'accord avec son commentaire.
Alors je n'ai pas compris ce qu'il a voulu dire !
Interruption ou pas, c'est un choix de la structure du programme, pas une manie.
Un "évenement rapide" ne veut rien dire !
En entrée µC on a un niveau 0 ou 1, c'est la durée de présence du niveau à prendre en compte qui est importante.
Et les interruptions seraient réservées à des évènements particuliers ?
Evidemment, ça dépend des nécessités du programme. Mais utiliser les interruptions à outrance n’est pas forcément une bonne idée. Elles sont indispensables pour une gestion d’UART ou de timer, par exemple, mais pour savoir si un bouton est actionné, il suffit d’un test dans la boucle. L’utilisateur ne se rendra pas compte qu’il a appuyé 10 millisecondes de plus parce que le programme était occupé ailleurs, éventuellement par d’autres interruptions urgentes.
A outrance ? Autant que nécessaire !
La gestion des interruptions est hiérarchisable.
+1
Et un bouton (ou des boutons !), ça se teste avec un timer, ce qui permet , en prime, de faire un anti-rebond par soft.
Par exemple, un automate programmable industriel est capable de géré des dizaines, voir des centaines d'entrées : boutons, capteurs, commutateurs, interrupteurs... sans interruptions, simplement en scrutant régulièrement ses entrées (temps de cycle typique 10ms)
Dans ce contexte les interruptions sont plutôt utilisées pour des périphériques genre codeur incrémental, compteurs, communication.
Je ne vois pas pourquoi un µC aurait besoin d'interruption pour gérer l’appui sur un bouton poussoir (actionné par un humain...)
ça fait pas loin de 20 ans que je bricole avec des µC, et j'ai jamais eu besoins d'interruptions pour gérer des boutons. (et mes boutons réagissent très bien et sans latence...)
Je ne dis pas qu'il ne faut pas le faire, et je ne dis pas qu'il n'y a pas des cas particuliers où ça peut être nécessaires, mais quand on regardes un peu l'historique des messages liés à la programmation de µC, on constate que de plus en plus souvent on à recours aux interruptions pour lire des boutons, alors qu'a côté de ça les programmes sont bourrés de "delay()" et autres temporisations bloquantes du genre. (mais l'un ne va pas sans l'autre, forcement on ne peut pas faire un scrutation régulière des boutons, si à côté de ça le programme passe un temps fou bloqué par des boucles de temporisations...)
J'ai surtout l'impression que les bonnes pratiques de la programmation se perdent, et que pour compenser on à de plus en plus recours à des artifices inutiles pour se sortir d'un programme mal foutu...
Donc je persiste, dans un contexte normal (genre j'appuie sur un bouton ça allume une led, je re-appuie ça l’éteint) les interruptions ne sont pas nécessaires.
Tout projet flou conduit à une connerie précise !
Normal ! Pour faire ça, il n'y a pas besoin, aussi, de µC ........ un simple NE555 est suffisant .
Ben oui, mais avec la priorité minimum pour le poussoir, ton utilisateur attendra autant de millisecondes que sans interruption.
Pourquoi faire simple...
De plus, l’action sur le bouton poussoir peut déclencher des procédures longues, selon les besoins du programme.
Jamais en interruption !
En interruption, on vient tester le sens de changement, un rebond et on positionne un flag 'semaphore) qui sera traité plus tard dans le "main"
Mais c'est bien ce que je voulais dire: pas besoin d'interruption pour détecter l'appui sur un poussoir !
Ben non ....
- L'interruption permet de prendre en compte "immédiatement (?)" l'évenement sur le bouton
- Le test du flag "plus tard (?)", d’exécuter l'action qui en résulte
Je partage à 100% le point de vu de antek et de DAUDET78. Moi j'ai toujours géré mes interrupteurs/boutons poussoirs en interruption.
Cela permet de réaliser une machine à état en guise de programme principal.
Au lieu, de scruter sans arrêt une entrée pour voir si l'utilisateur à appuyé sur un bouton (100% du CPU utilisé), moi je mets mon micro en veille et c'est une interruption sur le bouton qui vient réveiller mon micro.
dans mon programme d'interruption, je mets simplement une variable à une certaine valeur. Puis le micro se réveille à cause de l'interruption. Enfin le programme principal, qui est une boucle avec un simple switch case test la variable et exécute l'action désirée et hop..... re-mise en en veille. En faisant du polling (une boucle qui scrute tout le temps dans le soft) tu consommes toujours à 100%
Après effectivement, on peut toujours faire du polling ça va fonctionner aussi.
Ton contexte n'est pas "normal", on n'utilise pas un µC pour allumer une led.
Sauf dans le cadre de l'apprentissage.
Et il y a toujours plusieurs façons pour résoudre un problème.
D'accord pour le cas où l'utilisateur devrait maintenir appuyé le poussoir plusieurs secondes.
Ce cas doit quand même être assez rare, non ?
Dans le cas de l'Arduino, les interruptions ne font pas forcément bon ménage avec les temporisations.
Millis () s'appuie sur les interruptions pour compter, donc il ne sera jamais incrémenté pendant une interruption.
Comme delay () requiert des interruptions pour fonctionner, il ne fonctionnera pas s'il est appelé par une interruption.
Micros () fonctionne initialement, mais va commencer à se comporter de façon erratique après 1-2 ms.
DelayMicroseconds () n'utilise pas de compteur, donc il fonctionnera normalement.
Un civet, un plat de côtes et puis, glissez-moi une petite paupiette avec.( Lino Ventura)
Pas du tout, ça fonctionne dans tous les cas.
Faut apprendre à lire entre les lignes hein...
Tout projet flou conduit à une connerie précise !
Il est vrai que la question de départ concerne Arduino et pas les µC en général.
C'est déjà assez difficile de communiquer par écrit.
Alors si on rajoute des possibilités d'interprétation . . .
C'est une approche intéressante pour une application qui passe son temps à attendre des événements et ça permet effectivement d’économiser un peu d’énergie. Mais ça demande d'utiliser les interruptions pour un peu prêt tout.
Quand on doit faire des calculs réguliers en tache de fond (régulation PID par exemple) ça tombe un peu à l'eau.
En scrutation on peut aussi faire un programme qui met le µC en veille et sans interruption*. Si on vient lire les entrées que toutes les 10ms, et qu'on déroule le programme que s'il y a eu un changement, les µC passe aussi le plus clair de son temps en veille. (bien-sûr même limitation que si à côté de ça on doit faire des calculs réguliers)
C'est un tout petit peu moins économe qu'avec les interruptions, mais ça ne nécessite pas d'interruptions...(nombre de vecteurs parfois limités, etc...)
10ms sur un appuis de bouton c'est rien... c'est le temps minimum de l'anti-rebond... et pour un µC c'est une éternité, donc ça fait quand même pas mal d'économies.
*EDIT : avant qu'on vienne pinailler... oui bien sur il faut quand même une interruption sur un timer pour réveiller régulièrement le µC
Dernière modification par Forhorse ; 18/03/2017 à 13h19.
Tout projet flou conduit à une connerie précise !
C'est quand même evident que c'était un exemple... j'allais pas citer toutes les actions que l'on peut déclencher par l’appui sur un BP. Et puis je me met au niveau de la grande majorité des utilisateurs qui viennent poser des questions sur ce forum à propos de l'arduino...
En caricaturant à peine : il ont fait un programme qui font clignoter une led à grand coups de "delay()" et ensuite il veulent en allumer une autre quand ils appuient sur un bouton, et ils se demandent pourquoi ça marche pas...
Je pense que ceux qui participent à cette discussion ont déjà un certain niveau et j'imaginais donc qu'ils comprendraient ce que je voulais dire par "allumer une led" visiblement c'est pas le cas...
Tout projet flou conduit à une connerie précise !
Évidemment!
Alors je précise : traiter l’appui du BP par interruption est justifié si des tâches longues peuvent être en cours. C’est le principe du flag levé dans l’interruption, proposé par DAUDET78.
Question : ce cas est-il fréquent ?
AMHA, c’est assez exceptionnel, et le test d’un poussoir est suffisant dans 90% des cas. J’ai cru comprendre que le demandeur se trouve dans les 90%.
