Le serveur arrête la réception + désynchronisation

Version imprimable

Voir 40 message(s) de cette discussion en une page

10/09/2009, 10h50
ens-lyon

Salut :

Juste d'autre question si tu permet :

Je ne comprend toujours pas pourquoi il y'a des pertes alors que le protocole TCP/IP assure la récéption de la donnée????

On sait que (si je me trompe pas) si le recepteur n'a pas réussila donnée il la redemande encore et encore jusq'a réception , je vois mieux pourquoi il y'a un décalage entre les données qui sont réelement acquise dans le temps dans la lecture via SPI, mais normalement il doit pas avoir de perte non????
10/09/2009, 11h19
ens-lyon

Ouhla je viens de me rendre compte d'une chose pettr importante:

Le programme qu'avait écrit mon maitre de stage pour le code TCP/IP , est en mode non bloqué , ça peut signifier quoi ça???que le send ne bloque meme pas??
10/09/2009, 13h21
Mac LAK

Citation:

Envoyé par ens-lyon

Je ne comprend toujours pas pourquoi il y'a des pertes alors que le protocole TCP/IP assure la récéption de la donnée????

Je pense qu'il n'y a pas de pertes réelles, mais un écrasement des données au niveau des buffers internes de la stack TCP/IP de ton µC lors de l'envoi, lié à la saturation des dits buffers.

Citation:

Envoyé par ens-lyon

Le programme qu'avait écrit mon maitre de stage pour le code TCP/IP , est en mode non bloqué , ça peut signifier quoi ça???que le send ne bloque meme pas??

Qu'un thread dédié à la stack TCP/IP fonctionne dans le système afin d'assurer la gestion asynchrone. Ce qui revient peu ou prou à ce que je te conseillais de faire, mais tu n'auras peut-être pas autant de contrôle sur ce thread "système" que sur un thread créé par tes soins.
10/09/2009, 13h29
ens-lyon

Citation:

Qu'un thread dédié à la stack TCP/IP fonctionne dans le système afin d'assurer la gestion asynchrone. Ce qui revient peu ou prou à ce que je te conseillais de faire, mais tu n'auras peut-être pas autant de contrôle sur ce thread "système" que sur un thread créé par tes soins.

Ok soit , je vais essayer de me debrouiller , car je connais rien en programmation multitaches,c'est pas du tout mon domaine!!!:(

Merci
10/09/2009, 13h35
ens-lyon

Encore je vais te deranger avec mes question débiles un peu:

Maintenant que je sais que le serveur ne bloque pas mais remplit la pile et rend la main pour l'acquisition de nouvelle données.

1-Qui se charge de l'envoi après???si ce serveur a rempli la pile et a rendu la main???

2-Pourquoi à l'oscillo j'ai des arrets pendant des moment??si le serveur a rendu la main alors la lecture ne doit pas se faire d'une façon continue et sans interruption???

Cordialement
10/09/2009, 13h45
Mac LAK

Citation:

Envoyé par ens-lyon

Ok soit , je vais essayer de me debrouiller , car je connais rien en programmation multitaches,c'est pas du tout mon domaine!!!:(

Oui, mais d'un autre côté, t'as un maître de stage dont le boulot est, justement, de te former et non pas de te laisser galérer.
Attention, je ne dis pas que je ne veux pas te répondre, mais je n'ai pas forcément toutes les billes en main : c'est à lui aussi de faire sa part du marché dans ton stage, et non pas juste te prendre comme main d'œuvre gratuite.

Citation:

Envoyé par ens-lyon

1-Qui se charge de l'envoi après???si ce serveur a rempli la pile et a rendu la main???

Un thread/processus dédié qui s'occupe de l'envoi vers le contrôleur Ethernet lui-même. Soit la stack fonctionne comme ça (le cas le plus courant), soit tes fonctions sont bloquantes jusqu'à ce que les données aient fini d'être émises sur le réseau (cas de pas mal de stacks embarquées pour µC).

Citation:

Envoyé par ens-lyon

2-Pourquoi à l'oscillo j'ai des arrets pendant des moment??si le serveur a rendu la main alors la lecture ne doit pas se faire d'une façon continue et sans interruption???

