Akku und Aufladung

Benutzererfahrung beim Laden des Akkus

In diesem Thema werden Empfehlungen zum Akku und Aufladen in Windows 10 behandelt. Alle Geräte, auf denen Windows ausgeführt wird, haben unabhängig von Formfaktor, Befehlssatz oder Plattformarchitektur ein konsistentes Akkuladeerlebnis. Infolgedessen haben die Benutzer eine konsistente und qualitativ hochwertige Erfahrung mit dem Laden der Batterie.

1. Der Ladevorgang erfolgt immer bei Anschluss an das Ladegerät.

   Abgesehen von Fällen eines Akkuausfalls ist ein Gerät mit Windows immer in der Lage, den Akku aufzuladen, wenn es an das Ladegerät angeschlossen ist.

2. Windows kann immer booten, wenn es an das Ladegerät angeschlossen ist.

   • Windows 10 für Desktop-Editionen (Home, Pro, Enterprise und Education):

     Befindet sich das Gerät im S5 (Shutdown-Zustand), kann es immer in Windows booten, wenn es an das Ladegerät angeschlossen ist, unabhängig vom Ladezustand des Akkus und Vorhandensein des Akkus, wenn der Akku entfernbar ist.

   • Windows 10 Mobile:

     Eine Batterie muss vorhanden und ausreichend geladen sein, damit das System hochfahren kann.

3. Die Hardware verwaltet den Ladevorgang autonom.

   Die Hardware lädt den Akku des Geräts auf, ohne dass Firmware, Windows, Treiber oder andere Software auf der/den Haupt-CPU(s) ausgeführt werden müssen. Diese Anforderung gilt nur für Systeme mit Windows 10 für Desktop-Editionen. Windows 10 Mobile-Systeme erfordern möglicherweise die Unterstützung einer UEFI-Lade-App und/oder anderer Softwarekomponenten, um den Akku aufzuladen.

4. Der Ladevorgang stoppt automatisch, wenn der Akku vollständig geladen ist oder wenn ein Fehler auftritt.

   Die Hardware stoppt den Ladevorgang automatisch, wenn der Akku vollständig aufgeladen ist. Dies erfolgt, ohne dass Firmware, Windows, Treiber oder andere Software auf der/den Haupt-CPU(s) ausgeführt werden müssen. Bei einem Batterie- oder thermischen Fehlerzustand wird der Ladevorgang ebenfalls automatisch gestoppt.

Der Ladevorgang erfolgt bei Anschluss an das Ladegerät

Benutzer erwarten, dass ihr Gerät aufgeladen wird, wenn es an das Ladegerät angeschlossen ist. Daher muss die Hardware immer versuchen, den Akku aufzuladen, wenn das Gerät an das Ladegerät angeschlossen ist, unabhängig vom Stromversorgungszustand. Diese Erwartung gilt für alle Energiezustände, einschließlich aktiv (S0), Energiesparmodus (S3), Ruhezustand (S4), Herunterfahren (S5), Hard-off (G2/G3) und S0-Leerlauf. Der Ladevorgang kann beendet werden, sobald der Akku vollständig aufgeladen ist oder wenn ein Fehlerzustand auftritt.

Wir empfehlen kein Design, das den Akku mit einer reduzierten Rate auflädt, wenn Windows oder die Firmware nicht gestartet wurde oder ausgeführt wird. Beispielsweise kann der Akku langsamer geladen werden, wenn das System vollständig ausgeschaltet und an das Ladegerät angeschlossen ist, und schneller geladen werden, wenn das Gerät gestartet wird, und die ACPI-Firmware kann verwendet werden, um den Akku regelmäßig zu überwachen.

Schließlich kann ein Design die Batterie mit einer niedrigeren Rate laden, wenn sich das System in einem thermischen Zustand befindet. In diesem Szenario kann die Wärme reduziert werden, indem das Aufladen der Batterie verlangsamt oder vollständig eliminiert wird. Thermische Bedingungen sind die Ausnahme in jedem guten Systemdesign.

Windows ist immer bootfähig, wenn es an das Stromnetz angeschlossen ist

• Windows 10-Desktopeditionen

  Benutzer erwarten, dass sie ihr Gerät sofort starten und verwenden können, wenn es an das Ladegerät angeschlossen ist. Daher muss das Gerät immer booten und voll funktionsfähig sein, wenn es an das Stromnetz angeschlossen ist. Dies gilt unabhängig vom Ladezustand des Akkus, dem Zustand des Akkus/Ladegeräts und dem Vorhandensein des Akkus (wenn der Akku abnehmbar ist).

  Benötigt das Gerät eine Mindestakkukapazität zum Booten der Firmware und von Windows, muss die Hardware dafür sorgen, dass immer Akkukapazität von der Plattform reserviert wird. Die reservierte Akkukapazität darf Windows nicht ausgesetzt werden.

• Windows 10 Mobile

  Wenn das System an das Stromnetz angeschlossen und der Akku vorhanden ist, sollte das System versuchen, das Betriebssystem zu starten, solange der Akku ausreichend aufgeladen ist, um das System während des Startvorgangs mit Strom zu versorgen.

Die Hardware verwaltet den Ladevorgang autonom

Wie oben angegeben, erwarten Benutzer, dass ihr Gerät aufgeladen wird, wenn es an das Ladegerät angeschlossen ist. Infolgedessen muss die Hardware den Akku aufladen, ohne dass Firmware, Windows, Treiber oder andere Software auf der/den Haupt-CPU(s) ausgeführt werden müssen, da eine oder mehrere dieser Komponenten zu einem bestimmten Zeitpunkt möglicherweise nicht betriebsbereit sind oder sich in einem Fehlerzustand befinden. Diese Anforderung gilt nur für Systeme mit Windows 10 für Desktop-Editionen. Windows 10 Mobile-Systeme erfordern möglicherweise die Unterstützung einer UEFI-Lade-App und/oder anderer Softwarekomponenten, um den Akku aufzuladen.

Der Ladevorgang stoppt automatisch, wenn er vollständig aufgeladen ist oder wenn ein Fehler auftritt

