Batching

Was ist Stapeln?

Beim Stapeln werden Sensorereignisse in einem Sensor-Hub und/oder Hardware-FIFO gepuffert, bevor die Ereignisse über den Sensor-HAL gemeldet werden. Der Ort, an dem Sensorereignisse gepuffert werden (Sensor-Hub und/oder Hardware-FIFO), wird auf dieser Seite als „FIFO“ bezeichnet. Wenn die Stapelverarbeitung von Sensorereignissen nicht aktiv ist, werden Sensorereignisse sofort an die Sensor-HAL gemeldet, sofern verfügbar.

Die Stapelverarbeitung kann erhebliche Energieeinsparungen ermöglichen, indem der Hauptanwendungsprozessor (AP), auf dem Android ausgeführt wird, nur dann aktiviert wird, wenn viele Sensorereignisse zur Verarbeitung bereit sind, anstatt ihn für jedes einzelne Ereignis zu aktivieren. Die potenziellen Energieeinsparungen stehen in direktem Zusammenhang mit der Anzahl der Ereignisse, die der Sensor-Hub und/oder FIFO puffern kann: Es besteht ein größeres Potenzial für Energieeinsparungen, wenn mehr Ereignisse gebündelt werden können. Beim Batching wird Speicher mit geringem Stromverbrauch genutzt, um die Anzahl der AP-Weckvorgänge mit hohem Stromverbrauch zu reduzieren.

Die Stapelverarbeitung kann nur erfolgen, wenn ein Sensor über einen Hardware-FIFO verfügt und/oder Ereignisse innerhalb eines Sensor-Hubs puffern kann. In beiden Fällen muss der Sensor über SensorInfo.fifoMaxEventCount die maximale Anzahl von Ereignissen melden, die gleichzeitig gestapelt werden können.

Wenn für einen Sensor innerhalb eines FIFO Platz reserviert ist, muss der Sensor die Anzahl der reservierten Ereignisse über SensorInfo.fifoReservedEventCount melden. Wenn der FIFO dem Sensor zugeordnet ist, ist SensorInfo.fifoReservedEventCount die Größe des FIFO. Wenn der FIFO von mehreren Sensoren gemeinsam genutzt wird, kann dieser Wert Null sein. Ein häufiger Anwendungsfall besteht darin, einem Sensor die Nutzung des gesamten FIFO zu ermöglichen, wenn er der einzige aktive Sensor ist. Wenn mehrere Sensoren aktiv sind, ist jedem Sensor garantiert Platz für mindestens SensorInfo.fifoReservedEventCount Ereignisse im FIFO. Bei Verwendung eines Sensor-Hubs kann die Garantie durch Software durchgesetzt werden.

Sensorereignisse werden in den folgenden Situationen gestapelt:

• Die aktuelle maximale Berichtslatenz des Sensors ist größer als Null, was bedeutet, dass Sensorereignisse bis zur maximalen Berichtslatenz verzögert werden können, bevor sie über die HAL gemeldet werden.
• Der AP befindet sich im Suspend-Modus und der Sensor ist ein Nicht-Wake-up-Sensor. In diesem Fall dürfen Ereignisse den AP nicht aufwecken und müssen gespeichert werden, bis der AP aufwacht.

Wenn ein Sensor die Stapelverarbeitung nicht unterstützt und der AP im Ruhezustand ist, werden nur Aktivierungssensorereignisse an den AP gemeldet und Nichtaktivierungsereignisse dürfen nicht an den AP gemeldet werden.

Batch-Parameter

Die beiden Parameter, die das Verhalten der Stapelverarbeitung steuern, sind „sampling_period_ns “ und „max_report_latency_ns“ . sampling_period_ns bestimmt, wie oft ein neues Sensorereignis generiert wird, und max_report_latency_ns bestimmt, wie lange es dauert, bis das Ereignis an die Sensor-HAL gemeldet werden muss.

probenahme_zeitraum_ns

Was der Parameter sampling_period_ns “ bedeutet, hängt vom Berichtsmodus des angegebenen Sensors ab:

• Kontinuierlich: sampling_period_ns ist die Abtastrate, also die Rate, mit der Ereignisse generiert werden.
• Bei Änderung: sampling_period_ns begrenzt die Abtastrate von Ereignissen, was bedeutet, dass Ereignisse nicht schneller als alle sampling_period_ns Nanosekunden generiert werden. Perioden können länger als sampling_period_ns sein, wenn kein Ereignis generiert wird und sich die Messwerte über längere Zeiträume nicht ändern. Weitere Einzelheiten finden Sie im Berichtsmodus bei Änderung .
• Einmalig: sampling_period_ns wird ignoriert. Es hat keine Wirkung.
• Speziell: Einzelheiten zur Verwendung von sampling_period_ns für spezielle Sensoren finden Sie unter Sensortypen .

Weitere Informationen zu den Auswirkungen von sampling_period_ns in den verschiedenen Modi finden Sie unter Berichtsmodi .

Für Dauer- und Wechselsensoren:

• Wenn sampling_period_ns kleiner als SensorInfo.minDelay ist, muss die HAL-Implementierung es stillschweigend auf max(SensorInfo.minDelay, 1ms) beschränken. Android unterstützt die Generierung von Ereignissen mit mehr als 1000 Hz nicht.
• Wenn sampling_period_ns größer als SensorInfo.maxDelay ist, muss die HAL-Implementierung den Wert stillschweigend auf SensorInfo.maxDelay kürzen.

Physikalische Sensoren haben manchmal Einschränkungen hinsichtlich der Geschwindigkeit, mit der sie laufen können, und der Genauigkeit ihrer Uhren. Um dies zu berücksichtigen, kann die tatsächliche Abtastfrequenz von der angeforderten Frequenz abweichen, sofern sie die Anforderungen in der folgenden Tabelle erfüllt.

max_report_latency_ns

max_report_latency_ns legt die maximale Zeit in Nanosekunden fest, um die Ereignisse verzögert und im Hardware-FIFO gespeichert werden können, bevor sie über die HAL gemeldet werden, während der AP aktiv ist.

Ein Wert von Null bedeutet, dass die Ereignisse gemeldet werden müssen, sobald sie gemessen werden, wobei entweder der FIFO ganz übersprungen wird oder der FIFO geleert wird, sobald ein Ereignis vom Sensor vorliegt.

Beispielsweise löst ein bei 50 Hz aktivierter Beschleunigungsmesser mit max_report_latency_ns=0 50 Mal pro Sekunde Interrupts aus, wenn der AP wach ist.

Wenn max_report_latency_ns>0 ist, müssen Sensorereignisse nicht gemeldet werden, sobald sie erkannt werden. Sie können vorübergehend im FIFO gespeichert und stapelweise gemeldet werden, solange kein Ereignis um mehr als max_report_latency_ns Nanosekunden verzögert wird. Dies bedeutet, dass alle Ereignisse seit der vorherigen Charge aufgezeichnet und auf einmal zurückgegeben werden. Dies reduziert die Anzahl der an den AP gesendeten Interrupts und ermöglicht es dem AP, in einen Modus mit geringerem Stromverbrauch (Leerlauf) zu wechseln, während der Sensor Daten erfasst und stapelt.

Jedem Ereignis ist ein Zeitstempel zugeordnet. Eine Verzögerung der Meldung eines Ereignisses hat keinen Einfluss auf den Zeitstempel des Ereignisses. Der Zeitstempel muss korrekt sein und dem Zeitpunkt entsprechen, zu dem das Ereignis physisch stattgefunden hat, nicht dem Zeitpunkt, zu dem es gemeldet wurde.

Das Zulassen, dass Sensorereignisse vorübergehend im FIFO gespeichert werden, ändert nichts am Verhalten der Übermittlung von Ereignissen an den HAL; Ereignisse von verschiedenen Sensoren können verschachtelt werden und alle Ereignisse von demselben Sensor werden zeitlich geordnet.

Aufwach- und Nicht-Wach-Ereignisse