Explicite un peu mieux stp : tu mesures quoi, à quel endroit, et sous quelles conditions de fonctionnement ?
10/09/2009, 15h05
ens-lyon

Bh en fait à l'oscilloscope je visualise les signal de l'horloge SPI qui m'indique si effectivement je suis en phase de lecture de données.

Comme j'ai déjà dit il y'a des moment où cette horloge arrête d'être generée , alors cela veut dire que l'instruction de lecture ne s'est pas déroulé dans le programme , cette instruction qui vient juste après l'envoi , Or l'envoi est non bloquant cela veut dire que la lecture doit continuer.

tu a compris ???
10/09/2009, 15h32
Mac LAK

Citation:

Envoyé par ens-lyon

Comme j'ai déjà dit il y'a des moment où cette horloge arrête d'être generée , alors cela veut dire que l'instruction de lecture ne s'est pas déroulé dans le programme , cette instruction qui vient juste après l'envoi , Or l'envoi est non bloquant cela veut dire que la lecture doit continuer.

C'est que le send() est en fait bloquant et/ou qu'un thread de plus haute priorité a pris la main (au hasard, celui de la stack...).
10/09/2009, 15h35
ens-lyon

Citation:

Envoyé par Mac LAK

C'est que le send() est en fait bloquant et/ou qu'un thread de plus haute priorité a pris la main (au hasard, celui de la stack...).

Non le send n'est pas bloquant , d'après le code.

Mais comment je peux savoir quel processus a pris la main,et s'en débarasser?
et si c'est celui du stack, ca sert a quoi alors d'avoir un mode non bloquant???

Désole pour ce ton d questions, ca me met vraiment mal a l'aise!!!!
10/09/2009, 15h48
Mac LAK

Citation:

Envoyé par ens-lyon

Mais comment je peux savoir quel processus a pris la main,et s'en débarasser?

Là, ça dépend de l'OS qui tourne sur ton µC, et du niveau de contrôle que tu as dessus. La liste des tâches peut être "en dur" dans le code, par compilation, ou dynamique (=> appel de fonction système pour en avoir la liste), ou un système autre. Impossible de te répondre sans connaître l'OS.

Citation:

Envoyé par ens-lyon

et si c'est celui du stack, ca sert a quoi alors d'avoir un mode non bloquant???

Si c'est celui-là, c'est juste que les priorités sont mal réglées : ton thread d'acquisition SPI doit avoir une priorité supérieure.

Comme je te l'ai dit, l'idéal est d'avoir l'acquisition SPI en IT, et l'envoi TCP/IP dans un thread : ce serait le cas idéal, passant outre TOUS les problèmes de ce genre. Dans tous les autres cas, tu pourras tomber sur un cas vicieux qui plombera l'acquisition et/ou l'envoi.
10/09/2009, 15h54
ens-lyon

Bon la j'ai refait le test de led cette fois pour mode non bloquant.

Résultat : toujours la même chose blocage!!!

t'en di quoi???
10/09/2009, 15h59
Mac LAK

Faut regarder du côté de la priorité du thread de stack, je te l'ai dit... Monte la priorité de ton thread d'acquisition au maximum et/ou baisse celui de la stack.
11/09/2009, 12h08
ens-lyon

Salut , ca va???

Alors j'ai reussi à avoir une lecture qui se deroule tout le temps sans interruption.

Mainetant il faut que j'aurai pas d'erreurs donc pour faire je veux suivre la méthode du ping pong bufering est ce que tu peux me dire plus sur le coté sémaphore et comment faire pour etre sur que l'nvoi est effectivement terminé avant que je permute les buffer????
11/09/2009, 12h24
Mac LAK

Un simple mutex suffit pour permuter les buffers, il suffit d'en avoir un par buffer.

S'il est libre, le buffer est vide/déjà envoyé. S'il est pris, c'est qu'il est en cours de remplissage (côté SPI) ou d'envoi (côté TCP/IP).