Die Hardware beendet den Ladevorgang automatisch, wenn der Akku vollständig geladen ist oder ein Fehler aufgetreten ist. Wie beim Aufladen muss dies erfolgen, ohne dass Firmware, Windows, Treiber oder andere Software auf der/den Haupt-CPU(s) ausgeführt werden müssen. Außerdem muss die Hardware alle regulatorischen Bedingungen für die Batteriesicherheit erfüllen.

Betriebs- und Ladeanzeigen

Windows bietet eine Stromquelle und eine Batteriestatusanzeige mit Symbolen, die der Benutzer an mehreren Stellen sehen kann. Zu den Orten gehören das Batteriesymbol in der Taskleiste und der Sperrbildschirm.

Ein Gerät kann auch eine physische Anzeige haben, wie z. B. eine LED, die den Ladestatus anzeigt. Diese Anzeige darf wenig Einfluss auf den Stromverbrauch haben.

Windows Power- und Ladesymbole

Windows zeigt die Stromquelle und den Ladestatus an drei Stellen an:

• Auf dem Sperrbildschirm:

  Windows zeigt ein Batteriesymbol mit der Stromquelle und dem Ladestatus an.

• Desktop-Taskleiste (nur Windows 10 für Desktop-Editionen):

  Windows zeigt ein Batteriesymbol mit Stromquelle und Ladestatus an. Wenn der Benutzer auf das Batteriesymbol klickt, kann er Informationen wie die verbleibende Kapazität, die geschätzte verbleibende Zeit und Details pro Batterie (falls mit mehreren Batterien ausgestattet) anzeigen.

• Statusleiste (nur Mobile-SKU):

  Windows zeigt ein Batteriesymbol mit Stromquelle und Ladestatus an. Wenn der Benutzer vom oberen Bildschirmrand nach unten wischt, um das Aktionszentrum zu erweitern, kann er den tatsächlichen Batterieprozentsatz anzeigen.

• Energiespareinstellungen:

  Auf der Einstellungsseite von Battery Saver (Einstellungen –> System –> Battery Saver) zeigt Windows den Gesamtakkuprozentsatz, den Akkustatus (Laden vs. Entladen) und die geschätzte verbleibende Zeit zum Laden/Entladen an.

Bei Plattformen mit S0-Leerlauffunktion leuchtet Windows, wenn das Display sichtbar ist, kurz auf, wenn das System an das Ladegerät angeschlossen oder davon getrennt wird, um den Benutzer über einen Wechsel der Stromquelle zu informieren.

Plattform-Hardware-Ladeanzeigen

Die in Windows integrierten Symbole beziehen sich nur auf Szenarien, in denen Windows ausgeführt wird und die Anzeige für den Benutzer sichtbar ist. Die Bildschirmanzeigen sind jedoch nicht sichtbar, wenn das System heruntergefahren ist oder im S0-Ruhezustand, in dem das Display ausgeschaltet ist. Da der Benutzer keine visuellen Hinweise auf dem Bildschirm sehen kann, kann die Plattform eine physische Ladeanzeige umfassen, um anzuzeigen, dass Strom vorhanden ist.

Der folgende Abschnitt enthält unsere Empfehlung für die Implementierung von Tastaturen und Mäusen/Touchpads auf S0-Idle-Plattformen mit Docking-Lösungen. In diesem Abschnitt werden auch die Herausforderungen und Prinzipien sowie mögliche Lösungen beschrieben. Beide möglichen Lösungen gelten für mobile und mit Klimaanlage betriebene stationäre Docks.

Offenlegen des Stromversorgungs- und Ladesubsystems für Windows

Jedes mobile Gerät, auf dem Windows ausgeführt wird, enthält einen oder mehrere Akkus und eine Stromquelle, z. B. ein Netzteil. Informationen von diesen Subsystemen übermitteln dem Benutzer den Energieverwaltungsstatus. Der Status umfasst jederzeit die verbleibende Batteriekapazität, den Zustand des Netzteils und des Batterieladevorgangs sowie die geschätzte verbleibende Batteriezeit. Die Informationen zum Energiesubsystem werden in der Windows-Akkuanzeige und anderen Diagnosedienstprogrammen für die Energieverwaltung angezeigt.

Der folgende Abschnitt enthält unsere Empfehlung für die Implementierung von Tastaturen und Mäusen/Touchpads auf S0-Idle-Plattformen mit Docking-Lösungen. In diesem Abschnitt werden auch die Herausforderungen und Prinzipien sowie mögliche Lösungen beschrieben. Beide möglichen Lösungen gelten für mobile und mit Klimaanlage betriebene stationäre Docks.

Typische Hardwaretopologien für Stromversorgungssubsysteme

Im Allgemeinen erwartet Windows eine von zwei Hardwaretopologien für das Stromversorgungs- und Ladesubsystem.

Die folgende Abbildung zeigt die erste Topologie, die den Embedded Controller der Plattform verwendet, der bei bestehenden Geräten mit Windows üblich ist. Der Embedded Controller führt mehrere Funktionen in einem mobilen Gerät aus, einschließlich Stromquellensteuerung, Batterielademanagement, Netzschalter-/Schaltererkennung und PS/2-kompatible Tastatur- und Mauseingabe. Der eingebettete Controller ist typischerweise über den LPC-Bus (Low Pin Count) mit dem Kern-Silizium verbunden. Windows fragt Informationen zum Stromversorgungssubsystem ab und wird über die integrierte ACPI-Controller-Schnittstelle benachrichtigt.

Die nächste Abbildung zeigt die zweite Topologie, die einen Batterieladeregler und eine Komponente zur Kraftstoffanzeige verwendet, die über einen leichten Peripheriebus wie I²C direkt mit dem Kernsilizium der Plattform verbunden sind. In dieser Konfiguration fragt Windows Änderungen am Stromversorgungssubsystem ab und wird über die Kommunikation über den I²C-Bus benachrichtigt. Anstatt einen Gerätetreiber für das Akku- oder Ladesubsystem zu verwenden, wird die Umgebung der ACPI-Steuerungsmethode um die Unterstützung einer SPB-Operationsregion (Simple Peripheral) erweitert. Die SPB-Betriebsregion ermöglicht den ACPI-Steuerungsmethodencode, die mit dem Kern-Silizium über I²C verbunden sind, an den Akkuladeregler und Kraftstoffmesserkomponenten zu kommunizieren.

