C# de série du problème de port - trop simple à l'échec, mais

Assurez-vous que vous êtes à l'ouverture du port de droite, à l'aide de paramètres corrects. Voici un exemple de comment vous pouvez le configurer:

serial = new SerialPort();

serial.ReadBufferSize = 8192;
serial.WriteBufferSize = 128;

serial.PortName = "COM1";
serial.BaudRate = 115200;
serial.Parity = Parity.None;
serial.StopBits = StopBits.One;

//attach handlers
//(appears to be broken in some Mono versions?)
serial.DataReceived += SerialPort_DataReceived;
serial.Disposed += SerialPort_Disposed;

serial.Open();

Je recommande l'open source RealTerm terminal, il dispose d'un riche ensemble de fonctionnalités et peut vous aider à déboguer. Essayez d'écrire un octet manuellement à l'aide de ce logiciel, et si cela fonctionne, alors le problème est dans votre programme. Autrement, cela pourrait être un problème de pilote (mais plus probablement il ne l'est pas).

[Modifier]

Appel SerialPort.ReadLine est en fait censé bloquer le thread jusqu'à ce que SerialPort.De retour à la ligne est reçu. Aussi ReadChar et ReadByte va s'accrocher jusqu'à ce qu'au moins un octet est reçu. Vous devez vous assurer que vous êtes en train de recevoir des caractères de l'autre côté, et vous ne serez pas les recevoir si votre application est bloquée et ne peut pas envoyer de l'espace.

Depuis je n'ai jamais utilisé l'Unité, je ne suis pas sûr de savoir comment Update est appelé, mais je suis en espérant qu'il a tiré sur un thread de premier plan à intervalles réguliers (sinon, votre application ne serait pas de gel).

L'exemple que vous avez lié (Arduino et de l'Unité exemple) montre que l'Arduino envoie les données en permanence, et c'est pourquoi leur Update méthode est constamment à la réception de données (pas de caractère d'espace doit être envoyé vers le périphérique). Si ils débranchez le périphérique, leur application se bloque tout aussi bien.

Bien, peut-être pas, parce que dans .NET 1.1, la valeur par défaut pour ReadTimeout n'était pas infini, comme il est .NET 2.0.

Donc, ce que vous pouvez faire est:

un. Définir la ReadTimeout de la propriété à une valeur raisonnable. Par défaut .NET 2.0 est InfiniteTimeout, qui ne répondent pas à vos besoins. Inconvénients: méthode de mise à jour va quand même s'accrocher un moment sur chaque appel, mais pas à l'infini.

b. Quelqu'un a dit que les événements ne sont pas mises en MONO SerialPort, donc je suppose que l'aide DataReceived seulement n'est pas une option.

c. Déplacez votre l'envoi de la logique à la Update méthode également, de sorte que vous n'avez pas de lire des données à tous, jusqu'à ce qu'il est temps de le lire:

private volatile bool _shouldCommunicate = false;
void Update ()
{
  if (_shouldCommunicate) //this is a flag you set in "OnGui"
  {
     try {
       stream.Write(" ");
       Debug.Log(stream.ReadLine());
     } catch (Exception e){
       Debug.Log("Error reading input "+e.ToString());
     }
  }
}

void OnGUI() //simple GUI
{
   if (GUI.Button (new Rect(10,10,100,20), "Send"))
      _shouldCommunicate = true;
}

Noter que, si votre appareil n'est pas de l'envoi des données, il permet également de bloquer à stream.ReadLine(), donc assurez-vous que votre ReadTimeout est défini à une valeur raisonnable. Vous voudrez aussi pour arrêter l'envoi à un certain point, mais je vous laisse à vous.

d. Envoyer de l'espace dans OnGui comme vous le faites maintenant, mais toujours vérifier s'il existe des données dans votre mémoire tampon avant de le lire:

void Update () { //called about 60 times/second
 try {
   //call our new method
   Debug.Log(ReadLineNonBlocking());
 } catch (Exception e){
  Debug.Log("Error reading input "+e.ToString());
 }
}

private StringBuilder sb = new StringBuilder();
string ReadLineNonBlocking()
{
    int len = stream.BytesToRead;
    if (len == 0)
        return "";

    //read the buffer
    byte[] buffer = new byte[len];
    stream.Read(buffer, 0, len);
    sb.Append(ASCIIEncoding.ASCII.GetString(buffer));

    //got EOL?
    if (sb.Length < 2 ||
        sb[sb.Length-2] != '\r' ||
        sb[sb.Length-1] != '\n')
        return ""; 

    //if we are here, we got both EOL chars
    string entireLine = sb.ToString();
    sb.Length = 0;
    return entireLine;
 }

Avertissement: ceci est directement hors de ma tête, pas testé, donc il peut y avoir quelques erreurs de syntaxe qui, je suis sûr que vous allez gérer.

OriginalL'auteur Groo

Peut-être que votre problème est la configuration du port série. Il est important non seulement pour vérifier la vitesse de transmission ou d'Arrêt. Aussi, vous devez configurer le signal DTR, RTS, poignée de main, tout. C'est aussi une cause importante peut-être un autre programme moches, les valeurs et la configuration doit être explicitement défini à chaque démarrage ou de certains paramètres de la connexion ancienne vous des ennuis.

Aussi peut-être de prendre un coup d'oeil dans l'un de ces outils:

• com0com
• Serial Port Monitor

Ils peuvent vous aider à talon de votre interface série ou de prendre un regard plus profond dans la connexion. Aussi peut-être essayer d'en parler à votre série de l'appareil en utilisant HyperTerminal ou tout autre outil qui est prouvée à travailler.

OriginalL'auteur Oliver

Ne pas mélanger les données de l'événement et le blocage de la lecture. Qu'attendez-vous de se produire si les données arrivent? Que la lecture de la méthode et de l'événement devrait obtenir les mêmes données reçues?

Vous devriez aussi lire sur le sujet:

• CTS: http://en.wikipedia.org/wiki/RS-232_RTS/CTS#RTS.2FCTS_handshaking
• DTR: http://en.wikipedia.org/wiki/Data_Terminal_Ready

Petit port série tutoriel décrivant tous les états: http://www.wcscnet.com/Tutorials/SerialComm/Page1.htm

OriginalL'auteur jgauffin