.net - visual - windows serialport




Qu'est-ce qui pourrait affecter les valeurs renvoyées par Serialport.Read() (3)

Avez-vous vérifié les paramètres pour le nombre de bits de données, les bits d'arrêt et la parité?

Le bit de parité est une sorte de mécanisme de détection d'erreur. Par exemple: Si vous envoyez en utilisant 7 bits de données et un bit de parité, le huitième bit sera utilisé pour détecter les erreurs d'inversion de bit. Si le récepteur attend 8 bits de données et aucun bit de parité, le résultat sera brouillé.

J'ai écrit une application simple en C # 2.0 en utilisant la classe .Net Framework 2.0 Serialport pour communiquer avec une carte contrôleur via COM1.

Un problème est survenu récemment lorsque les octets renvoyés par la méthode Read étaient incorrects. Il a retourné la bonne quantité d'octets, seules les valeurs étaient incorrectes. Une application similaire écrite en Delphi a quand même renvoyé les valeurs correctes.

J'ai utilisé Portmon pour enregistrer l'activité sur le port série des deux applications, comparé les deux journaux et là où certains paramètres (apparemment) mineurs différents et j'ai essayé d'imiter l'application Delphi aussi étroitement que possible, mais en vain.

Alors, qu'est-ce qui pourrait affecter les valeurs d'octets renvoyées par la méthode Read?

La plupart des paramètres entre les deux applications sont identiques.

Voici une liste des lignes qui différaient dans le journal de Portmon:

Delphi App:

IOCTL_SERIAL_SET_CHAR Sériel0 SUCCESS EOF: dc ERR: 0 BRK: 0 EVT: 0 XON: 11 XOFF: 13
IOCTL_SERIAL_SET_HANDFLOW Sérial0 SUCCESS Shake: 0 Remplacer: 0 XonLimit: 256 XoffLimit: 256 IOCTL_SERIAL_SET_TIMEOUTS Sérial0 SUCCESS RI: -1 RM: 100 RC: 1000 WM: 100 WC: 1000 IOCTL_SERIAL_SET_WAIT_MASK Sériel0 SUCCESS Masque: RXCHAR RXFLAG TXEMPTY CTS DSR RLSD BRK ERR RING RX80FULL

C # App:

IOCTL_SERIAL_SET_CHAR Sériel0 SUCCESS EOF: 1a ERR: 0 BRK: 0 EVT: 1a XON: 11 XOFF: 13 IOCTL_SERIAL_SET_HANDFLOW Sérial0 SUCCESS Shake: 0 Remplacer: 0 XonLimit: 1024 XoffLimit: 1024 IOCTL_SERIAL_SET_TIMEOUTS Sérial0 SUCCESS RI: -1 RM: -1 RC: 1000 WM: 0 WC: 1000 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Masque: RXCHAR RXFLAG CTS DSR RLSD BRK ERR RING

METTRE À JOUR:

Les bons octets retournés étaient: 91, 1, 1, 3, 48, 48, 50, 69, 66, 51, 70, 55, 52, 93 (14 octets). La dernière valeur étant une somme de contrôle simple.

Les valeurs incorrectes renvoyées étaient: 91, 241, 254, 252, 242, 146, 42, 201, 51, 70, 55, 52, 93 (13 octets).

Comme vous pouvez le voir le premier et les cinq derniers octets retournés correspondent.

L'événement ErrorReceived indique qu'une erreur de cadrage s'est produite, ce qui peut expliquer les valeurs incorrectes. Mais la question est de savoir pourquoi SerialPort rencontrerait une erreur de cadrage lorsque l'application Delphi ne le fait pas?


Malheureusement, vous n'avez pas mentionné exactement le type de différences que vous avez. Est-ce un caractère occasionnel qui est différent ou est-ce que toutes vos données entrantes sont brouillées? Notez que les caractères lus via la fonction SerialPort.Read peuvent être modifiés par le système en raison du paramètre de la propriété SerialPort.Encoding . Ce paramètre affecte l'interprétation du texte entrant, car il s'agissait d'un texte en ASCII, Unicode, UTF8 ou tout autre schéma de codage que Windows utilise pour la conversion des «octets bruts» en «texte lisible».


Si vous lisez un tableau d'octets (ex: SerialPort.Read), vous devriez obtenir exactement les octets que vous voyez sur PortMon.

Si vous convertissez en caractères (SerialPort.ReadLine ou SerialPort.ReadChar) alors les données seront codées en utilisant l'encodage actuel (propriété SerialPort.Encoding), ce qui explique les différences que vous voyez.

Si vous voulez voir des caractères avec les mêmes valeurs binaires que les octets sur le fil, un bon codage à utiliser est Latin-1 comme décrit dans ce message .

Exemple:

SerialPort.Encoding = Encoding.GetEncoding("Latin1")




serial-port