Bonsoir,
pour le #163, je ne comprends pas ton problème.
pour le #164 :
si tu enregistre la moitié de l'angle en degré dans l'EEPROM, alors tu ne dépassera jamais 360/2=180.
Sinon, pour le reste du message, est-ce que tu peux être plus explicite :
- "il calcule 360°" ne veut rien dire : dis moi telle variable, à tel endroit du code, à telle date vaut 360
- "il s'arrête à quelque degrés de 0 °" : tu parles de la turntable physique (vu que tu ne semble pas distinguer la physique du code correspondant)? Si oui, es-tu sur qu'elle était parfaitement à "0" au début du mois? Et qu'elle n'a jamais été bougée manuellement par mégarde (ou bougée par un bout de code)?
- "il affiche 0° au lieu de 10°" : qui affiche? : quelle est la variable affichée? à quelle ligne du code? Sachant que dans le code du #164, il n'y a rien qui affiche une valeur.
- "du coup quand il calcul le premier jour du mois de mars il affiche 0° au lieu de 10" tu semble dire qu'une erreur de calcul découle d'une erreur dans la position du turntable physique, ce qui me semble absurde. Du coup, que veux tu dire? Tu as connaissance d'un lien de causalité, ou s'agit-il d'une hypothèse?
Si tu penses qu'ajouter 2 lignes de codes pourrait résoudre le problème, alors teste au lieu de poser la question.
Pour être honnête, le débogage est toujours la partie la moins amusante (pour ne pas dire la plus chiante) de la programmation. C'est déjà long et pénible dans le meilleur des cas, quand on débogue son propre code (que l'on connait donc bien) et que celui-ci a été écrit de manière propre et bien structurée de manière à faciliter les tests. Hors, ici, c'est tout le contraire. Quand on utilise en plus du hardware, le débogage devient encore plus compliqué. Mais quand on n'a même pas le hardware en question sous la main, et que le code est écrit de telle manière que rien n'est modulaire et que du coup rien ne peut être testé sans avoir le matériel, alors le débogage devient extrêmement difficile (la méthode usuelle de débogage consistant à effectuer des tests successifs de manière à trouver de plus en plus précisément où se trouve l'erreur). Si en plus de ça tu ne me décrit pas de manière TRÈS PRÉCISE ce qui se passe et quel est le problème, alors c'est quasi impossible.
Franchement, déboguer le code des autres ne m'amuse pas, et ne m'apporte généralement pas grand chose (contrairement à d'autres questions qui me font réfléchir sur des aspects de la robotique que je n'avais spas encore abordé sous cet angle). Si je t'aide, et que j'y passe un temps considérable que je pourrais consacrer à des projets qui m'intéressent plus, c'est uniquement dans le but de te rendre service. La moindre des choses serait que tu fasse tout ton possible pour que je puisse t'aider de manière aussi efficace que possible.
Du coup, à partir de maintenant, je te demanderais, pour chaque question/problème :
1) formuler explicitement le problème
2) de mettre en pièce jointe la dernière version du code complet
3) mettre les parties du code que tu penses être pertinantes
4) décrire précisément tout ce que tu observe (position du turntable, qu'est-ce qui s'affiche sur l'écran, qu'est ce qui s'affiche dans le moniteur série) et quand. Précise également où dans le code ses valeurs sont affichées (au moins pour celles que tu penses être pertinentes). Penses également à préciser la date du jour.
5) fait une copie du code, dans laquelle tu affiche toutes les variables qui pourraient jouer un rôle : donne moi ces valeurs, ainsi que le code en question (soit les parties modifiées, soit tout le code), en précisant bien les lignes qui provoquent l'affichage.
6) fais des tests toi même avant de poser la question sur le forum.
Si tu ne fais pas cet effort de ton coté, alors ne comptes plus sur moi pour passer des heures à essayer de résoudre tes problèmes.
Et une chose encore : une fois que les deux problèmes en cours seront résolus (ou même avant si tu préfère), on va re-voir ton code en profondeur de manière à le rendre plus modulaire, et donc plus facile à déboguer. Ça consistera entre autre à utiliser des fonctions avec argument et retour, à éviter autant que possible les variables globales, ... Une bonne partie de ces choses je te les ai déjà suggéré plusieurs fois, mais tu n'as jamais voulu écouter mes conseils sur les bonnes pratiques de programmation (qui sont faites pour gagner du temps sur le long terme en aidant à trouver et corriger les erreurs). Si tu ne veux pas suivre ces bonnes pratiques, c'est ton choix, mais dans ce cas ne comptes plus sur moi pour trouver les erreurs dans ton code.
Bonne soirée
Sandro