Invio in batch dei dati dei sensori per risparmiare energia

Questo argomento illustra le interfacce necessarie tra l'estensione della classe del sensore e il driver del sensore, per implementare l'invio in batch dei dati dei sensori in Windows 10.

Introduzione

Un driver del sensore che implementa l'invio in batch di dati consente al processore di applicazioni di risparmiare energia, poiché il processore riceve ed elabora i dati del sensore meno frequentemente. In questo caso, il driver del sensore memorizza nel buffer i campioni di dati del sensore nell'hardware del sensore e li trasferisce insieme in un batch all'estensione della classe del sensore. Per supportare l'invio in batch, è necessario fornire un driver del sensore universale UMDF 2.0, che implementa le interfacce necessarie.

Latenza batch

La latenza batch viene definita come la quantità massima di tempo per cui un sensore può memorizzare un campione di dati nel buffer dopo la raccolta, prima di distribuirlo all'estensione della classe del sensore. I dati del sensore vengono elaborati secondo una "pianificazione" in batch che si attiva quando gli eventi del sensore sono trasmessi dal driver, in base al valore di latenza del batch, come illustrato nei diagrammi seguenti.

Nel caso di un driver che non implementa l'invio in batch dei dati, il driver raccoglie e invia semplicemente i dati del sensore man mano che diventano disponibili. Ad esempio, per inviare esempi di dati N, il driver avvierà la raccolta e l'invio degli esempi di dati, N volte.

Nel caso di un driver che implementa l'invio in batch dei dati, la raccolta dei dati e la sequenza di recapito vengono eseguite in batch, come illustrato nel diagramma immediatamente precedente. Il valore della latenza batch viene specificato dall'estensione della classe del sensore. Pertanto, quando l'hardware del sensore deve raccogliere e trasferire campioni di dati N, ad esempio, il driver del sensore potrebbe suddividere il processo in due batch. La prima metà dei campioni di dati N viene inviata dopo un intervallo di tempo uguale al periodo di latenza batch. Quindi, dopo un altro intervallo di tempo di latenza batch, la seconda metà dei campioni di dati verrebbe inviata, effettuando un totale di due trasferimenti, rispetto ai trasferimenti N richiesti dal metodo di recapito normale.

Proprietà del sensore

Oltre alle proprietà comuni del sensore e alle proprietà di enumerazione necessarie, un driver che supporta l'invio in batch di dati deve anche segnalare le proprietà seguenti:

• PKEY_Sensor_FifoReservedSize_Samples
• PKEY_Sensor_FifoMaxSize_Samples
• PKEY_Sensor_WakeCapable

Per altre informazioni, vedere Proprietà comuni dei sensori e Proprietà di enumerazione.

Se il sottosistema hardware del sensore è in grado di svegliarsi, dovrebbe assicurarsi di avviare la riattivazione abbastanza presto per evitare overruns del buffer.

Funzioni DDSI facoltative per l'invio in batch di dati

Le funzioni DDSI (Device Driver Software Interface) sono l'interfaccia tra il driver e l'estensione della classe. Per supportare l'invio in batch dei dati, un driver deve implementare la funzione DDSI seguente, in modo che l'estensione della classe del sensore possa impostare la latenza batch.

• EvtSensorSetBatchLatency

  Si tratta di una funzione di callback che imposta la latenza batch per un sensore specificato. Il driver deve impostare Batch Latency su un valore minore o uguale al parametro BatchLatencyMs , a seconda della disponibilità del buffer.

Il driver deve anche implementare tutte le funzioni DDSI necessarie. Per altre informazioni, vedere _SENSOR_CONTROLLER_CONFIG struttura.

È facoltativo per l'estensione della classe del sensore specificare la latenza batch. La latenza batch predefinita per tutti i sensori è zero (0), che viene usata per indicare che i campioni non verranno inseriti in batch. Gli esempi di sensori verranno recapitati in batch, solo se l'estensione della classe chiama EvtSensorSetBatchLatency per impostare un valore di latenza batch. In caso contrario, i campioni verranno recapitati normalmente alla frequenza periodica dell'intervallo di dati.

L'estensione della classe del sensore può chiamare EvtSensorSetBatchLatency per modificare il valore di latenza batch in qualsiasi momento. In particolare, questa funzione può essere chiamata mentre il sensore specificato è già attivo e in esecuzione e questo non dovrebbe comportare la perdita di eventi. È previsto che il driver del sensore raccolga e inizi a distribuire immediatamente i campioni del batch più recente (con il massimo sforzo). Il driver non deve superare la latenza batch specificata dall'estensione della classe.

È importante notare che non vi sono modifiche implicite ai metodi e agli eventi di recapito dei dati dei sensori a causa dell'invio in batch dei dati. Quando la latenza batch scade, il driver chiama ripetutamente SensorsCxSensorDataReady per recapitare tutti gli esempi di dati memorizzati nel buffer uno alla volta. Gli esempi di dati sono accompagnati dai relativi timestamp (contenuti nei campi dati associati PKEY_SensorData_Timestamp) che indicano quando è stato eseguito ogni campionamento. Per altre informazioni sulle PKEY_SensorData_Timestamp, vedere Campi dati comuni.

Relazione tra latenza batch e frequenza dei dati

La latenza batch e frequenza dei dati sono correlate come segue:

