Compartir a través de

SerCx2 Custom-Receive Transacciones

  • Artículo

Algunos hardware del controlador serie pueden implementar un mecanismo de transferencia de datos que no sea PIO o DMA del sistema para leer datos de un controlador serie. Un controlador de controlador serie puede admitir transacciones de recepción personalizadas para que este mecanismo de transferencia de datos esté disponible para ser utilizado por SerCx2.

Para iniciar una transacción de recepción personalizada, SerCx2 llama a la función de devolución de llamada de eventos EvtSerCx2CustomReceiveTransactionStart del controlador y proporciona como parámetros la solicitud de lectura (IRP_MJ_READ) y una descripción del búfer de lectura para la transacción. En esta llamada, la función inicia la transacción y devuelve. A continuación, el controlador es responsable de finalizar la transacción y completar la solicitud de lectura.

Creación del objeto de recepción personalizada

Antes de que SerCx2 pueda llamar a cualquiera de las funciones EvtSerCx2CustomReceiveTransactionXxx**del controlador serie, el controlador debe llamar al método SerCx2CustomReceiveTransactionCreate para registrar estas funciones con SerCx2. Este método acepta, como parámetro de entrada, un puntero a una estructura SERCX2_CUSTOM_RECEIVE_TRANSACTION_CONFIG que contiene punteros a las funciones EvtSerCx2CustomReceiveTransactionXxx** del controlador.

El controlador debe implementar las dos funciones siguientes:

Como opción, el controlador puede implementar cualquiera o todas las tres funciones siguientes:

El método SerCx2CustomReceiveTransactionCreate crea un objeto de recepción personalizado y proporciona al controlador de llamada un identificador SERCX2CUSTOMRECEIVETRANSACTION a este objeto. Las funciones EvtSerCx2CustomReceiveTransactionXxx** del controlador toman este identificador como primer parámetro. Los siguientes métodos SerCx2 toman este identificador como primer parámetro:

Inicialización y limpieza de hardware

Es posible que algunos controladores de controlador de serie necesiten inicializar el hardware del controlador serie al inicio de una transacción de recepción personalizada o para limpiar el estado de hardware del controlador serie al final de la transacción.

Si un controlador implementa una función de devolución de llamada de eventos EvtSerCx2CustomReceiveTransactionInitialize , SerCx2 llama a esta función para inicializar el controlador serie antes de iniciar la transacción. Si se implementa, la función EvtSerCx2CustomReceiveTransactionInitialize debe llamar al método SerCx2CustomReceiveTransactionInitializeComplete para informar a SerCx2 cuando el controlador termine de inicializar el controlador serie.

Si el controlador implementa una función de devolución de llamada de evento EvtSerCx2CustomReceiveTransactionCleanup , SerCx2 llama a esta función para limpiar el estado de hardware una vez finalizada la transacción. Si se implementa, la función EvtSerCx2CustomReceiveTransactionInitialize debe llamar al método SerCx2CustomReceiveTransactionCleanupComplete para informar a SerCx2 cuando el controlador termine de limpiar el controlador serie.

Notificaciones de datos nuevos

Como opción, el controlador de controlador serie puede implementar una función de devolución de llamada de eventos EvtSerCx2CustomReceiveTransactionEnableNewDataNotification . Si se implementa, SerCx2 usa esta función para administrar eficazmente los tiempos de espera de intervalo que se producen durante el control de solicitudes de lectura que se procesan como transacciones de recepción personalizadas.

Se produce un tiempo de espera de intervalo si el intervalo entre dos bytes sucesivos recibidos por el controlador serie supera un tiempo máximo especificado por el cliente. Después de que un controlador periférico envíe una solicitud de lectura a SerCx2, no se puede producir un tiempo de espera de intervalo hasta que se reciba al menos un byte de datos desde el dispositivo periférico conectado en serie. La hora entre la llegada de una solicitud de lectura y la recepción del primer byte de datos del dispositivo periférico puede ser significativamente mayor que el tiempo necesario para recibir el resto de los datos de la solicitud de lectura después de recibir el primer byte. Para obtener más información, consulte SERIAL_TIMEOUTS.

