Comunicazione porta seriale: polling porta seriale vs utilizzo evento DataReceived porta seriale

Question

Sto solo rivedendo un po 'di codice che ho scritto per comunicare con la porta seriale in C # su CF2.0. Non sto usando l'evento DataReceived poiché non è affidabile. MSDN afferma che:

  

L'evento DataReceived non lo è   garantito da rilanciare per ogni byte   ricevuto. Utilizzare la proprietà BytesToRead   per determinare a quanti dati vengono lasciati   essere letto nel buffer.

Eseguo il polling della porta con read () e ho un delegato che elabora i dati quando vengono letti. Ho anche letto da qualche parte che "il polling è male" (nessuna spiegazione fornita).

Qualche idea sul perché il polling potrebbe essere negativo? a parte le consuete precauzioni di threading - Ho un thread separato (thread in background) che esegue il polling della porta, il thread viene chiuso dopo la lettura dei dati, tutto testato e funziona bene.

Answer 1

Nel modo in cui l'ho letto, potresti ottenere un evento per più byte, anziché un evento per byte. Mi aspetterei comunque di ricevere un evento quando i dati sono pronti e non averlo " salta " alcuni byte interamente.

Ho sempre usato questo evento e non ho avuto problemi con esso.

Answer 2

La saggezza convenzionale dice che "il polling è negativo" perché spesso finisce per essere un processo associato alla CPU. Se si utilizza invece l'I / O di blocco, la CPU è disponibile per altri processi fino a quando si verifica l'evento.

Detto questo, di solito è possibile impostare le cose in modo che un sondaggio attenda un (breve) timeout prima di tornare quando non ci sono personaggi disponibili. Se viene scelto un timeout adatto, il semplice ciclo di polling consuma molto meno tempo della CPU e anche altri processi vengono eseguiti.

Non ho usato affatto le porte seriali da C #, ma ho intenzione di rischiare che il significato della documentazione

  

L'evento DataReceived non è garantito per essere generato per ogni byte ricevuto. Uso   la proprietà BytesToRead per determinare la quantità di dati che devono essere letti nel buffer.

è che non puoi aspettarti di ottenere un evento per personaggio. In alcune circostanze potrebbe consegnare l'evento con più di un personaggio disponibile. Recupera semplicemente tutti i personaggi disponibili nel gestore dell'evento e tutto andrà bene.

Modifica: Effettuare una chiamata di blocco su un thread del lettore potrebbe essere la risposta migliore in assoluto. Non è polling di per sé poiché il thread è bloccato fino all'arrivo dei caratteri. Potrebbe essere necessario ottimizzare le dimensioni del buffer e alcune impostazioni della porta seriale se è necessario elaborare i dati così come arrivano anziché in blocchi di dimensioni fisse.

Answer 3

Sono abbastanza sicuro che il codice del driver della porta seriale sottostante sia guidato dall'interruzione, anche quando si utilizza la chiamata di lettura bloccata.