Batería y carga
Experiencia del usuario de carga de batería
En este tema se tratan las recomendaciones para la batería y la carga en Windows 10. Todos los dispositivos que ejecutan Windows tienen una experiencia de carga de batería coherente, independientemente del factor de forma, el conjunto de instrucciones o la arquitectura de la plataforma. Como resultado, los usuarios tienen una experiencia coherente y de calidad con la carga de la batería.
La carga siempre se produce cuando se conecta al cargador.
Excepto en los casos de error de batería, un dispositivo que ejecuta Windows siempre es capaz de cargar la batería siempre que esté conectado al cargador.
Windows siempre puede arrancar cuando se conecta al cargador.
Windows 10 para ediciones de escritorio (Home, Pro, Enterprise y Education):
Si el dispositivo está en el estado S5 (estado de apagado), siempre puede arrancar en Windows cuando esté conectado al cargador, independientemente del nivel de carga de la batería y la presencia de la batería, si la batería es extraíble.
Windows 10 Mobile:
Una batería debe estar presente y tener suficiente nivel de carga para que el sistema arranque.
El hardware administra de forma autónoma la carga.
El hardware carga la batería del dispositivo sin necesidad de firmware, Windows, controladores u otro software que se ejecute en las CPU principales. Este requisito solo se aplica a Windows 10 para sistemas de ediciones de escritorio. Windows 10 Mobile sistemas pueden requerir el soporte de una aplicación de carga UEFI y/u otros componentes de software para cargar la batería.
La carga se detiene automáticamente cuando la batería se carga por completo o cuando se produce un error.
El hardware detiene automáticamente la carga cuando la batería se carga por completo. Esto se hace sin necesidad de firmware, Windows, controladores u otro software que se ejecute en las CPU principales. Si hay una batería o una condición de error térmico, la carga también se detiene automáticamente.
La carga se produce cuando se conecta al cargador
Los usuarios esperan que su dispositivo se cargue cada vez que esté conectado al cargador. Por lo tanto, el hardware siempre debe intentar cargar la batería siempre que el dispositivo esté conectado al cargador independientemente del estado de alimentación. Esta expectativa es cierta en todos los estados de energía, incluidos los activos (S0), suspensión (S3), Hibernate (S4), apagado (S5), apagado (G2/G3) y S0 Inactivo. La carga puede detenerse una vez que la batería esté totalmente cargada o si se produce una condición de error.
No se recomienda un diseño que carga la batería a una velocidad reducida cuando Windows o el firmware no se ha arrancado ni en ejecución. Por ejemplo, la batería puede cargarse a una velocidad más lenta cuando el sistema está completamente apagado y conectado al cargador y cargar a una velocidad más rápida cuando el dispositivo se arranca y el firmware ACPI se puede usar para supervisar la batería periódicamente.
Por último, un diseño puede cargar la batería a una velocidad inferior cuando el sistema está en una condición térmica. En este escenario, el calor se puede reducir al ralentizar o eliminar la carga de la batería por completo. Las condiciones térmicas son la excepción en cualquier buen diseño del sistema.
Windows siempre se puede arrancar cuando se conecta a la alimentación de CA
Ediciones de Windows 10 para escritorio
Los usuarios esperan que puedan arrancar inmediatamente y usar su dispositivo cada vez que esté conectado al cargador. Por lo tanto, el dispositivo siempre debe arrancar y ser totalmente utilizable cuando esté conectado a la alimentación de CA. Esto es cierto independientemente del nivel de carga de la batería, el estado de la batería/cargador y la presencia de la batería (si la batería es extraíble).
Si el dispositivo requiere una capacidad mínima de batería para arrancar el firmware y Windows, el hardware debe asegurarse de que la capacidad de la batería siempre está reservada por la plataforma. La capacidad reservada de la batería no debe exponerse a Windows.
Windows 10 Mobile
Cuando el sistema está conectado a la alimentación de CA y la batería está presente, el sistema debe intentar arrancar en el sistema operativo, siempre y cuando la batería tenga suficiente carga para alimentar el sistema durante el proceso de arranque.
El hardware administra de forma autónoma la carga
Como se especificó anteriormente, los usuarios esperan que su dispositivo cargue cuando esté conectado al cargador. Como resultado, el hardware debe cargar la batería sin necesidad de firmware, Windows, controladores u otro software que se ejecute en las CPU principales, ya que uno o varios de estos componentes pueden no estar operativos o pueden estar en estado de error en un momento dado. Este requisito solo se aplica a Windows 10 para los sistemas de ediciones de escritorio. Windows 10 Mobile sistemas pueden requerir el soporte de una aplicación de carga UEFI y/u otros componentes de software para cargar la batería.
La carga se detiene automáticamente cuando se carga por completo o cuando se produce un error
El hardware detiene automáticamente la carga cuando la batería se carga por completo o si se produjo un error. Al igual que con la carga, esto debe realizarse sin necesidad de firmware, Windows, controladores u otro software que se ejecute en las CPU principales. Además, el hardware es necesario para cumplir con todas las condiciones normativas de seguridad de la batería.
Indicadores de potencia y carga
Windows proporciona una fuente de alimentación y un indicador de estado de la batería mediante iconos que el usuario puede ver en varios lugares. Los lugares incluyen el icono de bandeja del sistema de batería y la pantalla de bloqueo.
Un dispositivo también puede tener un indicador físico, como un LED que indica el estado de carga. Este indicador debe tener poco impacto en el consumo de energía.
Iconos de carga y energía de Windows
Windows muestra el estado de fuente de alimentación y carga en tres ubicaciones:
En la pantalla de bloqueo:
Windows muestra un icono de batería con la fuente de alimentación y el estado de carga.
Bandeja del sistema de escritorio (solo Windows 10 para ediciones de escritorio):
Windows muestra un icono de batería con fuente de alimentación y estado de carga. Cuando el usuario hace clic en el icono de la batería, puede ver información como la capacidad restante, el tiempo estimado restante y los detalles por batería (si están equipados con varias baterías).
Barra de estado (solo SKU móvil):
Windows muestra un icono de batería con fuente de alimentación y estado de carga. Cuando el usuario desliza el dedo hacia abajo desde la parte superior de la pantalla para expandir el centro de actividades, puede ver el porcentaje de batería real.
Configuración del ahorro de batería:
En la página Configuración del ahorro de batería (Configuración -> Sistema -> Ahorro de batería), Windows muestra el porcentaje general de batería, el estado de la batería (carga frente a descarga) y el tiempo restante estimado para cargar o descargar.
En el caso de las plataformas capaces de S0 Idle, si la pantalla está visible, Windows ilumina brevemente la pantalla cuando el sistema está conectado o desconectado del cargador para notificar al usuario un cambio de fuente de alimentación.
Indicadores de carga de hardware de plataforma
Los iconos integrados en escenarios de direcciones solo de Windows en los que Se ejecuta Windows y la pantalla es visible para el usuario. Sin embargo, los indicadores en pantalla no son visibles cuando el sistema está apagado o el estado de inactividad S0 donde la pantalla está desactivada. Dado que el usuario no puede ver indicaciones visuales en la pantalla, la plataforma puede incluir un indicador de carga físico para indicar que la energía está presente.
En la siguiente sección se proporciona nuestra recomendación para implementar teclados y mouse/touchpads en plataformas inactivas S0 con soluciones de acoplamiento. En esta sección también se tratan los desafíos y principios junto con las posibles soluciones. Ambas soluciones potenciales se aplican a acoplamientos fijos móviles y A/C.
Exposición del subsistema de alimentación y carga a Windows
Cada dispositivo móvil que ejecuta Windows incluye una o varias baterías y una fuente de alimentación, como un adaptador de CA. La información de estos subsistemas transmite el estado de administración de energía al usuario. El estado incluye la capacidad restante de la batería en cualquier momento, el estado del adaptador de CA y la carga de la batería, y el tiempo de batería restante estimado. La información del subsistema de energía se expone en el medidor de batería de Windows y otras utilidades de diagnóstico de administración de energía.
En la siguiente sección se proporciona nuestra recomendación para implementar teclados y mouse/touchpads en plataformas inactivas S0 con soluciones de acoplamiento. En esta sección también se tratan los desafíos y principios junto con las posibles soluciones. Ambas soluciones potenciales se aplican a acoplamientos fijos móviles y A/C.
Topologías típicas de hardware del subsistema de energía
Por lo general, Windows espera una de las dos topologías de hardware para el subsistema de alimentación y carga.
En la ilustración siguiente se muestra la primera topología que usa el controlador insertado de la plataforma, que es común en los dispositivos existentes que ejecutan Windows. El controlador incrustado realiza varias funciones en un dispositivo móvil, incluido el control de fuente de alimentación, la administración de la carga de la batería, la detección del botón de encendido/conmutador y la entrada del teclado y el mouse compatibles con PS/2. El controlador insertado normalmente se conecta al silicio principal a través del bus de recuento de patillas bajas (LPC). Las consultas de Windows y se notifican sobre la información del subsistema de energía a través de la interfaz del controlador insertado ACPI.
En la siguiente ilustración se muestra la segunda topología, que hace uso de un controlador de carga de batería y un componente de medidor de combustible conectados directamente al silicio principal de la plataforma a través de un bus periférico ligero, como I²C. En esta configuración, Windows consulta y recibe una notificación sobre los cambios del subsistema de energía a través de las comunicaciones a través del bus I²C. En lugar de usar un controlador de dispositivo para la batería o el subsistema de carga, el entorno del método de control ACPI se extiende con compatibilidad con una región de operación de periférico simple (SPB). La región de operación SPB permite que el código del método de control ACPI se comunique con el controlador de carga de la batería y los componentes del medidor de combustible conectados al silicio principal a través de I²C.
Modelo de controlador del subsistema de batería y energía
Windows cuenta con un sólido modelo de controlador de dispositivo del subsistema de batería y energía. La información de administración de energía se transmite al administrador de energía de Windows a través de un controlador de dispositivo de batería y, a continuación, se agrega y expone a la interfaz de usuario de Windows a través de los IRP del dispositivo de batería y un conjunto de API de software de administración de energía.
El modelo de controlador de batería es un modelo de puerto o minipuerto, es decir, el modelo de batería y las interfaces se definen de modo que los nuevos tipos de batería se puedan exponer a través de un minipuerto. Sin embargo, en la práctica, solo hay dos minipuertos que tienen un uso significativo en el ecosistema de Windows: el controlador de minipuerto de batería que admite las baterías del método de control ACPI y el controlador de minipuerto de batería HID para dispositivos de fuente de alimentación ininterrumpida (UPS) conectados a USB.
Se espera que todos los equipos expongan las baterías y el subsistema de carga a través de la interfaz del método de control ACPI. La interfaz del minipuerto de batería no debe utilizarse para subsistemas de carga de baterías específicos de la plataforma. Hay métodos de control definidos por la especificación ACPI que permiten a Windows sondear la información y el estado de la batería. Del mismo modo, hay un modelo controlado por eventos para permitir que la plataforma de hardware notifique a Windows los cambios de batería y fuente de energía, como una transición de CA a energía de batería.
Sondeo de estado
El administrador de energía de Windows solicita periódicamente información de estado de la batería, incluida la capacidad de carga restante y la velocidad actual de purga. Esta solicitud se origina en el administrador de energía, en un componente de interfaz de usuario de nivel superior o en una aplicación. El administrador de energía convierte la solicitud en un paquete de solicitud de E/S (IRP) a los dispositivos de batería. Cuando la batería se expone a través de la interfaz del método de control ACPI, el controlador de batería del método de control (cmbatt.sys) ejecuta los métodos de control ACPI adecuados. En el caso de la información de estado, se ejecuta el método _BST (estado de la batería).
El método _BST requiere el firmware ACPI para obtener información actual del subsistema de energía y, a continuación, empaqueta esa información en un búfer con el formato especificado por la especificación ACPI. El código específico necesario para acceder al estado de la batería desde el controlador incrustado o el cargador de batería conectado a través de I²C se encuentra dentro del firmware ACPI y parte del código que comprende el método _BST. El resultado neto del método _BST es el búfer de información necesaria, que se devuelve al controlador de batería del método de control. El controlador de batería del método de control convierte finalmente el búfer en el formato requerido por el controlador de batería y el administrador de energía de Windows.
Notificaciones de cambio de estado
El subsistema de energía y batería generará varias notificaciones a Windows para los cambios de estado, incluidas las transiciones de CA a energía de batería. El sondeo por Parte de Windows para estos cambios de estado no es práctico dada la alta frecuencia a la que se requeriría el sondeo. Por lo tanto, la plataforma de hardware debe usar un modelo controlado por eventos para notificar a Windows cuando el estado de la batería cambia significativamente.
Cuando cambia el estado de la batería, incluida la capacidad restante o el estado de carga, el firmware ACPI emite una notificación (0x80) en el dispositivo de la batería del método de control. A continuación, el controlador de batería del método de control de Windows evalúa el método _BST y devuelve la información actualizada al administrador de energía.
Cuando cambian los datos estáticos de la batería, incluida la última capacidad de carga completa, la capacidad de diseño y el recuento de ciclos, el firmware ACPI emite una notificación (0x81) en el dispositivo de batería del método de control. A continuación, el controlador de batería del método de control de Windows evalúa el método _BIX y devuelve la información actualizada al administrador de energía.
La plataforma interrumpe el entorno de firmware ACPI a través de la interrupción del control del sistema (SCI) en el caso de una plataforma equipada con controlador incrustado y a través de un GPIO en el caso de plataformas con hardware subsistema de batería conectado directamente al silicio principal.
Operación ACPI con un controlador insertado
Las plataformas que tienen su subsistema de batería y energía conectados al controlador insertado típico usan la región de operación del controlador incrustado ACPI para facilitar las comunicaciones entre el entorno del método de control ACPI y el hardware de la plataforma.
El firmware ACPI debe definir el controlador insertado en el espacio de nombres ACPI tal y como se describe en la sección 12.11.1 de la especificación ACPI, incluyendo:
- Un nodo Device() para el controlador incrustado.
- Objeto _HID que indica que el dispositivo es un controlador incrustado.
- Objeto _CRS para indicar los recursos de E/S para el controlador incrustado.
- Objeto _GPE que define la SCI para el controlador incrustado.
- Una región de operación que describe la información contenida en el controlador incrustado a la que puede acceder otro código de método de control ACPI en el espacio de nombres, incluido el estado de la batería y los métodos de información.
Los detalles completos se describen en la sección 12 de la especificación ACPI.
Acceso a la información de la batería desde el controlador incrustado
El método de control ACPI accede a la información del controlador incrustado mediante la lectura de los valores descritos en la región de operación del controlador incrustado.
Notificación al sistema operativo cuando cambia el estado de la batería
Cuando el controlador incrustado detecta un cambio en el estado de la batería, incluido un cambio en el estado de carga o la capacidad restante según lo especificado por _BTP, el controlador incrustado genera una SCI y establece el bit de SCI_EVT bit en el registro de estado del controlador incrustado (EC_SC). El controlador ACPI de Windows se comunicará con el controlador incrustado y emitirá un comando de consulta (QR_EC) para solicitar información específica sobre la notificación que se va a emitir. A continuación, el controlador incrustado establece un valor de byte correspondiente al método _QXX que se va a ejecutar. Por ejemplo, el controlador incrustado y el firmware ACPI pueden definir el valor 0x33 ser una actualización de la información de estado de la batería. Cuando el controlador incrustado establece el valor 0x33 como notificación, el controlador ACPI ejecutará el método _QXX. El contenido del método _QXX normalmente será notify(0x80) en el dispositivo de batería del método de control en el espacio de nombres.
Operación ACPI con un sistema de carga conectado I²C
Las plataformas también pueden conectar su subsistema de batería y energía conectado al conjunto de chips principal a través de un bus serie de bajo consumo, como I²C. En estos diseños, la región de operación GenericSerialBus ACPI se usa para comunicarse entre los métodos de control ACPI y el hardware del subsistema de batería. Conectar el hardware del subsistema de batería a una interrupción GPIO permite ejecutar los métodos de control ACPI cuando cambia el estado de la batería.
Cuando el hardware del subsistema de batería y energía se conecta a través de I²C, el firmware ACPI debe definir:
Un nodo Device() para el dispositivo del controlador GPIO al que está conectada la interrupción I²C, entre los que se incluyen:
- _HID objeto que describe el identificador de hardware del controlador GPIO.
- _CSR objeto que describe los recursos de interrupción y hardware del controlador GPIO.
- _AEI objeto que asigna una o varias líneas GPIO a la ejecución del método de evento ACPI. Esto permite que los métodos ACPI se ejecuten en respuesta a interrupciones de línea GPIO.
Un nodo Device() para el controlador I²C al que está conectado el medidor de combustible de la batería y el hardware de carga, entre los que se incluyen:
- _HID y _CSR objetos que describen el identificador de hardware y los recursos del controlador I²C.
- GenericSerialBus OperationRegion dentro del ámbito del dispositivo I²C que describe los registros de comandos virtuales para el dispositivo I²C.
- Definiciones de campo dentro de GenericSerialBus OperationRegion. Las definiciones de campo permiten que el código ASL fuera del dispositivo I²C acceda a los registros de comandos virtuales para el dispositivo I²C.
Describir el controlador GPIO y la asignación de líneas GPIO a eventos ACPI permite ejecutar los métodos de control para el estado de la batería y la notificación cuando se genera una interrupción gpIO de un dispositivo I²C. Describir la región de operación GenericSerialBus permite que el código ACPI para el estado de la batería se comunique a través del bus I²C y lea los registros e información del medidor de combustible de la batería y el subsistema de carga.
Acceso a la información de la batería desde el sistema de carga
Los métodos de control ACPI pueden ejecutar el estado de la batería enviando y recibiendo comandos sobre el bus I²C al que está conectado el hardware del subsistema de batería. El código del método de control que respalda el estado y los métodos de información estática de batería lee y escribe datos de las regiones de operación GenericSerialBus descritas en el espacio de nombres ACPI. El código del método de control lee los datos del dispositivo de medidor de combustible o información estática sobre la capacidad de la batería y los recuentos de ciclo sobre el bus I²C a través de la región de operación GenericSerialBus.
Notificación a Windows cuando cambia el estado de la batería
El hardware del subsistema de batería puede generar una interrupción cuando cambia el estado y la interrupción está conectada físicamente a una línea GPIO en el silicio principal. La línea GPIO se puede asignar a una ejecución de método de control específica mediante el objeto _AEI bajo el controlador GPIO descrito en ACPI. Cuando se produce la interrupción de GPIO, el subsistema ACPI de Windows ejecuta el método asociado a la línea GPIO específica que, a su vez, puede realizar una notificación() en el dispositivo de batería del método de control, lo que hace que Windows vuelva a evaluar el estado y los métodos de información estáticos para actualizar el estado de la batería.
Implementación ACPI del objeto de fuente de alimentación
El firmware ACPI debe implementar un dispositivo de fuente de alimentación ACPI. Este objeto debe informarse con un identificador de hardware (_HID) de "ACPI0003". Este objeto también debe implementar el método ACPI _PSR (Fuente de energía). Este método devuelve el estado de la fuente de alimentación y transmite si la fuente de alimentación está actualmente en línea (alimentación de CA) o sin conexión (en la alimentación de la batería). Todas las fuentes de alimentación de entrada para el sistema deben multiplexarse a través de un único método de _PSR. Por ejemplo, _PSR deben transmitirse en línea si el sistema está alimentado a través de un conector de cañón de controlador de dominio o un conector de acoplamiento independiente. No use varios dispositivos de fuente de alimentación de ACPI.
El método _PSR solo debe informar en línea (alimentación de CA) cuando el sistema está conectado a la alimentación principal. Cuando cambia el estado de _PSR, la plataforma debe generar una interrupción y una notificación (0x80) en el dispositivo en el espacio de nombres ACPI. Esto debe realizarse inmediatamente después de que la plataforma detecte el cambio de estado físico.
Implementación ACPI de información estática de batería
El firmware ACPI debe implementar el método de _BIX ACPI para cada batería que proporcione información estática sobre la batería, incluida la capacidad de diseño, el recuento de ciclos y el número de serie. La tabla siguiente se expande en las definiciones de los campos descritos en la especificación ACPI y enumera los requisitos específicos de Windows para esta información.
| Campo | Descripción | Requisitos específicos de Windows |
|---|---|---|
| Revisión | Indica _BIX revisión | Debe establecerse en 0x0 |
| Unidad de alimentación | Determina las unidades notificadas por el hardware. Ya sea: MA/MAh o mW/mWh. | Debe establecerse en 0x0 para indicar que las unidades son mW/mWh. |
| Capacidad de diseño | Indica la capacidad original de la batería en mWh. | Debe establecerse en un valor preciso y no se puede 0x0 ni 0xFFFFFFFF |
| Última capacidad de cargo completo | Indica la capacidad de carga completa actual de la batería. | Debe establecerse en un valor preciso y no se puede 0x0 ni 0xFFFFFFFF Este valor debe actualizarse cada vez que aumenta el recuento cíclico. |
| Tecnología de batería | Indica si la batería es recargable o de uso único. | Debe establecerse en 0x1 para indicar que la batería es recargable |
| Voltaje de diseño | Indica el voltaje de diseño de la batería. | Debe establecerse en el voltaje de diseño de la batería cuando sea nuevo en mV. No se debe establecer en 0x0 o 0xFFFFFFFF. |
| Capacidad de diseño de advertencia | Indica un nivel de advertencia de batería bajo proporcionado por el OEM. | Windows omite este valor. |
| Capacidad de diseño de baja | Indica el nivel de batería crítico en el que Windows debe apagar o hibernar inmediatamente antes de que el sistema se apague. | Debe establecerse en un valor entre 0x0 y el 5 % de la capacidad de diseño de la batería. |
| Granularidad de la capacidad de la batería 1 | Indica la cantidad mínima de cambio de carga restante que el hardware detecta entre la capacidad de diseño de advertencia y la capacidad de diseño de baja. | Debe establecerse en un valor no superior al 1 % de la capacidad de diseño de la batería. |
| Granularidad de la capacidad de la batería 2 | Indica la cantidad mínima de cambio de carga restante que el hardware detecta entre la última capacidad de carga completa y la capacidad de diseño de advertencia. | Debe establecerse en un valor no mayor que 75mW (aproximadamente,25% de una batería de 25Whr), que es (1/400) de la capacidad de diseño de la batería. |
| Recuento de ciclos | Indica el recuento cíclico de la batería. | Debe establecerse en un valor mayor que 0x0. No se debe establecer en 0xFFFFFFFF. |
| Precisión de la medida | Indica la precisión de la medición de la capacidad de la batería. | Debe establecerse en 95 000 o superior, lo que indica una precisión del 95 % o superior. |
| Tiempo máximo de muestreo | El tiempo de muestreo máximo admitido entre dos evaluaciones sucesivas de _BST que mostrarán una diferencia en la capacidad restante. | No hay ningún requisito específico. |
| Tiempo de muestreo mínimo | Tiempo de muestreo mínimo admitido entre dos evaluaciones de _BST sucesivas que mostrarán una diferencia en la capacidad restante. | No hay ningún requisito específico. |
| Intervalo de promedio máximo | Intervalo de promedio máximo, en milisegundos, que el medidor de combustible de la batería soporta. | No hay ningún requisito específico. |
| Intervalo de promedio mínimo | Intervalo de promedio mínimo, en milisegundos, que el medidor de combustible de la batería soporta. | No hay ningún requisito específico. |
| Número de modelo | Número de modelo de batería proporcionado por OEM | No debe ser NULL. |
| Número de serie | Número de serie de batería proporcionado por OEM | No debe ser NULL. |
| Tipo de batería | Información de tipo de batería proporcionada por OEM | No hay ningún requisito específico. |
| Información de OEM | Información proporcionada por OEM | No hay ningún requisito específico. |
Implementación ACPI de información de estado en tiempo real de la batería
El firmware ACPI debe implementar el método ACPI _BST para cada batería que proporciona información de estado en tiempo real sobre la batería, incluida la capacidad restante y la velocidad actual de purga. La tabla siguiente se expande en las definiciones de los campos descritos en la especificación ACPI y enumera los requisitos específicos de Windows para esta información.
| Campo | Descripción | Requisitos específicos de Windows |
|---|---|---|
| Estado de la batería | Indica si la batería se está cargando actualmente, se descarga o está en un estado crítico. | El estado de la batería debe notificar la carga solo si la batería se está cargando. Del mismo modo, el estado de la batería debe notificar la descarga solo si la batería se descarga. Una batería que no está cargándose ni descargándose no debe notificar ninguno de los dos bits. |
| Velocidad de presentación de la batería | Proporciona la velocidad actual de purga en mW de la batería. | Debe ser un valor mayor que 0x0 y menor que 0xFFFFFFFF. Debe ser preciso dentro del valor de precisión de medida en _BIX. |
| Capacidad restante de la batería | Proporciona la capacidad restante de la batería en mWh. | Debe ser un valor mayor que 0x0 y menor que 0xFFFFFFFF. Debe ser preciso dentro del valor de Precisión de medida en _BIX |
| Voltaje presente de la batería | Indica el voltaje de corriente en los terminales de la batería. | Debe estar entre un valor de 0x0 y 0xFFFFFFFF en mV. |
Al cambiar los datos de _BST, la plataforma debe generar una interrupción y una notificación (0x80) en el dispositivo de batería en el espacio de nombres ACPI. Esto debe realizarse inmediatamente después de que la plataforma detecte el cambio de estado físico. Esto incluye cualquier cambio en el campo Estado de la batería para la carga (es decir, Bit0) o descarga de bits (es decir, Bit1).
Además, la plataforma debe implementar el mecanismo de punto de viaje de batería _BTP. _BTP permite a Windows especificar un umbral de capacidad restante que, cuando se cruza, la plataforma debe generar una interrupción y una notificación (0x80) en el dispositivo de batería en el espacio de nombres ACPI. El método _BTP evita que Windows necesite sondear la batería periódicamente.
Métodos de control de batería
La especificación ACPI ofrece métodos de control específicos del sistema operativo y del dispositivo a través del método de control Device-Specific o _DSM método de control. _DSM se describe en la sección 9.14.1 de la especificación ACPI.
Windows admite los siguientes métodos de _DSM para dispositivos de batería de método de control.
Dirección de la velocidad de carga térmica
| Campo | Valor | Descripción |
|---|---|---|
| UUID | 4c2067e3-887d-475c-9720-4af1d3ed602e | GUID que indica extensiones para la compatibilidad del controlador de batería del método de control de Windows |
| ID de revision | 0x0 | Primera revisión de esta funcionalidad |
| Índice de función | 0x1 | Establecer la limitación de carga de la batería |
| Argumentos | Límite térmico | Valor entero de 0 a 100 que indica el límite de carga térmica. Un valor del 40 % indica que la batería debe cargarse al 40 % de la velocidad máxima. Un valor del 0 % indica que la carga de la batería debe detenerse hasta que se vuelva a llamar a este método. |
| Valores devueltos | None | N/D |
Batería que se puede atender por el usuario
| Campo | Valor | Descripción |
|---|---|---|
| UUID | 4c2067e3-887d-475c-9720-4af1d3ed602e | GUID que indica las extensiones que admiten el controlador de batería del método de control de Windows |
| ID de revision | 0x0 | Primera revisión de esta funcionalidad |
| Índice de función | 0x2 | Indica que este _DSM es para que OSPM determine si el dispositivo de batería es utilizable por el usuario o no. |
| Argumentos | Ninguno | No se requieren argumentos. |
| Valores devueltos | Paquete con un único número entero. | 0x0 si la batería no es utilizable por el usuario y el usuario final no puede sustituirla, o sí puede sustituirla con herramientas adicionales. 0x1 si el usuario final puede reemplazar la batería sin herramientas adicionales. |
Se necesita el guardián de carga
| Campo | Valor | Descripción |
|---|---|---|
| UUID | 4c2067e3-887d-475c-9720-4af1d3ed602e | GUID que indica las extensiones que admiten el controlador de batería del método de control de Windows |
| ID de revision | 0x0 | Primera revisión de esta funcionalidad |
| Índice de función | 0x3 | Indica que este _DSM es para que el OSPM determine si la batería del método de control requiere el restablecimiento periódico del guardián para mantener una carga de corriente alta y el período en el que se debe restablecer el guardián. |
| Argumentos | Ninguno | No se requieren argumentos. |
| Valores devueltos | Paquete con un único número entero. | 0x0 si la batería no requiere del guardián.
Los valores 0x0000001e y 0x12C, estos incluidos, indican el intervalo máximo de sondeo en segundos. Todos los demás valores se omiten y se tratan como 0x0 y no es necesario el restablecimiento del guardián. Si se especifica un intervalo de guardián válido, Windows ejecutará el método _BST en un intervalo que ya no sea el valor de guardián especificado cada vez que el valor de BatteryState en el método _BST esté establecido en cargar. No se admite la actualización dinámica de este valor. |
Controladores de minipuerto de batería de terceros
En Windows 10, los OEM e IHD pueden desarrollar sus propios controladores de miniporte de batería de terceros para reemplazar el controlador de Microsoft cmbatt.sys y comunicarse directamente con el hardware de la batería. Microsoft proporciona un controlador de batería de ejemplo en GitHub y como parte del kit de ejemplos de WDK .
Carga USB (Windows 10 para ediciones de escritorio)
Microsoft reconoce el valor para proporcionar la opción de admitir la carga USB de un dispositivo móvil. Con los esfuerzos de normalización, como la migración de la UE a cargadores de teléfono móvil estandarizados, los cargadores USB están ampliamente disponibles y funcionan en una amplia variedad de dispositivos, como Windows Phone, reproductores MP3, dispositivos GNSS, etc. Microsoft entiende el valor de ofrecer un único cargador que se puede usar para cargar varios dispositivos, incluido un dispositivo que ejecuta Windows. Además, dado el amplio apoyo del sector para la carga USB, hay ventajas auxiliares que reducen los costos y el impacto ambiental.
A partir de Windows 8, un dispositivo móvil podría encenderse o cargarse a través de USB siempre que se cumplan los requisitos de carga de la batería que se describen a continuación. Además, hay una serie de requisitos específicos de USB que se deben cumplir para garantizar una experiencia de usuario de calidad.
La alimentación y carga USB debe implementarse completamente en el firmware de la plataforma. La compatibilidad no debe requerir un sistema operativo, un controlador o una aplicación.
El dispositivo NO DEBE enumerar cuándo está conectado a otro dispositivo. Como resultado, el dispositivo no se cargará cuando esté conectado a un puerto USB de PC estándar, ya que estos puertos están limitados a 500 mA de forma predeterminada. Las únicas excepciones son cuando este puerto se usa para depurar y para la programación inicial de firmware de fábrica.
El dispositivo admite la carga desde un puerto de carga USB dedicado. El dispositivo debe cargarse cuando esté conectado a un cargador compatible con la especificación de carga de batería USB versión 1.2. El dispositivo no debe dibujar más de 1,5A por estándar de carga cuando se conecta a un cargador USB estándar. El OEM puede optar por admitir niveles actuales superiores siempre que se cumplan las siguientes condiciones:
- El dispositivo detecta automáticamente el tipo de cargador y los cargos a la tarifa adecuada para el tipo de cargador específico.
- El dispositivo y el cargador cumplen todos los estándares de seguridad y eléctricos pertinentes.
- El OEM envía el cargador y el cable asociado al dispositivo.
La carga USB se admite a través de un receptáculo micro-AB estándar, USB-C (recomendado) o un conector de acoplamiento propietario. No se permite un receptáculo micro-B en el dispositivo. Si usa un conector de acoplamiento propietario, el OEM debe enviar un cable adecuado con el dispositivo para habilitar la carga desde un cargador USB estándar.
Si se implementa el puerto micro-AB, el dispositivo debe detectar automáticamente el tipo de cable, la configuración y asumir el rol adecuado. Si se inserta un conector micro-B y no se habilita la depuración en el puerto, se debe asumir el rol de cargador. Si se inserta un conector micro-B y se habilita la depuración en el puerto, se debe asumir el rol de depuración (es decir, no se admite la carga). Si se inserta un conector microA, windows reconoce el rol de host USB donde Windows reconoce los dispositivos USB conectados.
Si el puerto micro-AB también funciona como puerto de depuración, el dispositivo debe proporcionar un medio a través del firmware para cambiar entre el cargador y el rol de depuración. La configuración predeterminada como enviada al usuario final debe tener la depuración DISABLED.
Si el puerto micro-AB también funciona como puerto de depuración, el dispositivo debe proporcionar una ruta de acceso de alimentación de entrada alternativa a través de un conector de barril dedicado o un conector de acoplamiento propietario.
Listas de comprobación del diseñador de plataformas e implementador
Puede usar las siguientes listas de comprobación para validar que el diseño de la plataforma y el firmware del sistema se adhieren a las instrucciones del subsistema de carga y batería que se describen.
Lista de comprobación de implementación del subsistema de batería y el firmware ACPI
Los diseñadores del sistema deben asegurarse de que han completado las siguientes tareas en su firmware ACPI para garantizar la generación correcta de informes de la batería y la información del subsistema de energía en Windows:
Agregue un objeto Device() para cada dispositivo de batería en el espacio de nombres ACPI.
Cada dispositivo de batería debe proporcionar los siguientes métodos de control y objetos:
- _HID con un valor de PNP0C0A.
- información de _BIX batería extendida:
Transmite la información estática de la batería, incluida la última capacidad de carga completa, la capacidad de diseño y el recuento de ciclo.
_BST-estado de la batería:
Transmite el estado actual de la batería, incluida la capacidad restante, la velocidad de purga y el estado de carga.
punto de viaje _BTP batería:
Permite que un modelo de estado de batería controlado por eventos reduzca el trabajo periódico para el sondeo. _BTP permite a Windows especificar un umbral de capacidad de carga restante en la que la plataforma debe emitir en Notify(0x80) en el dispositivo de batería para solicitar a Windows que actualice la información de estado de la batería.
_STA estado general:
Permite a Windows saber si la batería está presente en el dispositivo donde una batería puede ser extraíble o donde puede haber una batería en un soporte portátil.
Agregue un único objeto Device() para un adaptador de CA/Fuente de alimentación en el espacio de nombres ACPI.
El dispositivo de fuente de alimentación debe proporcionar los siguientes métodos de control y objetos:
_HID con un valor ACPI0003
_PSR-Power Source:
Transmite si la fuente de alimentación está actualmente en línea (alimentación de CA) o sin conexión (en batería). Todos los orígenes de alimentación de entrada para el dispositivo deben multiplexarse a través del método _PSR. Por ejemplo, el _PSR debe transmitirse en línea si el dispositivo está alimentado a través de un conector de cañón de controlador de dominio o un conector de acoplamiento independiente. No use varios dispositivos de fuente de alimentación de ACPI.
El método _BIX debe admitir los campos y restricciones descritos en la información estática de la batería anterior:
- El campo Revisión debe establecerse en 0x0.
- El campo Unidad de alimentación debe establecerse en 0x0.
- Los valores Capacidad de diseño y Última capacidad de carga completa deben establecerse en valores precisos del subsistema de carga y batería y no establecerse igual a 0xFFFFFFFF o 0x00000000.
- El campo Tecnología de batería debe establecerse en 0x1.
- El campo Voltaje de diseño debe establecerse con precisión y no es igual a 0x00000000 o 0xFFFFFFFF.
- La capacidad de diseño de baja debe establecerse en el valor mínimo necesario para hibernar o apagar el sistema desde un estado totalmente activo.
- Los campos Granularidad de capacidad de batería 1 y Granularidad de capacidad de batería 2 deben establecerse en un valor no mayor que el 1 % de la capacidad de diseño de la batería.
- El campo Recuento de ciclo debe rellenarse con precisión desde el subsistema de batería.
- El campo Precisión de medición debe establecerse en 80 000d o superior.
- Los campos Número de modelo y Número de serie no deben establecerse en NULL.
Proporcione un método de _BST que permita a Windows sondear el estado de la batería en tiempo real. Los campos del método _BST deben devolverse dinámicamente desde el subsistema subyacente de carga de batería y energía. Su precisión debe estar dentro del valor de Precisión de medida en el método _BIX.
Proporcione un método _BTP que permita a Windows especificar un umbral de capacidad de carga restante en el que la plataforma interrumpirá Windows con una notificación (0x80) en el dispositivo de batería.
Asegúrese de que una notificación (0x80) solo se emite en respuesta a un cambio de estado de la batería o _BTP viaje de límite de capacidad de carga. No ejecute periódicamente una notificación (0x80).
Cuando el nivel de batería alcanza el valor especificado en _BIX. DesignCapacityofLow, la plataforma debe generar una notificación (0x80) en el dispositivo de batería del método de control.
Para los sistemas con varias baterías, implemente completamente un dispositivo de batería de método de control para cada batería.
- La primera batería del espacio de nombres debe ser la batería principal del sistema para facilitar la depuración.
Implemente el método _DSM en cada dispositivo de batería para indicar si la batería es útil por el usuario.
Implemente el método _DSM si se requiere un restablecimiento periódico del guardián durante la carga y Windows garantizará la ejecución periódica del método _BST dentro de esa ventana de sondeo.
Implemente el método _DSM si se requiere el control de velocidad de carga de la batería para el modelo térmico en la plataforma.