EVT_SERCX2_PIO_TRANSMIT_DRAIN_FIFO funzione di callback (sercx.h)

Articolo
02/26/2024

La funzione di callback dell'evento EvtSerCx2PioTransmitDrainFifo 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 in precedenza denominato 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 anche implementare le funzioni di callback eventi EvtSerCx2PioTransmitCancelDrainFifo e EvtSerCx2PioTransmitPurgeFifo . Un driver che implementa queste funzioni li registra nella chiamata SerCx2PioTransmitCreate 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 dal 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 chiama SerCx2PioTransmitDrainFifoComplete.

Se il controller seriale ha un meccanismo fiFO hardware (o meccanismo di buffering simile) per contenere i dati di trasmissione, il driver deve implementare una funzione EvtSerCx2PioTransmitDrainFifo . In caso contrario, SerCx2 non può confermare che la trasmissione FIFO sia stata svuotata prima del completamento della richiesta di scrittura in sospeso. SerCx2 completa invece questa richiesta dopo l'ultimo byte nel buffer di scrittura viene scritta nella trasmissione FIFO. Non è possibile garantire che i dati scritti nella trasmissione FIFO vengano trasmessi senza un ritardo significativo. Tutti i dati che rimangono nel FIFO dopo il completamento della richiesta di scrittura potrebbero essere persi prima che possa essere trasmesso 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 deve ritardare l'invio di un IOCTL per modificare la frequenza di baud in corrispondenza della quale 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 nella trasmissione FIFO. Se il driver periferico invia quindi un IOCTL per impostare una nuova frequenza baud, alcuni dei byte rimanenti nel FIFO potrebbero essere trasmessi alla nuova velocità di 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 nel FIFO di trasmissione e il controller seriale chiude D0 per immettere uno stato di dispositivo a bassa potenza prima che i byte rimanenti nel FIFO possano essere trasmessi, il driver periferico non saprà che questi byte vengono persi.

Per altre informazioni, vedere SerCx2 PIO-Transmit Transazioni.

Esempio

Per definire una funzione di callback EvtSerCx2PioTransmitDrainFifo , è prima necessario specificare 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 callback consente l'analisi del codice per i driver, il verifica driver statico (SDV) e altri strumenti di verifica trovano errori ed è un requisito per la scrittura di driver per il sistema operativo Windows.

Ad esempio, per definire una funzione di callback EvtSerCx2PioTransmitDrainFifo denominata MyPioTransmitDrainFifo, usare il tipo di funzione EVT_SERCX2_PIO_TRANSMIT_DRAIN_FIFO , come illustrato nell'esempio di codice seguente:

EVT_SERCX2_PIO_TRANSMIT_DRAIN_FIFO  MyPioTransmitDrainFifo;

Implementare quindi la funzione di callback come indicato di seguito:

_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 durante l'esecuzione degli strumenti di analisi del codice, assicurarsi di aggiungere l'annotazione Use_decl_annotations alla definizione della funzione. L'annotazione Use_decl_annotations garantisce che vengano usate 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 tipi di ruolo per i driver KMDF. Per altre informazioni su Use_decl_annotations, vedere Annotazione del comportamento della funzione.

Requisiti

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.