Premier programme embarqué

Une broche GPIO sait tout faire : écouter un bouton ou commander une LED. Mais au démarrage, elle ne sait pas encore ce qu'on attend d'elle. Le premier travail de setup() est de le lui dire : « la broche de la LED est une sortie ». C'est une configuration, pas une action — on la pose une fois, elle vaut pour toute la vie du programme, comme le réglage d'un instrument avant le concert.

Prends ce réflexe de tri dès le premier jour : tout ce qui PRÉPARE va dans setup() — déclarer les broches, ouvrir la liaison série, poser les valeurs de départ. Tout ce qui AGIT ou DÉCIDE va dans loop(). Un programme dont la préparation traîne dans la boucle refait mille fois un travail d'une fois : il marche souvent… mais il pense mal, et il finit par le faire payer.

Allumer une LED, c'est mettre sa broche à l'état haut : la broche impose alors la tension d'alimentation, le courant circule à travers la résistance de limitation et la LED — lumière. La mettre à l'état bas la ramène à zéro volt : plus de courant, extinction. Deux ordres, deux états, rien d'autre : c'est le niveau haut et le niveau bas du monde numérique, appliqués à ta première sortie.

Détail capital pour lire le blink : une broche CONSERVE le dernier état écrit. Pendant « attendre 500 ms » — le fameux delay(500) — le programme s'immobilise, mais la broche, elle, ne change pas : la LED reste allumée toute l'attente. Le clignotement ne vient donc pas d'un ordre « clignote », qui n'existe pas : il naît de l'alternance écrite noir sur blanc — haut, attendre, bas, attendre.

Dans loop(), le blink tient en quatre lignes : état haut · attendre 500 ms · état bas · attendre 500 ms. Le tour complet dure 1 000 ms : un éclat par seconde. À l'oscilloscope, la broche dessine un créneau parfait — un plateau haut d'une demi-seconde, un plateau bas d'une demi-seconde — le tout premier signal que TON code impose au monde réel.

Le blink est le « bonjour » de l'embarqué, et surtout son thermomètre : s'il clignote, c'est que toute la chaîne fonctionne — éditeur, compilation, câble, flash, carte. C'est le premier réflexe des professionnels devant une carte suspecte : téléverser un blink. S'il bat, le matériel est hors de cause et le problème est dans le programme ; s'il ne bat pas, inutile de chercher plus loin dans le code.

Au clic sur « téléverser », tout s'enchaîne : la compilation vérifie et traduit, les instructions descendent le câble — sur beaucoup de cartes, de petites lumières papillotent pendant le transfert — puis la carte redémarre et exécute TON code : setup() une fois, loop() sans fin. Quand la LED de la carte se met à battre, savoure : c'est la première fois qu'un objet physique obéit à un programme que tu as écrit.

Si rien ne clignote, garde la tête froide et vérifie dans l'ordre : le câble — certains ne transportent que la charge, pas les données — puis la carte sélectionnée dans le menu de l'éditeur. Ces deux-là expliquent l'écrasante majorité des téléversements muets. Le code ne vient qu'en troisième : c'est toute la beauté du blink, il est trop court pour cacher longtemps une erreur.