Arduino UNO etc : Réagir à l'appui sur un bouton poussoir (front descendant...). Eviter les rebonds.

[@fouadchnioui2062]

Explication claire et pédagogique. Merci pour votre travail .

[@peaceforall8361]

Bravo pour la manière et Merci pour les efforts, Bonne continuation, pour info je suis du Maroc

[@neufmontiers]

Bonjour Eric J'ai 60 ans et intéressé par le monde d'arduino, je le découvre a travers vos vidéo. Je suis scotché par votre rigueur, votre calme, et votre pédagogie. J'adore vos analyses graphiques qui posent tout le problème. Il n'y a pas de place à la peu près. Sans mauvais jeu de mot vous fixez le potentiel. Sur un malheureux circuit de portes et un BP on pourrait passer 4heures a découvrir des trucs. J'aime bien, continuer SVP même si c'est ardu, ça ouvre l'esprit. Encore bravo, quand j'entends que vous vous pouvez passer 8h a préparer une vidéo. Salutations E.T

[@EricPeronnin]

Merci pour votre commentaire qui me rappelle tout l'intérêt de ce travail.

[@marcdupont2369]

Merci Eric, super explications claires et donc formatrices. Bravo, je suis retraité et je prends le temps de tester tous vos algos avec bonheur . Encore Merci.

[@phil12490]

Bonjour Eric. Vos vidéos sont géniales. C'est un régal. Un grand merci.

[@EricPeronnin]

Merci à vous

[@drumandbassfromju]

Super vidéo. Merci 🙏

[@thierryherve9811]

Excellente vidéo, grand merci pour ta grande qualité pédagogique et technique.

[@jean-claudechameroy8775]

Bonjour, ingénieur électronicien retraité, formé à l'Enac Orly puis Toulouse en 1967, 68 et 69, ce problème des rebonds des boutons poussoirs à une époque où seule l'analogique existait était un véritable casse-tête. On arrivait (selon mes souvenirs lointains) à le résoudre plus ou moins avec un réseau RC en série parallèle avec le poussoir ; méthode très artisanale. En tous cas félicitation pour ce cours qui me plait énormément. J'ai commandé le kit et je vais me faire plaisir.

[@EricPeronnin]

Bonjour Jean-Claude. Effectivement, le circuit RC permet de résoudre cela aussi. L'avantage de la solution programmée, c'est un allègement matériel et les timing peuvent aisément évoluer. En plus, ce n'est pas non plus très complexe.

[@antoinedevos3765]

Merci pour ces précisions. Impeccable comme d'habitude Bonne journée.

[@EricPeronnin]

Merci Antoine

[@PaysLimitrophes]

Merci pour ce tuto de folie mon srab j'te kiff bg grâce à toi Emile a réussi à faire son projet

[@arthuriphone9534]

Super, à 66ans je me revois au temps où j'étais en cours à l'IUT de Cachan (94) . Excellentes vidéos je les regarde toutes. Merci pour le travail accompli que je mets en application dans mon petit labo perso pour des applications liées à mon autre passion le radioamateurisme. Bravo et merci encore, Eddy

[@EricPeronnin]

Merci Eddy pour ton message

[@swit_azya]

bonsoir, étant débutant en ingénierie j'ai trouvé votre vidéo très intéressante, merci pour vos explications

[@vincentvidal3305]

Bravo et merci Éric pour cette présentation. Comme Thierry je suis adepte du circuit R/C et en complément d'un trigger de Schmitt, car pour traiter un ou deux BP par logiciel ça va, mais ça peut devenir galère si il y en a beaucoup surtout avec la fonction micros() ou millis() qui au final peuvent demander pas mal de ressources au UC. Tous les BP ont des rebonds, sur des gros projets, il y a, en solution hard, le MC14490 ou les MAX-6816-17-18. L’emploi d'un SN74LS540 avec R/C fonctionne bien aussi, pour voir un exemple : github.com/vidalv/Arduino-Multi-switch/blob/main/BP_Schemas.JPG. Encore merci pour les explications et le temps passé !

[@EricPeronnin]

Merci pour le lien Vincent. Je n'ai pas abordé les solutions matérielles pour l'instant mais cela pourra venir. Pour limiter l'impact en ressources CPU, on peut aussi mettre en place un traitement par interruptions mais dans l'absolu la solution proposée n'ai pas très gourmande. Pour la rendre encore moins gourmande, on doit pouvoir limiter la résolution de millis() en ne prenant que l'octet de poids faible en compte car finalement, c'est pratiquement ce calcul sur 32 bits qui est le plus gourmand dans cette approche. Je n'ai pas essayé mais cela doit fonctionner.

[@vincentvidal3305]

@@EricPeronninSalut Eric, en effet tu as raison, en fonctions des besoins il faut s'adapter, soit pas logiciel ou par matériel.

[@martial_8660]

Bonjour Eric Je ne suis pas le doyen ( je n'ai que 71ans ). Vos vidéos sont très bien faites. Je les suis et les réalise avec plaisir. Mon objectif est de les faire connaitre à mes petits enfants un peu plus tard ( Ils ont 8 ans pour l'instant ) Encore bravo. Martial

[@EricPeronnin]

Merci Martial pour votre commentaire.

[@marcabentin4438]

Merci beaucoup pour toutes ces vidéos très pédagogiques super travail

[@EricPeronnin]

Merci Marc.

[@seanmarotta5969]

Très pédagogique ! Je m'abonne !

[@lionneldupontavice9710]

Bonjour Eric, Ce que j'apprécie dans vos vidéos c'est la précision de vos explications à la fois claires et très utiles. Vos étudiants doivent bien apprécier vos cours.

[@EricPeronnin]

