Discussion :

[cobra38]

Bonjour à tous

Je tourne en rond avec ce petit programme sous wokwi
http://wokwi.com/projects/424243477486689281

je voudrais savoir svp selon vous pourquoi :
- à l'initialisation , il affiche le code "1000" au lieu de "0000" alors le code est initialisé à zéro
- seul premier chiffre la roue codeuse part dans le sens contraire des aiguilles d'une montre mais pas les autres chiffres lorsqu'on veut incrémenter les chiffres

un grand merci par avance
pascal

[Obsidian]

Hello,

Je ne suis pas familier de l'Arduino, donc il m'a fallu un moment pour me familiariser avec le langage, qui ressemble beaucoup à du C mais qui n'en est pas tout-à-fait, si bien que les particularités des initialisations du langage ne peuvent pas forcément être garanties. Il y a bien un bug dans ton programme mais j'ai l'impression que le compilateur l'est aussi (au moins dans le traitement de certaines chaînes)…

- à l'initialisation , il affiche le code "1000" au lieu de "0000" alors le code est initialisé à zéro

Oui, mais au démarrage, currentStateCLK et lastStateClk ne le sont pas. Leur valeur est indéfinie aux lignes 426 et 427, si bien que la première itération de ta boucle détecte quand même cela comme un premier appui en ligne 442, avant que tout cela rentre dans l'ordre.

Par contre, j'ai l'impression que l'opérateur « + » de la classe String (documentée ici) fonctionne mal, lui aussi. Tes chiffres s'affichent correctement mais lorsque je remplace le contenu de println() par String(56) + String(72), j'obtiens 72 à l'écran et pas 5672…

Je te suggère plutôt de calculer la valeur du code en amont dans un int puis de l'afficher en une fois, par exemple avec :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

display.println(pottentionalvalue[0]*1000 + pottentionalvalue[1]*100 + pottentionalvalue[2]*10 + pottentionalvalue[3]);

… le mieux étant de le déposer dans une variable dédiée dès la ligne 453 et ne travailler qu'avec elle ensuite (UPDATE : je m'aperçois que c'est ce que tu fais en fin de fonction, mais tu n'es pas obligé de recourir à pow(). C'est propre d'un point de vue mathématique mais c'est inutilement long à calculer).

- seul premier chiffre la roue codeuse part dans le sens contraire des aiguilles d'une montre mais pas les autres chiffres lorsqu'on veut incrémenter les chiffres

Tu ne remets pas counter à zéro après usage. En tout cas, pas au bon endroit. La ligne 436 devrait se trouver à l'intérieur de la boucle while(1) et pas en dehors.

Bon courage.

[f-leb]

Je ne suis pas familier de l'Arduino, donc il m'a fallu un moment pour me familiariser avec le langage…

Enfin, tu t'y es mis, il était temps de combler cette lacune

[Obsidian]

Enfin, tu t'y es mis, il était temps de combler cette lacune

Ah, malheureusement, si c'était la seule chose que j'avais négligée pendant les sept dernières années…

Il est temps de revenir aux fondamentaux.

[cobra38]

Bonjour à tous

merci Obsidian pour la réponse rapide

Oui, mais au démarrage, currentStateCLK et lastStateClk ne le sont pas. Leur valeur est indéfinie aux lignes 426 et 427, si bien que la première itération de ta boucle détecte quand même cela comme un premier appui en ligne 442, avant que tout cela rentre dans l'ordre.

Ok je comprends, est-ce à dire que quoique je fasse j'aurai toujours 1000 à l'initialisation ?

Tu ne remets pas counter à zéro après usage. En tout cas, pas au bon endroit. La ligne 436 devrait se trouver à l'intérieur de la boucle while(1) et pas en dehors.

j'ai essayé toutes les places mais rien ne changent vraiment désolé


pascal

[Obsidian]

Hello,

j'ai essayé toutes les places mais rien ne changent vraiment désolé

Oui, pardon, ça c'était une erreur de ma part. J'ai cru que « counter » ne servait qu'à appliquer « -1 » ou « +1 » au chiffre en cours mais en réalité, il sert bien à le définir complètement. Tu peux donc le laisser à sa place initiale. PAR CONTRE, tu ne gères pas correctement les débordements (quand ton chiffre dépasse 9 ou tombe en dessous de 0). La fonction abs() en ligne 455 ne suffit pas. Il te faut au minimum un modulo 10 (mais en gérant le signe quand même) ou une paire de if/else pour tenir compte des dépassements.

Ok je comprends, est-ce à dire que quoique je fasse j'aurai toujours 1000 à l'initialisation ?

Non, pas tout-à-fait. Je vois également que tu évites d'initialiser inutilement une variable quand elle va l'être plus loin ou quand sa valeur initiale n'a pas de sens. C'est une bonne chose en soi, surtout si on les regroupe après les variables initialisées (par contre, les professeurs risquent de tiquer dessus).

En revanche, je vois && currentStateCLK == 1 en ligne 442. Or, le simulateur indique que CLK, comme pas mal d'autres signaux, est associé à une résistance de pull-up. Elle est implicite, elle n'est pas sur le schéma mais est indiquée sur l'étiquette de D2 à l'exécution quand on pose un breakpoint. Elle est donc à l'état bas quand on sollicite le bouton et il existe une macro LOW, que tu utilises à d'autres endroits, pour représenter cet état. Cela fonctionne donc mieux avec == LOW. En outre, si c'est bien comme cela que ça fonctionne et que l'on peut raisonnablement faire l'hypothèse que ce signal ne sera jamais que HIGH ou LOW, alors on peut d'emblée initialiser lastStateCLK à HIGH en ligne 426.

Par contre, même si ça fonctionne mieux en l'état, souviens-toi qu'après les 5 secondes d'affichage du logo « coffre », le code ne sera présenté qu'après avoir sollicité le bouton au moins une fois. Comme il l'était implicitement jusqu'ici, on n'avait pas conscience du problème. Ceci signifie que si ta première action sur le bouton est une incrémentation, alors tu verras quand même « 1000 » parce que le chiffre viendra d'être mis à jour par cette action.

Enfin, le simulateur est déjà suffisamment long et bugué en lui-même (surtout sur ma machine, sur laquelle les secondes du chronomètre durent au moins 1,5 seconde…). Souviens-toi que tu as toujours un delay(500) en ligne 464, ce qui t'impose d'observer une demi-seconde de délai entre chaque appui, faute de quoi il ne sera pas pris en compte.


UPDATE : je viens de faire le test sur le simulateur et en prenant en compte tous les points exposés ci-dessus, ton code finit par fonctionner entièrement. J'ai pu définir un nouveau code, tenter d'ouvrir le coffre, me faire opposer un refus en cas de mauvais code et voir le servomoteur pivoter lors de la saisie du bon code, accompagnée de l'image bitmap du coffre ouvert. Je n'ai pas tenté de définir un nouveau code a posteriori.