Projet guidé : le carrefour
Ce que ce chapitre apporte 5 points
- Construire un programme par étapes, en gardant à chaque étape un programme qui fonctionne.
- Traduire un cahier des charges en diagramme d'états, puis en programme.
- Faire réagir un feu à un appel piéton à tout instant, sans attendre la fin d'un cycle.
- Mémoriser une demande et la servir au moment autorisé.
- Vérifier des règles de sécurité sur le comportement observé, et pas seulement à la lecture du code.
Un feu de circulation avec bouton piéton réunit tout le parcours : des sorties, une entrée qui rebondit, des durées, et surtout un comportement qui doit réagir à tout instant. On ne l'écrit pas d'un bloc. On le fait grandir en trois étapes, chacune donnant un programme qui fonctionne, et chacune ajoutant une exigence. La première version qui vient à l'esprit, une suite de delay, échoue à la deuxième étape, et comprendre pourquoi est l'objet même du projet.
Le montage
| Composant | Broche | Remarque |
|---|---|---|
| Feu voitures rouge | 13 | LED et résistance de 220 Ω vers GND |
| Feu voitures orange | 12 | idem |
| Feu voitures vert | 11 | idem |
| Feu piétons rouge | 10 | idem, ajouté à l'étape 3 |
| Feu piétons vert | 9 | idem, ajouté à l'étape 3 |
| Bouton d'appel | 2 | entre la broche et GND, configuré en INPUT_PULLUP |
Étape 1 : le feu seul
Le feu tourne de lui-même : vert quatre secondes, orange une seconde, rouge quatre secondes. Pas encore de bouton, mais déjà la structure définitive : une machine à états et millis().
Deux fonctions portent toute la mécanique. allumerSeul garantit qu'un seul feu est allumé, quel que soit l'état précédent. changerEtat note l'instant d'entrée dans le nouvel état : chaque durée se mesure alors par millis() - debutEtat, sans delay.
Que fait la fonction changerEtat ?
vert, delay(4000), orange, delay(1000), rouge, delay(4000) donne le même feu, plus court à écrire. Le défaut apparaît à l'étape suivante. Une version de ce type, qui lit le bouton au début de chaque cycle, a été simulée : sans aucun appui, le feu quitte le vert à 4, 13 puis 22 secondes, alors que le cahier des charges veut qu'il reste au vert ; et un appui donné à 8 secondes, pendant une pause, est tout simplement perdu.
Étape 2 : le bouton qui appelle
Le cahier des charges change : le feu reste au vert tant que personne n'appelle. Un appui déclenche immédiatement l'orange, puis le rouge pendant cinq secondes, puis le retour au vert, où le feu attend de nouveau.
Le bouton est lu à chaque tour, dans tous les états, par l'anti-rebond du chapitre 5. Simulé, ce programme reste au vert indéfiniment sans appui ; un appui donné à 8 s fait passer à l'orange à 8,036 s, les 36 ms venant des rebonds puis des 30 ms de stabilité exigées, au rouge à 9,036 s, et rend le vert à 14,036 s.
Pourquoi une version à base de delay ne peut-elle pas satisfaire l'étape 2 ?
Étape 3 : les piétons et la sécurité
Le cahier des charges complet ajoute un feu piéton et quatre règles.
- Le feu piéton n'est jamais vert tant que les voitures ont le vert ou l'orange.
- Les voitures gardent le vert au moins quatre secondes : un appel trop précoce attend.
- Un appel donné à n'importe quel moment, même pendant une traversée, est mémorisé et servi au cycle suivant.
- La fin de traversée est signalée par un vert piéton clignotant, puis une seconde où tous les feux sont rouges avant de rendre le vert aux voitures.
La demande est la clé de cette étape. Un appui ne provoque plus directement une transition : il lève un drapeau, demande = true, quel que soit l'état. Seul l'état VOITURES_VERT le consulte, et seulement une fois le vert minimum écoulé. C'est ce qui permet de ne perdre aucun appel sans jamais écourter le vert des voitures.
1.À quoi sert la variable demande de l'étape 3 ?
2.Pourquoi l'état VOITURES_VERT attend-il quatre secondes avant de servir une demande ?
Vérifier le comportement, pas seulement le code. Les règles de sécurité ont été vérifiées sur le comportement simulé, toutes les 5 ms pendant 40 secondes, avec des appuis donnés au pire moment : exactement un feu voitures allumé à tout instant, jamais de vert piéton avec le vert ou l'orange des voitures, jamais le rouge et le vert piétons ensemble. Relire le code ne suffit pas à s'en assurer : une règle de sécurité se vérifie sur ce que fait le programme, instant par instant.
Faire vérifier les règles par la carte
La même vérification se fait sur le montage, avec la trace du chapitre 8. Trois ajouts au programme de l'étape 3 suffisent : ouvrir la liaison dans setup(), tracer chaque changement d'état dans changerEtat, et contrôler les sorties à la fin de chaque tour.
Sur une broche en sortie, digitalRead rend le niveau que le programme y a écrit : la fonction contrôle donc exactement ce que voient les feux. La trace ne coûte presque rien, cinq lignes courtes par cycle, et ne change pas le rythme du feu. Un appel à 10 s, validé 30 ms plus tard par l'anti-rebond, doit produire 10030 -> 1, 11030 -> 2, 15030 -> 3, 17030 -> 4, 18030 -> 0, et aucune ligne REGLE VIOLEE, même en multipliant les appuis au pire moment : pendant l'orange, pendant la traversée, juste avant la fin du vert minimum.
Comment vérifier qu'un vert piéton ne s'allume jamais avec le vert des voitures ?
Mettre en pratique
Au démarrage de l'étape 3, un piéton appuie au bout d'une seconde. Quand les voitures passent-elles à l'orange ?
À 4 secondes. L'appui lève la demande dès qu'il est validé, vers 1,03 s, mais l'état VOITURES_VERT ne la sert qu'une fois le vert minimum de quatre secondes écoulé depuis son entrée, à l'instant 0.
La simulation le confirme : orange à 4 000 ms exactement.
Un piéton appuie pendant la traversée d'un autre. Son appel est-il perdu ?
Non. L'appui lève demande, qui n'est consultée ni pendant la traversée, ni pendant le dégagement. Au retour du vert voitures, la demande est toujours levée : les voitures passent à l'orange quatre secondes après le retour au vert, dès que le vert minimum est écoulé.
Dans la simulation, un premier appel à 10 s donne l'orange à 10,036 s ; un second, donné à 13 s pendant la traversée, donne un nouvel orange à 22,036 s, soit quatre secondes après le retour du vert à 18,036 s.
Combien de temps les voitures sont-elles arrêtées à chaque appel ?
De la fin du vert au retour du vert : orange 1 s, traversée 4 s, clignotement 2 s, dégagement 1 s, soit 8 secondes.
Les voitures ne sont vraiment à l'arrêt, feu rouge, que pendant les sept dernières. Toutes ces durées sont des constantes en tête du programme : un réglage ne demande de toucher aucune ligne de la machine à états.
Pourquoi l'étape 3 exige-t-elle une seconde où tous les feux sont rouges ?
Un piéton engagé au dernier moment du clignotement est encore sur la chaussée quand celui-ci se termine. Rendre le vert aux voitures à cet instant précis les ferait démarrer vers lui.
L'état DEGAGEMENT laisse une marge. C'est une règle de sécurité, et elle s'écrit comme un état à part entière du diagramme, et non comme un delay glissé entre deux lignes : elle reste ainsi visible, réglable, et vérifiable.
Chapitre révisé en octobre 2026 · Une erreur dans ce chapitre ?