Discussion :

[kramer]

Bonjour,

Je dois poller pour des lectures un port de communication dans un thread s�par�. Dans la fonction Execute() du thread, si je me contente de lire byte par byte le flux entrant, �a marche correctement.
En revanche, si je fais un test pr�liminaire pour savoir si des donn�es sont disponibles sur le port - comme le bon sens m'y invite - �a marche aussi mais le CPU est � 100%.

Voici un extrait du code:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
 
void __fastcall USB_RX_THREAD::Execute()
{
DWORD BytesReturned, BytesSent, EventWord;
while (!Terminated) {
        FT_GetStatus(ftHandle, &BytesReceived, &BytesSent, &EventWord);
        //if (BytesReceived) {
                FT_Read(ftHandle, &RxData, 1, &BytesReturned);
                Synchronize(ProcessRxData);
        //}
 
}

Dans le code ci-dessus, le test pr�liminaire est mis en commentaires.
Il y a sans doute qqch qui cloche dans mon code... Une id�e? Merci!

[chasse18]

ton code doit pas compiler il manque }
sinon tu viens de cr�er un deamon il va tout le temps faire le test de ta connexion.

[cfdev]

lut,
Ton code me dis quelque chose
j'avais le m�me pour dialoguer avec le FDTI232BM
seul pb, c'est que j'ai fait exactement la meme chose que toi et pareil 100% pross meme dans un thread!
Obliger de faire ca avec un Timer.
Si jamais tu trouves la soluce ce serai sympa de la patager.



Bon courage.
++

[kramer]

Salut VirtuA,

Bien vu, ce sont des fonctions de l'API FTDI
J'ai provisoirement r�gl� le probl�me en ins�rant un Sleep() dans la boucle. Il y a eu un post ici-m�me � ce sujet:
http://www.developpez.net/forums/vie...1b34625eca5fa7
Le code est � pr�sent

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
 
while (!Terminated) {
        FT_GetStatus(ftHandle, &BytesReceived, &BytesSent, &EventWord);
        if (BytesReceived) {
                FT_Read(ftHandle, &RxData, 1, &BytesReturned);
                Synchronize(ProcessRxData);
        }
        else
                Sleep(5);
}

Evidemment cette m�thode suppose que tu as une id�e du d�bit sur la ligne. Pour ma part je sais que je re�ois 200 bytes de statuts par seconde que je dois traiter au plus vite, d'o� les 5 ms pour le sleep. Je ne suis pas amoureux de cette solution mais bon �a marche - et sous Windows je m'habitue � ne pas trop en demander.
D'ailleurs je manque d'infos sur le traitement multi-t�ches de Windows. J'ai une doc qui annonce que Windows accorde 20ms d'ex�cution � chaque process. Si le process est multi-threads, ces 20ms sont partag�es entre les threads. Dans quelle mesure? Enfin pour ma part j'ai test� les �v�nements signal�s par la souris, et je mesure pr�cis�ment 1 �v�nement souris par 10ms. Quelqu'un a-t-il des infos plus pr�cises sur le cadencement sous Windows?

[ChMerlier]

Bonjour,

La lib�ration de la charge CPU vient de la fonction Synchronize.

Quand tu enl�ves les commentaires, tu passes tout le temps dans le Synchronize.
Dans le cas contraire, tu boucles jusqu'a valider la condition, donc tu prends 100% de CPU.

Soit tu ajoutes une pause (effectivement ici le Sleep(1)), soit essaye d'appeler Synchronize ou Application->ProcessMessages().

Attention toutefois au temps de pooling.
Dans les 2 cas c'est assez incertain.

Le Sleep est fonction du quantum de windows ( 1ms = 10ms )
Application->ProcessMessages/Synchronize d�pend du traitement effectu� ...

[kramer]

Merci! Je commence � comprendre l'esprit je crois. Tant qu'il n'a pas ex�cut� un Synchronise(), le thread reste actif.
Je devrais pouvoir �crire (?) � la place du sleep():

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
 
while (!Terminated) { 
        FT_GetStatus(ftHandle, &BytesReceived, &BytesSent, &EventWord); 
        if (BytesReceived) { 
                FT_Read(ftHandle, &RxData, 1, &BytesReturned); 
                Synchronize(ProcessRxData); 
        } 
        else 
                Synchronize(ReturnToMain);
}

