IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Réseau C Discussion :

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


Sujet :

Réseau C

  1. #1
    Candidat au Club
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 43
    Points : 3
    Points
    3
    Par défaut Le serveur arrête la réception + désynchronisation
    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

  2. #2
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par ens-lyon Voir le message
    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.

    Citation Envoyé par ens-lyon Voir le message
    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).
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  3. #3
    Candidat au Club
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 43
    Points : 3
    Points
    3
    Par défaut
    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.

  4. #4
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par ens-lyon Voir le message
    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.

    Citation Envoyé par ens-lyon Voir le message
    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 ?).

    Citation Envoyé par ens-lyon Voir le message
    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.

    Citation Envoyé par ens-lyon Voir le message
    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...

    Citation Envoyé par ens-lyon Voir le message
    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.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  5. #5
    Candidat au Club
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 43
    Points : 3
    Points
    3
    Par défaut
    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

  6. #6
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par ens-lyon Voir le message
    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.

    Citation Envoyé par ens-lyon Voir le message
    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.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  7. #7
    Candidat au Club
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 43
    Points : 3
    Points
    3
    Par défaut
    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.

  8. #8
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par ens-lyon Voir le message
    Des traces , pourriez vous expliquer encore plus?
    Les traces, c'est ce que j'expliquais dans le sujet précédent.
    Dans le cas d'un µC, tu n'as pas toujours accès à ce genre de choses, donc tu peux aussi jouer avec les leds pour afficher dans quel étape tu es.

    Citation Envoyé par ens-lyon Voir le message
    Donc durant les 800us , ca semble suffisant pour que le serveur fasse son envoi quand meme???
    Ben non, ce serait même étonnant que ça marche, si tu veux mon avis... J'ai l'habitude de laisser les tâches TCP/IP avec au moins 10 MILLIsecondes de latence...
    D'où l'intérêt d'acquérir le SPI en priorité (en IT par exemple), de mettre les données en FIFO et de laisser l'OS se débrouiller pour partager les 80% de temps CPU restant afin que l'envoi se passe correctement.

    Citation Envoyé par ens-lyon Voir le message
    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.
    T'es sur un µC : faudrait savoir avec quel OS tu tournes dessus, mais il y a de fortes chances que ce soit "aucun"... Donc, pas de thread système gérant l'envoi TCP/IP, donc un gouffre à temps CPU à priori.

    Si tu veux tracer ça, appelle l'allumage d'une led (ou d'un GPIO) avant l'acquisition SPI, et d'une autre led pour l'envoi TCP/IP. Bien sûr, tu éteinds les leds après l'appel, et tu colles un oscillo double voie là-dessus pour voir les timings. Au pire, fais-toi aider par un hardeux pour régler correctement les triggers de l'oscillo.

    En gros :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    while (1) {
        if (connected) {
            Led_1_GPIO = 1 ;
            Read_SPI();
            Led_1_GPIO = 0 ;
     
            Led_2_GPIO = 1 ;
            Send_TCP();
            Led_2_GPIO = 0 ;
        }
    }
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  9. #9
    Candidat au Club
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 43
    Points : 3
    Points
    3
    Par défaut
    Pourquoi 10ms , ça sert a quoi de se servir de tel type de transfert , si ce n'est pas si rapide?

    et en fait avec 10ms je ne peux rien faire , ma frequence d'echantillonage est 1Khz meme avec 1ms c'est pas possible de faire une telle frequence.

  10. #10
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par ens-lyon Voir le message
    Pourquoi 10ms , ça sert a quoi de se servir de tel type de transfert , si ce n'est pas si rapide?
    Parce qu'Ethernet n'est pas un protocole déterministe, pour commencer, et que TCP/IP n'est pas le protocole le plus simple du monde à gérer (UDP est nettement plus simple, mais ce n'est ni connecté, ni avec garantie de livraison).
    Or, un retard de quelques ms sur un réseau Ethernet est courant : suffit de pas grand chose, un CSMA/CD foiré, un cafouillage au niveau du contrôleur Ethernet, une implémentation PHY uniquement avec une couche MAC 100% soft, bref des raisons, il y en a plein.
    TCP/IP est rapide, mais ce n'est pas temps réel. Or, tu colles une tâche RT (l'acquisition SPI), synchrone en plus, en plein milieu d'un traitement dont la durée ne peut même pas être bornée.

    Par exemple, j'acquiert des milliers de signaux chaque milliseconde, et je les envoie par TCP/IP, et sans perte. Tout simplement parce que l'acquisition est en temps réel "dur", et l'émission bufferisée en temps réel "mou" (= moins prioritaire que l'acquisition)... Notamment parce que l'on n'envoie pas de données tant que la taille de paquet "idéale" n'est pas atteinte !

    Dans ton cas, je te conseille d'attendre au moins d'arriver au MTU, c'est à dire en gros 1400 octets, avant de tenter d'envoyer des données. Sinon, tu risques fort d'avoir plus de données d'entête TCP/IP que de charge utile, dans tes trames réseau, et c'est justement la construction de cet entête (et l'émission réelle de la trame) qui coûte le plus cher.

    Citation Envoyé par ens-lyon Voir le message
    et en fait avec 10ms je ne peux rien faire , ma frequence d'echantillonage est 1Khz meme avec 1ms c'est pas possible de faire une telle frequence.
    D'où threads et/ou acquisition sous IT... T'es sur un µC, pas sur un PC de bureau, ne l'oublie pas.

    Tu as un OS sur ton µC, ou pas ?
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  11. #11
    Candidat au Club
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 43
    Points : 3
    Points
    3
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    .

    Par exemple, j'acquiert des milliers de signaux chaque milliseconde, et je les envoie par TCP/IP, et sans perte. Tout simplement parce que l'acquisition est en temps réel "dur", et l'émission bufferisée en temps réel "mou" (= moins prioritaire que l'acquisition)... Notamment parce que l'on n'envoie pas de données tant que la taille de paquet "idéale" n'est pas atteinte !
    Paquet "idéale" ?La taille idéale de mon paquet qui est un 8octet est atteinte.

    En plus la lecture et l'envoi sont des instructions secquentielles , et si la lecture d'un paquet complet n'est pas faites alors il n'ya pas d'envoi .


    Citation Envoyé par Mac LAK Voir le message
    Dans ton cas, je te conseille d'attendre au moins d'arriver au MTU, c'est à dire en gros 1400 octets, avant de tenter d'envoyer des données. Sinon, tu risques fort d'avoir plus de données d'entête TCP/IP que de charge utile, dans tes trames réseau, et c'est justement la construction de cet entête (et l'émission réelle de la trame) qui coûte le plus cher.

    D'où threads et/ou acquisition sous IT... T'es sur un µC, pas sur un PC de bureau, ne l'oublie pas.

    Tu as un OS sur ton µC, ou pas ?
    C'est quoi l'emission réelle???

  12. #12
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Houlà, y'a du boulot : apparemment, tu ne sais pas comment fonctionne TCP/IP ni Ethernet, et j'ai l'impression que tu n'as pas beaucoup d'expérience dans l'embarqué et/ou le temps réel... Je comprends mieux certaines de tes questions. Suis les liens précédents, lis attentivement, ça devrait déjà dégrossir un peu tout ça.

    Citation Envoyé par ens-lyon Voir le message
    Paquet "idéale" ?La taille idéale de mon paquet qui est un 8octet est atteinte.
    Une trame Ethernet fait au maximum 1500 octets (ce que l'on appelle le MTU), tout compris, inclus l'entête Ethernet (18 octets en tout).
    Or, toute trame TCP/IP fait au minimum 53 octets, et en pratique 64 octets... Pour envoyer 8 octets "utiles", ça fait un peu beaucoup quand même. De plus, envoyer une trame proche du MTU ou une trame minimale, ça prends le même temps d'acquisition du médium (CSMA/CD), et plus tu découpes ton flux TCP/IP, plus tu vas "surcharger" ta communication avec des trames de contrôle... Donc, perdre du temps.
    Réciproquement, envoyer de trop grosses données d'un seul coup est très coûteux en temps CPU si l'on n'a pas une pile TCP/IP dédiée tournant dans un processus/thread séparé, contrôlé par l'OS, car il va falloir gérer les "découpes" en paquets <= 1436 octets (MTU utile pour TCP/IP).

    Citation Envoyé par ens-lyon Voir le message
    En plus la lecture et l'envoi sont des instructions secquentielles , et si la lecture d'un paquet complet n'est pas faites alors il n'ya pas d'envoi .
    Sauf que tu ne comprends pas que la tâche critique sur ton µC, c'est l'acquisition SPI et non pas l'envoi TCP/IP qui peut être plus ou moins différé sans aucune perte de données...
    A 8 octets par acquisition, toutes les millisecondes, cela veut dire que tu obtiens un paquet de taille correcte (environ 1400 octets) toutes les 175 ms... Donc, un peu moins de six paquets par SECONDE.
    Avec ton algo actuel, tu vas envoyer MILLE paquets par seconde, ce qui est bien trop élevé quoi qu'il en soit, et tu vas en plus perdre sévèrement en performances.

    Citation Envoyé par ens-lyon Voir le message
    C'est quoi l'emission réelle???
    Le moment où le paquet TCP/IP est réellement émis sur le réseau Ethernet physique... Ce qui peut arriver bien après l'acquisition "hard" depuis le SPI.

    J'aimerais aussi que tu répondes à ma question (que tu as éludée déjà deux fois) : as-tu un OS sur ton µC, permettant de créer des threads, ou pas ?
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  13. #13
    Candidat au Club
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 43
    Points : 3
    Points
    3
    Par défaut
    Non en matière de TCP/IP c'est pas mon domaine , je fais mes etudes en electronique, donc c'est dur pour moi un peu tout ça.

    Oui , mon microp permet la programmation multitache.

  14. #14
    Candidat au Club
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 43
    Points : 3
    Points
    3
    Par défaut
    Citation Envoyé par ens-lyon Voir le message
    Non en matière de TCP/IP c'est pas mon domaine , je fais mes etudes en electronique, donc c'est dur pour moi un peu tout ça.

    Oui , mon microp permet la programmation multitache.
    Je vais poster le code , reste a me guider dans ce que on peux faire pour palier ce problème.

    En ce qui concerne le décalage , désolé de ne pas répondre de suite , je désigne par décalage le fait que la fréquence d'acquision des données vue par le client n'est pas à 1Khz pile.

    J'ai pensé alors que c'est le TCP:IP qui est la cause de ce décalage puisque j'ai visualisé sur l'oscilo les trames SPI ,et tout marche nikel sauf que j'ai remarqué par contre que il n'ya pas de lecture ( pas de SPI clk) durant quelques moments au cours de l'acquision.

  15. #15
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par ens-lyon Voir le message
    Non en matière de TCP/IP c'est pas mon domaine , je fais mes etudes en electronique, donc c'est dur pour moi un peu tout ça.
    Je comprends mieux pourquoi tu arrives à faire des chronos avec un oscillo alors que tu ignores ce qu'est réellement TCP/IP ou le temps réel... Habituellement, c'est plutôt le contraire, les softeux ayant tendance à devenir tout pâles quand il faut sortir l'oscillo !

    Citation Envoyé par ens-lyon Voir le message
    Oui , mon microp permet la programmation multitache.
    Bon, alors tu vas vérifier combien de RAM il te reste sur ton µC (en gros, hein, pas à l'octet près), et prévoir un système de double buffers entre ton acquisition SPI et ton envoi TCP/IP.

    En gros :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
                          /----------\
                       +--+ Buffer 1 +--+
                       |  \----------/  =
    +----------+       |                =       +----------+
    | Acq. SPI | *-----+                +-----* | Env. TCP |
    +----------+       =                |       +----------+
                       =  /----------\  |
                       +--+ Buffer 2 +--+
                          \----------/
    Les "=" indiquent chemin bloqué : si l'acquisition SPI se fait dans le buffer 1, l'envoi TCP se fait à partir du buffer 2.

    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. Bien sûr, le thread SPI doit être en haute priorité, ou, mieux, sous IT afin de garantir qu'il sera appelé réellement à chaque milliseconde et non pas "à peu près" toutes les millisecondes... Les "sleep" à 800 micros, c'est rarement bien propre et précis.
    Le temps de finir l'acquisition d'un buffer complet, il y a de très fortes chances que ton envoi soit fini depuis bien longtemps. Au pire, ça se vérifie facilement par code, et tu peux donc passer dans un cas d'erreur connu (perte de données).

    Tu peux aussi passer par une FIFO protégée par plages, mais cela demande plus de primitives de synchronisation pour fonctionner correctement, et c'est également sensiblement plus complexe à gérer qu'un double buffer.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  16. #16
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par ens-lyon Voir le message
    En ce qui concerne le décalage , désolé de ne pas répondre de suite , je désigne par décalage le fait que la fréquence d'acquision des données vue par le client n'est pas à 1Khz pile.
    C'est pour ça que je te disais de coller ton acquisition SPI dans une IT plutôt que dans un thread...
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  17. #17
    Candidat au Club
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 43
    Points : 3
    Points
    3
    Par défaut
    Voila mon bout 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
    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
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    const USHORT TCPPORT = 7; //Port n° 7
     	int retval;
     	short sd;
     
     	// create the server and client socket
     	cSocket S, *T = NULL;
     
     	// create the SPI Interface
     	Config_SPI_HW *ItfSPI;
     
     	// Open the server socket
     	retval = S.Opensocket();
      	if (retval == API_ERROR)
       {
          printf("(1) API_ERROR\n");
          return 0;
       }
      	else
       	sd = retval;
     
      	// Setup the server socket
     	S.Bind(htons(TCPPORT));
     
       // Init. the SPI interface
     	ItfSPI= new Config_SPI_HW();
     	ItfSPI->InitSPIInterface();
     
       unsigned char data[8*3];
       unsigned char zz=0x00;
       unsigned char wbuffer[8]={zz,zz,zz,zz,zz,zz,zz,zz};
     
       //on applique la méthode Listen à l'objet S
    	retval = S.Listen();
      	T = new cSocket();
     
    	// Establish a connection
      	retval = S.Accept(*T);
      	if (retval == API_ERROR)
       {
          printf("(2) API_ERROR : %d\n",retval);
          return 0;
       }
       else
      		sd = retval;
     
     
     
     	while(1)
      	{    commande_present=hal_read_pio(PIN_COMMANDE);
     
      		if (T->Established() == 1)
       	{
     
     
          //etat 0
               if((commande_passe==1)&&(commande_present==0))    // front descendant commande active
                {
                 //traitement sur front descendant
     
                ItfSPI->ReadWriteBlock(data,wbuffer);
     
                while(i++<m);
                i=0;
                ItfSPI->ReadWriteBlock(data+8,wbuffer);  //cette lecture se fait avant le CS2
                /* 													  // ceu qui genere des erreurs.
                 while(i++<2*m);
                i=0;
                ItfSPI->ReadWriteBlock(data+16,wbuffer);
                 */
                 T->Send(data,8*3);
     
     
                }
               /*
                else if((commande_passe==0)&&(commande_present==0))
                {
                //pas de changement d'etat : front bas
     
                }
     
       else if((commande_passe==0)&&  commande_present==1))
     
                {
                //front montant
                 commande_passe=1;
                }
     
                else if((commande_passe==1)&&(commande_present==1))
                {
                //niveau hau
                } */
                commande_passe=commande_present;
     
          }
         else
          {   cout<<"conectionarrete"<<endl;
    	      delete T;
    			//on applique la méthode Listen à l'objet S
      			retval = S.Listen();
    		  	T = new cSocket();
      			// Establish a connection
    	  		retval = S.Accept(*T);
    	   	if (retval != API_ERROR)
       	 		sd = retval;
          }
     
      	}// while(1)
     
       return 0;
    }

  18. #18
    Candidat au Club
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 43
    Points : 3
    Points
    3
    Par défaut
    Donc l'acquisition se fait suivant le front d'un pin que je scrute.

    Je li du premier capteur , du deuieme , et ensuite j'envoi le buffer contenant les données des deux capteurs.

  19. #19
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Mouais, ça confirme ce que je pensais : il faut séparer ton code d'acquisition SPI de ton envoi sur Ethernet, et "grouper" plusieurs acquisitions ensemble sur la même trame pour gagner du temps (au moins 150 trames unitaires de 8 octets, donc).
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  20. #20
    Candidat au Club
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 43
    Points : 3
    Points
    3
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    Mouais, ça confirme ce que je pensais : il faut séparer ton code d'acquisition SPI de ton envoi sur Ethernet, et "grouper" plusieurs acquisitions ensemble sur la même trame pour gagner du temps (au moins 150 trames unitaires de 8 octets, donc).
    Salut , merci pour ta reponse , j'etai un peu malade donc j'ai pas pu te repondre.

    Je vais essayer de faire comme tu di le probleme c'est qu'il faut justifier au responsable pourquoi je doi faire,je veux dire des explicaions rationnelle.

    Merci d'avance

Discussions similaires

  1. Arrêt d'un serveur multithread
    Par bambou dans le forum Entrée/Sortie
    Réponses: 7
    Dernier message: 07/07/2010, 16h04
  2. [VBA, Pb serveur mail Exchange] Réception et Sauvegarde
    Par nokolyo dans le forum VBA Outlook
    Réponses: 8
    Dernier message: 01/12/2008, 17h51
  3. [tomcat] lancement/arrêt du serveur
    Par amel666 dans le forum Tomcat et TomEE
    Réponses: 1
    Dernier message: 28/05/2006, 23h55
  4. [DatagramSocket] Pb de réception de messages côté serveur
    Par simsky dans le forum Entrée/Sortie
    Réponses: 3
    Dernier message: 13/09/2005, 18h41
  5. Notifier l'arrêt du serveur
    Par tintin22 dans le forum Bases de données
    Réponses: 2
    Dernier message: 16/06/2005, 18h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo