L’analyseur logique observe plusieurs lignes numériques en même temps et n’en retient que les états logiques — 0 ou 1 — horodatés. Là où l’oscilloscope montre la forme analogique d’une ou deux voies, l’analyseur en suit huit ou seize et sait décoder les protocoles : il transforme les impulsions d’un bus en octets lisibles. C’est l’instrument du débogage de bus de communication. Fiche tuto-outil du hub instruments de mesure.
À quoi ça sert ?
Quand un capteur « ne répond pas », le code n’en dit rien : la question est de savoir ce qui circule vraiment sur les fils. L’analyseur logique sert à :
- constater qu’une trame part et arrive — ou pas : l’adresse est-elle émise ? l’esclave répond-il (ACK) ?
- décoder une trame UART, I²C ou SPI en octets lisibles, au lieu de compter des fronts à la main ;
- suivre plusieurs lignes synchrones : les quatre signaux d’un bus SPI s’observent ensemble, ce qu’un oscilloscope deux voies ne peut pas faire ;
- confronter le chronogramme réel au chronogramme attendu de la datasheet.
L’interprétation des trames décodées — qui parle, dans quel ordre, avec quelles adresses — reste l’affaire des fiches de chaque bus : l’analyseur les rend simplement visibles.
S’équiper
Le projet n’exige pas un instrument de laboratoire. Ce tableau sert à reconnaître celui qu’on a en main et à savoir ce qu’il permet :
| Instrument | Ce qu’il permet |
|---|---|
| Clone USB 8 voies (type « 24 MHz, 8 CH ») | huit lignes échantillonnées jusqu’à 24 Méch/s, largement au-dessus de l’UART, de l’I²C et du SPI d’un projet ; reconnu nativement par les logiciels libres, donc sans pilote propriétaire à installer |
| PulseView (suite libre sigrok) | pilote ces clones et embarque les décodeurs UART / I²C / SPI — c’est le logiciel décrit dans cette fiche |
| Saleae Logic 8 | la référence professionnelle : profondeur de capture supérieure et logiciel plus confortable. Quand le laboratoire en dispose, c’est celui-là qu’on prend |
Brancher et capturer
- GND d’abord : relier une masse de l’analyseur à la masse du montage — sans référence commune, les lectures sont fantaisistes.
- Clipper les voies sur les lignes à observer : SDA + SCL pour l’I²C, TX + RX pour l’UART, CS + CLK + MOSI + MISO pour le SPI.
- Nommer les voies dans le logiciel — « CH0 » ne dit rien, « SDA » si.
- Choisir la fréquence d’échantillonnage : au moins quatre fois le signal le plus rapide observé — dix fois pour être confortable.
- Capturer, puis activer le décodeur du protocole : les impulsions deviennent des octets.
Pièges
Y chercher de l’analogique. L’analyseur tranche tout en 0 / 1 : un rebond de bouton, un front mou, un niveau dégradé par une piste trop longue lui sont invisibles. Il affichera un beau signal carré là où l’oscilloscope montrerait le problème. Au doute sur la qualité d’un signal, c’est l’oscilloscope.
Dépasser la tension d’entrée. Les clones USB tolèrent 5 V, guère plus : pas de mesure sur un rail 12 V ou 24 V sans adaptation.
Échantillonner trop lentement. Sous-échantillonné, un bus produit une trame plausible mais fausse — l’erreur la plus sournoise, car rien ne signale le repliement. En cas de décodage incohérent : monter la fréquence d’échantillonnage avant de soupçonner le montage.
Oublier la masse commune. Premier geste du branchement, première cause de capture aberrante.
Raccrochage projet
- Phase de preuve de concept — valider le dialogue microcontrôleur ↔ capteur dès le premier câblage : l’adresse I²C répond, les octets attendus circulent.
- Phase d’intégration et tests — déboguer les échanges entre sous-ensembles assemblés, preuves de trames à l’appui pour le rapport de test → fiabiliser et déboguer.
Voir aussi
- Instruments de mesure — le hub : méthode commune et choix de l’instrument
- Oscilloscope — le complément analogique : la qualité du signal, pas seulement ses états
- UART · I²C · SPI — les protocoles que l’analyseur décode
- Chronogramme — lire ce que l’analyseur affiche
- Wokwi — son analyseur logique virtuel, pour capturer un bus simulé avant de câbler