Freigeben über


Hardwaredesign für Akku- und Energiesubsystem

Ab Windows 8 können Systemhardwaredesigner zwischen zwei verschiedenen Hardwaretopologien für Akku- und Energiesubsystem auf ihren Windows-Plattformen wählen.

Hardwaretopologien

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

Die erste Topologie wird im folgenden Blockdiagramm veranschaulicht. Diese Topologie, die häufig in PCs verwendet wird, die Windows 7 ausführen, verwendet einen eingebetteten Controller auf der Plattform. Der eingebettete Controller führt in der Regel mehrere Funktionen in einem mobilen Windows-PC aus, einschließlich Stromquellensteuerung, Akkuladeverwaltung, Netzschaltererkennung und PS/2-kompatibler Tastatur und Mauseingabe. Der eingebettete Controller ist in der Regel über den LPC-Bus (Low Pin Count) mit dem Kernprozessor verbunden. Über die eingebettete ACPI-Controllerschnittstelle führt Windows Abfragen durch und wird darüber über das Energiesubsystem informiert.

Allgemeine Topologie in Windows 7

Die zweite Topologie wird im folgenden Blockdiagramm veranschaulicht. Diese Topologie verwendet einen Akkuladecontroller und eine Ladestandkomponente, die über einen einfachen Peripheriebus wie I²C direkt mit dem Kernprozessor der Plattform verbunden sind. In dieser Konfiguration führt Windows über den I²C-Bus Abfragen durch und wird darüber über Änderungen des Energiesubsystems informiert. Ein SPB-Betriebsbereich (Simple Peripheral Bus) ermöglicht dem ACPI-Steuerungsmethodencode in der Firmware, mit dem Akkuladecontroller und den Ladestandkomponenten zu kommunizieren, die über einen I²C-Bus mit dem Kernprozessor verbunden sind.

Akkuladecontroller und Ladestand

ACPI-Vorgang mit einem eingebetteten Controller

Plattformen, deren Akku- und Energiesubsystem mit dem typischen in die Plattform eingebetteten Controller verbunden ist, verwenden den Betriebsbereich des eingebetteten ACPI-Controllers zur einfacheren Kommunikation zwischen der ACPI-Steuermethodenumgebung und der Plattformhardware.

Die ACPI-Firmware muss den eingebetteten Controller im ACPI-Namespace definieren. Eine Typdefinition enthält Folgendes:

  • Einen Device()-Knoten für den eingebetteten Controller.
  • Ein _HID-Objekt, das angibt, dass das Gerät ein eingebetteter Controller ist.
  • Ein _CRS-Objekt, das die E/A-Ressourcen für den eingebetteten Controller angibt.
  • Ein _GPE-Objekt, das die SCI für den eingebetteten Controller definiert.
  • Ein Betriebsbereich, der die im eingebetteten Controller enthaltenen Informationen beschreibt, auf die andere ACPI-Steuermethodencodes im Namespace einschließlich Akkustatus- und Informationsmethoden zugreifen können.

Weitere Informationen finden Sie in der ACPI 5.0-Spezifikation unter Abschnitt 12.11, „Defining an Embedded Controller Device in ACPI Namespace“ (Definieren eines eingebetteten Controllergeräts im ACPI-Namespace).

Zugreifen auf Akkuinformationen vom eingebetteten Controller

ACPI-Steuermethoden greifen auf Informationen vom eingebetteten Controller zu, indem sie die Werte lesen, die im Betriebsbereich des eingebetteten Controllers beschrieben werden.

Benachrichtigen von Windows beim Ändern des Akkuzustands (eingebetteter Controller)

