La plaie des fuses mal réglés dans la communication

Il m’est arrivé un problème très bête, mais qui guette quiconque tente de travailler avec une interface de communication. Dans mon cas, il s’agissait d’un port série, que j’avais déjà réussi à faire fonctionner mille fois.

L’enfer du débogage

Cependant, ici, ça ne marchait pas. J’étais dans une nouvelle configuration par rapport à mon habitude. En effet, j’ai tendance à utiliser la même tension (5V) sur tout mon circuit, et vu que mes montages consomment peu, je n’ai aucun problème à utiliser une alimentation provenant d’un port USB, et qui plus est, à utiliser l’alimentation proposée par une clef USB de communication série TTL.

Mais dans le cas présent, j’avais dans l’idée de faire communiquer un montage, utilisant sa propre source d’énergie (tirée depuis une alimentation 12V, laquelle était abattue ensuite par un régulateur de tension à 5V), avec une clef USB identique au montage précédent. Pas moyen.

Je met tout d’abord en cause ma nouvelle installation (j’ai porté tout mes scripts et Makefile sous Linux, étant bien plus à l’aise avec ce système). Je reprend donc tout sur Windows 8. Ça ne fonctionne pas.

On va essayer plus simple

Alors, c’est mon projet qui doit être douteux. Je sors donc des cartons le premier projet que j’ai déployé avec une connexion série. Je le compile, et l’envoie sur le microcontrôleur. Boum, ça ne marche pas. Petit coup de stress.

Je doute maintenant de mon montage, et je commence à chercher un peu de détails sur le net. J’ouvre les spécifications série TTL et tout me semble correct. Je me résous donc à faire un montage plus simple, identique à mon premier essai concluant, et là, cela ne marche pas.

Le même montage, le même code, la même clef, sur la même machine.

J’abandonne ce soir là. Je rumine, je cherche sur Internet, je ne trouve rien relatif à ce problème. Je prend même un ATMega tout neuf pour tester le code ; même problème.

Mais bordel !

Dépité, Je démarre un terminal série un peu plus poussé afin de voir ce qui se passe en bas niveau (binaire). Les caractères sont indéchiffrables, mais quelque chose attire mon attention : Les codes hexadécimaux reçus ne sont que des 0x00 et 0x80. Et enfin je comprend !

Dans l’entête de mon code je précise la cadence de l’horloge, qui n’est pas celle par défaut. Or, j’utilisais dans mes tests des microcontrôleurs neufs ! Ceux-ci fonctionnaient à la fréquence d’usine, et lors de la mise en route, la configuration de la communication série s’établit avec celle que je donne en entête. Le microcontrôleur communique donc à une vitesse différente de celle attendue, et bien entendu, il n’y a aucun moyen de le déterminer.

Il y a deux solutions dans mon cas :

  • changer la cadence au niveau de mon code, pour utiliser la fréquence d’usine
  • reprogrammer les registres « fuses » du microcontrôleur afin d’utiliser la fréquence définit en entête (ce que j’ai fait).

Soulagé !

Et tout de suite, cela marche beaucoup mieux ! Ainsi, si vous vous sentez bloquer lors de l’utilisation d’une fonctionnalité dépendant d’une base de temps (communication, synchronisation, … tout en fait !), pensez à vérifier ces foutus registres !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*