Administración de energía de sensores

Un equipo móvil normalmente incorpora dispositivos sensores como un sensor de luz ambiental (ALS), un acelerómetro 3D, un girómetro 3D, o bien un magnetómetro 3D. Cuando un dispositivo de sensor no está siendo utilizado por el sistema operativo o por una aplicación, el software de administración de energía puede cambiar el dispositivo a un modo de bajo consumo de energía para reducir el consumo de energía. En un PC que admite el modelo moderno de energía en espera, se anticipa que los dispositivos del sensor cambien a un modo de bajo consumo poco después de que el PC entre en el modo de espera moderno y permanezcan en este modo hasta que el PC salga de este modo.

En este artículo se explica cómo implementar la administración de energía para dispositivos de sensor. Además, en este artículo se describe la administración de energía del microcontrolador de sensor opcional (también denominado centro de fusión del sensor o el MCU del sensor) y los dispositivos de sensor agregados. (por ejemplo, un dispositivo de sensor de brújula se puede implementar agregando un acelerómetro, un girómetro y un magnetómetro bajo el control de un microcontrolador del sensor. El microcontrolador expone estos dispositivos de sensor a Windows como un único dispositivo de sensor lógico).

Sensores y microcontrolador de sensores

El hardware del sensor es fundamental para la experiencia móvil moderna. A partir de Windows 10, hay disponible una infraestructura de sistema enriquecida para exponer y administrar varios dispositivos de sensor. Esta infraestructura simplifica el desarrollo de aplicaciones que incorporan información del sensor y que admiten escenarios críticos de Windows integrados, como la rotación automática de pantalla o el cambio del brillo de la pantalla en función de la luz ambiente.

Durante el tiempo de ejecución del sistema, los sensores individuales se pueden apagar cuando no están en uso. Los requisitos para usar un dispositivo sensor determinado se comunican al dispositivo y sus controladores a través de la API de sensor de Windows. Cuando el sistema operativo o cualquier aplicación no usa un dispositivo sensor, el controlador del sensor puede apagarlo o el firmware que se ejecuta en el microcontrolador del sensor.

Una vez desactivada la pantalla del sistema y la plataforma de hardware entra en espera moderna, todos los dispositivos de sensor y los microcontroladores de sensor opcionales que aún no están en estados de bajo consumo deben entrar en sus estados de baja potencia, en espera en unos segundos para que la plataforma en su conjunto pueda entrar en un estado de baja potencia. Sin embargo, los controladores de sensor no supervisan directamente las transiciones hacia y desde el modo de espera moderno para determinar cuándo se deben encender y apagar los dispositivos del sensor. En su lugar, el controlador del sensor debe permitir que el dispositivo reciba energía cuando uno o varios clientes usen activamente el dispositivo, que pueden ser aplicaciones o componentes del sistema operativo. El controlador debe quitar la energía del dispositivo cuando ningún cliente use el dispositivo.

Cuando la extensión de clase de sensor solicita al controlador que inicie las lecturas de muestra del sensor de informes, llama al método de devolución de llamada EvtSensorStart del controlador del sensor. Cuando la extensión de clase de sensor solicita al controlador que detenga las lecturas de muestra del sensor de informes, llama al método de devolución de llamada EvtSensorStop del controlador. Para obtener más información, consulte Acerca de los eventos del controlador del sensor.

Una vez que el equipo entra en modo de espera moderno y todos los dispositivos del sensor entran en estados de baja energía, el consumo total de energía de todo el hardware del sensor del sistema debe ser inferior a un milivatio. Los dispositivos de sensor y el microcontrolador de sensores opcionales pueden entrar en un estado de espera de baja potencia específico del hardware del sensor. Alternativamente, el raíl de alimentación de hardware para los dispositivos sensores y el microcontrolador de sensor opcional se puede desactivar bajo el control de los controladores del sensor y/o el firmware ACPI del sistema.

A partir de Windows 10, se proporciona soporte para un conjunto limitado de opciones de conectividad de hardware de sensor al silicio principal o sistema en un chip (SoC) en una plataforma con modo de espera moderno. En las secciones siguientes se detallan las configuraciones de hardware y software admitidas, así como sus comportamientos de administración de energía tanto durante el modo de espera moderno como cuando se usa activamente la plataforma.

Modos de administración de energía

Windows espera que cada dispositivo del sensor o el microcontrolador del sensor tengan tres modos de energía de dispositivo (activo, inactivo y en espera), además de un modo opcional sin energía de cero vatios. En la tabla siguiente se describen los modos de energía de un dispositivo sensor y un microcontrolador de sensor opcional. La tabla distingue entre un modo inactivo en el que se usa el hardware del sensor, pero está inactivo actualmente, y un modo inactivo en el que no se usa el hardware del sensor.

