Projet guidé : le carrefour
Ce que ce chapitre apporte
- 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.
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 passe au rouge à 4, 11 puis 18 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.
É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.
Exercices type
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.
Vérification
1.Pourquoi une version à base de delay ne peut-elle pas satisfaire l'étape 2 ?
2.À quoi sert la variable demande de l'étape 3 ?
3.Pourquoi l'état VOITURES_VERT attend-il quatre secondes avant de servir une demande ?
4.Comment vérifier qu'un vert piéton ne s'allume jamais avec le vert des voitures ?
5.Que fait la fonction changerEtat ?
La méthode
- Écrire le cahier des charges en règles courtes et vérifiables avant tout diagramme.
- Dessiner le diagramme d'états, une flèche par transition, avec son événement.
- Construire par étapes : un programme qui fonctionne à chaque étape, une exigence de plus à la suivante.
- Lire les entrées à chaque tour, dans tous les états, et mémoriser les événements qui ne peuvent pas être servis tout de suite.
- Regrouper les durées en constantes, et les états dans un
enum. - Vérifier les règles de sécurité sur le comportement, en provoquant les cas défavorables : appui trop tôt, appui pendant la traversée, appuis répétés.
Synthèse
- Un projet se construit par étapes, chacune donnant un programme qui fonctionne.
- Le feu est une machine à états ; chaque durée se mesure par
millis() - debutEtat. - Une version à
delayperd les appuis survenus pendant les pauses, et ne peut pas attendre un appel. - Le bouton se lit à chaque tour, avec un anti-rebond qui ne bloque pas.
- Une demande mémorisée découple l'instant de l'appui de l'instant où il est servi.
- Les règles de sécurité deviennent des états ou des conditions explicites, et se vérifient sur le comportement observé.