Wenn der eingebettete Controller eine Änderung des Akkuzustands einschließlich einer Änderung des Ladezustands oder der verbleibenden Kapazität gemäß _BTP erkennt, generiert der eingebettete Controller eine SCI und legt das SCI_EVT-Bit im Statusbefehl des eingebetteten Controllers (EC_SC) fest. Der Windows ACPI-Treiber „Acpi.sys“ kommuniziert mit dem eingebetteten Controller und gibt einen Abfragebefehl (QR_EC) aus, um bestimmte Informationen zur auszugebenden Benachrichtigung anzufordern. Der eingebettete Controller legt einen Bytewert fest, der der auszuführenden _QXX-Methode entspricht. Der eingebettete Controller und die ACPI-Firmware können beispielsweise Wert 0x33 als Aktualisierung der Akkustatusinformationen definieren. Wenn der eingebettete Controller den Wert 0x33 als Benachrichtigung festlegt, führt „Acpi.sys“ die _QXX-Methode aus. Die _QXX-Methode gibt in der Regel einen Notify(0x80)-Befehl auf dem Akkusteuermethodengerät im Namespace aus.

Stromverbrauch

Bei modernen Standbysystemen muss besonders darauf geachtet werden, dass die angestrebte Akkumindestlebensdauer für den modernen Standbybetrieb erreicht wird. Bei modernen Standbysystemen muss die vom eingebetteten Controller für Energie- und Akkusubsystem verbrauchte Nennleistung unter 5 Milliwatt liegen. Stellen Sie auf PCs mit den herkömmlichen S3/S4-Leistungsstatus sicher, dass der eingebettete Controller keine Auswirkungen auf die angestrebte Akkulebensdauer hat. Es gibt keine spezifischen Nennleistungsanforderungen für Systeme mit S3/S4.

ACPI-Betrieb mit einem über SPB angeschlossenen Ladesystem

Plattformen können auch das mit dem Kernchipsatz verbundene Akku- und Energiesubsystem mit einem einfachen Peripheriebus (SPB) mit niedriger Leistung wie I²C verbinden. In diesen Designs wird der ACPI-GenericSerialBus-Betriebsbereich zur Kommunikation zwischen ACPI-Steuermethoden und Akkusubsystemhardware verwendet. Durch das Verbinden der Akkusubsystemhardware mit einem GPIO-Interrupt können ACPI-Steuermethoden ausgeführt werden, wenn sich der Akkustatus ändert.

Wenn die Akku- und Energiesubsystemhardware mit I²C verbunden ist, muss die ACPI-Firmware Folgendes definieren:

  • Einen Device()-Knoten für das GPIO-Controllergerä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 Hardwareressourcen des GPIO-Controllers beschreibt.
    • _AEI-Objekt, das eine oder mehrere GPIO-Leitungen der Ausführung der ACPI-Ereignismethode zuordnet. Dadurch können ACPI-Methoden als Reaktion auf GPIO-Leitungsinterrupts ausgeführt werden.
  • Ein Device()-Knoten für den I²C-Controller, mit dem die Akkuladestand- und Ladehardware verbunden sind, einschließlich:
    • _HID- und _CSR-Objekten, die die Hardware-ID und Ressourcen des I²C-Controllers beschreiben.
    • Ein GenericSerialBus-Betriebsbereich im Bereich des I²C-Geräts, der die virtuellen Befehlsregister für das I²C-Gerät beschreibt.
    • Felddefinitionen im GenericSerialBus-Betriebsbereich. Die Felddefinitionen ermöglichen ASL-Code außerhalb des I²C-Geräts den Zugriff auf die virtuellen Befehlsregister für das I²C-Gerät.

Das Beschreiben des GPIO-Controllers und die Zuordnung von GPIO-Leitungen zu ACPI-Ereignissen ermöglicht die Ausführung von Steuermethoden für Akkustatus und Benachrichtigung, wenn ein GPIO-Interrupt von einem I²C-Gerät ausgelöst wird. Die Beschreibung des GenericSerialBus-Betriebsbereichs ermöglicht ACPI-Code für den Akkustatus, über den I²C-Bus kommunizieren und Register und Informationen aus dem Akkuladestand und Ladesubsystem zu lesen.

Zugreifen auf Akkuinformationen vom Ladesystem aus