Batterie- und Stromversorgungs-Subsystem-Treibermodell

Windows verfügt über ein robustes Batterie- und Stromversorgungs-Subsystem-Gerätetreibermodell. Die Energieverwaltungsinformationen werden über einen Batteriegerätetreiber an den Windows-Energiemanager übermittelt, dann aggregiert und über die Batteriegeräte-IRPs und eine Reihe von Energieverwaltungssoftware-APIs der Windows-Benutzeroberfläche bereitgestellt.

Das Batterietreibermodell ist ein Port/Miniport-Modell – das heißt, das Batteriemodell und die Schnittstellen sind so definiert, dass die neuen Batterietypen über einen Miniport verfügbar gemacht werden können. In der Praxis gibt es jedoch nur zwei Miniports, die einen nennenswerten Nutzen im Windows-Ökosystem haben – der Batterie-Miniport-Treiber, der die Batterien der ACPI-Steuerungsmethode unterstützt, und der HID-Batterie-Miniport-Treiber für über USB angeschlossene unterbrechungsfreie Stromversorgungsgeräte (USV).

Von allen PCs wird erwartet, dass sie die Akkus und das Ladesubsystem über die Schnittstelle der ACPI-Steuerungsmethode verfügbar machen. Die Batterie-Miniport-Schnittstelle sollte nicht für plattformspezifische Batterieladesubsysteme verwendet werden. Es gibt von der ACPI-Spezifikation definierte Steuerungsmethoden, die es Windows ermöglichen, Akkuinformationen und -status abzufragen. In ähnlicher Weise gibt es ein ereignisgesteuertes Modell, mit dem die Hardwareplattform Windows über Änderungen der Batterie und der Stromquelle benachrichtigen kann, z. B. einen Übergang von Wechselstrom zu Batteriestrom.

Statusabfrage

Der Windows-Energiemanager fordert regelmäßig Statusinformationen vom Akku an, einschließlich der verbleibenden Ladekapazität und der aktuellen Entladerate. Diese Anforderung stammt aus dem Power Manager, einer Benutzerschnittstellenkomponente oder Anwendung auf höherer Ebene. Der Energiemanager wandelt die Anforderung in ein E/A-Anforderungspaket (IRP) an das/die Batteriegerät(e) um. Wenn die Batterie über die Schnittstelle der ACPI-Steuerungsmethoden verfügbar gemacht wird, führt der Batterietreiber der Steuerungsmethode (cmbatt.sys) die entsprechenden ACPI-Steuerungsmethoden aus. Bei Statusinformationen wird die Methode _BST (Batteriestatus) ausgeführt.

Die _BST-Methode erfordert, dass die ACPI-Firmware aktuelle Informationen vom Stromversorgungssubsystem erhält und diese Informationen dann in einem Puffer mit dem von der ACPI-Spezifikation angegebenen Format verpackt. Der spezifische Code, der für den Zugriff auf den Batteriestatus entweder vom eingebetteten Controller oder dem über I²C angeschlossenen Batterieladegerät erforderlich ist, ist in der ACPI-Firmware und einem Teil des Codes enthalten, der die _BST-Methode umfasst. Das Nettoergebnis der _BST-Methode ist der erforderliche Informationspuffer, der an den Steuermethode-Batterietreiber zurückgegeben wird. Die Steuermethode Batterietreiber konvertiert schließlich den Puffer in das Format, das der Batterietreiber und der Windows-Energiemanager benötigen.

Benachrichtigungen über Statusänderungen

Das Stromversorgungs- und Batteriesubsystem generiert mehrere Benachrichtigungen an Windows für Zustandsänderungen, einschließlich Übergänge von Wechselstrom- zu Batteriestrom. Das Abrufen dieser Zustandsänderungen durch Windows ist angesichts der hohen Häufigkeit, mit der das Abrufen erforderlich wäre, nicht praktikabel. Daher muss die Hardwareplattform ein ereignisgesteuertes Modell verwenden, um Windows zu benachrichtigen, wenn sich der Akkustatus erheblich ändert.

Wenn sich der Batteriestatus ändert, einschließlich der verbleibenden Kapazität oder des Ladestatus, gibt die ACPI-Firmware eine Notify (0x80) auf dem Batteriegerät der Steuermethode aus. Der Batterietreiber der Windows-Steuerungsmethode wertet dann die _BST-Methode aus und gibt die aktualisierten Informationen an den Energiemanager zurück.

Wenn sich die statischen Daten der Batterie ändern, einschließlich der letzten vollen Ladekapazität, der Entwurfskapazität und der Zykluszahl, gibt die ACPI-Firmware eine Notify (0x81) auf dem Batteriegerät der Steuermethode aus. Der Batterietreiber der Windows-Steuerungsmethode wertet dann die _BIX-Methode aus und gibt die aktualisierten Informationen an den Energiemanager zurück.

Die Plattform unterbricht die ACPI-Firmwareumgebung durch den System Control Interrupt (SCI) im Fall einer mit Embedded Controller ausgestatteten Plattform und durch einen GPIO im Fall von Plattformen mit Batterie-Subsystem-Hardware, die direkt mit dem Kern-Silizium verbunden ist.

ACPI-Betrieb mit einem eingebetteten Controller

Plattformen, deren Batterie- und Stromversorgungssubsystem mit dem typischen eingebetteten Controller verbunden sind, verwenden den Betriebsbereich des ACPI-Embedded-Controllers, um die Kommunikation zwischen der Umgebung des ACPI-Steuerverfahrens und der Plattformhardware zu erleichtern.

Die ACPI-Firmware muss den eingebetteten Controller im ACPI-Namespace definieren, wie in Abschnitt 12.11.1 der ACPI-Spezifikation beschrieben, einschließlich:

