SerialPort et SerialDataReceivedEventHandler

Bonjour à toutes et à tous,

Électronicien de formation et débutant en C#, j'aurai aimé réaliser comme première application une communication de type série entre le PC et une carte d'acquisition.

Si la communication entre la carte et l'hyperterminal se déroule sans problème, ainsi que l'envoi de caractères via l'application programmée en C#, je rencontre des problèmes pour réceptionner les informations fournies par la carte. En lisant plusieurs sites, j'ai essayé de suivre leur méthode en créant une fonction de gestion des caractères reçu (le pooling est-il possible en C# ?). Malheureusement malgré l'envoi de caractères, le programme ne passe jamais dans cette fonction de réception. Pour simplifier les choses, la carte n'envoie qu'un seul caractère 0x30, à la cadence de 2x seconde. J'ai essayé par curiosité d'envoyer un NULL à la fin de chaque envoi, mais cela ne change rien

La carte d'acquisition communique via un port COM virtuel, qui est en réalité un port USB, via un driver fourni par le fabriquant de la carte. Donc, je n'ai ni DTR ou RTS physique.

Le code que j'ai essayé est le suivant, en espérant que vous pourrez m'aider :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

using System; using System.IO.Ports; using System.Text;     namespace SerialPortExample { class SerialPortProgram { // Create the serial port with basic settings private SerialPort port = new SerialPort("COM4", 9600, Parity.None, 8, StopBits.One);   [STAThread] static void Main(string[] args) { new SerialPortProgram(); }   private SerialPortProgram() { port.ReceivedBytesThreshold = 1; port.Handshake = Handshake.None; port.DtrEnable = false; port.RtsEnable = false; // Instatiate this class Console.WriteLine ("Incoming Data:"); // Begin communications port.Open();   port.DataReceived += new SerialDataReceivedEventHandler(port_DataReceived);   Console.WriteLine(port.ReadBufferSize);   System.Console.ReadKey(); port.Close(); }   private void port_DataReceived (object sender, System.IO.Ports.SerialDataReceivedEventArgs e) { // Show all the incoming data in the port's buffer Console.WriteLine("Caractère reçu"); Console.WriteLine(port.ReadExisting()); } } }

---

Merci d'avance.

Sébastien.

dans ce code je ne vois aucun envoie de données

et en général les matériels répondent suite à une question
cette question est normalisée, avec des caractères de début et de fin généralement


il est aussi préférable d'envoyer des octets plutot que de laisser la classe serialport faire la transcription entre un string et les octets

L'envoi a été testé mais a été retiré du code.

Si, pour "les matériels", vous parlez de la carte d'acquisition, dans ce cas-ci ce n'est pas le cas. Elle envoie les trames, récepteur présent ou non, et fait office de "timer".
Tout comme on pourrait programmer un microcontroleur qui enverrait une série d'informations utiles toutes les x ms à l'aide d'un printf par exemple.

La valeur de port.BytesToRead reste en permanence à zéro. Ne doit-elle pas s'incrémenter à chaque byte reçu ? Je suppose que c'est sa valeur qui va déclencher le lancement de la fonction SerialDataReceivedEventHandler, non ?
Tout envoi d'une trame doit-il se finir par un zéro de fin de chaîne ou cela n'est-il pas nécessaire ?

J'ai ajouté la fonction suivante, qui aurait pu m'indiquer si une erreur est survenue, mais le programme ne passe jamais dedans.

Code:

---

1 2 3 4

private void port_ErrorReceived(object sender, SerialErrorReceivedEventArgs e) { Console.WriteLine("Erreur"); }

---

avec ajout dans le main de :

Code:

---

1 2	port.ErrorReceived += new SerialErrorReceivedEventHandler(port_ErrorReceived);

---

Après avoir cherché pendant plusieurs jours, j'ai trouvé la solution à ce problème de communication.
Malgré qu'il n'y ait pas de DTR et de RTS physique, il est nécessaire de les activer pour que cela fonctionne. Peut-être que le driver du convertisseur fait en sorte de gérer ces deux lignes, même si elles n'existent pas.

Cela évitera peut-être à d'autres de chercher inutilement.
Problème résolu.