Der Akkustatus kann von ACPI-Steuermethoden ausgeführt werden, indem Befehle über den I²C-Bus gesendet und empfangen werden, mit dem die Akkusubsystemhardware verbunden ist. Der Steuermethodencode, der den Status und die statischen Akkuinformationsmethoden sichert, liest und schreibt Daten aus den im ACPI-Namespace beschriebenen GenericSerialBus-Betriebsbereichen. Der Steuermethodencode kann Daten aus dem Ladestandgerät oder statische Informationen über die Akkukapazität und die Zyklusanzahl über den I²C-Bus über den GenericSerialBus-Betriebsbereich lesen.

Benachrichtigen von Windows beim Ändern des Akkuzustands (Subsystemhardware)

Die Akkusubsystemhardware kann beim Ändern des Zustands oder von einer GPIO-Leitung am Kernprozessor aus einen Interrupt generieren. Die GPIO-Leitung kann einer bestimmten Steuermethodenausführung zugeordnet werden, indem das _AEI-Objekt unter dem in ACPI beschriebenen GPIO-Controller verwendet wird. Wenn der GPIO-Interrupt auftritt, führt das Windows ACPI-Subsystem die Methode aus, die der spezifischen GPIO-Leitung zugeordnet ist, wodurch wiederum ein Notify()-Befehl auf dem Akkusteuermethodengerät ausgegeben werden kann. Dies führt dazu, dass Windows den Status und statische Informationsmethoden erneut auswertet, um den Akkustatus zu aktualisieren.

Stromversorgungs- und Ladeanzeigen

Windows ermöglicht die Anzeige von Stromquellen- und Akkustatus im Betriebssystem. Die Anzeige erfolgt an mehreren Stellen, einschließlich des Akkusymbols auf dem Desktop, im Startmenü und direkt auf dem Sperrbildschirm.

Windows 8-Plattformen können auch eine Anzeige des Ladestatus bieten. Die folgenden Abbildungen zeigen zwei Benutzeroberflächenbeispiele. Die verwendete Anzeige darf nur geringe Auswirkungen auf den Stromverbrauch und die Benutzererfahrung haben.

Stromversorgungs- und Ladebenutzeroberflächen-Elemente in Windows

Windows bietet an drei zentralen Positionen eine Anzeige des Stromquellen- und Ladestatus:

  • Auf dem Sperrbildschirm. Ein Akkusymbol mit Stromquelle und Ladestatus wird angezeigt.
  • In der Zeit- und Datumsanzeige beim Zeigen auf die Startschaltfläche. Ein Akkusymbol mit Stromquelle und Ladestatus wird angezeigt.
  • Akkusymbol auf dem Desktop. Ein Akkusymbol mit Stromquelle und Ladestatus wird angezeigt. Weitere Informationen sind verfügbar, wenn Sie auf das Akkusymbol klicken; dies umfasst verbleibende Kapazität, geschätzte verbleibende Zeit und Details pro Akku, wenn das System mehrere Akkus hat.

. Bei modernen Plattformen mit Standbyfunktion leuchtet die Windows-Anzeige kurz auf, wenn sich das System in S0 befindet und der Deckel (sofern vorhanden) nicht geschlossen ist, sofern das System mit dem Ladegerät verbunden ist und mit Strom versorgt wird. So sehen die Benutzer, wie die Plattform auf den Anschluss des Ladegeräts reagiert.

Hardwareladeanzeigen der Plattform

Die in Windows integrierten Benutzeroberflächenelemente sind für die Szenarien bestimmt, in denen Windows ausgeführt wird und die Anzeige für den Benutzer sichtbar ist. Diese Bildschirmanzeigen sind jedoch nicht sichtbar, wenn das System heruntergefahren ist, sich im Ruhezustand befindet oder anderweitig nicht ausgeführt wird.

Eine Plattform kann mittels einer LED anzeigen, dass die Stromversorgung aktiv ist. Eine solche LED sollte sich nicht auf dem Systemchassis befinden. Stattdessen sollte sich die LED entweder auf dem Stromversorgungsmodul, dem Netzkabel oder dem Netzstecker befinden. Optional kann diese LED dem Benutzer auch den Ladestatus anzeigen.

