Procesamiento por lotes de datos del sensor para ahorrar energía
En este tema se tratan las interfaces necesarias entre la extensión de clase sensor y el controlador del sensor, para implementar el procesamiento por lotes de datos del sensor en Windows 10.
Introducción
Un controlador de sensor que implementa el procesamiento por lotes de datos permite al procesador de aplicaciones ahorrar energía, ya que el procesador recibe y procesa los datos del sensor con menos frecuencia. En este caso, el controlador del sensor almacena en búfer los ejemplos de datos del sensor en el hardware del sensor y, a continuación, los transfiere juntos en un lote a la extensión de clase sensor. Para admitir el procesamiento por lotes, debe proporcionar un controlador de sensor universal UMDF 2.0, que implementa las interfaces necesarias.
Latencia por lotes
La latencia de Batch se define como la cantidad máxima de tiempo para la que un sensor puede almacenar en búfer una muestra de datos después de recopilarla, antes de entregarla a la extensión de clase del sensor. La "programación" de procesamiento por lotes de datos del sensor se inicia cuando el controlador entrega los eventos del sensor, según el valor de latencia por lotes, tal como se muestra en los diagramas siguientes.
En el caso de un controlador que no implementa el procesamiento por lotes de datos, el controlador simplemente recopila y envía los datos del sensor a medida que está disponible. Por ejemplo, para enviar N ejemplos de datos, el controlador iniciaría la recopilación y el envío de los ejemplos de datos, N veces.
En el caso de un controlador que implementa el procesamiento por lotes de datos, la recopilación de datos y la secuencia de entrega se llevan a cabo en lotes, como se muestra en el diagrama inmediatamente anterior. La extensión de clase sensor especifica el valor de latencia por lotes. Por lo tanto, cuando el hardware del sensor tiene que recopilar y transferir muestras de datos N, por ejemplo, el controlador del sensor podría dividir el proceso en dos lotes. La primera mitad de las muestras de datos N se enviaría después de un intervalo de tiempo igual al período de latencia del lote. A continuación, después de otro intervalo de tiempo de latencia por lotes, se enviaría la segunda mitad de las muestras de datos, haciendo un total de dos transferencias, en comparación con las N transferencias requeridas por el método de entrega normal.
Propiedades del sensor
Además de las propiedades comunes del sensor y las propiedades de enumeración necesarias, un controlador que admita el procesamiento por lotes de datos también debe notificar las siguientes propiedades:
- PKEY_Sensor_FifoReservedSize_Samples
- PKEY_Sensor_FifoMaxSize_Samples
- PKEY_Sensor_WakeCapable
Para obtener más información, consulte Propiedades comunes del sensor y Propiedades de enumeración.
Si el subsistema de hardware del sensor es compatible con reactivación, debe asegurarse de que se inicia la reactivación lo suficientemente pronto como para evitar saturaciones de búfer.
Funciones DDSI opcionales para el procesamiento por lotes de datos
Las funciones de interfaz de software del controlador de dispositivo (DDSI) son la interfaz entre el controlador y la extensión de clase. Para admitir el procesamiento por lotes de datos, un controlador debe implementar la siguiente función DDSI, de modo que la extensión de clase del sensor pueda establecer la latencia del lote.
-
Se trata de una función de devolución de llamada que establece la latencia por lotes de un sensor especificado. El controlador debe establecer la latencia de Batch en un valor menor o igual que el parámetro BatchLatencyMs , en función de la disponibilidad del búfer.
El controlador también debe implementar todas las funciones DDSI necesarias. Para obtener más información, consulte estructura de _SENSOR_CONTROLLER_CONFIG.
Es opcional que la extensión de clase del sensor especifique la latencia por lotes. La latencia por lotes predeterminada para todos los sensores es cero (0), que se usa para indicar que las muestras no se procesarán por lotes. Los ejemplos de sensor se entregarán en lotes, solo si la extensión de clase llama a EvtSensorSetBatchLatency para establecer un valor de latencia por lotes. De lo contrario, las muestras se entregarán normalmente a la velocidad del intervalo de datos periódico.
La extensión de clase de sensor puede llamar a EvtSensorSetBatchLatency para cambiar el valor de latencia por lotes en cualquier momento. En concreto, se puede llamar a esta función mientras el sensor especificado ya está activo y en ejecución, y esto no debería dar lugar a la pérdida de eventos. Se espera que el controlador del sensor recopile y empiece a entregar muestras del lote más reciente inmediatamente (de forma más adecuada). El controlador no debe superar la latencia por lotes especificada por la extensión de clase.
Es importante tener en cuenta que no hay ningún cambio implícito en los métodos y eventos de entrega de datos del sensor debido al procesamiento por lotes de datos. Cuando expira la latencia por lotes, el controlador llama repetidamente a SensorsCxSensorDataReady para entregar todas las muestras de datos almacenadas en búfer de una en una. Las muestras de datos van acompañadas de sus marcas de tiempo (contenidas en sus campos de datos de PKEY_SensorData_Timestamp asociados) que indican cuándo se tomó cada muestra. Para obtener más información sobre PKEY_SensorData_Timestamp, consulte Campos de datos comunes.
Relación de latencia y velocidad de datos por lotes
La latencia por lotes y la velocidad de datos están relacionadas de la siguiente manera:
Donde SensorBatching_MaxSize_Bytes es el tamaño máximo del búfer para los datos del sensor por lotes. Si el sensor es un acelerómetro, se recomienda un búfer de hardware lo suficientemente grande como para contener 250 muestras o más. La velocidad de datos se expresa en milisegundos y es el tiempo que se tarda en transferir una muestra de datos. El número de muestras que el hardware del sensor debe almacenar en un lote es inversamente proporcional a la velocidad de datos. Cuanto menor sea la velocidad de datos, mayor será el búfer de ejemplo necesario para almacenar las muestras por lotes para un valor de latencia por lotes determinado. En la fórmula anterior, la latencia por lotes se representa mediante BatchLatencyMs y la velocidad de datos se representa mediante DataRateMs. Y si la combinación de BatchLatencyMs y DataRateMs dan como resultado un tamaño de búfer mayor que SensorBatching_MaxSize_Bytes, EvtSensorSetBatchLatency y EvtSensorSetDataInterval establecerán la latencia por lotes en el valor mostrado por la fórmula anterior.
Si el autor de la llamada especifica un valor BatchLatencyMs menor que DataRateMs, los datos se entregan sin almacenamiento en búfer.
Procesamiento por lotes con umbrales de datos
Un controlador de sensor que implementa el procesamiento por lotes de datos puede usar EvtSensorSetDataThresholds para establecer un umbral de datos distinto de cero. En este caso, cuando la diferencia en los valores de datos entre las lecturas actuales y las últimas lecturas, supera el umbral de datos que se estableció mediante EvtSensorSetDataThresholds, se invoca la recopilación de datos, el procesamiento por lotes y el proceso de entrega. Por lo tanto, el uso del procesamiento por lotes de datos junto con los umbrales de datos permite al controlador del sensor ahorrar aún más energía.
Cuando la extensión de clase de sensor establece umbrales de datos distintos de cero, junto con el procesamiento por lotes de datos, se espera que el controlador entregue muestras por lotes con marcas de tiempo precisas y que respete también los umbrales de datos. Si el propio hardware del sensor no es capaz de mantener marcas de tiempo precisas al aplicar umbrales de datos, puede recopilar muestras sin aplicar umbrales de datos. Sin embargo, en tal caso, el controlador debe filtrar muestras que no cumplen la configuración actual del umbral de datos, antes de entregarlas a la extensión de clase del sensor.
Ejemplos de diagramas de secuencia
Estos son diagramas de secuencia que muestran el uso de las funciones DDSI de procesamiento por lotes de datos opcionales que se mencionaron en funciones DDSI opcionales para el procesamiento por lotes de datos. Podemos agregar más diagramas de secuencia según sea necesario, para aclarar los escenarios en función de los comentarios de los asociados.
Escenario 1
En este escenario, la extensión de clase sensor establece la latencia por lotes y el intervalo de datos, antes de iniciar el sensor. Una vez que se inicia el sensor, entrega lotes periódicamente respetando las propiedades establecidas.
Escenario 2
En este escenario, la extensión de clase sensor establece la latencia por lotes, el intervalo de datos y los umbrales de datos, antes de iniciar el sensor. Una vez que se inicia el sensor, entrega lotes periódicamente respetando las propiedades establecidas. Tenga en cuenta que el controlador no debe entregar un lote a menos que haya un ejemplo que cumpla los valores de umbral de datos, que debe enviarse dentro de la latencia por lotes especificada.
Escenario 3
En este escenario, la extensión de clase sensor establece la latencia y el intervalo de datos por lotes antes de iniciar el sensor. Una vez que se inicia el sensor, entrega lotes periódicamente, respetando las propiedades establecidas. La extensión de clase sensor cambia la latencia y el intervalo de datos por lotes mientras se ejecuta el sensor, y el controlador comienza inmediatamente a entregar muestras de acuerdo con los nuevos valores sin perder ninguna muestra de datos mientras se ejecuta.
Configuraciones de hardware de procesamiento por lotes de datos
Los datos del sensor deben procesarse por lotes en el hardware del sensor, sin la participación del procesador de aplicaciones. Esto permitirá que el procesador entre en suspensión mientras los datos se están procesando por lotes para conservar la energía. En el diagrama siguiente se muestran las posibles configuraciones para el procesamiento por lotes de datos basados en hardware del sensor.
Configuración 1: el búfer FIFO se implementa en el componente Sensor, que está conectado directamente al procesador de aplicaciones.
Configuración 2: el búfer FIFO se implementa en el núcleo de hardware del sensor de baja potencia, al que está conectado el componente del sensor. En este caso, el búfer FIFO puede compartirse entre varios sensores o incluso compartirse con componentes que no son de sensor, en función del diseño del núcleo del sensor. A su vez, el núcleo del sensor de baja potencia está conectado al procesador de aplicaciones y se puede integrar en el SoC. O bien, puede ser un componente externo.
Configuración 3: el búfer FIFO se implementa en el componente del sensor. El componente del sensor está conectado a un núcleo de sensor de baja potencia, que está conectado al procesador de aplicaciones. El componente del sensor se puede integrar en el SoC o puede ser un componente externo.
Configuración 4: el búfer FIFO se implementa en el componente del sensor y el núcleo del sensor de baja potencia. El componente del sensor está conectado a un núcleo de sensor de baja potencia que, a su vez, está conectado al procesador de aplicaciones. El componente del sensor se puede integrar en el SoC o puede ser un componente externo. Cabe destacar que el núcleo del sensor se puede usar para extender un FIFO demasiado superficial.
La clave que hay que tener en cuenta es que el FIFO se puede implementar en el hardware del núcleo del sensor o en el hardware del sensor o en ambos. El controlador abstrae esto para el sistema operativo y presenta una interfaz uniforme a través de DDSI.
En el diagrama siguiente se muestran las distintas configuraciones descritas en la lista anterior.
Comportamiento completo del búfer en hardware
En circunstancias normales, el controlador debe leer el búfer de hardware al menos una vez cada intervalo de tiempo igual a BatchLatencyMs, para asegurarse de que no se quitan ni pierden datos. Cuando el búfer FIFO de hardware se llena, debe encapsularse y comportarse como un búfer circular, sobrescribiendo eventos anteriores.