Problemi nell'accesso alle porte COM in C#

Ciao a tutti,

Sto iniziando ad imparare C# (con Visual Studio Express 2005) e mi imbatto continuamente nello stesso problema. Per fare un confronto, ho scritto codice simile anche in VB, ma il risultato è lo stesso.

Il seguente codice è un programma semplice che apre la porta seriale, inizializza l'adattatore CANUSB e quindi visualizza le stringhe ricevute in una casella di testo. Ho collegato il pulsante 'Apri' all'inizializzazione dell'adattatore CANUSB, in modo che la registrazione inizi immediatamente. Allo stesso modo, ho collegato il pulsante 'Chiudi' per indicare all'adattatore CANUSB di interrompere la registrazione.

Il problema è che il mio programma si blocca quando provo a chiuderlo.
Premendo il pulsante, non succede ogni volta, ma circa una volta su due. Se rimuovo la riga `serialPort1.Write('C');` durante la chiusura, il programma impiega più tempo a bloccarsi, ma comunque si verifica dopo 5-10 aperture/chiusure. Il passaggio da un evento DataReceived a un timer evita il problema, ma non sono sicuro che questa sia la soluzione al mio problema o che lo renda solo meno evidente.

Dato che sono ancora all'inizio per quanto riguarda le conoscenze di programmazione, sono ovviamente un po' confuso e vorrei sentire qualche opinione a riguardo. Sarebbero utili anche esempi in VB6, VB 2005 o C# 2005. È interessante notare che questo problema si verifica solo con il mio codice. Posso collegare e disconnettere can tool tutte le volte che voglio, ma non succede nulla.

Sarei grato per qualsiasi consiglio.

Saluti,
Dirk.


using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.IO.Ports;

namespace CANTest10
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

private void btnOpen_Click(object sender, EventArgs e)
{
if (serialPort1.IsOpen)
{
btnOpen.Text = 'Open';
//reset CAN adapter and close COM port
serialPort1.Write('C ');
serialPort1.Close();
}
else
{
btnOpen.Text = 'Close';
// set COM port parameters and open COM port
serialPort1.PortName = 'COM4';
serialPort1.BaudRate = 115200;
serialPort1.DataBits = 8;
serialPort1.StopBits = StopBits.One;
serialPort1.Parity = Parity.None;
serialPort1.Open();
//init CAN adapter to read all CAN traffic off CAN bus
serialPort1.Write('C S3 Z0 O ');
}
}

private void serialPort1_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
//if new data arrives in serial port buffer use invoke to display on Windows form
this.Invoke(new EventHandler(ProcessNewData));
}

private void ProcessNewData(object sender, EventArgs e)
{
//read all data received off buffer and display in text box
this.textBox1.Text = serialPort1.ReadExisting();

}
}
}

Ciao,

Secondo me, il problema si verifica esattamente durante la chiamata a `serialPort1.Close()`. Potresti provare a verificarlo con il debugger. Imposta un punto di interruzione sulla chiamata a `serialPort1.Close()` e poi esegui passo dopo passo. Il programma si blocca qui o solo quando 'elimini' l'oggetto `SerialPort`?

È un peccato che il tuo codice non contenga le parti rilevanti. È importante capire come e dove, ad esempio, crei e distruggi l'oggetto `serialPort`.

Il problema è spesso legato alla gestione delle risorse. Con linguaggi interpretati e linguaggi basati sull'esecuzione a runtime come C#/Java, non si può programmare nello stesso modo in cui si fa con C++. In particolare, dovresti utilizzare ampiamente il pattern 'Dispose' (vedi le pagine Microsoft). Finché continuerai a lavorare come in VB, C++ o altri linguaggi compilati, avrai ancora molti problemi di questo tipo.

Innanzitutto, è necessario capire esattamente dove si verifica il 'blocco'. A mio parere, la scatola non si 'aggancia' effettivamente, ma semplicemente ci vuole troppo tempo perché il programma continui l'esecuzione. Tuttavia, per quanto riguarda la gestione delle porte, troverai sicuramente molte informazioni utili online.

Certo, il problema del blocco durante la chiusura della porta seriale con `Close()` si verifica anche in C++. Il comportamento del driver seriale è, diciamo, tutt'altro che piacevole. Quindi, se la causa del problema è proprio la chiamata a `Close()`, dovrai trovare tu stesso una soluzione alternativa. Se il problema è dovuto a una gestione errata delle risorse, potrai risolverlo nel tuo codice.

Sono al lavoro sul mio dispositivo di diagnostica, sia a causa di un problema con la connessione ('hänger'), ma anche per via dell'impostazione della velocità di trasmissione dati che non funziona correttamente e delle limitate possibilità di rilevamento della frequenza dei bit direttamente sull'hardware. Questo crea meno problemi rispetto all'utilizzo delle funzionalità fornite da Windows (API, OCX), tuttavia richiede un driver del dispositivo per accedere all'hardware.

Saluti,
Jens.

Piccola sezione dalla pagina di aiuto relativa alla classe SerialPort, metodo Close:

The best practice for any application is to wait for some amount of time after calling the Close method before attempting to call the Open method, as the port may not be closed instantly.

Se quindi il problema fosse effettivamente causato dalla funzione 'Close', allora...
a) dover convivere con questo oppure...
b) come devo risolvere io stesso il problema.

Buona fortuna.
Jens.

Ciao Jens,

