Arduino UNO etc : Gérer les débordements de micros() et millis() après 1H11... et 49 jours...

[@paulragot6155]

Merci Eric. L'overflow : sujet délicat mais parfaitement expliqué.

[@EricPeronnin]

Merci Paul.

[@jfmahe1407]

Merci.

[@Victurf]

Une vidéo d'une grande importance! Merci!

[@patrickfle4485]

Bonjour. Un bug potentiel à connaître, Bien vu et merci !

[@ericjalbert9433]

Merci! C'est exactement le genre de réflexion que j'aurais pas pensé faire!

[@nicolasvinc]

Très bonne réponse à mon commentaire sur votre précédente vidéo. Cela me permet de comprendre mieux le mécanisme de débordement et l’impact sur la fonction mathématique à utiliser. Chose que je n’avais pas vu dans ma formation GEII (orienté électrotechnique) ;)

[@eliegedeonbikieyoudonangou5728]

Bonjour ! Merci pour vos vidéos. J'aime beaucoup l'approche pédagogique que vous adopter dans vos vidéos. Ce sont pas que des exemples que l'on reproduit sans comprendre, mais tout est très bien expliqué de sorte à nous mettre en mains les outils et nous permettre de faire ensuite ce que nous voulons ! Merci beaucoup Monsieur ! Dieu vous bénisse !

[@stephanefouret304]

Bonjour , comme toujours trés interessant , je me le grave en mémoire pour une prochaine application

[@EricPeronnin]

Important de s'en souvenir en effet car le risque de générer un bug difficile à trouver est important.

[@patricktuchais7596]

Merci Eric, c'est extrêmement instructif!

[@mikl5228]

Suite un une de vos vidéos, je me suis acheter un bitscope 9 canaux. Je m'amuse à voir les trames i2c. C'est très intéressant. Merci à vous

[@EricPeronnin]

C'est le bitscope BS05U ou l'analyseur que je proposais en lien que vous avez acquis ?

[@mikl5228]

AZDelivery Logic Analyser. 8 voies

[@EricPeronnin]

C'est un produit très intéressant et ce qu'on visionne avec est très instructif. En passant, j'attends toujours le mien... J'ai l'impression que tous ceux qui l'ont commandé l'ont reçu, sauf moi !

[@sylvainmasson4457]

Difficile d’être plus claire. Excellente démonstration! Dans ma pratique avec millis() j’utilise plutôt des entiers 16 bit pour éviter des calculs sur 32 bit. Surtout avec un microcontrôleur 8 bit. Cela permet des délais de 65 sec qui est la plupart du temps suffisant. Cependant pour éviter des surprises, sauvegarder le résultat de millis() dans une variable temporaire 16 bit avant d’effectuer la comparaison: uint16_t msec; static uint16_t last_msec = millis(); msec = millis(); if (msec - last_msec >= PERIOD) { last_msec += PERIOD; ....etc.... }

[@EricPeronnin]

J'évoquais dans une autre réponse la possibilité de passer sur 8 bits pour certains cas. Tout dépend des besoins. J'aurais du aborder cela dans cette vidéo mais n'y ai plus pensé. Merci pour le rappel

[@pierredieu1620]

Bonjour, compter réaliser une vidéo sur comment gérer une action coute (LED rouge allumée) ou longue (LED verte allumée) avec un seul BP . Merci pour votre travail

[@mikl5228]

euh la vous m'avez perdu quand vous avez commencer a parler du "complément a 2" .... Certes, je peux chercher de mon coté, mais en lisant la vidéo ce n'est plus vraiment facile de vous suivre. Ceci n'est pas du tout une critique, je vais me documenter sur ce complément a 2 (mes cours d'électronique sont assez vieux (environ 20 ans). Je regarderai cette vidéo une fois que je me serais mis a jours sur le sujet. Ceci dit, vous traitez vraiment sur un sujet de fond où cela peut tous nous handicaper dans notre code ! bravo !

[@EricPeronnin]

Pour vous mettre à jour, il faut voir la série de vidéos les nombres et l'ordinateur : kzbin.info/aero/PLuQznwVAhY2VQOjfkOiqNPpxVnR_Z6GrI

[@mikl5228]

@@EricPeronnin effectivement c'est plus claire en révisant.... Mais sur Arduino, où peut on récupérer le bit de débordement? Ça peut être utile parfois non?

[@mikl5228]

