La dernière fois, nous avons utilisé un analyseur logique pour étudier le ID_SD et ID_SC broches sur un Raspberry Pi, qui s’est avéré être un I2C ordinaire, puis nous avons piraté le hotplug dans le code de la caméra Raspberry Pi avec un MCU externe. Un tel exercice donne l’impression que les analyseurs logiques sont faciles, et c’est parce qu’ils le sont ! Si vous disposez d’un analyseur logique, vous constaterez que tout un tas de hacks s’offrent à vous.
Dans cet article, voyons les endroits où vous pouvez utiliser un analyseur logique et ceux où vous ne le pouvez pas. Nous commencerons par la première limitation des analyseurs logiques : la vitesse de capture. Par exemple, voici une chose intéressante que vous pouvez acheter sur Aliexpress : un bracelet de TTGO qui ressemble à un tracker de fitness habituel, mais qui contient un ESP32, ainsi qu’une IMU, un RTC et un écran IPS ! Le vendeur dispose également d’une carte de développement connectable FFC pour programmer ce bracelet via UART, ainsi que de modules d’extension de vibromoteur et de capteur de fréquence cardiaque.
Vous pouvez exécuter C, MicroPython, Rust, JavaScript ou autre – n’oubliez pas d’apporter votre propre économie d’énergie, car la batterie est très petite. Cependant, j’avais l’intention d’exécuter MicroPython dessus et je suis tombé sur un problème : l’écran du contrôleur ST7735 ne fonctionnerait tout simplement pas avec le st7735.py bibliothèque que j’ai trouvée; mon image serait mal alignée et inversée.
Les spécifications ne prévoyaient pas grand chose d’autre que « ST7735, 80×160 ». Récapitulatif – le code original utilise une bibliothèque Arduino (C++) ST7735 et fonctionne bien, et nous avons une bibliothèque MicroPython ST7735 qui ne le fait pas. En plus de cela, j’avais également du mal à faire fonctionner une bibliothèque générique Arduino ST7735. Habituellement, un tel problème est dû au fait que les commandes d’initialisation sont légèrement différentes, et la raison en est simple : ST7735 est simplement le nom du circuit intégré du contrôleur utilisé sur le panneau LCD.
Chaque écran existant a des spécificités qui vont au-delà du contrôleur : les pixels du panneau peuvent être connectés au contrôleur de différentes manières, avec différents décalages et types de connexion, et le panneau peut nécessiter différentes exigences en matière de pompe de charge LCD – par exemple. , selon les propriétés du panneau, vous devrez peut-être écrire 0x10 dans un certain registre du ST7735, ou vous aurez besoin 0x40. Si vous vous trompez sur un ou plusieurs de ces registres, vous vous retrouverez au mieux avec une image mal alignée sur votre écran, ou au pire aucune sortie.
2 Rapide 2 Prise
Tout d’abord, j’ai essayé de lire le code pour comparer les paramètres d’initialisation à vue. Cependant, il était suffisamment abstrait pour être difficile à comparer – le code C++ ressemblait à write_to_display(ST7735_PWCTR1 , 2+TFT_INIT_DELAY, 0x02, 0x70, 10) et le code MicroPython ressemblait à write_to_display(0xC0, 0x80, 0x02, 0x70, 0xA). Décoder soixante lignes de #define-Le code C lourd n’était pas dans mes plans pour la journée, et j’ai connecté mon analyseur logique aux broches SPI de l’écran, dans le but de capturer les commandes au fur et à mesure de leur transfert.
L’écran comporte un certain nombre de broches que nous pouvons voir sur le schéma du bracelet. L’un d’eux contient les données SPI, un autre est l’horloge SPI et un autre est appelé RS, également connu sous le nom de D/C ou A0 sur d’autres écrans SPI comme celui-ci – il est utilisé pour indiquer à l’affichage si vous envoyez des commandes ou des données ( valeurs de pixels). Il y a aussi des broches RESET et CS, mais nous n’avons pas besoin de les capturer – nous n’avons aucun autre appareil sur ce bus SPI donc CS n’a aucun sens, et nous ne nous soucions pas non plus du moment où l’affichage est réinitialisé. En conséquence, nous n’avons besoin de connecter que trois GPIO à notre analyseur.
Cependant, si vous exécutez l’analyseur logique dans cet état, vous remarquerez rapidement un problème : le signal n’a pas beaucoup de sens, l’horloge est tronquée et les données du paquet ne peuvent pas être décodées. C’est ici que notre analyseur logique à 5 $ échoue : nous devons capturer tout un tas de données SPI, mais la vitesse SPI utilisée par ce code est tout simplement bien trop rapide. C’est logique : vous souhaitez transmettre les données à votre écran le plus rapidement possible, afin que vos images y apparaissent plus rapidement.
Il s’agit d’une limitation de l’interface USB 2.0 que la puce FX2 de notre analyseur peut utiliser ; notre analyseur logique a une vitesse de connexion de 480 Mbps, soit 480 mégabits par seconde, soit seulement 60 mégaoctets par seconde, et c’est sans protocole USB ni surcharge de protocole de bas niveau de l’analyseur logique. Ces analyseurs sont appelés analyseurs 24 MHz pour une raison : c’est à peu près la fréquence la plus rapide à laquelle vous pouvez diffuser des octets sur votre PC, et notre interface SPI a été configurée plus rapidement que cela, car cela avait du sens. Et, encore une fois, vous souhaitez utiliser une fréquence de capture qui est trois ou quatre fois supérieure à la fréquence du signal – capturer à deux fois la fréquence est théoriquement acceptable, mais en pratique, cela entraînera des points de données manqués, car les signaux que nous mesurons le sont. imparfait.
Ralentissez pour comparer
Il existe trois façons de contourner un tel problème. La première consiste à obtenir un analyseur logique plus rapide : il existe des analyseurs qui se connectent via un port USB3 et vous pouvez les acheter en ligne. Il existe également des analyseurs logiques dotés d’une puce mémoire : ils capturent un signal à vitesse plus élevée pendant un certain temps dans leur puce mémoire, puis transmettent toutes les données capturées à votre PC via l’interface USB comparativement plus lente. Ce n’est pas aussi pratique que le mode streaming que nous obtenons avec les analyseurs FX2, mais cela rend possible certains types de captures ! Et, si vous vous le demandiez, nos analyseurs FX2 ne disposent pas de mémoire supplémentaire pour une telle astuce.
La troisième façon, comme vous l’avez peut-être deviné, consiste à réduire la vitesse SPI dans le code ! Les écrans fonctionnent généralement bien avec une vitesse SPI faible – il est beaucoup plus courant de voir des limitations de vitesse « les plus élevées possibles » plutôt que des limitations « les plus basses possibles ». Du côté de MicroPython, c’était trivial, et du côté du firmware d’usine, il a fallu un peu de temps pour trouver le code source – le GitHub officiel ne semblait avoir que des fichiers .bin au début, j’ai dû fouiller dans le » Exemples »pour trouver le code source de ceux-ci.
Après avoir capturé les communications d’affichage, j’ai pu exporter les journaux des deux communications et voir quels paramètres d’initialisation la bibliothèque Arduino utilise réellement. Ensuite, j’ai mis les paramètres d’initialisation SPI fonctionnels dans le code source de la bibliothèque MicroPython ST7735, et l’affichage piloté par MicroPython a commencé à fonctionner correctement !
Une faible vitesse de capture ne sera pas un problème pour les interfaces à faible vitesse comme UART, I2C et bien d’autres – c’est pourquoi j’ai commencé le premier article avec I2C comme exemple, car il est difficile de tout gâcher. Pour les interfaces comme SPI, la vitesse peut être un problème.
Par exemple, prenez votre carte de développement ESP32 ou ESP8266 la plus proche – elle aura une interface qSPI (quad SPI) pour communiquer avec la puce flash, et cette interface est généralement exposée sur les broches SD0-3 sur les cartes de développement bon marché ; imprudemment, car le câblage jusqu’à ces broches ne peut vraiment casser les choses que si vous savez ce que vous faites. Cette interface va généralement à 40 MHz ou même plus, ce qui nécessite que vous obteniez un analyseur correctement spécifié, car 25 MHz maximum ne le feront plus, et vous ne pouvez pas non plus simplement réduire la vitesse de l’interface.
La vitesse n’est pas non plus la seule limitation de l’analyse logique : toutes les interfaces ne peuvent pas être facilement exploitées au départ.
Apportez du matériel supplémentaire
Un analyseur logique ne peut capturer que des signaux numériques de niveau logique référencés à la terre, oscillant de la terre à 3,3 V ou 5 V. Nous les connaissons sous le nom de signaux asymétriques, et ceux-ci incluent SPI, I2C, UART et bien d’autres. Cependant, dans ce monde technologique complexe, de nombreux signaux sont différentiels, beaucoup sont analogiques et certains sont numériques mais comportent une composante analogique.
Prenons RS232, RS485 et CAN : ce sont des interfaces puissantes utilisées dans les environnements automobiles et embarqués ; votre voiture dispose probablement d’un réseau CAN et si vous travaillez avec des équipements industriels, elle peut avoir une connexion RS232 ou RS485 exposée à des fins de communication. Cependant, RS232 n’est décidément pas un niveau logique – au lieu de 0 V et 5 V, il passe de -12 V à 12 V. RS485 et CAN, en revanche, sont des interfaces différentielles – si vous ne vous en souvenez pas, une paire différentielle code 0 et 1 avec deux signaux, et les niveaux de tension sur ces paires sont relatifs les uns aux autres par opposition à la masse – pas du tout de signalisation de niveau logique.
Cependant, tout n’est pas perdu – tout ce que vous avez à faire est d’obtenir une puce PHY RS232/RS485/CAN au niveau logique, de la régler en mode réception et d’écouter sa sortie – en recevant toutes les communications du bus, bien converties. à une plage de niveaux logiques ! Il en va de même pour les communications USB-PD, sauf que je n’ai pas vraiment vu de PHY qui vous permette de recevoir les communications PD sous forme de signal de niveau logique. Cependant, vous pouvez créer un circuit avec un amplificateur opérationnel et écouter les secrets les plus profonds de vos appareils USB-C.
Une situation similaire se produit avec l’interface USB : vous vous souviendrez peut-être que certains périphériques USB fonctionnent à 12 Mbps, ce qui est une vitesse relativement faible ; ces appareils sont des souris, des claviers et de nombreux MCU comme le RP2040. Vous pourriez penser qu’il serait facile de connecter un tel signal USB à un analyseur logique, mais pas si rapidement : l’USB utilise également une paire différentielle ! Pire encore, la paire est également semi-duplex : vous pouvez transférer des données d’un hôte à un appareil, ou d’un appareil à l’autre, mais pas les deux en même temps.
Ainsi, si vous souhaitez capturer les communications USB, vous devrez exploiter les fils D+ et D-, les convertir en un signal asymétrique d’une manière ou d’une autre, disons, avec un amplificateur opérationnel suffisamment rapide, puis interpréter les paquets USB. ‘direction de leur contenu. Attention, cela ne couvrirait que la communication à 12 Mbps (pleine vitesse) – l’USB fonctionne un peu différemment à 480 Mbps (haute vitesse), et il serait de toute façon hors de portée d’un analyseur bon marché. C’est pourquoi il existe des analyseurs logiques dédiés : ils peuvent avoir un prix un peu élevé, mais ils peuvent être indispensables. Il existe également des options logicielles de capture de paquets USB que vous pouvez utiliser, par exemple, Wireshark propose un plugin pour cela.
Hors de portée
Bien sûr, il existe toute une série d’interfaces encore plus rapides que cela. Si vous souhaitez analyser PCIe, USB3 ou DisplayPort, vous souhaiterez vous procurer un analyseur dédié au lieu d’un analyseur générique – ces interfaces sont à la fois différentielles et très rapides, et c’est le point où vous souhaitez obtenir quelque chose de spécialement conçu. Un analyseur logique n’est pas aussi efficace qu’un périphérique dédié qui reçoit le signal, c’est avant tout un outil d’analyse, et il échantillonnerait mal un signal à très haute vitesse lorsque ce qui vous importe vraiment est soit le contenu du paquet, soit le signal. propriétés analogiques.
Même en dessous de 100 MHz, les choses resteront délicates. Il y a l’interface LPC, qui est essentiellement l’ancienne ISA mais réduite à six fils – fonctionnant à des vitesses de 33 MHz à 100 MHz. Même s’il s’agit d’un niveau logique, le signal LPC est un flux constant de messages entre le CPU ou le chipset et les autres périphériques, et ce n’est pas le genre de signal que vous souhaitez mettre sur des câbles de prototypage sans au moins le mettre en mémoire tampon – les réflexions vous obtiendront. . En fin de compte, obtenir un FPGA pour décoder les signaux LPC pourrait être bien moins cher que d’obtenir un analyseur et une configuration matérielle capable de gérer directement le décodage LPC. Du côté positif, si vous mettez la main sur les messages du bus LPC, vous avez une chance de montrer à tout le monde que tous ces TPM sophistiqués ne sont pas ce qu’ils semblent être !
Enfin, voici un autre avertissement concret pour la route. Si vous souhaitez capturer un signal de 1,8 V, votre analyseur logique pourrait échouer – cela dépendra du fait qu’il dispose ou non d’un tampon d’entrée et de quel type de tampon il s’agit. Avec la technologie 1,8 V devenant de plus en plus abondante chaque jour, si vous n’obtenez pas de signal lorsque vous testez une technologie, vous pourriez faire du bien en jetant un oscilloscope sur la broche pour doubler le contrôle et en utilisant un circuit intégré logique pour tamponner le signal. s’il s’avère qu’il y a effectivement une activité et qu’elle est juste hors de la plage d’entrée pour votre LA à 5 $ !