• Ein Device()-Knoten für den eingebetteten Controller.
• Ein _HID-Objekt, das angibt, dass das Gerät ein eingebetteter Controller ist.
• Ein _CRS-Objekt zum Bezeichnen der E/A-Ressourcen für den eingebetteten Controller.
• Ein _GPE-Objekt, das den SCI für den eingebetteten Controller definiert.
• Ein Betriebsbereich, der die im eingebetteten Controller enthaltenen Informationen beschreibt, auf die durch anderen ACPI-Steuerungsmethodencode im Namespace zugegriffen werden kann, einschließlich Batteriestatus und Informationsmethoden.

Vollständige Details sind in Abschnitt 12 der ACPI-Spezifikation beschrieben.

Zugriff auf Batterieinformationen vom eingebetteten Controller

Das ACPI-Steuerverfahren greift auf die Informationen des eingebetteten Controllers zu, indem es die im Betriebsbereich des eingebetteten Controllers beschriebenen Werte liest.

Benachrichtigen des Betriebssystems, wenn sich der Batteriezustand ändert

Wenn der eingebettete Controller eine Änderung des Batteriezustands erkennt, einschließlich einer Änderung des Ladezustands oder der verbleibenden Kapazität, wie durch _BTP angegeben, generiert der eingebettete Controller ein SCI und setzt das Bit SCI_EVT im Statusbefehlsregister des eingebetteten Controllers (EC_SC). Der Windows-ACPI-Treiber kommuniziert mit dem eingebetteten Controller und gibt einen Abfragebefehl (QR_EC) aus, um bestimmte Informationen über die auszugebende Benachrichtigung anzufordern. Der eingebettete Controller setzt dann einen Bytewert, der der auszuführenden _QXX-Methode entspricht. Beispielsweise können der eingebettete Controller und die ACPI-Firmware den Wert 0x33 als Aktualisierung der Batteriestatusinformationen definieren. Wenn der eingebettete Controller den Wert 0x33 als Benachrichtigung festlegt, führt der ACPI-Treiber die Methode _QXX aus. Der Inhalt der _QXX-Methode ist normalerweise ein Notify(0x80) auf dem Batteriegerät der Steuermethode im Namespace.

ACPI-Betrieb mit einem I²C-verbundenen Ladesystem

Plattformen können auch ihr Batterie- und Stromversorgungssubsystem, das über einen seriellen Bus mit geringem Stromverbrauch wie I²C mit dem Kernchipsatz verbunden ist, verbinden. In diesen Entwürfen wird der ACPI GenericSerialBus-Betriebsbereich verwendet, um zwischen den ACPI-Steuerungsmethoden und der Hardware des Batteriesubsystems zu kommunizieren. Das Verbinden der Batterie-Subsystem-Hardware mit einem GPIO-Interrupt ermöglicht die Ausführung der ACPI-Steuerungsmethoden, wenn sich der Batteriestatus ändert.

Wenn die Hardware des Batterie- und Stromversorgungssubsystems über I²C verbunden ist, muss die ACPI-Firmware Folgendes definieren:

• Ein Device()-Knoten für das GPIO-Controller-Gerät, mit dem der I²C-Interrupt verbunden ist, einschließlich:

  • _HID-Objekt, das die Hardware-ID des GPIO-Controllers beschreibt.
  • _CSR-Objekt, das die Interrupt- und Hardware-Ressourcen des GPIO-Controllers beschreibt.
  • _AEI-Objekt, das eine oder mehrere GPIO-Leitungen der Ausführung von ACPI-Ereignismethoden zuordnet. Dadurch können ACPI-Methoden als Reaktion auf GPIO-Leitungsunterbrechungen ausgeführt werden.

• Ein Device()-Knoten für den I²C-Controller, mit dem die Batteriestandsanzeige und die Ladehardware verbunden sind, einschließlich:

  • _HID- und _CSR-Objekte, die die Hardware-ID und Ressourcen des I²C-Controllers beschreiben.
  • Eine GenericSerialBus OperationRegion im Bereich des I²C-Geräts, die die virtuellen Befehlsregister für das I²C-Gerät beschreibt.
  • Felddefinitionen innerhalb der GenericSerialBus OperationRegion. Die Felddefinitionen ermöglichen ASL-Code außerhalb des I²C-Geräts, auf die virtuellen Befehlsregister für das I²C-Gerät zuzugreifen.

Durch die Beschreibung des GPIO-Controllers und die Zuordnung von GPIO-Leitungen zu ACPI-Ereignissen können die Steuerungsmethoden für den Batteriestatus und die Benachrichtigung ausgeführt werden, wenn ein GPIO-Interrupt von einem I²C-Gerät ausgelöst wird. Durch die Beschreibung des GenericSerialBus-Betriebsbereichs kann der ACPI-Code für den Batteriestatus über den I²C-Bus kommunizieren und Register und Informationen von der Batteriestandsanzeige und dem Ladesubsystem lesen.

Zugriff auf Batterieinformationen vom Ladesystem

Der Batteriestatus kann durch ACPI-Steuerungsmethoden ausgeführt werden, indem Befehle über den I²C-Bus gesendet und empfangen werden, mit dem die Hardware des Batteriesubsystems verbunden ist. Der Steuerungsmethodencode, der die statischen Status- und Batterieinformationsmethoden unterstützt, liest und schreibt Daten aus den GenericSerialBus-Operationsregionen, die im ACPI-Namespace beschrieben sind. Der Steuerverfahrenscode liest die Daten von der Kraftstoffanzeigevorrichtung oder statische Informationen über die Batteriekapazität und Zykluszahlen über den I²C-Bus durch den GenericSerialBus-Betriebsbereich.

Benachrichtigen von Windows, wenn sich der Batteriestatus ändert

