Bateria e carregamento

Experiência do usuário de carregamento de bateria

Este tópico aborda as recomendações de bateria e carregamento no Windows 10. Todos os dispositivos executados no Windows têm uma experiência consistente de carregamento de bateria, independentemente do fator forma, do conjunto de instruções ou da arquitetura da plataforma. Como resultado, os usuários têm uma experiência consistente e de qualidade com o carregamento da bateria.

1. O carregamento sempre ocorre quando conectado ao carregador.

   Exceto para casos de falha da bateria, um dispositivo que executa o Windows é sempre capaz de carregar a bateria sempre que estiver conectado ao carregador.

2. O Windows sempre pode ser inicializado quando conectado ao carregador.

   • Windows 10 para edições desktop (Home, Pro, Enterprise e Education):

     Se o dispositivo estiver no S5 (estado de desligamento), ele sempre poderá ser inicializado no Windows quando conectado ao carregador, independentemente do nível de carga da bateria e da presença da bateria, se a bateria for removível.

   • Windows 10 Mobile:

     Uma bateria deve estar presente e ter nível de carga suficiente para que o sistema seja inicializado.

3. O hardware gerencia o carregamento de forma autônoma.

   O hardware carrega a bateria do dispositivo sem a necessidade de firmware, Windows, drivers ou outros softwares em execução no main CPU(s). Esse requisito só se aplica a Windows 10 para sistemas de edições desktop. Windows 10 Mobile sistemas podem exigir o suporte de um aplicativo de carregamento UEFI e/ou outros componentes de software para carregar a bateria.

4. O carregamento é interrompido automaticamente quando a bateria é totalmente carregada ou quando ocorre uma falha.

   O hardware para de carregar automaticamente quando a bateria é completamente carregada. Isso é feito sem a necessidade de firmware, Windows, drivers ou outros softwares em execução no main CPU(s). Se houver uma condição de bateria ou falha térmica, o carregamento também será interrompido automaticamente.

O carregamento ocorre quando conectado ao carregador

Os usuários esperam que o dispositivo carregue sempre que ele estiver conectado ao carregador. Dessa forma, o hardware sempre deve tentar carregar a bateria sempre que o dispositivo estiver conectado ao carregador, independentemente do estado de energia. Essa expectativa se mantém verdadeira em todos os estados de energia, incluindo ativo (S0), Suspensão (S3), Hibernação (S4), desligamento (S5), desligamento rígido (G2/G3) e S0 Ocioso. O carregamento poderá parar quando a bateria estiver totalmente carregada ou se ocorrer uma condição de falha.

Não recomendamos um design que carrega a bateria a uma taxa reduzida quando o Windows ou o firmware não tiver sido inicializado ou em execução. Por exemplo, a bateria pode carregar a uma taxa mais lenta quando o sistema está completamente desligado e conectado ao carregador e carregar a uma taxa mais rápida quando o dispositivo é inicializado e o firmware ACPI pode ser usado para monitorar a bateria periodicamente.

Por fim, um design pode carregar a bateria a uma taxa mais baixa quando o sistema está em uma condição térmica. Nesse cenário, o calor pode ser reduzido diminuindo ou eliminando completamente a carga da bateria. As condições térmicas são a exceção em qualquer bom design do sistema.

O Windows é sempre inicializável quando conectado à energia AC

• Windows 10 para edições de área de trabalho

  Os usuários esperam que possam inicializar e usar o dispositivo imediatamente sempre que ele estiver conectado ao carregador. Dessa forma, o dispositivo deve sempre inicializar e ser totalmente utilizável quando conectado à energia AC. Isso vale independentemente do nível de carga da bateria, do estado da bateria/do carregador e da presença da bateria (se a bateria for removível).

  Se o dispositivo exigir uma capacidade mínima de bateria para inicializar o firmware e o Windows, o hardware deverá garantir que a capacidade da bateria seja sempre reservada pela plataforma. A capacidade reservada da bateria não deve ser exposta ao Windows.

