Quand un simple radar LED devient une odyssée électronique… Au départ, c’était simple. Trop simple, même.
L’idée : faire tourner un anneau de LEDs comme un radar, avec une petite traînée lumineuse. Et lorsqu’on approche un badge NFC, afficher une réaction lumineuse : explosion colorée, vert si c’est le bon badge, rouge si c’est un intrus, et RGB en tiers pour un badge de test. Facile, non ?
Oui. Enfin… sur le papier.
Au sommaire :
- 1 ARTICLE : Quand le radar LED ne veut pas tourner
- 1.1 Saga NFC, delays et escargots de Bourgogne fatigués
- 1.2 Connexions
- 2 Vidéo
- 3 Conclusion
ARTICLE : Quand le radar LED ne veut pas tourner
Saga NFC, delays et escargots de Bourgogne fatigués
Étape 1 : le radar LED, nickel
On commence par le radar seul. Un petit FastLED, une broche DATA bien connectée, un loop() qui fait tourner les LEDs toutes les 50 ms, et hop, une belle rotation visuelle. Validé, testé, fluide.
Bref : le radar, ça tourne.
Étape 2 : test du lecteur NFC seul – tout fonctionne
Avant de mélanger le radar avec le lecteur, on teste évidemment le module NFC PN532 en mode SPI, tout seul. On charge un sketch simple qui lit l’UID des badges et l’affiche sur le port série.
Verdict : chaque badge posé renvoie son UID, sans accroc.
- Matériel NFC OK
- Lecture UID fiable
- Badges bien lus et identifiés
- On se dit : parfait, il n’y a plus qu’à assembler.
Étape 3 : on combine… et tout bloque
C’est là que les choses se corsent. On branche le module NFC, on ajoute la lecture avec :
nfc.readPassiveTargetID(PN532_MIFARE_ISO14443A, uid, &uidLength);
Et là, surprise : dès qu’on lance le sketch…
le radar ne tourne plus. Ou une fois. Puis plus rien.
Les LEDs restent bloquées sur 3 ou 4 diodes fixes.
Analyse : qui bloque qui ?
Le problème vient de readPassiveTargetID() : cette fonction est bloquante par défaut.
Elle attend indéfiniment qu’un badge soit détecté.
Tant qu’il n’y a rien : elle ne rend pas la main.
Donc :
- Le radar ne tourne plus
- La boucle loop() est figée
- Le badge peut parfois être lu (mais au prix de 4 LEDs figées)
- Et pourtant, le module NFC marchait très bien seul.
Tentative 1 : delay() dans le radar — mauvaise idée
“Pas grave ! On va faire un delay() pour temporiser entre deux pas du radar.”
Mauvaise idée.
Le delay() bloque aussi le temps CPU. Donc :
Le radar tourne, OK.
Mais le NFC ne détecte plus rien → impossible de scanner un badge.
C’est l’un ou l’autre. Mais pas les deux.
La bonne solution : timeout + escargot
La vraie solution, c’est :
1. Utiliser la fonction non bloquante avec timeout :
nfc.readPassiveTargetID(PN532_MIFARE_ISO14443A, uid, &uidLength, 20);
→ Avec un timeout de 20 ms, on interroge régulièrement sans bloquer la boucle.
2. Ralentir le radar : passer en mode « escargot de Bourgogne fatigué »
#define DELAI_ESCARGOT 300
→ Le radar avance d’une LED toutes les 300 ms.
C’est joli, lent, visible… et ça laisse au NFC le temps de faire sa lecture sans gêner le reste.
Le résultat (enfin) satisfaisant
- Le radar tourne fluide, lent mais hypnotique
- Les badges sont lus même s’ils sont posés doucement
- Explosion colorée + vert si bon badge
- RGB en tiers pour le badge de test
- Rouge si inconnu
- Le tout sans delay(), sans blocage, sans prise de tête
Connexions
| Fonction | Broche Arduino |
|---|---|
| LED WS2812 | D6 |
| NFC PN532 SS | D10 |
| SPI MOSI | D11 |
| SPI MISO | D12 |
| SPI SCK | D13 |
Vidéo
Conclusion
Leçon de cette galère
- Tester séparément, toujours.
- Ne jamais supposer qu’une fonction est « inoffensive ».
- Et surtout : se méfier des fonctions bloquantes dans une boucle censée rester fluide.
- Et comme dirait l’escargot de Bourgogne :
- “Si tu veux aller vite… ralentis.”
