Andere ACPI-Namespaceobjekte

Für einige bestimmte Geräteklassen müssen zusätzliche ACPI-Namespaceobjekte (Advanced Configuration und Power Interface) unter diesen Geräten im Namespace angezeigt werden. In diesem Abschnitt werden die zusätzlichen Objekte aufgeführt, die für SoC-basierte Plattformen erforderlich sind.

Prozessoridentifikationsobjekte

Prozessoren müssen im ACPI-Namespace aufgezählt werden. Prozessoren werden unter \_SB mithilfe der "Device"-Anweisung deklariert, wie bei anderen Geräten auf der Plattform. Prozessorgeräte müssen die folgenden Objekte enthalten:

• _HID: ACPI0007
• _UID: Eine eindeutige Zahl, die dem Eintrag des Prozessors im MADT entspricht.

Anzeigespezifische Objekte

Weitere Informationen zu anzeigespezifischen Objekten finden Sie in Anhang B, "Videoerweiterungen" der ACPI 5.0-Spezifikation.

Anforderungen an Display-Specific-Objekte

USB-Hostcontroller und -Geräte

USB-Hostcontroller werden auf SoC-Plattformen zum Verbinden interner und externer Geräte verwendet. Windows enthält Posteingangstreiber für STANDARD-USB-Hostcontroller, die mit den EHCI- oder XHCI-Spezifikationen kompatibel sind.

Auf SoC-basierten Plattformen kann der USB-Hostcontroller von ACPI aufgezählt werden. Windows verwendet die folgenden ACPI-Namespaceobjekte beim Aufzählen und Konfigurieren kompatibler USB-Hardware:

• Eine vom Anbieter zugewiesene ACPI-kompatible Hardware-ID (_HID).

• Ein eindeutiges ID-Objekt (_UID), wenn mehr als eine instance des USB-Controllers im Namespace vorhanden ist (d. a. zwei oder mehr Knoten mit identischen Geräteidentifikationsobjekten).

• Eine kompatible ID (_CID) für den EHCI- oder XHCI Standard-kompatiblen USB-Hostcontroller (EHCI: PNP0D20), (XHCI: PNP0D10).

• Die aktuellen Ressourceneinstellungen (_CRS), die dem USB-Controller zugewiesen sind. Die Ressourcen des Controllers werden in der entsprechenden Hardwareschnittstellenspezifikation (EHCI oder XHCI) beschrieben.

USB-Device-Specific-Methode (_DSM)

Windows definiert eine Device-Specific-Methode (_DSM), um die geräteklassenspezifische Konfiguration des USB-Subsystems zu unterstützen. Weitere Informationen finden Sie unter USB Device-Specific-Methode.

Unterstützung für integrierte USB-Transaktionsübersetzung (TT) (_HRV)

Standardmäßige EHCI-Hostcontroller unterstützen nur Hochgeschwindigkeits-USB-Geräte. Auf SoC-Plattformen unterstützt Windows zwei gängige Designs von EHCI-kompatiblen Hostcontrollern, die einen integrierten Transaktionsübersetzer für Low-Speed- und Full-Speed-USB-Geräte implementieren. Das HardwareRevisionsobjekt (_HRV) gibt den Typ der integrierten TT-Unterstützung für den USB-Hostcontrollertreiber an.

Die _HRV wird nach den folgenden Kriterien festgelegt:

• NoIntegratedTT – _HRV = 0

  Standard-EHCI-Hostcontroller implementieren keine integrierten Transaktionsübersetzungen, und ein _HRV Wert von 0 ist nur für diese Controller gültig. Es ist nicht erforderlich, das _HRV-Objekt für diese Controller einzuschließen.

• IntegratedTTSpeedInPortSc – _HRV = 1

  Aktivieren sie die integrierte TT-Unterstützung. Diese Variante der Schnittstelle umfasst die LowSpeed- und HiSpeed-Bits im PORTSC-Register selbst. Diese Bits befinden sich bei den Bitoffsets 26 bzw. 27. Beim Bestimmen der Geschwindigkeit liest der EHCI-Treiber die PORTSC und extrahiert die Geschwindigkeitsinformationen aus diesen Bits.

