Discussion :

[homeostasie]

Bonjour,

Pour d�finir le contexte, j'utilise la classe CCom de Farscape pour r�cup�rer des donn�es en mode asynchrone sur la liaison s�rie. Je lance le thread de r�ception � partir d'une classe d�riv�e de CDialog. Lorsque le thread d�tecte l'�v�nement EV_RXCHAR, il envoie un message WM_CCOMRCV vers ma classe parent d�riv�e de CDialog. L'arriv�e de ce message d�clenche la fonction suivante:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
long CComTLS::ON_WM_CCOMRCV(WPARAM wparam,LPARAM lparam)
{
	char sz[4096+1] = {0};
 
	m_comDll.ReadBuffer(sz,sizeof(sz)-1);
	m_sRx += sz;
 
	m_nTotalOctetLus += m_comDll.GetCountRead();	
 
	return 0L;
}

Ainsi, je viens lire et stocker les donn�es dans le buffer de r�ception � chaque �mission du message WM_CCOMRCV.

Je g�re un time out de r�ception grace au code suivant: (Ce code fait partie d'une fonction appell�e par un autre thread de travail qui attend de r�ceptionner toutes les donn�es �mises).

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
if(ret)
{
	bool bEndWhile = false;
	UINT OctetLus = 0;
	while(!bEndWhile)
	{
		OctetLus = m_nTotalOctetLus;
		Sleep(2000);
		if( OctetLus == m_nTotalOctetLus )
		{
			bEndWhile = true;
		}
	}
	m_sMNV = m_sRx;
}

Mon probl�me:
Ce code fonctionne depuis un moment. Mais bizarrement, je perds des donn�es depuis peu...
J'utilise ce m�me code dans une version ant�rieure du logiciel que je d�veloppe et j'obtenais ceci:

01 54 00 00 01 00 01 01 01 D8 0810 00000028 00 EF 4C TOTO
01 42 00 00 01 00 01 03 01 00 0800 000000B6 61 EF 4C TATA
01 54 00 01 01 00 01 01 01 C9 0810 00000028 00 EF 4C TOTO
01 42 00 01 01 00 01 03 01 00 0800 000000B6 61 EF 4C TATA

Maintenant j'obtiens cela:

01 54 00 00 01 00 01 01 01 D8 0810 00000028 00 EF 4C TOTO0 01 00 01 03 01 00 0800 000000B6 61 EF 4C TATA 01 54 00 01 01 00 01 01 01 C9 0810 00000028 00 EF 4C TOTO01 42 00 01 01 00 01 03 01 00 0800 000000B6 61 EF 4C TATA

Il me manque donc de temps en temps des caract�res (ici le saut de fin de ligne, mais aussi des donn�es)...

Quelles pourraient �tre les causes de pertes de donn�es? et quelles pourraient �tre les raisons pour que d'un c�t� (version ant�rieur du logiciel) ca fonctionne et de l'autre (version actuelle) non?

Il y aurait il une histoire d'augmenter la priorit� d'un thread?

Si vous avez des id�es, merci d'avance.

Nicolas

[farscape]

salut,
pour les pb de perte de caract�res il faut d�j� �tre s�r du reste:
- vitesse adapt�e � la longueur du cable et cable blind� et environnement sain.
- gestion de flux mat�riel rts/cts (pr�f�rable). -> cable correct.
- buffer de r�ception adapt�.

si tu as un gestion de flux correct tu ne dois pas perdre de caract�res ou alors tu as un chipset vraiment mauvais (ce qui n'est plus le cas depuis des ann�es sur les pc).

[David Fouejio]

Bonjour,

Je pense qu'au lieu de fixer la taille de ton buffer de r�ception par

char sz[4096 +1]

tu devrais utiliser plut�t la fonction de la classe CCom de Farscape qui retoure le nombre de caract�res disponibles.

[farscape]

Bonjour,

Je pense qu'au lieu de fixer la taille de ton buffer de r�ception par
char sz[4096 +1]

tu devrais utiliser plut�t la fonction de la classe CCom de Farscape qui retoure le nombre de caract�res disponibles.

hum effectivement je n'avais pas fait attention a cette partie de code...
cette portion la :

Code :

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

1
2
 
m_sRx += sz;

pour moi n'est pas correcte...
si ton buffer de r�ception re�oit un z�ro ton ajout � m_srx sera tronqu�.
il vaut mieux utiliser :

Code :

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

1
2
3
4
5
char sz[4096+1] = {0};
 
m_comDll.ReadBuffer(sz,sizeof(sz)-1);
m_sRx += CString(sz,m_comDll.GetCountRead());

[homeostasie]

si tu as un gestion de flux correct tu ne dois pas perdre de caract�res ou alors tu as un chipset vraiment mauvais (ce qui n'est plus le cas depuis des ann�es sur les pc).

Oui oui, ca ne vient pas de l�, c'est clair!

Sinon j'ai essay� ceci:

Code :

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

1
2
3
4
5
 
char sz[4096+1] = {0};
 
m_comDll.ReadBuffer(sz,sizeof(sz)-1);
m_sRx += CString(sz,m_comDll.GetCountRead());

R�sultat de ceci, je sauvegarde seulement la premi�re lecture du buffer de r�ception, bizarre...

Dans mon cas, je me dis que cela

Code :

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

m_sRx += sz;

est correcte car je travaille en ascii. J'initialise au pr�alable � z�ro mon tableau de char pour �tre sur d'avoir le caract�re de fin de chaine afin de stocker seulement ce que jeviens de lire dans mon buffer de r�ception.

J'ai effectu� un autre test ce matin, en faisant ceci:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
long CComTLS::ON_WM_CCOMRCV(WPARAM wparam,LPARAM lparam)
{
        char sz[4096+1] = {0};
 
	m_comDll.ReadBuffer(sz,sizeof(sz)-1);
	UINT nOctetLus = m_comDll.GetCountRead();
	TRACE(" %d -> %s",nOctetLus,sz);
	m_sRx += sz;
 
	m_nTotalOctetLus += nOctetLus;	
 
	return 0L;
}

Je constate que de temps en temps, GetCountRead() annonce que je viens de lire x caract�res (par exemple 42) et que sz n'en compte que y (par exemple 13). La diff�rence entre ces deux valeurs corresponds aux caract�res soit disant perdus... Je ne comprends pas d'ou vient le probl�me!

A titre d'information, les valeurs retourn�es par GetCountRead() sont celles que j'attends vraiment. Le soucis viendrait alors de ma facon de r�cup�rer les caract�res recus ou sinon de la fonction ReadBuffer() fourni dans la classe CCom qui me stocke incorrectement les caract�res re�us(ce qui me surprendrait mais on ne sait jamais...).

Une id�e? Ou une autre facon d'impl�menter?

Merci

Nicolas

[farscape]

salut,
et pour la gestion de flux ? le cable etc .. ?

[homeostasie]

salut,
et pour la gestion de flux ? le cable etc .. ?

Niveau gestion de flux, je n'ai rien r�gl�. J'ai laiss� l'initialisation par d�faut.
La configuration que j'utilise actuellement fonctionne tr�s bien avec l'hyperterminal et avec des versions ant�rieures du logiciel.

Si j'ajoute un sleep(100) dans ma fonction de message priv�

Code :

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

long CComTLS::ON_WM_CCOMRCV(WPARAM wparam,LPARAM lparam)

alors je perds encore plus de donn�es, sachant que GetCountRead() me retourne toujours bien le nombre de donn�es que je d�sirerais lire.

Cela pourrait il venir du fait que ma pompe � messages ne traite pas assez rapidement le message ou bien le code associ� dans le message priv�?

Ma configuration s�rie est de 8 bits de donn�es, 1 bit de stop, et 19200 bauds.

En esp�rant que cela fasse avancer l'affaire...

[farscape]

si tu n'as rien r�gl� au niveau gestion de flux il ne faut pas s'etonner si tu perds des caract�res .....

[homeostasie]

si tu n'as rien r�gl� au niveau gestion de flux il ne faut pas s'etonner si tu perds des caract�res .....

D'accord...

Voici comment j'ai r�gl� ma gestion de flux:

Code :

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

1
2
3
4
5
6
7
8
9
 
m_comDll.PortOpen(nCom,nDebit,'N',8,1);
 
if(!m_comDll.UseXonXoff(true))
	AfxMessageBox("Erreur pour initialiser la gestion de flux!",MB_OK);
 
m_comDll.PurgeCom();
 
m_comDll.SetCommMask(EV_RXCHAR); // spécifie l'événement d'attente.

Le r�sultat est toujours le m�me, perte de caract�res! Comment savoir quelle gestion de flux utilis�?
(La sp�c de l'�quipement qui envoie les donn�es s�ries ne demande pas de configurer avec une gestion de flux)

Voil� ce que me retourne la fonction ReadFile() appel�e par ReadBuffer() grace � l'utilisation de la fonction TRACE :

ReadFile: 44 caract�res, buffer: 01 54 00 00 01 00 01 01 01 D8 0810 00000028
ReadFile: 42 caract�res, buffer: 00 EF 4C 400HZ_KO
ReadFile: 50 caract�res, buffer: 01 03 01 00 0800 000000B6 61 EF 4C BAD_FREQ_DISC
ReadFile: 68 caract�res, buffer: 01 54 00 01 01 00 01 01 01 C9 0810 00000028 00 EF 4C 400HZ_KO
ReadFile: 57 caract�res, buffer: 01 42 00 01 01 00 01 03 01 00 0800 000000B6 61 EF 4C BAD_
ReadFile: 43 caract�res, buffer: FREQ_DISC
01 54 00 02 01 00 01 01 01 DC 08
ReadFile: 2 caract�res, buffer: 10
ReadFile: 40 caract�res, buffer: 00000028 00 EF 4C 400HZ_KO

J'ai mis en gras, l'endroit o� des donn�es semblent perdues. ReadFile() me retourne par exemple 42 caract�res lus et me stocke dans la variable de r�ception "buffer" seulement 18 caract�res.
C'est de cela qu'on conclue qu'il ya un probleme de gestion de flux?
J'aurais pens� que meme si on perds des donn�es, le nombre de caract�res lus corresponds au nombre mis dans le buffer.
Pourquoi perdrais je des caract�res maintenant est pas auparavant?

Merci
Nicolas

[farscape]

je note que tu re�ois bien des \0 dans ton flux contrairement � ce que tu disais plus haut ,
alors pour moi ta concat�nation de chaine ne peut fonctionner...
si tu ne connais pas la gestion de flux ne met pas xon/xoff c'est le plus sur moyen de tout bloquer ...
r�gle le en mode rts/cts.

[homeostasie]

Je voulais rajouter que GetOverlappedResult() renvoie bien le m�me nombre de caract�res que ReadFile().

Est ce que mon probl�me ne pourrait pas plutot venir au niveau de la pompe � message de la classe (d�riv�e de CDialog) qui instance l'objet CCom?

En effet, serait il possible que je traite trop lentement les messages envoy�s, via SendMessage(), du thread de r�ception de la communication s�rie vers ma classe d�riv�e de CDialog?
J'ai constat� qu'en utilisant PostMessage(), je perds moins de donn�es. Fruit du hasard ou est ce un indice sur la source du bug?

[EDIT]

je note que tu re�ois bien des \0 dans ton flux contrairement � ce que tu disais plus haut ,
alors pour moi ta concat�nation de chaine ne peut fonctionner...

Ce n'est pas un \0 mais un "0", cad le caract�re 0 de la table ascii.

[homeostasie]

si tu ne connais pas la gestion de flux ne met pas xon/xoff c'est le plus sur moyen de tout bloquer ...
r�gle le en mode rts/cts.

Avec le mode rts/cts, je ne r�cup�re plus rien!

J'ai aussi essay� avec les autres modes, cela ne change rien au fait que je perds des donn�es.

De plus, j'ai impl�ment� diff�remment ma lecture du port s�rie, sans passer par le lancement du thread, mais en effectuant ma r�cup�ration de donn�es � coup de ReadBuffer(), le r�sultat est le m�me...

[homeostasie]

Bonjour,

En fait, l�origine de la panne provient du temps de traitement de l�application vis � vis des messages.
Dans mon cas de figure, un thread de travail lan�ait le thread de r�ception de donn�es. Ce dernier informait l�arriv�e de donn�es en �mettant un message priv�e vers mon thread de travail.
Afin de r�aliser un curseur d�attente durant la r�ception de donn�es � partir de mon thread de travail, j�avais fait le code suivant :

Code :

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

1
2
3
//Forme du curseur en sablier: attente
::PostMessage(m_hWnd,WM_GESTION_CURSEUR,0,0);  // Message vers le thread principal d’interface utilisateur
m_WaitCursor = true;

Dans mon thread principal d'interface utilisateur:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
long CTLDlg::OnReceiveGestionCurseur(WPARAM wparam,LPARAM lparam)
{
	BeginWaitCursor();
	while(m_WaitCursor)
	{
		PumpMessages();
		RestoreWaitCursor();
		Sleep(50);			
	}
	EndWaitCursor();
 
	return 0l;
}

Cette fonction devait me consommer trop de temps de traitement. Depuis que je l�ai mise en commentaires, je n�ai plus de perte de donn�es, enfin presque�

2 probl�mes subsistent :
- Si l�utilisateur joue avec la fen�tre principale (la bouge dans tout les sens), superpose rapidement une autre fen�tre dessus en d�placement rapide etc�, je perds � nouveau des donn�es, dues au traitement des messages pour mettre � jour la fen�tre de mon application.
J�ai pourtant augment� la priorit� du thread de travail mais aucun r�sultat. A ce jour, j�ai intercept� et bloqu� tout les clics souris sur le fen�tre de l�application durant la r�ception des donn�es.
Il y a t�il une m�thode plus astucieuse ?

- Comment impl�menter un curseur d�attente � partir d�un thread de travail cr�� � partir du thread principal de l�interface utilisateur ?
J�ai fait ceci mais cela n�y fait rien, pas de curseur d'attente :

Code :

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

1
2
3
HCURSOR hCursor = AfxGetApp()->LoadStandardCursor(IDC_WAIT);
if(NULL == hCursor)
AfxMessageBox("Erreur pour charger le curseur d'attente",MB_OK);

Merci pour votre aide.

Nicolas

[farscape]

salut,
je sais je me r�p�te mais :
c'est pour cela que l'on travaille avec une gestion de flux ....
pour �viter de perdre des caract�res quand le r�cepteur n'est pas pr�t.
il vaudrait mieux que tu creuses la question de la gestion de flux cot� �metteur.
on ne peut pas faire du transfert de donn�es en flux continu sans gestion de flux...

[homeostasie]

C'est vrai, tu as raison!

il vaudrait mieux que tu creuses la question de la gestion de flux cot� �metteur

A vrai dire je crois qu'il y en a pas (aucune sp�c sur l'�quipement indique une gestion de flux), et je ne pourrais modifier le code impl�ment� dans l'�quipement.

Ayant essay� tout les modes possibles de gestion de flux et n'ayant pas eu de r�sultats probants, j'en conclue donc que la gestion de flux cot� �metteur n'a pas �t� g�r�...

Il y a un truc qui m'�chappe. Je pensais que toutes donn�es recues sur le port s�rie sont stock�es dans un buffer de r�ception g�r� au niveau hardware, pourquoi perdrais je des donn�es? A moins que si je recois des donn�es alors que le processeur est occup� pour une autre t�che, alors je perds ces derni�res?

[farscape]

le buffer au niveau du hardware est tr�s limit� (quelques octets) �a d�pend du chipset s�rie,
ici c'est windows qui prend le relai au niveau du buffer .
dans ma classe le buffer est r�gl� par d�faut � 1050 octets .
tu as peut �tre int�r�t a augmenter la valeur par d�faut.
la gestion de flux assure au moins que lorsque le buffer est rempli l'�metteur est avertit pour qu'il s'arr�te d'�mettre ...
je peux pas croire que le mat�riel en question ait fait l'impasse sur ce sujet.

[homeostasie]

dans ma classe le buffer est r�gl� par d�faut � 1050 octets .
tu as peut �tre int�r�t a augmenter la valeur par d�faut.

C'est d�j� fait!
Mais je ne suius pas sur que cela est servi car j'ai rajout� une Trace apr�s l'appel de la fonction GetOverlappedResult() et je recois puis lis de 1 a 2 octets.

je peux pas croire que le mat�riel en question ait fait l'impasse sur ce sujet.

C'est un �quipement con�u et d�velopp� par la boite dans laquelle je travaille. Et j'ai l'impression que le programmeur qui s'est occup� de cette partie a omi la gestion de flux.
Je vais t�cher de me renseigner.

En tout cas, merci pour les renseignements!

[farscape]

le pb est r�gl� ?

[homeostasie]

Disons � moiti�...

La source du probl�me est bel et bien �lucid�e. Apr�s renseignements, aucune gestion de flux a �t� pr�vu du c�t� de l'�metteur.

La solution qui me vient � l'esprit pour limiter le nombre de messages � traiter, notamment avec le code de l'affichage du curseur d'attente que j'ai montr� dans les messages pr�c�dents:
Durant la r�ception de donn�es, filtrer tout les �v�nements souris dans la fonction PreTranslateMessage et charger le curseur d'attente par d�faut dans l'application. (Chose que je n'ai pas recu encore � faire et qui est le sujet d'un autre post...).

[farscape]

peut �tre quand implementant une pile de reception �a devrait limiter le probl�me.
tu receptionnes en permanence dans un buffer par le thread de r�ception sans traitement.
et dans un autre thread tu exploites le buffer recu pour ton traitement...