Sensorereignisse von Wecksensoren müssen in einem oder mehreren Weck-FIFOs gespeichert werden. Ein gängiges Design besteht darin, einen einzigen, großen, gemeinsam genutzten Weck-FIFO zu haben, in dem Ereignisse von allen Wecksensoren verschachtelt werden. Alternativ können Sie einen Weck-FIFO pro Sensor oder dedizierte FIFOs für bestimmte Wecksensoren und einen gemeinsamen FIFO für die übrigen Wecksensoren verwenden.

Ebenso müssen Sensorereignisse von nicht aufweckbaren Sensoren in einem oder mehreren nicht aufweckbaren FIFOs gespeichert werden.

In allen Fällen können Aktivierungssensorereignisse und Nichtaktivierungssensorereignisse nicht im selben FIFO verschachtelt werden. Aufweckereignisse müssen in einem Aufweck-FIFO gespeichert werden, und Nicht-Aufweckereignisse müssen in einem Nicht-Aufweck-FIFO gespeichert werden.

Für den Weck-FIFO bietet das einzelne, große, gemeinsam genutzte FIFO-Design die besten Leistungsvorteile. Für den Nicht-Wake-up-FIFO haben der einzelne große gemeinsam genutzte FIFO und mehrere kleine reservierte FIFOs ähnliche Leistungseigenschaften. Weitere Vorschläge zur Konfiguration der einzelnen FIFOs finden Sie unter FIFO-Zuweisungspriorität .

Verhalten außerhalb des Suspend-Modus

Wenn der AP wach ist (nicht im Suspend-Modus), werden Ereignisse vorübergehend in FIFOs gespeichert, solange sie nicht um mehr als max_report_latency verzögert werden.

Solange der AP nicht in den Suspend-Modus wechselt, darf kein Ereignis verworfen werden oder verloren gehen. Wenn interne FIFOs voll werden, bevor max_report_latency abläuft, werden Ereignisse zu diesem Zeitpunkt gemeldet, um sicherzustellen, dass kein Ereignis verloren geht.

Wenn sich mehrere Sensoren denselben FIFO teilen und die max_report_latency eines von ihnen abläuft, werden alle Ereignisse aus dem FIFO gemeldet, auch wenn die max_report_latency der anderen Sensoren noch nicht abgelaufen ist. Dadurch wird die Häufigkeit verringert, mit der Ereignisstapel gemeldet werden. Wenn ein Ereignis gemeldet werden muss, werden alle Ereignisse von allen Sensoren gemeldet.

Wenn beispielsweise folgende Sensoren aktiviert sind:

• Beschleunigungsmesser gestapelt mit max_report_latency = 20s
• Gyroskop gestapelt mit max_report_latency = 5s

Die Beschleunigungsmesser-Batches werden gleichzeitig mit den Gyroskop-Batches gemeldet (alle 5 Sekunden), auch wenn der Beschleunigungsmesser und das Gyroskop nicht denselben FIFO verwenden.

Verhalten im Suspend-Modus

Die Stapelverarbeitung ist besonders nützlich, um Sensordaten im Hintergrund zu sammeln, ohne den AP wach zu halten. Da die Sensortreiber und die HAL-Implementierung keinen Wake-Lock* halten dürfen, kann der AP auch während der Erfassung von Sensordaten in den Suspend-Modus wechseln.

Das Verhalten von Sensoren während der AP angehalten ist, hängt davon ab, ob es sich bei dem Sensor um einen Wecksensor handelt. Weitere Einzelheiten finden Sie unter Wecksensoren .

Wenn ein Nicht-Weck-FIFO voll ist, muss er sich wie ein Ringpuffer verhalten und ältere Ereignisse überschreiben, wobei die neuen Ereignisse die alten ersetzen. max_report_latency hat im Suspend-Modus keine Auswirkungen auf Nicht-Wake-up-FIFOs.

Wenn ein Weck-FIFO voll ist oder die max_report_latency eines der Wecksensoren abläuft, muss die Hardware den AP aufwecken und die Daten melden.