• IntegratedTTSpeedInHostPc – _HRV = 2

  Aktivieren sie die integrierte TT-Unterstützung. Diese Variante der Schnittstelle umfasst die LowSpeed- und HiSpeed-Bits in einem separaten HOSTPC-Register. Wenn der EHCI-Treiber die Portgeschwindigkeit bestimmen muss, liest er das HOSTPC-Register, das dem port of interest entspricht, und extrahiert die Geschwindigkeitsinformationen.

USB XHCI D3cold-Unterstützung

Zusätzlich zum selektiven Anhalten können interne USB-Geräte, die mit XHCI-Controllern verbunden sind, in einen D3cold-Zustand versetzt und ausgeschaltet werden, wenn sie nicht verwendet werden. Weitere Informationen finden Sie unter Geräteenergieverwaltung. Alle USB-Gerätefunktionstreiber müssen D3cold aktivieren.

USB-Port-spezifische Objekte

Windows muss die Sichtbarkeit und Verbindungsfähigkeit von USB-Anschlüssen auf dem System kennen. Dies ist erforderlich, um dem Benutzer genaue Informationen über Ports und Geräte bereitzustellen. Zu diesem Zweck werden zwei Objekte verwendet: Standort des physischen Geräts (_PLD) und USB-Portfunktionen (_UPC). Weitere Informationen finden Sie unter

• Abschnitte 6.1.6, "Geräteidentifikationsobjekte" und 9.13.1, "USB 2.0 Host Controller und _UPC und _PLD" in der ACPI 5.0-Spezifikation.

• Verwenden von ACPI zum Konfigurieren von USB-Anschlüssen auf einem Computer.

SD-Hostcontroller und -Geräte

SD-Hostcontroller werden auf SoC-Plattformen für den Zugriff auf Speicher sowie auf E/A-Geräte verwendet. Windows enthält einen Posteingangstreiber für SDA-Standard-Hostcontrollerhardware. Zur Kompatibilität mit diesem Treiber muss ein SD Host Controller-Gerät die SD-Hostcontrollerspezifikation der SD Association erfüllen.

Auf SoC-Plattformen kann der SD-Hostcontroller von ACPI aufgezählt werden. Windows verwendet die folgenden ACPI-Namespaceobjekte beim Auflisten und Konfigurieren kompatibler SD-Hardware:

• Eine vom Anbieter zugewiesene ACPI-kompatible Hardware-ID (_HID).

• Ein Eindeutiges ID-Objekt (_UID), wenn mehr als eine instance des SD-Controllers im Namespace vorhanden ist (also zwei oder mehr Knoten, die identische Geräteidentifikationsobjekte aufweisen).

• Eine kompatible ID (_CID) für den SDA-standardkonformen SD-Hostcontroller (PNP0D40).

• Die dem Controller zugewiesenen aktuellen Ressourceneinstellungen (_CRS). Die Ressourcen des Controllers werden wie folgt beschrieben:

  • Hardwareressourcen für alle implementierten Slots sind enthalten. Ein Slot ist ein Verbindungspunkt auf dem SDIO-Bus für ein Speicher- oder E/A-Gerät. Jeder Slot ist einem Standardsatz von Registern und einem Interrupt im SD-Hostcontroller zugeordnet, die für die Kommunikation mit dem verbundenen Gerät verwendet werden. SD-Hostcontroller können eine beliebige Anzahl von Slots implementieren, aber auf SoC-Plattformen gibt es in der Regel nur einen.

  • Slotressourcen werden in der Reihenfolge der Slotnummer aufgelistet (die Ressourcen von Slot 0 sind zuerst, die Ressourcen von Slot 1 sind an zweiter Stelle usw.).

  • Ressourcen werden für jeden Slot in der folgenden Reihenfolge aufgeführt:

    • Die Basisadresse des SD-Standardregisters, das für den Slot festgelegt ist.

    • Der SD-Standard-Interrupt für den Slot.

    • Eine GPIO-Interruptressource für den Slot zum Signalisieren Karte Ein- und Auslagerungen (wenn die Standard-SD-Karte-Detect-Schnittstelle während aller Energiezustände nicht unterstützt wird).

    • Eine GPIO-Eingaberessource für den Slot zum Lesen, ob sich ein Karte derzeit im Slot befindet (wenn die Standard-SD-Karte-Detect-Schnittstelle während aller Energiezustände nicht unterstützt wird). Verwendet denselben Pin wie der Einfüge-/Entfernungs-Interrupt.

    • Eine zweite GPIO-Eingaberessource zum Lesen, ob der Karte im Slot schreibgeschützt ist (wenn die Standard-SD-Schreibschutzschnittstelle während aller Energiezustände nicht unterstützt wird).

