Discussion :

[alyma]

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

[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

[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?

[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

[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 ?

[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:

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

Oui tout à fait

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