[WD19] overhead de latence dans lecture et traitement port série

Bonjour

Je suis en train de faire une application qui s'interface avec un équipement via un antique port série RS232.

L'émetteur envoie des messages binaires ayant un header et une payload.

La contrainte que je rencontre est que le PC doit répondre à l'émetteur en respectant des timeout assez contraints en envoyant deux types de messages :
- un ACK qu'on doit envoyer avant 200 ms après validation du Checksum du message
- un ACCEPT qu'on doit envoyer avant 600 ms après validation de la payload

J'utilise la gestion des événements série sur détection d'un caractère présent et la communication se fait à 9600 bauds.

Visiblement, mon PC ne réponds pas à l'émetteur dans les 200ms prévues et parfois visiblement non plus dans les 600ms, ce qui génère des retransmissions puis une coupure de la communication de la part de l'émetteur.

Remarque : je fais l'exécution soit en mode debug soit en lançant le programme généré, et j'ai des comportements un peu différents.

Question : avant que je ne regarde ailleurs ou que je ne cherche des causes physiques (câble, etc ...), est-ce que Windev pourrait être en cause. Je ne connais bien les performances de Windev dans ces cas contraints ... et je crains que le framework ne génère un overhead de traitement et soit la cause de la latence.

Quel est votre avis ?