• Windows 10 Mobile

  Quando o sistema está conectado à energia AC e a bateria está presente, o sistema deve tentar inicializar o sistema operacional, desde que a bateria tenha carga suficiente para ligar o sistema durante o processo de inicialização.

O hardware gerencia o carregamento de forma autônoma

Conforme especificado acima, os usuários esperam que o dispositivo carregue quando ele estiver conectado ao carregador. Como resultado, o hardware deve carregar a bateria sem a necessidade de firmware, Windows, drivers ou outro software em execução no main CPU(s), pois um ou mais desses componentes podem não estar operacionais ou estar em um estado de falha em um determinado momento. Esse requisito se aplica apenas a Windows 10 para sistemas de edições desktop. Windows 10 Mobile sistemas podem exigir o suporte de um aplicativo de carregamento UEFI e/ou outros componentes de software para carregar a bateria.

O carregamento é interrompido automaticamente quando totalmente carregado ou quando ocorre uma falha

O hardware para de carregar automaticamente quando a bateria é completamente carregada ou se ocorreu uma falha. Assim como acontece com o carregamento, isso deve ser feito sem a necessidade de firmware, Windows, drivers ou outros softwares em execução no main CPU(s). Além disso, o hardware é necessário para cumprir todas as condições regulatórias de segurança da bateria.

Indicadores de energia e carregamento

O Windows fornece uma fonte de energia e um indicador de status de bateria usando ícones que o usuário pode ver em vários lugares. Os locais incluem o ícone de bandeja do sistema de bateria e a tela de bloqueio.

Um dispositivo também pode ter um indicador físico, como um LED que indica o status de carregamento. Esse indicador deve ter pouco impacto sobre o consumo de energia.

Ícones de energia e carregamento do Windows

O Windows exibe a fonte de alimentação e status de carregamento em três locais:

• Na tela de bloqueio:

  O Windows exibe um ícone de bateria com a fonte de alimentação e o status de carga.

• Bandeja do sistema da área de trabalho (Windows 10 somente para edições desktop):

  O Windows exibe um ícone de bateria com fonte de alimentação e status de carga. Quando o usuário clica no ícone de bateria, ele pode exibir informações como capacidade restante, tempo estimado restante e detalhes por bateria (se equipado com várias baterias).

• Barra de status (somente SKU móvel):

  O Windows exibe um ícone de bateria com fonte de alimentação e status de carga. Quando o usuário desliza o dedo para baixo da parte superior da tela para expandir a central de ações, ele pode exibir o percentual real da bateria.

• Configurações de economia de bateria:

  Na página Configurações de Economia de Bateria (Configurações – Sistema –>> Economia de Bateria), o Windows exibe o percentual geral da bateria, a status da bateria (Carregamento versus Descarregação) e o Tempo Restante Estimado para carregar/descarregar.

Para plataformas capazes de S0 Idle, se a tela estiver visível, o Windows acenderá brevemente a tela quando o sistema estiver conectado ou desconectado do carregador para notificar o usuário sobre uma alteração de fonte de alimentação.

Indicadores de carregamento de hardware de plataforma

Os ícones internos do Windows abordam apenas cenários em que o Windows está em execução e a exibição é visível para o usuário. No entanto, os indicadores na tela não ficam visíveis quando o sistema está desligado ou o estado Ocioso S0 em que a exibição está desativada. Como o usuário não pode ver indicações visuais na tela, a plataforma pode incluir um indicador de carregamento físico para indicar que a energia está presente.

A seção a seguir fornece nossa recomendação para implementar teclados e mouses/touchpads em plataformas Ociosas S0 com soluções de encaixe. Esta seção também fala sobre os desafios e princípios, juntamente com possíveis soluções. Ambas as soluções potenciais se aplicam a encaixes estacionários móveis e A/C.

Expondo o subsistema de energia e carregamento ao Windows

