Temporisations SerialPort en mode autonome

Question

J'ai un comportement étrange dans mon application.

J'ouvre un port COM pour communiquer avec un appareil via Bluetooth. Je fais les étapes suivantes:

1. Ouvrez le port COM virtuel;
2. Basculer le Bluetooth à distance en mode commande;
3. Effectuer quelques commandes (par exemple, lire le numéro de série du périphérique distant);
4. Basculer le bluetooth distant vers le mode de données;
5. Envoyer des données à l'appareil;

6. Lit un octet de réponse (ReadByte() à partir de la classe SerialPort);

   L'appareil fonctionne bien et répond immédiatement et tout va bien pendant que je cours mon application en mode débogage via Visual Studio.

Mais lorsque je tente de l'exécuter directement (sans visual studio et adebugger attatched - mais toujours compilé avec l'option "Mise au point") i obtenir une exception de délai d'attente à l'étape 6.

Le bug est entièrement reproductible (pas de timeout dans Visual Studio, et à chaque fois sans cela).

Est-ce que quelqu'un a une idée qui pourrait causer un tel comportement?

Voici le code de l'étape 6

private byte[] ReadResponse() { 

     try { 
      int bytes2Read = 6; 
      do { 
       this.buffer.Append((byte)ReadByte()); // <- there the timeout occurs 

       if (this.buffer.Length == 6) { // header receiver 
        // bytes 2 and 3 contain message length 
        bytes2Read = this.buffer[2] + (this.buffer[3] << 8); 
       } 
      } while (this.buffer.Length < bytes2Read); 

      return this.buffer.ToArray(); 
     } finally { 
      this.buffer.Clear(); 
     } 
    } 

Le procédé se trouve dans la classe qui dérive de la classe SerialPort.

Answer 1

Un dépassement de délai est un comportement normal pour le SerialPort. Cela empêche votre application de caler.

Vous devriez pouvoir modifier la propriété ReadTimeout pour augmenter le délai d'attente.

http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.readtimeout.aspx

Answer 2

sonne comme un problème de synchronisation. En mode débogage, les lignes de programme sont plus lentes que sans débogueur connecté. Il doit y avoir un problème de synchronisation

Answer 3

Lorsque vous effectuez le débogage, vous accordez beaucoup de temps au pilote de port pour recevoir un octet. Le temporisateur de délai ne commence pas à s'exécuter tant que vous n'avez pas passé l'appel ReadByte(), le pilote a probablement déjà reçu l'octet pour que ReadByte() renvoie immédiatement. Cela n'arrive pas lorsque vous courez à pleine vitesse.

Augmentez la valeur de la propriété ReadTimeout. Envisagez également d'utiliser l'événement DataReceived à la place.

Answer 4

Il semble y avoir un bug dans certains ports COM virtuels avec des délais d'attente immédiatement après une écriture. Vous pouvez partiellement contourner le problème en insérant un délai après l'écriture (essayez 10-20 millisecondes), mais je n'ai pas encore trouvé une bonne solution.

Here is discussion on the bug in an ethernet-> RS232 virtual com port