Modo	Descripción	Consumo medio de energía	Latencia de salida a activa	Mecanismo de transición
Activo	El microcontrolador del sensor o el dispositivo sensor está proporcionando o procesando activamente los cambios en el entorno.	< 100 miliwatts	No disponible	No disponible
Inactivo (en uso)	Uno o más aplicaciones usan el dispositivo de sensor o el microcontrolador del sensor y está esperando proporcionar el siguiente conjunto de información del sensor al procesador principal.	< 50 miliwatts	Específico del sensor	Hardware autónomo
Inactivo (no en uso)	Ninguna aplicación usa el dispositivo del sensor o el microcontrolador del sensor. Se mantienen los datos de calibración para el sensor o el microcontrolador del sensor.	< 5 miliwatts	Específico del sensor	Comandos de dispositivo de interfaz humana (HID) o mensajes de Sensor Framework que describen el uso actual de los dispositivos de sensor.
En espera	Ninguna aplicación usa el dispositivo del sensor o el microcontrolador del sensor. Se mantienen los datos de calibración para el sensor o el microcontrolador del sensor. El microcontrolador del sensor o el sensor no realiza ninguna acción adicional hasta que lo solicite el software que se ejecuta en el procesador principal.	< 1 milliwatt (para todos los sensores del sistema)	< 10 milisegundos	Varias opciones: Comando HIDI2C SET_POWER (Dormir) Mensaje privado del controlador del fabricante Línea GPIO de SoC al hardware del sensor
Sin energía	Se corta la alimentación al dispositivo sensor y/o al microcontrolador del sensor, y se pierde todo el contexto de hardware.	0 miliwatts	< 100 milisegundos	La entidad externa quita la energía o la aplica a través del firmware ACPI en respuesta a IRP con energía D3.

Nota:

En la tabla anterior, el término espera hace referencia a un modo de energía del dispositivo que es distinto del modo de espera moderno, que es un estado de energía para toda la plataforma.

Mecanismos de administración de energía de software

La gestión de energía en tiempo real para dispositivos de sensor y el microcontrolador del sensor está principalmente determinada por su uso. Como regla general, se espera que el controlador del sensor y el hardware coloquen un sensor en el modo de energía inactiva cuando el sistema operativo o una aplicación no lo usen. La Plataforma de sensores de Windows proporciona información sobre el número de clientes de aplicación o sistema operativo conectados a un sensor determinado, así como los requisitos para el ciclo de trabajo o la velocidad de datos del sensor. El controlador del sensor o hardware usa esta información para realizar la transición sin problemas del dispositivo del sensor al modo de alimentación inactiva durante los momentos en que el sistema se está ejecutando y la pantalla está activada.

Una vez apagada la pantalla del sistema y cuando la plataforma entre en modo de espera moderno, Windows esperará que todos los sensores y microcontroladores del sensor entren en modo de espera o sin energía.

La elección de un mecanismo de administración de energía mediante software que se usará para dispositivos de sensor y el microcontrolador de sensor opcional depende de cómo el controlador del dispositivo presenta el hardware del sensor a Windows y cómo el hardware del sensor está conectado físicamente al silicio del SoC o del núcleo. Windows admite dos métodos para exponer y conectar dispositivos de sensor. Un método usa el controlador de clase HID del sensor integrado a través de una conexión I2C, donde el controlador HIDI2C integrado transfiere información HID a través de la conexión I2C. El otro requiere un controlador de terceros que implemente la interfaz del controlador del sensor universal y llame a los métodos de la tabla SensorscxFunctions.

Las dos opciones para conectarse a un sensor o microcontrolador de sensor se comparan en la tabla siguiente. La selección de una de las dos opciones para conectarse al hardware del sensor dicta los mecanismos de administración de energía de software necesarios para realizar la transición del hardware del sensor al modo en espera o apagado.

Opción de conexión	Conexión de bus	Se requiere el controlador del sensor	Proveedor de controladores	Comentarios
HIDI2C	El hardware del sensor se conecta directamente al SoC o al núcleo de silicio a través de I2C.	Controlador de clase HID del sensor + controlador de clase HID a través de I2C	Microsoft. Componente de bandeja de entrada a partir de Windows 8.	Ventajas y desventajas
Controlador de sensor de terceros	El hardware del sensor se conecta directamente al SoC o núcleo de silicio a través de I2C o UART.	Controlador de terceros que implementa SENSOR_CONTROLLER_CONFIG	Proveedor de dispositivos de sensor.	Ventajas y desventajas

HIDI2C