Cada dispositivo móvel que executa o Windows inclui uma ou mais baterias e uma fonte de alimentação, como um adaptador AC. As informações desses subsistemas transmitem status de gerenciamento de energia para o usuário. O status inclui a capacidade restante da bateria a qualquer momento, o estado do adaptador AC e o carregamento da bateria e o tempo estimado restante da bateria. As informações do subsistema de energia são expostas no medidor de bateria do Windows e em outros utilitários de diagnóstico de gerenciamento de energia.

A seção a seguir fornece nossa recomendação para implementar teclados e mouses/touchpads em plataformas Ociosas S0 com soluções de encaixe. Esta seção também fala sobre os desafios e princípios, juntamente com possíveis soluções. Ambas as soluções potenciais se aplicam a encaixes estacionários móveis e A/C.

Topologias típicas de hardware do subsistema de energia

Em geral, o Windows espera uma das duas topologias de hardware para o subsistema de energia e carregamento.

A figura a seguir ilustra a primeira topologia que usa o Controlador Inserido da plataforma, que é comum em dispositivos existentes que executam o Windows. O Controlador Inserido executa várias funções em um dispositivo móvel, incluindo controle do código-fonte de energia, gerenciamento de carga da bateria, detecção de botão de energia/comutador e entrada de teclado e mouse compatíveis com PS/2. O controlador inserido normalmente está conectado ao silício principal por meio do barramento LPC (contagem baixa de pinos). O Windows consulta e é notificado sobre as informações do subsistema de energia por meio da interface do controlador inserido do ACPI.

A figura a seguir ilustra a segunda topologia, que usa um controlador de carga de bateria e um componente de medidor de combustível conectados diretamente ao silício principal da plataforma sobre um barramento periférico leve, como I²C. Nessa configuração, o Windows consulta e é notificado sobre alterações de subsistema de energia por meio de comunicações no barramento I²C. Em vez de usar um driver de dispositivo para a bateria ou subsistema de carregamento, o ambiente do método de controle ACPI é estendido com suporte para uma região de operação SPB (Periférico Simples). A região de operação do SPB permite que o código do método de controle ACPI se comunique com o controlador de carga da bateria e os componentes do medidor de combustível conectados ao silício principal por I²C.

Modelo de driver de subsistema de bateria e energia

O Windows apresenta um modelo robusto de driver de dispositivo de subsistema de energia e bateria. As informações de gerenciamento de energia são transmitidas ao gerenciador de energia do Windows por meio de um driver de dispositivo de bateria e, em seguida, agregadas e expostas à interface do usuário do Windows por meio dos IRPs do dispositivo de bateria e um conjunto de APIs de software de gerenciamento de energia.

O modelo de driver de bateria é um modelo de porta/miniporto, ou seja, o modelo de bateria e as interfaces são definidas de modo que os novos tipos de bateria possam ser expostos por meio de um miniporto. No entanto, na prática, há apenas dois miniportos que têm qualquer uso significativo no ecossistema do Windows - o driver de miniporta de bateria que dá suporte às baterias do método de controle ACPI e o driver de miniporto de bateria HID para dispositivos UPS (fonte de alimentação ininterrupta) anexadas a USB.

Espera-se que todos os computadores exponham as baterias e o subsistema de carregamento por meio da interface do método de controle ACPI. A interface da miniporta da bateria não deve ser usada para subsistemas de carregamento de bateria específicos da plataforma. Há métodos de controle definidos pela especificação de ACPI que permitem ao Windows sondar informações de bateria e status. Da mesma forma, há um modelo controlado por eventos para permitir que a plataforma de hardware notifique o Windows sobre alterações de bateria e fonte de energia, como uma transição do AC para a energia da bateria.

Sondagem de status

