Discussion :

[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????

[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??

[Mac LAK]

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.

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.

[ens-lyon]

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

[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

[Mac LAK]

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.

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).

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 ?

[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 ???

[Mac LAK]

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...).

[ens-lyon]

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!!!!

[Mac LAK]

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.

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.

[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???

[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.

[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????

[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).

[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

[ens-lyon]

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 :

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

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.??

[ens-lyon]

C'est boon j'ai trouvé en fait je libére pas la sémaphore....

[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 !

[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

[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).