RS-485 - Mauvaise réception trame

[Snypp]

Bonjour à tous,

Je travaille actuellement sur le PIC16F15223 de chez Microchip. Mon but est d'envoyer une trame côté PC vers mon microcontrôleur. Pour cela, j'utilise le logiciel Dockligth. Cependant, j'ai un petit problème.

J'opère de la façon suivante : lorsque mon PIC reçoit un byte, cela déclenche une interruption dans laquelle je vais lire ce byte et le renvoyer au PC. Cette étape fonctionne correctement à l'exception du fait que le caractère reçu (et donc renvoyé) ne correspond pas au caractère envoyé côté PC.
En réalité, il semble y avoir une inversion puisque lorsque j'envoie 0xFF côté PC, je lis 0x00 côté µc.
Ci-dessous quelques autres exemples :
PC : Microcontrôleur :
0x00 0x00
0x01 0x7F
0x02 0x3F
0x03 0X7E
0xFE 0x00
0xFF 0x00

En observant à l'oscilo sur la PIN réception du PIC, je note bien cette inversion, avec 8 bits à 1 pour 0x00 (or le micro lit 0x00...) et 8 bits à 0 pour 0xFF.
J'ai pensé dans un premier temps que le problème pouvait venir d'une mauvaise configuration du BaudRate, mais ça n'a pas l'air d'être le cas. J'ai aussi cherché s'il n'existait pas un registre de configuration pouvant provoquer cette inversion, mais je n'ai rien trouvé, si ce n'est le registre "SCKP Clock/Transmit Polarity Select", mais sa configuration n'a pas solvé le problème.

Je reste disponible pour détailler davantage si besoin.

N'hésitez pas si vous avez des pistes concernant ce problème, je vous remercie par avance.
-----

[vincent66]

bonsoir...!
Euh ... A et B inversés sur un des deux connecteurs...?

[Jack]

Les bits start et stop (éventuellement la parité) sont aussi inversés?

Et si tu envoies des données avec autre terminal tel que putty ou teraterm?

On peut voir un oscillogramme avec 0x03 par exemple?

[Snypp]

Bonjour !

Tout d'abord, je vous remercie pour vos réponses.
Pour te répodnre Vincent, j'utilise 2 transceiver RS-485 (l'un pour la transmission, l'autre pour la réception) reliés à un convertisseur RS-485 vers USB. J'ai vérifié le branchement et il semble bon (RX+ --> TX+, RX- --> TX-, ...)

Dans la programmation de mon micro, je n'ai jamais réglé les bits start et stop, donc je ne sais pas trop comment vérifier ?
En envoyant mes données via un programme Python (avec PySerial), j'arrive exactement aux mêmes résultats.
Je n'ai pas accès à l'oscilo actuellement, mais j'ai relevé sur feuille quelques résultats. Je les ai représenté ci-dessous :

trames.png

Merci encore pour vos réponses !

[A voir en vidéo sur Futura]

[Jack]

On voit clairement sur les oscillogrammes que les niveaux sont inversés par rapport à la normale.

[Jack]

Ce qui me surprend, c'est l'interprétation de l'uart du µC: par exemple, pour 0x01, le '0' devrait être interprété comme le bit start. Du coup les 8 bits suivants seraient 11111100, c'est à dire 0x3F et non pas 0x7F.
pareil pour 0x05, le premier '0' étant le start, les 8 bits suivants sont donc 10111100, soit 0x3D et non pas 0x7D.

La première chose à faire est de déterminer pourquoi les niveaux logiques sont inversés. Comme le proposait vincent66, une simple inversion des fils de la paire devraient améliorer le résultat, mais je pense que tu as déjà dû essayer. Et ça donnait quoi?

[Snypp]

Merci pour ta réponse.
Dans mon cas, j'utilise 2 transceiver RS-485, l'un pour la réception, l'autre pour l'émission. En inversant les fils RX (+ et -), je ne pouvais plus envoyer de trame depuis mon microcontrôleur vers mon PC. Pour mon test, je n'avais inversé que la polarité pour les fils RX en pensant que le problème venait de là, peut-être dois-je inverser aussi les TX ?
Concernant le bit de start, ne correspond pas t'il au premier '1' ? Dans ce cas, pour 0x01 par exemple, on aurait bien : 0111 1111 => 0x7F ?

Le problème ne peut-il pas venir d'une configuration côté software ?

