Com RS232

[davidif]

Bonjour,

Je suis en train d'implémenter du code c pour utiliser les UARTs de mon micro afin de communiquer en rs232 avec un autre micro (pic32 vers PIC16)
J'ai donc générer des trames du PIC16 vers le PIC32, alors que je les vois bien passer à l'oscillo en RX du pic32 je ne les perçois pas encore dans mon buffer.

Donc histoire de comprendre comment fonctionne ces trames pour mieux appréhender mon code, j'aurai quelques questions dont je n'ai pas trouvé de réponses sur google, en autres :

Une trame est entre 10 et 12 bits, selon qu'elle comporte la parité, et 1 ou 2 bit d'arret, en me basant sur du 9600Bd (bits/s), celle-ci dure entre 1ms et 1,25ms.

En fait, ce qu'il me manque comme info, c'est combien de temps doit s'écouler entre 2 trames, je supposerai quelque chose comme bien supérieur à 104uS (durée d'un bit) non ?
-----

[inviteb9f49292]

c'est combien de temps doit s'écouler entre 2 trames, je supposerai quelque chose comme bien supérieur à 104uS (durée d'un bit) non ?

A priori non, les trames peuvent être collées, c'est le bit de start qui fait la "synchro". Je suis même tombé sur un contrôleur UART qui permettait de déclencher une interruption lorsqu'il n'y avait plus d'activité sur la ligne depuis les n us correspondant à la longueur de quelques bits.

Quelques pistes:

Il existe plusieurs "niveau" d'UART, en général en sortie d'un ucontrôleur c'est du 3V3 (ou du 5V) non inversé, le 0 au 0V et le 1 au 3V3 (ou 5V), et la "vraie" RS232 (comme sur un PC par exemple) c'est -12V pour le 1 et +12V pour le 0. Tu vas d'un micro à un micro donc à priori ce devrait être bon.... sauf s'il y a un max232 (ou affilié)

Tu as bien inhibé les contrôles de flux des deux côtés ?

tu as bien croisé les fils, le rx de l'un sur le tx de l'autre (c'est un grand classique de mon bureau d'étude élec...)

Tu affiches les "buffer overrun"? car peut être ça va trop vite du coup tu n'as pas le temps de lire le caractère avant qu'il ne soit écrasé par le suivant

[jiherve]

Bonjour,
En sortie du micro c'est souvent(toujours pour ceux que j'ai utilisés )inversé , l'état de repos c'est un un, le start est un zéro.
JR

[antek]

En fait, ce qu'il me manque comme info, c'est combien de temps doit s'écouler entre 2 trames, je supposerai quelque chose comme bien supérieur à 104uS (durée d'un bit) non ?

En UART il faut attendre la fin du stop bit avant d'émettre un start bit (ça me semble normal)
Mais regarde s'il n'y a pas d'autres contraintes dues au convertisseur RS232

[A voir en vidéo sur Futura]

[inviteb9f49292]

En sortie du micro c'est souvent(toujours pour ceux que j'ai utilisés )inversé , l'état de repos c'est un un, le start est un zéro.

Longtemps que je n'ai plus mis un scope sur une liaison série, j'ai pu inverser les deux en effet...

[polo974]

Bonjour,
En sortie du micro c'est souvent(toujours pour ceux que j'ai utilisés )inversé , l'état de repos c'est un un, le start est un zéro.
JR

heu non, les datas sont dans le bon sens, c'est juste le start qui vaut 0 et le stop 1 (et le repos est à 1 aussi, ce qui permet de détecter le start).

une fois passé dans les drivers rs232, c'est tout à l'envers...

[invite0bbe92c0]

heu non, les datas sont dans le bon sens, c'est juste le start qui vaut 0 et le stop 1 (et le repos est à 1 aussi, ce qui permet de détecter le start).

une fois passé dans les drivers rs232, c'est tout à l'envers...

Et il y a aussi le NRZI .....

[jiherve]