[EDIT] j'ai oublié de préciser que la RS232 n'est pas reçue sur un port COM habituel (on n'en trouve plus surtout sur les PC portables), mais via un convertisseur RS232-USB basé sur le chipset PROLIFIC et intégré dans un cable PLUGABLE. Ceci pourrait être également la cause de la latence ....

Bonjour

Petit retour d'expérience pour la gestion des ports série avec Windev :

- l'utilisation d'événement engendre de temps en temps des problèmes de latence surtout si on utilise des
timer/thread dans de le même programme
- dans le cas de latence faible, le mieux est d'utiliser un timer pour scanner le buffer
du port série


Pour les adaptateurs USB/Série, il y a des paramètres dans le driver à vérifier :
(je n'utilise que des adaptateurs avec des puces FDTI, mais il devrait y a voir la même chose chez les concurrents)

- vérifier la taille du buffer d'entrée de la puce, l'adaptateur n'envoie les données que par paquet, il faut donc que la taille du
buffer soit supérieur a la taille maximale d'un message
- vérifier le temps de latence d'émission du buffer quand des données sont reçues

Rappel : principe de fonctionnement de la plupart des adaptateurs
réception de données sur port série -> mise en attente dans un buffer -> envoie soit sur buffer plein ou temps d'attente max

Bon dev.

Merci pour la réponse rapide.

Entre temps, je suis passé sur un vrai port série sans adaptateur .... et cela améliore les choses mais cela n'est pas encore le top. Certains messages sont ré émis de temps en temps par le périphérique car visiblement l'acquittement ne lui parvient pas encore à temps.

Citation:

---

Envoyé par cmt44

Bonjour

Petit retour d'expérience pour la gestion des ports série avec Windev :

- l'utilisation d'événement engendre de temps en temps des problèmes de latence surtout si on utilise des
timer/thread dans de le même programme
- dans le cas de latence faible, le mieux est d'utiliser un timer pour scanner le buffer
du port série

---

Le souci dans mon cas, c'est que l'acquittement doit arriver avant 200 ms au périphérique.... le timer risque de ne pas être assez rapide.

J'utilise le système d'interruption sur caractère détecté, mais il me faudrait aussi donner une priorité très haute à cette interruption : est ce que c'est possible dans Windev ?

Ou alors lancer un thread dans l'interruption, dont on peut régler la priorité : est ce une bonne idée ?

Citation:

---

Pour les adaptateurs USB/Série, il y a des paramètres dans le driver à vérifier :
(je n'utilise que des adaptateurs avec des puces FDTI, mais il devrait y a voir la même chose chez les concurrents)

- vérifier la taille du buffer d'entrée de la puce, l'adaptateur n'envoie les données que par paquet, il faut donc que la taille du
buffer soit supérieur a la taille maximale d'un message
- vérifier le temps de latence d'émission du buffer quand des données sont reçues

---

J'utilise un cable de la marque Plugable avec une puce Prolific (PL-2303HXD): j'envisage d'utiliser un cable FTDI pour voir -> aurais tu une bonne référence à me recommander ?

Comment peut-on vérifier la taille du buffer et la latence du chip : avec la doc ou via une application ? Via le gestionnaire de périphériques de Windows, on peut changer des paramètres de buffer dans le menu Avancé -> est cela ?

Citation:

---

Rappel : principe de fonctionnement de la plupart des adaptateurs
réception de données sur port série -> mise en attente dans un buffer -> envoie soit sur buffer plein ou temps d'attente max

Bon dev.

---

Bonjour,

petites questions concernant le problème :

1 - Quelle est la taille des messages ( en octets) ?
2 - Le messages est-il constitué d'un header d'un payload et d'un checksum ?
3 - Le Ack et le Accept ont quelles tailles ?
4 - Ne peut-on pas augmenter la vitesse de transmission ?
5 - Pas de handshake hard (rts/cts) non plus ou soft (xon xoff)?
6 - Ne peux-tu pas mettre un oscilloscope ou un analyseur logique ou série pour voir le timing ?

bon ved.

Citation:

---

Envoyé par Nullosse

Bonjour,

petites questions concernant le problème :

1 - Quelle est la taille des messages ( en octets) ?

---

Variable de 20 a 1026 octets

Citation:

---

2 - Le messages est-il constitué d'un header d'un payload et d'un checksum ?

---

Message = header de 10 octets (mot dle soh+message id+word count+flags+checksum) + data payload de 0 a 1016 octets (avec checksum si taille non nulle)

Citation:

---

3 - Le Ack et le Accept ont quelles tailles ?

---

10 octets = message avec header seul (flags identifient le type ack ou accept)

Citation:

---

4 - Ne peut-on pas augmenter la vitesse de transmission ?

---

Non 9600 bauds

Citation:

---

5 - Pas de handshake hard (rts/cts) non plus ou soft (xon xoff)?

---

Non RS 232 sur 3 fils

Citation:

---

6 - Ne peux-tu pas mettre un oscilloscope ou un analyseur logique ou série pour voir le timing ?

---

Pas pour le moment .... Mais idée à creuser

Citation:

---

bon ved

.

---

hello,

regarde ici pour voir la façon de régler le latency timer de ton port série (si c'est possible).
sinon pour un ftdi on peut le faire aussi par la base de registre.

Ami calmant, J.P

Bonjour

Je n'utilise pas d'adaptateur précis, je développe directement les cartes électroniques avec des puces FDTI embarquées, donc
pas de référence précise à te proposer. Mais la plupart des adaptateurs du marché à base de ces puces utilise le driver générique de FDTI.
Pour accéder aux paramètres du driver :
panneau de configuration -> clic droit propriété sur le port com -> onglet paramètre du port -> bouton avancé

Pièce jointe 161017

Latence : régler au plus faible
Délais : mettre 0 en lecture et écriture
Longueur trame : 2048 (>1026o tout en restant une valeur standard)
Ne pas cocher enable selective suspend (la sortie de veille étant longue)

Pour la vitesse de windev, je n'ai pas eut de gros problème à récupérer des données sur le port série même avec des temps de réponse
court, ce qui ralenti le plus souvent c'est les traitements à effectuer sur les trames reçues. Avec l'analyseur de performance de windev ou en
traçant le code du devrait trouver ce qui consomme trop de temps.

Merci pour l'information.

Pour l'instant j'utilise des cables à base de chip PROLIFIC, car à terme, je dois connecter mon périphérique à un smartphone, et j'ai déjà validé le driver Android de PROLIFIC.

Je vais acheter des cables à base de FTDI pour voir et tester le driver ANDROID de PROLIFIC.