Tu peux tester les débordements assez simplement via un trylock, ou un booléen (un par buffer, protégé par le mutex) que tu ne ferais QUE lire en dehors du code protégé (et qui reflète l'état de disponibilité du buffer).
11/09/2009, 12h38
ens-lyon

Ouhla c'est quoi ces mot que j'ai jamais entendu.

Ok je vais chercher la signification de tout ce que tu me dit ,si je pige rien je t'embete encore :D

Salut :

Bon j'ai tenté de faire déja avec un seul buffer et donc un seul mutex.
le SPI est prioritaire par une interruption avec un signal externe.
Et donc l'envoi se fait seulement si le mutex est dispo .

voila la portion du code qui s'occupe de l'envoi :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 while(1) { if (T->Established() == 1) { I2C_transmit_char(0x70,0x00); // led allume if((RTX_Reserve_Sem ( *semID,0))==0) //wait forever for semaphore and then { //reserve if possible T->Send(data,8*3); } I2C_transmit_char(0x70,0xff); // led eteinte }
Je n'arrive toujours pas à comprendre pourquoi j'ai des moments où le signal du led reste dans un seul état très longtemps(état 0xff) => pas d'envoi , cependant la lecture SPI se déroule a chaque front montant du signal externe.

tu peux m'expliquer cela stp.??

11/09/2009, 18h03
ens-lyon

C'est boon j'ai trouvé en fait je libére pas la sémaphore....:oops:
11/09/2009, 18h16
Mac LAK

DEUX buffers au minimum, sinon c'est comme si tu ne faisais rien du tout... Si ton send() bloque, tu l'as dans le dos avec un seul buffer, vu qu'il est bloqué pendant ce temps !
14/09/2009, 10h18
ens-lyon

Salut :

Je suis un peu perdu dans le code de la programation des semaphore , surtout avec un microp qui ne fournit pas d'exemple de programmer les sémaphore.

Tu veux stp mettre un algorithme un peu précis pour que je puisse voir ce que je peux faire exactement.

Merci.

Voila le lien expliquant un peu ces semaphore sur le microp: http://www.beck-ipc.com/files/api/sc.../rtx/rtx18.htm
14/09/2009, 10h47
Mac LAK

RTX_Create_Sem() pour créer le sémaphore, avec un initvalue de -1 (resource semaphore).
RTX_Delete_Sem() pour le détruire.

RTX_Reserve_Sem() pour prendre le sémaphore, avec un timeout nul (début de traitement d'un buffer).
RTX_Free_Sem() pour le libérer (fin de traitement d'un buffer).
14/09/2009, 10h55
ens-lyon

Tout ça je le connais et je l'ai fais , ce que je comprend pas c'est l'algorithme,quand commuter quand on a besoin d la semaphore, où l'appeler.

C'est l'algo que je ne comprend pas.
14/09/2009, 11h38
Mac LAK
Au début, l'acquisition SPI prends les DEUX sémaphores, et ENSUITE, le thread d'envoi TCP/IP essaie de prendre le premier (ce qui va le bloquer, bien sûr).

Une fois le premier buffer rempli, le SPI lâche le sémaphore du premier buffer, ce qui permet au thread d'envoi d'avoir la main dessus. Une fois les données envoyées, le thread d'envoi lâche le sémaphore, et attends le second (normalement, il est encore bloqué par l'acquision SPI).
A chaque fois que le buffer est plein, le thread SPI doit effectuer les actions suivantes :
- Prendre l'AUTRE sémaphore, éventuellement avec un timeout négatif pour vérifier s'il est libre (s'il ne l'est pas => erreur critique).
- Relâcher le sémaphore courant (=> libère le thread TCP/IP en attente dessus).
- Acquérir les données jusqu'à remplissage du buffer.
Pour le thread TCP/IP, c'est la séquence suivante :
- Prendre le sémaphore courant (=> on se retrouve bloqué, il est pris par l'acquisition SPI).
- Une fois débloqué, envoyer les données sur le réseau jusqu'à vider le buffer.
- Libérer le sémaphore courant.
- Prendre l'autre (=> bloqué, normalement).
14/09/2009, 11h42
ens-lyon

Merci infiniment , c'est ce que je faisai aussi , sauf que j'ai pas envi de taper des lignes de codes et de ne pas savoir les erreurs proviennent d'où surtout dans une programmation qui me fait perdre !!

Merci

Voilà quelques bouts de code pour assurer les échanges de buffers :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
int Current = 0 ;
void* Buffers[2] ;
int Semaphores[2] ;

// Récupération du buffer/sémaphore courant.
Buffers[Current] = .... ;
Semaphores[Current] = .... ;

// Récupération de l'AUTRE buffer/sémaphore.
Buffers[1-Current] = .... ;
Semaphores[1-Current] = .... ;

// Changement de buffer courant.
// A ne faire QUE lorsque l'acquisition SPI possède les DEUX sémaphores !!!!
Current = 1 - Current ;

Voila quelque lignes de code que j'ai fait si tu peu jeter un coup d 'oeil je me suis juste occupe de l'envoi pour le moment :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
while(1)
  	{
 
  		if (T->Established() == 1)
   	{  // recuperer les buf/semaphore
 
        Buffers[Current] =data1;
        Semaphores[Current] =semID1 ;
        Buffers[1-Current] = data2;
        Semaphores[1-Current] =semID2;
        // envoi
        T->Send(Buffers[Current],8*3,Semaphores[Current]);
        //echnage de buffer semaphore
        Current = 1 - Current ;
 
     }

Code de la fonction send :

Code:

1
2
3
4
5
6
7
8
9
short cSocket::Send(unsigned char * bufptr, USHORT bufLen,int far *sem)
{  int result;
    RTX_Reserve_Sem(*sem,0);
    result=send ( sd, bufptr, bufLen, MSG_DONTWAIT, &error );
    RTX_Free_Sem(*sem);
 
    //if (result==-1) established = 0;   //si l'envoi echoue on ferme la connection
    return result;
}

14/09/2009, 14h52
ens-lyon
Bon je crois je suis énormément perdu la :

Tu dis que AU DEBUT il faut que le SPI reserve les deux semaphore , comment alors faire sachant que mon SPI fonctionne sur interruption externe.
Code:

1 2 3 4 5 6 7 8 9 void main() { //installation de l'interruption while(1) { if(connected) //envoi } }
Dans le main je ne sais pas comment faire le "AU DEBUT", ni l'echange de buffers puisque comme j'ai dit le SPI est en interruption.
Donc en gros je te demande stp qu'est ce que je dois mettre dans les fonction :

Code:

void huge Config_SPI_HW::ReadWriteBlock(unsigned char *rbuffer,unsigned char *wbuffer) //Read/Write 8 Bytes

et

Code:

short cSocket::Send(unsigned char * bufptr, USHORT bufLen)

qu'est ce que le main doit contenir et qu'est ce que le thread envoi et l'interruption vont contenir???

Merci

Salut j'attend toujours ta réponse , en attendant je te file mon pseudo code pour voir si c'est ce qu'il faut faire :

Code:

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
 
unsigned char data1[8*3];              // les deux buffer
unsigned char data2[8*3];
 
unsigned char zz=0x00;
unsigned char wbuffer[8]={zz,zz,zz,zz,zz,zz,zz,zz};              // pour la fonction de la lecture SPI
 
int far *semID1;                     		// semaphore for protecting data1 , et data2
int far *semID2;
// variable pour l'échange
 
int Current = 0 ;                             	// variables d'echange cote EVNOI TCP
void* Buffers[2] ;
int Semaphores[2] ;
 
int _Current = 0 ;                    		  //variables d'echange coté SPI
void* _Buffers[2] ;
int _Semaphores[2] ;
 
 
short cSocket::Send(USHORT bufLen)
 
{		Buffers[Current]=data1;       //recupere buffer et semaphore
		Semaphores[Current]=semID1 ;
		Buffers[1-Current] = data2;
		Semaphores[1-Current] =semID2;
 
		RTX_Reserve_Sem(Semaphores[Current],0);
		send ( sd, Buffers[Current], bufLen, MSG_DONTWAIT, &error );
		RTX_Free_Sem(Semaphores[Current]);
 
    		current=1-current;		//echange de semaphore et buffer.
}   
 
 
void huge Config_SPI_HW::ReadWriteBlock()
{
  spi_waiton_sem_setmode_dyn(SPI_MODE, div);  		//pour synchroniser les esclaves SPI.
 
		_Buffers[_Current]=data1;       	//recupere buffer et semaphore
		_Semaphores[_Current]=semID1 ;
		_Buffers[1-_Current] = data2;
		_Semaphores[1-_Current] =semID2;
 
		RTX_Reserve_Sem(Semaphores[Current],0);
//Lecture SPI
 while(1)
 
      { 	 for (i=0;i<8;i++)
      		{
                     		spi_read_write_dyn(_Buffers[_Current]+i,wbuffer+i,1);
                     		//Introduction de retard
                     		while(ctr-->0);
                     		ctr = 2;
               		}
 
       }
		RTX_Free_Sem(_Semaphores[_Current]);   //liberer la semaphore
 
		_Current =1-_Current;    //echange de buffer semaphore
  spi_release_sem();        // liberer le bus SPI
}
 
 
 
main()
 
{
 
 
  // debut de code 
 
 
while(1)
{
if(connected)
 
 	{    Send(8*3);
 
 	}
else
	{
 	// ecoute et réinitialisation de la connection
 
	} 
 
}

Le souci est comment le SPI peut posseder les deux sémaphore tout au début.

Merci et désolé encore pour le dérangement!

14/09/2009, 17h32
Mac LAK

Déjà, il faut vérifier que le SPI peut bien acquérir les sémaphores tout en étant en IT. Normalement, oui, mais c'est à vérifier quand même.

Ensuite : au départ, l'acquisition SPI peut parfaitement locker les deux sémaphores parce qu'ils n'appartiennent à personne.

Enfin : tu ne dois pas échanger les buffers, et encore moins les sémaphores, dans le thread TCP/IP. Seul l'acquisition SPI a le droit de le faire, le thread TCP/IP prenant TOUJOURS le buffer/sémaphore courant.
Dit autrement, le consommateur (thread TCP/IP) boucle sur un seul et même buffer, c'est le producteur (acquisition SPI) qui est maître des deux buffers et autorise la permutation.
15/09/2009, 02h50
ens-lyon

Comment le TCP/IP doit boucler sur un seul buffer???

Citation:

Pour le thread TCP/IP, c'est la séquence suivante :
Prendre le sémaphore courant (=> on se retrouve bloqué, il est pris par l'acquisition SPI).
Une fois débloqué, envoyer les données sur le réseau jusqu'à vider le buffer.
Libérer le sémaphore courant.
Prendre l'autre (=> bloqué, normalement).

Prendr l'autre ca veux dire l'autre buffer non!!??

Ce n'est pas logique si on boucle sur le meme buffer on risque de l'ecraser par l'ecriture SPI a tout moment!!!

Vraiment je comprend plus rien en ce que tu m'a di c'est un peu contradictoire pour moi,l'envoi doit se fair sur un buffer quand ce buffer est plein l'envoi se fera cette fois sur l'autre , il y'a bel et bien 2 buffer quand meme dans le processus TCP/IP , et apres tu di :

Citation:

Enfin : tu ne dois pas échanger les buffers, et encore moins les sémaphores, dans le thread TCP/IP

Comment ca se fait???8O
15/09/2009, 11h38
Mac LAK

Citation:

Envoyé par ens-lyon

Comment le TCP/IP doit boucler sur un seul buffer???

Oui, il envoie (par exemple) toujours le contenu du premier buffer.

Citation:

Envoyé par ens-lyon

Prendr l'autre ca veux dire l'autre buffer non!!??

Prendre le SÉMAPHORE de l'autre buffer. Une fois plein, l'acquisition SPI va échanger buffers et sémaphores.

Citation:

Envoyé par ens-lyon

Ce n'est pas logique si on boucle sur le meme buffer on risque de l'ecraser par l'ecriture SPI a tout moment!!!

Mais non. A part sur la première boucle (et encore...), le SPI, lui, remplit systématiquement le SECOND buffer.

Citation:

Envoyé par ens-lyon

Vraiment je comprend plus rien en ce que tu m'a di c'est un peu contradictoire pour moi,l'envoi doit se fair sur un buffer quand ce buffer est plein l'envoi se fera cette fois sur l'autre , il y'a bel et bien 2 buffer quand meme dans le processus TCP/IP

Oui, mais regarde de nouveau le schéma que j'avais indiqué en début de sujet, sur le double buffer : à chaque fois, un des accès est coupé pour un des éléments.

Le fait de "changer de buffer" signifie que l'on échange les pointeurs des buffers, et des sémaphores associés, lorsque le buffer SPI est plein.

Citation:

Envoyé par ens-lyon

Comment ca se fait???8O

Parce que le thread TCP/IP est consommateur (= "esclave", si tu préfères). Ce n'est pas lui qui peut décider du taux de remplissage du buffer en cours d'acquisition SPI, mais bel et bien le code d'acquisition SPI lui-même. C'est donc le SPI qui est "maître" des buffers, et qui décide du moment où l'échange se produit.
15/09/2009, 13h00
ens-lyon

Ok ,alors pourquoi tu a expliqué au début que :

Citation:

Quand le buffer d'acquisition SPI est plein, tu permutes les deux buffers (en fait, simplement le pointeur sur le buffer), et tu préviens par un sémaphore / mutex / flag global que l'envoi doit se faire sur l'autre buffer
15/09/2009, 13h47
Mac LAK

Citation:

Envoyé par ens-lyon

Ok ,alors pourquoi tu a expliqué au début que :

Parce que c'est le principe général : en l'occurrence, tu "préviens" en libérant le sémaphore, ce qui va libérer le thread TCP/IP en attente... Et comme tu viens de permuter les deux buffers, "son" buffer est bien de nouveau plein et prêt à être expédié.

Voila ma dérniere version du code , tu peux me dire si c'est bon là , sinon tu peux editer le code et mettre des explications dessus , genre des commentaires là où ça marche pas :D

Déclarations :

Code:

1
2
3
4
5
6
7
int far *semID1;                     		// semaphore for protecting data1 , et data2
int far *semID2;
// variable pour l'échange
 
int Current = 0 ;                             	// variables d'echange cote EVNOI TCP
void* Buffers[2] ;
int Semaphores[2] ;

Code TCP :

Code:

1
2
3
4
5
6
7
8
9
10
short cSocket::Send(unsigned char * bufptr, USHORT bufLen)
{  RTX_Reserve_Sem(Semaphores[Current],0); // reserve semaphore courant
 
	int result = send ( sd, bufptr, bufLen, MSG_DONTWAIT, &error ); // envoi quand il est  débloqué
   RTX_Free_Sem(Semaphores[Current]);      //  Quand le buffer est vidé on libére la sémaphore courante
   if (result==-1)
     established = 0;   //si l'envoi echoue on ferme la connection
 
   return result;
}

Code SPI

Code:

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
26
void huge Config_SPI_HW::ReadWriteBlock()  			//Read/Write 8 Bytes
{
  		spi_waiton_sem_setmode_dyn(SPI_MODE, div);  //pour synchroniser les esclaves SPI.
 
		Buffers[Current]=data1;       				  //recupere buffers et semaphores
		Semaphores[Current]=semID1 ;
		Buffers[1-Current] = data2;
		Semaphores[1-Current] =semID2;
 
		RTX_Reserve_Sem(Semaphores[Current],0); 	  //réserve le sémaphore courant.
 
		//Lecture SPI
 		while(1)
 
      { 	 for (i=0;i<8;i++)
      					{   	spi_read_write_dyn(Buffers[Current]+i,wbuffer+i,1);
                     		//Introduction de retard
                     		while(ctr-->0);
                     		ctr = 2;
               		}
       }
		RTX_Free_Sem(Semaphores[Current]);   //liberer la semaphore courante.
 
		Current =1-Current;    //echange de buffer /semaphore
  		spi_release_sem();        // liberer le bus SPI
}

Ah j'ai oublié le main :

Code:

1
2
3
4
5
6
7
8
9
while(1)
  	{
 
  	if (T->Established() == 1)
   		{
 
       			T->Send(Buffers[Current],8*3);
 
       		}

Voilà merci :P

Voir 40 message(s) de cette discussion en une page

Fuseau horaire GMT +2. Il est actuellement 01h36.