Para la opción HIDI2C, el microcontrolador opcional del sensor está físicamente conectado al silicio del núcleo o al SoC a través de un bus I2C. El microcontrolador expone varias colecciones HID de nivel superior, una para cada dispositivo de sensor lógico. Por ejemplo, un sensor de compás se puede exponer a través de HID como un dispositivo lógico que agrupa el acelerómetro, el girómetro y el magnetómetro detrás del microcontrolador. Esto es lo más fácil de implementar en términos de conectividad y software, ya que no requiere software de terceros para el dispositivo sensor.

La pila HIDI2C de Windows es similar a la de los controladores táctiles y digitalizadores de lápiz en que se admiten dos mecanismos de administración de energía de software: un comando HID en banda y una transición en tiempo de ejecución al estado D3.

Comando HID en banda

SET_POWER(Sleep) Se envía al dispositivo una vez que se desactive la pantalla y la plataforma entre en modo de espera moderno. Este comando puede realizar la transición del dispositivo al modo de energía en espera.

SET_POWER(On) Se envía al dispositivo cuando la plataforma exista en modo de espera moderno y la pantalla se vuelva a activar.

Transición en tiempo de ejecución al estado D3 para la pila de dispositivos del sensor HID

D3 IRP Una solicitud IRP_MJ_POWER que se envía a la pila de controladores del dispositivo inmediatamente después del comando SET_POWER(Sleep). Esto indica al dispositivo que escriba el estado de alimentación del dispositivo D3. Como parte de la transición a D3, el firmware ACPI del sistema podría ejecutar métodos de control para cambiar el dispositivo al modo de espera o apagado.

D0 IRP Solicitud de IRP_MJ_POWER que se envía a la pila de controladores para el dispositivo cuando la plataforma exista en el modo de espera moderno y la pantalla se encuentre activada. Esto indica al dispositivo que escriba el estado de alimentación del dispositivo D0. Si es necesario, el firmware ACPI del sistema puede ejecutar métodos de control para volver al modo inactivo (no en uso).

Controlador de sensor de terceros

Para el controlador de sensor de terceros, el microcontrolador del sensor está conectado físicamente al silicio principal a través de un bus I2C o UART.

El proveedor del dispositivo de sensor debe proporcionar un controlador User-Mode Driver Framework (UMDF) que implemente SENSOR_CONTROLLER_CONFIG interfaz. El controlador UMDF se comunica con el dispositivo sensor a través de I2C o UART. Esto se puede implementar varias veces: una vez para cada sensor que está detrás del microcontrolador del sensor. El controlador de sensor de terceros es responsable de crear y coordinar toda la administración de energía.

Se espera que los controladores de sensor del fabricante se compilen mediante Windows Driver Frameworks (WDF) y se basen en el controlador de muestra Adxl354acc. El controlador debe usar una cola administrada por energía y configurar el estado de inactividad D3 a través de una llamada al método IWDFDevice3::AssignS0IdleSettingsEx. El controlador debe usar los métodos IWDFDevice2::StopIdle e IWDFDevice2::ResumeIdle para indicar a WDF cuando el dispositivo está inactivo o activo. El controlador también debe habilitar D3cold estableciendo el miembro ExcludeD3Cold de la estructura WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS en WdfFalse. Habilitar D3cold permite que la plataforma quite la energía del dispositivo del sensor después de que se quede inactiva y entre en el estado D3.

Como procedimiento recomendado, coloque código específico del dispositivo en el controlador y coloque código específico de la plataforma en el firmware ACPI para habilitar el uso de nuevo de bajo costo del código de controlador en varias plataformas.

Especificación de los requisitos de modo de espera moderno

Los requisitos del controlador de sensor de un tercero para la administración de energía son una función del consumo de energía en modo de espera del hardware del sensor.

Los controladores de sensores de terceros deben iniciar una transición a D3 cuando el dispositivo del sensor esté listo para entrar en modo de espera o apagado, incluso si el dispositivo es capaz de usar un mecanismo de comunicaciones en banda para cambiar a un modo de alimentación que consume menos de un miliwatt. El motivo de este requisito es que muchos controladores de bus en Windows realizan un seguimiento del estado de energía del dispositivo de sus dispositivos de punto de conexión y se apagan solo cuando todos los dispositivos de punto de conexión se han apagado. Para algunos diseños de SoC y buses de conexión (especialmente Universal Serial Bus (USB)), todos los dispositivos de punto de conexión y el controlador host deben estar en D3 para que el SoC entre en el estado de energía más bajo durante el modo de espera moderno. La incapacidad de entrar en el estado de energía más bajo puede impedir fácilmente que un sistema cumpla los requisitos modernos de espera para la duración de la batería.

Si el hardware del sensor tiene un consumo de energía en espera de menos de un miliwatt para todo el hardware del sensor controlado, el controlador del sensor debería cambiar automáticamente el dispositivo al modo en espera cuando los sensores (o todos los sensores del microcontrolador) ya no estén en uso.

