Sommaire
Au sein d’un équipement ou entre différents équipements, les composants électroniques communiquent en utilisant des bus de données standardisés. Par exemple :
- le CAN, qui utilise une simple paire torsadée, est omniprésent dans l’automobile. Il permet aux calculateurs de dialoguer entre eux sur le même bus.
- le RS-485, qui utilise aussi une paire torsadée, est répandu dans les automates. C’est un support physique du protocole Modbus.
- l’I²C et le SPI, bien connus des utilisateurs de cartes de prototypage, sont adaptés à la communication entre microcontrôleurs au sein d’un même équipement.
- le 1-wire qui, comme son nom l’indique, n’utilise qu’un fil pour établir une communication bidirectionnelle bas débit. On le retrouve dans les chargeurs d’ordinateur portable et dans les passes Dallas.
- l’Ethernet, bien connu du grand public, tend à remplacer le CAN dans l’automobile et le RS-485 dans l’industrie.
Le RS-485 est très répandu sur les automates (Own picture, Public domain, via Wikimedia Commons)
Les convertisseurs analogique-numérique (en orange) et les pilotes LED (en rouge) de l’Amazon Echo se pilotent via une interface I²C (ifixit.com)
Pour analyser les paquets qui transitent sur un lien Ethernet, on peut utiliser une simple interface réseau et le logiciel libre Wireshark. Par contre, pour regarder ce qui se passe sur les autres bus cités plus haut, il faut avoir recours à un analyseur logique.
Les analyseurs logiques
Les bus de données ont au moins deux couches :
- la couche physique qui correspond à la manière dont sont transportés les bits : nombre de fils, liaison symétrique/asymétrique, tensions, fréquence de cadencement des bits…
- la couche données qui correspond à la manière dont les bits représentent l’information transportée.
L’analyseur logique a donc deux missions :
- accepter de nombreux types de bus physiques pour en extraire les bits ;
- retranscrire les bits en informations exploitables, c’est-à-dire :
- interpréter les séquences de bits,
- séparer l’information des éventuels en-têtes et sommes de contrôle,
- filtrer l’information en fonction de certains critères,
- indiquer les trames invalides.
Les analyseurs logiques existent sous deux formes : en boitier autonome muni d’une interface utilisateur ou en boitier d’acquisition qui se connecte à un ordinateur. Dans les deux cas, ils présentent un grand nombre d’entrées reliées à un circuit qui conditionne le signal et synchronise les entrées, puis ce signal passe dans un circuit d’acquisition spécialisé (souvent un FPGA). Dans les analyseurs logiques d’entrée de gamme, l’ensemble des étapes est réalisée par un microcontrôleur cadencé à quelques dizaines de mégahertz (voir plus bas).
Les analyseurs autonomes ont pour avantage d’être prêts à l’emploi. En contrepartie, ils sont onéreux et le logiciel embarqué est propriétaire, ce qui signifie qu’il n’y a pas de garantie que le décodage des futurs protocoles soit supporté.
Analyseur logique autonome Tektronix TLA5204 (Vonvon, CC BY-SA 3.0, via Wikimedia Commons)
Les boitiers d’acquisition sont plus abordables. Ils se connectent via une interface USB ou Ethernet à un PC. Ils effectuent uniquement le traitement de la couche physique, la couche de données étant déléguée à un logiciel spécialisé pour PC.
Analyseur Logique USB Digilent (Adafruit Industries, CC BY-NC-SA 2.0, via Flickr)
L’Openbench Logic Sniffer de Dangerous Prototypes (en rouge) est l’un des rares boitiers d’acquisition Open Hardware. Il utilise un transducteur pour conditionner le signal et un FPGA pour l’acquisition (Dangerous Prototypes, CC-BY-SA)
Quelques logiciels :
-
Waveforms de Digilent, non libre mais qui fonctionne sous Linux,
-
CANAlyzer de Vector, non libre et nécessitant un boitier spécifique, pour l’analyse des réseaux CAN,
-
Matlab de Mathworks, non libre, possède un module spécifique,
-
SUMP Logic Analyzer, sous licence GNU GPL, n’est plus actif depuis 2007,
- et le couple PulseView/sigrok dont nous allons (enfin) parler.
Présentation de sigrok
sigrok est un logiciel sous licence GPL v3 capable de récupérer et de traiter les données provenant d’appareils de mesure et de cartes d’acquisition.
Matériel supporté
sigrok supporte actuellement 245 matériels différents, dont :
- des analyseurs logiques (Hobby Components, Saleae Logic…),
- des oscilloscopes (Rhode&Schwarz, Siglent, Agilent…),
- des multimètres (Fluke, Keysight…),
- des sonomètres, des balances…
sigrok peut aussi piloter des alimentations de laboratoire.
Architecture du logiciel
Le projet sigrok est constitué de plusieurs modules. Partons de la source jusqu’à l’IHM.
- Linux s’interface avec le matériel d’acquisition via son firmware. Ce firmware peut être libre, par exemple fx2lafw pour le matériel d’entrée de gamme équipé d’une puce Cypress FX2. 28 firmwares sont disponibles par défaut.
-
libsigrok est la couche bas-niveau de sigrok qui s’interface avec le firmware.
-
libsigrokdecode est chargé, comme son nom l’indique, de l’interprétation des signaux. sigrok est capable de décoder un très grand nombre de protocoles, parmi lesquels : 1-wire, AC'97, CAN, HDMI-CEC, DALI, HDCP, I²C, I²S, JTAG, LIN, LPC, MIDI, Modbus, Morse (!), PS/2, S/PDIF, SPI, UART, USB…
- L’ensemble est piloté par une interface graphique.
En fonction de l’utilisation, plusieurs interfaces sont disponibles (images des contributeurs de sigrok, CC-BY-SA 3.0) :
-
smuview est une interface pour alimentations de labo et instruments de mesure.
Sous Debian, il suffit de sélectionner le paquet pulseview pour obtenir une installation complète. SmuView s’installe via AppImage.
Travaux pratiques
Nous allons voir comment utiliser Pulseview/sigrok à travers un cas d’usage simple. Nous souhaitons piloter un appareil via le protocole Modbus RTU sur bus RS-485. Le programme de pilotage est hébergé sur un Rasberry Pi possédant un HAT RS-485. Nous souhaitons voir si le programme envoie des messages correctement formatés.
Note : cette procédure a été rédigée quelques mois après la réalisation de l’acquisition physique. Il pourrait y avoir des écarts.
Configuration matérielle
Nous utilisons un analyseur logique Hobby Components. Il est peu coûteux, n’est pas Open Hardware et ses caractéristiques techniques sont les suivantes :
- 8 canaux,
- Compatible avec les niveaux logiques 3,3V et 5V,
- Fréquence d’acquisition maximale de 24MHz,
- Interface USB2.0,
- Firmware libre fx2lafw
À l’intérieur, 4 circuits intégrés : une EEPROM, un régulateur de tension, un transducteur 74HC245 et un microcontrôleur Cypress CY7C68013A.
Le transducteur joue le rôle de buffer : il conditionne les signaux d’entrée pour qu’ils soient « présentés » de la meilleure manière au microcontrôleur. Le microcontrôleur est de type 8051, est cadencé à 24MHz et intègre nativement l’interface USB. Cypress semble indiquer que son microcontrôleur est adapté aux applications basse consommation nécessitant des taux de transfert élevés. Parfait !
Le transducteur n’est pas capable d’acquérir des signaux RS-485; il n’est pas possible de connecter l’analyseur directement au bus. Il est donc intercalé sur le port UART entre le Raspberry Pi et le HAT RS-485.
Configuration de l’acquisition
Connecter le module d’acquisition à l’ordinateur.
Ouvrir Pulseview.
Configurer le périphérique d’acquisition en sélectionnant le firmware adapté, l’interface puis en scannant les périphériques disponibles.
L’interface se met à jour en affichant les entrées du module d’acquisition, le nombre d’échantillons à acquérir et le taux d’échantillonnage.
La broche TX du Raspberry Pi est reliée à D1 et la broche RX à D3. Le bouton Configure Channels permet de ne sélectionner que ces deux entrées. L’une des entrées peut être configurée comme « trigger », c’est-à-dire que l’acquisition ne se déclenche que lorsque son signal répond à une condition.
La liaison étudiée est cadencée à 115 200 bits par seconde. Il faut une fréquence d’acquisition au moins 2x supérieure pour capturer tous les bits. Une fréquence d’acquisition de 500kHz est choisie. Il est alors possible de déclencher la capture et de lancer notre programme qui envoie la trame Modbus. Voici ce qui est capturé :
Exploitation des résultats
Nous avons capturé les signaux électriques du port UART. Il faut maintenant la traduire pour obtenir la couche données Modbus. La puissance de sigrok repose sur le grand nombre de décodeurs pris en charge. Dans le sélecteur de décodeur, nous choisissons « Modbus ». Cela ajoute une ligne en dessous des signaux acquis. Il faut aider sigrok en indiquant les caractéristiques des données transmises :
- la broche recevant (RX) et émettant (TX) les données
- le débit de la liaison (115200 bits par seconde)
- le codage des bits (parité paire, 1 bit d’arrêt, 8 bits par donnée, affichage hexadécimal)
Voici ce que nous obtenons :
Les deux premières lignes du port UART ont été décodées pour afficher les données Modbus qu’elle contient. Quatre lignes ont été ajoutées :
-
UART: RX Warnings correspondant aux bits lus sur RX qui ne peuvent pas être interprétés. Ces bits parasites peuvent provenir d’un problème physique dans la liaison qui génère des échos.
-
UART: TX bits est la traduction des signaux électriques de la broche TX en bits.
-
UART: TX est la traduction des TX bits en hexadécimal. Le décodeur a extrait les bits de démarrage « S », de parité « P » et d’arrêt « T ».
-
Modbus: Client-server est l’interprétation de UART: TX en commandes Modbus.
À travers cette acquisition, nous pouvons conclure que le message est correctement envoyé par notre Raspberry Pi, mais il semblerait y avoir un problème matériel qui génère des bits parasites sur RX.
Si besoin, les données mesurées peuvent être exportées en de nombreux formats réutilisables : binaire brut, hexadécimal, csv, WAV…
Conclusion
L’analyse logique est un outil efficace pour tester des montages électroniques ou faire de la rétro-ingénierie. sigrok et Pulseview sont des outils très puissants pour les bricoleurs. Ils rendent l’analyse des bus logiques accessibles à tous en s’interfaçant avec un large choix de matériels de mesure. La licence libre garantit le fait que ce logiciel sera disponible sans restrictions et permet, au travers des contributions, la prise en charge de futurs protocoles.