Merci Lionnel à la fois pour vos commentaires et votre contribution à l'acquisition de l'oscilloscope.

[@paulragot6155]

Merci Eric pour cette excellente analyse. Tu nous décomposes parfaitement l'algorithme pour solutionner ce problème de rebonds. J'apprécie également lorsque en fin de vidéo, tu nous proposes un problème à résoudre pour la vidéo suivante. Cela permet de se frotter au problème avant de connaître ta solution. C'est très formateur. Cordialement

[@EricPeronnin]

Merci Paul pour le commentaire et pour ta contribution à l'acquisition de l'oscilloscope. Il va falloir faire un choix et ce n'est pas évident. Ce sera entre Siglent et Rigol qui sont vraiment bien placés en terme de rapport qualité/prix.

[@pierreviaud8123]

Bon, eh bien je viens d'apprendre que le doyen à 79 ans, je ne peux que lui souhaiter longue vie ainsi que tous les acteurs de cette merveilleuse chaîne que j'ai découverte il y a deux jours. Passé mon CAP d'électronicien dans les années 85, à 38 ans, et depuis toujours intéressé par l'électronique et ses dérivés. Merci pour votre pédagogie et ... je vois demain pour acheter le kit Arduino ... Pierre.

[@EricPeronnin]

Pas le doyen mais pas loin. Bon courage pour l'apprentissage Arduino etc

[@pierreviaud8123]

@@EricPeronnin Merci beaucoup de votre réponse.

[@jfmahe1407]

Oui, ça mérite largement un pouce bleu. Merci Eric.

[@EricPeronnin]

Merci :-)

[@ChristopheDeZanet]

Bonjour Eric. On est presque dans les visiteurs...jour...nuit...jour... Bref. Merci pour votre travail, je me délecte de vos vidéos. Cela fait plus de 15 ans que je suis sorti de mes études en électronique et ça me donne envie de m'y replonger (kikad par exemple) et d'aller plus loin (j'ai des arduino à la maison). Mais cela me donne envie aussi de montrer et d'expliquer la technologie à mes enfants. Bonne continuation. Vivement l'achat de l'oscillo.

[@EricPeronnin]

Merci Christophe à la fois pour votre contribution à l'acquisition de l'oscilloscope et pour votre message. J'espère que les enfants accrocheront. Vous me direz.

[@mikl5228]

Vivement les prochains !!

[@EricPeronnin]

Merci Michaël.

[@francoisgarault1160]

Bravo, pour la qualité de vos vidéos. Tant qu'à la pédagogie, j'aurais aimé avoir des professeurs comme vous.

[@dinoauci1252]

Bonjour , super video j'ai fait récemment un trainer Morse et je suis confronté a des rebonds tres bonne explication

[@laurentthommet8313]

Un grand classique auquel tout programmeur est rapidement confronté. Explication claire et pédagogique. Merci pour votre travail ! Laurent

[@fredericschmitt1486]

Bonjour, merci pour ces cours très instructifs. Etant de la vielle école j'ai besoin d'une mise à niveau pour pouvoir mener à terme mon projet. Les vidéos ont depuis été transmises à mes enfant, grands bidouilleurs.

[@EricPeronnin]

Bonjour. J'essaie d'être assez progressif en limitant les prérequis nécessaires pour suivre les vidéos. Si vous suivez les vidéos dans l'ordre des playlistes, ça doit pouvoir aller. J'espère que les jeunes bidouilleurs apprécieront.

[@fabricemotard4312]

Très bonne vidéo explications claire et précise bravo ! 👏👍 En attente de la prochaine !!

[@EricPeronnin]

Merci Fabrice

[@FloDav]

Excellent travail, on en redemande, merci.

[@cyberfly8452]

Excellent merci !

[@stephanefouret304]

Bonjour , Trés bon travail ,comme tous j'attends la suite avec impatience, bonne continuation , je m'en vais de ce pas apporter ma petite contribution pour l'oscillo .

[@EricPeronnin]

Merci Stéphane. Je progresse dans le choix de l'oscillo. Probablement un Siglent SDS1104X-E. Une petite hésitation avec en balance le SDS2104X Plus mais ce ne serait pas raisonnable. Il y aura aussi un générateur de la marque pour profiter du mode Bode de ces oscilloscopes. Et enfin je prévois une alimentation programmable.

[@jeanchristophechamparnaud]

Bonjour Eric, enfin des vidéos didactiques. Des cours clairs avec un objectif une explication et une démonstration. LIMPIDE. Je suis juste effaré que l'on puisse mettre un pouce rouge ... un principe d'incompréhension basique chez moi. Je ne comprends pas le concept. En tout cas moi, je continue la série et les pouces bleus au fur et à mesure ;-) Merci d'avoir réalisé ce travail.

[@EricPeronnin]

Merci Jean-Christophe. Je peux comprendre que spectateur puisse ne pas aimer une des vidéos. Cela mériterait néanmoins un message : pour progresser, il faut être informé de ses erreurs. Notez que j'ai constaté qu'un utilisateur, peut-être même un robot car cela se fait, mettait systématiquement un pouce rouge sur mes vidéos. Ils disparaissent parfois car KZbin fait la chasse à ces robots.

[@ericdurant8972]

Merci Eric

[@thierrymelmet3813]

Perso, je trouve la solution du condo de 10nF en parallèle sur le BP plus rapide à mettre en oeuvre. (oui je sais je fait ma feignasse) :) Superbre explications, encore bravo. :)

[@EricPeronnin]

Je traiterai aussi l'approche analogique dans une autre vidéo. Plus simple à mettre en œuvre mais qui nécessite des connaissances différentes pour être comprise. Merci pour votre message.

[@erichardy29]

