Discussion :

[cfalcot]

Bonjour,

Alors je travail sur une application qui écoute 6 ports RS. Rien n'empèche les six ports de communiquer simultanement (meme si la probabilitée est faible...).

Est il preferable d'écouter les six ports dans 6 threads differant ou ca ne sert a rien? L'application a fonctionnée avec un seul thread pendant 4ans et la je doit la refaire. Qu'est ce qui est le plus stable?

Merci.

[Philippe Gormand]

Bonjour.

Il y a un dicton qui dit : "On ne change pas une équipe qui gagne".

Ton application a fonctionnée pendant 4 ans. Donc je suppose qu'elle
est stable. A moin d'avoir remarqué certains problèmes de stabilité, je
ne ne vois pas l'interret de la compliquer ou d'augmenter la taille du
code.
De plus, en augmentant le nombre de Threads, tu risques d'avoir des
problèmes de synchronisation. Mais il existe un objet ataché aux Thread
pour les synchroniser. J'ai eu à m'en servire, mais c'était dans le cas de
4 Thread qui devaient accéder au même port de communication.

A+

[cfalcot]

Bonjour,

Ben en fait si on retravail dessus c'est qu'il y avait des petits soucis quand meme, genre des extinctions inopinées du soft... sans jamais trouver d'explication satisfaisante.

A priori, je n'ai pas de problèmes de syncronisation car je reception et j'affiche les données de 6 capteurs independants.

Avec ces nouvelles données, qu'en pense tu?
(Je joue avec les thread un peu comme un gosse qui à decouvert un nouveau jouet... Du coup je demande des avis avant de faire des conneries)

[Philippe Gormand]

Bon !

Cela fait pas mal de temps que je n'ai pas joué avec les Thread.

L'expérience que j'en ai, c'est que si il semble assez facile à les utiliser,
ce sont des objet très délicat à gérer. Apperemment tu ne connais pas
l'origine du plantage du programme. Donc tu ferais mieux d'en chercher
l'origine (et de la trouver) avant de modifier le code sans savoir si cela
va arranger les choses.

Le conseil que je peux te donner, est de retourner dans l'aide de DELPHI
sur le sujet. Tu peux aussi compulser les tutoriaux. Qui sait, par la lecture
tu trouveras sans doute l'origine du problème. Mais ne connaissant pas
ton programme je peux pas te conseiller mieux.

Salut.

[Graffito]

Bonjour,

Meme si on gères les ports RS232 par polling (ce qui est une solution qui convient parfaitement au débit des ports série), pas besoin de plus d'un thread. Si c'est géré par events idem, je conseillerai de faire quand même du polling à intervalles long (1 ou 2 secondes) pour récupérer des caractères qui auraient pu ne pas avoir été traités.

[Graffito]

Bonjour,

Une petite précision en relisant la question initiale :

En général, les UART des chips qui gèrent les RS232 ont un buffer de plusieurs caractères .
Si je me rappelle bien dans les année 80 les chips standard avaient un buffer de 6 caractères en réception, maintenant il semble que ce soit 15/16.

Entre les UART et le processeur du PC, il y a parfois des cartes intelligentes avec des buffers de plusieurs centaines d'octet et/ou une gestion par interruption dans les drivers Windows qui bufferisent aussi qq centaines d'octets dans la RAM du PC.

Donc, pas de raison de s'inquiéter du fait qu'on ait un seul thread, sauf cas improbable où on ait des connexions directes sur les chips RS232 sans gestion d'interrupt.