Dove SensorBatching_MaxSize_Bytes è la dimensione massima del buffer per i dati del sensore in batch. Se il sensore è un accelerometro, è consigliabile un buffer hardware sufficientemente grande da contenere 250 o più campioni. La velocità dei dati è espressa in millisecondi ed è il tempo necessario per trasferire un campione di dati. Il numero di campioni che l'hardware del sensore deve archiviare in un batch è inversamente proporzionale alla velocità dei dati. Più è bassa la velocità di trasmissione dei dati, più grande deve essere il buffer di campionamento necessario per memorizzare i campioni elaborati in blocco per un determinato valore di latenza batch. Nella formula precedente la latenza batch è rappresentata da BatchLatencyMs e la frequenza dei dati è rappresentata da DataRateMs. Se la combinazione di BatchLatencyMs e DataRateMs comporta una dimensione del buffer maggiore di SensorBatching_MaxSize_Bytes, EvtSensorSetBatchLatency e EvtSensorSetDataInterval imposta la latenza batch sul valore mostrato dalla formula precedente.

Se il chiamante specifica un valore BatchLatencyMs minore di DataRateMs, i dati vengono recapitati senza buffering.

Invio in batch con soglie di dati

Un driver del sensore che implementa l'invio in batch di dati può usare EvtSensorSetDataThresholds per impostare una soglia di dati diversa da zero. In questo caso, quando la differenza nei valori dei dati tra le letture correnti e le ultime letture supera la soglia dei dati impostata usando EvtSensorSetDataThresholds, viene richiamata la raccolta dati, l'invio in batch e il processo di recapito. Pertanto, l'uso di batch di dati insieme alle soglie dei dati consente al driver del sensore di risparmiare ancora più energia.

Quando le soglie di dati non zero vengono impostate dall'estensione della classe del sensore, insieme al raggruppamento dei dati, il driver dovrebbe fornire campioni raggruppati con timestamp accurati e rispettare anche le soglie dei dati. Se l'hardware del sensore stesso non è in grado di mantenere timestamp accurati applicando le soglie di dati, può raccogliere campioni senza applicare soglie di dati. Tuttavia, in questo caso, il driver deve filtrare i campioni che non soddisfano le impostazioni di soglia dei dati correnti, prima di recapitarli all'estensione della classe del sensore.

Esempi di diagrammi di sequenza

Di seguito sono riportati diagrammi di sequenza che mostrano l'utilizzo delle funzioni DDSI facoltative di invio in batch dei dati menzionate in Funzioni DDSI facoltative per l'invio in batch dei dati. È possibile aggiungere altri diagrammi di sequenza in base alle esigenze, per chiarire gli scenari in base al feedback dei partner.

Scenario 1

In questo scenario, l'estensione della classe del sensore imposta la latenza batch e l'intervallo di dati, prima di avviare il sensore. Quando il sensore si avvia, i batch vengono consegnati periodicamente rispettando le proprietà impostate.

Scenario 2

In questo scenario, l'estensione della classe del sensore imposta la latenza batch, l'intervallo di dati e le soglie dei dati prima di avviare il sensore. All'avvio del sensore, i batch vengono recapitati periodicamente rispettando le proprietà impostate. Si noti che il driver non deve recapitare un batch a meno che non sia presente un campione che soddisfi i valori di soglia dei dati, che deve essere inviato all'interno della latenza batch specificata.

Scenario 3

In questo scenario, l'estensione della classe del sensore imposta la latenza batch e l'intervallo di dati prima di avviare il sensore. All'avvio del sensore, i batch vengono recapitati periodicamente, rispettando al tempo stesso le proprietà impostate. L'estensione della classe del sensore modifica la latenza batch e l'intervallo di dati mentre il sensore è in esecuzione e il driver inizia immediatamente a recapitare campioni in base ai nuovi valori senza perdere campioni di dati durante l'esecuzione.

Configurazioni hardware per l'invio in batch di dati

I dati del sensore devono essere inseriti in batch nell'hardware del sensore, senza il coinvolgimento del processore dell'applicazione. Ciò consentirà al processore di dormire mentre i dati vengono in batch per risparmiare energia. Il diagramma seguente illustra le possibili configurazioni per l'invio in batch di dati basati su hardware del sensore.

• Configurazione 1: il buffer FIFO viene implementato nel componente Sensor, che è connesso direttamente al processore dell'applicazione.

• Configurazione 2: il buffer FIFO viene implementato nel core hardware del sensore a basso consumo, a cui è connesso il componente del sensore. In questo caso, il buffer FIFO può essere condiviso tra più sensori o anche condiviso con componenti non del sensore, a seconda della progettazione del core del sensore. Il core del sensore a basso consumo è a sua volta connesso al processore dell'applicazione e può essere integrato nel SoC. In alternativa, potrebbe trattarsi di un componente esterno.

• Configurazione 3: il buffer FIFO viene implementato nel componente del sensore. Il componente del sensore è connesso a un core sensore a basso consumo, connesso al processore dell'applicazione. Il componente del sensore può essere integrato nel SoC o può essere un componente esterno.

• Configurazione 4: il buffer FIFO viene implementato nel componente del sensore e nel core del sensore a basso consumo. Il componente del sensore è connesso a un core sensore a basso consumo che a sua volta è connesso al processore dell'applicazione. Il componente del sensore può essere integrato nel SoC o può essere un componente esterno. Vale la pena notare che il core del sensore può essere usato per estendere un FIFO troppo superficiale.

La cosa chiave da notare è che il FIFO può essere implementato sia sull'hardware del core del sensore che sull'hardware del sensore, o su entrambi. Il driver astrae questo per il sistema operativo e presenta un'interfaccia uniforme tramite DDSI.

Il diagramma seguente illustra le diverse configurazioni descritte nell'elenco precedente.

Comportamento completo del buffer nell'hardware

In circostanze normali il driver dovrebbe leggere il buffer hardware almeno una volta ogni intervallo di tempo uguale a BatchLatencyMs, per assicurarsi che nessun dato venga eliminato o perso. Quando il buffer FIFO hardware si riempie, deve comportarsi come un buffer circolare, sovrascrivendo gli eventi meno recenti.