Une question: période traitement est codé sur 32 bits, vu qu'on lui affecte 200 ( qui tient sur 8 bits) . Ça revient à dire qu'il faut dimensionner ses variables de la même façon en cas de calculs entre eux? Aurait on eu le même résultat si on additionné micros( 32 bits) avec période traitement (200) sur 8 bits? Merci

[@EricPeronnin]

Il est toujours plus sage pour éviter des effets non prévisibles de manipuler des données de même type. Le C est un langage parfois trop permissif. Dans le pire des cas, on peut opérer un transtypage pendant l'opération mais encore une fois, je préfère une approche rigoureuse avec un type identique et ce d'autant plus que dans le cas du const, ça ne consomme rien en mémoire.

[@mikl5228]

@@EricPeronnin merci

[@antibullingl1032]

,j'ai bossé dans l'industrie... le mieux c'etait de vérfier si micros(); soit inférieur à tdebut le plus souvent on dit que la tempo est terminée. pour etre rigoureux faut faire if ( ( temps < tdebut && 0xFFFFFFFF - tdebut + temps >= PERIODE) || (temps >= tdebut && temps - tdebut >= PERIODE) ) { tdebut = temps ; lance_mesures (); } et dans l'industrie faut savoir pour qui on travaille. si c'est pour de la machine à laver et que l'on mette une tempo de 2h en microsecondes.

[@EricPeronnin]

L'expression proposée n'amène rien de plus en terme de rigueur. La connaissance du fonctionnement des opérations arithmétiques dans un microprocesseur répond déjà précisément et de façon très rigoureuse à la problématique. Bien sûr, vous avez raison de préciser qu'il est important de savoir de quel délai on parle et de la pertinence d'utiliser millis() ou micro().

[@wolframwolfram2192]

Bonjour Eric Peronnin Je ne veux pas jeter de l'huile sur le feu mais vous ne gérez pas le débordement vous écrivez un programme qui esquive le problème, ce n'est pas cela gérez un débordement.Gérez un c'est palier le problème dans n'importe quelle situation et non trouver une astuce dans un cas bien précis pour que ce problème ne vous gêne pas avec des paramètres, ou des valeurs qui évitent le plantage. Comme le dit Denis ce n'est pas votre valeur aussi grande soit elle qui vous donne raison quand vous tombez sur un os. Bon weekend quand même et prenez soin de vous.

[@EricPeronnin]

Bonjour. La discussion avec Denis a mal commencé puisqu'il a débuté en disant que ce que je faisais était faux et non pas que ce que je faisais ne répondait pas au problème plus général, sans d'ailleurs expliqué ce qu'il entendait par général. Qu'est-ce que serait une solution générale ? Qu'est-ce qu'on cherche à faire ? Mesurer le temps qui s'écoule de façon absolue avec une résolution supérieure à 32 bits ou être capable de détecter qu'une certaine durée (sur 32 bits) s'est écoulée depuis un instant de référence ? La vidéo propose de répondre à la seconde question en veillant à ce que les débordements de millis() ou micros() n'aient pas d'incidence. Sur la question de mesurer le temps qui s'écoule en gérant les débordements de millis() ou micros(), c'est à dire finalement de réaliser un millis() sur plus de 32 bits, je trouve cela totalement inutile. Et pour cause : la précision de l'horloge des cartes de type Arduino Uno rend totalement inutile le calcul d'un tel timestamp qui se révèlera faux de +/-15mn par an. Ca se fait sur les RPi parce que ce sont des systèmes Linux et cela se fait à l'échelle de la seconde. Chaque fois qu'on veut réaliser un système embarqué capable de mesurer le temps qui s'écoule correctement, on utilise un circuit d'horloge temps réel (RTC). Et si on veut mesurer le temps absolu plus longtemps, quel intérêt de rester à l'échelle de la milliseconde ? Le timestamp Unix est à l'échelle de la seconde. Autant implémenter une sorte de timestamp à la mode RPi. uint32_t timestamp = 0; uint32_t getTimestamp() { static uint32_t dernierMillis = 0; while ((millis() - dernierMillis) >= 1000) { dernierMillis += 1000; timestamp++; } return timestamp; } Note : il y aura aussi débordement à un moment avec timestamp sur 32 bits. On peut passer à 64 bits... Je ne vois pas de solution générale à la gestion des débordements de millis() et micros() mais différentes solutions correspondant à des différents objectifs à atteindre en gérant correctement ce problème de débordement.