O gerenciador de energia do Windows solicita periodicamente status informações da bateria, incluindo a capacidade de carga restante e a taxa atual de drenagem. Essa solicitação tem origem no power manager, em um componente de interface do usuário de nível superior ou no aplicativo. O gerenciador de energia transforma a solicitação em um IRP (Pacote de Solicitação de E/S) para os dispositivos de bateria. Quando a bateria é exposta por meio da interface do método de controle ACPI, o driver de bateria do método de controle (cmbatt.sys) executa os métodos de controle ACPI apropriados. No caso de informações de status, o método _BST (status de bateria) é executado.

O método _BST requer que o firmware acpi obtenha informações atuais do subsistema de energia e, em seguida, empacota essas informações em um buffer com o formato especificado pela especificação acpi. O código específico necessário para acessar a bateria status do controlador inserido ou do carregador de bateria conectado por meio de I²C está contido no firmware ACPI e parte do código que inclui o método _BST. O resultado líquido do método _BST é o buffer de informações necessárias que é retornado ao driver de bateria do método de controle. O driver de bateria do método de controle finalmente converte o buffer no formato exigido pelo driver da bateria e pelo gerenciador de energia do Windows.

Notificações de alteração de estado

O subsistema de energia e bateria gerará várias notificações ao Windows para alterações de estado, incluindo transições do AC para a energia da bateria. A sondagem feita pelo Windows para essas alterações de estado não é prática, dada a alta frequência com que a sondagem seria necessária. Portanto, a plataforma de hardware deve usar um modelo controlado por eventos para notificar o Windows quando o estado da bateria mudar significativamente.

Quando a bateria status é alterada, incluindo capacidade restante ou status de carregamento, o firmware ACPI emite um Notify(0x80) no dispositivo de bateria do método de controle. O driver de bateria do método de controle do Windows avalia o método _BST e retorna as informações atualizadas para o gerenciador de energia.

Quando os dados estáticos da bateria são alterados, incluindo a última capacidade de carga total, capacidade de design e contagem de ciclos, o firmware ACPI emite um Notify(0x81) no dispositivo de bateria do método de controle. O driver de bateria do método de controle do Windows avalia o método _BIX e retorna as informações atualizadas para o gerenciador de energia.

A plataforma interrompe o ambiente de firmware acpi por meio da SCI (Interrupção de Controle do Sistema) no caso de uma plataforma equipada com controlador inserido e por meio de um GPIO no caso de plataformas com hardware de subsistema de bateria conectado diretamente ao silício principal.

Operação ACPI com um controlador inserido

As plataformas que têm o subsistema de bateria e energia conectados ao controlador inserido típico usam a região de operação controlador incorporado ACPI para facilitar a comunicação entre o ambiente do método de controle ACPI e o hardware da plataforma.

O firmware ACPI deve definir o controlador inserido no namespace acpi, conforme descrito na seção 12.11.1 da especificação acpi, incluindo:

• Um nó Device() para o controlador inserido.
• Um objeto _HID que indica que o dispositivo é um controlador inserido.
• Um objeto _CRS para indicar os recursos de E/S para o controlador inserido.
• Um objeto _GPE que define o SCI para o controlador inserido.
• Uma região de operação que descreve as informações contidas no controlador incorporado que podem ser acessada por outro código de método de controle ACPI no namespace, incluindo o status da bateria e métodos de informações.

Detalhes completos são descritos na seção 12 da especificação acpi.

Acessando informações de bateria do controlador inserido

O método de controle ACPI acessa as informações do controlador inserido lendo os valores descritos na região de operação do controlador inserido.

Notificando o sistema operacional quando o estado da bateria é alterado

Quando o controlador inserido detecta uma alteração no estado da bateria, incluindo uma alteração no estado de carregamento ou na capacidade restante, conforme especificado por _BTP, o controlador inserido gera um SCI e define o SCI_EVT bit no registro do comando de status do controlador inserido (EC_SC). O driver ACPI do Windows se comunicará com o controlador inserido e emitirá um comando de consulta (QR_EC) para solicitar informações específicas sobre a notificação a ser emitida. Em seguida, o controlador inserido define um valor de byte correspondente ao método _QXX a ser executado. Por exemplo, o controlador inserido e o firmware ACPI podem definir o valor 0x33 ser uma atualização para a bateria status informações. Quando o controlador inserido define o valor 0x33 como a notificação, o driver ACPI executará o método _QXX. O conteúdo do método _QXX normalmente será um Notify(0x80) no dispositivo de bateria do método de controle no namespace .

