enum et un switchLes deux premiers font dialoguer la puce avec le monde ; les trois derniers gardent votre code lisible.
Les bus de communication Machine à états finis
INPUT_PULLUP, que lit-on quand le bouton est pressé ?HIGH ?| Réponse | |
|---|---|
| 1 | Rien de fiable : c’est la zone indéterminée |
| 2 | Elle flotte : haute impédance, rien ne fixe sa tension |
| 3 | LOW : la logique est inversée |
| 4 | Non : elle tire vers 0 V, une résistance de rappel fait le HIGH |
| 5 | Le rebond du contact ; on filtre avec millis() |
| 6 | Les broches ADC1 (ADC2 est inutilisable avec le Wi-Fi) |
| 7 | Un MOSFET « logic level », et une diode de roue libre |
Haute impédance, open-drain et millis() reviennent aujourd’hui, avec l’I2C et la game loop.
GPIO et monde numérique ADC et PWM
Faire dialoguer les composants
L’écran de l’atelier (240 × 320) reçoit 76 800 pixels par image, soit plus de 150 000 octets en couleur 16 bits. Un capteur renvoie une température sur 16 bits. Une carte SD, des blocs de 512 octets.
Câbler un fil par bit serait impraticable : plus aucune broche disponible, une carte illisible, et des perturbations entre pistes.
Un bus série envoie les bits les uns après les autres, sur deux à quatre fils. On échange de la largeur contre du temps, et la puce est assez rapide pour que ça ne se voie pas.
En parallèle, un fil par bit : rapide, mais encombrant. En série, un seul fil de données : les bits passent l’un après l’autre.
| Question | Les deux réponses possibles |
|---|---|
| Combien d’interlocuteurs ? | Point à point (deux) ou multipoint (plusieurs) |
| Une horloge partagée ? | Synchrone (oui) ou asynchrone (non) |
| Les deux sens en même temps ? | Full-duplex (oui) ou half-duplex (chacun son tour) |
| Comment choisir le destinataire ? | Une adresse dans le message, ou un fil de sélection |
Ces quatre réponses suffisent à décrire UART, I2C et SPI.
Aucun n’est meilleur dans l’absolu : chacun échange de la vitesse contre des fils, ou des fils contre de la complexité. Le choix se fait par le besoin.
Deux fils, point à point
Point à point, full-duplex, asynchrone : sans horloge, la vitesse (le baud rate, souvent 115 200 bauds) est fixée à l’avance des deux côtés.
Le TX d’un appareil se branche sur le RX de l’autre, et réciproquement. Un câblage TX vers TX ne transmet rien, et c’est silencieux : aucun message d’erreur ne vous préviendra, vous verrez seulement un module qui « ne répond pas ».
Le start donne le signal, le récepteur compte les bits à la vitesse convenue. 8 bits, pas de parité, 1 stop : 8N1. Format ou vitesse différents : du charabia.
Les curseurs mesurent 103,6 µs par bit, soit 9600 bauds. Copie d’écran : Haji akhundov, via Wikimedia Commons, sous CC BY-SA 3.0.
Serial.begin(115200); // le port série du moniteur
Serial.printf("x=%d y=%d\n", x, y);
Le moniteur série se manie comme un UART. L’UART est aussi le bus des modules GPS, Bluetooth ou GSM, et le moyen le plus simple de faire dialoguer deux microcontrôleurs.
Sur beaucoup de cartes, une puce USB-série (CP2102, CH340) traduit l’UART en USB et réclame un driver sous Windows. La XIAO n’en a pas : Serial passe directement par l’USB natif de l’ESP32-S3, et l’UART0 reste libre sur D6/D7.
Le port série sous VSCode Vérification de la toolchain
Deux fils, plusieurs composants
Multipoint, synchrone (SCL), half-duplex. Chaque esclave a une adresse sur 7 bits ; le maître l’écrit en tête de chaque message.
Start, adresse + R/W, ACK de l’esclave, données (un ACK par octet), stop. Pas d’ACK après l’adresse : personne ne répond à cette adresse.
SDA et SCL sont en open-drain, comme au CM2 : les composants ne peuvent que tirer la ligne vers LOW, jamais vers HIGH. C’est précisément ce qui permet à plusieurs d’entre eux de partager le fil sans court-circuit.
Il faut donc deux résistances de pull-up (~4,7 kΩ) vers le 3,3 V. Sans elles, la ligne ne remonte jamais et rien ne communique.
La plupart des modules du commerce les intègrent déjà. Si vous en chaînez plusieurs, une seule paire suffit sur tout le bus : inutile de les cumuler. ↓ pour le détail.
Les bus de communication GPIO et monde numérique
Chacun peut tirer la ligne à 0 ou la relâcher, jamais imposer un 1 : deux composants ne peuvent pas se contredire.
On ne connaît pas toujours l’adresse. On les balaie toutes :
for (byte adr = 1; adr < 127; adr++) {
Wire.beginTransmission(adr);
if (Wire.endTransmission() == 0) {
Serial.printf("Trouvé : 0x%02X\n", adr);
}
}
Absent du scan ? Le problème est le câblage ou les pull-ups.
| Mode | Vitesse |
|---|---|
| Standard | 100 kHz |
| Fast | 400 kHz |
| Fast+ | 1 MHz |
| High Speed | 3,4 MHz |
Largement suffisant pour des capteurs ou un petit écran OLED monochrome, sur un ou deux mètres au plus. Bien trop lent pour un écran TFT couleur : à 400 kHz, une image de 240 × 320 pixels demanderait plus de trois secondes.
Quatre fils, plein débit
| Fil | Rôle |
|---|---|
| MOSI | Données du maître vers l’esclave |
| MISO | Données de l’esclave vers le maître |
| SCK | Horloge, générée par le maître |
| CS | Chip Select : un fil par esclave |
Transmission synchrone (l’horloge cadence chaque bit, donc pas de baud rate à accorder) et full-duplex (les deux sens en même temps).
Pas d’adresse : le CS à 0 désigne l’esclave. Les autres laissent MISO en haute impédance. De quelques MHz à 80 MHz sur ESP32-S3.
À chaque coup d’horloge, un bit part et un bit revient : full-duplex. Ni adresse, ni accusé de réception : c’est ce qui le rend si rapide.
| Signal | Broche | Rôle |
|---|---|---|
| SCK | D9 (GPIO8) | Horloge SPI |
| MOSI | D10 (GPIO9) | Données CPU vers écran |
| DC | D8 (GPIO7) | Bascule commande / donnée |
| RESET | D7 (GPIO44) | Reset matériel de l’écran |
| CS | GND | Écran toujours sélectionné |
| LED | 3V3 | Rétroéclairage, toujours allumé |
MISO n’est pas câblé (écriture seule) et CS est à GND : un seul esclave, toujours sélectionné.
CS est relié à GND : un seul esclave, toujours sélectionné.
lib_deps =
adafruit/Adafruit ST7735 and ST7789 Library@^1.11.0
Adafruit_ST7789 tft(&SPI, -1, D8, D7); // CS (aucun), DC, RESET
SPI.begin(D9, -1, D10, -1); // SCK, MISO, MOSI, CS
tft.init(240, 320, SPI_MODE3);
tft.fillScreen(ST77XX_BLACK);
De mauvaises broches donnent un écran noir, pas une erreur de compilation. Si l’écran reste éteint alors que tout compile, vérifier en premier les broches passées à SPI.begin() (SCK sur D9) et le SPI_MODE3, obligatoire quand CS est relié à GND.
| Critère | UART | I2C | SPI |
|---|---|---|---|
| Fils (hors masse) | 2 | 2 | 3 + 1 CS par esclave |
| Liaison | point à point | multipoint | multipoint |
| Horloge | asynchrone | synchrone | synchrone |
| Sens | full-duplex | half-duplex | full-duplex |
| Destinataire | aucun à choisir | adresse 7 bits | fil CS |
| Accusé de réception | non | oui (ACK) | non |
| Vitesse | ~1 Mbit/s | 0,1 à 3,4 Mbit/s | jusqu’à 80 Mbit/s |
| Usage type | debug, modules | capteurs, OLED | écrans, carte SD |
flowchart LR
B{"Besoin de<br/>vitesse ?"} -->|Oui| C["SPI<br/>écran, carte SD"]
B -->|Non| D{"Plusieurs<br/>composants ?"}
D -->|Oui| E["I2C<br/>capteurs, OLED"]
D -->|Non| F["UART<br/>debug, GPS, BT"]
Notre projet : un port série pour le moniteur, SPI pour l’écran. ↓ pour la page.
Ne jamais bloquer
void loop() {
static uint32_t lastFrameMs = 0;
uint32_t nowMs = millis();
if (nowMs - lastFrameMs < FRAME_TIME_MS) { // 16 ms
return; // pas encore l'heure
}
lastFrameMs = nowMs;
float joystickX = normalizeJoystick(analogRead(PIN_JOYSTICK_X), joystickCenterX);
bool startPressed = justPressed(selectButton); // 1. lire
gameUpdate(game, joystickX, startPressed, nowMs); // 2. calculer
rendererDraw(game); // 3. afficher
}
Cette charpente ne changera plus : le Pong du TD4 puis le Snake du projet enrichiront gameUpdate() et rendererDraw().
Le temps restant n’est jamais perdu dans un delay().
16 ms
par image, soit 60 images par seconde. En dessous, l’œil voit saccader.
4 M
cycles CPU disponibles dans ces 16 ms, à 240 MHz. De quoi faire beaucoup.
Si une image prend plus de 16 ms à calculer, le jeu ralentit au lieu de sauter des images. Premier suspect en cas de lenteur : un delay() oublié, ou un redessin complet de l’écran au lieu des seules zones modifiées.
Sortir du plat de spaghettis
Un jeu a plusieurs moments de vie : un menu d’accueil, une partie en cours, un écran de fin. Gérés à la main, ils donnent ceci :
bool enPartie = false;
bool gameOver = false;
bool menuActif = true;
// et ça empire à chaque nouvelle phase
Que veut dire enPartie && gameOver ? Rien. Et pourtant rien ne l’empêche.
stateDiagram-v2
[*] --> MENU
MENU --> PARTIE : bouton START
PARTIE --> GAME_OVER : vie == 0
GAME_OVER --> MENU : bouton RETRY
| État \ Événement | START | vie == 0 | RETRY |
|---|---|---|---|
| MENU | PARTIE | - | - |
| PARTIE | - | GAME_OVER | - |
| GAME_OVER | - | - | MENU |
Une case « - » veut dire « événement ignoré dans cet état ». Le tableau se traduit ligne à ligne en switch/case, et révèle les cas oubliés.
Le dessiner avant de coder prend cinq minutes, et en fait gagner deux heures.
enum et switchenum EtatJeu { MENU, PARTIE, GAME_OVER };
EtatJeu etat = MENU; // l'état courant, un seul
void loop() {
lireEntrees();
switch (etat) {
// un case par état
}
}
Un enum nomme les états, une variable retient celui qui est actif. Le switch fait le reste.
case par état
case MENU:
if (appuiStart()) { afficherJeu(); etat = PARTIE; }
break;
case PARTIE:
mettreAJourJeu(); // et redessine ce qui a bougé
if (vieJoueur == 0) { afficherGameOver(); etat = GAME_OVER; }
break;
case GAME_OVER:
if (appuiRetry()) { afficherMenu(); etat = MENU; }
break;
Un écran complet se dessine une fois, à la transition, jamais à chaque tour. Et appuiStart() ne vaut true qu’une fois par appui (front).
Dans la même séance, le mot état désigne deux choses : les données du jeu (position de la balle, score, ce sont des variables) et la phase du jeu (MENU, PARTIE, GAME_OVER, c’est la FSM). Gardez la distinction en tête pour ne pas les mélanger.
Réinitialiser le score ou effacer l’écran ne doit pas se répéter 60 fois par seconde. On l’exécute au moment de la transition, pas dans le case :
void allerVers(EtatJeu nouvel) {
etat = nouvel;
entreeEtat = millis(); // date d'entrée
if (nouvel == PARTIE) initialiserPartie();
if (nouvel == GAME_OVER) afficherGameOver();
}
C’est l’action d’entrée (onEnter). Toutes les transitions passent par là.
L’écran « GAME OVER » revient au menu après trois secondes, sans bloquer quoi que ce soit :
case GAME_OVER:
if (millis() - entreeEtat > 3000) {
allerVers(MENU);
}
break;
FSM et millis() se combinent naturellement : c’est la transition temporisée. La date d’entrée dans l’état, mémorisée par allerVers(), sert de référence.
Machine à états finis Du matériel au logiciel
stateDiagram-v2
MENU --> PARTIE : appui
PARTIE --> GAME_OVER : plus de vies
GAME_OVER --> MENU : 3 s écoulées
La flèche du bas ne dépend d’aucune entrée : seulement du temps passé dans l’état.
stateDiagram-v2
[*] --> VERT
VERT --> ORANGE : 5 s
ORANGE --> ROUGE : 2 s
ROUGE --> VERT : 5 s
Trois états, des transitions purement temporisées, aucun bouton.
void loop() {
unsigned long ec = millis() - entreeEtat;
switch (etat) {
case VERT: if (ec > 5000) allerVers(ORANGE); break;
case ORANGE: if (ec > 2000) allerVers(ROUGE); break;
case ROUGE: if (ec > 5000) allerVers(VERT); break;
}
}
Aucun delay() : le programme pourrait aussi lire un bouton piéton.
| Approche | Lisibilité | Extensibilité | Bugs typiques |
|---|---|---|---|
| Booléens | faible | difficile | états contradictoires |
FSM enum |
élevée | un case de plus |
aucun |
Au projet, cette FSM s’étendra aux états réseau du Snake multijoueur.
MENU, PARTIE, PAUSE ?, GAME_OVER)Comparez avec le binôme voisin : les différences sont instructives.
millis(), sans jamais bloquercaseLes bus de communication Machine à états finis
| Séance | Ce que vous allez faire |
|---|---|
| TD1 | Installer, flasher, lire le port série |
| TD2 | Tester les modules de la mallette : GPIO, ADC, PWM, SPI |
| TD3 | Concevoir votre carte sous KiCad |
| TD4 | Souder la carte, y écrire un Pong : game loop et FSM |
| Projet | Un Snake multijoueur, la FSM étendue au réseau |
Les trois cours sont terminés : tout ce que vous venez de voir sert dès le TD2.
Syllabus de l’atelier Les modules de la mallette
