Vitesse d'horloge du récepteur UART

J'essayais de comprendre les principes fondamentaux de l'UART.

• C'est un protocole de communication asynchrone et donc les horloges TX et RX sont indépendantes les unes des autres
• La réception des données est garantie par l'utilisation d'un bit de démarrage et d'un ou plusieurs bits d'arrêt. De plus, le récepteur doit être conscient du débit de données afin de générer une horloge appropriée pour piloter le registre SIPO utilisé pour la réception.

Les questions ici sont

Il est mentionné que normalement une horloge de 16X le débit binaire est utilisée pour récupérer les données. Alors, comment la conversion de bps en fréquence d'horloge est-elle possible? Veuillez me fournir quelques références pour étudier le mécanisme de synchronisation utilisé dans le récepteur UART.

Les horloges émettrice et réceptrice sont indépendantes l'une de l'autre, de la même manière qu'elles sont générées indépendamment, mais elles doivent être bien adaptées pour assurer une transmission correcte.

Le bit de démarrage, qui est faible, et le bit d'arrêt, qui est élevé, garantissent qu'entre deux octets, il y a toujours une transition de haut en bas sur laquelle le récepteur peut se synchroniser, mais après cela, c'est tout seul: il n'y a plus de temps indices qu'il peut utiliser pour distinguer les bits successifs. Tout ce qu'il a, c'est sa propre horloge. Donc, la chose la plus simple à faire est de commencer à partir de l'échantillon de bits de départ chaque bit au milieu de son temps. Par exemple, à 9600 bits / s, un temps de bit est de 104 µs, puis il échantillonnerait le bit de début à + 52 µs, le premier bit de données à + 52 µs + 104 µs, le deuxième bit de données à + 52 µs + 2 104 µs, etc. est le front descendant du bit de départ. Bien que l'échantillonnage du bit de départ ne soit pas vraiment nécessaire (vous$T_0$$T_0$$T_0$$\times$$T_0$sachez qu'il est bas), il est utile de vérifier que le bord de départ n'était pas un pic.

Pour une synchronisation de 52 µs, vous avez besoin du double de la fréquence d'horloge de 9600 bps, soit 19200 Hz. Mais ce n'est qu'une méthode de détection de base. Des méthodes plus avancées (lire: plus précises) prendront plusieurs échantillons d'affilée, pour éviter de frapper juste ce pic. Ensuite, vous devrez peut-être en effet une horloge 16 9600 Hz pour obtenir 16 ticks par bit, dont vous pouvez utiliser, disons, environ 5 dans ce qui devrait être le milieu d'un bit. Et utiliser un système de vote pour voir s'il doit être lu comme haut ou bas.$\times$

Si je me souviens bien, le 68HC11 a pris quelques échantillons au début, au milieu et à la fin d'un peu, le premier et le dernier probablement pour se resynchroniser en cas de changement de niveau (ce qui n'est pas garanti).

L'horloge d'échantillonnage n'est pas dérivée du débit binaire, c'est l'inverse. Pour 9600 bps, vous devrez régler l'horloge d'échantillonnage à 153 600 Hz, que vous dériverez via un pré-échelle à partir de la fréquence d'horloge du microcontrôleur. Ensuite, l'horloge binaire est dérivée de celle d'une autre division par 16.

horloges inégalées
Voici ce qui se passera si l'horloge du récepteur n'est pas synchrone avec celle de l'émetteur:

L'horloge du récepteur est lente de 6,25%, et vous pouvez voir que l'échantillonnage pour chaque bit suivant sera de plus en plus tard. Une transmission UART typique se compose de 10 bits: 1 bit de démarrage, une charge utile de 8 bits de données et 1 bit d'arrêt. Ensuite, si vous échantillonnez au milieu d'un bit, vous pouvez vous permettre d'être un demi-bit au dernier bit, le bit d'arrêt. Un demi-bit sur dix bits est de 5%, donc avec notre écart de 6,25%, nous rencontrerons des problèmes. Cela apparaît clairement dans l'image: déjà au troisième bit de données, nous échantillonnons près du bord.

Revenons un peu en arrière et parlons du protocole de signalisation de bas niveau utilisé par les UART. TX et RX sont des lignes de données, pas des horloges. Les horloges ne se trouvent qu'à l'intérieur de chaque UART, c'est pourquoi il doit y avoir un accord à l'avance sur le débit en bauds.

Lorsqu'il ne transmet pas, la ligne reste inactive. Pour transmettre un octet (par exemple, d'autres largeurs de données sont possibles), l'émetteur envoie d'abord le bit de départ . Le récepteur utilise le temps du front montant du bit de départ et la vitesse de transmission connue pour décoder ensuite le reste du caractère. Disons par souci de simplicité que 100 kBauds sont utilisés. Cela signifie que chaque temps de bit est long de 10 µs. Cela inclut le bit de démarrage, les bits de données et le ou les bits d'arrêt. Par conséquent, le milieu du premier bit de données sera à 15 µs après le bord d'attaque du bit de départ, le second à 25 µs, etc.

