Synchronisation de deux ports série

Version imprimable

08/07/2013, 14h48
alyma

Synchronisation de deux ports série

Bonjour,

Je cherche à débugger une communication entre deux dispositifs. On considère que les deux dispositifs dialoguent en liaison RX/TX.
Je me suis arrangée pour pouvoir récupérer le RX et le TX sous deux ports série au niveau du PC. Imaginons pas exemple sur le port 10 la liaison RX et sur le port 11 la liaison TX. Jusque là aucun soucis.

Ensuite afin de visualiser les échanges, je mets en place une interface via les MFC, qui affiche ce qui est reçu sur les ports. Pour cela, je dispose d'une classe fonctionnelle qui gère les ports série, et j'utilise deux threads : un pour chaque port série. Chaque thread a pour objectif de recevoir des données sur le port série et d'envoyer un message à la fenêtre pour les afficher dans une console.
Ainsi sur la console (editbox) j'affiche par exemple:
RX 0x32 0x10 0x00
TX 0x41
RX 0x12
TX 0x44 0x10

Or, j'ai un problème de synchronisation: les données et RX et TX ne se chevauchent pas correctement.
Par exemple au lieu d'avoir:
TX : 0x12 (commande 1)
RX : 0x34 (réponse 1)
j'ai :
TX : 0x12 (commande 1)
RX : 0x06 (reponse -1)
TX : 0x04 (commande 2)
RX : 0x34 (réponse 1)

Quel pourrait être le problème?
Est ce qu'il faut que les deux threads soient vraiment lancés au même instant?
Est ce un problème de queue de messages?
Y aurait-il d'autres façons de faire que d'utiliser deux threads?
Merci d'avance
08/07/2013, 15h57
deletme

Salut,

Quel est le rôle de la commande que tu envoies ? Interroges-tu des registres dans ton dispositif ? (quel est ce dispositif ?) Cela pourrait expliquer ce comportement.

Cdlt, deletMe
08/07/2013, 16h37
alyma

Le dispositif est une carte électronique réalisée par nos soins. Il n'y pas de problème de ce côté là : à l'oscilloscope les données sont bien synchronisées.

