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

VB.NET Discussion :

Réception Port COM. BytesToRead > = mais TimeOut sur readline


Sujet :

VB.NET

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éprouvé Avatar de megamario
    Homme Profil pro
    VB6/VB.net/C/C++/C#
    Inscrit en
    Septembre 2008
    Messages
    931
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Activité : VB6/VB.net/C/C++/C#
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2008
    Messages : 931
    Par défaut Réception Port COM. BytesToRead > = mais TimeOut sur readline
    Bonjour,

    J'ai un souci de lecture du port COM.

    Je contrôle si j'ai des données à lire par serialPort1.BytesToRead puis j'effectue un ReadLine mais j'ai un time-out dessus. Est-ce qu'il attend un caractère de fin pour permettre la lecture ?


    Merci

  2. #2
    Expert éminent Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 198
    Par défaut
    je pense en effet que readline attend qu'un clrf soit dans le buffer ...
    utilise les autres .read
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  3. #3
    Membre éprouvé Avatar de megamario
    Homme Profil pro
    VB6/VB.net/C/C++/C#
    Inscrit en
    Septembre 2008
    Messages
    931
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Activité : VB6/VB.net/C/C++/C#
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2008
    Messages : 931
    Par défaut
    Petite question.

    Qu'est-ce qui pourrait bloquer bloquer une liaison COM. J'ai essayé par exemple avec un serialPort1.ReadByte

    Mais mon souci est le même au bout d'un moment mon serveur se bloque.

    J'explique:

    Je crée un logiciel pour mettre à jour de façon automatique un petit serveur linux embarqué.
    Pour se faire je lit le port COM de ce serveur et lui envoie des commandes. Par exemple je lit le boot un fois qu'il est fini je supprime des fichiers et répertoire, j'ouvre une connexion tfp pour lui envoyer la nouvelle image.bin une fois terminé je ferme le ftp c'est la que cela se complique je lui lance des commandes pour le mettre à jour par le port COM.
    Et la avec mon logiciel lors de la mise à jour il y a un blocage du serveur. Donc effectivement au niveau du port COM j'ai plus d'info. Même si j'attend longtemps rien ne se passe.

    En redémarrant le serveur il se trouve dans un état de débogage , heureusement car cela nous permet de lui envoyer une image.bin de l'OS d'origine, NET OS. Une fois fait je lui envoie en ftp l'image.bin du linux et c'est bon.

    Mais pourquoi lorsque j'effectue toutes ces manipulations manuellement avec l'hyperterminal de windows pour la partie COM et les commandes ftp depuis le terminal windows cela se passe bien?

    Lorsque j'envoie la commande d'update :update_flash -r -q -t /ram /home/linux.bin 2.

    J'ai constaté que le serveur envoie des trames avec juste des CR entre chaque ligne indiquant la progression du flash.

    C'est pour cette raison je suppose que le ReadLine ne m'envoie rien dans qu'il n'a pas reçu le LF.

    Mais avec le ReadByte je vide bien le buffer mais le blocage est identique. Lorsque cela arrive sur mon logiciel je suis dans une boucle qui attend les données. En pas a pas je vois bien BytesToRead est à 0.

    Qu est-ce qui pourrait bloquer le serveur en comparaison avec la lecture de l'hyperterminal?

  4. #4
    Expert éminent Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 198
    Par défaut
    rien compris mais si ton problème est un serveur linux qui se bloque je ne pense pas que c'est le meilleur endroit pour en parler
    un port com ne peut pas faire planter un pc

    en .net la classe serialport permet d'envoyer et de recevoir des octets
    il faut la configurer (port, bauds, parité etc...) si les 2 côtés on le même paramétrage le dialogue peut se faire comme il faut
    en général on déporte le traitement sur un thread (à moins qu'il n'y ait des méthodes asynchrones) car de mémoire certaines méthodes sont bloquantes (= attente de réception avant de continuer l'exécution du programme, donc sur le thread principal ca peut figer l'appli)
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  5. #5
    Membre éprouvé Avatar de megamario
    Homme Profil pro
    VB6/VB.net/C/C++/C#
    Inscrit en
    Septembre 2008
    Messages
    931
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Activité : VB6/VB.net/C/C++/C#
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2008
    Messages : 931
    Par défaut
    Bonjour Pol63,

    J'ai effectivement un thread pour le port COM.

    Mon souci ne viens pas du serveur ou enfin pas directement.

    Pour faire simple, car je reconnais que je suis pas forcement clair.

    Si j'effectue les actions avec l'hyperterminal de windows cela fonctionne bien jusqu'au bout.

    Si j'effectue ces même action dans mon logiciel VB.net cela "fonctionne mal".

    La configuration de vitesse, de port est bien respecté. Je développe le "fonctionne mal":

    Avant de faire l'update j'envoie des commandes cela se passe bien, je reçois les retours cela se passe bien, donc la communication est bonne d’ailleurs, que j'utilise Readline ou ReadByte.

    Lorsque j'envoie la commande d'update cela commence bien puis plus rien. Avec la commande Readline il m'indique qu'il y a encore des donnée dans le buffer, normale s'il attend un caractère de fin avant de me fournir la ligne entière. Avec la commande readByte je vais jusqu'à ce qu'il n'y a plus rien à lire. Le serveur c'est bloqué.

    Alors effectivement c'est le serveur qui c'est bloqué, mais pourquoi. Pourquoi je ne retrouve pas ce défaut avec l'hyperterminal.

    Un collègue ma donner une piste, est-ce que ce n'est pas l'un de mes envoies précédent l'update qui n'arriverais pas plus tard et qui me provoquerais ce blocage du serveur. Lorsque j'envoie les commandes manuellement j'attend qu'elle soit traité. Lorsque j'envoie les commande avec mon logiciel j'attend aussi mais est-ce qu'il n'y a pas quelque chose dans le tuyaux.

    je vais regarder cette piste.

Discussions similaires

  1. Réponses: 1
    Dernier message: 19/07/2013, 12h38
  2. Réponses: 0
    Dernier message: 13/03/2009, 19h21
  3. [vb6] Evénement de réception/envoi sur port COM
    Par Original Prankster dans le forum VB 6 et antérieur
    Réponses: 31
    Dernier message: 13/12/2006, 00h05
  4. Problème de reception sur Port COM
    Par Revan777 dans le forum C
    Réponses: 9
    Dernier message: 19/04/2005, 21h55
  5. lire/écrire sur un port com sans le monopoliser
    Par totofweb dans le forum Windows
    Réponses: 4
    Dernier message: 26/07/2004, 13h23

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