Die Interrupts müssen reaktiviert sein (beschrieben als "SharedAndWake" oder "ExclusiveAndWake").

Eingebettete SD-Geräte

Sd-verbundene Geräte werden vom SD-Bustreiber aufgelistet. SD-Geräte, die in die Plattform integriert sind, müssen auch im ACPI-Namespace als untergeordnete Elemente des SD-Hostcontrollers aufgeführt werden. Diese Anforderung ermöglicht es dem Betriebssystem, das busaufgezählte Gerät den plattformspezifischen Attributen zuzuordnen, die von ACPI-Objekten für das Gerät bereitgestellt werden (z. B. Nicht-Entfernbarkeit, Geräteleistungsstatus, verbrauchte GPIO- oder SPB-Ressourcen usw.). Für diese Zuordnung benötigt der Gerätenamespace das Address -Objekt (_ADR), das die Adresse des Geräts auf dem SDIO-Bus kommuniziert. Das _ADR-Objekt gibt eine ganze Zahl zurück.

Für den SDIO-Bus wird der Wert dieser ganzen Zahl wie folgt definiert:

• Hohes Wort – Slotnummer (0 – erster Slot)

• Niedriges Wort – Funktionsnummer (Definitionen finden Sie unter SD-Spezifikation.)

Ein eingebetteter SD-Gerätenamespace muss außerdem Folgendes umfassen:

• Ein Remove-Methode -Objekt (_RMV), das 0 zurückgibt (um anzugeben, dass das Gerät nicht entfernt werden kann).

• Ein _CRS Objekt für die vom Gerät benötigten Seitenbandressourcen (z. B. GPIO-Pins oder SPB-Verbindungen), falls erforderlich.

Geräte der Bildverarbeitungsklasse (Kameras)

Kamerageräte können vom Grafiktreiber oder über USB aufgezählt werden. In beiden Fällen muss Windows den physischen Standort der Kamera kennen, damit die entsprechende Benutzeroberfläche angezeigt werden kann. Hierzu werden Kamerageräte, die in das Gehäuse des Systems integriert sind und eine mechanisch feste Richtung aufweisen, im ACPI-Namespace enthalten und das Objekt Physischer Gerätestandort (Physical Device Location, _PLD) bereitstellen. Dies erfordert:

• Das Kameragerät, das als untergeordnetes (geschachteltes Gerät) des Enumeratorgeräts (entweder das GPU-Gerät oder das USB-Gerät) angezeigt werden soll.

• Das Kameragerät, das das Address-Objekt (_ADR) bereitstellt, das die Adresse der Kamera auf dem Bus des übergeordneten Geräts enthält.

  • Informationen zu USB finden Sie unter ACPI-Namespacehierarchie und _ADR für eingebettete USB-Geräte im nächsten Abschnitt unten.

  • Für Grafiken ist dies der Bezeichner, der in der _DOD-Methode angegeben wird, die unter dem GPU-Gerät bereitgestellt wird. Weitere Informationen finden Sie in Anhang B, "Videoerweiterungen", der ACPI 5.0-Spezifikation.

• Das Kameragerät, das das _PLD-Objekt bereitstellen soll.

• Wenn der Kameratreiber Seitenbandressourcen benötigt (z. B. GPIO-Interrupt- oder E/A-Verbindungen oder eine SPB-Verbindung), wird das _CRS-Objekt für diese Ressourcen bereitgestellt.

Im _PLD-Objekt werden die Felder Panel (Bit 67-69), Deckelfeld (Bit 66) und Dockfeld (Bit 65) auf korrekte Werte für die Oberfläche festgelegt, auf der die Kamera montiert ist. Alle anderen Felder sind optional. Für mobile Handheld-Geräte, einschließlich Tablets, ist die Frontleiste das, das den Bildschirm hält, und sein Ursprung befindet sich in der unteren linken Ecke, wenn der Bildschirm im Hochformat angezeigt wird. Mit diesem Verweis gibt "Front" an, dass die Kamera den Benutzer (Webcam) anzeigt, während "Zurück" angibt, dass die Kamera vom Benutzer entfernt (Stand- oder Videokamera). Weitere Informationen finden Sie in Abschnitt 6.1.8, "_PLD (Physischer Standort des Geräts)" in der ACPI 5.0-Spezifikation.