Si el hardware del sensor tiene un consumo de energía en espera superior a un miliwatt, el controlador del sensor debe realizar una transición D3 y permitir que los métodos de control ACPI quiten la energía del dispositivo del sensor. El controlador del sensor debe guardar todo el estado necesario del dispositivo del sensor para que la alimentación se pueda quitar del dispositivo durante D3. El proveedor de hardware del sensor debe colaborar estrechamente con el integrador del sistema para asegurarse de que el hardware y el controlador del sensor realizan la transición D3 de forma confiable y rápida.

Importante

El controlador debe guardar todo el contexto del dispositivo del sensor antes de que el dispositivo entre en D3 y debe restaurar todo el contexto del dispositivo del sensor después de que el dispositivo entre en D0.

Poco después de entrar en modo de espera moderno, Windows detiene automáticamente el uso de todos los sensores al deshabilitar el uso de sensores por el sistema operativo (por ejemplo, luz ambiente y rotación) y suspendiendo las aplicaciones. El controlador del sensor debe agregar el estado de todo el hardware del sensor controlado y cambiar este hardware al modo de alimentación del dispositivo en espera cuando todos los sensores ya no estén en uso.

El mecanismo para cambiar el dispositivo del sensor al modo de espera se puede diseñar para usar la comunicación en banda a través del bus que conecta el dispositivo al SoC. Por ejemplo, se puede enviar un comando propietario en modo de espera a través del bus al hardware del sensor. O el hardware del sensor podría estar conectado a una línea GPIO que cambie el dispositivo al modo en espera y fuera de este.

Nota:

Cuando se usa una línea GPIO para cambiar el dispositivo al modo en espera, el controlador del sensor debe realizar la transición de la pila de controladores a D3 y permitir que los métodos de control ACPI para el dispositivo (por ejemplo, _PS3) establezcan la línea GPIO en el estado necesario para colocar el hardware en modo de espera. Este esquema permite que el controlador del sensor se escriba de forma independiente de la plataforma: la línea GPIO específica, los requisitos de tiempo y otra información específica de la plataforma se codifican en el firmware ACPI proporcionado por el integrador del sistema y no en el controlador específico del dispositivo.

Salir de los requisitos de modo de espera moderno

Cuando la plataforma sale del modo de espera moderno, el controlador del sensor debe volver a pasar el hardware del sensor al modo inactivo (no en uso). A medida que se reanudan los servicios del sistema, Windows solicitará el uso de sensores, como la rotación y la luz ambiente, que son necesarias para realizar funciones del sistema. A medida que se reanudan las aplicaciones, podrían solicitar información del sensor. Si el hardware del sensor requiere un mensaje en banda para devolver el dispositivo al modo inactivo, el controlador del dispositivo debe enviar este mensaje tan pronto como se envíe la primera solicitud de información del sensor. Si el hardware del sensor requiere una línea GPIO para indicar al dispositivo que vuelva al estado inactivo, el controlador debe usar esta línea GPIO para realizar una transición a D0 tan pronto como se proporcione la primera solicitud de información del sensor. En este caso, los métodos de control ACPI (por ejemplo, _PS0) deberían controlar la línea GPIO según sea necesario para comenzar la transición. Por último, si el hardware del sensor requería anteriormente una transición al modo eliminado de energía porque el consumo de energía en modo de espera supera un miliwatt, el controlador del sensor debe realizar una transición a D0 y permitir que los métodos de control ACPI restauren la energía en el dispositivo.

Configuraciones de energía de hardware admitidas

La configuración de administración de energía de hardware que se usará para un dispositivo sensor depende del consumo de energía del hardware del sensor en modo de espera y de si un microcontrolador de sensor opcional administra el dispositivo.

Potencia en modo de espera < un milivatio

Si el consumo de energía de un dispositivo sensor en modo de espera no supera un miliwatio, no es necesario que el diseñador de plataformas conecte el hardware del sensor a un raíl de alimentación que los métodos de control ACPI pueden activar y desactivar. Uno de los siguientes mecanismos se usa para cambiar el sensor al modo de alimentación en espera:

• Un comando HID SET_POWER(Sleep).
• Una línea GPIO del SoC.
• Un comando propietario enviado al hardware del sensor por el controlador de sensor de terceros.

Si la plataforma incluye un microcontrolador de sensor, el chip de microcontrolador puede contener uno o varios dispositivos de sensor integrados o podría estar conectado a uno o varios dispositivos de sensor externos. En cualquier caso, estos dispositivos de sensor son, desde el punto de vista del software, oculto detrás del microcontrolador e invisible para Windows. Si un microcontrolador de sensor y sus dispositivos de sensor agregados consumen menos de un miliwatt cuando el microcontrolador y el hardware del sensor están en modo de alimentación en espera, el diseñador de plataformas no es necesario para conectar el microcontrolador o el hardware del sensor a un raíl de alimentación que los métodos de control ACPI pueden activar y desactivar. El microcontrolador del sensor usa uno de los siguientes mecanismos para realizar la transición y todos los sensores que administra hacia y desde el modo en espera:

• Un comando HIDI2C SET_POWER (o similar) enviado a través del bus de comunicaciones.
• Una línea GPIO del SoC.

Si el sensor requiriese una línea GPIO desde el SoC para iniciar transiciones hacia y desde el modo en espera, el firmware de la plataforma deberá proporcionar un objeto _PS3 y un objeto _PS0 en el espacio de nombres ACPI en el dispositivo de hardware del sensor. El firmware ACPI también debe incluir una región de operación GPIO que describa la línea GPIO del SoC al hardware del sensor. El método de control _PS3 alterna la línea GPIO para cambiar el dispositivo al modo en espera y el método de control _PS0 alterna la línea GPIO para cambiar el hardware del sensor al modo inactivo.

En el diagrama de bloques siguiente se muestran las opciones de administración de energía de un sensor independiente que consume menos de un miliwatt en modo de energía en espera.

Una opción es usar la pila HIDI2C de Windows, como se muestra en el lado izquierdo del diagrama anterior. En este caso, la transición del sensor al modo en espera de energía se podrá iniciar mediante un comando en banda HID SET_POWER(Sleep) o mediante un D3 de IRP que controle el controlador ACPI ejecutando el método de control _PS3 para el sensor.

La otra opción es usar un controlador de sensor de terceros, como se muestra en el lado derecho del diagrama anterior. El controlador de sensor del fabricante puede iniciar la transición al modo de espera de energía mediante un comando propietario en banda o enviando un IRP D3 que el controlador ACPI controlará ejecutando el método de control _PS3 para el sensor.

El diseñador de plataformas puede elegir cualquiera de los mecanismos independientemente de si los dispositivos del sensor están integrados o externos al chip de microcontrolador.

Potencia en modo de espera > un milivatio

Si la plataforma incluyese hardware del sensor o un microcontrolador de sensor que juntos consumiesen más de un milivatio en modo en espera de energía, el hardware del sensor y el microcontrolador deberán pasarse al modo sin energía cuando el sistema se encuentre en modo de espera moderno. En esta configuración, el sensor, el microcontrolador de sensor opcional y todos los sensores detrás del microcontrolador deben colocarse en un solo raíl de alimentación que esté encendido y apagado bajo el control de una línea GPIO desde el SoC.

Esta configuración requiere que el diseñador de plataformas coloque todo el hardware del sensor en un raíl de alimentación conmutable, controlado por una línea GPIO desde el SoC. Si se requieren varios voltajes de entrada para el hardware del sensor, se pueden usar varios conmutadores, cada uno controlado por la misma línea GPIO. Además del raíl de alimentación conmutable, el firmware ACPI de la plataforma debe definir un recurso de energía en el espacio de nombres. Este recurso de energía describe el hardware del sensor e incluye los métodos _ON y _OFF responsables del uso de una región de operaciones GPIO para alternar la línea GPIO desde el SoC.

El firmware de la plataforma debe incluir una referencia al recurso de energía en cada dispositivo de sensor del espacio de nombres ACPI en el raíl de energía conmutable, incluyendo los objetos _PR0 y _PR3.

En el diagrama de bloques siguiente se muestran las opciones de administración de energía para el hardware del sensor o un microcontrolador de sensor que juntos consumen más de un miliwatt en modo de energía en espera. Las dos opciones consisten en usar la pila HIDI2C de Windows, tal y como se muestra en el lado izquierdo del diagrama, o usar un controlador de sensor del fabricante, tal y como se muestra en el lado derecho.

En la configuración que usa la pila de controladores HIDI2C integrada, como se muestra en el lado izquierdo del diagrama anterior, el controlador HIDI2C inicia una transición D3 después de que la pantalla se apague y la plataforma entre en espera moderna. Cuando el IRP D3 fluye a través del controlador ACPI, el objeto _PR3 se evaluará y Windows desactivará el recurso de energía especificado ejecutando el método _OFF. En caso de que varios sensores compartan el recurso de energía, Windows hará referencia automáticamente a todos los sensores y ejecutará el método _OFF solo después de que todos los sensores hayan entrado en D3.

Si el hardware del sensor usa un controlador de sensor de terceros, como se muestra en el lado derecho del diagrama anterior, el flujo de control es el mismo que antes, salvo que el controlador del sensor es responsable de iniciar la transición a D3.