Ein Interrupt kann von der Batterie-Subsystem-Hardware generiert werden, wenn sich der Zustand ändert und der Interrupt physisch mit einer GPIO-Leitung auf dem Core-Silizium verbunden ist. Die GPIO-Leitung kann mithilfe des _AEI-Objekts unter dem in ACPI beschriebenen GPIO-Controller einer bestimmten Steuerungsmethodenausführung zugeordnet werden. Wenn der GPIO-Interrupt auftritt, führt das Windows ACPI-Subsystem die Methode aus, die der spezifischen GPIO-Leitung zugeordnet ist, die wiederum ein Notify() auf dem Batteriegerät der Steuermethode ausführen kann, wodurch Windows den Status und die statischen Informationsmethoden neu auswertet, um die zu aktualisieren Batteriestatus.

ACPI-Implementierung des Stromversorgungsobjekts

Die ACPI-Firmware muss ein ACPI-Stromquellengerät implementieren. Dieses Objekt muss sich selbst mit einer Hardware-ID (_HID) von „ACPI0003“ melden. Dieses Objekt muss auch die ACPI-Methode _PSR (Power Source) implementieren. Diese Methode gibt den Status der Stromquelle zurück und übermittelt, ob die Stromquelle derzeit online (Netzstrom) oder offline (Akkustrom) ist. Alle Eingangsstromquellen für das System müssen durch eine einzige _PSR-Methode gemultiplext werden. Beispielsweise muss _PSR online übertragen werden, wenn das System über einen DC-Hohlstecker oder einen separaten Dock-Anschluss mit Strom versorgt wird. Verwenden Sie nicht mehrere ACPI-Stromquellengeräte.

Die _PSR-Methode muss sich nur online (Netzstrom) melden, wenn das System an das Stromnetz angeschlossen ist. Wenn sich der Zustand von _PSR ändert, muss die Plattform einen Interrupt und eine Notify(0x80) auf dem Gerät im ACPI-Namespace generieren. Dies muss sofort durchgeführt werden, nachdem die Änderung des physikalischen Zustands von der Plattform erkannt wurde.

ACPI-Implementierung von statischen Batterieinformationen

Die ACPI-Firmware muss die ACPI _BIX-Methode für jeden Akku implementieren, die statische Informationen über den Akku bereitstellt, einschließlich Entwurfskapazität, Zyklusanzahl und Seriennummer. Die folgende Tabelle erweitert die Definitionen der in der ACPI-Spezifikation beschriebenen Felder und listet Windows-spezifische Anforderungen für diese Informationen auf.

Feld	BESCHREIBUNG	Windows-spezifische Anforderungen
Revision	Gibt die _BIX-Revision an	Muss auf 0x0 gesetzt werden
Triebwerk	Bestimmt die von der Hardware gemeldeten Einheiten. Entweder: MA/MAh oder mW/mWh.	Muss auf 0x0 gesetzt werden, um anzugeben, dass die Einheit mW/mWh ist
Designkapazität	Zeigt die ursprüngliche Kapazität des Akkus in mWh an	Muss auf einen genauen Wert gesetzt werden und darf nicht 0x0 oder 0xFFFFFFFF sein
Letzte volle Ladekapazität	Zeigt die aktuelle Vollladekapazität des Akkus an	Muss auf einen genauen Wert gesetzt werden und darf nicht 0x0 oder 0xFFFFFFFF sein Dieser Wert muss jedes Mal aktualisiert werden, wenn sich die Zykluszahl erhöht.
Batterietechnologie	Zeigt an, ob der Akku wiederaufladbar oder einmalig ist.	Muss auf 0x1 gesetzt werden, um anzuzeigen, dass die Batterie wiederaufladbar ist
Bemessungsspannung	Zeigt die Nennspannung der Batterie an	Muss auf die Auslegungsspannung der Batterie im Neuzustand in mV eingestellt werden. Darf nicht auf 0x0 oder 0xFFFFFFFF gesetzt werden.
Designkapazität von Warning	Zeigt eine vom OEM bereitgestellte Warnstufe für niedrigen Batteriestand an.	Dieser Wert wird von Windows ignoriert.
Auslegungskapazität von Niedrig	Zeigt den kritischen Akkustand an, bei dem Windows sofort heruntergefahren oder in den Ruhezustand versetzt werden muss, bevor das System ausgeschaltet wird.	Muss auf einen Wert zwischen 0x0 und 5% der Akku-Designkapazität eingestellt werden.
Granularität der Batteriekapazität 1	Zeigt die minimale verbleibende Ladungsänderung an, die von der Hardware zwischen der Design Capacity of Warning und Design Capacity of Low erkannt werden kann.	Muss auf einen Wert eingestellt werden, der nicht größer als 1% der Batterieauslegungskapazität ist.
Granularität der Batteriekapazität 2	Gibt die minimale verbleibende Ladungsänderung an, die von der Hardware zwischen der Kapazität der letzten vollen Ladung und der Auslegungskapazität der Warnung erkannt werden kann.	Muss auf einen Wert von nicht mehr als 75 mW (ca. 0,25% einer 25-Wh-Batterie) eingestellt werden, was (1/400) der Batterie-Designkapazität entspricht.
Anzahl der Durchgänge	Zeigt die Anzahl der Batteriezyklen an.	Muss auf einen Wert größer als 0x0 gesetzt werden. Darf nicht auf 0xFFFFFFFF gesetzt werden.
Meßgenauigkeit	Zeigt die Genauigkeit der Batteriekapazitätsmessung an.	Muss auf 95.000 oder besser eingestellt werden, was eine Genauigkeit von 95% oder besser anzeigt.
Max. Abtastzeit	Die maximal unterstützte Abtastzeit zwischen zwei aufeinanderfolgenden _BST-Auswertungen, die einen Unterschied in der verbleibenden Kapazität zeigen.	Keine besondere Anforderung.
Min. Abtastzeit	Die minimale unterstützte Abtastzeit zwischen zwei aufeinanderfolgenden _BST-Auswertungen, die einen Unterschied in der verbleibenden Kapazität zeigen	Keine besondere Anforderung.
Max. Mittelungsintervall	Das maximale Mittelungsintervall in Millisekunden, das von der Batteriestandsanzeige unterstützt wird.	Keine besondere Anforderung.
Min. Mittelungsintervall	Das minimale Mittelungsintervall in Millisekunden, das von der Batteriestandsanzeige unterstützt wird.	Keine besondere Anforderung.
Modellnummer	Modellnummer des vom OEM bereitgestellten Akkus	Darf nicht NULL sein.
Seriennummer	Seriennummer des vom OEM bereitgestellten Akkus	Darf nicht NULL sein.
Batterietyp	Vom OEM bereitgestellte Informationen zum Batterietyp	Keine besondere Anforderung.
Informationen zum Gerätehersteller	Vom OEM bereitgestellte Informationen	Keine besondere Anforderung.

