Administración de energía de sensores

Un equipo móvil normalmente incorpora dispositivos de sensor como un sensor de luz ambiente (ALS), acelerómetro 3D, girómetro 3D o magnetómetro 3D. Cuando un dispositivo 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 equipo que admita el modelo moderno de energía en espera, se espera que los dispositivos del sensor cambien a un modo de bajo consumo poco después de que el EQUIPO entre en espera moderno y permanezcan en este modo hasta que el PC salga del modo de espera moderno.

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 enriquecida del sistema 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 con el 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 o el firmware que se ejecuta en el microcontrolador del sensor puede apagarlo.

Después de que la pantalla del sistema se apague y la plataforma de hardware entre 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 como un todo 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 los dispositivos del sensor deben estar encendidos y apagados. 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 puede 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 sensor solicita al controlador que inicie las lecturas de muestras del sensor de informes, llama al método de devolución de llamada EvtSensorStart del controlador del sensor. Cuando la extensión de clase sensor solicita al controlador que detenga las lecturas de muestras 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 espera moderno y todos los dispositivos sensor entran en estados de baja potencia, el consumo total de energía de todo el hardware del sensor del sistema debe ser inferior a un milliwatt. Los dispositivos de sensor y el microcontrolador de sensores opcionales pueden entrar en un estado de espera de bajo consumo específico del hardware del sensor. O bien, el raíl de alimentación de hardware para los dispositivos del sensor y el microcontrolador opcional del sensor se puede desactivar bajo el control de los controladores del sensor o el firmware ACPI del sistema.

A partir de Windows 10, se proporciona compatibilidad con un conjunto limitado de opciones de conectividad de hardware de sensor al silicio principal o sistema en un chip (SoC) en una plataforma moderna en espera. 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 sensor o el microcontrolador del sensor tengan tres modos de alimentación de dispositivo (activo, inactivo y en espera), además de un modo opcional, de cero vatios y apagado de energía. En la tabla siguiente se describen los modos de alimentación 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.

Mode	Descripción	Consumo medio de energía	Latencia de salida a activa	Mecanismo de transición
Activo	El dispositivo de sensor o el microcontrolador del sensor proporciona o procesa activamente los cambios ambientales.	< 100 miliwatts	N/D	N/D
Inactivo (en uso)	Uno o más aplicaciones usan el dispositivo 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 está usando el dispositivo 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 del dispositivo de interfaz humana (HID) o mensajes de Sensor Framework que describen el uso actual de los dispositivos de sensor.
Standby	Ninguna aplicación está usando el dispositivo sensor o el microcontrolador del sensor. Se mantienen los datos de calibración para el sensor o el microcontrolador del sensor. El sensor o microcontrolador del sensor no realiza ninguna otra acción 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(Sleep) Mensaje privado del controlador de terceros Línea GPIO de SoC al hardware del sensor
Se ha quitado energía	La alimentación se quita del dispositivo del sensor o del microcontrolador del sensor y se pierde todo el contexto de hardware.	0 miliwatts	< 100 milisegundos	La entidad externa quita la energía o aplica energía a través del firmware ACPI en respuesta al IRP de alimentación D3.

Nota

En la tabla anterior, el término modo de espera hace referencia a un modo de alimentación de dispositivo 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 administración de energía en tiempo de ejecución para los dispositivos de sensor y el microcontrolador del sensor se controla principalmente si se usan. Como regla general, se espera que el controlador del sensor y el hardware coloquen un sensor en el modo de alimentación 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 tiempos en que el sistema se está ejecutando y la pantalla está activada.

Una vez apagada la pantalla del sistema y la plataforma entra en espera moderna, Windows espera que todos los sensores y microcontroladores del sensor entren en modo de espera o apagado.

La elección de un mecanismo de administración de energía de software que se usará para dispositivos de sensor y el microcontrolador de sensor opcional depende de cómo el controlador del dispositivo expone el hardware del sensor a Windows y cómo el hardware del sensor está conectado físicamente al soC o al silicio principal. 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 de espera o apagado.

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

HIDI2C

Para la opción HIDI2C, el microcontrolador de sensor opcional está conectado físicamente al silicio soC o núcleo 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 brújula se puede exponer a través de HID como un dispositivo de sensor lógico que es una agregación del acelerómetro, el girómetro y los sensores magnetómetros detrás del microcontrolador del sensor. 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 admite 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 desactivada la pantalla y la plataforma entra en espera moderna. Este comando puede realizar la transición del dispositivo al modo de alimentación en espera.

SET_POWER(Activado) Se envía al dispositivo cuando la plataforma existe en espera moderna y la pantalla se vuelve a activar.

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

D3 IRP Solicitud IRP_MJ_POWER que se envía a la pila de controladores para el 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 existe en espera moderna y la pantalla está 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 de terceros se compilan mediante windows Driver Frameworks (WDF) y se basan en el controlador de ejemplo 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 de WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS en WdfFalse. Habilitar D3cold permite que la plataforma quite la energía del dispositivo sensor después de que se quede inactiva y entre en 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 nuevo uso de bajo costo del código de controlador en varias plataformas.

Especificación de los requisitos de espera modernos

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

Los controladores de sensor 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 milliwatt. El motivo de este requisito es que muchos controladores de autobús de Windows realizan un seguimiento del estado de alimentación 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 (en particular, bus serie universal (USB),todos los dispositivos de punto de conexión y el controlador de 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 de más de un milliwatt, 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 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 del sensor y el controlador 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 la entrada a un modo de espera moderno, Windows detiene automáticamente el uso de todos los sensores deshabilitando el uso de sensores del 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, un comando propietario en espera se puede enviar a través del bus al hardware del sensor. O bien, el hardware del sensor podría estar conectado a una línea GPIO que cambia el dispositivo al modo en espera y fuera del modo de espera.

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 en 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 modernos de espera

Cuando la plataforma sale del modo de espera moderno, el controlador del sensor debe volver 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) deben alternar la línea GPIO según sea necesario para iniciar la transición. Por último, si el hardware del sensor requería previamente una transición al modo de eliminación 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.

