Google is committed to advancing racial equity for Black communities. See how.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Procesamiento por lotes

¿Qué es el procesamiento por lotes?

El procesamiento por lotes se refiere a los eventos del sensor de almacenamiento en búfer en un concentrador de sensores y / o FIFO de hardware antes de informar los eventos a través de HAL de sensores . La ubicación donde se almacenan los eventos del sensor (hub del sensor y / o FIFO de hardware) se denominan "FIFO" en esta página. Cuando el procesamiento por lotes de eventos del sensor no está activo, los eventos del sensor se informan inmediatamente al HAL de los sensores cuando están disponibles.

El procesamiento por lotes puede permitir importantes ahorros de energía al activar solo el procesador de aplicaciones principal (AP), que ejecuta Android, cuando muchos eventos de sensores están listos para ser procesados, en lugar de activarlo para cada evento individual. El ahorro potencial de energía está directamente relacionado con el número de eventos que el concentrador del sensor y / o FIFO pueden almacenar: existe un mayor potencial de ahorro de energía si se pueden agrupar más eventos. El procesamiento por lotes aprovecha el uso de memoria de baja potencia para reducir la cantidad de activaciones de AP de alta potencia.

El procesamiento por lotes solo puede ocurrir cuando un sensor posee un FIFO de hardware y / o puede almacenar eventos dentro de un concentrador de sensores. En cualquier caso, el sensor debe informar el número máximo de eventos que se pueden agrupar a la vez a través de SensorInfo.fifoMaxEventCount .

Si un sensor tiene espacio reservado dentro de un FIFO, el sensor debe informar el número de eventos reservados a través de SensorInfo.fifoReservedEventCount . Si el FIFO está dedicado al sensor, SensorInfo.fifoReservedEventCount es el tamaño del FIFO. Si el FIFO se comparte entre varios sensores, este valor puede ser cero. Un caso de uso común es permitir que un sensor use todo el FIFO si es el único sensor activo. Si hay varios sensores activos, cada sensor tiene espacio garantizado para al menos los eventos SensorInfo.fifoReservedEventCount en el FIFO. Si se utiliza un concentrador de sensor, la garantía puede hacerse cumplir a través del software.

Los eventos del sensor se agrupan en las siguientes situaciones:

  • La latencia máxima actual del informe del sensor es mayor que cero, lo que significa que los eventos del sensor pueden retrasarse hasta la latencia máxima del informe antes de informarse a través del HAL.
  • El AP está en modo de suspensión y el sensor es un sensor sin activación. En este caso, los eventos no deben activar el AP y deben almacenarse hasta que el AP se active.

Si un sensor no admite el procesamiento por lotes y el AP está dormido, solo los eventos del sensor de activación se informan al AP y los eventos que no son de activación no se deben informar al AP.

Parámetros de procesamiento por lotes

Los dos parámetros que rigen el comportamiento de procesamiento por lotes son sampling_period_ns y max_report_latency_ns . sampling_period_ns determina con qué frecuencia se genera un nuevo evento de sensor, y max_report_latency_ns determina cuánto tiempo hasta que el evento se debe informar a los Sensores HAL.

samples_period_ns

Lo que los sampling_period_ns parámetros medios depende del modo de presentación de informes del sensor especificado:

  • Continuo: sampling_period_ns es la frecuencia de muestreo, es decir, la frecuencia a la que se generan los eventos.
  • Al cambiar: sampling_period_ns limita la frecuencia de muestreo de eventos, lo que significa que los eventos se generan no más rápido que cada sampling_period_ns nanosegundos. Los períodos pueden ser más largos que sampling_period_ns si no se genera ningún evento y los valores medidos no cambian durante largos períodos. Para obtener más detalles, consulte el modo de informe al cambiar .
  • One-shot: sampling_period_ns se ignora. No tiene efecto.
  • Especial: Para detalles sobre cómo sampling_period_ns se utiliza para sensores especiales, ver Tipos de sensor .

Para obtener más información sobre el impacto de sampling_period_ns en los diferentes modos, consulte Modos de informes .