Una vez que la plataforma se reanuda desde el modo de espera moderno y una aplicación o el sistema operativo solicita el uso del sensor, el controlador pasa a D0. Un IRP D0 fluye a través del controlador ACPI y el objeto _PR0 se evalúa para que el controlador ACPI ejecute el método _ON para el recurso de energía asociado. El método _ON alterna la línea GPIO para activar el raíl de energía conmutable. Si el sistema usa un controlador de sensor de terceros, el controlador debe solicitar un IRP D0 e iniciar una transición a D0 inmediatamente después de que el sistema operativo o una aplicación soliciten los datos del sensor.

Problemas de reactivación

No hay problemas de reactivación para los sensores o el microcontrolador de sensor opcional. Se espera que los dispositivos de sensor estén en modo de espera o apagado durante el modo de espera moderno y no se espera que activen el SoC mientras la plataforma está en espera moderna.

Pruebas y validación

Es fundamental que el diseñador del sistema compruebe que el hardware del sensor entra en modo de espera o de eliminación de energía cuando la pantalla está apagada para el modo de espera moderno. El método usado para probar y validar la administración de energía del dispositivo depende de cómo está conectado el dispositivo del sensor.

Sensor conectado a HIDI2C

En caso de que el sistema use la pila HIDI2C de Windows, el integrador de sistemas deberá ponerse en contacto con el proveedor del controlador del sensor para obtener información sobre cómo comprobar mejor que el controlador realice correctamente la administración de energía. Se recomienda a los proveedores de controladores de sensores usar el rastreo de eventos para Windows (ETW) para todas las decisiones de administración de energía en su controlador de dispositivo y proporcionar documentación de ejemplo a los integradores de sistemas para describir cómo comprobar la operación correcta de administración de energía utilizando los eventos ETW y el Windows Performance Toolkit (WPT).

Controlador de sensor de terceros

Si el sistema usa un controlador de sensor de terceros, el integrador del sistema debe ponerse en contacto con el proveedor del controlador del sensor para obtener información sobre cómo comprobar mejor que el controlador realice correctamente la administración de energía. Se recomienda a los proveedores de controladores de sensores usar el seguimiento de eventos para Windows (ETW) para todas las decisiones de gestión de energía en su controlador de dispositivos y proporcionar documentación de ejemplo a los integradores de sistemas para describir cómo comprobar la operación correcta de gestión de energía mediante los eventos ETW y el Windows Performance Toolkit (WPT).

Si el controlador inicia una transición a D3 cuando ya no se usan todos sus dispositivos de sensor, puede seguir las instrucciones de la lista siguiente para comprobar que esta transición se produce según lo previsto y que un dispositivo sensor vuelve a D0 cuando una aplicación o el sistema operativo necesitan volver a usar el dispositivo.

El método centrado en software usa la instrumentación de Windows para verificar que el IRP D3 pasa por la pila de controladores del dispositivo sensor. El administrador de energía de Windows tiene instrumentación ETW integrada, que incluye instrumentación para detectar IRP Dx (solicitudes de energía del dispositivo). Para ver esta información en modo manual, descargue windows Performance Toolkit e instálelo en el sistema en prueba.

Después de instalar windows Performance Toolkit, siga estas instrucciones para iniciar un seguimiento XPerf en modo de usuario:

1. Abra una ventana de comandos como administrador.

2. Vaya a la carpeta \%ProgramFiles%\Windows Kits\8.0\Windows Performance Toolkit\ .

3. Para iniciar Xperf, ejecute el siguiente comando: xperf.exe -start power_session -on Microsoft-Windows-Kernel-Power

4. Cambie el sistema a modo de espera moderno presionando el botón de encendido.

5. Espera 30 segundos.

6. Cambie el sistema fuera del modo de espera moderno presionando el botón de encendido.

7. Ejecute el siguiente comando para detener el registro de eventos: xperf.exe -stop power_session

8. Convierta el archivo de rastreo binario en formato .csv y en formato legible para humanos: xperf.exe –i \user.etl > power.txt

9. Abra el archivo Power.txt en un editor de texto y busque el identificador de hardware del dispositivo sensor. Busque el Id. de hardware del dispositivo de sensor en la pestaña Detalles de las propiedades del dispositivo en Administrador de dispositivos en Ruta de acceso de instancia de dispositivo. En el ejemplo siguiente, la ruta de acceso de la instancia del dispositivo de sensor es ACPI\MST0731\2&daba3ff&0.

