L'interfaccia HAL Sensors, dichiarata in sensors.h, rappresenta l'interfaccia tra il framework Android e il e software specifico per l'hardware. Un'implementazione HAL deve definire ogni funzione dichiarata in sensor.h. Le funzioni principali sono:
get_sensors_list
: restituisce l'elenco di tutti i sensori.activate
- Avvia o arresta un sensore.batch
- Imposta i parametri di un sensore, come la frequenza di campionamento e il valore massimo latenza dei report.setDelay
: utilizzata solo nella versione 1.0 dell'HAL. Imposta la frequenza di campionamento per un un dato sensore.flush
- Esegue il flush del FIFO del sensore specificato e segnala uno svuotamento completato al termine dell'operazione.poll
: restituisce gli eventi dei sensori disponibili.
L'implementazione deve essere sicura tramite thread e consentire di chiamare queste funzioni da diversi thread.
L'interfaccia definisce anche diversi tipi utilizzati da queste funzioni. Il principale sono:
sensors_module_t
sensors_poll_device_t
sensor_t
sensors_event_t
Oltre alle sezioni seguenti, consulta la pagina sensors.h per ulteriori informazioni su questi tipi di dispositivi.
get_sensors_list(elenco)
int (*get_sensors_list)(struct sensors_module_t* module, struct sensor_t const** list);
Fornisce l'elenco dei sensori implementati dall'HAL. Per informazioni dettagliate su come vengono definiti i sensori, consulta la sezione sensor_t.
L'ordine in cui appaiono i sensori nell'elenco è l'ordine in cui i sensori i sensori verranno segnalati alle applicazioni. Di solito, i sensori di base appaiono seguiti dai sensori compositi.
Se più sensori condividono lo stesso tipo di sensore e proprietà di riattivazione, la prima
quello dell'elenco è chiamato sensore "predefinito". È quello restituito da
getDefaultSensor(int sensorType, bool wakeUp)
.
Questa funzione restituisce il numero di sensori nell'elenco.
attiva(sensore, vero/falso)
int (*activate)(struct sensors_poll_device_t *dev, int sensor_handle, int enabled);
Attiva o disattiva un sensore.
sensor_handle
è il manico del sensore per l'attivazione/disattivazione. Un sensore
l'handle viene definito dal campo handle
della struttura sensor_t.
Il valore enabled
è impostato su 1 per attivare o su 0 per disattivare il sensore.
I sensori one-shot si disattivano automaticamente alla ricezione di un evento.
e devono comunque accettare di essere disattivati tramite una chiamata al numero activate(...,
enabled=0)
.
I sensori non di attivazione non impediscono mai al SoC di entrare in modalità di sospensione. che l'HAL non deve mantenere un wakelock parziale per conto delle applicazioni.
I sensori di riattivazione, durante l'invio continuo di eventi, possono impedire al SoC di entra in modalità di sospensione, ma se non è necessario pubblicare alcun evento, viene eseguita la il wakelock deve essere rilasciato.
Se enabled
è 1 e il sensore è già attivato, questa funzione è autonoma
e ha successo.
Se il valore di enabled
è 0 e il sensore è già disattivato, questa funzione è autonoma
e ha successo.
Questa funzione restituisce 0 in caso di esito positivo, mentre in caso contrario restituisce un numero di errore negativo.
batch(sensore, flag, periodo di campionamento, latenza massima del report)
int (*batch)( struct sensors_poll_device_1* dev, int sensor_handle, int flags, int64_t sampling_period_ns, int64_t max_report_latency_ns);
Consente di impostare i parametri di un sensore, tra cui la frequenza di campionamento e report massimo una latenza di pochi millisecondi. Questa funzione può essere chiamata mentre il sensore è attivato, in in questo caso non devono andare perse le misurazioni del sensore: il passaggio da una frequenza di campionamento all'altra non possono causare la perdita di eventi, passaggio da una latenza massima del report elevata a una latenza massima bassa una latenza di pochi millisecondi.
sensor_handle
è il punto di manipolazione del sensore da configurare.
flags
al momento non è utilizzato.
sampling_period_ns
è il periodo di campionamento in cui il sensore
dovrebbe essere eseguito in nanosecondi. Vedi sampling_period_ns per
ulteriori dettagli.
max_report_latency_ns
è il tempo massimo entro il quale possono essere eseguiti
ritardato prima di essere riportato tramite l'HAL, in nanosecondi. Consulta la sezione max_report_latency_ns
per ulteriori dettagli.
Questa funzione restituisce 0 in caso di esito positivo, mentre in caso contrario restituisce un numero di errore negativo.
setDelay(sensore, periodo di campionamento)
int (*setDelay)( struct sensors_poll_device_t *dev, int sensor_handle, int64_t sampling_period_ns);
Dopo la versione 1.0 dell'HAL, questa funzione è deprecata e non viene mai chiamata.
Viene invece chiamata la funzione batch
per impostare
sampling_period_ns
.
Nella versione 1.0 dell'HAL, è stato utilizzato setDelay anziché batch per impostare sampling_period_ns.
flush(sensore)
int (*flush)(struct sensors_poll_device_1* dev, int sensor_handle);
Aggiungi un evento di svuotamento completo alla fine del file FIFO hardware per il sensore specificato ed effettua il flush del segnale FIFO. questi eventi vengono pubblicati normalmente (ovvero come se la latenza massima nei report erano scaduti) e rimossi dal FIFO.
Lo svuotamento avviene in modo asincrono (ad esempio, questa funzione deve essere restituita immediatamente). Se l'implementazione utilizza un singolo FIFO per diversi sensori, quel FIFO viene e l'evento svuotamento completo viene aggiunto solo per il sensore specificato.
Se il sensore specificato non ha il segnale FIFO (non è possibile il buffering) oppure se il sensore FIFO,
era vuoto al momento della chiamata, flush
deve comunque riuscire e
inviare un evento di svuotamento completo del sensore. Questo vale per tutti i sensori,
rispetto ai sensori one-shot.
Quando viene chiamato flush
, anche se un evento di flush è già nella
FIFO per quel sensore, è necessario crearne un altro e aggiungerlo alla fine
del FIFO e quest'ultimo deve essere immerso. Il numero di flush
devono essere uguali al numero di eventi di svuotamento completi creati.
flush
non si applica a one-shot
sensori; se sensor_handle
si riferisce a un sensore one-shot,
flush
deve restituire -EINVAL
e non generarne nessuna
svuota l'evento di metadati completo.
Questa funzione restituisce 0 in caso di esito positivo, -EINVAL
se il sensore specificato è un
sensore one-shot o non abilitato, e un numero di errore negativo negli altri casi.
sondaggio()
int (*poll)(struct sensors_poll_device_t *dev, sensors_event_t* data, int count);
Restituisce un array di dati del sensore riempiendo l'argomento data
. Questa funzione
devono essere bloccati finché gli eventi
non sono disponibili. Verrà restituito il numero di eventi letti
in caso di esito positivo o un numero di errore negativo in caso di errore.
Il numero di eventi restituiti in data
deve essere inferiore o uguale a
dall'argomento count
. Questa funzione non restituirà mai 0 (nessun evento).
Sequenza di chiamate
All'avvio del dispositivo, viene chiamato get_sensors_list
.
Quando un sensore viene attivato, la funzione batch
viene chiamata con il
parametri richiesti, seguiti da activate(..., enable=1)
.
Tieni presente che nella versione 1_0 dell'HAL l'ordine era opposto: il nome activate
era
seguito da set_delay
.
Quando le caratteristiche richieste di un sensore cambiano mentre è
viene attivata la funzione batch
.
flush
può essere chiamato in qualsiasi momento, anche se i sensori non sono attivati (in questo caso
deve restituire -EINVAL
)
Quando un sensore viene disattivato, viene chiamato activate(..., enable=0)
.
Parallelamente a queste chiamate, la funzione poll
verrà chiamata ripetutamente a
richiedere dati. poll
può essere chiamato anche se non sono attivi sensori.
modulo_sensori_t
sensors_module_t
è il tipo utilizzato per creare l'hardware Android
per i sensori. L'implementazione dell'HAL deve definire un oggetto
HAL_MODULE_INFO_SYM
di questo tipo per esporre la funzione get_sensors_list. Consulta le
definizione di sensors_module_t
in sensors.h e la definizione di hw_module_t
per ulteriori informazioni.
sensor_poll_device_t / sensori_poll_device_1_t
sensors_poll_device_1_t
contiene i restanti metodi definiti sopra:
activate
, batch
, flush
e
poll
. Il relativo campo common
(di tipo hw_device_t)
definisce il numero di versione dell'HAL.
sensore_t
sensor_t
rappresenta un'istanza Android
il sensore. Ecco alcuni dei suoi campi importanti:
name: una stringa visibile dall'utente che rappresenta il sensore. Questa stringa spesso contiene il nome parziale del sensore sottostante, il tipo di sensore e o un sensore di sveglia. Ad esempio, "Accelerometro LIS2HH12", "MAX21000 Giroscopio non calibrato", "BMP280 Wake-up Barometer", "Gioco MPU6515 Rotazione Vector" (Vettore di rotazione)
handle: il numero intero utilizzato per fare riferimento al sensore durante la registrazione o generando eventi.
type: il tipo di sensore. Leggi la spiegazione relativa al sensore
digita Che cosa sono i sensori Android? per ulteriori dettagli e vedi Tipi di sensori per i tipi di sensori ufficiali. Per
tipi di sensori non ufficiali, type
deve iniziare con SENSOR_TYPE_DEVICE_PRIVATE_BASE
stringType:il tipo di sensore come stringa. Quando
di un sensore è di tipo ufficiale, impostato su SENSOR_STRING_TYPE_*
. Quando
il sensore è di un tipo specifico del produttore, stringType
deve
iniziano con il nome di dominio inverso
del produttore. Ad esempio, un sensore (come
rilevatore unicorno) definita dal team di Cool-product di
L'azienda di fantasia potrebbe usare
stringType=”com.fictional_company.cool_product.unicorn_detector”
.
stringType
viene utilizzato per identificare in modo univoco i sensori non ufficiali
di testo. Vedi sensors.h per ulteriori informazioni su tipi e stringhe.
di testo.
requiredPermission:una stringa che rappresenta l'autorizzazione.
che le applicazioni devono possedere per vedere il sensore, registrarsi e ricevere
e i relativi dati. Una stringa vuota indica che le applicazioni non richiedono alcuna autorizzazione per
accedere a questo sensore. Alcuni tipi di sensori, come il rilevatore del battito cardiaco, hanno un
requiredPermission
obbligatorio. Tutti i sensori che forniscono dati sensibili
informazioni utente (come il battito cardiaco) devono essere protette da un
autorizzazione.
flags: segnalazioni per il sensore, che definiscono la modalità di segnalazione del sensore e se
se il sensore è un sensore di sveglia o meno. Ad esempio, un sensore di sveglia one-shot
avrà flags = SENSOR_FLAG_ONE_SHOT_MODE | SENSOR_FLAG_WAKE_UP
. I frammenti
il flag non utilizzato nella versione attuale dell'HAL deve essere lasciato uguale a 0.
maxRange: il valore massimo che il sensore può segnalare, nella stessa unità del
i valori segnalati. Il sensore deve essere in grado di registrare i valori senza saturazione
in [-maxRange; maxRange]
. Nota che ciò significa che l'intervallo totale
in senso generico è 2*maxRange
. Quando il sensore segnala valori superiori a
più assi, l'intervallo si applica a ciascuno di essi. Ad esempio, "+/- 2g"
dell'accelerometro segnalerà maxRange = 2*9.81 = 2g
.
risoluzione:la differenza minima di valore che il sensore è in grado di misurare.
Solitamente viene calcolato in base a maxRange
e al numero di bit nella misurazione.
power (alimentazione): il costo dell'alimentazione per l'attivazione del sensore, espresso in milliA.
Questo è quasi sempre superiore al consumo energetico riportato nella
scheda tecnica del sensore sottostante. Vedi Sensori di base != fisici
Sensori per ulteriori dettagli e consulta la sezione Misurazione dell'alimentazione
per informazioni dettagliate su come misurare il consumo energetico di un sensore.
Se il consumo energetico del sensore dipende dal fatto che il dispositivo sia in movimento, il
il consumo energetico durante gli spostamenti è quello riportato nell'power
.
minDelay: per i sensori continui, il periodo di campionamento, in
microsecondi, corrispondenti alla velocità più veloce supportata dal sensore. Vedi sampling_period_ns per
i dettagli su come viene utilizzato questo valore. Tieni presente che minDelay
è
espresso in microsecondi mentre sampling_period_ns
è in
nanosecondi. Per i sensori in caso di modifica e in modalità di reporting speciale, a meno che
altrimenti specificato, minDelay
deve essere 0. Per i sensori one-shot,
deve essere -1.
maxDelay: per i sensori continui e in continuo cambiamento, il campionamento
periodo, in microsecondi, corrispondente alla velocità più lenta del sensore
Google Cloud. Vedi sampling_period_ns per
i dettagli su come viene utilizzato questo valore. Tieni presente che maxDelay
è
espresso in microsecondi mentre sampling_period_ns
è in
nanosecondi. Per i sensori speciali e one-shot, maxDelay
deve essere
0.
fifoConfidentialEventCount:il numero di eventi riservati a questo sensore nella zona
hardware FIFO. Se è presente un FIFO dedicato per questo sensore,
fifoReservedEventCount
è la dimensione di questo FIFO dedicato. Se il FIFO è
condiviso con altri sensori, fifoReservedEventCount
è la dimensione della parte
il FIFO riservato al sensore. Sulla maggior parte dei sistemi FIFO condivisi e
per i sistemi privi di FIFO hardware questo valore è 0.
fifoMaxEventCount: il numero massimo di eventi che possono
verrà memorizzato nei FIFO di questo sensore. Questo valore è sempre maggiore o uguale a
fifoReservedEventCount
. Questo valore viene utilizzato per stimare il modo
rapidamente il FIFO si riempie quando si registra sul sensore a una
, sempre che non ci siano altri sensori attivati. Sui sistemi che non hanno
FIFO hardware, fifoMaxEventCount
è 0. Per ulteriori dettagli, consulta Raggruppamento in batch.
Per i sensori con un tipo di sensore ufficiale, alcuni campi vengono sovrascritti
dal framework. Ad esempio, sensori dell'accelerometro
sono obbligati ad avere una modalità di segnalazione continua, mentre i monitor del battito cardiaco
essere costrette a essere protetti dalle SENSOR_PERMISSION_BODY_SENSORS
autorizzazione.
evento_t_sensori
Gli eventi generati dai sensori Android e segnalati tramite la funzione poll sono pari a type sensors_event_t
. Ecco alcuni esempi
campi importanti di sensors_event_t
:
version: deve essere sizeof(struct sensors_event_t)
sensor: l'handle del sensore che ha generato l'evento, come definito dalla
sensor_t.handle
.
type: il tipo di sensore del sensore che ha generato l'evento, come definito dalla
sensor_t.type
.
timestamp: il timestamp dell'evento espresso in nanosecondi. Questa è l'ora
che si è verificato (è stato effettuato un passo o è stata effettuata una misurazione con l'accelerometro),
non l'ora in cui l'evento è stato segnalato. timestamp
deve essere sincronizzato con
orologio elapsedRealtimeNano
; nel caso di sensori continui, il tremolio
deve essere piccolo. A volte il filtro timestamp è necessario per soddisfare il CDD
come l'uso esclusivo del tempo di interruzione del SoC per impostare i timestamp
causa un jitter troppo elevato e l'uso del solo chip del sensore per impostare la
i timestamp possono causare la desincronizzazione
Orologio elapsedRealtimeNano
, mentre l'orologio del sensore cambia.
dati e campi sovrapposti: i valori misurati
sensore. Il significato e le unità di questi campi sono specifici di ciascun sensore
di testo. Consulta la pagina sensors.h e la definizione dei diversi tipi di sensori per una descrizione dei
campi di dati. Per alcuni sensori viene segnalata anche la precisione delle letture
come parte dei dati, tramite un campo status
. Questo campo è limitato
vengono trasmessi per i tipi di sensori selezionati, visualizzati a livello dell'SDK come
il valore della precisione. Per questi sensori, il fatto che il campo dello stato sia impostato
è menzionato nel suo tipo di sensore
definizione di Kubernetes.
Eventi completati per lo svuotamento dei metadati
Gli eventi dei metadati sono dello stesso tipo dei normali eventi dei sensori:
sensors_event_meta_data_t = sensors_event_t
. Vengono restituiti insieme
altri eventi del sensore
tramite sondaggio. Esse possiedono i seguenti campi:
version: deve essere META_DATA_VERSION
type: deve essere SENSOR_TYPE_META_DATA
sensor, Reserve, and timestamp: deve essere 0
meta_data.what: contiene il tipo di metadati per questo evento. Al momento è presente un
singolo tipo di metadati valido: META_DATA_FLUSH_COMPLETE
.
Gli eventi META_DATA_FLUSH_COMPLETE
rappresentano il completamento del flush di un
sensore FIFO. Quando meta_data.what=META_DATA_FLUSH_COMPLETE
, meta_data.sensor
deve essere impostato sull'impugnatura del sensore che è stato lavato in lavatrice. Sono
generate quando e solo quando flush
viene chiamato su un sensore. Consulta la sezione sulle
la funzione flush per ulteriori informazioni.