Sensordatenbatches zur Energieeinsparung

In diesem Thema werden die Schnittstellen behandelt, die zwischen der Sensorklassenerweiterung und dem Sensortreiber erforderlich sind, um die Batchverarbeitung von Sensordaten in Windows 10 zu implementieren.

Einführung

Ein Sensortreiber, der die Datenbatchverarbeitung implementiert, ermöglicht es dem Anwendungsprozessor, Strom zu sparen, da der Prozessor Sensordaten seltener empfängt und verarbeitet. In diesem Fall puffert der Sensortreiber die Sensordatenbeispiele in der Sensorhardware und überträgt sie dann in einem Batch an die Sensorklassenerweiterung. Zur Unterstützung der Batchverarbeitung müssen Sie einen universellen UMDF 2.0-Sensortreiber bereitstellen, der die erforderlichen Schnittstellen implementiert.

Batchlatenz

Die Batch-Latenz ist definiert als die maximale Zeitspanne, für die ein Sensor ein Datenbeispiel nach der Erfassung puffern kann, bevor es an die Sensorklassenerweiterung übermittelt wird. Der "Zeitplan" für die Batchverarbeitung von Sensordaten wird ausgelöst, wenn die Sensorereignisse vom Treiber übermittelt werden, basierend auf dem Batchlatenzwert, wie in den folgenden Diagrammen dargestellt.

Im Fall eines Treibers, der keine Datenbatches implementiert, sammelt und sendet der Treiber die Sensordaten einfach, sobald sie verfügbar werden. Um beispielsweise N-Datenbeispiele zu senden, würde der Treiber die Sammlung und das Senden der Datenbeispiele initiieren, n mal.

Bei einem Treiber, der die Datenbatchverarbeitung implementiert, erfolgt die Datensammlung und Übermittlungssequenz in Batches, wie im unmittelbar vorangehenden Diagramm dargestellt. Der Batchlatenzwert wird von der Sensorklassenerweiterung angegeben. Wenn die Sensorhardware also beispielsweise N-Datenproben sammeln und übertragen muss, könnte der Sensortreiber den Prozess in zwei Batches aufteilen. Die erste Hälfte der N-Datenbeispiele wird nach einem Zeitintervall gesendet, das dem Batchlatenzzeitraum entspricht. Nach einem weiteren Batchlatenzzeitintervall würde dann die zweite Hälfte der Datenbeispiele gesendet, wobei insgesamt zwei Übertragungen durchgeführt werden, verglichen mit den N-Übertragungen, die für die normale Übermittlungsmethode erforderlich sind.

Sensoreigenschaften

Zusätzlich zu den erforderlichen allgemeinen Sensoreigenschaften und Enumerationseigenschaften muss ein Treiber, der die Datenbatchverarbeitung unterstützt, auch die folgenden Eigenschaften melden:

• PKEY_Sensor_FifoReservedSize_Samples
• PKEY_Sensor_FifoMaxSize_Samples
• PKEY_Sensor_WakeCapable

Weitere Informationen finden Sie unter Allgemeine Sensoreigenschaften und Enumerationseigenschaften.

Wenn das Sensorhardwaresubsystem aktivierungsfähig ist, sollte es sicherstellen, dass es früh genug reaktiviert wird, um Pufferüberläufe zu vermeiden.

Optionale DDSI-Funktionen für die Datenbatchverarbeitung

Die DDSI-Funktionen (Device Driver Software Interface) sind die Schnittstelle zwischen dem Treiber und der Klassenerweiterung. Zur Unterstützung der Datenbatches muss ein Treiber die folgende DDSI-Funktion implementieren, damit die Sensorklassenerweiterung die Batchlatenz festlegen kann.

• EvtSensorSetBatchLatency

  Dies ist eine Rückruffunktion, die die Batchlatenz für einen angegebenen Sensor festlegt. Der Treiber sollte die Batchlatenz abhängig von der Pufferverfügbarkeit auf einen Wert festlegen, der kleiner oder gleich dem BatchLatencyMs-Parameter ist.

Der Treiber muss auch alle erforderlichen DDSI-Funktionen implementieren. Weitere Informationen finden Sie unter _SENSOR_CONTROLLER_CONFIG-Struktur.

Die Sensorklassenerweiterung kann optional die Batchlatenz angeben. Die Standardmäßige Batchlatenz für alle Sensoren ist null (0). Dies wird verwendet, um anzugeben, dass die Stichproben nicht in Batches verarbeitet werden. Sensorbeispiele werden nur dann in Batches bereitgestellt, wenn die Klassenerweiterung EvtSensorSetBatchLatency aufruft , um einen Batchlatenzwert festzulegen. Andernfalls werden die Stichproben normal mit der regelmäßigen Datenintervallrate übermittelt.

