Blog

Jan 22, 2024

Qu'est-ce qui pourrait mal tourner : l'édition série asynchrone

C'est la chose la plus simple au monde : des données série simples et directes. Il s'agit du protocole de communication de secours pour presque tous les systèmes embarqués, et c'est donc celui que vous souhaitez vraiment utiliser.

C'est la chose la plus simple au monde : des données série simples et directes. Il s'agit du protocole de communication de secours pour presque tous les systèmes embarqués, et c'est donc celui sur lequel vous souhaitez vraiment travailler lorsque les puces sont en panne. Et encore! Lorsque vous en aurez le plus besoin, vous découvrirez peut-être que même une série asynchrone peut vous coûter quelques heures de débogage et ajouter quelques cheveux gris à votre cuir chevelu.

Dans cet article, je vais aborder la plupart (toutes ?) des choses qui peuvent mal tourner avec les protocoles série asynchrones, et comment diagnostiquer et déboguer cette méthode de transfert de données la plus utile. L'objectif est de vous faire prendre suffisamment conscience de ce qui peut mal se passer pour que, lorsque cela se produit, vous le dépanniez systématiquement en quelques minutes au lieu de perdre quelques heures.

Imaginez que vous ayez huit bits de données que vous souhaitez m'envoyer par voie électronique. Si nous avons huit fils (plus la terre) entre nous, vous pouvez simplement inverser vos huit interrupteurs et mettre des tensions hautes ou basses sur chaque fil. Si je suis à l'autre bout du fil avec des LED, je lis simplement celles qui s'allument et c'est terminé. Mais huit fils, c'est beaucoup de cuivre. Au lieu de cela, vous décidez d'envoyer un bit à la fois, en utilisant un seul fil (plus la masse). C'est l'essence même de la communication série : les bits sont envoyés en série en faisant varier la tension sur un fil avec précision au fil du temps.

Cela semble facile, mais nous devons maintenant faire des choix. À quelle vitesse envoyez-vous chaque bit ? Une LED allumée représente-t-elle un 1 ou un 0 ? Comment saurai-je quand votre message commence ou s'arrête ? Et enfin, si nous voulons tous les deux nous envoyer des données, nous aurons besoin de deux fils. Comment savoir lequel j'envoie et lequel vous envoyez ? Chacun de ces choix est un endroit où les choses se trompent et où des bugs s'insinuent.

Ce dernier point, quels câbles transmettent les données dans quelle direction, est étonnamment une source courante de confusion, c'est donc un bon point de départ pour commencer le débogage.

« RX » et « TX » signifient respectivement « recevoir » et « transmettre ». La plupart des systèmes de communication série en auront un de chaque. Souvent, la configuration ressemble à ceci : vous vous retrouverez à connecter « GND » sur un appareil jusqu'à « GND » sur l'autre. Peut-être qu'ils partageront également un rail d'alimentation, vous connecterez donc le « VCC » de l'un au « VCC » de l'autre. Et puis, au fur et à mesure, vous connecterez « RX » sur un appareil jusqu'à « RX » sur l'autre.

Et c'est l'erreur numéro un. Les deux appareils s'attendent à recevoir des données sur leur ligne « RX », ils restent donc tous les deux assis là à attendre que les deux lignes « TX » finissent par se parler. Non, la « bonne » façon de procéder est de connecter le port « RX » d’un appareil au port « TX » de l’autre et vice versa. C'est juste logique, non ? Pour vous aider à vous le rappeler, parfois le « TX » sera étiqueté « TXD » où le « D » signifie « appareil » et cela est censé vous rappeler que vous regardez les choses du point de vue de cet appareil.

Quel que soit le nom que vous lui donnez, la connexion d'un port appelé « TX » à un port appelé « RX » provoque des problèmes dans les programmes de CAO modernes, où vous nommez le réseau plutôt que les ports individuels. Comment appelle-t-on un fil qui relie les broches « GND » des deux appareils ? "GND" est un bon nom. Comment appelle-t-on le fil qui relie « TX » à « RX » ? Que diriez-vous de celui qui connecte « RX » à « TX » ? La confusion règne.

(Notez que SPI, qui a ses propres problèmes que nous aborderons la prochaine fois, appelle ces lignes « master in, slave out » et « master out, slave in ». Les noms de lignes sont cohérents, et si vous savez quel périphérique vous regardez, vous savez instantanément dans quelle direction les données circulent. C'est bien mieux.)

La première question de débogage à vous poser est donc de savoir si vous avez correctement franchi les lignes de signal. Et même si c'est le cas, essayez quand même de les échanger car même si vous n'êtes pas confus, vous ne pouvez pas être sûr que l'ingénieur en amont de vous ne l'était pas. (Nous l'avons vu se produire.)

Nous avons tout compris, alors qu'en est-il de la vitesse à laquelle vous envoyez (et recevez) des données ? C'est important, car si vous voyez une haute tension sur votre fil pendant un certain temps, vous devez savoir combien de bits ce « pendant » était censé représenter. Si je vous envoie quatre zéros, vous verrez une tension constante pendant deux fois plus longtemps que si je vous en envoyais deux, mais nous devons nous mettre d'accord sur une base de temps afin que vous puissiez être sûr que je n'ai pas simplement envoyé deux zéros, ou huit. .