Oui, l'usage d'un condo est judicieux sur un plan strictement électronique pour la réduction du bruit. Mais on peut voir le principe utilisé ici de façon beaucoup plus large : par exemple pour contrôler la fréquence d'appui (i.e. on ne veut pas d'appui sur le bouton à une fréquence supérieure à 1Hz). Ce principe peut aussi être utilisé pour contrôler l'arrivée d'événements divers par les interruptions et prendre ou ne pas prendre en compte tel ou tel événement en fonction de sa fréquence. Merci à toi, Eric, je me plais à recommander tes vidéos à des débutants ! (et je prends aussi plaisir à les suivre...)

[@EricPeronnin]

Bien sûr. La version logicielle apporte une souplesse supérieure. Le besoin en terme de ressource est en plus limité.

[@fredericschmitt1486]

Les deux sont complémentaires à mon avis, le condo pour traiter les signaux parasites, la programmation pour filtrer les comportements erratiques des actionneurs.

[@jipdroj9380]

bonjour, je suis vos productions avec intérêt ! claires et précises. et pouce bleu à chaque :) le cote éthique de la redistribution des "gains" youtube, Respect ! Et le rebond sont un vaste sujet, je galère avec cela sur un encodeur rotatif (lowcost) qui me saute des pas - Dans le programme C , le #define, pour moi s'était pour le precompilateur l'équivalent d'un cherché/remplacé et cela pouvait poser problème si le mots clé utilisé dans le #define correspond à un éléments autre dans le programme. on m'avait conseillé de remplacer les #define par une Constante. hâte de la prochaine vidéo

[@tanguymarion6368]

La constante prend une place dans la mémoire alors que le define n'en prend pas. Tout dépend de tes besoins. Pour éviter le problème si le mot clé utilisé par le define correspond à un élément du programme, il existe "une règle" en programmation, mettre le define en majuscule :)

[@jipdroj9380]

@@tanguymarion6368 merci, j'avais dans l'idée que les constantes avaient des vérifications supplémentaires, mais que cela finissaient comme le définie par un remplacement par la valeur. Je m'arrête je vais pas troller 🤗

[@DjOddEssA]

Arf ! Pris de vitesse par @Tanguy MARION -_- Tiens, ça me rappelle que je souhaitais signaler à @Eric Peronnin dès le début de sa série, qu'il aurait été sans doute judicieux d'expliquer pourquoi, à la différence de la quasi totalité des vidéos ou des formations sur Arduino, pourquoi il utilisait "#define" et non "const int", la différence entre ces deux variables et ses implications. Pour les néophytes, les débutants ayant déjà un peu bricolé avec ou d'autres, cela aurait été, ce n'est que mon avis, utile, non ?

[@tanguymarion6368]

@@jipdroj9380 les constantes ont des vérifications supplémentaires qui sont gérées par le compilateur, alors que le define lui est géré au niveau du preprocessing

[@EricPeronnin]

Bonjour. Et merci pour les réponses précises que vous apportez. J'utilise les #define par habitude. Au départ par souci d'optimisation pour réaliser l'équivalent de fonctions inline de masquage par exemple donc pas seulement pour des valeurs littérales. J'ai une formation très généraliste en génie électrique mais suis totalement autodidacte en développement logiciel. Je me suis souvent basé sur les travaux des ingénieurs Microchip pour les microcontrôleurs PIC et ils ont un usage exclusif des #define. Jamais un const dans leur code. En revanche, il existe un effet de bord très préjudiciable avec les #define lorsque l'intitulé à remplacer, dans les faits une suite de caractères, est présent dans le programme. Dans ce cas, le préprocesseur le remplace partout ... Exemple : #define TOTO 12 const int TOTO_va_a_la_plage = 20; entraine une erreur au moment de la compilation puisque le compilateur va compiler le code const int 12_va_a_la_plage = 20; Dans les fichiers Arduino, on trouve d'ailleurs ceci : A noter une chose intéressante. Dans les fichiers de définitions d'une carte pour l'IDE Arduino, on trouve ceci : #define PIN_WIRE_SDA (18u) #define PIN_WIRE_SCL (19u) static const uint8_t SDA = PIN_WIRE_SDA; static const uint8_t SCL = PIN_WIRE_SCL; Pour rendre utilisable SDA et SCL comme numéros de broche et éviter l'effet de bord d'un #define SDA Ce qu'il faut retenir : #define -> c'est le préprocesseur qui gère. Des erreurs pourront apparaître durant la phase de compilation, erreurs qui peuvent parfois être difficile à retracer (exemple ci-dessus) const -> il y a création d'une variable avec interdiction de l'affecter en dehors de sa phase d'initialisation. Le code généré peut ne pas être aussi concis qu'avec un define : tout dépend des options d'optimisation du compilateur. Avec Arduino, #define PIN_LED 3 et const int pinLed = 3; conduisent à la génération d'exécutables de même taille, donc des codes très probablement identiques.

[@danielroibert5631]

Bizarre, il y a un pouce vers le bas, alors que la vidéo est super-parfaite, ça doit être un rebond de pouce mal géré par KZbin.

[@EricPeronnin]

Bien vu Daniel. Ca fait un moment que j'essaie de comprendre l'origine de ce seul pouce vers le bas sur beaucoup de mes vidéos. Souvent il apparaît dans les premières secondes. Il semble que ce soit un robot...

[@DjOddEssA]

@@EricPeronnin C'est un bot, aucun doute à ce sujet. Par contre j'ignore ses algos qui décident du choix des vidéos à marquer : catégorie ? Nombre de vues ? Nombre d'abonné(e)s ? Nombre de commentaires ? ... .

[@EricPeronnin]

