La dernière fois, nous avons envisagé d'utiliser un analyseur logique pour décoder les signaux SPI des écrans LCD, ce qui peut nous aider à réutiliser les écrans LCD de systèmes propriétaires, ou à transférer le code du pilote LCD d'une plate-forme à une autre ! Cependant, si vous faites cela, vous risquez de rencontrer un goulot d'étranglement. En général, vous devez capturer tout un tas de données, puis les parcourir en comparant les octets un par un, ce qui est assez lent. Si vous avez bricolé Pulseview, vous avez probablement déjà trouvé une option pour exporter les données décodées – tout ce que vous avez à faire est de cliquer avec le bouton droit sur la sortie du décodeur et de nombreuses options vous seront présentées pour l'exporter. Voici ce que vous trouverez :
2521888-2521888 I²C: Address/data: Start
2521896-2521947 I²C: Address/data: Address write: 22
2521947-2521954 I²C: Address/data: Write
2521955-2521962 I²C: Address/data: ACK
2521962-2522020 I²C: Address/data: Data write: 01
2522021-2522028 I²C: Address/data: ACK
2522030-2522030 I²C: Address/data: Start repeat
2522038-2522089 I²C: Address/data: Address read: 22
2522089-2522096 I²C: Address/data: Read
2522096-2522103 I²C: Address/data: ACK
2522104-2522162 I²C: Address/data: Data read: 91
2522162-2522169 I²C: Address/data: NACK
2522172-2522172 I²C: Address/data: Stop
Que ce soit à l'écran ou dans un fichier exporté, la sortie du décodeur n'est pas très lisible – selon le type d'interface que vous reniflez, que ce soit I2C, UART ou SPI, vous obtiendrez cinq à dix lignes de sortie du décodeur pour chaque octet. transféré. Si vous obtenez de grandes quantités de données de votre analyseur logique et que vous souhaitez réellement comprendre ce qui se passe, cela deviendra rapidement un problème – sans compter que faire défiler la fenêtre Pulseview n'est pas une expérience confortable.
Le résultat ci-dessus pourrait ressembler à ceci : 0x22: read 0x01 ( DEV_ID) = 0x91 (0b10010001). Pourtant, ce n’est pas le cas, et je veux vous montrer comment corriger cette injustice. Aujourd'hui, nous surchargeons Pulseview avec quelques scripts externes, et je vais vous montrer comment transférer de grandes quantités de données de sortie du décodeur Sigrok dans de superbes impressions de transactions lisibles par l'homme. Pendant que nous y sommes, vérifions également sigrok en ligne de commande, en évitant complètement l'interface utilisateur Pulseview – avec sigrok-clivous pouvez facilement créer un programme léger qui s'exécute en arrière-plan et enregistre toutes les données capturées dans un fichier texte, ou les affiche sur un écran en temps réel !
Oh, et pendant que nous y sommes, j'aimerais vous montrer un truc plutôt sympa que j'ai trouvé sur Aliexpress ! Ce sont de minuscules cartes FX2 avec le même schéma d'analyseur logique, elles fonctionnent donc avec le firmware open source FX2 et Sigrok – mais elles sont beaucoup plus petites, ont des connecteurs USB-C au lieu du câble miniUSB, et sont souvent encore moins chères. que les analyseurs FX2 « boîtier en plastique » auxquels nous sommes habitués. De plus, puisque vous pouvez voir le PCB exposé, contrairement aux analyseurs à « boîtier en plastique », vous savez si vous obtenez des tampons d'entrée ou non !
Le faire bouillir
A titre d'exemple, considérons une capture du bus I2C du fer à souder Pinecil. Sur ce bus, il y a trois appareils I2C – un écran OLED 96×16 à l'adresse 0x3cun accéléromètre à 0x18et le FUSB302B USB-PD PHY à 0x22. Le FUSB302B est une puce dont nous nous souvenons des articles sur la communication PD de bas niveau USB-C dans lesquels nous avons construit notre propre carte de déclenchement PD. Je n'aurais pu écrire ces articles que parce que j'ai obtenu les captures de l'analyseur logique, les ai transformées en impressions de transactions et les ai utilisées pour déboguer mon code PD. Maintenant, vous apprenez également à utiliser ces captures à votre avantage.
Si vous ouvrez les fichiers ci-dessus dans Pulseview, vous verrez tout un tas de traces I2C. Je voulais naturellement me concentrer sur le FUSB302 – l’accéléromètre et les communications OLED sont également intéressants mais n’étaient pas mon objectif. Vous verrez également qu'un décodeur de protocole appelé « filtre I2C » est connecté. D'une manière ou d'une autre, cela m'a été remarquablement inutile chaque fois que j'essaie de l'utiliser, sans rien filtrer du tout. Peu importe, faites un clic droit sur la ligne de sortie du décodeur I2C (celle qui affiche les octets et les événements décodés), cliquez sur « Exporter toutes les annotations pour cette ligne », choisissez un nom de fichier, puis ouvrez le fichier dans un éditeur de texte.
La vue que vous obtenez est un peu écrasante : nous obtenons 22 000 lignes de texte, ce qui est loin du type de données que vous pourriez raisonnablement lire. Bien sûr, la plupart de ces données sont des données de transfert LCD, et il y a aussi pas mal d'interrogations d'accéléromètre – vous souhaitez filtrer les deux si vous souhaitez voir uniquement les transactions FUSB302. Néanmoins, c'est un bon début : vous obtenez un fichier texte qui contient toute l'activité se déroulant sur le bus I2C, c'est tout simplement trop de texte à lire par vous-même.
Voici un exemple de ligne : 2521783-2521834 I²C: Address/data: Address write: 30. C’est très simple à traiter, si vous y regardez de plus près ! Chaque ligne décrit un événement I2C et commence par deux horodatages : le début et la fin de l'événement, séparés par - . Ensuite, nous obtenons trois valeurs supplémentaires, séparées par des espaces : le nom du décodeur, le type d'événement du décodeur et l'événement du décodeur lui-même. Ce format de sortie peut être modifié dans les paramètres Pulseview, si vous le souhaitez, cependant, vous pouvez facilement l'analyser tel quel. Pour ce format, nous pouvons simplement diviser la chaîne par espace (sans diviser plus de trois espaces), en obtenant un horodatage, un nom de décodeur, un type de sortie de décodeur et un événement de décodeur.
J'utiliserai Python pour l'analyse, mais n'hésitez pas à traduire le code en tout ce qui fonctionne pour vous. Voici un peu de Python qui lit notre fichier ligne par ligne et met les parties utiles de chaque ligne dans des variables :
with open('decoded.txt', 'r') as f:
line = f.readline()
while line:
line = line.strip()
if not line: # empty line terminates the loop, use `continue` to ignore empty lines instead
break
# ignoring decoder name and decoder output type - they don't change in this case
tss, _, _, d = line.split(' ', 3)
[ "do something with this data" ]
line = f.readline() # get a new line and rerun the loop body
L'analyse de lignes de texte en données d'événements est assez simple : à partir de là, nous devons regrouper les événements dans des transactions I2C. Comme vous pouvez le constater, une transaction commence par un Start événement, que nous pouvons utiliser comme marqueur pour séparer les différentes transactions au sein de tous les événements que nous obtenons. Nous pouvons appliquer la tactique de programmation habituelle : parcourir les événements, avoir une liste de « transactions en cours » à laquelle nous ajoutons de nouveaux événements et une liste « toutes les transactions jusqu'à présent » dans laquelle nous mettons les transactions que nous avons fini de traiter.
Le plan est simple : dans la même boucle, nous regardons l'événement que nous obtenons, et si ce n'est pas un Start événement, qu'il s'agisse d'un événement de bit d'écriture/lecture/ACK/NACK, ou Stop/Start repeat événement, nous le mettons simplement dans la liste « transaction en cours ». Si nous obtenons un nouveau Start événement, nous considérons cette liste de « transactions en cours » terminée et l'ajoutons à notre liste de transactions reçues, puis démarrons une nouvelle liste de « transactions en cours ». Pendant que nous y sommes, nous pouvons également analyser les octets d'adresse et de données – nous les recevons sous forme de chaînes et nous devons les analyser sous forme de chiffres hexadécimaux, à moins que vous ne changiez le décodeur I2C pour afficher autre chose.
Voici un lien vers la section de code concernée. Je pourrais parler davantage de ce qu'il fait, par exemple, il filtre les transferts FUSB302 par adresse, mais j'aimerais aller droit au but et afficher les lignes d'entrée par rapport à la liste des transactions de sortie. Vous pouvez obtenir cette sortie si vous exécutez python -i parse.py et entrez tr[0] dans le REPL :
>>> tr[0] ['start', 34, 'wr', 'ack', 'wr', 1, 'ack', 'start repeat', 34, 'rd', 'ack', 'rd', 145, 'nack', 'stop']
Maintenant, c’est une véritable transaction I2C ! Tous ces éléments sont des choses que nous pouvons discerner visuellement dans l'interface utilisateur Pulseview. Attention, ce code est adapté à l'analyse des transactions FUSB302, mais il ne devrait pas être difficile de le modifier pour qu'il distingue et analyse les transactions par accéléromètre ou OLED à la place. À partir de là, il suffit presque de simplement concaténer les éléments de la liste de transactions et d'obtenir une transaction semi-lisible par l'homme, mais n'arrêtons pas nos ambitions ici : le FUSB302 dispose d'une documentation disponible, et nous pouvons parvenir à un décodage parfaitement lisible de ce que contient le code. effectivement !
J'ai parcouru la fiche technique et créé un dictionnaire Python avec un mappage adresse-nom de registre. En utilisant cela, nous pouvons facilement parcourir les transactions, les mapper à des lectures et écritures de registre spécifiques, et convertir les données brutes de transaction en lignes de texte qui nous l'indiquent clairement – d'abord, nous écrivons cet octet dans le registre SWITCHES0, puis nous écrivons cet octet. dans le registre POWER, et ainsi de suite. Voici le code que j'ai écrit pour effectuer des transactions détaillées – et il vous aide à transformer les captures de l'analyseur logique en code Python !
Disons que vous écrivez un firmware open source de remplacement pour quelque chose que vous possédez, ou peut-être que vous cherchez à copier l'implémentation d'un protocole à vos propres fins, comme j'ai copié l'implémentation PD de Pinecil pour m'aider à déboguer mon propre code PD. . Voici la partie intéressante : vous pouvez traduire ce type de sortie dans votre propre code de haut niveau presque instantanément, au point où vous pouvez même modifier ce script de décodage pour générer du code Python ou C ! C'est comme une décompilation, sauf que vous obtenez le langage de votre choix et une description lisible par l'homme du comportement externe du code, ce qui est souvent ce que vous souhaitez réellement.
Voici à quoi ressemble une liste détaillée de transactions : [34, '0x22', 1, '0x01 ( DEV_ID)', 'rd', [145], '0x91 (0b10010001)']. Et voici comment je peux formater de telles transactions, en utilisant une fonction d'assistance incluse dans le code que j'ai lié :
>>> tr_as_upy(transactions[0]) i2c.readfrom_mem(0x22, 0x1) # rd: DEV_ID 0x91 (0b10010001) >>> tr_as_upy(transactions[1]) i2c.writeinto_mem(0x22, 0xc, b'\x01') # wr RESET: 0x01 (0b00000001)
Un tel code vous permet de procéder rapidement à une rétro-ingénierie des appareils propriétaires et open source, tout en ayant une bonne compréhension de ce qu'ils font spécifiquement. De plus, avec un tel décodeur, vous pouvez également écrire un décodeur de protocole pour Sigrok afin de pouvoir y accéder facilement depuis Pulseview ! Par exemple, si vous capturez des lectures/écritures pour une EEPROM I2C, il existe un décodeur EEPROM I2C dans Sigrok que vous pouvez ajouter – et il n'y a jamais assez de décodeurs Sigrok, donc ajouter votre propre décodeur à la pile est une merveilleuse contribution à la logiciel d'analyse logique open source que tout le monde connaît et aime.
Aller plus loin avec la ligne de commande
Cette approche de décodage vous donne le plus grand contrôle sur vos données de sortie, ce qui est extrêmement utile si vous devez en traiter de grandes quantités. Vous pouvez également déboguer des problèmes complexes comme jamais auparavant. Par exemple, j'ai dû aider quelqu'un à déboguer un flasheur ESP8266 basé sur le Web qui ne peut pas flasher correctement certains types d'images de micrologiciel, et pour cela, je capture les données UART transférées entre le PC et l'ESP8266.
Il y a aussi un problème avec une telle capture : pendant le flashage, le débit en bauds de l'UART change, le débit en bauds du chargeur de démarrage étant de 76 800, le débit en bauds du clignotement étant de 468 000 et le débit en bauds du logiciel étant de 115 200. En conséquence, vous ne pouvez pas réaliser l'astuce habituelle. où vous connectez la broche RX d'un adaptateur USB-UART à votre bus de données et lui faites diffuser des données vers une fenêtre de terminal série sur votre moniteur. Eh bien, avec un contrôle granulaire sur la façon dont vous traitez les données capturées par l'analyseur logique, vous n'avez pas à vous en préoccuper !
L'idée est la suivante : vous connectez un analyseur logique au bus de données et empilez deux décodeurs UART sur la même broche ! Chaque décodeur va envoyer des messages d'erreur chaque fois que le signal actuel est sur un débit en bauds différent de celui attendu par le décodeur. Désormais, Sigrok étant un projet raisonnablement modulaire et open source, vous pouvez absolument écrire un décodeur UART pour Sigrok qui fonctionne avec plusieurs débits en bauds. Si vous êtes comme moi et que vous ne voulez pas faire cela, vous pouvez également faire preuve de paresse et mélanger la sortie de deux décodeurs en temps réel, en utilisant les messages d'erreur pour vous indiquer où le changement s'est produit !
Pour ce type d’objectif, disposer d’un traitement en temps réel et uniquement sous forme de texte des données produites par Sigrok est plus que suffisant. Heureusement, les analyseurs FX2 vous permettent de capturer des données indéfiniment, et la ligne de commande Sigrok vous permet d'empiler des décodeurs de protocole qui s'exécuteront ensuite en temps réel ! J'ai donc créé un script que vous pouvez diriger sigrok-cli sortie dans, qui compare la sortie du décodeur pour déterminer quel débit en bauds est actuellement utilisé et sort les données du décodeur avec le moins de défauts. Il manque au code un algorithme de mise en mémoire tampon plus intelligent, donc le moment de commutation entre les débits en bauds est un peu gênant, comme vous pouvez le voir sur la capture d'écran, mais cela fonctionne autrement !
Avec cette approche en ligne de commande Sigrok, vous gagnez une superpuissance supplémentaire en matière d'analyseur logique ! Étant donné que les analyseurs FX2 vous permettent de capturer des données indéfiniment, en les diffusant sur votre PC au fur et à mesure de leur capture, un décodeur en ligne de commande vous permet de connecter un analyseur FX2 à un Pi Zero – afin que vous puissiez construire un petit appareil capturant et décodant un bus de données 24h/24 et 7j/7. . Placez le combo FX2 et Pi Zero à proximité de tout ce que vous essayez d'exploiter, exécutez sigrok, faites-le enregistrer les données avec des horodatages sur une carte SD et vous pourrez facilement collecter des semaines de données d'activité du bus ! C'est le genre de capacité que j'aurais aimé avoir lorsque j'étais chargé de procéder à la rétro-ingénierie d'une pièce spéciale de machine industrielle, contrôlée via CAN et utilisant un algorithme de communication semi-propriétaire ; avoir beaucoup de données aide sérieusement dans de tels scénarios et j'avais du mal à en capturer suffisamment.
Si vous préférez vous en tenir à des expériences d'interface graphique de faible profondeur, ce type d'analyse est également utile : les décodeurs de protocole Sigrok sont écrits en Python, ce qui signifie que vous pouvez également prendre votre code d'analyse de sortie Python et le transformer en décodeur de protocole accessible par Pulseview. assez facilement. Dans l’ensemble, ce type d’expérimentation vous permet d’exploiter autant que possible les analyseurs logiques les moins chers du marché. Dans le prochain article, j'aimerais approfondir les autres types d'analyseurs logiques dont nous disposons, en particulier toutes les options bon marché. Étant donné que Sigrok a récemment fusionné le PR avec la prise en charge du Pi Pico, vous pouvez aller bien au-delà de ce que les analyseurs basés sur FX2 ont à offrir !