Operação ACPI com um sistema de carregamento conectado de I²C

As plataformas também podem conectar a bateria e o subsistema de energia conectados ao chipset principal por meio de um barramento serial de baixa potência, como o I²C. Nesses designs, a região de operação GenericSerialBus da ACPI é usada para se comunicar entre os métodos de controle ACPI e o hardware do subsistema de bateria. Conectar o hardware do subsistema de bateria a uma interrupção gpio permite que os métodos de controle ACPI sejam executados quando uma bateria status é alterada.

Quando o hardware do subsistema de bateria e energia é conectado por meio de I²C, o firmware acpi deve definir:

• Um nó Device() para o dispositivo controlador GPIO ao qual a interrupção I²C está conectada, incluindo:

  • _HID objeto que descreve a ID de hardware do controlador GPIO.
  • Objeto _CSR que descreve os recursos de interrupção e hardware do controlador GPIO.
  • _AEI objeto que mapeia uma ou mais linhas GPIO para a execução do método de evento ACPI. Isso permite que os métodos ACPI sejam executados em resposta a interrupções de linha GPIO.

• Um nó Device() para o controlador I²C ao qual o medidor de combustível da bateria e o hardware de carregamento estão conectados, incluindo:

  • _HID e _CSR objetos que descrevem a ID de hardware e os recursos do controlador I²C.
  • Uma GenericSerialBus OperationRegion dentro do escopo do dispositivo I²C que descreve os registros de comando virtual para o dispositivo I²C.
  • Definições de campo dentro de GenericSerialBus OperationRegion. As definições de campo permitem que o código ASL fora do dispositivo I²C acesse os registros de comando virtual para o dispositivo I²C.

Descrever o controlador GPIO e o mapeamento de linhas GPIO para eventos ACPI permite que os métodos de controle para status de bateria e notificação sejam executados quando uma interrupção GPIO de um dispositivo I²C é gerada. Descrever a região de operação GenericSerialBus permite que o código ACPI para status de bateria se comunique pelo barramento I²C e leia registros e informações do medidor de combustível da bateria e do subsistema de carregamento.

Acessando informações de bateria do sistema de carregamento

A status de bateria pode ser executada por métodos de controle ACPI enviando e recebendo comandos sobre o barramento I²C ao qual o hardware do subsistema da bateria está conectado. O código do método de controle que dá suporte aos métodos de informações estáticas de status e bateria lê e grava dados das regiões de operação GenericSerialBus descritas no namespace ACPI. O código do método de controle lê os dados do dispositivo do medidor de combustível ou informações estáticas sobre a capacidade da bateria e as contagens de ciclo sobre o barramento I²C por meio da região de operação GenericSerialBus.

Notificando o Windows quando o estado da bateria é alterado

Uma interrupção pode ser gerada pelo hardware do subsistema da bateria quando o estado é alterado e a interrupção está fisicamente conectada a uma linha GPIO no silício principal. A linha GPIO pode ser mapeada para uma execução de método de controle específica usando o objeto _AEI no controlador GPIO descrito em ACPI. Quando ocorre a interrupção do GPIO, o subsistema ACPI do Windows executa o método associado à linha GPIO específica que, por sua vez, pode fazer um Notify() no dispositivo de bateria do método de controle, fazendo com que o Windows revalie os métodos de informações estáticas e status para atualizar a bateria status.

Implementação de ACPI do objeto de fonte de alimentação

