Quelle est la fréquence des fréquences UART?

17

Je vais utiliser un cristal à 8 MHz pour faire fonctionner mon microcontrôleur à 16 MIPS (PLL 4x, instructions à 2 cycles). Cependant, 8 MHz ne se divise pas en fréquences UART AFAIK ... alors, à quel point ces fréquences sont-elles critiques? Je prévois d'utiliser 115 200 bauds.

L'UART peut-il fonctionner à ± 1%? Si cela ne fonctionne pas, quelle fréquence dois-je utiliser? (Je voudrais me rapprocher le plus possible de 16 MIPS, pour une vitesse de traitement maximale.) Si cela importe, j'utilise un PIC24FJ64GA004.

Thomas O
la source

Réponses:

13

Si vous êtes à moins de 1%, vous devriez être OK.

Supposons que votre UART utilise une horloge de suréchantillonnage 16x, par exemple, vous pouvez la régler sur 1 843 200 Hz pour un suréchantillonnage 16 x 115 200 bits / s. (un suréchantillonnage comme celui-ci est assez courant) Cela permet à l'UART de compter 8 sur-horloges à partir du front descendant du bit de démarrage, afin de pouvoir localiser le centre des cellules de bit à +/- une période de l'horloge, après dont il compte 16 périodes de l'over-clock pour déterminer quand échantillonner les données.

Si vous supposez qu'il peut frapper le centre du bit de départ, afin de continuer à échantillonner les données série dans les cellules binaires correctes sur 8 bits de données, la fréquence d'horloge doit rester entre (8-0,5) / 8 et (8 + 0,5 ) / 8, soit +/- 6,25% du débit binaire prévu. Un overclocking plus élevé se rapproche de la condition idéale de frapper le centre du bit de départ, mais 8x ou 16x est généralement suffisamment proche pour que vous puissiez supposer qu'une différence de 5% fonctionnera.

Cependant, vous ne pouvez pas compter sur l'autre côté étant parfaitement sur la fréquence. Si vous connectez un appareil 4% rapide à un appareil 4% lent, vous aurez un problème. J'ai rencontré au moins un cas où un PC fonctionnait un peu lentement et un appareil un peu rapide, et les deux ne pouvaient communiquer que de manière marginale, bien que le même appareil soit bien avec d'autres PC et que le PC soit bien avec d'autres dispositifs. (O-scoped ceux-ci à environ 112 kbps et 119 kbps) Pour cette raison, il est bon d'essayer d'atteindre la fréquence nominale aussi près que possible. Je n'ai jamais rien vu à moins de 2% du nominal avoir un problème.

La chose habituelle à faire est d'utiliser une fréquence d'horloge maître qui fournit un nombre entier multiple du taux de suréchantillonnage UART prévu multiplié par le débit en bauds. Par exemple, si vous vouliez un processeur fonctionnant à environ 8 MHz, vous pourriez utiliser un oscillateur à 7,3728 MHz, qui peut être divisé par 4 pour obtenir 1,8432 MHz, qui se trouve être exactement 16 fois 115200.

JustJeff
la source
8 MHz pourrait être divisé par 69 pour obtenir 115 942, ce qui est bien à ± 1%. Je me demande si le PIC prend en charge ce type de division pour son générateur de vitesse de transmission. J'espère bien, mais je ne pense pas que ce sera le cas.
Thomas O
Le PIC possède un générateur de vitesse de transmission. Cela fonctionnerait bien mais seulement pour des bauds inférieurs comme 9600, cela ne fonctionnerait pas pour des bauds élevés comme 115,200, cela devient trop imprécis.
Thomas O
Pensez-vous que je pourrais utiliser un cristal à 7,3728 MHz? (Je ne vais pas utiliser l'oscillateur interne de 7,37 MHz parce que j'aimerais de la précision.) Il me permet de diviser par 64 pour obtenir une fréquence UART de 115 200. C'est le plus rapide que je puisse faire avec une tolérance élevée.
Thomas O
1
si votre UART le prend en charge, il est préférable de lui donner un overclocking (comme 16x) afin qu'il puisse suréchantillonner le bit de départ et trouver le centre de la cellule de bit, mais obtenir un 16x pour 115K à 1% pourrait être un défi, à moins que vous utilisez un cristal baud-multiple.
JustJeff
4

La mention 1% @JustJeff n'est pas requise. La plupart des UART permettent une erreur d'un demi-bit sur le dernier bit. La plupart du temps, une trame comprend 1 bit de démarrage, 8 bits de données et 1 bit d'arrêt, pour un total de 10 bits. Un demi-bit sur 10 bits est de 5% (6,25% de JustJeff ne prend pas en compte le bit de début et de fin).

