Mettre en oeuvre une liaison RS232

[inviteeab0141b]

Bonjour,

Je cherche a configurer une liaison RS232 grâce à l'USART d'un microcontrôleur de chez ATMEL.

On peut configurer les éléments suivant si je ne me trompe pas:

-données:mot de 7 ou 8 bits
-séparation entre deux mots ? oui ou non
-débit binaire => 9600 bits/s d’après le professeur c’est un standard
-bit de stop: 1 ou 2?
-parité: 1 ou aucun
-niveau de tension ? Déjà mis en œuvre dans l’interface série du micro
-état inactif « 1 » entre deux mots

Les questions que je me pose pour configurer cette liaison sont:
-Peut-on choisir 7 ou 8 bits pour les données? j'ai un doute
-La séparation entre deux mots est-elle utile?
-Au niveau du débit comment le définir? Si ce n'est en regardant la vitesse des autres périphériques aux alentour.
-Pour les ou le bit de stop! un bit est obligatoire mais un deuxième servirai a quoi?
-La parité sert a éviter les erreurs donc il vaut mieux le mettre
-Pour le niveau de tension! Il est généré par le micro par un standard mais lequel?
-A quoi sert l'état inactif entre deux mots?

Merci d'avance
-----

[invite29971eb1]

Les questions que je me pose pour configurer cette liaison sont:
-Peut-on choisir 7 ou 8 bits pour les données? j'ai un doute

On peut même choisir entre 5 et 9 bits de donnée sur l'USART d'un tiny2313. Le 7 bits devait permettre de grapiller un peu de temps sur les transmissions de caractères ASCII. Autant rester en 8 bits je pense.

-La séparation entre deux mots est-elle utile?

Je ne vois pas de quoi tu parles.

-Au niveau du débit comment le définir? Si ce n'est en regardant la vitesse des autres périphériques aux alentour.

De toutes façons, le RS-232, ce ne sont que deux équipements qui discutent. Si l'un deux impose une vitesse, il faut s'y calquer. Sinon, le choix de la vitesse se fait en regardant le débit nécessaire à ton application, les possibilités des deux interlocuteurs et le quartz de ton micro. En effet, le baudrate est généré à partir de l'horloge du micro et pour chaque paire vitesse de quartz/baudrate, il en résulte une erreur entre la vitesse souhaitée et la vitesse réellement obtenue. Cette différence, exprimée en pourcentage d'erreur, doit être la plus faible possible pour limiter les erreurs de transmission.

-Pour les ou le bit de stop! un bit est obligatoire mais un deuxième servirai a quoi?

Encore un reliquat de systèmes anciens. Un ancien pourra te dire, perso j'en sais rien.

-La parité sert a éviter les erreurs donc il vaut mieux le mettre

Attention, la parité n'est pas une correction d'erreur. Tout au plus, elle te dit si un bit a changé. Mais si 2 bits (ou un autre nombre pair) ont changé, le contrôle de parité ne verra rien.

-Pour le niveau de tension! Il est généré par le micro par un standard mais lequel?

généré par un standard? késako?

Les tensions RS232 sont relativement souples et on utilise généralement des circuits dédiés tels que le MAX232 pour atteindre ces niveaux.

-A quoi sert l'état inactif entre deux mots?

pas clair non plus comme question.

[invite8699d527]

concernant les niveaux de tension, en sortie d'un µC c'est généralement 3,3v ou 5v. Il faut que tu regardes si l'équipement avec lequel tu vas discuter marche avec les mêmes tensions ou pas. Si ce n'est pas le cas, tu auras besoin d'un convertisseur de niveau (type MAX232 par exemple)

[bobflux]

Le plus simple (plutôt que de coller des MAX232 partout) est de choper un câble USB-RS232 et de virer le MAX232 (ou équivalent) qui est dedans. Et voilà un port série 5V.

[A voir en vidéo sur Futura]

[inviteeab0141b]

Proposition du format de ma liaison:

-format 8 bits pour les données. Vous êtes sur que de transmettre 7 bits permet de grapiller un peu de temps sur la transmissions de caractères ASCII? Sa permet juste d'enlever un bit de donnée non?

-9600 bits/s apparement si je transmet à cette vitesse, alors je pourrai l'imposer à l'ordinateur qui recoit via hypertherminal! Reste a dire pourquoi je prend cette vitesse...dicté par mon professeur

-a voir encore pour les bits de stop 1 ou 2

-parité oui , si il y a une erreur je pourrai toujours l'afficher je pense! ce bit sera utile

Jusqu'ici, cela vous semble correcte?

-dans la doc de l'AT90USB162, j'ai trouvé ceci, "Operating Voltages : 2.7 - 5.5V"
Quel tension serait en sortie du micro donc? Ici, c'est juste les tensions qui peuvent être traité?



