Discussion :

[Guillaume M]

Bonjour,

J'ai une tache en threading qui envoi des trames RS232 et une autre qui reçoit les réponses.
Lorsque j'envoie un trame, la commande m'est acquitté soit pas OK ou HS.
Cet acquittement me permet de changer l'état d'une variable globale et donc de continuer ma transmission.

Mon problème : c'est que je n'arrive pas a faire de pause a ma fonction d'envoi le temps que je reçoive l'acquittement. Une boucle while permettant de scruter toute les 0.5 s la variable me bloque tout mes ressources.

Merci d'avance

[josmiley]

je code surtout avec pygame donc une des caracteristique la plus interessante est de pouvoir creer et intercepter des evenements. J'en abuse car je trouve absurde de boucler sur une variable pour savoir si sa valeur a changée.
je ne connais pas les autres libs, mais il doit surement y en avoir une qui gere se genre de situation. Le thread qui reçoit les reponses doit pouvoir declancher un evenement attendu par un autre thread.

[wiztricks]

Bonsoir,

Si vous expédiez une trame puis attendez l'acquittement avant de traiter la suivante, mettre dans des threads séparées la réception et l'émission des trames me semble plus compliqué que le nécessaire.

Par contre, vous pouvez dire qu'avec RS232 si on ne lit pas les octets dès qu'ils sont là, le suivant écrase le courant et vous perdez des octets et des trames... Il parait donc sensé de lire et écrire les trames sur le port RS232 de façon asynchrone.

Mais cela suppose faire 3 threads:

Une comprenant des fonctions :

• emission : pose dans une queue la prochaine trame à émettre
• reception : récupère dans une autre queue la trame reçue

Queue au sens du module threading.

Les deux autres threads sont là pour:
- émission: on attend qu'il y ait une trame à émettre. On la sort de la queue, on l'expédie via la sortie RS232,
- réception : on attend le marqueur de début de trame, on lit la trame, on vérifie qu'elle est valide et on la dépose dans la queue de réception.

Dans ces conditions, vous découplez la gestion de l'état de la transmission de la transmission et de la réception tout en disposant de toutes les données nécessaire à cette gestion dans un même thread.
- W

[Guillaume M]

Bonsoir,
Une comprenant des fonctions :

• emission : pose dans une queue la prochaine trame à émettre
• reception : récupère dans une autre queue la trame reçue

Queue au sens du module threading.

Bonjour,

Je ne voit pas bien pourquoi ce thread là est nécessaire. Etant donné que l'un de mes threads me permet de remplir une queue (== list ?) et que mon IHM via des scripts me permet de remplir une autre queue qui est dépilé par mon deuxieme thread.

[josmiley]

je ne comprends par pourquoi il est necessaire d'avoir plusieurs threads. j'ai dans l'idée qu'on ne peut pas lire et en même temps ecrire sur un port; soit il ne se passe rien et on attends, soit on ecrit puis on atends confirmation de la reception, soit on reçoit puis on envoie une confirmation.
Guillaume M, pourrais-tu m'expliquer le protocole ?

[Guillaume M]

En faite, j'ai des trames sur la RS qui peuvent venir aléatoirement de mon système qui est en face.
Je ne peut pas me contenter d'envoi une trame et d'attendre l'acquittement de cette trames.

[josmiley]

désolé, pas comprendre.

Mon problème : c'est que je n'arrive pas a faire de pause a ma fonction d'envoi le temps que je reçoive l'acquittement. Une boucle while permettant de scruter toute les 0.5 s la variable me bloque tout mes ressources.

on est d'accord que tu n'envoies rien tant que la reception n'est pas finie.
pourquoi c'est pas le même thread qui s'occupe des envois/receptions ?

[wiztricks]

Bonjour,

Je ne voit pas bien pourquoi ce thread là est nécessaire. Etant donné que l'un de mes threads me permet de remplir une queue (== list ?) et que mon IHM via des scripts me permet de remplir une autre queue qui est dépilé par mon deuxieme thread.

Ce qui est asynchrone, c'est l'arrivée ou l'émission des trames.
C'est exactement ce que vous à proposé Josmiley dans la

Ces activités là dorment tant qu'il n'y a pas de trame à émettre ou des octets à lire qui seront ou pas de bonnes trames, reçue avant ou pas un timeout.

discussion

Mais cela ne fait que vider ou remplir des listes (qui mériteraient être des Queue) reste à écrire la logique qui attend l'acquittement avant d'expédier la trame suivante.

Soit vous mettez cela dans un même thread et vous n'avez pas de problème de variable globale, soit vous choisissez de séparer et faire remonter les acquittements 'à part'.

Il n'est à priori utile de séparer vous souhaiter utiliser cela pour échanger des trames dans les deux sens avec un piggyback des acquittements.
-W

[wiztricks]

on est d'accord que tu n'envoies rien tant que la reception n'est pas finie. pourquoi c'est pas le même thread qui s'occupe des envois/receptions ?

Effectivement, si ce n'est que pour faire du start/stop, inutile de multiplier les threads. Une seule suffit et comme l'émission et la réception des caractères est lente (RS232 c'est 19.6 Kdbs ou 2KB/s), ce thread ne fait rien sinon attendre réception ou timeout.

De plus même si on voulait faire du pipelining (envoi de plusieurs trames sans attente de l'acquittement) ce serait largement suffisant.
Ce qu'il peut être nécessaire de découpler c'est l'expédition et la réception des octets sur la ligne.
- W