In beiden Fällen (Wake-Up und Non-Wake-Up) wird, sobald der AP den Suspend-Modus verlässt, ein Batch mit dem Inhalt aller FIFOs erstellt, auch wenn max_report_latency einiger Sensoren noch nicht abgelaufen ist. Dies minimiert das Risiko, dass der AP kurz nach der Rückkehr in den Suspend-Modus wieder aufwachen muss, und minimiert somit den Stromverbrauch.

*Eine bemerkenswerte Ausnahme, bei der es Fahrern nicht gestattet ist, eine Wecksperre zu halten, ist, wenn ein Wecksensor mit dem kontinuierlichen Meldemodus mit max_report_latency < 1 Sekunde aktiviert wird. In diesem Fall kann der Treiber eine Wecksperre aufrechterhalten, da der AP keine Zeit hat, in den Suspend-Modus zu wechseln, da er durch ein Weckereignis geweckt würde, bevor er den Suspend-Modus erreicht.

Vorsichtsmaßnahmen beim Stapeln von Wecksensoren

Je nach Gerät kann es einige Millisekunden dauern, bis der AP den Suspend-Modus vollständig verlässt und mit dem Leeren des FIFO beginnt. Im FIFO muss genügend Spielraum zugewiesen werden, damit das Gerät den Suspend-Modus verlassen kann, ohne dass der Aktivierungs-FIFO überläuft. Es dürfen keine Ereignisse verloren gehen und die max_report_latency muss eingehalten werden.

Vorsichtsmaßnahmen beim Stapeln von Nicht-Wake-up-On-Change-Sensoren

On-Change-Sensoren erzeugen nur dann Ereignisse, wenn sich der von ihnen gemessene Wert ändert. Ändert sich der Messwert, während sich der AP im Suspend-Modus befindet, erwarten Anwendungen den Empfang eines Ereignisses, sobald der AP aufwacht. Aus diesem Grund muss die Stapelverarbeitung von Nicht-Wake-up -Sensorereignissen bei Änderung sorgfältig durchgeführt werden, wenn der Sensor seinen FIFO mit anderen Sensoren teilt. Das letzte von jedem On-Change-Sensor generierte Ereignis muss immer außerhalb des gemeinsam genutzten FIFO gespeichert werden, damit es niemals durch andere Ereignisse überschrieben werden kann. Wenn der AP aufwacht und alle Ereignisse vom FIFO gemeldet wurden, muss das letzte Sensorereignis bei Änderung gemeldet werden.

Hier ist eine Situation, die Sie vermeiden sollten:

1. Eine Anwendung registriert sich beim Nicht-Wake-up-Schrittzähler (bei Änderung) und beim Nicht-Wake-up-Beschleunigungsmesser (kontinuierlich), die beide denselben FIFO verwenden.
2. Die Anwendung empfängt ein Schrittzählerereignis step_count=1000 steps Code>.
3. Der AP wird suspendiert.
4. Der Benutzer geht 20 Schritte, wodurch Schrittzähler- und Beschleunigungsmesserereignisse verschachtelt werden, wobei das letzte Schrittzählerereignis step_count = 1020 steps ist.
5. Der Benutzer bewegt sich längere Zeit nicht, was dazu führt, dass sich Beschleunigungsmesserereignisse weiterhin im FIFO ansammeln und schließlich jedes step_count -Ereignis im gemeinsam genutzten FIFO überschreiben.
6. AP wacht auf und alle Ereignisse vom FIFO werden an die Anwendung gesendet.
7. Die Anwendung empfängt nur Beschleunigungsmesserereignisse und geht davon aus, dass der Benutzer nicht gelaufen ist.

Durch das Speichern des letzten Schrittzählerereignisses außerhalb des FIFO kann der HAL dieses Ereignis melden, wenn der AP aufwacht, selbst wenn alle anderen Schrittzählerereignisse durch Beschleunigungsmesserereignisse überschrieben wurden. Auf diese Weise erhält die Anwendung step_count = 1020 steps wenn der AP aufwacht.

