Communication UART et GND

[Bastien59]

Bonjour à tous et à toutes,

Voici ma situation :
J'ai une board de test/développement sur laquelle je viens brancher un module radio, avec lequel je communique à l'aide d'un certain protocole via une chip (FT232) qui transforme un signal USB en un signal UART (la communication se fait via un logiciel sur PC).
Aucun soucis à ce niveau là, la communication se fait très bien (en même temps c'est un kit acheté, il vaudrait mieux)

Maintenant je souhaite établir une communication avec ce module radio, toujours par UART, mais depuis un microcontrôleur (PIC18F97J60) et donc vers le microcontrôleur (STM32L151) du module radio.
C'est là que ça se corse, et mes interrogations sont les suivantes :

• Sur le device comportant mon PIC18F, je n'ai pas l'alimentation adéquate pour alimenter mon module radio (il me faudrait du 3V, j'ai du 5V)
• Ce que je fais c'est donc que j'alimente toujours mon module radio via la board de test, mais avec la connexion entre les deux microcontroleur et pas avec l'USB/UART
• Je me retrouve donc avec deux GND, celui de l'alimentation 3V de ma board de développement, branché au module radio, et celui de mon device qui fournit 5V
• Est-ce que relier les deux GND du 3 et 5V est suffisant pour établir cette communication UART ? J'esère que c'est assez clair ...

PS1 : oui, mes deux micorcontroleurs sont au même baudrate (115200)
PS2 : oui, TX et RX sont bien croisés
PS3 : oui, j'observe bien la trame envoyée depuis mon PIC18F sur TX à l'oscillo

Merci de m'avoir lu
-----

[jiherve]

Bonjour

Est-ce que relier les deux GND du 3 et 5V est suffisant pour établir cette communication UART ?

Oui il faut assurer l'équipotentialité et tu auras de la chance si rien n'est flingué!
JR

[antek]

Est-ce que relier les deux GND du 3 et 5V est suffisant pour établir cette communication UART ?

Oui, si les niveaux de tensions entre les deux µC sont compatibles.

[Aurélien]

Et quel est le probleme exactement ? Le module radio ne renvoie aucune donnée ?
Observes tu des réponses du module radio à l'oscillo ou pas ?
Ton PIC ne doit pas être alimenté en 5V mais en 3V/3.3V, pourquoi ne pas prendre sur cette alim (à moins qu'elle ne soit générée en interne par le PIC) ?

[A voir en vidéo sur Futura]

[jiherve]

Re

Oui, si les niveaux de tensions entre les deux µC sont compatibles

en effet j'avais zappé les niveaux logique mais il ne va pas comprendre.
si les signaux du PIC sont en 5V donc le signal TX issu du PIC risque d’être trop costaud pour le STM32L151 et à l'inverse le TX du STM32L151
risque d’être faiblard pour le PIC.
Si la liaison n'est pas trop rapide un pont diviseur règle le premier cas (PIC=> STM), le second demande une analyse des datasheet.
JR

[Bastien59]

Oui, si les niveaux de tensions entre les deux µC sont compatibles.

C'est le cas, 3V

Et quel est le probleme exactement ? Le module radio ne renvoie aucune donnée ?
Observes tu des réponses du module radio à l'oscillo ou pas ?
Ton PIC ne doit pas être alimenté en 5V mais en 3V/3.3V, pourquoi ne pas prendre sur cette alim (à moins qu'elle ne soit générée en interne par le PIC) ?

Oui le module radio ne renvoi pas de données, rien sur RX à l'oscillo, je suppose donc qu'il n'a pas compris le message envoyé
Oui mon PIC est alimenté en 3V3, le truc c'est que je n'ai pas de broche sur laquelle me connecter pour ce 3V3, je n'ai qu'une sortie 5V ..

EDIT

si les signaux du PIC sont en 5V donc le signal TX issu du PIC risque d’être trop costaud pour le STM32L151 et à l'inverse le TX du STM32L151
risque d’être faiblard pour le PIC.

Signaux PIC 3V

[jiherve]

Re
pas de soucis les deux devraient être en 3,3V.
donc avec des masses communes la bobinette cherrera!
JR

[Aurélien]

Verifie la parité de ta comm ? Il n'y a pas d'autres signaux que Tx/Rx sur ton module ? Tu ne dois pas attendre un certain délai avant qu'il soit initialisé ?

[Bastien59]

Verifie la parité de ta comm ?

Pas de parité dans la datasheet du module radio, le port UART du pic18 est configuré comme ça donc à priori pas de soucis là dessus.
par contre j'ai remarqué que la trame que j'envoi au module radio ne correspond pas vraiment à ce que je vois sur l'oscillo, un peu bizarre je creuse là dessus

Il n'y a pas d'autres signaux que Tx/Rx sur ton module

Si tu veux parler de CTS/RTS ils ne sont pas utilisés par le module radio

Tu ne dois pas attendre un certain délai avant qu'il soit initialisé ?

Je n'ai pas d'infos là dessus, rien sur la datasheet, mais bien vu, je vais me mettre un timer de quelques secondes en début de programme

[Bastien59]

par contre j'ai remarqué que la trame que j'envoi au module radio ne correspond pas vraiment à ce que je vois sur l'oscillo, un peu bizarre je creuse là dessus

Erreur de ma part là dessus, je n'avais pas pris le LSB first, j'arrive bien à décoder la trame que j'envoi à l'oscillo.
Par contre entre chaque octet de j'envoi, j'ai un niveau haut d'environ 66us puis un niveau d'environ 8us, c'est normal ?

[jiherve]

Re
66µS etat haut et 8 µs etat bas ?
à quelle vitesse es tu ?
JR

[Bastien59]

Re
66µS etat haut et 8 µs etat bas ?
à quelle vitesse es tu ?
JR

Oui c'est ce que je constate à l'oscillo

Baudrate 115200
Fréquence 41,6MHz

[jiherve]

Re
le niveau haut c'est l’état de repos (stop) mais ton pulse de 8µS cela correspondrait à un start bit !
peux tu placer une photo de ce que ton scope capture?
JR

[Aurélien]

8µs = durée d'un bit (de start en l'occurence) et 66µs c'et le temps que tu dois mettre ton programme à recharger la prochaine variable à envoyer (en fonction de ton implémentation, de l'utilisation de FIFO, interruption, etc..., le délai peut etre plus ou moins long). Dans cette famille de micro tu ne dois pas avoir de DMA malheureusement...

Aurélien

[Bastien59]

le niveau haut c'est l’état de repos (stop) mais ton pulse de 8µS cela correspondrait à un start bit !

Mais oui je suis bête merci c'est évident

peux tu placer une photo de ce que ton scope capture?

Voici, désolé pour la qualité


En bleu TX, en rose RX
La trame que j'envoie est : 0x C0 01 01 16 07 C0

Chose que j'ai remarqué, mon signal TX vaut 3,1V (sur l'image 2,81 mais parce qu'on vient de transmettre), ce qui parait correct, par contre RX est en dessous de 3V ..

[jiherve]

Re
Cela correspond bien à ce que tu souhaites envoyer mais as tu bien relié les deux GND ?
JR

[Bastien59]

Re
Cela correspond bien à ce que tu souhaites envoyer mais as tu bien relié les deux GND ?
JR

Bonjour,

Oui je suis affirmatif là dessus, le bip du multimètre me le confirme, par contre les straps que j'ai fais ne sont pas super niveau qualité (pin et connecteurs pas exactement de la même taille et donc contact peut être pas toujours bien effectué).
Je vais essayer d'en faire des meilleurs, c'est peut être ça le problème

[Bastien59]

66µS etat haut et 8 µs etat bas ?
à quelle vitesse es tu ?

Hello,

Un petit point sur mon avancement, j'ai finalement abouti à quelque chose, le problème si situait au niveau du baudrate :

Configuration 115200/8N1 ok, sauf que mon programme calculait une valeur de 23 pour ucSpbrg, alors que la datasheet indique 22 (cas "else" dans le code, la valuer de GetPeripheralClock est 41666667/4) :

	if ((((GetPeripheralClock()+2*ulBaudRate)/ulBaudRate)/16 - 1) >= 255)
	{
            usSpbrg = (GetPeripheralClock()+2*ulBaudRate)/ulBaudRate/16 - 1;
            ucBrgh = USART_BRGH_HIGH;
	}
        else    // Use the low baud rate setting
	{
	    usSpbrg = (GetPeripheralClock()+8*ulBaudRate)/ulBaudRate/4 - 1;
	    ucBrgh = USART_BRGH_LOW;
	}

Donc, en forçant ucSpbrg à 22, j'obtiens un résultat, mais pas encore top :

Ping request with response.jpg
Ping request with no response.jpg

Sur la première image, la réponse est là.
Sur la deuxième, j'ai un état de repos entre le deux premiers octet transmis un peu plus long, ça arrive de temps en temps mais je dois surement pouvoir gérer ça. Je suppose que c'est ce qui fait que je n'obtiens pas de réponse, le problème se situe surement au niveau du STM32 avec lequel je communique, je n'ai pas la main déçu et je ne sais pas comment il gère la réception UART (à part le fait qu'il soit en 115200/8N1 et la manière dont il décode les trames).

Peut être une sorte de timeout implanté qui fait qu'il drop la réception si la transmission est trop longue ?
C'est la seule chose qui me vient, du coup je vais contacter le constructeur pour voir ce qu'il me dit, à moins que vous n'ayez d'autres suggestions