Problème liaison série sur micro contrôleur PIC 18F4523

[gillou026]

Bonjour

J'ai un problème pas banal que je n'arrive pas à solutionner, avec la liaison série d'un micro contrôleur PIC 18F4523.

Sur mon système il y a 2 cartes électronique.

La première est composée en gros d'un clavier 4 x4 touches, un écran LCD 4 x16 caractères, quelques bricoles, le tout géré par un PIC 18F4523.
Sur l'écran tout un tas de données sont affichées en temps réel. Là il n'y a pas de soucis ça marche correctement.

Certaines de ces données (16 au total) doivent être envoyées sur une 2ème carte qui est composée d'un PIC et d'un afficheur LCD 2 x 16 caractères. La liaison fait environ 1 mètre.

Le programme de la 1ere carte tourne dans une boucle sans fin qui dure dans les 15 ms. A chaque tour de boucle j'envoie une des 16 données.

Mon problème :

Sur les 16 données envoyées à tour de rôle sur la liaison série il y en a une qui merdouille car sur l'afficheur de la 2ème carte cette valeur n'arrête pas de changer !!!

exemple :
1ere carte : l'affichage est 21.32 et sur la 2ème ça alterne entre : 21.32 et 24.32
J'ai donc le "1" qui n'arrête pas de changer et se transforme en "4" !!!!

Le problème n'est pas sur la 2ème carte car lorsque je coupe la liaison entre les 2 l'affichage n'alterne plus.

De plus j'ai mit l'oscillo sur la sortie TX du 18F4523 et je vois bien que l'octet transmit change (alterne entre la bonne valeur et cet octet qui correspond au 4) !

Donc je ne comprends pas pourquoi l'octet qui sort de ma liaison série change de valeur comme ça ... alors que celle que je lui envoi est toujours la même ...

Quelqu'un a une idée ???

Merci pour vos réponses.
-----

[antek]

Jamais osé faire aussi long avec UART.
Liaison perturbée ?
Programme ?
Est-ce que les octets envoyés sont corrects avec la 2e carte déconnectée (Tx chargé avec 20 K au bout) ?
Comment est connecté Rx 1ère carte ?
La réalisation matérielle est-elle soignée ?

[gillou026]

Liaison perturbée ?
Non .. du tout.

Programme ?
Pour moi je ne vois pas de soucis ...


Est-ce que les octets envoyés sont corrects avec la 2e carte déconnectée (Tx chargé avec 20 K au bout) ?
Non justement c'est ce que j'explique.
Sur les 16 octets (qui sont correctement affichés sur la 1ère carte) un seul se change de façon aléatoirement lors de la transmission ... un coup il est bien envoyé, un coup il se change en une autre valeur qui sort de je ne sais où ...


Comment est connecté Rx 1ère carte ?
C'est à dire ?

La réalisation matérielle est-elle soignée ?
Oui pas de soucis.

[katmai]

Salut,

Est-ce que les octets envoyés sont corrects avec la 2e carte déconnectée (Tx chargé avec 20 K au bout) ?
Non justement c'est ce que j'explique.
Sur les 16 octets (qui sont correctement affichés sur la 1ère carte) un seul se change de façon aléatoirement lors de la transmission ... un coup il est bien envoyé, un coup il se change en une autre valeur qui sort de je ne sais où ...

Antek voulait que tu fasses le test carte déconnecté pour voir si c'était pas ta longue ligne..
Mais bon ce que tu vois à l'oscillo ne devrait pas changer entre deux boucles.
Dans le cas d'un problème de ligne, je pense que c'est plutôt une erreur d'interprétation
du récepteur qu'on devrait voir..

Personnellement je pense plutôt à un soucis logiciel dans l'émetteur.

A+

[A voir en vidéo sur Futura]

[antek]

Le programme est bon
La réalisation est correcte
La liaison n'est pas perturbée

Donc c'est l'UART qui fait des siennes . . .

[gillou026]

Oui je pense aussi à un problème logiciel dans l’émetteur mais je ne vois pas où !!!!

Ci-dessous le code ...
Cette procédure est appelée à chaque passage dans la boucle du prog principal.

C'est sur l'envoi de "dcent" que ça foire ... un coup ça l'envoi bien un coup non ... alors que sur la carte 1 l'affichage de cette variable est ok.

Côté récepteur je me sers des 4 bits de poids fort pour identifier la variable reçue. Les 4 bits de poids faibles c'est ma donnée (de 0 à 9).