10. El inicio del IRP de D3 del dispositivo de sensor se indica mediante un evento de tipo Microsoft-Windows-Kernel-Power/IRP/Stop que tiene la ruta de acceso de la instancia del dispositivo de sensor y un último valor de evento de 3, que indica que el estado de destino es D3. El siguiente evento de salida del archivo Power.txt muestra el inicio del IRP D3. Los dos últimos valores del parámetro de este evento (que se muestran en el extremo derecho) indican la ruta de acceso de la instancia del dispositivo y el estado de destino.

    Microsoft-Windows-Kernel-Power/Irp/Start, 7605393, "Unknown" (4), 256, 0,,,,, 0x868e2728, 1, 2, 0x85fb56e0, 25, "ACPI\MSFT0731\2&daba3ff&0", 3

11. Este evento debe registrarse cerca del inicio del archivo de salida de Power.txt. El valor 0x868e2728 del parámetro del evento de salida anterior es un puntero a la estructura de IRP para el IRP de D3. Al buscar eventos posteriores en el archivo de seguimiento que tengan este mismo puntero IRP, es posible seguir el progreso del IRP de D3 a medida que fluya a través de la pila de controladores para el dispositivo de sensor.

12. Microsoft-Windows-Kernel-Power/Irp/Start, 7605393, "Unknown" (4),256, 0,,,,, 0x868e2728, 1, 2, 0x85fb56e0, 25, "ACPI\ATML1000\2&daba3ff&0", 3

13. Microsoft-Windows-Kernel-Power/Driver/Start, 7605416, "Unknown" (4), 20, 0,,,,, 0x868e2728, 0x85fb56e0, "\Driver\sensdrv"

14. Microsoft-Windows-Kernel-Power/Driver/Stop, 7605515, "Unknown" (4), 20, 0,,,,, 0x868e2728, 0x85fb56e0

15. Microsoft-Windows-Kernel-Power/Driver/Start, 7605522, "Unknown" (4), 20, 0,,,,, 0x868e2728, 0x85fab6a0, "\Driver\i2cdrv"

16. Microsoft-Windows-Kernel-Power/Driver/Stop, 7608342, "Unknown" (4), 20, 0,,,,, 0x868e2728, 0x85fab6a0

17. Microsoft-Windows-Kernel-Power/Driver/Start, 7608351, "Unknown" (4), 20, 0,,,,, 0x868e2728, 0x857ffb90, "\Driver\ACPI"

18. Microsoft-Windows-Kernel-Power/Driver/Stop, 7608416, "Unknown" (4), 20, 0,,,,, 0x868e2728, 0x857ffb90

19. Microsoft-Windows-Kernel-Power/Driver/Start, 7608424, "Unknown" (4), 20, 0,,,,, 0x868e2728, 0x85fb56e0, "\Driver\sensdrv"

Cuando el controlador ACPI de Windows, Acpi.sys, procesa el IRP D3, Acpi.sys ejecuta el método de control de _PR3 correspondiente. El diseñador de firmware del sistema proporciona este método de control para indicar qué recurso de energía se debe desactivar para que el dispositivo sensor entre en el estado D3. Acpi.sys también ejecuta el método de control _OFF en Power Resource.

Puede usar un proceso similar para comprobar que el dispositivo sensor vuelve a D0 cuando la plataforma sale del modo de espera moderno y la pantalla se activa. Un evento Microsoft-Windows-Kernel-Power/IRP/Start para el dispositivo sensor se registrará con un estado de destino de 0 (que indica D0) inmediatamente después de presionar el botón de encendido para reactivar el sistema y el sistema operativo o una aplicación reanudada solicita datos del sensor.

Lista de comprobación para la gestión de energía de sensores y microcontroladores de sensores

Los integradores de sistemas y los proveedores de dispositivos de sensor deben usar la siguiente lista de comprobación para asegurarse de que su diseño de administración de energía del sistema es compatible con Windows 8 y versiones posteriores.

• Seleccione el hardware del sensor compatible con el controlador HIDI2C integrado y la pila de controladores HIDSensor.
• Seleccione el hardware del sensor que tenga un consumo de energía en espera de menos de un miliwatt.
• Compruebe que el hardware del sensor y el controlador de terceros (si es necesario) admiten la administración de energía inactiva en tiempo de ejecución cuando la pantalla está activada:
  • Los sensores deben apagarse y entrar en D3 automáticamente cuando no los use una aplicación o el sistema operativo.
  • Los sensores deben encenderse y introducir D0 automáticamente cuando una aplicación o el sistema operativo solicitan los datos del sensor.
  • El controlador de sensor de terceros debe implementarse como controlador WDF y puede basarse en el controlador de ejemplo SpbAccelerometer.
  • El sondeo de la información del sensor debe estar limitado y habilitado en el nivel de consumo de energía más bajo posible. Por ejemplo, el sondeo de un sensor analógico debe producirse detrás de un microcontrolador u otro hardware de control de baja potencia, lo que puede interrumpir el SoC cuando los nuevos datos del sensor superan algún valor de detección de umbral. Evite sondear el sensor en un controlador que se ejecute periódicamente en el SoC, algo que podría aumentar significativamente el consumo general de energía del sistema.