Para sensores continuos y en cambio:

  • Si sampling_period_ns es inferior a SensorInfo.minDelay , entonces la aplicación HAL debe sujetar en silencio a max(SensorInfo.minDelay, 1ms) . Android no admite la generación de eventos a más de 1000 Hz.
  • Si sampling_period_ns es mayor que SensorInfo.maxDelay , entonces la aplicación HAL debe truncar en silencio a SensorInfo.maxDelay .

Los sensores físicos a veces tienen limitaciones en las velocidades a las que pueden funcionar y la precisión de sus relojes. Para tener en cuenta esto, la frecuencia de muestreo real puede diferir de la frecuencia solicitada siempre que satisfaga los requisitos de la tabla a continuación.

Si la frecuencia solicitada es

Entonces la frecuencia real debe ser

debajo de la frecuencia mínima (<1 / maxDelay)

entre 90% y 110% de la frecuencia mínima

entre frecuencia mínima y máxima

entre 90% y 220% de la frecuencia solicitada

Frecuencia máxima por encima (> 1 / min Retardo)

entre 90% y 110% de la frecuencia máxima, y ​​por debajo de 1100 Hz

max_report_latency_ns

max_report_latency_ns establece el tiempo máximo en nanosegundos, por el cual los eventos pueden retrasarse y almacenarse en el FIFO del hardware antes de ser reportados a través del HAL mientras el AP está despierto.

Un valor de cero significa que los eventos se deben informar tan pronto como se midan, ya sea omitiendo la FIFO por completo o vaciando la FIFO tan pronto como esté presente un evento del sensor.

Por ejemplo, un acelerómetro activado a 50 Hz con max_report_latency_ns=0 activará interrupciones 50 veces por segundo cuando el AP esté despierto.

Cuando max_report_latency_ns>0 , no es necesario informar los eventos del sensor tan pronto como se detecten. Pueden almacenarse temporalmente en el FIFO e informarse en lotes, siempre que ningún evento se retrase más de max_report_latency_ns nanosegundos. Esto significa que todos los eventos desde el lote anterior se registran y devuelven a la vez. Esto reduce la cantidad de interrupciones enviadas al AP y permite que el AP cambie a un modo de menor potencia (inactivo) mientras el sensor está capturando y procesando datos.

Cada evento tiene una marca de tiempo asociada. Retrasar la hora a la que se informa un evento no afecta la marca de tiempo del evento. La marca de tiempo debe ser precisa y corresponde a la hora en que ocurrió físicamente el evento, no a la hora en que se informó.

Permitir que los eventos del sensor se almacenen temporalmente en el FIFO no modifica el comportamiento de enviar eventos al HAL; los eventos de diferentes sensores se pueden intercalar y todos los eventos del mismo sensor están ordenados por tiempo.

Eventos de despertador y no despertador

Los eventos del sensor de los sensores de activación deben almacenarse en uno o más FIFO de activación. Un diseño común es tener un FIFO de activación único, grande y compartido donde los eventos de todos los sensores de activación se intercalan. Alternativamente, puede tener un FIFO de activación por sensor o tener FIFO dedicados para sensores de activación particulares y un FIFO compartido para el resto de los sensores de activación.

De manera similar, los eventos de sensores de sensores que no son de activación deben almacenarse en uno o más FIFO que no son de activación.

En todos los casos, los eventos del sensor de activación y los eventos del sensor que no son de activación no se pueden intercalar en la misma FIFO. Los eventos de activación deben almacenarse en una FIFO de activación y los eventos que no son de activación deben almacenarse en una FIFO que no sea de activación.

Para el FIFO de activación, el diseño FIFO único, grande y compartido proporciona los mejores beneficios de potencia. Para el FIFO sin activación, el FIFO único, grande compartido y varios diseños de FIFO pequeños reservados tienen características de potencia similares. Para obtener más sugerencias sobre cómo configurar cada FIFO, consulte Prioridad de asignación de FIFO .

Comportamiento fuera del modo de suspensión

Cuando el AP está despierto (no en modo de suspensión), los eventos se almacenan temporalmente en FIFO siempre que no se retrasen más de max_report_latency .