Implementieren Sie die Stapelverarbeitung

Um Strom zu sparen, muss die Stapelverarbeitung ohne die Hilfe des AP erfolgen und der AP muss während der Stapelverarbeitung in den Ruhezustand versetzt werden können.

Wenn die Stapelverarbeitung in einem Sensor-Hub durchgeführt wird, sollte der Stromverbrauch des Sensor-Hubs minimiert werden.

Die maximale Meldelatenz kann jederzeit geändert werden, insbesondere während der angegebene Sensor bereits aktiviert ist; und dies sollte nicht zum Verlust von Ereignissen führen.

FIFO-Zuweisungspriorität

Auf Plattformen, bei denen die Hardware-FIFO- und/oder Sensor-Hub-Puffergröße begrenzt ist, müssen Systementwickler möglicherweise entscheiden, wie viel FIFO für jeden Sensor reserviert werden soll. Um Ihnen bei dieser Auswahl zu helfen, finden Sie hier eine Liste möglicher Anwendungen, wenn die Stapelverarbeitung auf den verschiedenen Sensoren implementiert ist.

Hoher Wert: Koppelnavigation für Fußgänger mit geringem Stromverbrauch

Angestrebte Dosierzeit: 1 bis 10 Minuten

Sensoren zur Charge:

• Weckschrittdetektor
• Weckspiel-Rotationsvektor bei 5 Hz
• Aufwachbarometer mit 5 Hz
• Unkalibriertes Magnetometer mit 5 Hz aufwecken

Die Stapelung dieser Daten ermöglicht die Durchführung einer Koppelnavigation für Fußgänger, während der AP in den Ruhezustand versetzt wird.

Hoher Wert: Intermittierende Aktivitäts-/Gestenerkennung mit mittlerer Leistung

Angestrebte Dosierzeit: 3 Sekunden

Zu stapelnde Sensoren: Nicht-Wake-up-Beschleunigungsmesser mit 50 Hz

Durch die Stapelung dieser Daten können in regelmäßigen Abständen willkürliche Aktivitäten und Gesten erkannt werden, ohne dass der AP während der Datenerfassung wach gehalten werden muss.

Mittlerer Wert: Kontinuierliche Aktivitäts-/Gestenerkennung mit mittlerer Leistung

Angestrebte Dosierzeit: 1 bis 3 Minuten

Zu stapelnde Sensoren: Wake-up-Beschleunigungsmesser mit 50 Hz

Durch die Stapelung dieser Daten können kontinuierlich willkürliche Aktivitäten und Gesten erkannt werden, ohne dass der AP während der Datenerfassung wach gehalten werden muss.

Mittelhoher Wert: Lastreduzierung unterbrechen

Angestrebte Dosierzeit: < 1 Sekunde

Zu stapelnde Sensoren: alle Hochfrequenzsensoren, normalerweise nicht aufweckbar.

Wenn das Gyroskop auf 240 Hz eingestellt ist, kann selbst die Stapelung von nur 10 Gyroskopereignissen die Anzahl der Interrupts von 240/Sekunde auf 24/Sekunde reduzieren.

Mittlerer Wert: Kontinuierliche niederfrequente Datenerfassung

Angestrebte Dosierzeit: 1 bis 10 Minuten

Sensoren zur Charge:

• Aufwachbarometer mit 1 Hz
• Weck-Feuchtigkeitssensor mit 1 Hz
• Andere Niederfrequenz-Wecksensoren mit ähnlichen Raten

Ermöglicht die Erstellung von Überwachungsanwendungen bei geringem Stromverbrauch.

Mittlerer bis niedriger Wert: Kontinuierliche Erfassung aller Sensoren

Angestrebte Dosierzeit: 1 bis 10 Minuten

Zu stapelnde Sensoren: Alle Wecksensoren mit hohen Frequenzen

Ermöglicht die vollständige Erfassung von Sensordaten, während der AP im Ruhemodus bleibt. Ziehen Sie dies nur in Betracht, wenn der FIFO-Speicherplatz kein Problem darstellt.