• Si el hardware del sensor usa un controlador de terceros:
  • El integrador de sistemas debe comunicarse con el proveedor del dispositivo de sensor para comprender cómo implementar la administración de energía para el hardware del sensor.
  • Si el hardware del sensor consume más de un miliwatt en modo de alimentación en espera, coloque el hardware del sensor en un raíl de alimentación independiente controlado por una línea GPIO desde el SoC. Proporcione referencias al recurso de energía ACPI necesario, a los métodos de control _ON/_OFF, y al recurso de energía que se encuentra bajo el dispositivo del sensor en el espacio de nombres ACPI (como se describe a continuación).
  • Si el hardware del sensor usa una línea GPIO desde el SoC para cambiar el dispositivo al modo de alimentación en espera, asegúrese de que el firmware ACPI del sistema incluye los métodos de control de _PS3 y _PS0 adecuados (como se describe a continuación).
• Si el hardware del sensor incluye un microcontrolador de sensor que tiene dispositivos de sensor conectados detrás de él, el microcontrolador del sensor debe tener una manera de apagar los dispositivos del sensor. Los dispositivos se pueden apagar mediante la comunicación en banda a través del bus que conecta el microcontrolador a los dispositivos o una línea GPIO desde el microcontrolador a los dispositivos.
• Si el hardware del sensor requiere una línea GPIO desde el SoC para cambiar el dispositivo al modo de energía en espera:
  • Asegúrese de que la línea GPIO de SoC cumple los requisitos de nivel y desencadenador establecidos por el proveedor de hardware del sensor.
  • En el espacio de nombres ACPI, describa el pin gpIO de SoC como parte de una región de operación GPIO.
  • Proporcione un método de control _PS3 en el dispositivo de sensor del espacio de nombres ACPI para alternar la señal en la línea GPIO según sea necesario para cambiar el hardware del sensor al modo de espera de energía.
  • Proporcione un método de control _PS0 bajo el dispositivo sensor del espacio de nombres ACPI para alternar la señal en la línea GPIO según sea necesario para cambiar el hardware del sensor al modo inactivo o activo después de que el dispositivo cambie a D0.
• Si el hardware del sensor consume más de un miliwatt en el modo de energía en espera:
  • Coloque todo el hardware del sensor en un raíl de alimentación que se pueda encender y desactivar mediante una línea GPIO desde el SoC. O bien, si la plataforma contiene varios sensores que tienen diferentes requisitos de voltaje de suministro, proporcione rieles independientes que se puedan cambiar de forma independiente.
  • Describir el raíl de alimentación conmutable como un recurso de energía en el espacio de nombres ACPI.
  • En este recurso de energía, proporcione los métodos de control _ON y _OFF que activan y desactivan el raíl de alimentación mediante una línea GPIO que se describe como parte de una región de operación GPIO.
  • En el espacio de nombres ACPI, proporcione _PR3 y _PR0 objetos que designen el recurso de energía para el hardware del sensor.
  • Asegúrese de que los métodos _ON y _OFF incorporen los requisitos de eliminación de rebote o de temporización del hardware del sensor.
• Pruebe y valide la administración de energía en tiempo de ejecución de los dispositivos de sensor en la plataforma. Trabaje estrechamente con el proveedor de hardware del sensor para validar la administración de energía en tiempo de ejecución cuando la pantalla del sistema está activada.
• Pruebe y compruebe que el hardware del sensor entre en modo de espera o sin energía cuando la plataforma entre en modo de espera moderno.
  • Si el hardware del sensor usa las pilas de controladores del sensor HIDI2C + HID incluidas con Windows, consulte Pruebas y validación para obtener más información.
  • Si el hardware del sensor usa un controlador de terceros, póngase en contacto con el proveedor del controlador del sensor para obtener la metodología de prueba recomendada.
  • Si el controlador del sensor realiza una transición a D3 como parte de su entrada al modo en espera o apagado, use el Kit de herramientas de rendimiento de Windows como se describe en Pruebas y validación. Compruebe que el hardware del sensor entra en D3 cuando la plataforma entra en modo de espera moderno, y que el hardware del sensor entra en D0 después de que el sistema salga del modo de espera moderno y se solicite nuevamente la información del sensor.
• Mida el consumo de energía del hardware del sensor en modo de espera o apagado.
• Inicie varias transiciones dentro y fuera del modo de espera moderno y, a continuación, pruebe el funcionamiento de los dispositivos del sensor y las aplicaciones que usan información del sensor cuando la pantalla está activada.