Pulseview et sigrok pour un analyseur logique libre

Posté par  . Édité par Ysabeau 🧶 🧦, ted et Benoît Sibaud. Modéré par Ysabeau 🧶 🧦. Licence CC By‑SA.
71
6
mar.
2022
Do It Yourself

sigrok est un logiciel libre qui s’interface avec du matériel de mesure pour le piloter et/ou acquérir les données. Pulseview est une interface graphique pour sigrok.

Dans cette dépêche, nous allons voir ce qu’est un bus de communication, ensuite nous verrons que les analyseurs logiques permettent de décoder les informations qui y circulent, enfin nous décrirons l’analyseur logique libre sigrok accompagné de son interface Pulseview. Un exemple simple d’utilisation est donné à la fin.

Logo de sigrok

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.

RS-485
Le RS-485 est très répandu sur les automates (Own picture, Public domain, via Wikimedia Commons)

Amazon Echo
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
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
Analyseur Logique USB Digilent (Adafruit Industries, CC BY-NC-SA 2.0, via Flickr)

Openbench logic Sniffer
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) :

  • sigrok-cli permet d’utiliser sigrok via un terminal
    sigrok-cli

  • pulseview est une interface en Qt dédiée à l’analyse de signaux logiques. Elle sera détaillée plus bas.

IHM Pulseview

  • smuview est une interface pour alimentations de labo et instruments de mesure.

smuview

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

hobbytronics

À 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.

setup

Configuration de l’acquisition

Connecter le module d’acquisition à l’ordinateur.
Ouvrir Pulseview.

sigrok1

Configurer le périphérique d’acquisition en sélectionnant le firmware adapté, l’interface puis en scannant les périphériques disponibles.

sigrok2

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.

sigrok3

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.

sigrok4

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é :

sigrok5

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)

sigrok6

Voici ce que nous obtenons :

sigrok7

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.

Aller plus loin

  • # Wireshark

    Posté par  . Évalué à 7.

    A noter que Wireshark permet de capturer et analyser les trames passant par un bus Ethernet ou USB (entre autres).

    Certains adaptateurs mentionnés dans l'article capturent des trames à partir d'un bus physique et les encapsulent dans de l'USB ou de l'Ethernet.

    Il est donc possible pour Wireshark de les analyser s'il possède le bon "dissector" (analyseur logiciel, intégré ou en plugin, qui connaît la structure des trames et sait l'afficher dans l'interface).

    • [^] # Re: Wireshark

      Posté par  (site web personnel) . Évalué à 1.

      C'est intéressant. C'est peut-être même utilisé par les dev du projet pour débogger leurs interfaces, avec un outil tiers comme wireshark.

  • # Merci

    Posté par  . Évalué à 4. Dernière modification le 15 mars 2022 à 09:17.

    Merci pour cette découverte.

    Intéressant, dommage que les PicoScopes ne soient pas encore supportés car le décodage des bus semble assez poussé.

  • # test ?

    Posté par  (site web personnel) . Évalué à 4.

    Est-ce qu il existe des fonctions de tests pour automatiser des verifications ?

    "La première sécurité est la liberté"

    • [^] # Re: test ?

      Posté par  . Évalué à 3.

      Je n'ai pas l'impression. Après, il est possible de rédiger un script qui s'interface entre l'appareil à tester et sigrok-cli.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.