Re,
Les stops sont gérés par l'UART, donc il ne peut y avoir chevauchement à l'émission par contre il faut une routine d'interruption à la réception s' il n'existe pas de buffer ad hoc suffisamment profond.
Et pour le sens tout est inversé, faire une petite recherche!
JR

[polo974]

Et il y a aussi le NRZI .....

embrouille pas là où c'est pas nécessaire

ici, c'est du NRZ sans le I
EOT

[jiherve]

Ré
Faute de frappe tout n'est pas inversé en sortie .
JR

[davidif]

Merci pour les infos que je vais creuser.

Pour ma configue hard, j'ai mis un max3232 en sortie RX tx de mon pic32 et idem sur l'autre pic16 puis je l'ai est bien croisés entre les deux.
Après pour l'initialisation des UART de chaque côtés, j'ai laissé faire mplab pour générer le code (code configurator, pic16) et (harmony de l'autre PIC32)

J'arrive bien à envoyer des trames dans le sens PIC16 vers PIC32 pour les visualiser à l'oscillo, maintenant reste à voir si elle sont correct afin de comprendre pourquoi mon pic32 ne les voit pas (après j'ai peu-être pas tout fait, a voir ..)

[David71120]

Bonjour,

Si j'étais toi, j'avancerai étape par étape, avant de vouloir faire le tx et le rx, je commencerais par relier le tx à un PC via un max232 ou équivalent et essayer de recevoir les trames avec un soft style terminal ou autre.
Une fois la partie Tx débugguée et fonctionnelle, je m'attaquerais à la partie Rx.

[invite01fb7c33]

Envoie un code avec une signature simple comme E1H. C'est facile à valider à l'oscilloscope.
A 9600bd tu as start bit à 0 104µs, 1er bit à 1 104µs, 4 bits à 0 416µs, 3 bits à 1 ,parité paire à 1 , 2 stop bit 208µs, à 1 pendant plus de 6 bits > 624µs.

[davidif]

Oui effectivement ce serai logiquement la meilleur méthode, seulement je n'ai pas d'interface pour communiquer avec mon pc pour le moment.

[davidif]

C'est ce que j'ai fais, par contre je n'ai pas vérifié dans le détail ma trame à l'oscillo, c'est pour ça que je demandais confirmation sur la forme de la trame, c'est ce que je vais faire maintenant.

[inviteb9f49292]

C'est ce que j'ai fais, par contre je n'ai pas vérifié dans le détail ma trame à l'oscillo, c'est pour ça que je demandais confirmation sur la forme de la trame, c'est ce que je vais faire maintenant.

Pour les codes simples je préfères 0x55 et/ou 0xAA, ça fait des signaux carrés.

Regarder à l'oscilloscope me semble assez peu pertinent car en dehors d'un convertisseur de niveau cramé, les contrôleur UART savent faire leur boulot, probablement plutôt un problème de mauvaise configuration. A la limite pour vérifier que la configuration que tu penses avoir réglée est la bonne. Mais mesurer la taille du bit de start...

Pour ce genre de chose il vaut bien mieux un analyseur logique, ils te mâchent pas mal de boulot pour analyser les protocoles UART, SPI et autres I2C. Tu en as des pas trop cher chez Embedded Artists, saleae ou dangerous prototypes par exemple. Une liste de matériel de se type est dispo sur le site du projet sigrok.

[davidif]

Bonjour,

Je reviens vers vous car j'ai pu vérifier le fonctionnement de ma com RS232, en prenant un convertisseur rs232 <--> USB ce qui m'a permis de valider tout d'abord mon tx puis mon RX indépendamment, par contre quand j'ai voulu envoyé en TX et réceptionner en RX en même tps dans mon while du main directement là plus rien.

c'est seulement quand je réceptionne en rx que mon tx envoie une valeur

    while (1)
    {
        
         
    EUSART_Write(175);
    
    tempo=500;
    while(tempo){  
    tempo--;}
    
    i=EUSART_Read(); 

        
    }
}

Dans ce cas, je réceptionne bien une valeur et après j'envoi une autre valeur.
Bon après mon code est plutôt grossier, mais c'est plutôt pour comprendre comment ça fonctionne.

Ha oui , j'utilise une application d'éval de 15jours d'essai lookrs232 qui correspond à ce que je cherchais, c'est à dire pouvoir lire et écrire sur bus rs232 et qui fonctionne plutôt bien, seulement c'est valable que 15jours, connaitriez-vous un petit soft gratuit qui fait la même choses que je sois pas limité dans le temps ?

Auriez_vous une explication ? merci de votre aide

[davidif]

avec

uint8_t EUSART_Read(void)
{

   RCSTAbits.SREN = 1;
    while(!PIR1bits.RCIF)
    {
    }

    
    if(1 == RCSTAbits.OERR)
    {
        // EUSART error - restart

        RCSTAbits.SPEN = 0; 
        RCSTAbits.SPEN = 1; 
    }

    return RCREG;
}

void EUSART_Write(uint8_t txData)
{
    while(0 == PIR1bits.TXIF)
    {
    }

    TXREG = txData;    // Write the data byte to the USART.
}

[David71120]

Pour le coté prog, je ne m'y connais pas assez pour t'aider, en ce qui concerne le soft, il y en a pas mal, le plus connu: hyperterminal, il y a aussi putty, realterm,termite, et mon préféré pour les choses simples, bcsp, téléchargeable au bas de cette page:
http://idmax.free.fr/Download/Download.html

[davidif]

Pour le coté prog, je ne m'y connais pas assez pour t'aider, en ce qui concerne le soft, il y en a pas mal, le plus connu: hyperterminal, il y a aussi putty, realterm,termite, et mon préféré pour les choses simples, bcsp, téléchargeable au bas de cette page:
http://idmax.free.fr/Download/Download.html

Merci David pour les infos

[jiherve]

Bonjour,
Un UART se gère plutôt par interruption mais si le µC n'a rien d'autre à faire que d'attendre l'arrivée d'un octet pourquoi pas!
https://atlas-scientific.com/_files/...ample-code.pdf
faire recherche avec PIC UART Interrupt.
JR

[davidif]

Bonjour,
Un UART se gère plutôt par interruption mais si le µC n'a rien d'autre à faire que d'attendre l'arrivée d'un octet pourquoi pas!
https://atlas-scientific.com/_files/...ample-code.pdf
faire recherche avec PIC UART Interrupt.
JR

Je comprend bien, seulement pourquoi quand je réceptionne un octet j'envoi seulement à ce moment là un autre octet alors que sauf erreur, je devrais envoyer constamment des valeurs puis réceptionner simultanément.

quand je ne prend pas en compte le rx et j'envoi constamment, ma trame est constamment en envoyé

    while (1)
    {
        
         
    EUSART_Write(175);
    
    tempo=500;
    while(tempo){  
    tempo--;}
    
         
    }
}