Die Sensorklassenerweiterung kann EvtSensorSetBatchLatency aufrufen, um den Batchlatenzwert jederzeit zu ändern. Insbesondere kann diese Funktion aufgerufen werden, während der angegebene Sensor bereits aktiv ist und ausgeführt wird. Dies sollte nicht zum Verlust von Ereignissen führen. Es wird erwartet, dass der Sensortreiber proben der neuesten Batches sofort (nach bestem Aufwand) sammelt und zu liefern beginnt. Der Treiber sollte die von der Klassenerweiterung angegebene Batchlatenz nicht überschreiten.

Es ist wichtig zu beachten, dass aufgrund der Datenbatchverarbeitung keine Änderungen an den Methoden und Ereignissen der Sensordatenübermittlung impliziert werden. Wenn die Batchlatenz abläuft, ruft der Treiber SensorsCxSensorDataReady wiederholt auf, um alle gepufferten Datenbeispiele einzeln zu übermitteln. Die Datenproben werden von ihren Zeitstempeln begleitet (die in den zugeordneten PKEY_SensorData_Timestamp Datenfeldern enthalten sind), die angeben, wann die einzelnen Stichproben entnommen wurden. Weitere Informationen zu PKEY_SensorData_Timestamp finden Sie unter Allgemeine Datenfelder.

Batchlatenz- und Datenratenbeziehung

Batchlatenz und Datenrate hängen wie folgt zusammen:

Wobei SensorBatching_MaxSize_Bytes die maximale Größe des Puffers für die Sensordaten in Batchverarbeitung ist. Wenn es sich bei Ihrem Sensor um einen Beschleunigungsmesser handelt, empfehlen wir einen Hardwarepuffer, der groß genug ist, um 250 oder mehr Proben aufzunehmen. Die Datenrate wird in Millisekunden ausgedrückt, und es ist die Dauer, die zum Übertragen einer Datenstichprobe benötigt wird. Die Anzahl der Stichproben, die die Sensorhardware in einem Batch speichern muss, ist umgekehrt proportional zur Datenrate. Je kleiner die Datenrate, desto größer ist der Beispielpuffer, der zum Speichern der Batchbeispiele für einen bestimmten Batchlatenzwert erforderlich ist. In der obigen Formel wird die Batchlatenz durch BatchLatencyMs und die Datenrate durch DataRateMs dargestellt. Wenn die Kombination aus BatchLatencyMs und DataRateMs zu einer Puffergröße führt, die größer als SensorBatching_MaxSize_Bytes ist, legen EvtSensorSetBatchLatency und EvtSensorSetDataInterval die Batchlatenz auf den Wert fest, der in der obigen Formel angezeigt wird.

Wenn der Aufrufer einen BatchLatencyMs-Wert angibt, der kleiner als DataRateMs ist, werden die Daten ohne Pufferung übermittelt.

Batchverarbeitung mit Datenschwellenwerten

Ein Sensortreiber, der die Datenbatchverarbeitung implementiert, kann EvtSensorSetDataThresholds verwenden, um einen Datenschwellenwert ungleich Null festzulegen. In diesem Fall wird der Datensammlungs-, Batchverarbeitungs- und Übermittlungsprozess aufgerufen, wenn der Unterschied in den Datenwerten zwischen den aktuellen Und den letzten Messwerten den mit EvtSensorSetDataThresholds festgelegten Datenschwellenwert überschreitet. Die Verwendung von Datenbatches zusammen mit Datenschwellenwerten ermöglicht es dem Sensortreiber also, noch mehr Strom zu sparen.

Wenn die Sensorklassenerweiterung Datenschwellenwerte ungleich 0 (null) zusammen mit der Datenbatchverarbeitung festsetzt, wird erwartet, dass der Treiber Batchproben mit genauen Zeitstempeln liefert und auch die Datenschwellenwerte berücksichtigt. Wenn die Sensorhardware selbst nicht in der Lage ist, genaue Zeitstempel bei der Erzwingung von Datenschwellenwerten beizubehalten, kann sie Stichproben sammeln, ohne Datenschwellenwerte zu erzwingen. In einem solchen Fall sollte der Treiber jedoch Beispiele herausfiltern, die die aktuellen Einstellungen für den Datenschwellenwert nicht erfüllen, bevor sie an die Sensorklassenerweiterung bereitgestellt werden.

Beispiele für Sequenzdiagramme