ACPI-Namespacehierarchie und _ADR für eingebettete USB-Geräte

Beim Hinzufügen eingebetteter USB-Geräte zum ACPI-Namespace muss die Hierarchie der Geräteknoten genau mit der Hierarchie der Geräte übereinstimmen, die vom Windows-USB-Treiber aufgezählt werden. Dies kann ermittelt werden, indem Sie Windows Geräte-Manager im Modus "Nach Verbindung anzeigen" untersuchen. Die gesamte Hierarchie, beginnend mit dem USB-Hostcontroller bis hin zum eingebetteten Gerät, muss einbezogen werden. Die "Address"-Eigenschaft, die in Geräte-Manager für jedes Gerät bereitgestellt wird, ist die Adresse, die die Firmware im _ADR des Geräts melden muss.

Die ACPI 5.0-Spezifikation definiert die Adressen für USB-Geräte wie folgt:

USB Root HUB: Nur untergeordnetes Element des Hostcontrollers. Es muss eine _ADR von 0 aufweisen. Andere untergeordnete Elemente oder Werte von _ADR sind nicht zulässig.

USB-Ports: Portnummer (1-n)

USB-Geräte, die mit einem bestimmten Port verbunden sind, teilen sich die Adresse dieses Ports.

Wenn es sich bei dem an einen Port verbundenen Gerät um ein zusammengesetztes USB-Gerät handelt, müssen die Funktionen innerhalb des zusammengesetzten Geräts die folgende Adresse verwenden:

USB-Funktion innerhalb eines zusammengesetzten USB-Geräts: Portnummer des Ports, an den das zusammengesetzte Gerät angeschlossen ist, PLUS die erste Schnittstellennummer der Funktion. (Arithmetische Addition).

Weitere Informationen finden Sie unter Identifizieren des Standorts interner Kameras.

ASL-Codebeispiele

Im folgenden ASL-Codebeispiel wird eine USB-Webcam beschrieben, die direkt an USB-Anschluss 3 angeschlossen ist.

Device (EHCI) {
    ...  // Objects required for EHCI devices
    Device {RHUB) {         // the Root HUB
     Name (_ADR, ZERO)      // Address is always 0.
     Device (CAM0) {          // Camera connected directly to USB
                       //   port number 3 under the Root.
            Name (_ADR, 3)      // Address is the same as the port.
            Method (_PLD, 0, Serialized) {...}
            }  //  End of Camera device
    } // End of Root Hub Device
}  // End of EHCI device

Im folgenden ASL-Codebeispiel wird ein zusammengesetztes USB-Gerät beschrieben, das eine Webcam als Funktion 2 implementiert.

Device (EHCI) {
    ...  // Objects required for EHCI devices
    Device {RHUB) {
     Name (_ADR, ZERO)
     Device (CUSB) {        // Composite USB device
                    //   connected to USB port number 3
                    //   under the Root.
            Name (_ADR, 3)      // Address is the same as the port.
            Device (CAM0) { // Camera function within the
                    //   Composite USB device.
                Name (_ADR, 5)  // Camera function has a first
                    //   Interface number of 2, so
                    //   Address is 3 + 2  = 5.
                Method (_PLD, 0, Serialized) {...}
            }  //  End of Camera device
        } // End of Composite USB Device
    } // End of Root Hub Device
}  // End of EHCI device

Im folgenden ASL-Codebeispiel wird eine Webcam beschrieben, die über I2C verbunden ist.

Device (GPU0) {
    ... // Other objects required for graphics devices
    Name (_DOD, Package ()  // Identifies the children of this graphics device.
                // Each integer must be unique within the GPU0 namespace.
                {
                    0x00024321,  // The ID for CAM0. It is a non-VGA
                    //   device, cannot be detected by
                    //   the VGA BIOS, and uses a vendor-
                    //   specific ID format in bits 15:0
                    //   (see the _DOD specification).
                    ...     // Other child device IDs (for
                    //   example, display output ports)
                })
    Device (CAM0) {
        Name (_ADR, 0x00024321) // The identifier for this device
                    //   (Same as in _DOD above)
        Name (_CRS, ResourceTemplate()
            {
            // I2C Resource
            // GPIO interrupt resource(s), if required by
            //   driver
            // GPIO I/O resource(s), if required by driver
                ...
            })
        Method (_PLD, 0, Serialized) {...}
    } // End of CAM0 device
} // End of GPU0 device

