Die in sensors.h deklarierte HAL-Schnittstelle ist die Schnittstelle zwischen dem Android-Framework und dem Hardware-spezifische Software zu implementieren. Eine HAL-Implementierung muss jede Funktion definieren Sensoren.h. Die Hauptfunktionen sind:
get_sensors_list
: gibt die Liste aller Sensoren zurück.activate
: Startet oder beendet einen Sensor.batch
: Legt die Parameter eines Sensors fest, z. B. die Abtastrate und den Höchstwert Berichtslatenz.setDelay
: Wird nur in HAL-Version 1.0 verwendet. Legt die Stichprobenhäufigkeit für eine Sensor verwendet.flush
: Löscht den FIFO des angegebenen Sensors und meldet, dass das Spülen abgeschlossen ist wenn dieser Vorgang abgeschlossen ist.poll
: Gibt die verfügbaren Sensorereignisse zurück.
Die Implementierung muss threadsicher sein und das Aufrufen dieser Funktionen zulassen aus verschiedenen Threads.
Über die -Schnittstelle werden auch mehrere Typen definiert, die von diesen Funktionen verwendet werden. Die wichtigsten Typen sind:
sensors_module_t
sensors_poll_device_t
sensor_t
sensors_event_t
Zusätzlich zu den Abschnitten unten finden Sie unter sensors.h weitere Informationen zu diesen Typen.
get_sensors_list(list)
int (*get_sensors_list)(struct sensors_module_t* module, struct sensor_t const** list);
Liefert die Liste der vom HAL implementierten Sensoren. Weitere Informationen zur Definition der Sensoren findest du unter sensor_t.
Die Sensoren erscheinen in der Liste werden Sensoren an die Apps gemeldet. Normalerweise sind die Basissensoren gefolgt von den Verbundsensoren.
Wenn mehrere Sensoren denselben Sensortyp und dieselbe Aufwacheigenschaft haben,
einer in der Liste wird als „Standardsensor“ bezeichnet. Es handelt sich um die von
getDefaultSensor(int sensorType, bool wakeUp)
Diese Funktion gibt die Anzahl der Sensoren in der Liste zurück.
aktivieren(sensor, true/false)
int (*activate)(struct sensors_poll_device_t *dev, int sensor_handle, int enabled);
Aktiviert oder deaktiviert einen Sensor.
sensor_handle
ist der Ziehpunkt des Sensors, der aktiviert oder deaktiviert werden soll. Der
Handle wird durch das Feld handle
seiner sensor_t-Struktur definiert.
enabled
ist zum Aktivieren auf „1“ und zum Deaktivieren auf „0“ gesetzt.
One-Shot-Sensoren werden beim Empfang eines Ereignisses automatisch deaktiviert.
und sie müssen der Deaktivierung durch einen Aufruf von activate(...,
enabled=0)
zustimmen.
Nicht-Aktivierungssensoren verhindern niemals, dass das SoC in den Ruhemodus wechselt. das hat der HAL keinen Teil-Wakelock im Namen von Anwendungen.
Wake-up-Sensoren können bei der kontinuierlichen Bereitstellung von Ereignissen verhindern, dass das SoC in den Sperrmodus versetzt werden, aber wenn kein Ereignis übermittelt werden muss, muss freigegeben werden.
Wenn enabled
1 ist und der Sensor bereits aktiviert ist, ist diese Funktion eine Nullfunktion.
und erfolgreich ist.
Wenn enabled
0 ist und der Sensor bereits deaktiviert ist, ist diese Funktion eine Nullfunktion.
und erfolgreich ist.
Diese Funktion gibt bei Erfolg 0 und ansonsten eine negative Fehlerzahl zurück.
Batch(Sensor, Flags, Stichprobenzeitraum, maximale Berichtslatenz)
int (*batch)( struct sensors_poll_device_1* dev, int sensor_handle, int flags, int64_t sampling_period_ns, int64_t max_report_latency_ns);
Legt die Parameter eines Sensors fest, einschließlich der Abtasthäufigkeit und Bericht zur maximalen Anzahl Latenzzeit. Diese Funktion kann aufgerufen werden, während der Sensor aktiviert ist: In diesem Fall darf dies nicht zu einem Verlust von Sensormessungen führen: Übergang von einer Stichprobenrate zur anderen Rate verloren gegangen sind. Ebenso wenig Übergang von einer hohen maximalen Berichtslatenz zu einem niedrigen maximalen Bericht Latenz.
sensor_handle
ist der Handle des zu konfigurierenden Sensors.
flags
wird derzeit nicht verwendet.
sampling_period_ns
ist der Zeitraum der Stichprobenerhebung, in dem der Sensor
in Nanosekunden. Siehe sampling_period_ns für
erhalten Sie weitere Informationen.
max_report_latency_ns
ist die maximale Zeit, innerhalb der Ereignisse
in Nanosekunden, bevor sie über den HAL gemeldet werden. Siehe max_report_latenz_ns
finden Sie weitere Informationen.
Diese Funktion gibt bei Erfolg 0 und ansonsten eine negative Fehlerzahl zurück.
setDelay(Sensor, Stichprobenzeitraum)
int (*setDelay)( struct sensors_poll_device_t *dev, int sensor_handle, int64_t sampling_period_ns);
Nach HAL Version 1.0 ist diese Funktion veraltet und wird nie aufgerufen.
Stattdessen wird die Funktion batch
aufgerufen, um den
sampling_period_ns
-Parameter.
In HAL-Version 1.0 wurde zum Festlegen von sampling_period_ns anstelle eines Batches setDelay verwendet.
Flush(Sensor)
int (*flush)(struct sensors_poll_device_1* dev, int sensor_handle);
Fügen Sie am Ende des Hardware-FIFO für den angegebenen Sensor ein Ereignis zum Leeren des Abschlusses hinzu und leert den FIFO. werden diese Ereignisse wie gewohnt bereitgestellt. abgelaufen ist) und aus dem FIFO entfernt.
Das Leeren erfolgt asynchron, d.h. diese Funktion muss sofort zurückgeben. Wenn die Implementierung einen einzelnen FIFO für mehrere Sensoren verwendet, ist dieser FIFO geleert und das Ereignis „Leeren abgeschlossen“ wird nur für den angegebenen Sensor hinzugefügt.
Wenn der angegebene Sensor keinen FIFO hat (keine Pufferung möglich) oder der FIFO,
zum Zeitpunkt des Aufrufs leer war, muss flush
trotzdem erfolgreich sein und
für diesen Sensor
ein Ereignis des abgeschlossenen Leerens Dies gilt für alle Sensoren
als One-Shot-Sensoren.
Wenn flush
aufgerufen wird, selbst wenn ein Leerung-Ereignis bereits im
FIFO für diesen Sensor muss ein zusätzlicher Sensor erstellt und am Ende des Sensors hinzugefügt werden.
und der FIFO muss geleert werden. Die Anzahl der flush
-Aufrufe müssen der Anzahl der erstellten Ereignisse für abgeschlossene Leerungen entsprechen.
flush
gilt nicht für One-Shot.
Sensoren wenn sensor_handle
sich auf einen One-Shot-Sensor bezieht,
flush
muss -EINVAL
zurückgeben und darf keine Werte generieren.
Leeren Sie das vollständige Metadatenereignis.
Diese Funktion gibt bei Erfolg 0 und -EINVAL
zurück, wenn der angegebene Sensor ein
One-Shot-Sensor oder nicht aktiviert, andernfalls eine negative Fehlerzahl.
Umfrage()
int (*poll)(struct sensors_poll_device_t *dev, sensors_event_t* data, int count);
Gibt ein Array von Sensordaten zurück, indem das Argument data
ausgefüllt wird. Diese Funktion
müssen blockiert werden, bis Ereignisse verfügbar sind. Es wird die Anzahl der gelesenen Ereignisse
bei Erfolg oder eine negative Fehlerzahl im Falle eines Fehlers.
Die Anzahl der in data
zurückgegebenen Ereignisse muss kleiner oder gleich sein
Das Argument count
. Diese Funktion sollte niemals 0 zurückgeben (kein Ereignis).
Reihenfolge der Aufrufe
Beim Starten des Geräts wird get_sensors_list
aufgerufen.
Wenn ein Sensor aktiviert wird, wird die Funktion batch
mit dem Parameter
Angeforderte Parameter, gefolgt von activate(..., enable=1)
.
Beachten Sie, dass in HAL-Version 1_0 das Gegenteil der Fall war: activate
wurde aufgerufen
gefolgt von set_delay
.
Wenn sich die angeforderten Eigenschaften eines Sensors ändern, während er
aktiviert ist, wird die Funktion batch
aufgerufen.
flush
kann jederzeit aufgerufen werden, auch bei nicht aktivierten Sensoren (in diesem Fall)
Es muss -EINVAL
zurückgegeben werden.
Wenn ein Sensor deaktiviert wird, wird activate(..., enable=0)
aufgerufen.
Parallel zu diesen Aufrufen wird die Funktion poll
wiederholt aufgerufen, um
Daten anzufordern. poll
kann auch dann aufgerufen werden, wenn keine Sensoren aktiviert sind.
Sensorenmodult
sensors_module_t
ist der Typ, der zum Erstellen der Android-Hardware verwendet wird
für die Sensoren. Die Implementierung des HAL muss ein Objekt definieren.
HAL_MODULE_INFO_SYM
dieses Typs, um die Funktion get_sensors_list verfügbar zu machen. Weitere Informationen finden Sie in der
Definition von sensors_module_t
in sensors.h und Definition von hw_module_t
.
sensor_poll_device_t / sensor_poll_device_1_t
sensors_poll_device_1_t
enthält die restlichen oben definierten Methoden:
activate
, batch
, flush
und
poll
Das Feld common
(vom Typ hw_device_t)
definiert die Versionsnummer des HAL.
Sensor_t
sensor_t
steht für ein Android-
. Hier sind einige wichtige Felder:
name:Ein für den Nutzer sichtbarer String, der den Sensor darstellt. Dieser String wird häufig verwendet den Teilnamen des zugrunde liegenden Sensors, den Sensortyp und ganz gleich, ob es sich um einen Wecksensor handelt. Beispiel: „LIS2HH12-Beschleunigungsmesser“, „MAX21000 Unkalibrated Gyroscope“, „BMP280 Wake-up Barometer“, „MPU6515 Game“ Rotationsvektor“
Handle:Die Ganzzahl, mit der bei der Registrierung auf den Sensor verwiesen wird, oder und Ereignisse daraus generieren.
type:Der Sensortyp. Erklärung zum Sensor ansehen
geben Sie Was sind Android-Sensoren? ein, und Sensortypen für offizielle Sensortypen. Für
nicht offizielle Sensortypen, type
muss mit SENSOR_TYPE_DEVICE_PRIVATE_BASE
beginnen
stringType:Der Sensortyp als String. Wenn der Parameter
Sensor hat einen offiziellen Typ, der auf SENSOR_STRING_TYPE_*
eingestellt ist. Wann?
hat der Sensor einen herstellerspezifischen Typ, stringType
muss
mit dem Reverse-Domainnamen
des Herstellers beginnen. Ein Sensor (z. B.
Einhorndetektor, die vom Cool-product-Team bei
Das fiktive Unternehmen könnte
stringType=”com.fictional_company.cool_product.unicorn_detector”
Die stringType
wird verwendet, um nicht offizielle Sensoren eindeutig zu identifizieren
Typen. Weitere Informationen zu Typen und Strings finden Sie unter sensors.h.
Typen.
requiredPermission:Ein String, der die Berechtigung darstellt.
die Anwendungen haben müssen, um den Sensor zu sehen, sich bei ihm zu registrieren und
ihre Daten. Ein leerer String bedeutet, dass für Anwendungen keine Berechtigung zum Ausführen dieser Aktion erforderlich ist.
auf diesen Sensor zugreifen können. Einige Sensortypen wie der Herzfrequenzmesser haben
obligatorische requiredPermission
. Alle Sensoren liefern sensible
Benutzerinformationen (z. B. die Herzfrequenz) durch eine
Berechtigung.
flags:Flags für diesen Sensor, mit denen der Berichtsmodus des Sensors definiert und angegeben wird, ob
ob der Sensor eine Weckzeit ist oder nicht. Ein Schuss-Wake-up-Sensor
hat flags = SENSOR_FLAG_ONE_SHOT_MODE | SENSOR_FLAG_WAKE_UP
. Die Bestandteile von
Das Flag, das in der aktuellen HAL-Version nicht verwendet wird, muss gleich 0 sein.
maxRange:Der Maximalwert, den der Sensor melden kann. Der Wert sollte in derselben Einheit wie der
den angegebenen Werten. Der Sensor muss Werte ohne Sättigung ausgeben können
innerhalb von [-maxRange; maxRange]
. Dies bedeutet, dass der Gesamtbereich der
im allgemeinen Sinn 2*maxRange
ist. Wenn der Sensor Werte über
gilt der Bereich für jede Achse. Beispiel: „+/- 2g“
Der Beschleunigungsmesser meldet maxRange = 2*9.81 = 2g
.
Resolution:Der kleinste Wertunterschied, der vom Sensor gemessen werden kann.
Wird in der Regel anhand von maxRange
und der Anzahl der Bits in der Messung berechnet.
power:Die Kosten für die Aktivierung des Sensors in MilliAmp.
Dies ist fast immer höher als der Stromverbrauch im Bericht
Datenblatt des zugrunde liegenden Sensors. Siehe Basissensoren != physisch
Sensoren, um weitere Informationen zu erhalten, und siehe Leistungsmessung
weitere Informationen dazu, wie Sie den Stromverbrauch eines Sensors messen können.
Wenn der Stromverbrauch des Sensors davon abhängt, ob sich das Gerät bewegt,
Der Stromverbrauch während der Bewegung ist der im power
erfasste Stromverbrauch
ein.
minDelay:Bei fortlaufenden Sensoren beträgt die Stichprobendauer in
Mikrosekunden. Dies entspricht der schnellsten Geschwindigkeit, die vom Sensor unterstützt wird. Siehe sampling_period_ns für
Details zur Verwendung dieses Werts. minDelay
ist
in Mikrosekunden ausgedrückt, während der Wert für sampling_period_ns
in
Nanosekunden. Für Sensoren im Modus „Bei Änderung“ und „Spezielle Berichtsmodus“, es sei denn,
anders angegeben, muss minDelay
0 sein. Bei One-Shot-Sensoren
muss -1 sein.
maxDelay:Bei fortlaufenden und On-Change-Sensoren kann die Stichprobenerhebung
Periode in Mikrosekunden, entsprechend der langsamsten Geschwindigkeit, die der Sensor
unterstützt. Siehe sampling_period_ns für
Details zur Verwendung dieses Werts. maxDelay
ist
in Mikrosekunden ausgedrückt, während der Wert für sampling_period_ns
in
Nanosekunden. Für spezielle und One-Shot-Sensoren muss maxDelay
0.
fifoReserviertEventCount:Die Anzahl der für diesen Sensor reservierten Ereignisse im
Hardware-FIFO. Wenn es einen dedizierten FIFO für diesen Sensor gibt,
fifoReservedEventCount
ist die Größe dieses dedizierten FIFO. Wenn der FIFO
mit anderen Sensoren geteilt wird, ist fifoReservedEventCount
die Größe des Teils
den für diesen Sensor reservierten FIFO. Auf den meisten gemeinsam genutzten FIFO-Systemen und auf
ohne Hardware-FIFO, ist dieser Wert 0.
fifoMaxEventCount:Die maximale Anzahl von Ereignissen, die
für diesen Sensor in den FIFOs gespeichert werden. Dieser Wert ist immer größer oder gleich
fifoReservedEventCount
Anhand dieses Werts wird geschätzt,
wird der FIFO schnell voll, wenn er sich bei einer bestimmten
vorausgesetzt, dass keine anderen Sensoren aktiviert sind. Bei Systemen ohne
Hardware-FIFO, fifoMaxEventCount
ist 0. Weitere Informationen finden Sie unter Batching.
Bei Sensoren mit einem offiziellen Sensortyp werden einige Felder überschrieben
durch das Framework definiert. Zum Beispiel Sensoren des Beschleunigungsmessers
haben einen kontinuierlichen Berichtsmodus erzwungen und die Herzfrequenzmessung
durch SENSOR_PERMISSION_BODY_SENSORS
geschützt werden muss,
Berechtigung.
sensor_event_t
Sensorereignisse, die von Android-Sensoren generiert und über die poll-Funktion gemeldet werden, haben den Wert type sensors_event_t
. Hier sind einige
wichtige Felder von sensors_event_t
:
version:Muss sizeof(struct sensors_event_t)
sein
sensor:Der Handle des Sensors, der das Ereignis generiert hat, wie durch
sensor_t.handle
type:Der Sensortyp des Sensors, der das Ereignis generiert hat, wie durch
sensor_t.type
timestamp:Der Zeitstempel des Ereignisses in Nanosekunden. Dies ist der Zeitpunkt,
Ereignis eingetreten ist (ein Schritt wurde unternommen oder eine Messung des Beschleunigungsmessers durchgeführt).
und nicht den Zeitpunkt, zu dem das Ereignis gemeldet wurde. timestamp
muss mit dem
elapsedRealtimeNano
-Uhr und bei fortlaufenden Sensoren den Jitter
muss klein sein. Die Zeitstempelfilterung ist manchmal erforderlich, um die CDD-Anforderungen zu erfüllen
wie die Verwendung der SoC-Unterbrechungszeit zum Festlegen der Zeitstempel
verursacht einen zu hohen Jitter und es wird nur die Zeit des Sensor-Chips verwendet, um den
können dazu führen, dass die Synchronisierung
elapsedRealtimeNano
Uhr, während die Sensoruhr in der Zeit verschoben wird.
Daten und sich überschneidende Felder: Die von der
Sensor. Die Bedeutung und die Einheiten dieser Felder sind für jeden Sensor unterschiedlich.
Typ. Unter sensors.h und in der Definition der verschiedenen Sensortypen finden Sie eine Beschreibung der
Datenfelder. Bei einigen Sensoren wird auch die Genauigkeit der Messwerte angegeben.
als Teil der Daten über das Feld status
. Dieses Feld enthält nur
für diese ausgewählten Sensortypen, die auf der SDK-Ebene als
Genauigkeitswert. Für diese Sensoren ist die Tatsache, dass das Statusfeld
in ihrem Sensortyp erwähnt wird.
Definition.
Ereignisse zu abgeschlossenem Leeren von Metadaten
Metadatenereignisse haben denselben Typ wie normale Sensorereignisse:
sensors_event_meta_data_t = sensors_event_t
Sie werden zusammen mit
andere Sensorereignisse
über die Umfrage. Sie enthalten die folgenden Felder:
version:Muss META_DATA_VERSION
sein
type:Muss SENSOR_TYPE_META_DATA
sein
Sensor, Reserviert und Zeitstempel: Muss 0 sein
meta_data.what:Enthält den Metadatentyp für dieses Ereignis. Es gibt derzeit eine
Einzelner gültiger Metadatentyp: META_DATA_FLUSH_COMPLETE
.
META_DATA_FLUSH_COMPLETE
-Ereignisse stellen den Abschluss einer Leerung eines
FIFO-Sensor. Wann: meta_data.what=META_DATA_FLUSH_COMPLETE
, meta_data.sensor
muss auf den Griff des gespülten Sensors eingestellt sein. Sie sind
wird generiert, wenn und nur wenn flush
auf einem Sensor aufgerufen wird. Weitere Informationen finden Sie im Abschnitt
der Funktion flush.