Aucune idée. Mais ce n'est pas bien grave mais je me suis simplement demandé qui avait intérêt à cela sur ma modeste chaine.

[@patrickcharlier7821]

Bonjour Monsieur Peronnin, Permettez-moi de vous remercier pour le travail que vous réalisez et qui doit vous demander énormément de temps . Je suis reparti sur votre exemple afin de générer un code semblable ou le bouton poussoir permet d'inverser le fonctionnement de deux leds. Cela fonctionne très bien. ou cela se corse c'est que je voudrais initialiser l'allumage de la première led (toujours la même) via un détecteur de présence. Tant que le détecteur est actif, l'appui sur le bouton poussoir inverse le fonctionnement des deux leds. Si le détecteur de présence passe à l'état bas, la led allumée doit s'éteindre. Le passage à l'état haut du détecteur rallume la première led et ainsi de suite Voici le code généré mais qui ne fonctionne pas correctement. Auriez-vous une piste de solution? bien à vous Patrick #define SENSOR_PIN 13 // HIGH = motion detected #define PIN_BP 2 #define PIN_LED_NORMAL 3 #define PIN_LED_UV 5 #define DELAI_SANS_REBOND 10000 void setup() { // put your setup code here, to run once: pinMode (SENSOR_PIN, INPUT); // PIN 13 pinMode(PIN_LED_NORMAL, OUTPUT); pinMode(PIN_LED_UV, OUTPUT); pinMode(PIN_BP, INPUT_PULLUP); digitalWrite(PIN_LED_NORMAL, HIGH); } void loop() { // Début l'exécution de la boucle static uint8_t dernierBP = HIGH; uint8_t BP = digitalRead(PIN_BP); static unsigned long derniereTransition = 0; unsigned long _micros; if (digitalRead(SENSOR_PIN)==HIGH) { digitalWrite(PIN_LED_NORMAL, HIGH); // Présence d'un front if (dernierBP != BP) { _micros = micros(); if ((_micros - derniereTransition) >= DELAI_SANS_REBOND) { // Présence d'un front descendant if (BP == LOW) { digitalWrite(PIN_LED_NORMAL,!digitalRead(PIN_LED_NORMAL)); digitalWrite(PIN_LED_UV,!digitalRead(PIN_LED_NORMAL)); } } derniereTransition = _micros; } // Fin de l'exécution de la boucle dernierBP = BP; } else { digitalWrite(PIN_LED_NORMAL, LOW); digitalWrite(PIN_LED_UV, LOW); } }

[@patrickcharlier7821]

Parfois, le fait de poser la question...vous fait trouver la solution. Je répond donc à ma question avec une solution qui fonctionne. Le but maintenant serait de mettre du "fading" sur les différents allumages et extinctions. #define SENSOR_PIN 13 // HIGH = motion detected #define PIN_BP 2 #define PIN_LED_NORMAL 3 #define PIN_LED_UV 5 #define DELAI_SANS_REBOND 10000 void setup() { // put your setup code here, to run once: pinMode (SENSOR_PIN, INPUT); // PIN 13 pinMode(PIN_LED_NORMAL, OUTPUT); pinMode(PIN_LED_UV, OUTPUT); pinMode(PIN_BP, INPUT_PULLUP); } void loop() { // Début l'exécution de la boucle static uint8_t dernierBP = HIGH; uint8_t BP = digitalRead(PIN_BP); static unsigned long derniereTransition = 0; unsigned long _micros; if (digitalRead(SENSOR_PIN) == HIGH) { digitalWrite(PIN_LED_NORMAL, !digitalRead(PIN_LED_UV)); // Présence d'un front if (dernierBP != BP) { _micros = micros(); if ((_micros - derniereTransition) >= DELAI_SANS_REBOND) { // Présence d'un front descendant if (BP == LOW) { digitalWrite(PIN_LED_NORMAL, !digitalRead(PIN_LED_NORMAL)); digitalWrite(PIN_LED_UV, !digitalRead(PIN_LED_UV)); } } derniereTransition = _micros; } // Fin de l'exécution de la boucle dernierBP = BP; } else { digitalWrite(PIN_LED_NORMAL, LOW); digitalWrite(PIN_LED_UV, LOW); } }

[@maessenjean-luc139]

Bonsoir, merci pour cette vidéo, je viens de comprendre un problème que j'ai rencontré par le passé. 2 questions; 1) Le problème du rebond, ne peut-il être résolu en travaillant sur le circuit? 2) En milieu industriel, les PB, fins de courses, etc..., sont-ils sujet aux rebonds? Ce que nous utilisons comme matériel lors de nos montages Arduino est un peu bas de gamme, ce qui explique peut-être les rebonds. Merci Bonsoir à Raimond et Lucas.

[@EricPeronnin]

Bonjour Jean-Luc. Le problème peut être résolu de façon électronique mais la solution logicielle est finalement simple à mettre en oeuvre et toujours efficace. Oui je pense que les capteurs industriels, sauf dispositif interne l'empêchant, sont aussi sujets au rebond. Eric

[@maessenjean-luc139]

@@EricPeronnin Merci

[@laurent9288]

Parfait !

[@jeanclaude8857]

Super, j'ai testé l'analyseur de logique ( - de 10 €) avec le logiciel Saleae Logic 1.2.18 sous Ubuntu 20.04, ça marche bien et on voit bien les signaux et les rebonds plus importants avec mon BP.

[@EricPeronnin]

Super. Vraiment utile ce petit appareil. Et dès lors qu'on s'intéresse à l'I2C par exemple, cela devient encore plus utile.

[@DjOddEssA]

@@linuxmint9107 Linux est utilisé depuis longtemps dans certaines administrations y compris dans la gendarmerie. Il devrait être utilisé dans les écoles en parallèle avec Windows, même si plusieurs collèges et lycée utilisent des logiciels open source ce qui est un premier pas, mais il faut reconnaître que question convivialité pour installer un programme on a vu mieux ! Cependant je me vois mal, par exemple, concevoir et analyser de la UHF sans un ordi sous Windows, car aucun soft n'existe sous Linux.

[@DjOddEssA]

@@linuxmint9107 En UHF et Hyperfrequency ? Avec le matériel de labo qui va bien ? Je suis curieux de voir cela :)

