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

je pense en effet que readline attend qu'un clrf soit dans le buffer ...
utilise les autres .read

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?

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)

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.