void envoi_donnee_vers_lcd()
{
        // envoi des donnée vers LCD
        if (rotation_LCD == 0)
           mot_dep = 16 + d10kil;          
        if (rotation_LCD == 1)
           mot_dep = 32 + dkil;              
        if (rotation_LCD == 2)
           mot_dep = 48 + dcent;               // BUG ici 
        if (rotation_LCD == 3)
           mot_dep = 64 + ddiz;                 
        if (rotation_LCD == 4)
           mot_dep = 0 + dunit;    
        if (rotation_LCD == 5)
           mot_dep = 128 + ddiz_part;   
        if (rotation_LCD == 6)
           mot_dep = 112 + dcent_part;   
        if (rotation_LCD == 7)
           mot_dep = 96 + d1kil_part; 
        if (rotation_LCD == 8)
           mot_dep = 80 + d10kil_part; 
        if (rotation_LCD == 9)
           mot_dep = 144 + dcent_avret;   
        if (rotation_LCD == 10)
           mot_dep = 160 + ddiz_avret;  
        if (rotation_LCD == 11)
           mot_dep = 176 + dunit_avret;
        if (rotation_LCD == 12)
           mot_dep = 224 + bit_LCD_AV_RET;
        if (rotation_LCD == 13)
           mot_dep = 192 + moy_diz_lcd;
        if (rotation_LCD == 14)
           mot_dep = 208 + moy_unit_lcd;
        if (rotation_LCD == 15)
           mot_dep =  cad_on | 0xF0;    
        
        UART1_Write(mot_dep);
        delay_ms(1);
        rotation_LCD ++;
        if (rotation_LCD >= 16)
           rotation_LCD = 0;
}

[katmai]

Tu ne devrais pas coder ces valeurs comme ça:
mot_dep = 16 + d10kil;
Mais plutôt comme ça:
mot_dep = (1 << 4) + d10kil;

Voire avec un #define ça t'éviterait pas mal de bug pourris .

Mais là n'est sans doute pas le soucis.
Quel est ton baudrate?

A+

[gillou026]

Je ne pense pas que ça vienne du codage ....

ça : mot_dep = (1 << 4) + d10kil;

ou ça : mot_dep = 16 + d10kil;

ça donne la même chose ...

Pourquoi ça marche sur 15 variables et pas sur une seule qui en plus est au milieux des 16 .... ???!!!???

Elle se transforme en une autre valeur (toujours la même du reste) alors que cette variable ne bouge pas !

C'est à s'arracher les cheveux !

9600 bauds ....
Le signal est nikel, très propre et au bon timing.

Reste que ce put**** d'octet change tout seul !!!!!!!

[invite1f39ae77]

Quel est le type de mot_dep et et dcent ? dcent prend des valeurs jusque combien?

ps : des elsif auraient étés plus propre, et un switch aurait été encore mieux que plein de if.

[gillou026]

dcent et mot_dep sont déclarés en CHAR donc 8 bits.

dcent varie de 0 à 9. En fait les données affichées sont des distances : 00.000 kms à 99.999 kms.

Je suis bien d'accord que le "case" aurait été mieux mais bon ... ça n'explique pas pourquoi ça plante sur une valeur, en l'occurrence dcent alors que pour les autres c'est impec !

[invite1f39ae77]

Bizarre car un CHAR va de -128 à +127, et les lignes à partir de "mot_dep = 144 + dcent_avret;" alors qu'il y a un dépassement de valeur. Modifie en unsigned char pour voir

[gillou026]

J'essayerai ça demain ....

Mais c'est étonnant car toutes les variables sont en char ... et il y en a une seule où ça foire.

J'ai même essayé de virer la variable (pour voir si ça venait pas d'elle) en mettant : mot_dep = 48 + 7;

Ben le résultat est le même ... ça alterne entre affichage du 4 et du 7 ... Donc le 7 est bon mais le 4 sort de je ne sais où ....

Incompréhensible !

[katmai]

Je sais bien que le problème ne vient pas du codage..
C'était juste une suggestion parce que c'est pas lisible du tout.
Aussi il faut te protéger des éventuels débordements avec un masque.

De toute façon si tu as testé en hardcodant la valeur le problème ne vient pas de là..

À l'oscillo la valeur est la bonne ou tu la vois changer?
C'est quoi ton code d'envoi sur l'uart?
Tu peux essayer avec une tempo plus grande?

À+

[gillou026]

Sur mon outil de développement un CHAR c'est du non signé.

Pour déclarer en signé c'est : signed char

Donc c'est pas ça ....

[gillou026]

C'est quoi ton code d'envoi sur l'uart?

UART1_Write(mot_dep);

c'est la fonction toute faite de mon outil de dev (mikroC pro).