HID-over-I2C-Geräte

Windows enthält einen Klassentreiber für Human Interface Devices (HID). Dieser Treiber ermöglicht generische Unterstützung für eine vielzahl von Eingabegeräten (z. B. Touchpanels, Tastaturen, Mäuse und Sensoren). Auf SoC-Plattformen können HID-Geräte über I2C mit der Plattform verbunden werden und werden von ACPI aufgezählt. Aus Gründen der Kompatibilität mit der HID-Klassenunterstützung in Windows werden die folgenden Namespaceobjekte verwendet:

• Ein herstellerspezifischer _HID

• Eine _CID von PNP0C50

• Eine _CRS mit:

  • Eine I2CSerialBusConnection-Ressource für den Zugriff auf das Gerät

  • Eine GpioInt-Ressource für Interrupts

• Die HIDI2C-_DSM-Methode zum Zurückgeben der HID-Deskriptorregisteradresse auf dem Gerät. Weitere Informationen finden Sie unter HIDI2C Device-Specific-Methode (_DSM).

Schaltflächengeräte

Für SoC-Plattformen unterstützt Windows sowohl die von ACPI definierte Steuerungsmethode Power Button als auch ein Windows-kompatibles Array mit fünf Tasten. Der Netzschalter, unabhängig davon, ob er als ACPI Control Method Power Button oder als Teil des Windows-kompatiblen Schaltflächenarrays implementiert ist, führt folgendes aus:

• Bewirkt, dass die Plattform aktiviert wird, wenn sie ausgeschaltet ist.

• Generiert das Power Button Override-Ereignis, wenn es gedrückt gehalten wird. Weitere Informationen finden Sie in Abschnitt 4.8.2.2.1.3, "Power Button Override" der ACPI 5.0-Spezifikation.

Ein-/Ausschalter für die Steuerungsmethode

Clamshell-Designs und andere Systeme mit integrierten oder verbundenen Tastaturen implementieren die ACPI-definierte Steuerungsmethode Power Button (Abschnitt 4.8.2.2.2.1.2 der ACPI 5.0-Spezifikation) mithilfe GPIO-Signaled ACPI-Ereignisse (Abschnitt 5.6.5 der ACPI 5.0-Spezifikation). Um das Netzschaltergerät zu unterstützen, lautet der Namespace:

• Beschreibt den GPIO-Interruptpin des Netzschalters als nicht freigegebene (exklusive) GPIO-Interruptressource.

• Listet die GPIO-Interruptressource des Netzschalters im _AEI Objekt des GPIO-Controllers auf, mit dem sie verbunden ist.

• Stellt die zugeordnete Ereignismethode (Lxx/Exx/EVT) unter dem GPIO-Controllergerät bereit. Diese Ereignismethode benachrichtigt den Treiber "Control Method Button" im Betriebssystem, dass das Schaltflächenereignis aufgetreten ist.

Weitere Informationen finden Sie unter Hardwareschaltflächen für Windows 8 Tablet- und Convertible-Geräte.

Windows-kompatibles Schaltflächenarray

Für Plattformen ohne Tastatureingabe, z. B. Slates, bietet Windows einen generischen Treiber für ein Array von fünf Schaltflächen. Jede Schaltfläche im Array hat ihre definierte Funktion (siehe die nummerierten Elemente in der Liste unten), und bestimmte Tastenkombinationen "Halten und Drücken" haben eine zusätzliche Bedeutung auf der Benutzeroberfläche. Es sind keine Tastenkombinationen definiert, für die das Herunterhalten des Netzschalters erforderlich ist. Aus Gründen der Kompatibilität mit dem Treiber der Windows-Posteingangsschaltfläche wird das windowskompatible Button Array ACPI-Gerät implementiert. Das Gerät wird wie folgt definiert:

• Jede der fünf Tasten ist mit einem eigenen dedizierten Interrupt-Pin auf der Plattform verbunden.

