Domanda

Ho scritto del codice C # che controlla se un dispositivo è presente su qualsiasi SerialPort inviando un comando sulla porta e aspettando una risposta. Quando ho appena impostato la velocità della porta, apro la porta, ottengo il flusso seriale e inizio l'elaborazione, funziona il 100% delle volte. Tuttavia, alcuni dei nostri dispositivi funzionano a velocità diverse e sto provando a cercare un dispositivo a varie velocità per negoziare automaticamente una connessione e rilevare la presenza del dispositivo.

Quando faccio tutto questo in un singolo thread non ci sono problemi. Tuttavia, il timeout di 3 secondi a dieci velocità è di 30 secondi per porta seriale e potrebbero essercene diversi. Da qui il desiderio di sondare tutte le porte contemporaneamente.

A volte funziona. A volte Bluescreens Vista. Quando uso i thread per sondare tutte le porte contemporaneamente, quasi sempre bluescreens. Quando forzo tutto in un thread, non succede mai.

Un adattatore Prolific PL-2303 USB-seriale è in uso con driver x64.

@Vinko - grazie per il consiglio sulla lettura di minidump.

Per quanto ne so, il nocciolo del problema è che avviando una nuova operazione di I / O asincrona da un thread diverso è possibile dare un significato completamente nuovo a I / I sovrapposti O, inducendo una condizione di gara all'interno del pilota. Poiché il driver viene eseguito in modalità kernel, BLAM!

Epilogo

Ad eccezione del calcio d'inizio, non usare BeginXxx al di fuori del gestore di callback e non chiamare BeginXxx fino a quando non hai chiamato EndXxx, perché indurrai una condizione di competizione nel codice del driver che gira in modalità kernel.

Postscript

Ho scoperto che questo vale anche per i flussi di socket.

È stato utile?

Soluzione

Avendo scritto i driver di Windows per uno di questi tipi di dispositivi una volta, il mio consiglio sarebbe di non perdere tempo con WinDbg cercando di dimostrare ciò che già sai, ovvero che il driver che stai utilizzando è difettoso.

Se riesci a trovare un driver più aggiornato dal PL2302, allora provalo, ma la mia raccomandazione è che se devi usare adattatori seriali USB, quelli basati su FTDI sono i migliori. (Sono non quello per cui ho scritto i driver, o ...)

Altri suggerimenti

Puoi anche disabilitare " Riavvio automatico " in Proprietà del sistema \ Avanzate \ Avvio e ripristino \ Impostazioni. Una volta disabilitato, puoi vedere BSOD e cercare il messaggio di errore, ad es. IRQL_LESS_OR_EQUAL, cercando quel nome di errore, in genere è possibile restringere il campo all'origine del problema.

A proposito, al giorno d'oggi non molti notebook sono dotati di porte seriali, quindi è necessario utilizzare il convertitore USB-seriale? In tal caso, il driver potrebbe essere stato un problema all'inizio, poiché la maggior parte dei produttori ha scritto il driver della porta seriale come driver virtuale.

BSOD di solito significa driver difettosi.

Che tipo di porte HW usi? Ho avuto BSOD con driver SiLabs CP21xx da USB a convertitori seriali.

Esistono driver FTDI stabili in x64 vista e win7. Secondo, la persona che ha detto di usare solo chipset FTDI.

La maggior parte dei dongle da seriale a usb a basso costo nei negozi vicino a me (Toronto, Canada) sembrano essere chip FTDI. Non è mai sulla scatola, quindi ne compro uno e, se va bene, vado a comprarne uno pieno.

W

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top