Mientras el AP no entre en modo de suspensión, no se perderá ni perderá ningún evento. Si los FIFO internos se llenan antes de que transcurra max_report_latency , los eventos se informan en ese punto para garantizar que no se pierda ningún evento.

Si varios sensores comparten la misma FIFO y max_report_latency la max_report_latency de uno de ellos, se informan todos los eventos de la FIFO, incluso si aún no ha transcurrido la max_report_latency de los otros sensores. Esto reduce la cantidad de veces que se informan lotes de eventos. Cuando se debe informar un evento, se informan todos los eventos de todos los sensores.

Por ejemplo, si los siguientes sensores están activados:

  • acelerómetro en max_report_latency con max_report_latency = 20s
  • giroscopio en max_report_latency con max_report_latency = 5s

Los lotes del acelerómetro se informan al mismo tiempo que se informan los lotes del giroscopio (cada 5 segundos), incluso si el acelerómetro y el giroscopio no comparten el mismo FIFO.

Comportamiento en modo suspendido

El procesamiento por lotes es particularmente beneficioso para recopilar datos del sensor en segundo plano sin mantener el AP despierto. Debido a que los controladores del sensor y la implementación de HAL no pueden mantener un bloqueo de activación *, el AP puede ingresar al modo de suspensión incluso mientras se recopilan los datos del sensor.

El comportamiento de los sensores mientras el AP está suspendido depende de si el sensor es un sensor de activación. Para obtener más detalles, consulte Sensores de activación .

Cuando un FIFO que no se activa se llena, debe envolverse y comportarse como un búfer circular, sobrescribiendo los eventos más antiguos con los nuevos eventos reemplazando a los antiguos. max_report_latency no tiene ningún impacto en los FIFO que no se activan durante el modo de suspensión.

Cuando se llena un FIFO de max_report_latency , o cuando max_report_latency la max_report_latency de max_report_latency de uno de los sensores de activación, el hardware debe activar el AP e informar los datos.

En ambos casos (reactivación y no reactivación), tan pronto como el AP sale del modo de suspensión, se produce un lote con el contenido de todos los FIFO, incluso si todavía no ha transcurrido la max_report_latency de algunos sensores. Esto minimiza el riesgo de que el AP tenga que despertarse nuevamente poco después de que regrese al modo de suspensión y, por lo tanto, minimiza el consumo de energía.

* Una notable excepción de los conductores a los que no se les permite mantener un bloqueo de activación es cuando se activa un sensor de activación con el modo de informe continuo con max_report_latency <1 segundo. En este caso, el controlador puede mantener un bloqueo de activación porque el AP no tiene tiempo para ingresar al modo de suspensión, ya que se despertaría por un evento de activación antes de llegar al modo de suspensión.

Precauciones a tomar al agrupar sensores de activación

Dependiendo del dispositivo, el AP podría tardar algunos milisegundos en salir completamente del modo de suspensión y comenzar a vaciar el FIFO. Se debe asignar suficiente espacio para la cabeza en el FIFO para permitir que el dispositivo salga del modo de suspensión sin que el FIFO de activación se desborde. No se perderán eventos, y se debe respetar la max_report_latency .

Precauciones a tomar al agrupar sensores de cambio sin activación

Los sensores de cambio solo generan eventos cuando el valor que están midiendo está cambiando. Si el valor medido cambia mientras el AP está en modo de suspensión, las aplicaciones esperan recibir un evento tan pronto como se active el AP. Debido a esto, el procesamiento por lotes de los eventos del sensor de cambio sin activación debe realizarse con cuidado si el sensor comparte su FIFO con otros sensores. El último evento generado por cada sensor de cambio siempre debe guardarse fuera del FIFO compartido para que otros eventos nunca lo puedan sobrescribir. Cuando el AP se despierta, después de que se hayan informado todos los eventos del FIFO, se debe informar el último evento del sensor de cambio.