O firmware ACPI deve implementar um dispositivo de fonte de energia ACPI. Esse objeto deve relatar a si mesmo com uma ID de hardware (_HID) de "ACPI0003". Esse objeto também deve implementar o método acpi _PSR (Power Source). Esse método retorna o status da fonte de alimentação e transmite se a fonte de alimentação está online (alimentação AC) ou offline (na energia da bateria). Todas as fontes de energia de entrada para o sistema devem ser multiplexadas por meio de um único método de _PSR. Por exemplo, _PSR deve transmitir online se o sistema é alimentado por meio de um conector de barril dc ou um conector de encaixe separado. Não use vários dispositivos ACPI de fonte de energia.

O método _PSR só deve relatar a energia online (AC) quando o sistema estiver conectado à energia da rede elétrica. Quando o estado de _PSR é alterado, a plataforma deve gerar uma interrupção e um Notify(0x80) no dispositivo no namespace ACPI. Isso deve ser executado imediatamente após a alteração de estado físico ser detectada pela plataforma.

Implementação de ACPI de informações estáticas da bateria

O firmware ACPI deve implementar o método acpi _BIX para cada bateria que fornece informações estáticas sobre a bateria, incluindo capacidade de design, contagem de ciclos e número de série. A tabela a seguir expande as definições dos campos descritos na especificação acpi e enumera os requisitos específicos do Windows para essas informações.

Implementação de ACPI de informações de status em tempo real da bateria

O firmware ACPI deve implementar o método acpi _BST para cada bateria que fornece informações de status em tempo real sobre a bateria, incluindo a capacidade restante e a taxa atual de esvaziamento. A tabela a seguir expande as definições dos campos descritos na especificação acpi e enumera os requisitos específicos do Windows para essas informações.

Quando qualquer dado no _BST é alterado, a plataforma deve gerar uma interrupção e um Notify(0x80) no dispositivo de bateria no namespace ACPI. Isso deve ser executado imediatamente após a alteração de estado físico ser detectada pela plataforma. Isso inclui qualquer alteração no campo Estado da Bateria para os bits de carregamento (ou seja, Bit0) ou descarregação (ou seja, Bit1).

Além disso, a plataforma deve implementar o _BTP-Battery Trip Point-method. _BTP permite que o Windows especifique um limite de capacidade restante que, quando cruzado, a plataforma deve gerar uma interrupção e um Notify(0x80) no dispositivo de bateria no namespace ACPI. O método _BTP impede que o Windows precise sondar a bateria periodicamente.

Métodos de controle de bateria

A especificação ACPI oferece métodos de controle específicos do dispositivo e do sistema operacional por meio do método específico ao dispositivo ou método de controle _DSM. _DSM é descrito na seção 9.14.1 da especificação de ACPI.

O Windows dá suporte aos seguintes métodos _DSM para dispositivos de bateria de método de controle.

Direção da taxa de carga térmica

Bateria útil do usuário

Watchdog de carregamento necessário

Drivers de miniporta de bateria de terceiros

Em Windows 10, os OEMs e os IHVs podem desenvolver seus próprios drivers de miniporta de bateria de terceiros para substituir o driver do Microsoft cmbatt.sys e se comunicar diretamente com o hardware da bateria. Um driver de bateria de exemplo é fornecido pela Microsoft no GitHub e como parte do kit de exemplos do WDK.

Carregamento USB (Windows 10 para edições desktop)

A Microsoft reconhece o valor em fornecer a opção de dar suporte ao carregamento USB de um dispositivo móvel. Com esforços de padronização, como a mudança da UE para padronizar carregadores de telefones celulares, os carregadores USB estão amplamente disponíveis e funcionam em uma ampla variedade de dispositivos, incluindo Windows Phones, mp3 players, dispositivos GNSS etc. A Microsoft entende o valor de oferecer um único carregador que pode ser usado para carregar vários dispositivos, incluindo um dispositivo que executa o Windows. Além disso, dado o amplo suporte do setor para o carregamento usb, há benefícios auxiliares que reduzem os custos e o impacto ambiental.