Je vais peut être essayer de non pas scruter en permanence les ports mais plutôt de les gérer par interruption (avec un wait sur event pluôt qu'un ReadFile()). Ce sera peut être mieux?
08/07/2013, 18h02
pfeuh

Salut,

Tu dis que tes données sont synchronisées, est-ce cela signifie qu'elle ne se superposent jamais? Que c'est du half duplex? Dans ce cas une solution utilisée de temps en temps est de mélanger les deux tx sur le même signal, un peu à la manière d'une RS422. Attention, avec bien sûr les contraintes hardware qui vont bien, transistors à collecteur ouvert, pullup, tout ça. Je bosse dans l'embarqué et c'est cette techno qui est toujours utilisée, donc c'est transparent pour moi... Ce n'est pas le cas avec une véritable RS232, d'où nécessité de passer par un petit peu de hardware. Je précise que je n'ai aucune connaissance dans ce domaine, ne faisant plus que du soft depuis des années. Ainsi tu n'a plus qu'un seul récepteur sur ton visualisateur, donc plus aucun problème de synchro. Tu ne sauras plus qui a envoyé quoi, mais tes données seront ordonnées.

Bonne continuation,

Pfeuh
08/07/2013, 18h40
Bktero

En lisant naïvement le sujet, n'est-ce pas un simple problème d'affichage lié au multi-threading ? Tu dis que les trames sont correctement synchronisées en les regardant à l'oscilloscope, donc il semble logique que le problème viennent du programme PC d'affichage.

Tu as un thread par port COM, donc un qui affiche les RX et l'autre les TX ?

Comment un thread sait-il que c'est son tour d'afficher une trame dans la console ?
09/07/2013, 09h29
alyma

Merci pour vos réponses

@pfeuh : ça pourrait être une solution en effet mais ça m'embête un peu, la distinction RX/TX ne serait alors plus visible.

@Bktero:

Citation:

Tu as un thread par port COM, donc un qui affiche les RX et l'autre les TX ?

Oui tout à fait

Citation:

Comment un thread sait-il que c'est son tour d'afficher une trame dans la console ?

Voilà, tu as mis en évidence le problème. Je ne sais pas comment opérer pour le savoir. En fait, nous ne savons pas combien de temps est accordé pour chaque thread. Il faudrait avoir un horodadage lors de la réception des données pour pouvoir les afficher dans l'ordre dans la console.
Je ne vois pas de solution :cry:

Ce n'est donc qu'une question d'affichage. Il faut donc mettre en place un mécanisme pour indiquer qui doit écrire maintenant. Tu peux faire un truc moche dans ce genre avec une variable globale :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
 
#include "pthread.h"
 
volatile char who = 'r';
 
void* print_rx_frames(void* pParameters)
{
    puts("THREAD FOR RX");
 
    for(int i = 0; i < 0xF; i++)
    {
        while(who != 'r')
        {}
        printf("Receive %d...\n", i);
        who = 't';
    }
    return pParameters;
}
 
void* print_tx_frames(void* pParameters)
{
    puts("THREAD FOR TX");
 
    for(int i = 0; i < 0xF; i++)
    {
        while(who != 't')
        {}
        printf("Send %d...\n", i);
        who = 'r';
    }
    return pParameters;
}
 
int main()
{
 
    pthread_t thread_rx;
    pthread_t thread_tx;
 
    puts("Try to create a thread...");
 
    int rx_created = pthread_create(&thread_rx, NULL, print_rx_frames, NULL);
    int tx_created = pthread_create(&thread_tx, NULL, print_tx_frames, NULL);
 
    if(rx_created == 0 && tx_created == 0)
    {
        pthread_join(thread_rx, NULL);
        pthread_join(thread_tx, NULL);
        printf("Thread RX (%d) and thread TX (%d) terminated\n", thread_rx, thread_tx);
    }
    else
    {
        printf("Error while one thread\n");
    }
    return 0;
}

Je pars ici du principe qu'une trame TX sera toujours suivie d'une trame RX.

Si ton application a besoin de robustesse ou si tu ne veux pas pomper du CPU à mort, il te faudra regarder du côté des sémaphores. On pourrait imaginer un mécanisme ou le thread qui termine son écriture émet un sémaphore à destination de celui dont ça va être le tour d'écrire.

09/07/2013, 18h57
mith06

pthread_mutex_t est ton ami!

http://linux.die.net/man/3/pthread_mutex_trylock

Je pensais plutôt à un sémaphore (je viens d'apprendre comment marche les sémaphores pthread à l'instant, il y a peut-être coquille) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
 
#include "pthread.h"
#include "semaphore.h"
 
sem_t psem_for_rx;
sem_t psem_for_tx;
 
void* print_rx_frames(void* pParameters)
{
    puts("THREAD FOR RX");
 
    for(int i = 0; i < 0xF; i++)
    {
        // Wait until it is our turn to write
        sem_wait(&psem_for_rx);
 
        // Write our RX frame
        printf("Receive %d...\n", i);
 
        // Let TX thread know that it can write
        sem_post(&psem_for_tx);
 
    }
    return pParameters;
}
 
void* print_tx_frames(void* pParameters)
{
    puts("THREAD FOR TX");
 
    for(int i = 0; i < 0xF; i++)
    {
        // Wait until it is our turn to write
        sem_wait(&psem_for_tx);
 
        // Write our TX frame
        printf("Send %d...\n", i);
 
        // Let RX thread d know that it can write
        sem_post(&psem_for_rx);
 
    }
    return pParameters;
}
 
int main()
{
 
    pthread_t thread_rx;
    pthread_t thread_tx;
 
    puts("Try to create a thread...");
 
    sem_init(&psem_for_tx, 0, 1);
    sem_init(&psem_for_rx, 0, 0);
 
    int rx_created = pthread_create(&thread_rx, NULL, print_rx_frames, NULL);
    int tx_created = pthread_create(&thread_tx, NULL, print_tx_frames, NULL);
 
    if(rx_created == 0 && tx_created == 0)
    {
        pthread_join(thread_rx, NULL);
        pthread_join(thread_tx, NULL);
        printf("Thread RX (%d) and thread TX (%d) terminated\n", thread_rx, thread_tx);
    }
    else
    {
        printf("Error while one thread\n");
    }
    return 0;
}

Il s'agit plutôt pour moi d'un jeton à donner au bon moment puisqu'il y a une notion d'ordre (donc à un sémaphore bien qu'ici sa valeur ne dépasse jamais un) plutôt qu'un accès concurrent à une ressource partagée (et donc un mutex). Quoique la console en soit une... Comment comptes-tu procéder avec le mutex ? :) Je pense qu'au final on arrive à une solution équivalente.

10/07/2013, 09h40
alyma

Merci pour vos réponses.

@Bktero : Ce principe poserait problème car la réponse n'est pas de longueur fixe : parfois c'est un octet, parfois deux ...
Et je ne suis pas sûre que cela résolve le problème qui là en l'occurence est un problème de décalage : Comme les deux ports série ne sont pas ouverts exactement en meme temps, les buffers de réception ne se remplissent pas en même temps alors il y a un décalage. Le buffer RX aurait peut être déjà 20 octets et le buffer TX seulement 10 octets.
En fait, il faudrait connaître dans la liaison série quelle est le timestamp de réceptioni des données, pour pouvoir ainsi les classer correctement.
10/07/2013, 10h02
deletme

Citation:

Je pensais plutôt à un sémaphore (je viens d'apprendre comment marche les sémaphores pthread à l'instant, il y a peut-être coquille)

Un sémaphore et un mutex sont identiques si ce n'est qu'un mutex ne peut prendre que les valeurs 1 et 0.

@alyma, si j'ai bien compris tu as un dispositif qui répond uniquement à des commandes que tu lui envoies ? Pourquoi, dans ce cas la, ne pas mettre en œuvre un affichage sur interruption ? Lorsque le message est parti, génération d'une interruption -> affichage de ce qui a été émis et idem sur réception.
10/07/2013, 11h52
alyma

@deletme : Non, le PC n'envoie pas de commande sur les ports séries.
Le PC se contente de scruter 2 ports série. Un port série qui ucorrespond à un RX d'une liaison, et un port série qui correspond à son TX.
Le PC analyse les données qui circulent sur ces deux ports mais en aucun cas il n'envoie de commande.
Dès que le PC reçoit quelque chose il l'affichage soit en tant que RX soit en tant que TX, dans une editbox.

Le problème est que l'affichage n'est pas bons, les deux ports ne sont pas synchronisés, il y a un décalage dans les données.
10/07/2013, 12h48
pfeuh

le seul moyen que je vois est l'analyse de la trame en cours de réception. Tant qu'elle n'est pas finie, ton thread ne doit pas rendre le sémaphore. Si tu ne sais pas de combien d'octets est formée la trame, ça me semble sans solution.

A+

Pfeuh
10/07/2013, 14h16
mith06

A OK tu fais une renifleur!!

Je pense qu'il faut passer d'un système asynchrone (attente bloquante d'une lecture sur le port série) pour le transformer en un système synchrone lecture no bloquante dur le port série répétée périodiquement.
Si cette période est inférieure à la durée de transmission de 1 octet sur la ligne, tu pourra savoir le quel est arrivé en premier.
10/07/2013, 17h37
pfeuh

Citation:

Envoyé par mith06

Je pense qu'il faut passer d'un système asynchrone (attente bloquante d'une lecture sur le port série) pour le transformer en un système synchrone lecture no bloquante dur le port série répétée périodiquement.

Tout à fait. Un seul thread qui teste deux ports série alternativement. Il y avait donc une solution. :ccool:Avant de lire un octet, ce qui est une fonction bloquante, on regarde si un octet a été reçu et seulement dans ce cas on le lit. Sous Windows, il suffit d'appeler une fonction (dont je ne rappelle plus le nom) qui donne le nombre d'octets reçus non dépilés. S'il n'y a rien en attente, on teste le deuxième port, puis on revient au premier...

A+

Pfeuh
11/07/2013, 09h54
alyma

Merci de vos réponses
Je vais essayer