Stevenvh
la source
1
ne me citez pas mal; concernant "1%", ma déclaration était que cela pourrait être difficile à réaliser. Le "6,25%" supposait que vous arriviez au centre du bit de départ, et serait la différence maximale autorisée dans les fréquences d'horloge récepteur-émetteur dans de telles conditions.
JustJeff
1

JustJeff a oublié le bit de départ, mais Stevenh a ajouté le bit d'arrêt. En supposant le protocole commun de 8 bits de données, 1 bit de début et aucun bit de parité, (le nombre de bits d'arrêt n'a pas d'importance), il y a 8 temps de 1/2 bit du bord avant du bit de début au centre de la dernier bit de données. Généralement, vous voulez que le récepteur échantillonne ce dernier bit dans un délai de 1/4 bit. Notez que 1/2 bit est le seuil d'échec garanti. Tout ce qui se trouve à proximité devient irréalisable car il y a toujours du bruit électrique et de la gigue.

1/4 divisé par 8 1/2 = 2,94%.

Comme JustJeff l'a mentionné, la plupart des implémentations UART échantillonnent réellement les données entrantes avec une horloge 16x asynchrone. Cela ajoute une autre incertitude de temps de 1/16 bit, car c'est l'erreur avec laquelle le front avant du bit de départ peut être mesuré. Un temps de 1/16 bit sur 8 1/2 bits est un autre 0,74%. Cela vient du budget d'erreur calculé plus tôt. Vous vous retrouvez avec 2,2% de décalage d'horloge autorisé pour que le récepteur échantillonne le dernier bit dans un délai de 1/4 bit de son centre.

Comme d'autres l'ont dit, l'utilisation d'un cristal à 7,3728 MHz est une pratique courante lorsqu'un débit en bauds précis est requis. Habituellement, vous pouvez vous arranger pour faire fonctionner le CPU près de son débit maximum tout en atteignant le débit en bauds UART dans l'erreur cristal.

Olin Lathrop
la source
Je ne suis pas d'accord pour dire que les bits d'arrêt n'ont pas d'importance. Dans cette question, la communication a échoué car le bit d'arrêt a été réglé par erreur à un niveau bas.
stevenvh
Le bit d'arrêt doit être là pour que la communication globale fonctionne, mais il n'entre pas dans le calcul du budget d'erreur pour la plupart des UART. Les UART nécessiteront un temps minimum après le dernier bit de données avant le bord avant suivant du bit de démarrage suivant. C'est à cela que sert le temps d'arrêt. Lorsque ce délai n'est pas respecté, vous obtenez une "erreur de cadrage". Peut-être que c'est échantillonné comme un bit de données, mais je connais des cas où il a été traité différemment. Les anciens télétypes avaient besoin de 2 bits d'arrêt pour donner au mécanisme mécanique le temps d'être prêt à saisir le caractère suivant.
Olin Lathrop
J'ai fait référence au bit de départ à trois reprises, n'est-ce pas?
JustJeff
@OlinLathrop: Le bit d'arrêt est nécessaire pour faire en sorte que lors de l' envoi d' un octet dont le MSB est égal à zéro , il y aura être un front descendant pour le prochain bit de départ. Différents périphériques se comportent différemment dans les cas où la ligne de données devient faible avant qu'il ne soit censé le faire, mais s'il n'y avait pas de bit d'arrêt, une séquence transmise de zéro octet ne contiendrait aucune information de synchronisation utile. Une telle exigence pourrait être satisfaite par d'autres moyens avec une surcharge de cadrage fixe inférieure à 25%, mais je ne connais personne qui le fasse.
supercat
1

Un point non encore mentionné est que certains appareils s'attendent à transmettre un octet de données pour chaque octet de données qu'ils reçoivent. Si un tel appareil reçoit des données en continu, sa vitesse de transmission est même 0,1% plus lente que celle de l'appareil émetteur, et il n'a pas la possibilité d'envoyer des bits d'arrêt légèrement rétrécis, sa sortie perdra un octet de retard pour chaque 1000 consécutives octets qui entrent. Si le périphérique est limité à 16 octets de mise en mémoire tampon, il supprimera un octet de données après avoir passé environ 16 000 et baissera ensuite environ un octet pour mille. Il est intéressant de noter que les modems dits "1200 bauds" fonctionnent en fait à une vitesse légèrement supérieure à 1200 bits / seconde (je pense que c'est environ 1202) précisément pour cette raison (de sorte que même si l'émetteur est 0,15% plus rapide qu'il ne le devrait) être,

supercat
la source