mais quand je met les deux (ecriture et lecture) je n'envoi plus constamment mais seulement lors d'une reception

while (1)
    {
        
         
    EUSART_Write(175);
    
    tempo=500;
    while(tempo){  
    tempo--;}
    
    i=EUSART_Read();
         
    }
}

[jiherve]

Re
Ben évidement puisque la routine de réception est bloquante !
que crois tu que ton µC fasse pendant :
while(!PIR1bits.RCIF)
eh bien il attend que PIR1bits.RCIF passe à un donc qu'il y ait réception d'un octet et ne fait strictement rien d'autre , ton processeur n'est pas une machine parallèle qui pourrait recevoir et émettre en même temps par l'action du saint esprit!
JR

[paulfjujo]

bonjour,


Au fait, c'est quoi la reference du MCU 16F ?

non bloquant, mais fiabilité douteuse !

  while (1)
    {
         
    EUSART_Write(175);
    if(PIR1bits.RCIF) 
    {
      if( RCSTAbits.OERR ==1)
      {
        // EUSART error - restart
        RCSTAbits.SPEN = 0; 
        RCSTAbits.SPEN = 1; 
      }
       if( RCSTAbits.FERR ==1)
      {
        i=RCREG;
      }
       i=RCREG;
    }
    // cette tempo peut occasionner des pertes de caracteres!
    tempo=500;
    while(tempo>0) tempo--;
  } // while