[@DjOddEssA]

@@linuxmint9107 Je ne parlais pas de l'écoute radio (je connais plusieurs de ces programmes utilisant une clef USB TNT), mais de la conception électronique. À ma connaissance aucun soft sur Linux, hormis ceux spécifiques réalisés en interne, n'existent. Je ne pense pas qu'un analyseur de spectre RHODE, par exemple, le permette d'ailleurs !

[@DjOddEssA]

​@@linuxmint9107 Je connais l'Université de NANTES ainsi qu'ATMEL ^^. Linux est tout aussi facile à pirater entre nous, mais le sujet est d'avoir un soft aussi puissant tournant sous Linux que celui tournant sous Windows et en R&D ce n'est clairement pas le cas. En tout cas pas avec mon RHODE 8 GHz. Cela dit, vous n'avez pas répondu à ma question !

[@jrioublanc]

Super, merci pour cette présentation simple et pédagogique. Certains commentaires parlent s’une solution analogique, c’est vrai que c’est possible, mais avouons qu’il y a 20 on rêvait de se passer de composants pour traiter ce problème. Amusant comme retournement. 😁 J’ai quand même une question, pourquoi créer des variables statiques dans loop() alors que des variables globales feraient l’affaire ?

[@EricPeronnin]

Bonjour Jérôme. Je ne suis pas un puriste en matière de programmation mais les programmeurs ont pour habitude de ne rendre disponible une variable que dans le contexte où elle est utile pour éviter tout risque d'utilisation inadaptée de la variable. En plus, les programmes sont souvent beaucoup plus lisibles comme ça.

[@eddybash1342]

Bonjour professeur, Le poussoir est un oscillateur harmonique et donc de fréquence propre à la lame oscillante portant les contacteurs. Vous pourriez voir ce phénomène sur l'entrée ADC plutôt que l'entrée numérique à trigger . ;) En conséquence la périodicité est ISO mais l'amplitude du signal chute vs time.

[@EricPeronnin]

Bonsoir. Que la lame se comporte comme un oscillateur mécanique, c'est indéniable. En revanche, l'évolution du potentiel observé sur les contacts n'est pas du tout comparable au déplacement de la lame dont l'action sur les contacts est purement binaire. Ce qu'on observe en analogique sur les contacts est le fait du contact binaire induit par la lame et de la présence d'un circuit RC sur le chemin du contact (la résistance de pullup et la capacité d'entrée du microcontrôleur), donc les branches exponentielles d'un circuit du premier ordre.

[@raymondhuve3100]

Bonsoir , et surtout grand merci a vous , je vient de découvrir votre série de cours qui ma déjà permis en quelque jours de résoudre quelque petit problèmes . Débutant en programmation sur Arduino. Il était temps car je viens de fêter mes 71 ans. Est il toujours possible de poser quelques question a propos de ce cours. Merci Raymond.

[@jean-marcmandin4766]

Bonjour et encore Merci pour ce riche travail. Pourrions nous disposer du code de programmation écrit dans son intégralité svp.

[@EricPeronnin]

Bonjour. Je mets progressivement à jour mon site geii.eu pour qu'il contienne aussi le code des vidéos. Voir geii.eu/index.php?option=com_content&view=article&id=234&Itemid=944

[@MauriceBoulard]

pour éliminer les rebonds du bouton, on pourrait mettre au niveau hardware un filtre RC au niveau du bouton: si il y a un rebond, l'energie elec serait absorbée dans la capa donc le chgt de niveau ne serait pas visible par le microP

[@stanislasthouret5971]

Bonjour, Merci Pour toutes ces explications très claires. Peu-t-on avoir une copie des instructions du programme ? Merci pour votre aide.

[@jeanmarchadier3807]

Merci pour ces très claires explications. Je me suis demandé si l'utilisation d'une interruption ne serait pas indiqué pour exploiter un poussoir. En effet, si le temps de boucle est très long, on risque de louper des transitions.

[@EricPeronnin]

Bonsoir. C'est l'objet d'une autre vidéo. Les choses sont présentées de façon progressive.

[@aureliengassot1482]

Bonjour. Merci pour toutes ces vidéos. C'est vraiment très bien fait et super enrichissant. Une question à mon niveau, (au regarde du nombre de commentaire, j'espère être le premier à la poser) Quel outil utilisez vous avec votre analyseur logique ? J'en ai un lowcost et malgré une échantillonnage annoncé en 24Mhz je n'arrive à capturer qu'avez une fréquence de 1Mhz avec l'outil Pulseview de Sigrok. Merci d'avance.

[@EricPeronnin]

Bonsoir. Je n'ai pas utilisé le petit analyseur sur mes vidéos pour l'instant. C'est un Bitscope Micro avec son logiciel dédié. J'utiliserai prochainement celui que vous avez avec Pulseview de Sigrok et vous en dirai plus. Il semble que l'OS ait son importance. Je vous en dis plus dès que j'aurais eu le temps de voir ça car pour le moment je suis trop chargé professionnellement.

[@technophile01]

Salut professeur.j ai vu la vidéo la nuit et j ai remarqué la faute de frappe (tansition) qui vous a valu une remarque quelque peu "indélicate"d un internaute qui lui-même est tombé dans l erreur 2fois: example!+erreur de syntaxe.. Ce n'est pas mal de faire des remarques mais poliment..Sans rancune par example!!!😃