ACPI-Implementierung von Batteriestatusinformationen in Echtzeit

Die ACPI-Firmware muss die ACPI _BST-Methode für jeden Akku implementieren, die Echtzeit-Statusinformationen über den Akku bereitstellt, einschließlich der verbleibenden Kapazität und der aktuellen Entladerate. Die folgende Tabelle erweitert die Definitionen der in der ACPI-Spezifikation beschriebenen Felder und listet die Windows-spezifischen Anforderungen für diese Informationen auf.

Feld	BESCHREIBUNG	Windows-spezifische Anforderungen
Batteriezustand	Zeigt an, ob der Akku gerade geladen wird, entladen wird oder sich in einem kritischen Zustand befindet.	Der Batteriestatus muss das Laden nur melden, wenn die Batterie geladen wird. Ebenso MUSS der Batteriestatus nur dann eine Entladung melden, wenn die Batterie entladen wird. Eine Batterie, die weder lädt noch entlädt, darf kein Bit melden.
Akku-Präsenzrate	Liefert die aktuelle Entladerate in mW von der Batterie.	Muss größer als 0x0 und kleiner als 0xFFFFFFFF sein. Muss innerhalb des Wertes der Messgenauigkeit in _BIX genau sein.
Verbleibende Batteriekapazität	Liefert die verbleibende Batteriekapazität in mWh.	Muss größer als 0x0 und kleiner als 0xFFFFFFFF sein. Muss innerhalb des Wertes der Messgenauigkeit in _BIX genau sein
Batterie Spannung vorhanden	Zeigt die aktuelle Spannung an den Klemmen der Batterie an.	Muss zwischen einem Wert von 0x0 und 0xFFFFFFFF in mV liegen.

Wenn sich Daten in _BST ändern, muss die Plattform einen Interrupt und eine Notify(0x80) auf dem Batteriegerät im ACPI-Namespace generieren. Dies muss sofort durchgeführt werden, nachdem die Änderung des physikalischen Zustands von der Plattform erkannt wurde. Dies schließt jede Änderung im Batteriezustandsfeld für die Lade- (d. h. Bit0) oder Entlade- (d. h. Bit1) Bits ein.

Zusätzlich muss die Plattform die _BTP-Battery Trip Point-Methode implementieren. _BTP ermöglicht es Windows, einen Schwellenwert für die verbleibende Kapazität anzugeben, bei dessen Überschreitung die Plattform einen Interrupt und eine Notify (0x80) auf dem Akkugerät im ACPI-Namespace generieren muss. Die _BTP-Methode verhindert, dass Windows den Akku regelmäßig abfragen muss.

Batteriekontrollmethoden

Die ACPI-Spezifikation ermöglicht geräte- und betriebssystemspezifische Steuerungsmethoden durch die gerätespezifische Methode oder die _DSM-Steuerungsmethode. _DSM wird in Abschnitt 9.14.1 der ACPI-Spezifikation beschrieben.

Windows unterstützt die folgenden _DSM-Methoden für Batteriegeräte mit Steuermethode.

Richtung der thermischen Ladungsrate

Feld	Wert	Beschreibung
UUID	4c2067e3-887d-475c-9720-4af1d3ed602e	GUID, die Erweiterungen zur Unterstützung des Batterietreibers für die Windows-Steuerungsmethode angibt
Revisions-ID	0x0	Erste Überarbeitung dieser Funktion
Funktionsindex	0x1	Batterieladedrossel einstellen
Argumente	Thermische Grenze	Ganzzahliger Wert von 0 bis 100, der die thermische Belastungsgrenze angibt. Ein Wert von 40% gibt an, dass der Akku zu 40% der maximalen Rate geladen werden sollte. Ein Wert von 0% gibt an, dass das Laden des Akkus angehalten werden sollte, bis diese Methode erneut aufgerufen wird.
Rückgabewert(e)	Keine	–

Vom Benutzer wartbarer Akku

Feld	Wert	Beschreibung
UUID	4c2067e3-887d-475c-9720-4af1d3ed602e	GUID, die Erweiterungen zur Unterstützung des Batterietreibers für die Windows-Steuerungsmethode angibt
Revisions-ID	0x0	Erste Überarbeitung dieser Funktion
Funktionsindex	0x2	Gibt an, dass dieses _DSM für OSPM bestimmt ist, ob das Batteriegerät vom Benutzer gewartet werden kann oder nicht.
Argumente	Keine	Keine Argumente erforderlich.
Rückgabewert(e)	Paket, das eine einzelne Ganzzahl enthält.	0x0, wenn die Batterie nicht vom Benutzer gewartet werden kann und nicht vom Endbenutzer ersetzt werden kann oder vom Endbenutzer mit zusätzlichen Tools ersetzt werden kann. 0x1, wenn die Batterie vom Endbenutzer ohne zusätzliches Werkzeug ausgetauscht werden kann.

Ladeüberwachung erforderlich