Tant que les horloges du récepteur et de l'émetteur sont les mêmes, cela pourrait durer indéfiniment. Cependant, ils ne seront jamais exactement les mêmes, donc cela ne peut pas durer éternellement. Pour permettre la resynchronisation de l'horloge du récepteur avec l'horloge de l'émetteur, le caractère de données se termine, la ligne est laissée inactive pendant un peu, puis le processus est répété. Les erreurs de synchronisation s'accumulent à partir du bord d'attaque du bit de départ, de sorte que la dérive maximale se situe au dernier bit. Une fois ce caractère terminé, le récepteur se réinitialise en attendant le prochain bit de démarrage et le processus se répète.

Avec 8 bits de données, le pire cas de synchronisation est l'échantillonnage du dernier bit. C'est 8,5 bits de temps à partir de la référence de synchronisation, qui est le bord d'attaque du bit de départ. Si le récepteur est éteint de 1/2 bit ou plus, il échantillonnera le dernier bit pendant un bit différent. C'est clairement mauvais. Cela se produit à une différence de fréquence d'horloge de 1/2 bit sur 8 1/2 bits, soit 5,9%. C'est l'incompatibilité garantie d'échouer. Pour plus de fiabilité, vous voulez généralement vous assurer que le récepteur correspond à l'émetteur dans la moitié de celui-ci, ou 2,9%. Cela représente une erreur de temps de 1/4 bit sur le dernier bit.

Cependant, ce n'est pas aussi simple que cela. Dans le scénario décrit ci-dessus, le récepteur démarre essentiellement un chronomètre au bord d'attaque du bit de démarrage. Cela pourrait en théorie se faire en électronique analogique, mais ce serait compliqué et coûteux et difficilement intégrable sur des puces numériques. Au lieu de cela, la plupart des implémentations UART numériques ont une horloge interne qui fonctionne à 16 fois le débit binaire attendu. Le "chronomètre" compte alors ces 16x cycles. Cela signifie qu'il y a une erreur supplémentaire possible de 1/16 bit ajoutée à tous les temps d'échantillonnage de bits, ce qui est comme un autre décalage d'horloge de 0,7% au dernier bit.

Espérons que cela clarifie ce qu'est le bit d'arrêt, comment fonctionne le chronométrage des bits et ce qu'est l'horloge 16x. J'ai surtout ignoré les bits d'arrêt, mais peut-être pouvez-vous voir par vous-même pourquoi au moins un bit d'arrêt est requis. Fondamentalement, les bits d'arrêt sont le temps d'inactivité minimal appliqué entre les caractères. Il s'agit du temps pendant lequel le récepteur a fini de recevoir un caractère et est prêt pour le bord avant suivant d'un bit de départ. S'il n'y avait pas de bit d'arrêt, le dernier bit de données pourrait avoir la même polarité que le bit de démarrage et le récepteur n'aurait pas de front pour démarrer son chronomètre.

Il y a longtemps, ce protocole a été décodé par des cames, des leviers et des roues qui tournent. Deux bits d'arrêt ont souvent été utilisés pour permettre au mécanisme de se réinitialiser. De nos jours, tout se fait en logique numérique et 1 bit d'arrêt est utilisé à peu près universellement. Vous voyez souvent le protocole de bas niveau écrit en raccourci comme 8-N-1, ce qui signifie 8 bits de données, pas de bits de parité (oubliez-les, ils sont rarement utilisés aujourd'hui) et 1 bit d'arrêt. Le bit de départ est implicite car il n'y a pas d'option.

En utilisant 8-N-1, un octet de 8 bits de données prend en fait 10 fois de temps à envoyer. C'est une des raisons pour lesquelles il existe une distinction entre "débit binaire" et "débit en bauds". Le débit en bauds fait référence aux temps de signalisation des bits individuels, y compris les bits de démarrage et d'arrêt. À 100 kBauds, chaque bit transmis prend 10 µs, y compris les bits de démarrage et d'arrêt. Le caractère entier prend donc 100 µs, mais seuls 8 bits de données réelles sont transférés. Le débit en bauds est de 100 k, mais le débit binaire de transfert de données du point de vue des niveaux supérieurs n'est que de 80 kBits / s.

Le débit binaire pour la transmission est le taux d'horloge divisé par (comme vous le dites, généralement) 16. Vous avez également des bits non liés aux données pour les bits de trame (démarrage, parité, arrêt). Ainsi, pour une horloge à 16 000 Hz, vous obtenez 1 000 bits par seconde, mais après un minimum de bits de trame, seuls 800 bits de données ou 100 octets par seconde sont insérés.

Pour la réception, le récepteur compte à partir du milieu du bit de départ 16 horloges et échantillonne la ligne appelle ce qu'il voit "premier bit de données". il répète ce compte et échantillonne suffisamment de fois pour lire le symbole entier, il confirme ensuite la présence du bit d'arrêt et commence à attendre le bit de démarrage suivant.

Tant que l'horloge du récepteur est proche du taux de l'horloge de l'émetteur, l'échantillonnage frappera les bonnes parties du signal transmis.