Détection du bit de démarrage dans le logiciel UART

J'expérimente l'écriture d'un logiciel UART sur mon microcontrôleur à l'aide de broches GPIO. Il s'agit d'ajouter temporairement un canal UART sur un projet jusqu'à ce que nous obtenions la nouvelle conception implémentée qui utilise un uC avec plus de ports UART.

Ce que j'ai du mal à détecter correctement un bit de démarrage dans un flux série. La source du flux est externe et ne se soucie pas de la mise sous tension de mon appareil. Il est donc très probable que mon appareil s'allume et commence à voir des bits de données au milieu d'une transmission d'octets. Sans aucun doute, cela fera que mon logiciel UART lira des valeurs erronées, car il ne pourra pas faire la différence entre un bit de démarrage et toute autre transition de haut en bas.

Est-ce un problème inévitable avec un canal UART? Ou existe-t-il une astuce astucieuse que les fabricants d'uC utilisent dans leurs UART matériels?

Si vous utilisez une longueur de bit d'arrêt qui se distingue facilement du reste du flux de données, comme un temps de 1,5 bit, il devrait être facile de commencer à recevoir la mi-transmission. Cependant, cela se traduit par une augmentation des frais généraux. Votre débit de données total disponible souffrira à mesure que vous augmentez la longueur de votre bit d'arrêt.

Si vous n'utilisez pas le bus de manière intensive et que vous avez fréquemment des écarts entre les images, il peut simplement s'agir d'attendre que l'un de ces écarts se produise, puis de sélectionner la première transmission hi-lo comme début de votre bit de démarrage suivant.

Gardez à l'esprit que le nombre de bits de données doit être prévisible, de même que la taille de la trame, donc même si vous utilisez 100% de la capacité du bus et que votre bit d'arrêt est un temps de bit unique, vous devriez toujours pouvoir trouver le commencer bit si vous collectez suffisamment d'images. Chaque image est garantie d'avoir une transition hi-lo en elle. Le bit d'arrêt est celui qui est toujours haut. Le bit de départ est celui qui est toujours bas. En supposant que vos données sont aléatoires (ou suffisamment aléatoires), vous pouvez faire quelque chose d'aussi simple que de créer un tampon de la taille de votre trame, de définir chaque bit dedans, puis de continuer à collecter des trames et à les insérer dans ce tampon jusqu'à ce que le tampon ait seulement 1 ensemble de bits. Ce bit est votre bit d'arrêt. Celui qui suit est votre bit de départ. Voila! Vous l'avez trouvé.

Si vous utilisez un bit de parité, une autre option serait de saisir deux trames de données, de choisir le premier bit bas comme bit de départ, puis de calculer la somme de contrôle et de la comparer au bit de parité. Si cela correspond, alors vous avez (probablement) trouvé le bit de départ. Si ce n'est pas le cas, choisissez le bit bas suivant et répétez jusqu'à obtenir une bonne somme de contrôle. Si vous ne pouvez pas trouver un bit dans vos deux trames de données qui soit extrait comme un bit de démarrage valide, alors vos données ont été corrompues et vous devrez saisir deux autres trames.

Les UART matériels ont le même problème. Mais c'est généralement celui qui se résout rapidement en tout cas. À la fin de chaque trame, vérifiez le bit d'arrêt, et s'il n'est pas haut, jetez la trame et attendez la prochaine transition haut-bas. En supposant que les données de la source ne sont pas totalement pathologiques (par exemple, de longues chaînes de "UUUU" ou ASCII 0x55), l'UART finira par "se diriger" vers le bit de démarrage réel.

En supposant une transmission 8N1.

Vous devez attendre une chaîne de 9 bits hauts ou bas d'affilée.

S'il est élevé, cela signifiera soit un espace inactif dans les données, soit un caractère 0xFF et un bit STOP
ou
s'il est faible, un bit START et un caractère NULL 0x00.

L'une ou l'autre de ces conditions permettra la resynchronisation.

Pour l'accélérer: si vous connaissez certains caractères qui ne sont pas possibles dans les données, vous pouvez analyser les données entrantes à plusieurs reprises (après coup) pour chaque bit et si vous obtenez une série de 7 caractères absurdes (jeu de bits élevé, inférieur cas, codes de contrôle, ponctuation ou autre) suivi d'un caractère valide, vous pouvez être sûr que vous êtes resynchronisé.

Vous rencontrerez les mêmes problèmes lorsque vous utilisez un périphérique UART intégré et que vous ne pourrez pas effectuer d'évaluation au niveau du bit et que vous devrez également vous rappeler de réinitialiser tous les bits d'erreur de trame et autres à chaque fois qu'ils se produisent (en particulier à la mise sous tension).