le fin mot de l'histoire : Usage de UART RX interruption !..

[davidif]

Effectivement, j'ai validé l'interruption et ça fonctionne.
Autant pour moi pour le code, mais c'est surtout pour voir fonctionner mon bus, maintenant que ça fonctionne dans les deux sens on va mieux architecturer tout ça

Encore merci pour l'aide

[davidif]

Par contre, maintenant que ça fonctionne dans les deux sens, comment pourrais-je identifier mes données ?
elles ne sont pas nombreuses, j'ai 3 informations à transmettre de parts et d'autres :

Information de puissance 1 dont la valeur varie de 0 à 100
puissance 2 dont la valeur varie de 0 à 100 également
tempo dont la valeur varie de 0 à 60

Donc la valeur max tien sur 2 octets , l'idée serait d'y inclure un identifiant en poids fort seulement ça ne tiendrait pas sur 2 octets si je dis pas de bêtises (ce qui est certainement le cas (: )

peut-être envoyer plusieurs octets pour une seul valeur, lequel aura sont identifiant en poids fort, c'est comme ça que ça fonctionne ?

[jiherve]

Bonsoir
utilises 3 octets , en général tel qui veut faire des économies de bout de chandelle y laisse sa flanelle , vu tes valeurs en effet avec un codage du type :
0 ... 100 => 0 ... 0x64
0..60 => 0x80 ... 0xBC
Tu repéreras l'un des octets à coup sur.
JR

[davidif]

Bonsoir
utilises 3 octets , en général tel qui veut faire des économies de bout de chandelle y laisse sa flanelle , vu tes valeurs en effet avec un codage du type :
0 ... 100 => 0 ... 0x64
0..60 => 0x80 ... 0xBC
Tu repéreras l'un des octets à coup sur.
JR

Merci pour cette solution, si j'ai bien compris ont prend une plage entre 00 et FF que l'on attribut aux différentes valeurs, c'est intéressant.
Par contre, j'ai oublié une autre valeur à transférer autant pour moi, au total j'en ai 4

Information de puissance 1 dont la valeur varie de 0 à 100
puissance 2 dont la valeur varie de 0 à 100 également
tempo dont la valeur varie de 0 à 60

puis une autre info binaire de sécurité 1 ou 0

0 -- 64 65 -- C9 CA -- 106 107

100(1) 100(2) 60 sécurité

Comme ceci, si j'ai bien comprix

[jiherve]

Re
une solution:
0..100(1) => 0x00 .. 0x64
0..100(2) => 0x00 .. 0x64
0..60+sécurité => 0x80/0x81 .. 0xF8/0xF9 la valeur envoyée est 128 + 2xtempo + sécurité, le nombre est pair ou impair suivant l’état de ton bit de sécurité mais toujours "négatif" (MSB à 1) pour servir de drapeau de trame,c'est très facile à décoder.
JR

[davidif]

Bonjour,

Après une petite pose ou j'ai du passé à une autre fonction (pas résolu d'ailleurs ( je reviens vers la com RS232, et juste pour comprendre car sur le net on nous montre la trame composé d'un bit de start, des bites de donné(8 ou 9) et un ou deux bites de stop.

Seulement, au vue du nombres de bites de données, en règle général comment ce fait le transfert de données, notamment quand il y a plusieurs données comment les identifier sur une trame RS232, car si je souhaite transferer plus de données j'aimerai comprendre pour peut-être faire la même chose.

Une données peuvent-être comprises dans plusieurs trames ?, dans ce cas là il faudrait je suppose différentier les temps entre trames, c'est à dire, par exemple, si le temps entre trame est inférieur à une certaine valeur c'est la même données sinon c'est une autre données, je sais pas si je suis claire (:

Merci pour vos éclaircissement