o� la fonction ReturnToMain() ne serait que l'instruction return() ou une fonction vide.

[ChMerlier]

Dans l'absolue oui.
Je vois que tu fais une pause de 5ms.
Le quantum au Ring3 (niveau utilisateur est �gal � 10ms.
Donc entre 1 et 10ms, la pause effective est de 10ms, entre 11 et 20ms, la pause effective est de 20ms, etc ...

Le probl�me du Synchronize est que le temps laiss� au CPU n'est pas en soit mesurable.
Si tu bouges la souris comme un fous, tu vas capter le processeur et donc augmenter le temps de traitement (ceci est un exemple bien �videment).

Normalement la captation au niveau binaire (ou caract�re) doit se faire dans un driver. Seul le "completion code" est laiss� � un thread de plus haut niveau. (ceci est valable pour le pooling).

Une autre solution est de voir s'il est possible de se mettre en attente d'un �v�nement (event) ou signal. Ainsi le Thread se met en attente d'information, lorsque celle ci est disponible l'evenement est d�clench� (ou le signal signal� ) et le thread se d�bloque pour traiter les datas.

Exemple de code sur demande. Il faut bien sur que le syst�me puisse supporter ces modes de fonctionnement.

[kramer]

Mischt! J'ai essay� le coup du ReturnToMain() vide, et la charge CPU est � 100%. Je ne comprends d�cid�ment pas la logique du thread: quand (� quelle condition) passe-t-il la main?
Merci pour la suggestion du thread d�clench� par l'�v�nement, mais je ne vois pas comment faire � priori. Aurais-tu un exemple simple montrant comment cette technique est mise en oeuvre?

[DjmSoftware]

bonjour,
pour eviter ce probl�me de polling il faut utiliser les notification les API de
FTDI les proposent

un exemple de code

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
// demande de notification a placer dans le constructeur du Thread par exemple
 
FT_HANDLE ftHandle; // handle of an open deviceFT_STATUS ftStatus;
HANDLE hEvent;
DWORD EventMask;
hEvent = CreateEvent( NULL, false, // auto-reset event false, // non-signalled state “” );
EventMask = FT_EVENT_RXCHAR | FT_EVENT_MODEM_STATUS;
ftStatus = FT_SetEventNotification(ftHandle,EventMask,hEvent);
 
/////////////////////////////////////////////////////////////////////////////
// code Execute de ta classe TThread
while (!Terminated) { 
 
WaitForSingleObject(hEvent,INFINITE);
DWORD EventDWord;
DWORD RxBytes;
DWORD TxBytes;
FT_GetStatus(ftHandle,&RxBytes,&TxBytes,&EventDWord);
if (RxBytes > 0) 
 { // call FT_Read() to get received data from device }
FT_Read(ftHandle, &RxData, 1, &BytesReturned); 
 Synchronize(ProcessRxData); 
 }
}

de cette mani�re ton thread ne consomme uniquement du temps processeur lors du traitement de l'information
cordialement

[kramer]

Ca c'est fort!
Merci DjmSoftware!

J'ai test� - avec un certain retard - la m�thode qui bloque le thread dans l'attente d'un �v�nement. Ca fonctionne, mais le PC n'arrive pas � suivre la cadence impos�e par le flux en r�ception - la m�thode ne semble pas adapt�e au 'temps r�el' (je lis et traite chaque byte � mesure qu'il est dispo).
A noter que la m�thode pr�c�dente par polling des status et attente (sleep) ne rencontre aucun probl�me de cadence.

[DjmSoftware]

bonjour,
c'est un fonctionnement parfaitement normal
en effet lors que l'Event est signal� dans le code on ne contr�le pas le nombre de caract�res qui se trouve dans le Buffer (param�tre RxBytes)

si par exemple 15 caract�res sont d�pos�s dans le Buffer, et que l'on lise uniquement 1 caract�res � la fois, la prochaine notification aura lieu lorsque le 16 em caract�re sera d�pos� dans le buffer
--> perte de 14 �l�ments

en faisant un polling on force la lecture du buffer chaque fois que le thread est activ� par l'OS

le solution conciste en la lecture de (RxBytes* �l�ments) en lieu et place d'un �l�ment � la fois

d'autre part dans le code on peut supprimer FT_EVENT_MODEM_STATUS de l'EventMask

Cordialement

[kramer]

Merci pour ces pr�cisions et encore merci pour ton intervention.