[@wolframwolfram2192]

Je comprends Denis, vous aurez raison à n'importe quel prix!

[@EricPeronnin]

Je n'ai pas raison, je défends un point de vue que j'argumente et vous vous contentez d'invectives. Soyez plus constructif. Qu'entendez-vous par traitement général ? Traitement général ne veut absolument rien dire si on ne pose pas les bases d'un cahier des charges. Donc traitement pour quoi faire, dans quelle circonstance, avec quel objectif précis ? La critique est facile et je veux bien prendre en compte une remarque construite. La discussion m'intéresse vraiment mais pour le moment, l'un comme l'autre vous ne proposez rien. Proposez, argumentez... qu'on apprenne enfin quelque chose en vous lisant et je l'écris sans ironie. Votre point de vue m'intéresse si cela dépasse : ça ne marche pas; vous avez tort; c'est un cas particulier.

[@sismiwoolf4786]

Utiliser la soustraction pour éviter le problème de débordement! Et la nous avons une explication scientifique. Enfin sur la vidéo, puisque ici sa deborde Je redoutais quand même pour mon projet de remplissage 5h après lever du jour 10 minute marche, 20 d'arrêt par x fois (impaire pour observer si la marche forcé n'est pas, commence par arrêt et fini par l'arret) et quelques option détection période de l'année (2h après lever du jour), ajout ou retrait par 100 litres ou m3. Bien sûr, il faut évaluer la capacité de la pompe Le principe me permet d'utiliser des batteries en fin de vie et un remplissage plus adapter à l'éloignement lors de la garde du troupeau, si sa deborde de 100l au lieu de plusieurs m3... Bricole utile, pour les périodes de pénurie d'eau dans les sols, sa pompe passivement et sûrement. Oui il existe des boîtiers, mais là y a un problème. De la conception à l'utilisateur, il y a des bras cassé et du coup nous ne serons pas utilisateur. Le revendeur..., le plombier qui passe chez le commerçant, le commerçant qui commence à se perdre sur le catalogue à essayer d'évaluer les fonctions de la notice sans l'avoir dans les mains.

[@jean-claudechameroy8775]

Rebonjour, Après un petit vagabondage à droite et à gauche, je reviens vers ces supers cours. mais j'avoue avoir du mal à me retrouver dans les vidéos sur Arduino UNO, en particulier j'ai besoin de comprendre des soucis que je rencontre avec pinMode(). J'ai donc visualisé à nouveau la video 1A : configurer une sortie , ..... mais je ne trouve pas la suite et en règle générale je n'arrive pas à trouver une liste exhaustive des vidéos sur ce sujet bien qu'en fouillant mes notes, je retrouve une liste de 25 vidéos mais sans les vidéos 1B ... Merci de me mettre sur la piste.

[@Olivierl1970]

Vidéo toujours très intéressante. Merci. Par contre, je me pose encore une question. Que ce passerait t'il si on avait fait avant la condition : uint32_t traitementEnCours = dernierTraitement + PERIODE_TRAITEMENT; if (micro() >= traitementEnCours) { ... Dans ce cas, traitementEnCours n'aurait t'il pas fait un overflow en même temps que micro() et donc la condition aurait été vrai ?

[@EricPeronnin]

si vous revoyez la vidéo, le problème ne vient pas de l'overflow de la somme mais du fait que l'overflow peut se produire sur micros() alors que la somme est toujours à une valeur élevée. Le calcul de la somme de façon indépendante n'y changerait rien.

[@gerardmontessuit7854]

Bonjour Eric encore une vidéo au top! Un bug dans le composant? Notre ami Électro-bidouilleur kzbin.info/door/vv3bLR4Ws1GVycHG-t3dJw à tester il y a quelques temps ce petit appareil et en as fais une synthèse pour ceux que cela intéresse voici le lien de cette étude kzbin.info/www/bejne/ianOnmOLZbWmh5Y

[@EricPeronnin]

Bonjour. Pas un bug puisque l'origine est expliquée et est liée fonctionnement intrinsèque des microprocesseurs. Quant à l'analyseur logique proposé, j'en ai parlé précédemment sans offrir de test et il ne sera d'aucune aide pour ce type de problème logiciel.

[@Fifi-jr4yg]

Merci pour cette vidéo. C’était une question que j’avais et que je pensais qu’il fallait traiter par la valeur absolue. Mais votre démonstration est éclatante. Merci