Discussion :

[ens-lyon]

Bonjour

J'ai un serveur (un microcontrolleur) qui envoi les données reçues par une liaison SPI , mais il y'a des moments où le serveur arrete de lire les données

Voila les etapes apres etablissement de connection avec le client :

Code :

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

1
2
3
4
5
6
7
while(1)
if(connected)
{
Lire les données;
Envoyer les données;
 
}

Donc normalement si mon serveur n'arrive pas a continuer la boucle pour lire les données c'est que l'envoi bloque.
Autre chose les données que je reçois coté client (que je stock dans des fichiers binaires pour avoir le tracé Matlab après) sont décalés des données réelles.

Alors c'est quoi la solution :

1-Pour que la boucle ne bloque pas , car l'acquisition doit se faire d'une façon continue.
2-comment palier au problème de décalage.

Cordialement

[Mac LAK]

1-Pour que la boucle ne bloque pas , car l'acquisiont doit se faire d'une façon continue.

Acquisition SPI dans un thread, et la partie serveur TCP/IP dans un autre thread, tout simplement.

2-comment palier au problème de décalage.

Faudrait déjà voir ce que tu appelles "décalage"... Un exemple concret ?

Et vérifie via des traces, comme expliqué ci-dessus, que tu n'as pas de problèmes AVANT que cela ne se voie réellement via un blocage (souvent, lors de l'échange précédent).

[ens-lyon]

Merci pour la réponse .

Je dois dire que j'ai réflechi a la programmation multithread mais le problème je pense est le suivant :

le serveur lit les données et les envoi, cela se fait dans une boucle.

Le client lit ces données , mais après il doit effectuer un traitement : stocker dans des fichiers binaires.

Donc deux possibilités :

1-Soit le client ignore les données quand il est entrain de stocker, et donc il perd des echantillons, ce qui m'etonne en protocole TCP qui garantie la réception.

2-Soit le client tarde dans la phase du traitement , le serveur bloque alors sur l'instruction : send() , jusqu'à nouvelle demande de réception de la part du client, par recv().

Alors la programmation multithread ne doit pas se faire au niveau client que serveur, vu qu'il y'a assez d'instruction coté client que serveur??

J'aurai aimé poster le code mais il est sur une autre machine.Je compte sur votre comprehension.

[Mac LAK]

le serveur lit les données et les envoi, cela se fait dans une boucle.

Oui, et si ton client n'est pas connecté, tu crois qu'il se passe quoi dans ton send() ?
Il faut séparer l'acquisition (qui est sûrement synchrone, comme souvent avec le SPI) de TOUS les éléments asynchrones. Sinon, boum.

Le client lit ces données , mais après il doit effectuer un traitement : stocker dans des fichiers binaires.

Sauf si le volume de données reçues frise le monstrueux, ou que tu sauves sur un médium particulièrement lent, inutile de threader à ce niveau : tu ne stockeras rien que tu n'aie reçu, reste à savoir sur quoi tourne le client (je présuppose un PC sous Windows ?).

1-Soit le client ignore les données quand il est entrain de stocker, et donc il perd des echantillons, ce qui m'etonne en protocole TCP qui garantie la réception.

Oui, mais si ton client ne dépile pas assez vite sa socket, il n'enverra pas d'ACK, et va donc bloquer les envois/réception le temps de finir de vider les buffers. Mais il n'ignorera pas des données, par contre.

2-Soit le client tarde dans la phase du traitement , le serveur bloque alors sur l'instruction : send() , jusqu'à nouvelle demande de réception de la part du client, par recv().

Plus probable, mais ce serait étonnant car je suppose que ton client est un PC "normal", non ? Donc, globalement, bien plus puissant que ton µC...

Alors la programmation multithread ne doit pas se faire au niveau client que serveur, vu qu'il y'a assez d'instruction coté client que serveur??

Tout dépend de la problématique. Ce qui est sûr, c'est que ton code serveur est "mauvais" car il mélange deux actions n'ayant pas le même principe de fonctionnement (acquisition synchrone et émission asynchrone).
Vu que t'es sur un µC, il faudra peut-être mettre le code d'acquisition SPI en interruption plutôt qu'en thread (car pour ça, faut encore que tu aie la possibilité de créer des threads dessus, et donc d'avoir un OS !!), c'est à voir en fonction de ce qui tourne dessus.

[ens-lyon]

Oui je suis d'accord que ça soit deux action de natures differentes sur le serveur , cependant je declenche la lecture de données à un moment précis et apres j'ai normalement assez de temps pour faire l'envoi de données, avant la prochaine lecture.

Donc je ne vois pas comment ça peut causer un problème coté seveur?


Je répéte :

1-Le serveur cree une socket , puis il se met en écoute(bind listen ...).
2-le client demande la connection et le serveur accepte, et cree une autre socket pour communiquer avec le client.
3-

Code :

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

1
2
3
4
5
6
7
8
9
            while(1)
            {
                if(connected)
                {
                    lire les données;
                    envoi de donnes;
 
                 }
              }

4-cote client :

Code :

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

1
2
3
4
5
6
if(conected)
{
    recv(data);
    traitement de données;
 
}

Voila c'est tout.

J'essayerai de poster le code dans les minutes qui viennent,mais j'éspere continuer cette discussion pour voir en claire ce qui ne va pas.
Merci d'avance

[Mac LAK]

Oui je suis d'accord que ça soit deux action de natures differentes sur le serveur , cependant je declenche la lecture de données à un moment précis et apres j'ai normalement assez de temps pour faire l'envoi de données, avant la prochaine lecture.

Le "normalement" demande à être étayé et prouvé... Par expérience, surtout sur les µC, le "normalement" doit être pris avec d'extrêmes précautions.

Donc je ne vois pas comment ça peut causer un problème coté seveur?

Parce que tu n'as AUCUN contrôle sur ton send(), tout simplement, et qu'il peut bloquer (et donc différer l'acquisition SPI) à peu près n'importe quand.
Et si tu prends du retard sur un appel à send(), alors tu perds des données sur le SPI, d'où désynchronisation.

Donc, méthode de base :

• Activer/afficher des traces.
• En fonction du résultat des traces, dissocier les actions semblant poser problème (à priori, acquisition SPI et émission TCP/IP, donc).
• Relancer après correction, toujours avec les traces, et voir si le problème semble corrigé.
• Si oui, virer les traces (coûteux en temps CPU), voir si l'on tient les perfs.

[ens-lyon]

Désolé J'ai oublié : mon client se déroule sur mon PC.(une interface develppé en Borland Builder).

Des traces , pourriez vous expliquer encore plus?

Mon microp a une horloge 96Mhz.

Le temps de lecture des données ne dépassent pas 200us( visualisé à l'oscillo).

mon cahier de charge m'impose alors 800us avant la prochaine lecture , en gros 1Khz Comme freqence d'echantillonage.

Donc durant les 800us , ca semble suffisant pour que le serveur fasse son envoi quand meme???

Avec ces quelque details toujours je ne vois pas pourquoi ça peux causer un souci que ca soit synchrone ou non du moment qu'on lit et qu'on a assez de temps pour envoyer.