[@EricPeronnin]

Je n'en tiens pas rigueur à François qui m'a signalé cette coquille que je n'avais pas pu voir par un concours de circonstance car j'ai enregistré la vidéo en 2 temps. Et dans la seconde version, la première, fonctionnelle, étant déjà chargée sur la carte, j'ai lancé la compilation sans attendre le résultat et switché sur l'analyseur. Je n'ai donc jamais eu l'occasion de voir l'erreur de compilation et, clairement, après 8H de travail pour la vidéo donc 1H30 à enregistrer (plantage OBS à la première prise), je n'avais pas envie de la visionner. L'essentiel est que cela ait permis d'offrir une version aujourd'hui dénuée de cette coquille. Dans un enregistrement comme celui-ci, je travaille avec 3 écrans, 5 fenêtres différentes, 2 caméra... et je tente de faire tout cela en temps réel pour éviter l'opération de montage à laquelle je n'ai pas pu couper cette fois.

[@didierr6181]

@@EricPeronnin vous faites du très bon travail professeur.

[@jean-remydangers6453]

@@EricPeronnin 8 heures de travail, 2 caméras, 3 écrans pour sortir cette qualité de vidéo, ça ne m'étonne pas du tout ! La dure Loi du Réel...

[@phamarthur479]

Bonjour, est-ce que pour le programme de départ, il est possible de programmer comme cela ? : unsigned char pin_LED = 1 ; unsigned char pin_BP = 7 ; #define Appuye digitalRead(pin_BP)==LOW void setup() { // put your setup code here, to run once: pinMode(pin_LED,OUTPUT); pinMode(pin_BP,INPUT_PULLUP); digitalWrite(pin_LED,LOW); } void loop() { // put your main code here, to run repeatedly: static boolean etat = LOW ; if (Appuye) { etat=!etat; while (Appuye) { digitalWrite(pin_LED,etat); } } }

[@EricPeronnin]

Bonjour. D'une façon générale, j'interdis à mes étudiants de développer des applications qui reposent sur des boucles d'attentes bloquantes car une application complexe ne peut généralement pas se satisfaire de ce type d'approche. Et même en multi-thread, je ne suis pas certain que ce soit la bonne approche à retenir mais je ne suis pas spécialiste de ce type de programmation.

[@phamarthur479]

@@EricPeronnin Je vois. Merci Beaucoup pour votre réponse. Bonne Continuation !

[@jeanphilippelarre4218]

Merci beaucoup pour votre travail. Une question au temps 19:46 vous déclarez en static derniereTransition = 0, cela ne met pas à 0 à chaque tour de boucle? Même si static garde la derniere valeur de boucle, il n'y a pas de conflit?

[@EricPeronnin]

Non. C'est l'intérêt de la déclaration static. L'initialisation ne se fait qu'au moment de la création de la variable, c'est à dire au premier passage dans la boucle

[@jeanphilippelarre4218]

@@EricPeronnin merci beaucoup

[@albertmatin6683]

Bonsoir, merci pour ces excellentes vidéos.Mais pouvez-vous numéroter les vidéos car j'ai du mal de mis retrouver.

[@EricPeronnin]

Bonsoir. Pour vous y retrouver, regarder la playliste kzbin.info/aero/PLuQznwVAhY2V7Uh0aHOgBvaiqRw9VeCis Dès que je numérote, les vidéos de rang élevé ne sont plus vues...

[@phamarthur479]

Bonjour, À 20:10 , pouvait-on se passer de la création et l'affectation de la variable auxiliaire " _micros " et utiliser directement la fonction " micros() " à l'intérieur de la condition d'inégalité du " if " à 21:00 ? (Y a t-il une différence dans l'exécution du programme ?)

[@EricPeronnin]

Bonjour. Par habitude et à l'image de ce qui se fait dans un automate, je préfère lire les entrées du système en début de cycle (durant un cycle, on peut considérer que micros est une entrée puisqu'on utilise pour faire des tests). D'une façon générale, il y a des effets de bord possible à ne pas travailler comme ça. Il faudrait que je développe un exemple mais pas vraiment le temps d'y réfléchir.

[@pierrefellin3700]

Merci pour les videos. Pourquoi pas un condensateur pour éviter les rebonds?

[@EricPeronnin]

C'est une autre possibilité évidemment. J'en ferai état dans une autre vidéo. L'intérêt de la présente vidéo était aussi de présenter ce que sont les fronts montants et descendants, comment les prendre en compte sans interruption pour l'instant, comment penser une application à partir de l'analyse de chronogrammes...

[@gilfr33]

Le gros avantage de le faire dans le code mis à part le prix du condensateur c’est de pouvoir régler le temps de prise en compte des rebonds très facilement pour s’adapter à différents poussoirs ou au vieillissement. Le coût de la mise à jour d’un firmware n’a rien à voir avec le coût d’un remplacement de condensateur.

[@EricPeronnin]

Effectivement Gilles, c'est un des arguments auxquels je pensais. Il serait d'ailleurs intéressant d'écrire une fonction permettant d'évaluer le temps maximum entre rebonds.

[@cani77]

La librairie Bounce semble apporter aussi assistance sur ce problème.

[@EricPeronnin]

Effectivement. Le but ici est que chacun comprenne les enjeux.

[@cani77]

Ne pas y faire mention aura une cascade d'improvisation peu optimisé. L'excellence et la confiance sont des choix peus assumés. Mettre des interruptions plutôt que des délais illustrent parfaitement ce genre de dérives.

[@adamaadam8073]

