Chargenbildung

Was ist Batching?

Batching bezieht sich auf das Puffern von Sensorereignissen in einem Sensorhub und/oder Hardware-FIFO, bevor die Ereignisse durch die 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.

Batching kann erhebliche Energieeinsparungen ermöglichen, indem der Hauptanwendungsprozessor (AP), auf dem Android ausgeführt wird, nur 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 können: Es besteht ein größeres Potenzial für Energieeinsparungen, wenn mehr Ereignisse gestapelt werden können. Batching nutzt die Verwendung von Low-Power-Speicher, um die Anzahl der High-Power-AP-Wake-ups zu reduzieren.

Batching kann nur erfolgen, wenn ein Sensor einen Hardware-FIFO besitzt und/oder Ereignisse innerhalb eines Sensor-Hubs puffern kann. In jedem Fall muss der Sensor die maximale Anzahl von Ereignissen melden, die auf einmal durch SensorInfo.fifoMaxEventCount werden können.

Wenn für einen Sensor Platz in einem FIFO reserviert ist, muss der Sensor die Anzahl der reservierten Ereignisse über SensorInfo.fifoReservedEventCount . Wenn der FIFO dem Sensor zugeordnet ist, dann ist SensorInfo.fifoReservedEventCount die Größe des FIFO. Wenn der FIFO von mehreren Sensoren geteilt wird, kann dieser Wert Null sein. Ein häufiger Anwendungsfall besteht darin, einem Sensor zu erlauben, den gesamten FIFO zu verwenden, wenn er der einzige aktive Sensor ist. Wenn mehrere Sensoren aktiv sind, wird jedem Sensor Platz für mindestens SensorInfo.fifoReservedEventCount Ereignisse im FIFO garantiert. Wenn ein Sensor-Hub verwendet wird, 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-Aktivierungssensor. In diesem Fall dürfen Ereignisse den AP nicht aufwecken und müssen gespeichert werden, bis der AP aufwacht.

Wenn ein Sensor kein Batching unterstützt und der AP schläft, werden nur Aufweck-Sensorereignisse an den AP gemeldet und Nicht-Aufweck-Ereignisse dürfen nicht an den AP gemeldet werden.

Chargenparameter

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 Sensors HAL gemeldet werden muss.

sample_period_ns

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

  • Kontinuierlich: sampling_period_ns ist die Abtastrate, d. h. 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 Zeit nicht ändern. Weitere Einzelheiten finden Sie unter Berichtsmodus bei Änderung .
  • One-Shot: sampling_period_ns wird ignoriert. Es hat keine Wirkung.
  • Special: 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) klemmen. 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 es stillschweigend auf SensorInfo.maxDelay .

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

Wenn die angeforderte Frequenz ist

Dann muss die tatsächliche Frequenz sein

unter minimaler Frequenz (<1/maxDelay)

zwischen 90 % und 110 % der Mindestfrequenz

zwischen minimaler und maximaler Frequenz

zwischen 90 % und 220 % der angeforderten Frequenz

über Maximalfrequenz (>1/minVerzögerung)

zwischen 90 % und 110 % der maximalen Frequenz und unter 1100 Hz

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 wach ist.

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

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

Wenn max_report_latency_ns>0 , 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. Das bedeutet, dass alle Ereignisse seit dem vorherigen Batch aufgezeichnet und auf einmal zurückgesendet werden. Dies reduziert die Anzahl der an den AP gesendeten Interrupts und ermöglicht es dem AP, in einen Modus mit geringerem Stromverbrauch (Leerlauf) umzuschalten, während der Sensor Daten erfasst und bündelt.

Jedem Ereignis ist ein Zeitstempel zugeordnet. Das Verzögern des Zeitpunkts, zu dem ein Ereignis gemeldet wird, wirkt sich nicht auf den Ereigniszeitstempel aus. Der Zeitstempel muss genau sein und dem Zeitpunkt entsprechen, zu dem das Ereignis tatsächlich stattfand, nicht dem Zeitpunkt, zu dem es gemeldet wurde.

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

Weck- und Nicht-Weck-Ereignisse