Alimentación < en espera de un miliwatt

Si el consumo de energía de un dispositivo sensor en el modo de alimentación en espera no supera un miliwatt, el diseñador de plataformas no es necesario conectar 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 desde el 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 estar conectados a uno o varios dispositivos de sensor externos. En cualquier caso, estos dispositivos de sensor son, desde el punto de vista del software, ocultos detrás del microcontrolador y invisibles para Windows. Si un microcontrolador del 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 desde el SoC.

Si el sensor requiere una línea GPIO desde el SoC para iniciar transiciones hacia y desde el modo en espera, el firmware de la plataforma debe 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 para un sensor independiente que consume menos de un miliwatt en modo de alimentación 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 de alimentación en espera se puede iniciar mediante un comando HID en banda SET_POWER(Suspensión) o mediante un IRP D3 que controla el controlador ACPI ejecutando el método de control de _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 de terceros puede iniciar la transición al modo de alimentación en espera mediante un comando propietario en banda o enviando un IRP D3 que el controlador ACPI controla 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 del microcontrolador.

Alimentación > en espera de un miliwatt

Si la plataforma incluye hardware del sensor o un microcontrolador de sensor que juntos consumen más de un milliwatt en modo de alimentación en espera, el hardware del sensor y el microcontrolador deben pasarse al modo de apagado cuando el sistema está en espera moderno. En esta configuración, el sensor, el microcontrolador de sensor opcional y 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 que son responsables del uso de una región de operación 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 sensor del espacio de nombres ACPI en el raíl de alimentación conmutable, incluidos 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 alimentación en espera. Las dos opciones son usar la pila HIDI2C de Windows, como se muestra en el lado izquierdo del diagrama, o para usar un controlador de sensor de terceros, 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, se evaluará el objeto _PR3 y Windows desactivará el recurso de energía especificado ejecutando el método _OFF. Si varios sensores comparten power Resource, Windows hace referencia automáticamente a todos los sensores y ejecuta 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 alimentación 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 ningún problema de reactivación para los sensores o el microcontrolador de sensor opcional. Se espera que los dispositivos 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.

Prueba y validación

Es fundamental que el diseñador del sistema compruebe que el hardware del sensor entra en modo de espera o apagado 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 se conecte el dispositivo del sensor.

Sensor conectado a HIDI2C

Si el sistema usa la pila HIDI2C de Windows, 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 seguimiento de eventos para Windows (ETW) para todas las decisiones de administració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 administración de energía mediante los eventos ETW y 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 seguimiento de eventos para Windows (ETW) para todas las decisiones de administració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 administración de energía mediante los eventos ETW y 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 comprobar que el IRP D3 pasa a través de la pila de controladores del dispositivo del sensor. El administrador de energía de Windows tiene instrumentación ETW integrada, que incluye instrumentación para detectar IRP dx (solicitudes de alimentación del dispositivo). Para ver esta información en un modo manual, descargue windows Performance Toolkit e instálelo en el sistema sometido a prueba.

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

1. Abra una ventana del símbolo del sistema 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 al modo de espera moderno presionando el botón de encendido.

5. Espere 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 seguimiento binario en .csv y formato legible: 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. Puede buscar el identificador de hardware del dispositivo 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 del sensor es ACPI\MST0731\2&daba3ff&0.

10. El inicio del IRP D3 para el dispositivo 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 del dispositivo del 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 de parámetro para 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 se debe registrar cerca del inicio del archivo de salida de Power.txt. El valor 0x868e2728 del parámetro en el evento de salida anterior es un puntero a la estructura IRP para el IRP D3. Al buscar eventos posteriores en el archivo de seguimiento que tienen este mismo puntero IRP, puede seguir el progreso del IRP D3 a medida que fluye a través de la pila de controladores para el dispositivo 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 _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. Se registrará un evento Microsoft-Windows-Kernel-Power/IRP/Start para el dispositivo sensor 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 de administración de energía de sensor y microcontrolador 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 hardware de sensor que tenga un consumo de energía en espera de menos de un milliwatt.
• 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 escribir D3 automáticamente cuando no se usen en una aplicación o el sistema operativo.
  • Los sensores deben encenderse y escribir 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 bajo consumo, 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, lo que puede 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 del 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 milliwatt 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, _ON/_OFF métodos de control y Power Resource en el dispositivo 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 alimentación en espera:
  • Asegúrese de que la línea GPIO del 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 de GPIO de SoC como parte de una región de operación GPIO.
  • Proporcione un método de control _PS3 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 de alimentación en espera.
  • 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 milliwatt en el modo de alimentación en espera:
  • Coloque todo el hardware del sensor en un raíl de alimentación que se pueda encender y apagar mediante una línea GPIO desde el SoC. O bien, si la plataforma contiene varios sensores que tienen requisitos de voltaje de suministro diferentes, proporcione rieles independientes que se puedan cambiar de forma independiente.
  • Describa 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 incorporan los requisitos de desbotado o de tiempo 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 entra en modo de espera o apagado cuando la plataforma entra en espera moderna.
  • 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 quitado de energía, 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 espera moderna y que el hardware del sensor entra en D0 después de que el sistema salga de la información moderna de espera y sensor se solicite de nuevo.
• 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.