Bonjour, le programme que vous avez fait marche aussi avec les boutons de la vidéos précédentes ? Je n'ai pas le même bouton poussoir que cette vidéo et le programme ne marche pas.

[@EricPeronnin]

Bonjour. Il est possible que les connexions internes du bouton soient différentes. Testez avec un multimetre en testeur de continuité ou essayez d'autres branchements

[@leonmugisho331]

Bonsoir Professor Eric. je viens de visionner la video en entierete mais, j'ai un problem je voulais faire un montage de tel sorte que quand j'appuis une led s'allume; quand j'appuis encore elle s'eteint et une autre d'autre s'allumer, comment faire?

[@EricPeronnin]

Bonjour Léon. Il faut voir les autres vidéos sur les machines à états.

[@Fifi-jr4yg]

Merci pour cette vidéo très pédagogique. Je cherche à résoudre le même problème, mais en utilisant les interruptions. Une solution ?

[@Fifi-jr4yg]

Je viens de voir qu’il y a déjà une vidéo sur le sujet faite il y a 6 mois. Désolé. Je vais me jeter dessus. Je sens déjà que je vais me régaler. Merci

[@EricPeronnin]

Bonjour. Il y a plus de 200 vidéos sur la chaine ;-) N'hésitez pas à regarder les différentes playlistes pour faire votre marché.

[@Fifi-jr4yg]

Je viens de découvrir votre chaîne. Je mesure l’étendue des sujets traités. Merci pour votre travail et votre partage. Vous êtes passionnant.

[@nicolasvinc]

Bonjour, Petite question, que se passe-t-il si la fonction micro renvoi un débordement (arrivé aux delà de sa limite ) La soustraction pourrait renvoyer une valeur négative et le rebond non détecté si je ne me trompe pas.

[@EricPeronnin]

Réponse détaillée dans la prochaine vidéo... ;-) Ou dans les commentaires qui précèdent.

[@nicolasvinc]

Viens à point à qui sait attendre :)

[@bernardetienne6307]

Bonsoir Éric, Lorsque vous déclarez les variable en "static" il me semble que cela implique qu'elles ne sont déclarées qu'une fois et qu'ensuite elles conservent leurs dernières valeurs. Dans le boucle loop ça me semble justifié puisque la variable ne sera pas redéclarée à chaque tour, mais pourquoi ne pas le faire pour toutes les variables ? Sinon pourquoi ne pas déclarer une variable hors de loop comme une variable globale (pas recommandé) mais en static ce qui limitera sa portée au fichier où elle a été créée ? Et merci pour vos vidéos, j'espère que l'électronique pure va bientôt revenir...

[@tanguymarion6368]

Pour la première question, le static prend de la place dans la mémoire et la fin de la fonction la variable n’est pas écrasée. Si la variable n’est pas en static, alors à la fin de la fonction loop, celle ci libèrera la place qu’elle prend dans la mémoire. On pourrait déclarer toutes les variables en static, c’est faisable, à condition de bien gérer leurs valeurs quand tu repasses dans la boucle. Mais souvent c’est « plus propre » de ne pas déclarer une variable en static pour qu’elle se réinitialise correctement à chaque nouveau tour de boucle. Pour ta question sur la variable global static c’est faisable aussi, mais tout dépend de tes besoins. Je pense que tout sera plus simple à comprend quand il y aura des vidéos sur les fonctions. Le conseil que je peux te donner c’est que si tu n’as pas besoin de static et de global, ne l’utilise pas. Global c’est vraiment pour utiliser la variable ailleurs que dans la fonction loop J’espère que j’ai pu apporter un élément de réponse :)

[@EricPeronnin]

Impeccable. Merci Tanguy

[@bernardetienne6307]

Merci beaucoup, Donc tout ceci suppose que loop est une fonction appelée depuis un main (sous entendu) dans une boucle genre : main() { setup(); while(1) { loop(); } } ?

[@tanguymarion6368]

@@bernardetienne6307 oui c’est exactement ça ! (cf la première vidéo kzbin.info/www/bejne/d4GxkIpmYs2Va6M)

[@grivelator]

Bonjour, à 9:45 Pourquoi utiliser un int au lieu d'une variable booléenne?

[@EricPeronnin]

L'habitude (mauvaise). Sur les PIC que j'ai beaucoup pratiqués, les int étaient sur 1 octect. Sur les AVR, l'usage d'un int sur 16 bits est effectivement une mauvaise idée.

[@salamdiouck633]

Bonjour Monsieur Eric peronin, Message d'un fidèle abonné. Je me permets de vous contacter pour vous demander est-ce que on pourrait avoir une série de vidéos sur "la modulation et demodulation d'amplitude". Merci d'avance

[@EricPeronnin]

Bonjour. Je ferai cela un jour. Je m'apprête à faire l'acquisition d'un oscilloscope, d'une générateur et d'une alimentation de laboratoire adaptés pour faire mes vidéos. Matériel dont je ne dispose pas actuellement.

[@salamdiouck633]

@@EricPeronnin d accord

[@did3d523]

sinon delay(20); aprés detection appuis et delay(20); aprés detection relache et c tout (ok ca bloque un peu le code a ce moment mais ca depend du besoin) moi pour une telecomande ct pas un problem

[@EricPeronnin]

Le but était évidemment de montrer comment éviter ce blocage. L'intérêt pédagogique est de montrer comment gérer des évènements sans blocage.

[@technophile01]

Salut professeur. Est ce qu on ne pourrait pas résoudre le problème des rebonds en mettant un petit"delay" juste avant le changement d état de la led ? Je l ai essayé dans une application irremote et ça marche.avant la led ne s allumait pas(ir send)...

[@EricPeronnin]