Sensorereignisse von Aufwecksensoren müssen in einem oder mehreren Aufweck-FIFOs gespeichert werden. Ein übliches Design besteht darin, einen einzelnen, großen, gemeinsam genutzten Aufweck-FIFO zu haben, in dem Ereignisse von allen Aufwecksensoren verschachtelt sind. Alternativ können Sie einen Aufweck-FIFO pro Sensor oder dedizierte FIFOs für bestimmte Aufwecksensoren und einen gemeinsam genutzten FIFO für den Rest der Aufwecksensoren haben.

In ähnlicher Weise müssen Sensorereignisse von Nicht-Wecksensoren in einem oder mehreren Nicht-Weck-FIFOs gespeichert werden.

In allen Fällen können Wecksensorereignisse und Nicht-Wecksensorereignisse nicht in demselben FIFO verschachtelt werden. Weckereignisse müssen in einem Weck-FIFO gespeichert werden, und Nicht-Weckereignisse müssen in einem Nicht-Weck-FIFO gespeichert werden.

Für das Aufweck-FIFO bietet das einzelne, große, gemeinsam genutzte FIFO-Design die besten Leistungsvorteile. Für den Nicht-Weck-FIFO haben der einzelne, große gemeinsam genutzte FIFO und mehrere kleine reservierte FIFO-Designs ä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 , werden Ereignisse an diesem Punkt 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 reduziert, mit der Batches von Ereignissen gemeldet werden. Wenn ein Ereignis gemeldet werden muss, werden alle Ereignisse von allen Sensoren gemeldet.

Wenn zum Beispiel folgende Sensoren aktiviert sind:

  • Accelerometer 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), selbst wenn der Beschleunigungsmesser und das Gyroskop nicht denselben FIFO teilen.

Verhalten im Suspend-Modus

Batching ist besonders vorteilhaft, um Sensordaten im Hintergrund zu sammeln, ohne den AP wach zu halten. Da die Sensortreiber und die HAL-Implementierung keine Wake-Lock* halten dürfen, kann der AP in den Suspend-Modus wechseln, selbst während Sensordaten erfasst werden.

Das Verhalten von Sensoren, während der AP suspendiert ist, hängt davon ab, ob der Sensor ein Wecksensor ist. Weitere Einzelheiten finden Sie unter Wecksensoren .

Wenn sich ein Nicht-Weck-FIFO füllt, muss es umlaufen und sich wie ein Ringpuffer verhalten, wobei ältere Ereignisse überschrieben werden, wobei die neuen Ereignisse die alten ersetzen. max_report_latency hat keinen Einfluss auf Nicht-Weck-FIFOs im Suspend-Modus.

Wenn sich ein Wake-up-FIFO füllt oder wenn die max_report_latency eines der Wake-up-Sensoren 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 aus dem Suspend-Modus kommt, ein Batch mit dem Inhalt aller FIFOs erzeugt, auch wenn max_report_latency einiger Sensoren noch nicht abgelaufen ist. Dies minimiert das Risiko, dass der AP bald wieder aufwachen muss, nachdem er in den Suspend-Modus zurückgekehrt ist, und minimiert daher den Stromverbrauch.

*Eine bemerkenswerte Ausnahme von Fahrern, denen es nicht erlaubt 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 halten, weil der AP keine Zeit hat, in den Suspend-Modus zu wechseln, da er durch ein Weckereignis aufgeweckt würde, bevor er den Suspend-Modus erreicht.

Vorsichtsmaßnahmen beim Stapeln von Aktivierungssensoren

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. Dem FIFO muss genügend Spielraum zugewiesen werden, damit das Gerät aus dem Suspend-Modus herauskommen kann, ohne dass der Aufweck-FIFO überläuft. Es dürfen keine Ereignisse verloren gehen und die max_report_latency muss eingehalten werden.

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

On-Change-Sensoren generieren nur dann Ereignisse, wenn sich der von ihnen gemessene Wert ändert. Wenn sich der Messwert ändert, während sich der AP im Suspend-Modus befindet, erwarten Anwendungen, dass sie ein Ereignis erhalten, sobald der AP aufwacht. Aus diesem Grund muss das Stapeln von Nicht-Weck- On-Change-Sensorereignissen sorgfältig durchgeführt werden, wenn der Sensor seinen FIFO mit anderen Sensoren teilt. Das letzte von jedem Änderungssensor erzeugte Ereignis muss immer außerhalb des gemeinsam genutzten FIFO gespeichert werden, damit es niemals durch andere Ereignisse überschrieben werden kann. Wenn der AP aufwacht, nachdem alle Ereignisse aus dem FIFO gemeldet wurden, muss das letzte On-Change-Sensorereignis gemeldet werden.

