Batch di dati del sensore per risparmiare energia

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

Introduzione

Un driver del sensore che implementa il batch di dati consente al processore di applicazioni di risparmiare energia, poiché il processore riceve e elabora i dati del sensore meno frequentemente. Il driver del sensore in questo caso 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 il batch, è necessario fornire un driver sensore universale UMDF 2.0, che implementa le interfacce necessarie.

Latenza batch

La latenza Batch è definita come la quantità massima di tempo per cui un sensore può bufferare un campione di dati dopo la raccolta, prima di recapitarlo all'estensione della classe del sensore. I dati del sensore che eseguono il batch di "pianificazione" iniziano quando gli eventi del sensore vengono recapitati dal driver, in base al valore di latenza batch, come illustrato nei diagrammi seguenti.

Nel caso di un driver che non implementa il batch di dati, il driver raccoglie e invia i dati del sensore quando diventa disponibile. Ad esempio, per inviare esempi di dati N, il driver avvia la raccolta e l'invio degli esempi di dati, N volte.

Nel caso di un driver che implementa il batch di dati, la raccolta 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. Quindi, quando l'hardware del sensore deve raccogliere e trasferire esempi di dati N, ad esempio, il driver del sensore potrebbe suddividere il processo in due batch. La prima metà degli esempi di dati N verrà inviata dopo un intervallo di tempo uguale al periodo di latenza batch. Dopo un altro intervallo di tempo di latenza batch, la seconda metà degli esempi di dati verrà inviata, facendo un totale di due trasferimenti, rispetto ai trasferimenti N richiesti dal normale metodo di recapito.

Proprietà del sensore

Oltre alle proprietà comuni del sensore e alle proprietà di enumerazione necessarie, un driver che supporta il 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 riattivare, dovrebbe assicurarsi che venga avviato abbastanza presto per evitare l'overrun del buffer.

Funzioni DDSI facoltative per il batch di dati

Le funzioni DDSI (Device Driver Software Interface) sono l'interfaccia tra il driver e l'estensione della classe. Per supportare il batch di 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 la latenza batch 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 gli esempi non verranno batch. Gli esempi di sensore verranno recapitati in batch, solo se l'estensione della classe chiama EvtSensorSetBatchLatency per impostare un valore di latenza batch. In caso contrario, gli esempi verranno recapitati normalmente con la frequenza periodica dell'intervallo di dati.

L'estensione della classe del sensore può chiamare EvtSensorSetBatchLatency per modificare il valore della latenza batch in qualsiasi momento. In particolare, questa funzione può essere chiamata mentre il sensore specificato è già attivo ed in esecuzione e questo non dovrebbe causare la perdita di eventi. Il driver del sensore è previsto raccogliere e iniziare a distribuire campioni del batch più recente immediatamente (su base ottimale). Il driver non deve superare la latenza batch specificata dall'estensione della classe.

È importante notare che non esiste alcuna modifica implicita nei metodi e negli eventi di recapito dei dati dei sensori a causa del batch di dati. Quando scade la latenza batch, il driver chiama ripetutamente SensorCxSensorDataReady per distribuire tutti gli esempi di dati memorizzati nel buffer una alla volta. Gli esempi di dati sono accompagnati dai relativi timestamp (contenuti nei campi dati associati PKEY_SensorData_Timestamp) che indicano quando ogni campione è stato preso. Per altre informazioni sulle PKEY_SensorData_Timestamp, vedere Campi dati comuni.

Relazione di frequenza dei dati e la latenza batch

La latenza batch e frequenza dei dati sono correlate come indicato di seguito:

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 sufficiente per contenere 250 o più campioni. La velocità dei dati è espressa in millisecondi ed è il tempo necessario per trasferire un esempio di dati. Il numero di campioni che l'hardware del sensore deve archiviare in un batch è inversamente proporzionale alla frequenza dei dati. Frequenza dei dati più piccola, maggiore è il buffer di esempio necessario per archiviare gli esempi in batch per un determinato valore di latenza batch. Nella formula precedente la latenza batch è rappresentata da BatchLatencyMs e la frequenza dei dati è rappresentata da DataRateMs. E se la combinazione di BatchLatencyMs e DataRateMs genera 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.

Batch con soglie di dati

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

Quando le soglie dei dati non zero vengono impostate dall'estensione della classe del sensore, insieme al batch di dati, il driver dovrebbe recapitare campioni batch con timestamp accurati e per rispettare anche le soglie dei dati. Se l'hardware del sensore stesso non è in grado di mantenere timestamp accurati durante l'applicazione delle soglie di dati, può raccogliere campioni senza applicare soglie di dati. Tuttavia, in tal caso, il driver deve filtrare gli esempi che non soddisfano le impostazioni di soglia dei dati correnti, prima di recapitarli all'estensione della classe del sensore.

Esempi di diagramma sequenza

Ecco i diagrammi di sequenza che mostrano l'utilizzo delle funzioni DDSI facoltative in batch di dati menzionate nelle funzioni DDSI facoltative per il batch di 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 sensore imposta la latenza batch e l'intervallo di dati prima di avviare il sensore. Dopo l'avvio del sensore, viene recapitato periodicamente batch rispetto alle proprietà del set.

Scenario 2

In questo scenario, l'estensione della classe sensore imposta la latenza batch, l'intervallo di dati e le soglie dei dati, prima di avviare il sensore. Dopo l'avvio del sensore, viene recapitato periodicamente batch rispetto alle proprietà del set. Si noti che il driver non deve recapitare un batch a meno che non sia presente un esempio che soddisfa i valori di soglia dei dati, che devono essere inviati all'interno della latenza batch specificata.

Scenario 3

In questo scenario, l'estensione della classe sensore imposta la latenza batch e l'intervallo di dati prima di avviare il sensore. Dopo l'avvio del sensore, viene recapitato periodicamente batch, rispettando le proprietà del set. L'estensione della classe del sensore modifica la latenza e l'intervallo di dati batch mentre il sensore è in esecuzione e il driver inizia immediatamente a distribuire campioni in base ai nuovi valori senza perdere alcun campione di dati durante l'esecuzione.

Configurazioni hardware in batch di dati

I dati del sensore devono essere 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 il batch di dati basati su sensori.

• 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 bassa potenza, 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 sensore, a seconda della progettazione del core del sensore. Il core del sensore di potenza bassa è a sua volta connesso al processore dell'applicazione e può essere integrato nel SoC. In alternativa, può essere un componente esterno.

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

• Configurazione 4: il buffer FIFO viene implementato nel componente del sensore e nel core del sensore a bassa potenza. Il componente del sensore è connesso a un core sensore a bassa potenza che, a sua volta, è connesso al processore dell'applicazione. Il componente del sensore può essere integrato nel SoC oppure 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 fondamentale da notare è che il FIFO può essere implementato sull'hardware del core del sensore o 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 eseguire il wrapping e comportarsi come un buffer circolare, sovrascrivendo gli eventi meno recenti.