Começando com Windows 8, um dispositivo móvel pode ser alimentado e/ou carregado por meio de USB, desde que os requisitos de carregamento da bateria descritos abaixo sejam atendidos. Além disso, há uma série de requisitos específicos de USB que devem ser atendidos para garantir uma experiência de usuário de qualidade.

1. A energia/carga USB deve ser implementada inteiramente no firmware da plataforma. O suporte não deve exigir um sistema operacional, um driver ou um aplicativo.

2. O dispositivo NÃO DEVE enumerar quando conectado a outro dispositivo. Como resultado, o dispositivo não cobrará quando conectado a uma porta USB de computador padrão, pois essas portas são limitadas a 500mA por padrão. As únicas exceções são quando essa porta é usada para depuração e para programação inicial de firmware de fábrica.

3. O dispositivo dá suporte ao carregamento de uma porta de carregamento USB dedicada. O dispositivo deve carregar quando conectado a um carregador compatível com a especificação de carregamento de bateria USB versão 1.2. O dispositivo não deve desenhar mais de 1,5A por padrão de carregamento quando conectado a um carregador USB padrão. O OEM pode optar por dar suporte a níveis atuais mais altos, desde que as seguintes condições sejam atendidas:

   • O dispositivo detecta automaticamente o tipo de carregador e cobra na taxa apropriada para o tipo de carregador específico.
   • O dispositivo e o carregador atendem a todos os padrões elétricos e de segurança relevantes.
   • O OEM envia o carregador e o cabo associado ao dispositivo.

4. Há suporte para carregamento USB em um receptáculo micro-AB padrão, USB-C (recomendado) ou um conector de encaixe proprietário. Um recipiente microB NÃO é permitido no dispositivo. Se estiver usando um conector de encaixe proprietário, o OEM deverá enviar um cabo apropriado com o dispositivo para habilitar o carregamento de um carregador USB padrão.

5. Se a porta micro AB for implementada, o dispositivo deverá detectar automaticamente o tipo de cabo, a configuração e assumir a função apropriada. Se um plugue micro-B for inserido e a depuração não estiver habilitada na porta, a função de carregador deverá ser assumida. Se um plug micro-B for inserido e a depuração estiver habilitada na porta, a função de depuração deverá ser assumida (ou seja, não há suporte para carregamento). Se um plug-a-micro-A for inserido, a função de host USB será assumida quando os dispositivos USB anexados forem reconhecidos pelo Windows.

6. Se a porta micro AB também funcionar como uma porta de depuração, o dispositivo deverá fornecer um meio por meio de firmware para alternar entre o carregador e a função de depuração. A configuração padrão como enviada para o usuário final deve ter depuração DESABILITADO.

7. Se a porta micro AB também funcionar como uma porta de depuração, o dispositivo deverá fornecer um caminho de energia de entrada alternativo por meio de um conector de barril dedicado ou conector de encaixe proprietário.

Listas de verificação do designer e do implementador de plataforma

Você pode usar as listas de verificação a seguir para validar o design da plataforma e o firmware do sistema aderir às diretrizes do subsistema de carga e bateria descritas.

Lista de verificação de implementação do subsistema de bateria e do firmware ACPI

Os designers do sistema devem garantir que tenham concluído as seguintes tarefas em seu firmware ACPI para garantir o relatório correto das informações do subsistema de bateria e energia para o Windows:

• Adicione um objeto Device() para cada dispositivo de bateria no namespace ACPI.