Merci encore pour ta réponse !

[antek]

Electriquement la ligne au repos est à l'état "1" (+V), le start bit est donc un état "0".
Sur certains PICxxx la polarité de l'horloge interne pour interpreter un niveau est paramétrable, je n'ai pas regardé de près si ça peut provoquer ces inversions.

[Jack]

Merci pour ta réponse.
Dans mon cas, j'utilise 2 transceiver RS-485, l'un pour la réception, l'autre pour l'émission. En inversant les fils RX (+ et -), je ne pouvais plus envoyer de trame depuis mon microcontrôleur vers mon PC. Pour mon test, je n'avais inversé que la polarité pour les fils RX en pensant que le problème venait de là, peut-être dois-je inverser aussi les TX ?

Il faut relier le + au + et le - au - à chaque extrémité.

Concernant le bit de start, ne correspond pas t'il au premier '1' ? Dans ce cas, pour 0x01 par exemple, on aurait bien : 0111 1111 => 0x7F ?

Comme précisé par antek, pour une transmission série asynchrone, le bit Start est un '0', donc un état bas.

Tu n'as toujours pas essayé d'inverser les 2 fils de la transmission PC -> µC? (côté PC OU côté µC, pas les 2 côtés)

[Snypp]

Merci à vous pour vos précisions.

Je ne pourrai tester d'inverser les fils de transmission que demain, mais j'ai bien branché mes fils de la façon suivante :
Côté µc : Côté convertisseur USB
RX+ --> TX+
RX- --> TX-
TX+ --> RX+
TX- --> RX-

Outre l'inversion, j'ai du mal à comprendre comment le micro interprète les trames reçues, ces dernières ne correspondant pas aux observations que l'on peut faire à l'oscillo...
De mon côté, j'avais vérifié l'impact de la polarité de la CLK en modifiant le bit SCKP. J'obtenais des résultats différents pour certaines valeurs, mais qui ne semblaient pas davantage cohérents.



Merci encore pour votre temps.

[Jack]

Outre l'inversion, j'ai du mal à comprendre comment le micro interprète les trames reçues, ces dernières ne correspondant pas aux observations que l'on peut faire à l'oscillo...

Voir mon message 4: mis à par un bit à '1' fantôme dont je ne comprends pas trop la présence, les caractères reçus sont cohérents avec un inversion de Rx

[Snypp]

En effet, en espérant que le fait d'inverser les fils de la paire réglera par la même occasion la présence de ce mystérieux bit...
Je vous tiendrai au courant de mes avancées demain, merci encore et bonne soirée !

[Snypp]

Bonjour,

Avec un peu de retard (je m'en excuse), j'ai trouvé le temps d'effectuer quelques tests. En inversant la polarité des fils (côté convertisseur USB), j'arrive à recevoir les bons caractères ! Ou presque...
En effet, lorsque mon micro lit et renvoie au PC le caractère qu'il vient de recevoir, un octet à 0 vient se rajouter :



Ce qui m'étonne, c'est que je n'avais pas du tout ce problème lorsque il y avait une inversion. De plus, en mode debug sur mon µc, le registre de réception (RC1REG) contient bien la valeur que j'envoie sans la présence de cet octet nul, même chose pour le registre d'émission (TX1REG).
Avez-vous des idées concernant ce problème ? J'avais pensé à une mauvaise interprétation du bit de stop, mais cela devrait logiquement se répercuter sur la valeur lue dans mon registre de réception ?

[ATdevice]

Bonjour,

Il faudrait revoir la configuration de l'UART côté microcontrôleur, selon les PIC il y a différentes configurations, notamment le nombre de bit de stop (1 ou 2) et la taille du mot (7, 8 voire 9 bit)
ça pourrait expliquer qu'il y a des bits qui ne sont pas au bon niveau/bonne place.

Pour l'histoire de l'inversion complète, il faudrait observer directement au niveau des broches RX et TX du microcontrôleur pour voir si l'inversion vient du transceiver RS-485 ou si c'est une quelconque config dans le programme

[umfred]

Concernant l'inversion, si tu attaques directement les pins RX/TX de ton PIC, c'est peut-être que ton transceiver convertit le rs485 en Rs232 "classique" et donc il faut un étage rs232 <-> TTL de type MAX232 (ou MAX3232 pour TTL en 3.3 à 5V)