Feld	Wert	Beschreibung
UUID	4c2067e3-887d-475c-9720-4af1d3ed602e	GUID, die Erweiterungen zur Unterstützung des Batterietreibers für die Windows-Steuerungsmethode angibt
Revisions-ID	0x0	Erste Überarbeitung dieser Funktion
Funktionsindex	0x3	Gibt an, dass dieses _DSM für das OSPM bestimmt ist, ob die Batterie des Steuerverfahrens ein regelmäßiges Zurücksetzen des Watchdogs erfordert, um die Hochstromladung aufrechtzuerhalten, und den Zeitraum, in dem der Watchdog zurückgesetzt werden muss
Argumente	Keine	Keine Argumente erforderlich.
Rückgabewert(e)	Paket, das eine einzelne Ganzzahl enthält.	0x0, wenn die Batterie keine Watchdog-Wartung erfordert. Werte einschließlich 0x0000001e und 0x12C geben das maximale Polungsintervall in Sekunden an. Alle anderen Werte werden ignoriert und als 0x0 behandelt und ein Watchdog-Reset ist nicht erforderlich. Wenn ein gültiges Watchdog-Intervall angegeben ist, führt Windows die _BST-Methode in einem Intervall aus, das nicht länger als der angegebene Watchdog-Wert ist, wenn der Wert von BatteryState in der _BST-Methode auf Laden festgelegt ist. Die dynamische Aktualisierung dieses Werts wird nicht unterstützt.

Akku-Miniport-Treiber von 3 Anbietern

In Windows 10 können OEMs und IHVs ihre eigenen Batterie-Miniport-Treiber von 3 Anbietern entwickeln, um den Microsoft cmbatt.sys-Treiber zu ersetzen und direkt mit der Batteriehardware zu kommunizieren. Ein Beispielbatterietreiber wird von Microsoft auf GitHub und als Teil des WDK-Beispielkits bereitgestellt.

Aufladen über USB (Windows 10 für Desktop-Editionen)

Microsoft erkennt den Wert darin, die Option zur Unterstützung des Aufladens eines Mobilgeräts über USB bereitzustellen. Mit Standardisierungsbemühungen wie dem Schritt der EU, Ladegeräte für Mobiltelefone zu standardisieren, sind USB-Ladegeräte weit verbreitet und funktionieren auf einer Vielzahl von Geräten, einschließlich Windows Phones, MP3-Playern, GNSS-Geräten usw. Microsoft weiß, wie wertvoll es ist, ein einziges Ladegerät anzubieten, das dies kann verwendet werden, um mehrere Geräte aufzuladen, einschließlich eines Geräts, auf dem Windows ausgeführt wird. Darüber hinaus gibt es angesichts der breiten Industrieunterstützung für USB-Aufladung zusätzliche Vorteile, die Kosten und Umweltbelastung reduzieren.

Ab Windows 8 kann ein mobiles Gerät über USB mit Strom versorgt und/oder aufgeladen werden, vorausgesetzt, dass die unten aufgeführten Anforderungen zum Laden des Akkus erfüllt sind. Darüber hinaus gibt es eine Reihe von USB-spezifischen Anforderungen, die erfüllt werden müssen, um ein qualitativ hochwertiges Benutzererlebnis zu gewährleisten.

1. USB-Stromversorgung/Laden muss vollständig in der Plattform-Firmware implementiert werden. Der Support darf kein Betriebssystem, keinen Treiber oder keine Anwendung erfordern.

2. Das Gerät DARF NICHT aufzählen, wenn es mit einem anderen Gerät verbunden ist. Infolgedessen wird das Gerät nicht aufgeladen, wenn es an einen Standard-USB-Port eines PCs angeschlossen ist, da diese Ports standardmäßig auf 500 mA begrenzt sind. Die einzigen Ausnahmen sind, wenn dieser Port zum Debuggen und für die Erstprogrammierung der Werksfirmware verwendet wird.

3. Das Gerät unterstützt das Laden über einen dedizierten USB-Ladeanschluss. Das Gerät muss aufgeladen werden, wenn es an ein Ladegerät angeschlossen ist, das mit der USB Battery Charging Specification Version 1.2 kompatibel ist. Das Gerät sollte nicht mehr als 1,5 A pro Ladestandard ziehen, wenn es an ein Standard-USB-Ladegerät angeschlossen ist. Der OEM kann sich dafür entscheiden, höhere Stromstärken zu unterstützen, sofern die folgenden Bedingungen erfüllt sind:

   • Das Gerät erkennt automatisch den Ladegerättyp und lädt mit der entsprechenden Rate für den jeweiligen Ladegerättyp.
   • Das Gerät und das Ladegerät erfüllen alle relevanten Elektro- und Sicherheitsnormen.
   • Der OEM versendet das Ladegerät und das zugehörige Kabel mit dem Gerät.

4. Das Aufladen über USB wird entweder über eine standardmäßige Micro-AB-Buchse, USB-C (empfohlen) oder einen proprietären Dock-Anschluss unterstützt. Eine Mikro-B-Buchse ist am Gerät NICHT erlaubt. Bei Verwendung eines proprietären Dock-Anschlusses muss der OEM ein geeignetes Kabel mit dem Gerät liefern, um das Aufladen über ein Standard-USB-Ladegerät zu ermöglichen.

5. Wenn der Micro-AB-Port implementiert ist, muss das Gerät den Kabeltyp und die Konfiguration automatisch erkennen und die entsprechende Rolle übernehmen. Wenn ein Micro-B-Stecker eingesteckt ist und das Debugging am Port nicht aktiviert ist, sollte die Rolle des Ladegeräts übernommen werden. Wenn ein Mikro-B-Stecker eingesteckt und das Debuggen am Port aktiviert ist, sollte die Debug-Rolle übernommen werden (d. h. Laden wird nicht unterstützt). Wird ein Micro-A-Stecker eingesteckt, wird die USB-Host-Rolle übernommen, bei der angeschlossene USB-Geräte von Windows erkannt werden.

6. Wenn der Micro-AB-Port auch als Debug-Port fungiert, muss das Gerät über die Firmware eine Möglichkeit bieten, zwischen der Lade- und der Debug-Rolle umzuschalten. Die an den Endbenutzer gelieferte Standardeinstellung muss Debug DEAKTIVIERT haben.

7. Wenn der Micro-AB-Port auch als Debug-Port fungiert, sollte das Gerät einen alternativen Eingangsstrompfad entweder über einen dedizierten Barrel-Anschluss oder einen proprietären Dock-Anschluss bereitstellen.

Checklisten für Plattformdesigner und -implementierer