• Cada dispositivo de bateria deve fornecer os seguintes métodos de controle e objetos:

  • _HID com um valor de PNP0C0A.
  • _BIX-Battery Information Extended:

  Transmite as informações estáticas da bateria, incluindo a última capacidade de carga completa, capacidade de design e contagem de ciclos.

  • _BST-Battery Status:

    Transmite a bateria atual status, incluindo a capacidade restante, a taxa de drenagem e o estado de carregamento.

  • Ponto de viagem _BTP bateria:

    Permite que um modelo de status de bateria controlado por eventos reduza o trabalho periódico para sondagem. _BTP permite que o Windows especifique um limite de capacidade de carga restante na qual a plataforma deve emitir em Notify(0x80) no dispositivo de bateria para solicitar que o Windows atualize as informações de status da bateria.

  • status geral do _STA:

    Permite que o Windows saiba se a bateria está presente no dispositivo em que uma bateria pode ser removível ou onde pode haver uma bateria em uma doca portátil.

• Adicione um único objeto Device() para um adaptador AC/Fonte de Energia no namespace ACPI.

• O dispositivo de fonte de energia deve fornecer os seguintes métodos de controle e objetos:

  • _HID com um valor de ACPI0003

  • Fonte de energia do _PSR:

    Transmite se a fonte de alimentação está online (energia AC) ou offline (com energia da bateria). Todas as fontes de energia de entrada para o dispositivo devem ser multiplexadas por meio do método _PSR. Por exemplo, o _PSR deve transmitir online se o dispositivo é alimentado por meio de um conector de barril dc ou conector de encaixe separado. Não use vários dispositivos ACPI de fonte de energia.

• O método _BIX deve dar suporte aos campos e restrições descritos nas informações estáticas da bateria acima:

  • O campo Revisão deve ser definido como 0x0.
  • O campo Unidade de Energia deve ser definido como 0x0.
  • Os valores Capacidade de Design e Última Capacidade de Carga Total devem ser definidos com valores precisos da bateria e do subsistema de carregamento e não definidos como 0xFFFFFFFF ou 0x00000000.
  • O campo Tecnologia da Bateria deve ser definido como 0x1.
  • O campo Tensão de Design deve ser definido com precisão e não igual a 0x00000000 ou 0xFFFFFFFF.
  • A Capacidade de Design de Baixa deve ser definida com o valor mínimo necessário para Hibernar ou Desligar o sistema de um estado totalmente ativado.
  • Os campos Granularidade de Capacidade da Bateria 1 e Granularidade de Capacidade da Bateria 2 devem ser definidos como um valor não maior que 1% da capacidade de design da bateria.
  • O campo Contagem de Ciclos deve ser preenchido com precisão do subsistema de bateria.
  • O campo Precisão da Medida deve ser definido como 80.000d ou melhor.
  • Os campos Número do Modelo e Número de Série não devem ser definidos como NULL.

• Forneça um método _BST que permite ao Windows sondar status de bateria em tempo real. Todos os campos no método _BST devem ser retornados dinamicamente do subsistema de carregamento de bateria e energia subjacente. Sua precisão deve estar dentro do valor de Precisão da Medida no método _BIX.

• Forneça um método _BTP que permite ao Windows especificar um limite de capacidade de carga restante no qual a plataforma interromperá o Windows com um Notify(0x80) no dispositivo de bateria.

• Verifique se um Notify(0x80) só é emitido em resposta a uma alteração de status de bateria ou _BTP viagem de limite de capacidade de carga. Não execute uma Notify(0x80) periodicamente.

• Quando o nível da bateria atinge o valor especificado em _BIX. DesignCapacityofLow, a plataforma deve gerar um Notify(0x80) no dispositivo de bateria do método de controle.

• Para sistemas com várias baterias, implemente totalmente um dispositivo de bateria de método de controle para cada bateria.

  • A primeira bateria no namespace deve ser a bateria primária do sistema para auxiliar na depuração.

• Implemente o método _DSM em cada dispositivo de bateria para indicar se a bateria é útil para o usuário.

• Implemente o método _DSM se uma redefinição periódica de watchdog for necessária durante o carregamento e o Windows garantirá a execução periódica do método _BST dentro dessa janela de sondagem.

• Implemente o método _DSM se o controle de taxa de carregamento da bateria for necessário para o modelo térmico na plataforma.