Hier sind Sequenzdiagramme, die die Verwendung der optionalen DDSI-Funktionen für die Datenbatchverarbeitung zeigen, die unter Optionale DDSI-Funktionen für die Datenbatchverarbeitung erwähnt wurden. Wir können bei Bedarf weitere Sequenzdiagramme hinzufügen, um Szenarien basierend auf Partnerfeedback zu klären.

Szenario 1

In diesem Szenario legt die Sensorklassenerweiterung die Batchlatenz und das Datenintervall fest, bevor der Sensor gestartet wird. Sobald der Sensor gestartet wird, übermittelt er in regelmäßigen Abständen Batches unter Berücksichtigung der Seteigenschaften.

Szenario 2

In diesem Szenario legt die Sensorklassenerweiterung die Batchlatenz, das Datenintervall und die Datenschwellenwerte vor dem Starten des Sensors fest. Sobald der Sensor gestartet wird, übermittelt er in regelmäßigen Abständen Batches unter Berücksichtigung der Seteigenschaften. Beachten Sie, dass der Treiber keinen Batch übermitteln sollte, es sei denn, es gibt ein Beispiel, das die Datenschwellenwerte erfüllt, die innerhalb der angegebenen Batchlatenz gesendet werden muss.

Szenario 3

In diesem Szenario legt die Sensorklassenerweiterung die Batchlatenz und das Datenintervall vor dem Starten des Sensors fest. Sobald der Sensor gestartet wird, übermittelt er in regelmäßigen Abständen Batches unter Berücksichtigung der festgelegten Eigenschaften. Die Sensorklassenerweiterung ändert die Batchlatenz und das Datenintervall, während der Sensor ausgeführt wird, und der Treiber beginnt sofort mit der Übermittlung von Stichproben in Übereinstimmung mit den neuen Werten, ohne dass während der Ausführung Datenproben verloren gehen.

Hardwarekonfigurationen für die Datenbatchverarbeitung

Sensordaten müssen in der Sensorhardware in Batches ohne Beteiligung des Anwendungsprozessors verarbeitet werden. Dadurch kann der Prozessor in den Energiesparmodus versetzt werden, während die Daten im Batch verarbeitet werden, um Strom zu sparen. Das folgende Diagramm zeigt die möglichen Konfigurationen für die sensorhardwarebasierte Datenbatchverarbeitung.

• Konfiguration 1: Der FIFO-Puffer wird in der Sensorkomponente implementiert, die direkt mit dem Anwendungsprozessor verbunden ist.

• Konfiguration 2: Der FIFO-Puffer wird im Hardwarekern des Low-Power-Sensors implementiert, an den die Sensorkomponente angeschlossen ist. In diesem Fall kann der FIFO-Puffer je nach Sensorkerndesign für mehrere Sensoren oder sogar für Nicht-Sensorkomponenten freigegeben werden. Der Low-Power-Sensorkern ist wiederum mit dem Anwendungsprozessor verbunden und kann in das SoC integriert werden. Oder es kann sich um eine externe Komponente handelt.

• Konfiguration 3: Der FIFO-Puffer wird für die Sensorkomponente implementiert. Die Sensorkomponente ist mit einem Low-Power-Sensorkern verbunden, der mit dem Anwendungsprozessor verbunden ist. Die Sensorkomponente kann in den SoC integriert werden oder eine externe Komponente sein.

• Konfiguration 4: Der FIFO-Puffer wird auf der Sensorkomponente und dem Low-Power-Sensorkern implementiert. Die Sensorkomponente ist mit einem Low-Power-Sensorkern verbunden, der wiederum mit dem Anwendungsprozessor verbunden ist. Die Sensorkomponente kann in den SoC integriert werden, oder es kann sich um eine externe Komponente handelt. Es ist erwähnenswert, dass der Sensorkern verwendet werden kann, um ein zu flaches FIFO zu erweitern.

Wichtig ist, dass das FIFO auf der Sensorkernhardware oder Sensorhardware oder auf beiden implementiert werden kann. Der Treiber abstrahiert dies für das Betriebssystem und stellt eine einheitliche Schnittstelle über den DDSI dar.

Das folgende Diagramm veranschaulicht die verschiedenen Konfigurationen, die in der vorherigen Liste beschrieben sind.

Vollständiges Pufferverhalten in der Hardware

Unter normalen Umständen sollte der Treiber den Hardwarepuffer mindestens einmal jedes Zeitintervall lesen, das BatchLatencyMs entspricht, um sicherzustellen, dass keine Daten gelöscht oder verloren gehen. Wenn sich der Hardware-FIFO-Puffer füllt, sollte er sich umschließen und sich wie ein Zirkelpuffer verhalten, wobei ältere Ereignisse überschrieben werden.