Il n'y a pas unicité de la solution. L'approche avec un délai non bloquant est plus élégante et permet de spécifier un temps entre rebond donc plus faible qu'un temps de délai qui doit englober tous les rebonds potentiels. Notez et je ne l'ai pas dit que dans un programme qui comprend beaucoup de code, le programme lui même fait office de délai et les rebonds sont filtrés sans aucun traitement. Il reste que cette approche nécessite d'être certain du délai minimum de traitement de la boucle principale.

[@stephanefouret304]

Notre Professeur a quelques aversions pour les delay auxquels il prefere les milli et autres micros afin de ne point leser le temps de traitement . les delay sont rigolos mais si tu en a plusieurs , tu est vite perdu dans des loop à rallonge ( de temps bien sur )

[@EricPeronnin]

@@stephanefouret304 Votre professeur a raison ;-)

[@stephanefouret304]

Bonjour à tous , quelqu'un sait il pourquoi on ne peut plus acceder a www.mon-club-elec.fr ? C'est là que j'avais toutes les references au language arduino ...

[@EricPeronnin]

Aucune idée. Je ne connais pas ce site. En fait, je ne connais que les sites des constructeurs. D'autres auront peut-être une solution. Ou peut-être que le serveur est tombé temporairement.

[@wattezhercule9474]

Bonjour j'ai récupéré avec un analyseur Logic une trame RF 2400bds en signal serie asynchrone inverse. Comment inverser les séries de bits avec Arduino j'ai utilisé ceci " vague X crochet i crochet" dans une boucle for mais le signal que je produit n'est pas identique, X étant la variable ou je stocke mes bytes. Help

[@EricPeronnin]

Bonjour. Je ne comprends pas votre question. Pouvez-vous expliquer point par point ce que vous faites et ce que vous souhaiteriez obtenir ?

[@wattezhercule9474]

@@EricPeronnin Bonjour et merci. J'ai une télécommande 433MHz (ref SH4....) pour des prises de courant. Je parvient avec Saleae logic a décoder les groupes de 8 bits il y en a 127 plus 8 au début de trame et 8 autres en fin de trame -- > c'est un protocole EEE802.5 ce qui corresponds à ce que j'ai trouvé dans la datasheet du SH4. Je souhaite utiliser la liaison série (sérial Softwares) pour reproduire ces groupes de 8 bits Pour pouvoir décoder le signal avec saleae logic, j'ai cocher "signal invert", choisi "serie asynchr" et régler 2400bauds --> ça marche aucune erreur. Je me retrouve avec 144 groupes de 0 et 1, dans mon programme Arduino je les ai stockés dans une constante de type: const byte X[ ]={0b11111111, 0b1010010, ....} . J'essaie avec une commande serialsoft.write ( ~ X[i]), j'arrive ainsi à inverser les 0 et les 1. Cependant quand je repasse ce signal dans saleae logic avec les paramètres pour la télécommande je vois bien que c'est pas pareil. Je pense qu'il faudrait que le signal parte d'un niveau bas pour passer à haut, avant d'envoyer mais comment faire. Enfin j'enverrai ce signal sur un module émetteur 433Mhz. Si tous cela fonctionne je passerai ensuite a l'étape de voir ce qui change dans la trame entre On et Off , et où se trouve l'adressage pour chacune des prises. PS je cherche une solution logiciel, car j'ai déjà un système qui fonctionne avec des prises télécommandées moin complexe (bibliothèque Arduino RcSwitch.h), le tous sur un PCB que j'ai pu faire grâce à vos cours de kicad 😉.

[@EricPeronnin]

Bonjour. Pas facile d'y voir clair. J'ai un doute sur l'ordre des bits. Etes-vous certain que l'envoi respecte l'ordre que vous avez supposé être le bon au moment du stockage entre les bits de poids fort et de poids faible ?

[@wattezhercule9474]

@@EricPeronnin Bonjour, je parvient à envoyer les bit dans l'ordre adéquat, je l'ai vérifier avec le moniteur série. Le pb se situe au niveau des start bit et stop bit ( ils ne sont pas inversé eux), je pense éditer la librairie Sérial software, pour y ajouter une fonction supplémentaire que j'appellerai writeinverse. Je vous tiendrai au courant. Merci

[@wattezhercule9474]

Bonjour Comme promis je reviens vers vous. J'ai édité le fichier SoftwareSerial.ccp et voilà le code que j'ai trouvé à la ligne 249: SoftwareSerial::SoftwareSerial(uint8_t receivePin, uint8_t transmitPin, bool inverse_logic /* = false */) : _rx_delay_centering(0), _rx_delay_intrabit(0), _rx_delay_stopbit(0), _tx_delay(0), _buffer_overflow(false), _inverse_logic(inverse_logic) { setTX(transmitPin); setRX(receivePin); } "bool inverse logic".... Ah si j'avais su, juste un petit paramètre Je vais donc me mettre à VScode, cela m'aurais surement évité tous ce temps d'investigation. Merci encore pour toute vos vidéos ! Es ce que vous utiliser github.com, j’avoue que quelque vidéo sur le sujet me plairais beaucoup. Bon weekend

[@mekimr9736]

Sacrés problème que sont les rebonds, d'autant plus que ce n'est pas censé arriver !

[@electronic10]

Merci pour vos vidéos! J'ai vu un article intéressant concernant le "debouncing" : my.eng.utah.edu/~cs5780/debouncing.pdf . Il y est inclut la technique de la bascule SR qui serait performante et très peu utilisée "...The SR circuit is the most effective of all debouncing approaches... but it’s rarely used...". Une configuration de bascules D est même utilisé par Microchip dans "Robust Debouncing with CIPs - Microchip Technology"...

[@samuelcare6398]

Merci Eric