Die Helligkeit oder Farbe der LED sollte nicht variieren, und sie sollte auch nicht blitzen oder blinken, da dies den Benutzer ablenkt. Sie kann jedoch die Farbe wechseln, um den Ladestatus anzugeben, z. B. Gelb beim Laden, Grün bei vollständiger Ladung oder Rot, wenn ein Fehler auftritt.

Kapazität des Echtzeituhr-Reserveakkus

Die genaue Zeit ist entscheidend für eine hervorragende Benutzererfahrung. Darüber hinaus ist die genaue Zeit erforderlich, um eine Verbindung mit Diensten wie dem Microsoft Store herzustellen. Alle Windows-Systeme sollten auch dann, wenn sie ausgeschaltet sind, für einen Zeitraum von mindestens vier Wochen die genaue Zeit beibehalten. Hierzu dient in der Regel ein separater Sicherungsakku für die Echtzeituhr (Real-Time Clock, RTC). Dies ist bei ausgesprochenen Mobilgerät-Formfaktoren nicht immer möglich oder praktisch.

Systemdesigner können einen dedizierten Akku verwenden oder einen Teil des Hauptakkus des Systems reservieren. Angesichts der bescheidenen Stromanforderungen der RTC wird ein relativ niedriger Reserveschwellenwert Sicherungsakkus in heutigen PCs gerecht.

Entwurfsrichtlinien

OSPM bietet eine Methode, mit der Systemdesigner das kritische Akkuereignis des Windows-Betriebssystems außer Kraft setzen können. Wenn der Akku ein kritisches Niveau (in Milliwattstunden) erreicht, wie durch die _BIX-Methode (Erweiterte Akkuinformationen – Entwurfskapazität für Niedrigstand) in der Akkusteuermethoden-Implementierung definiert, gibt die Firmware einen an das Betriebssystem adressierten Benachrichtigungsbefehl aus. An diesem Punkt führt Windows ein Notfall-Herunterfahren oder den Wechsel in den Ruhezustand aus, um den Systemstatus zu erhalten.

Alle Designs müssen folgende Anforderungen erfüllen:

  • Die Entwurfskapazität für Niedrigstand in der _BIX-Methode muss auf mindestens 675 Milliwattstunden der vollständigen Entwurfskapazität festgelegt werden (zusätzlich zur erforderlichen Kapazität, um die kritische Aktion zuverlässig auszuführen).
  • Die oben genannte Reservekapazität muss weniger als vier Prozent der vollständigen Entwurfskapazität sein.

Ladeleistung

Wie lange es dauert, bis der Systemakku vollständigen geladen ist, spielt für den Benutzer eine wichtige Rolle. Viele Systeme werden über Nacht oder während anderer Zeiträume geladen, in denen der Benutzer nicht mit dem System interagiert. Wenn der Akku jedoch vollständig geleert ist und der Benutzer das System unterwegs verwenden möchte, ist die Ladeleistung von primärer Bedeutung.

Windows empfiehlt, dass alle Plattformen den Systemakku innerhalb von höchstens vier Stunden von 5 Prozent auf 90 Prozent laden können, wenn das System gestartet ist und sich in moderner Standbybereitschaft mit deaktiviertem Bildschirm befindet.

Systemdesigner sollten besonders bei Systemen, die nur die USB-Ladefunktion unterstützen, auf die Laderate achten. Systeme, die nur die USB-Ladefunktion bieten und große Akkukapazität haben, erfüllen möglicherweise nicht die Ladeleistungserwartungen des Kunden.

Wenn USB-Ladung auf Plattformen mit großer Akkukapazität (über 30 Wattstunden) erforderlich ist, sollte der Systemdesigner auch einen hochleistungsfähigen DC-Eingang bereitstellen und ein Hochleistungs-DC-Ladegerät mit dem System bündeln. So kann der Plattformakku auch während interaktiver Nutzung geladen werden, was sonst in Anbetracht der niedrigen Eingangsleistung und des hohen Stromverbrauchs einer Plattform mit großer Akkukapazität, die nur die USB-Ladefunktion bietet, unmöglich sein kann.