Aquí hay una situación para evitar:

  1. Una aplicación se registra en el contador de pasos sin activación (en cambio) y en el acelerómetro sin activación (continuo), ambos comparten el mismo FIFO.
  2. La aplicación recibe un evento de contador de pasos step_count=1000 steps código de step_count=1000 steps >.
  3. El AP va a suspender.
  4. El usuario camina 20 pasos, lo que hace que los eventos de contador de pasos y acelerómetro se intercalen, el último evento de contador de pasos es step_count = 1020 steps .
  5. El usuario no se mueve durante mucho tiempo, lo que hace que los eventos del acelerómetro continúen acumulándose en el FIFO, y finalmente sobrescriba cada evento step_count en el FIFO compartido.
  6. AP se despierta y todos los eventos del FIFO se envían a la aplicación.
  7. La aplicación recibe solo eventos de acelerómetro y piensa que el usuario no caminó.

Al guardar el último evento de contador de pasos fuera del FIFO, el HAL puede informar este evento cuando el AP se despierta, incluso si todos los demás eventos de contador de pasos fueron sobrescritos por eventos de acelerómetro. De esta manera, la aplicación recibe step_count = 1020 steps cuando el AP se step_count = 1020 steps .

Implementación de lotes

Para ahorrar energía, se debe implementar el procesamiento por lotes sin la ayuda del AP, y se debe permitir que el AP se suspenda durante el procesamiento por lotes.

Si se realiza el procesamiento por lotes en un concentrador de sensores, se debe minimizar el uso de energía del concentrador de sensores.

La latencia máxima del informe se puede modificar en cualquier momento, en particular mientras el sensor especificado ya está habilitado; y esto no debería resultar en la pérdida de eventos.

Prioridad de asignación FIFO

En las plataformas en las que el tamaño del búfer del concentrador de sensores o FIFO de hardware es limitado, los diseñadores de sistemas pueden tener que elegir cuánto FIFO reservar para cada sensor. Para ayudar con esta elección, aquí hay una lista de posibles aplicaciones cuando se implementa el procesamiento por lotes en los diferentes sensores.

Alto valor: cálculo de muertos de peatones de baja potencia

Tiempo de procesamiento por lotes objetivo: 1 a 10 minutos

Sensores a lote:

  • Detector de pasos de despertador
  • Vector de rotación del juego de despertador a 5 Hz
  • Barómetro de activación a 5 Hz
  • Despertador magnetómetro no calibrado a 5 Hz

El procesamiento por lotes de estos datos permite realizar un recuento de peatones muertos al tiempo que permite que el AP se suspenda.

Alto valor: actividad intermitente de potencia media / reconocimiento de gestos

Tiempo de procesamiento por lotes objetivo: 3 segundos

Sensores a lote: acelerómetro sin activación a 50 Hz

El procesamiento por lotes de estos datos permite reconocer periódicamente actividades y gestos arbitrarios sin tener que mantener el AP despierto mientras se recopilan los datos.

Valor medio: actividad continua de potencia media / reconocimiento de gestos

Tiempo de procesamiento por lotes objetivo: 1 a 3 minutos

Sensores a lote: acelerómetro de activación a 50 Hz

Lotear estos datos permite reconocer continuamente actividades y gestos arbitrarios sin tener que mantener el AP despierto mientras se recopilan los datos.

Valor medio-alto: reducción de la carga de interrupción

Tiempo de procesamiento por lotes objetivo: <1 segundo

Sensores por lote: cualquier sensor de alta frecuencia, generalmente sin activación.

Si el giroscopio está configurado a 240 Hz, incluso el procesamiento por lotes de solo 10 eventos giroscópicos puede reducir el número de interrupciones de 240 / segundo a 24 / segundo.

Valor medio: recopilación continua de datos de baja frecuencia

Tiempo de procesamiento por lotes objetivo: 1 a 10 minutos

Sensores a lote:

  • Barómetro de activación a 1 Hz
  • Sensor de humedad de despertador a 1 Hz
  • Otros sensores de activación de baja frecuencia a velocidades similares

Permite crear aplicaciones de monitoreo a baja potencia.

Valor medio-bajo: colección continua de sensores completos

Tiempo de procesamiento por lotes objetivo: 1 a 10 minutos

Sensores a lote: todos los sensores de activación, a altas frecuencias

Permite la recopilación completa de datos del sensor mientras se deja el AP en modo de suspensión. Solo considere si el espacio FIFO no es un problema.