Hier ist eine Situation, die Sie vermeiden sollten:

  1. Eine Anwendung registriert sich bei dem Nicht-Weck-Schrittzähler (bei Änderung) und dem Nicht-Weck-Beschleunigungsmesser (kontinuierlich), die beide denselben FIFO teilen.
  2. Die Anwendung empfängt ein Schrittzählerereignis step_count=1000 steps Code>.
  3. Der AP geht in den Suspend-Zustand.
  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 lange 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 aus dem FIFO werden an die Anwendung gesendet.
  7. Die Anwendung empfängt nur Beschleunigungsmesserereignisse und geht davon aus, dass der Benutzer nicht gegangen ist.

Indem das letzte Schrittzählerereignis außerhalb des FIFO gespeichert wird, kann die 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.

Batching implementieren

Um Energie zu sparen, muss das Batching ohne die Hilfe des AP implementiert werden, und dem AP muss erlaubt werden, während des Batchings zu unterbrechen.

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

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

FIFO-Zuweisungspriorität

Auf Plattformen, bei denen die Puffergröße des Hardware-FIFO und/oder des Sensorhubs begrenzt ist, müssen Systemdesigner möglicherweise auswählen, 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 Chargenbildung auf den verschiedenen Sensoren implementiert wird.

Hoher Wert: Fußgänger-Koppelnavigation mit geringer Leistung

Angestrebte Dosierzeit: 1 bis 10 Minuten

Sensoren zum Batch:

  • Wake-up-Schritt-Detektor
  • Weckspiel-Rotationsvektor bei 5 Hz
  • Weckbarometer bei 5 Hz
  • Unkalibriertes Magnetometer bei 5 Hz aufwecken

Das Stapeln dieser Daten ermöglicht die Durchführung einer Koppelnavigation für Fußgänger, während der AP in den Suspend-Zustand versetzt wird.

Hoher Wert: Intermittierende Aktivität/Gestenerkennung mit mittlerer Leistung

Angestrebte Dosierzeit: 3 Sekunden

Batch-Sensoren: Beschleunigungsmesser ohne Aktivierung bei 50 Hz

Das Stapeln dieser Daten ermöglicht das periodische Erkennen beliebiger Aktivitäten und Gesten, ohne dass der AP wach gehalten werden muss, während die Daten gesammelt werden.

Mittlerer Wert: Kontinuierliche Aktivität/Gestenerkennung mit mittlerer Leistung

Angestrebte Dosierzeit: 1 bis 3 Minuten

Sensoren zur Charge: Aktivierungs-Beschleunigungsmesser bei 50 Hz

Das Stapeln dieser Daten ermöglicht das kontinuierliche Erkennen beliebiger Aktivitäten und Gesten, ohne dass der AP wach gehalten werden muss, während die Daten gesammelt werden.

Mittelhoher Wert: Lastreduzierung unterbrechen

Angestrebte Dosierzeit: < 1 Sekunde

Sensoren zum Stapeln: jeder Hochfrequenzsensor, normalerweise nicht aufweckbar.

Wenn das Gyroskop auf 240 Hz eingestellt ist, kann selbst das Stapeln von nur 10 Gyro-Ereignissen die Anzahl der Interrupts von 240/Sekunde auf 24/Sekunde reduzieren.

Mittlerer Wert: Kontinuierliche niederfrequente Datenerfassung

Angestrebte Dosierzeit: 1 bis 10 Minuten

Sensoren zum Batch:

  • Weckbarometer bei 1 Hz
  • Feuchtigkeitssensor aufwecken bei 1 Hz
  • Andere niederfrequente Wecksensoren mit ähnlichen Raten

Ermöglicht das Erstellen von Überwachungsanwendungen bei geringem Stromverbrauch.

Mittel-niedriger Wert: Kontinuierliche Sammlung vollständiger Sensoren

Angestrebte Dosierzeit: 1 bis 10 Minuten

Sensoren zum Stapeln: Alle Aktivierungssensoren bei hohen Frequenzen

Ermöglicht die vollständige Erfassung von Sensordaten, während der AP im Suspend-Modus bleibt. Überlegen Sie nur, ob der FIFO-Platz kein Problem darstellt.