Grazie per la risposta. Purtroppo, ho appena iniziato a lavorare con C#. Sono stato contento di essere riuscito a comunicare con l'adattatore CANUSB utilizzando Visual Studio Express 2005 e i suoi oggetti trascinabili. Ma sono sollevato nel sapere che non sono l'unico ad avere questi problemi. Non mi sono ancora preoccupato della gestione delle risorse, ho sempre dato per scontato che l'IDE avrebbe inserito il codice appropriato.

Seguirò il tuo consiglio e proverò a capire, passo dopo passo, in modalità debug dove esattamente si blocca il programma. È sicuramente sempre quando si preme 'Chiudi', indipendentemente da quanto tempo la porta è rimasta aperta prima. Da quello che ho visto finora, sembra accadere più frequentemente quando ci sono molti dati nel buffer o quando il buffer viene interrogato molto spesso nell'unità di tempo.

Saluti,
Dirk.

Ciao Dirk,

Probabilamente si tratta di una chiamata a 'close' sull'oggetto seriale.

Volevo anche io riscrivere il mio strumento di diagnostica per farlo funzionare con C# (attualmente è basato su C++/MFC). Il motivo è che devo collegare un nuovo protocollo specifico del produttore per la mia Mercedes, dato che finora ho implementato solo protocolli VAG (in pratica, VAG1551 o VAS...).

Ich hatte mir erhofft, dass mit der .Net-Runtime nun endlich einmal ein vernuenftiger, funktionierender Zugriff auf den ser. Port moeglich sei. Meine Untersuchungen habe dann schnell gezeigt, dass auch die .Net-Runtime auf dem alten WinAPI-Gelumpe und aufsetzt und damit auch den Serial.sys-Treiber vom Windows verwendet. Dumm gelaufen, denn bis zu 200ms nach Umschalten der Bitrate kann ich mir nicht erlauben. Per questo motivo, ho deciso di non effettuare la conversione in C#, dato che non ci sarebbero vantaggi reali (ma solo numerosi svantaggi legati al garbage collector).

Saluti,
Jens.

Hai scelto un posto interessante dove vivere, soprattutto per chi ha la passione delle automobili!

@candev
Credo che, leggendo tra le righe, ho bisogno della stessa cosa di te. Voglio inviare dati relativamente semplici (idealmente con VB) a una velocità molto bassa (5 baud) e poi, immediatamente dopo (cioè aspettando meno di 200 ms), continuare a trasmettere e ricevere a una velocità diversa. Se hai una soluzione, per favore, pubblicala qui o mandami un'email.

saluti
Markus.

Ah, quindi anche qui bisogna fare un'inizializzazione lenta secondo lo standard ISO9141 .

Mi dispiace, ma in base a esperienze precedenti con fornitori di prodotti commerciali, non posso fornire né il codice sorgente né il driver del dispositivo. Vi prego di capire che non ho intenzione di dedicare anni allo sviluppo di qualcosa e poi vedere altri guadagnarci. Penso che capiate e che vi succederebbe la stessa cosa.

Per darvi un'idea del lavoro necessario: a quanto ne so, sono l'unico ad aver implementato il rilevamento della velocità di trasmissione (bit rate) nel mio strumento diagnostico per PC, e questo avviene misurando direttamente la lunghezza dei bit. Tutti gli altri devono utilizzare hardware esterno (che includa un timer con funzionalità di input capture) oppure 'indovinare' la velocità di trasmissione provando diverse opzioni. Solo l'implementazione del rilevamento della velocità di trasmissione mi ha richiesto 2 anni, ed è stata tutt'altro che piacevole...

Saluti,
Jens.

Il problema dell'inizializzazione lenta/veloce può essere risolto più facilmente con un po' di creatività e una corretta interpretazione di velocità di trasmissione (baud rate) che, a prima vista, potrebbero sembrare inadatte.

Nelle comunicazioni a velocità molto basse (ad esempio, Fastinit con 25 ms di segnale basso e 25 ms di segnale alto), molte interfacce seriali hanno semplicemente il problema di non riuscire a passare da una velocità di 5 baud a una velocità più alta, come 10400 baud o superiore, nel tempo richiesto, oppure l'interfaccia viene riavviata in modo imprevisto.

Se si riflette più a fondo sul problema e, eventualmente, si programma direttamente l'RTS/CTS dell'interfaccia stessa, esistono anche soluzioni per questo.

Saluti, Mike.

Gerade beim Fastinit (25ms low/25ms high) haben viele serielle Schnittstellen einfach das Problem, die Umschaltung von 5Bd auf die 10400Bd oder was auch immer anschließend benötigt wird nicht in der erforderlichen Zeit hinzubekommen oder die Schnittstelle wird ungewollt neu initialisiert.

Ciao Mike,

Devo per forza capirlo, o no? Almeno nel mio caso è diverso .
Con la modalità Slow-Init, ho riscontrato problemi con il cambio di bitrate (presupponendo che la piattaforma sia un PC), mentre con la modalità Fast-Init non ho problemi (trascurando casi particolari come la modifica del baud rate in combinazione con aggiornamenti software e alcune 'porte di servizio' presenti nei dispositivi di controllo utilizzati durante lo sviluppo).

Saluti,
Jens (con solo W202.078).

Ciao Jens,

Con il sistema SlowInit, noto problemi legati al livello del segnale richiesto (nei modelli Volkswagen/Audi), mentre con il sistema FastInit (Mercedes-Benz), invece, si verificano problemi relativi al pattern di risveglio.

Tuttavia, di solito non utilizzo piattaforme per personal computer, ma schede controllate da microcontrollori con chip Infineon C164, ATMEL + PHILIPS SJA o Freescale HCS12.

Saluti, Mike.

P.S.: (211.226)