Chroniques d’un Arduineur débutant

Note

Si l’auteur de ce poulet est un Arduineur débutant, il a un lourd passé informatique derrière lui et les poils blancs qui vont avec 🙂

Saison 1

Suite à réception de la bébête (Arduino UNO – REV 3), j’avais résisté à la brancher en attendant les cours de Sieur Laurent ce Jeudi (merci à lui).

Jeudi soir, super motivé, je branche enfin la chose sur un PC du FabLab : non reconnu 🙁 Je me dis donc que ça doit être un driver qui manque dans la Windows 10 mais n’ayant pas les droits utilisateurs je me trouve vite bloqué…

Vendredi soir, je décide d’essayer de
brancher l’Uno sur l’un de mes Framboise Pi
, qui comme tout le monde le sait fait tourner un vrai système d’exploitation (pas un truc avec des fenêtres): résultat la bête est reconnue par le noyau (message noyau présent dans la sortie de dmseg). Par contre pas de trace du périphérique série dans /dev. Idée c’est un périphérique USB donc pourquoi ne pas essayer un lsusb : bingo la bête est reconnue sur le port est non pas un Arduino mais un ATmega16u2.Un petit tour dans la documentation m’apprend que ce composant est le chipset d’interfaçage USB/Série. Donc il me manque un driver :-((

Samedi, je ré-essaye avec un PC du Fablab sans succès puis sur un PC avec droits d’administration (merci Jean-Louis!). Malgré nos effort rien de chez rien la bête semble définitivement hors d’usage, commence bien ça :-(((

Et dimanche arrive. Quand où d’autres crétures mythologiques se reposent, je continue mon enquête (bon ça macrche pas sur dodoz mais quand même avec un vrai OS on peut quand même essayer de comprendre non!). Je tombe sur un billet intéressant sur le site Arduino. Je suis la démarche installant le dfu-programmer mais impossible de d’utiliser le lien avec le firmware à télécharger… (NDR:vive web…). Un petit tour sur github (beurk), clonage du dépôt ArduinoCore-avr, recherche et trouvage du firmware (merci find . -name *uno.hex -print ). Suite de la procédure (erase/flash/reset), redémarrage de la bête.

Allez Louia!

lsusb

Bus 001 Device 006: ID 2341:0243 Arduino SA

et ls /dev/tty*

[...]  ttyACM0   [...]

Le port est visible sur l’IDE.

Conclusion provisoire, linux +1 / windows 0 (Vous allez dire, rien de nouveau sous le soleil).

La bêtete acceptera-t-elle d’être nourrie par le premier programme Arduino de son propriétaire? La LED 13 clignotera-t-elle enfin? Vous le saurez dans la prochaine saison […suspense…(pour l’Académie françsiase)/… cliffhanger… (pour les plus jeunes)].

Saison 2

Premier test du programme de clignotement de la LED 13. Compilation OK, transmission du PC vers l’Arduino OK (le voyant RX montre une activité) par contre la zone de message indique une erreur

avrdude: stk500_getsync() attempt X sur 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding

où X va de 1 à 10 (en gros il y a 10 essais infructueux).

avrdude étant le programme qui transfère le code compilé sur l’Arduino, on déduit

  •  par la première ligne que l’Arduino ne répond pas à la demande de synchronisation
  • par la seconde ligne que le programmateur (« programmer »)
    aussi connu sous le nom de bootloader ne répond pas

Après quelques recherches, le stk500 est le système qui permet de configurer l’Arduino [NDR: c’était juste une info au passage].

Le bootloader a donc été écrasé (c’est là que je me souviens du message que j’avais du accepter pour utiliser le dfu-programmer qui disait un truc comme ça — lol — [NDR: toujours bien noter quelque part les messages
, ça peut servir par la suite].

Catastrophe! Heureusement le Fablab et ses compétences incarnées dans Paolo devrait pouvoir m’aider à résoudre le problème (encorere).

Sur ce rendez-vous pour la saison trois de cet insoutenable suspence.

Laisser un commentaire