EVT_SERCX2_PIO_TRANSMIT_DRAIN_FIFO funzione di callback (sercx.h)
La EvtSerCx2PioTransmitDrainFifo funzione di callback degli eventi viene chiamata dalla versione 2 dell'estensione del framework seriale (SerCx2) per svuotare la trasmissione FIFO nell'hardware del controller seriale.
Sintassi
EVT_SERCX2_PIO_TRANSMIT_DRAIN_FIFO EvtSercx2PioTransmitDrainFifo;
void EvtSercx2PioTransmitDrainFifo(
[in] SERCX2PIOTRANSMIT PioTransmit
)
{...}
Parametri
[in] PioTransmit
Handle SERCX2PIOTRANSMIT a un oggetto di trasmissione PIO. Il driver del controller seriale precedentemente chiamato il metodo SerCx2PioTransmitCreate per creare questo oggetto.
Valore restituito
Nessuno
Osservazioni
Il driver del controller seriale può, come opzione, implementare questa funzione. Se il driver implementa questa funzione, deve implementare anche il EvtSerCx2PioTransmitCancelDrainFifo e EvtSerCx2PioTransmitPurgeFifo funzioni di callback degli eventi. Un driver che implementa queste funzioni li registra nel SerCx2PioTransmitCreate chiamata che crea l'oggetto di trasmissione PIO.
SerCx2 chiama la funzione EvtSerCx2PioTransmitDrainFifo, se implementata, per svuotare la trasmissione FIFO nell'hardware del controller seriale alla fine di una transazione di trasmissione PIO. Questa funzione assicura che tutti i byte di dati che rimangono nella trasmissione FIFO vengano trasmessi al dispositivo periferico connesso serialmente. Dopo la trasmissione dell'ultimo byte da FIFO, la funzione EvtSerCx2PioTransmitDrainFifo chiama il metodo SerCx2PioTransmitDrainFifoComplete per notificare SerCx2.
Se il driver del controller seriale implementa una funzione EvtSerCx2PioTransmitDrainFifo, SerCx2 non completa una richiesta di scrittura in sospeso (IRP_MJ_WRITE) finché il driver non chiama SerCx2PioTransmitDrainFifoComplete.
Se il controller seriale ha un fifo hardware (o un meccanismo di buffering simile) per contenere i dati di trasmissione, il driver deve implementare una funzione EvtSerCx2PioTransmitDrainFifo. In caso contrario, SerCx2 non è in grado di confermare che la trasmissione FIFO è stata svuotata prima del completamento della richiesta di scrittura in sospeso. SerCx2 completa invece questa richiesta dopo che l'ultimo byte nel buffer di scrittura viene scritto nel FIFO di trasmissione. Non vi può essere alcuna garanzia che i dati scritti nella trasmissione FIFO verranno trasmessi senza un ritardo significativo. Tutti i dati che rimangono nel FIFO dopo il completamento della richiesta di scrittura potrebbero andare persi prima che possano essere trasmessi al dispositivo periferico connesso serialmente. Questa perdita di dati imprevista in una richiesta di scrittura completata correttamente può creare problemi di affidabilità per il driver periferico.
Ad esempio, un driver periferico potrebbe inviare richieste di scrittura a una porta seriale a cui è connesso un dispositivo periferico. Fino a quando non vengono completate tutte le richieste di scrittura in sospeso, questo driver dovrebbe ritardare l'invio di un IOCTL per modificare la velocità in baud con cui la porta seriale trasmette i dati. Tuttavia, se non viene implementata alcuna funzione EvtSerCx2PioTransmitDrainFifo, una richiesta di scrittura per trasmettere 100 byte di dati potrebbe essere completata mentre 50 byte di dati rimangono ancora nel FIFO di trasmissione. Se il driver periferico invia quindi un IOCTL per impostare una nuova velocità baud, alcuni dei byte rimanenti nella FIFO potrebbero essere trasmessi alla nuova velocità baud, causando un errore.
Analogamente, se una richiesta di scrittura per trasmettere 100 byte di dati viene completata mentre 50 byte di dati rimangono ancora nella trasmissione FIFO e il controller seriale esce D0 per entrare in uno stato del dispositivo a basso consumo prima che i byte rimanenti nel FIFO possano essere trasmessi, il driver periferico non saprà che questi byte andranno persi.
Per altre informazioni, vedere SerCx2 PIO-Transmit Transactions.
Esempi
Per definire un EvtSerCx2PioTransmitDrainFifo funzione di callback, è prima necessario fornire una dichiarazione di funzione che identifica il tipo di funzione di callback che si sta definendo. Windows fornisce un set di tipi di funzione di callback per i driver. La dichiarazione di una funzione usando i tipi di funzione di callback consente di
Ad esempio, per definire un EvtSerCx2PioTransmitDrainFifo funzione di callback denominata MyPioTransmitDrainFifo, usare il tipo di funzione EVT_SERCX2_PIO_TRANSMIT_DRAIN_FIFO, come illustrato in questo esempio di codice:
EVT_SERCX2_PIO_TRANSMIT_DRAIN_FIFO MyPioTransmitDrainFifo;
Implementare quindi la funzione di callback come segue:
_Use_decl_annotations_
VOID
MyPioTransmitDrainFifo(
SERCX2PIOTRANSMIT PioTransmit
)
{...}
Il tipo di funzione EVT_SERCX2_PIO_TRANSMIT_DRAIN_FIFO è definito nel file di intestazione Sercx.h. Per identificare in modo più accurato gli errori quando si eseguono gli strumenti di analisi del codice, assicurarsi di aggiungere l'annotazione Use_decl_annotations alla definizione della funzione. L'annotazione Use_decl_annotations assicura che vengano utilizzate le annotazioni applicate al tipo di funzione EVT_SERCX2_PIO_TRANSMIT_DRAIN_FIFO nel file di intestazione. Per altre informazioni sui requisiti per le dichiarazioni di funzione, vedere Dichiarazione di funzioni tramite i tipi di ruolo della funzione per i driver KMDF. Per altre informazioni su Use_decl_annotations, vedere l'annotazione del comportamento della funzione.
Fabbisogno
| Requisito | Valore |
|---|---|
| client minimo supportato | Disponibile a partire da Windows 8.1. |
| piattaforma di destinazione | Desktop |
| intestazione |
sercx.h |
| IRQL | Chiamato in IRQL <= DISPATCH_LEVEL. |