Sie können die folgenden Checklisten verwenden, um zu validieren, dass das Plattformdesign und die Systemfirmware den Leitlinien für Akku und Ladesubsystem entsprechen.

Checkliste für die Implementierung von Akku-Subsystem und ACPI-Firmware

Systemdesigner sollten sicherstellen, dass sie die folgenden Aufgaben in ihrer ACPI-Firmware abgeschlossen haben, um sicherzustellen, dass Informationen zu Akku und Stromversorgungssubsystem korrekt an Windows übermittelt werden:

• Fügen Sie ein Device()-Objekt für jedes Batteriegerät im ACPI-Namespace hinzu.

• Jedes Batteriegerät muss die folgenden Steuermethoden und -objekte bereitstellen:

  • _HID mit einem Wert von PNP0C0A.
  • _BIX-Batterieinformationen erweitert:

  Übermittelt die statischen Informationen der Batterie, einschließlich der letzten vollen Ladekapazität, der Auslegungskapazität und der Zyklenzahl.

  • _BST-Batteriestatus:

    Übermittelt den aktuellen Batteriestatus, einschließlich der verbleibenden Kapazität, der Entladerate und des Ladezustands.

  • _BTP-Batterieauslösepunkt:

    Aktiviert ein ereignisgesteuertes Batteriestatusmodell, um die regelmäßige Arbeit für das Abrufen zu reduzieren. _BTP ermöglicht es Windows, einen Schwellenwert für die verbleibende Ladekapazität anzugeben, bei dem die Plattform Notify(0x80) auf dem Akkugerät ausgeben sollte, um Windows aufzufordern, die Akkustatusinformationen zu aktualisieren.

  • _STA-Allgemeiner Status:

    Ermöglicht Windows zu wissen, ob der Akku im Gerät vorhanden ist, wo ein Akku entfernbar ist, oder wo sich ein Akku in einem tragbaren Dock befindet.

• Fügen Sie ein einzelnes Device()-Objekt für einen AC-Adapter/eine Stromquelle im ACPI-Namespace hinzu.

• Das Stromquellengerät muss die folgenden Steuermethoden und -objekte bereitstellen:

  • _HID mit dem Wert ACPI0003

  • _PSR-Stromquelle:

    Gibt an, ob die Stromquelle derzeit online (Netzstrom) oder offline (Akkustrom) ist. Alle Eingangsstromquellen für das Gerät müssen durch die _PSR-Methode gemultiplext werden. Beispielsweise muss das _PSR online übermitteln, wenn das Gerät über einen DC-Hohlstecker oder einen separaten Dock-Anschluss mit Strom versorgt wird. Verwenden Sie nicht mehrere ACPI-Stromquellengeräte.

• Die _BIX-Methode muss die Felder und Einschränkungen unterstützen, die oben in den statischen Informationen zur Batterie beschrieben sind:

  • Das Revisionsfeld muss auf 0x0 gesetzt werden.
  • Das Feld Power Unit muss auf 0x0 gesetzt sein.
  • Die Werte für Design Capacity und Last Full Charge Capacity müssen auf genaue Werte des Akkus und des Ladesubsystems gesetzt werden und dürfen nicht gleich 0xFFFFFFFF oder 0x00000000 gesetzt werden.
  • Das Feld Battery Technology muss auf 0x1 gesetzt werden.
  • Das Feld Design Voltage muss genau eingestellt werden und darf nicht gleich 0x00000000 oder 0xFFFFFFFF sein.
  • Die Entwurfskapazität von Niedrig muss auf den Mindestwert eingestellt werden, der erforderlich ist, um das System aus einem vollständig eingeschalteten Zustand in den Ruhezustand zu versetzen oder herunterzufahren.
  • Die Felder Akkukapazität Granularität 1 und Akkukapazität Granularität 2 müssen auf einen Wert eingestellt werden, der nicht größer als 1% der Batterieentwurfskapazität ist.
  • Das Feld Cycle Count muss vom Batteriesubsystem genau ausgefüllt werden.
  • Das Feld Messgenauigkeit muss auf 80.000 d oder besser eingestellt sein.
  • Die Felder Modellnummer und Seriennummer dürfen nicht auf NULL gesetzt werden.

• Stellen Sie eine _BST-Methode bereit, die es Windows ermöglicht, den Batteriestatus in Echtzeit abzufragen. Die Felder in der _BST-Methode müssen alle dynamisch vom zugrunde liegenden Stromversorgungs- und Batterieladesubsystem zurückgegeben werden. Ihre Genauigkeit muss innerhalb des Wertes der Messgenauigkeit in der _BIX-Methode liegen.

• Stellen Sie eine _BTP-Methode bereit, mit der Windows einen Schwellenwert für die verbleibende Ladekapazität angeben kann, bei dem die Plattform Windows mit einem Notify(0x80) auf dem Akkugerät unterbricht.

• Stellen Sie sicher, dass eine Benachrichtigung (0x80) nur als Reaktion auf eine Änderung des Batteriestatus oder eine Auslösung der _BTP-Ladekapazitätsgrenze ausgegeben wird. Führen Sie ein Notify(0x80) nicht regelmäßig aus.

• Wenn der Batteriestand den in _BIX.DesignCapacityofLow angegebenen Wert erreicht, muss die Plattform eine Notify(0x80) auf dem Batteriegerät der Steuermethode generieren.

• Implementieren Sie für Systeme mit mehreren Batterien vollständig ein Batteriegerät für die Steuermethode für jede Batterie.

  • Die erste Batterie im Namespace sollte die primäre Batterie für das System sein, um Debugging-Zwecke zu unterstützen.

• Implementieren Sie die _DSM-Methode unter jedem Akkugerät, um anzugeben, ob der Akku vom Benutzer gewartet werden kann.

• Implementieren Sie die _DSM-Methode, wenn während des Ladevorgangs ein periodisches Watchdog-Reset erforderlich ist und Windows die regelmäßige Ausführung der _BST-Methode innerhalb dieses Abfragefensters garantiert.

• Implementieren Sie die _DSM-Methode, wenn die Batterieladeratensteuerung für das thermische Modell auf der Plattform erforderlich ist.