• Jeder Interrupt-Pin wird als nicht freigegebene (exklusive), edgeausgelöste (Edge)-Interruptressource konfiguriert, die an beiden Edges unterbricht (ActiveBoth).

• Der Gerätenamespace enthält eine vom Hersteller definierte _HID sowie eine _CID PNP0C40.

• Die GPIO-Interruptressourcen im _CRS-Objekt werden in der folgenden Reihenfolge aufgeführt:

  1. Interrupt entsprechend der "Ein/Aus"-Taste

     Die Ein/Aus-Taste muss wake-fähig (ExclusiveAndWake) sein.

  2. Interrupt entsprechend der Schaltfläche "Windows"

     Die Windows-Schaltfläche muss wake-fähig (ExclusiveAndWake) sein.

  3. Interrupt entsprechend der Schaltfläche "Lauter"

     Die Schaltfläche "Volume Up" darf nicht weckfähig sein (muss Exklusiv verwenden).

  4. Interrupt entsprechend der Schaltfläche "Leiser"

     Die Schaltfläche "Leiser" darf nicht weckfähig sein (muss Exklusiv verwenden).

  5. Interrupt entsprechend der Schaltfläche "Drehsperre", falls unterstützt

     Die Schaltfläche "Rotationssperre" darf nicht reaktivfähig sein (muss Exklusiv verwenden).

Weitere Informationen finden Sie unter Hardwareschaltflächen für Windows 8 Tablet- und Convertible-Geräte.

Um die Weiterentwicklung der Windows-Schaltflächen-Benutzeroberfläche zu unterstützen, definiert Windows eine Device-Specific-Methode (_DSM) für das Windows Button Array-Gerät. Weitere Informationen finden Sie unter Windows Button Array Device-Specific Method (_DSM).

Dock- und konvertierbare PC-Erfassungsgeräte

Windows unterstützt Docks und Convertibles (Clamshell/Tablet-Kombinationen) durch die Verwendung von zwei Erfassungsgeräten im ACPI-Namespace. Diese Geräte werden vom Windows-Posteingangsschaltflächentreiber unterstützt. Beachten Sie, dass die gleichen Anforderungen, die für das Button Array-Gerät gelten, auch für diese Geräte gelten:

• GPIO ActiveBoth-Interrupts müssen mit einem GPIO-Controller auf soC verbunden sein (nicht mit einem MIT SPB verbundenen GPIO-Controller).

• Der GPIO-Controller muss Unterbrechungen im Pegelmodus und dynamische Polaritätsreprogrammierung unterstützen.

• Der GPIO-Controllertreiber muss die ActiveBoth-Emulation verwenden, die von der GPIO-Frameworkerweiterung (GpioClx) bereitgestellt wird.

• Wenn der behauptete Zustand ("Docked" oder "Converted") nicht behauptet ist, ist der GPIO-Controller _DSM Methode erforderlich, um das Standardverhalten des GPIO-Treiberstapels außer Kraft zu setzen. Weitere Informationen finden Sie im Abschnitt GPIO-Controllergeräte im Thema Allgemeine E/A (GPIO).

Weitere Informationen finden Sie unter Hardwareschaltflächen für Windows 8 Tablet- und Convertible-Geräte.

Dock-Erfassungsgerät

Ein Dock-Erfassungsgerät unterbricht das System, wenn ein Dock an das System angeschlossen oder nicht angeschlossen ist. Diese Modusänderungsinformationen werden verwendet, um die Benutzereingabe- und Ausgabeerfahrung nach Bedarf zu aktualisieren. Der Namespace des Geräts erfordert Folgendes:

• Ein herstellerspezifischer _HID

• Eine _CID von PNP0C70

• Ein _CRS mit einem ActiveBoth-Interrupt

  Interrupt kann nicht aktiviert werden.

Konvertierbares PC-Sensorgerät

Ein Convertible-PC-Sensing-Gerät unterbricht das System, wenn ein konvertierbarer PC vom Tablet zum Clamshell-Formfaktor wechselt. Diese Modusänderungsinformationen werden verwendet, um die Benutzereingabe- und Ausgabeerfahrung nach Bedarf zu aktualisieren. Der Namespace des Geräts erfordert Folgendes:

• Ein herstellerspezifischer _HID

• Eine _CID von PNP0C60

• Ein _CRS mit einem ActiveBoth-Interrupt

  Interrupt kann nicht aktiviert werden.