Discussion :

[petitcoucou31]

Bonjour,

Pour ceux qui ont vu mes derniers posts , je suis sur la communication RS232 en utilisant les fonctions de WinApi.
Cette communication permet un dialogue entre le port USB d'un PC et un µcontroleur sur une longueur < 10 cm, et doit être très rapide (essayer d'approcher le Mbips/s). Des précautions sur cette liaison filaire seront mises en place aussi (paires différentielles...).

A ce jour nous fonctionnons à 430800 baud, mais les durées entre deux émissions consécutives sont pour notre besoin très lentes, de tête environs 15 millisecondes, bien supérieures à la durée d'émission d'un octet.

Lors de la configuration de mon port com, j'ai un certain nombre de TimeOut.

Les valeurs indiquées sont la synthèse des exemples que j'ai vus, sans vraiment comprendre comment cela s'applique sur la communication.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
  with timeouts do
  begin
      ReadIntervalTimeout         := 0;
      ReadTotalTimeoutMultiplier  := 0;
      ReadTotalTimeoutConstant    := 1;
      WriteTotalTimeoutMultiplier := 0;
      WriteTotalTimeoutConstant   := 1;
  end;
  SetCommTimeouts(Ucom, timeouts)

Quelqu'un saurait-il me dire les valeurs des "TimeOut" pour avoir les durées les plus courtes entre deux envois avec l'utilisation du port de l'unité WinApi ?
Je me demande aussi si les valeurs '0' sont prises en compte ?

Des essais en python (avec ces fonctions et sur Windows), semblent bien fonctionner avec des durées justes inférieures à la mS entre deux envois.

merci pour vos aides.

[ShaiLeTroll]

As-tu vérifier si SetCommTimeouts retourne S_OK ($00000000) et dans la cas contraire vérifier GetLastError
Si tu as l'impression que cela n'est pas prise en compte, c'est une première piste à écarter.

Et effectuer un GetCommTimeouts avant et après pour voir les valeurs initiales et les valeurs altérées.

Tu as été déçu pour TComPort pour ne pas l'utiliser ?
Je ne l'ai pas utilisé pour du vrai COM mais du Bridge USB-COM, la connexion c'était un Convertisseur USB - RS232 + Cable COM + Concentrateur COM (produit maison) + cable RS232 sur un bornier RS485 sur une à 16 cartes electroniques (produit maison)
c'était le mode courant faible de certains équipements, les autres étaient en RJ45 (bien moins chiant)


https://learn.microsoft.com/fr-fr/wi...e-commtimeouts indique clairement

ReadIntervalTimeout : La valeur zéro indique que les délais d’expiration d’intervalle ne sont pas utilisés.
ReadIntervalTimeout : La valeur MAXDWORD soit $FFFFFFFF et Zéro dans ReadTotalTimeoutConstant et ReadTotalTimeoutMultiplier, pas de délai de lecture

WriteTotalTimeoutConstant, à 1 donc tu ajoutes un délai de 1 ms à WriteTotalTimeoutMultiplier * Nb Octet écrit


La valeur zéro pour les membres WriteTotalTimeoutMultiplier et WriteTotalTimeoutConstant indique que les délais d’attente totaux ne sont pas utilisés pour les opérations d’écriture.

Cela est-il synonyme de "écriture immédiate" ?

[petitcoucou31]

Bonjour

@ShaiLeTroll, non pas déçus du port TComport et TComDataPacket, que j'utilise par ailleurs. Mais je ne pouvais pas les utiliser (dans ce cas) car c'est dans une application non fenêtrée et cela me demandait un codage que je ne maitrise pas pour utiliser le TComport, donc je suis passé par WinApi.

As-tu vérifié si SetCommTimeouts retourne S_OK ($00000000) et dans le cas contraire vérifie GetLastError

<= non à contrôler .

En fait cette application ressemble a celle donc tu parles. la mienne est
PC => connexion USB => FTDI => RS232 => µControleur => RS485 ( trame maison).

Mes dernières mesures me montrent :
Que je n'ai pas de durée "non voulue" entre deux envois consécutifs, nous sommes dans la 100ene de µS
Que j'ai une durée constante de 7mS avant chaque "Readfile", qui elle est gênante pour atteindre les vitesses requises.

n'ayant pas trouvé d'informations sur les divers TimeOuts, tes explications vont m'être très précieuses, je vais creuser là-dedans, merci a toi.

Je vous tiens au courant...

[ShaiLeTroll]

Je ne sais plus si il faut ajouter une boucle de message pour le TComPort
Tu peux très bien faire une application VCL sans MainForm, faut juste ajouter sa propre boucle Run ... ou alors laisser une Form mais ne pas l'afficher.
Je fais des applications VCL qui lancée en ligne de commande s'accroche à la place sur le terminal (AttachConsole) et donc affiche tout en mode texte, on n'y voit que du feu !

Un Service gère aussi très bien cette boucle, le TComPort doit être dans un Thread séparé lancé au OnStart

Sans RAD, j'utilise toujours le TComPort sans RAD, tout simplement parce que je n'installe pas le BPL, ça ne sert à rien : TComPort sous CodeGear C++Borland 2007, instancié le TComPort à la volée, c'est très facile.

En fait cette application ressemble a celle donc tu parles. la mienne est
PC => connexion USB => FTDI => RS232 => µControleur => RS485 ( trame maison).

Le monde est petit mais du protocole COM de nos jours, on s'attend à ce genre de chaine

elle est gênante pour attendre les vitesses requises.

Je ne travaille plus dans le domaine depuis 10 ans, dommage, j'aimais bien, mais à l'époque, c'était plus de petits messages comme en TCP d'ailleurs, haute fréquence mais quantité faible, donc je n'ai jamais eu trop de soucis de performance.

Le timeout de lecture si je comprends bien, fait attendre le ReadFile, une fois le délai dépassé, si il n'y a pas d'autres données, cela termine l'opération.
Maintenant en terme de perf, faire des milliers de ReadFile pour lire à chaque fois quelques octets contre un seul ReadFile pour lire plusieurs milliers d'octets, on peut se dire que laisser un peu de temps à saturer le tampon pourrait améliorer les perfs à une époque où l'on parlait d'un début en bit/s ou kbit/s ... cela me semble colossale 1ms de délai alors que l'on parle de mbit/s ... à un tel débit, il n'y a peu de chance de devoir attendre aussi longtemps ... le problème est inverse, c'est lire assez vite pour éviter la saturation du tampon.