SerCx2 llama a la función EvtSerCx2CustomReceiveTransactionEnableNewDataNotification , si se implementa, para habilitar una notificación de datos nuevo. Si esta notificación está habilitada y el controlador serie recibe uno o varios bytes de nuevos datos del dispositivo periférico, o ya tiene datos en su FIFO de recepción, el controlador del controlador serie debe llamar al método SerCx2CustomReceiveTransactionNewDataNotification para notificar a SerCx2.

Para detectar un posible tiempo de espera de intervalo, SerCx2 llama periódicamente a la función de devolución de llamada de eventos EvtSerCx2CustomReceiveTransactionQueryProgress para comprobar si se recibieron datos durante el intervalo anterior. La forma en que SerCx2 detecta la recepción del primer byte de datos depende de si el controlador del controlador serie implementa una función EvtSerCx2CustomReceiveTransactionEnableNewDataNotification . Si se implementa esta función, SerCx2 llama a la función para habilitar una notificación de datos nuevos y el controlador notifica cuando se recibe el primer byte de datos. De lo contrario, SerCx2 llama periódicamente a la función EvtSerCx2CustomReceiveTransactionQueryProgress para detectar la recepción del primer byte y es posible que tenga que reactivar periódicamente el procesador para realizar estas llamadas. Por lo tanto, un controlador que implementa una función EvtSerCx2CustomReceiveTransactionEnableNewDataNotification puede reducir el consumo de energía al no requerir que el procesador se active con tanta frecuencia.

SerCx2 no cancela explícitamente una notificación pendiente de datos nuevos para una transacción de recepción personalizada. Sin embargo, es posible que el controlador del controlador serie tenga que cancelar implícitamente una notificación de datos nuevo si la notificación está habilitada y el controlador debe completar la solicitud de lectura asociada por uno de los siguientes motivos:

  • La solicitud de lectura agota el tiempo de espera o se cancela.
  • El controlador serie está a punto de salir del estado de alimentación del dispositivo D0 para entrar en un estado de bajo consumo.

Normalmente, el controlador llama a un método como WdfRequestComplete para completar la solicitud. El controlador nunca debe llamar a SerCx2CustomReceiveTransactionNewDataNotification una vez completada la solicitud.

Acceso al objeto de solicitud

Para iniciar una transacción de recepción personalizada, SerCx2 llama a la función EvtSerCx2CustomReceiveTransactionStart del controlador y pasa la solicitud de lectura asociada (encapsulada en un identificador de objeto WDFREQUEST) a esta función como parámetro. El controlador es responsable de llamar a un método como WdfRequestComplete para completar esta solicitud cuando finalice la transacción. A menos que la solicitud se pueda completar inmediatamente, antes de que se devuelva la función EvtSerCx2CustomReceiveTransactionStart , el controlador debe llamar a un método como WdfRequestMarkCancelableEx para marcar la solicitud como cancelable.

El controlador del controlador serie no debe usar un método como WdfRequestRetrieveOutputBuffer para acceder al búfer de datos en la solicitud de lectura. En su lugar, el controlador debe usar los valores de parámetro Mdl, Offset y Length pasados a la función EvtSerCx2CustomReceiveTransactionStart para tener acceso a este búfer.

Durante una transacción de recepción personalizada, es posible que el controlador necesite almacenar información sobre la transacción en un contexto asociado al objeto de solicitud. Si es así, la función de devolución de llamada de eventos EvtDriverDeviceAdd del controlador puede llamar al método WdfDeviceInitSetRequestAttributes para establecer los atributos que se van a usar para los objetos de solicitud. Estos atributos incluyen el nombre y el tamaño de asignación que se van a usar para contextos de solicitud. Los atributos de solicitud especificados en esta llamada deben coincidir con los atributos de solicitud que el controlador especifica en la llamada al método SerCx2InitializeDevice . Estos atributos se especifican en el miembro RequestAttributes de la estructura SERCX2_CONFIG que el controlador pasa a SerCx2InitializeDevice. Para obtener más información, consulte SERCX2_CONFIG.

Para una solicitud de lectura que el controlador de serie recibe al principio de una transacción de recepción personalizada, el contexto de solicitud asignado por el marco de trabajo del controlador no está inicializado. El controlador debe, como procedimiento recomendado, llamar a la rutina RtlZeroMemory para inicializar este contexto de solicitud en todos los ceros.