Ces deux phrases je ne sais plus ou je les ai vu, si je les revoie je préciserai:

-A quoi sert l'état inactif entre deux mots?
-La séparation entre deux mots est-elle utile?

[inviteeab0141b]

Si mon kit de chez ATMEL le STK526 est alimenté en 5V via la liaison USB je pense que mon microcontrôleur sortira 5V non?

[invitee05a3fcc]

Vous êtes sur que de transmettre 7 bits permet de grapiller un peu de temps sur la transmissions de caractères ASCII? Sa permet juste d'enlever un bit de donnée non?

et d'être incompatible avec beaucoup de logiciel

-9600 bits/s apparement si je transmet à cette vitesse, alors je pourrai l'imposer à l'ordinateur qui recoit via hypertherminal! Reste a dire pourquoi je prend cette vitesse...dicté par mon professeur

On fait le calcul de la vitesse en fonction de la quantité d'information à transmettre. 9600 Bds est une vitesse usuelle

-a voir encore pour les bits de stop 1 ou 2

Ca ne sert à rien de mettre deux bits stops

-parité oui , si il y a une erreur je pourrai toujours l'afficher je pense! ce bit sera utile

Il vaut mieux faire un contrôle de parité global sur la trame (ensemble d'octets) ou mieux, mettre un CRC

"Operating Voltages : 2.7 - 5.5V"
Quel tension serait en sortie du micro donc?

la sortie (et l'entrée) est entre 2.7 - 5.5V"

-A quoi sert l'état inactif entre deux mots?
-La séparation entre deux mots est-elle utile?

A rien, il faut faire un "blanc" entre deux trames pour permettre la re-synchronisation de l'UART

[inviteeab0141b]

Voici l'algorigramme correspondant ! Est-il correcte?

[invitee05a3fcc]

Met ta pièce jointe en JPG .... avant évaporation !

[Tropique]

Bonjour,

Merci de respecter les http://forums.futura-sciences.com/el...-sabonner.html et de représenter l'image en un format autre que le pdf, réservé aux documents complexes et multipages.

[inviteeab0141b]

IL manque juste la bulle du début et de la fin! je les ai pas pris a cause du format après la taille serai trop petite

[invitee05a3fcc]

On ne fait pas d'extinction de l'UART .... quand il n'a plus rien à transmettre, il ne transmet plus rien .

C'est quoi tes données à transmettre? des caractères codés en ASCII ?
Il faut rajouter un caractère de début et un de fin pour que le machin qui reçoit puisse déterminer le début et la fin d'une trame. On utilise généralement 0x0A et 0x0D .

[Jack]

pour sécuriser une transmission RS232, on peut toujours avoir recours aux braves vieux protocoles qui ont fait leur preuves kermit, ou Xmodem, ymodem, etc qui sont reconnus par l'hyperterminal du PC, donc faciles à tester.

A+

[inviteeab0141b]

Mes données à transmettre viennent des jauges de ponts bascule de la société Précia Molen car notre projet de fin d'année est en partenariat avec cette société.

Mais la nature des données étant donné que je ne suis que sur la partie de mise en oeuvre d'une liaison RS232 et USB pour externaliser les données sur un ordinateur, je ne m'y suis pas encore intéressé.

Oui pour ce qu'il faut rajouter en fin de trame. D'ailleurs, on l'a déjà évoqué en projet

[inviteeab0141b]

Etant donné que j'utilise l'USART pour un AT90USB162, si j'utilise un autre type de protocole, qu'est-ce que je devrais faire à ce moment la?

Me créer mon protocole sans me servir de l'interface port série déjà fabriqué?

[invitee05a3fcc]

je ne m'y suis pas encore intéressé.

C'est la première chose à faire ..... regarder le protocole !

[Jack]

Précia Molen? Je constate que tu es toujours dans la région.

Les pont bascules ne communiqueraient-ils pas en modbus par hasard?

A+

[invite29971eb1]

Précia Molen? Je constate que tu es toujours dans la région.

Les pont bascules ne communiqueraient-ils pas en modbus par hasard?

A+

On passerait en RS-485 alors....on est pas rendus

[inviteeab0141b]

C'est la première chose à faire ..... regarder le protocole !

Je l'ai fait mais pas pour les données qui me parviennent

[invitee05a3fcc]

regarder le protocole !

Et c'est quoi le protocole ?

[inviteeab0141b]

Le protocole sera soit du RS232 pour les courtes distances soit du RS485 pour les longues distances.

Pour ce qui est des informations venant des ponts bascules ou autres systèmes, elles seront codées en ASCII effectivement.

[invitee05a3fcc]

Le protocole sera soit du RS232 pour les courtes distances soit du RS485 pour les longues distances.

Faut choisir ... ce n'est pas le même transceiver ni la même gestion soft

[inviteeab0141b]

Tout ce qui est en rouge reste à justifier parce que je sens que les interrogateurs de mon projet vont se fait plaisir sinon

Configuration du port série du micro :

-transmettre sur 7 tb permet de grappiller du temps mais on sera incompatible avec beaucoup de logiciel donc on va partir sur 8 bits car les caractères ASCII sont codés sur 8 bits. SI l’on prend 9 bits
qu’adviendra t-il ?

-On choisira une vitesse de 9600 bits/s car c’est une vitesse usuelle

-Inutilité de mettre 2 bits de stop donc on en mettra un seul

-Parité oui mais il n’y aura pas de correction juste une indication d’erreur et si l’on utilise un CRC(code à redondance cyclique) ?

-Pour notre micro : tensions d’entrées et de sorties comprises entre 2,7 et 5,5V

Pour le protocole, on peut recevoir des informations de ces deux types de liaison, je ne peux pas choisir. Tout dépend de ce qu'on rencontre sur le terrain.

On sort du 0 à 5V pour ensuite convertir ces signaux en la norme RS232 ou RS485.

[inviteeab0141b]

il faut faire un "blanc" entre deux trames pour permettre la re-synchronisation de l'UART

Ce "blanc" est fait automatiquement?

[Jack]

On passerait en RS-485 alors....on est pas rendus

Le protocole sera soit du RS232 pour les courtes distances soit du RS485 pour les longues distances.

hé! hé!

il faut faire un "blanc" entre deux trames pour permettre la re-synchronisation de l'UART

Ce "blanc" est fait automatiquement?

Pourquoi faire un blanc? Si dans la trame, on a sa longueur par exemple, il n'y a pas de raison de perdre la synchronisation.

A+

[invitee05a3fcc]

Tout ce qui est en rouge reste à justifier parce que je sens que les interrogateurs de mon projet vont se fait plaisir sinon

Non, il y a rien à justifier (et ça sert à rien). C'est ta bascule qui impose le protocole

il n'y a pas de raison de perdre la synchronisation.

Si on a une suite ininterrompue de caractères asynchrones et que le récepteur est mis sous tension... il n'est pas évident que celui-ci puisse retrouver le bit de start parmi la horde de (h)uns de la transmission....

Aussi, il est de bonne pratique de suspendre, pendant au moins la durée d'un caractère, la transmission de temps en temps

[inviteeab0141b]

Je pense que j'ai quand même à justifier ceci car ma fonction va lire les données dans une mémoire et envoyer ou plutôt externaliser les informations sur un ordinateur.

J'aimerai aussi savoir si suspendre la transmission pendant un temps est nécessaire? Sous peine peut être d'avoir des erreurs à la longue.

[inviteeab0141b]

Le protocole Xmodem n'a pas d'assistant de configuration comme l'USART du port série des micros de chez ATMEL non?

Ceci étant dit, il faudrait programmer un protocole! Ce qui pour le moment n'est pas chose aisé pour moi

[Jack]

Si on a une suite ininterrompue de caractères asynchrones et que le récepteur est mis sous tension... il n'est pas évident que celui-ci puisse retrouver le bit de start parmi la horde de (h)uns de la transmission....

Aussi, il est de bonne pratique de suspendre, pendant au moins la durée d'un caractère, la transmission de temps en temps

Ca se fera tout seul concrètement. Le seul cas où on reçoit un long flux ininterrompu de données, c'est au cours de la transmission d'un fichier. Du coup, si on loupe le début, ça ne sert à rien de récupérer le reste.
Entre deux envois successifs, il est peut effectivement être intéressant d'avoir un court blanc pour assurer la synchro, mais si on reçoit suffisamment de données, ça va se resynchroniser tout seul.

Le protocole Xmodem n'a pas d'assistant de configuration comme l'USART du port série des micros de chez ATMEL non?

Ceci étant dit, il faudrait programmer un protocole! Ce qui pour le moment n'est pas chose aisé pour mo

le protocole dont je t'ai parlé est une couche au dessus du protocole asynchrone de l'usart (start, data, parité, stop). Il y a échange entre émetteur et récepteur afin de garantir l'acheminement des données sans erreur.

L'écriture d'un tel protocole n'est pas spécialement compliqué.

A+

[invitee05a3fcc]

Avant de trouver des solutions .... il faut poser les problèmes.
On a maintenant l'impression que tu dois dialoguer avec un PC ? Si c'est une liaison série, c'est en RS232 ou USB ... rarement en RS485 !

Tu dois définir combien tu as d'information par seconde
Tu dois définir si les valeurs sont transmise en binaire ou en BCD (codé en ASCII) ou en décimal (codé en ASCII)
Tu dois définir quel est le logiciel (écrit par qui ?) qui reçoit tes informations sur le PC

Bref .... tu fais un cahier des charges