HAL de sensores 1.0

La interfaz de la HAL de sensores, declarada en sensors.h, representa la interfaz entre el framework de Android y las software específico de hardware. Una implementación de HAL debe definir cada función se declara en sensores.h. Las funciones principales son las siguientes:

• get_sensors_list: muestra la lista de todos los sensores.
• activate: Inicia o detiene un sensor.
• batch: Establece los parámetros de un sensor, como la frecuencia de muestreo y el valor máximo. la latencia de informes.
• setDelay: Solo se usa en la versión 1.0 del HAL. Fija la frecuencia de muestreo de un sensor dado.
• flush: Vacía el FIFO del sensor especificado e informa un vaciado completo. cuando esto esté listo.
• poll: Muestra los eventos de sensores disponibles.

La implementación debe ser segura para el subproceso y permitir que se llame a estas funciones de diferentes subprocesos.

La interfaz también define varios tipos que usan esas funciones. El principal tipos son los siguientes:

• sensors_module_t
• sensors_poll_device_t
• sensor_t
• sensors_event_t

Además de las secciones a continuación, consulta sensors.h para obtener más información sobre esos tipos.

get_sensors_list(lista)

int (*get_sensors_list)(struct sensors_module_t* module, struct sensor_t
  const** list);

Proporciona la lista de sensores implementados por la HAL. Consulta sensor_t para obtener detalles sobre cómo se definen los sensores.

El orden en el que aparecen los sensores en la lista es el orden en que de sensores se informará a las aplicaciones. Por lo general, los sensores base aparecen y, luego, los sensores compuestos.

Si varios sensores comparten el mismo tipo de sensor y propiedad de activación, el primero uno de la lista se llama sensor “predeterminado”. Es el que devuelve getDefaultSensor(int sensorType, bool wakeUp)

Esta función muestra el número de sensores en la lista.

activar(sensor, verdadero/falso)

int (*activate)(struct sensors_poll_device_t *dev, int sensor_handle, int
  enabled);

Activa o desactiva un sensor.

sensor_handle es el controlador del sensor que se activa o desactiva. La característica el identificador se define en el campo handle de su estructura sensor_t.

enabled se establece en 1 para habilitar el sensor o en 0 para inhabilitarlo.

Los sensores de un solo disparo se desactivan automáticamente al recibir un evento e igualmente deben aceptar la desactivación a través de una llamada a activate(..., enabled=0).

Los sensores que no están activados nunca evitan que el SoC entre en modo de suspensión. que la HAL no debe realizar un bloqueo de activación parcial en nombre de las aplicaciones.

Los sensores de activación, cuando se entregan eventos continuamente, pueden evitar que el SoC en modo de suspensión, pero si no es necesario entregar ningún evento, la se debe liberar el bloqueo de activación.

Si enabled es 1 y el sensor ya está activado, esta función no es operativa. y tenga éxito.

Si enabled es 0 y el sensor ya está desactivado, esta función es no-op y tenga éxito.

Esta función muestra 0 en caso de éxito y, de lo contrario, un número de error negativo.

lote(sensor, marcas, período de muestreo, latencia máxima del informe)

int (*batch)(
     struct sensors_poll_device_1* dev,
     int sensor_handle,
     int flags,
     int64_t sampling_period_ns,
     int64_t max_report_latency_ns);

Establece los parámetros de un sensor, incluida la frecuencia de muestreo y informe de máximos latencia. Se puede llamar a esta función mientras el sensor está activado, en en cuyo caso no debe causar que se pierdan las mediciones de los sensores: de una tasa de muestreo a la otra no puede causar la pérdida de eventos, ni transición de una latencia del informe máxima alta a un informe máximo bajo latencia.

sensor_handle es el controlador del sensor que se configurará.

flags no está en uso actualmente.

sampling_period_ns es el período de muestreo en el que el sensor debería ejecutarse en nanosegundos. Consulta samples_period_ns más detalles.

max_report_latency_ns es el tiempo máximo durante el cual se pueden ejecutar los eventos se retrasa antes de informarse a través de la HAL, en nanosegundos. Consulta max_report_Latency_ns párrafo para obtener más detalles.

Esta función muestra 0 en caso de éxito y, de lo contrario, un número de error negativo.

setDelay(sensor, período de muestreo)

int (*setDelay)(
     struct sensors_poll_device_t *dev,
     int sensor_handle,
     int64_t sampling_period_ns);

Después de la versión 1.0 de HAL, esta función es obsoleta y nunca se llama. En su lugar, se llama a la función batch para establecer la Parámetro sampling_period_ns.

En la versión 1.0 de la HAL, se usó setDelay en lugar de por lotes para configurar sample_period_ns.

vaciar(sensor)

int (*flush)(struct sensors_poll_device_1* dev, int sensor_handle);

Agrega un evento de vaciado completo al final del FIFO de hardware para el sensor especificado y limpia el FIFO. estos eventos se entregan como de costumbre (es decir, como si la latencia máxima de los informes venció) y se lo quitó del FIFO.

La limpieza se realiza de forma asíncrona (es decir, esta función debe mostrarse de inmediato). Si la implementación usa un único FIFO para varios sensores, ese FIFO se limpia y el evento de vaciado completo solo se agrega para el sensor especificado.

Si el sensor especificado no tiene FIFO (no hay almacenamiento en búfer posible) o si el FIFO, estaba vacío en el momento de la llamada, flush aún debe completarse correctamente y envía un evento de vaciado completo para ese sensor. Esto se aplica a todos los sensores que no sean que los sensores de un solo golpe.

Cuando se llama a flush, incluso si ya hay un evento de vaciado en el FIFO para ese sensor, se debe crear uno adicional y agregar al final del FIFO, y este se debe limpiar. La cantidad de flush de llamadas debe ser igual a la cantidad de eventos de limpieza completa creados.

flush no se aplica a un intento único sensores; si sensor_handle hace referencia a un sensor de un solo lanzamiento, flush debe mostrar -EINVAL y no generar ningún para limpiar el evento de metadatos completo.

Esta función muestra 0 en caso de éxito, -EINVAL si el sensor especificado es un sensor de un solo uso o no se habilitó, y un número de error negativo en caso contrario.

encuesta()

int (*poll)(struct sensors_poll_device_t *dev, sensors_event_t* data, int
  count);

Muestra un array de datos de sensores completando el argumento data. Esta función se deben bloquear hasta que los eventos estén disponibles. Devuelve la cantidad de eventos leídos si la operación es exitosa o un número de error negativo en caso de error.

La cantidad de eventos que se muestran en data debe ser menor o igual que el argumento count. Esta función nunca debe devolver 0 (ningún evento).

Secuencia de llamadas

Cuando se inicia el dispositivo, se llama a get_sensors_list.

Cuando se activa un sensor, se llamará a la función batch con el los parámetros solicitados, seguidos de activate(..., enable=1).

Ten en cuenta que, en la versión 1_0 de HAL, el orden era el opuesto: se llamaba a activate. primero y, luego, set_delay.

Cuando las características solicitadas de un sensor cambian mientras está activado, se llama a la función batch.

Se puede llamar a flush en cualquier momento, incluso con sensores no activados (en cuyo caso debe mostrar -EINVAL).

Cuando se desactive un sensor, se llamará a activate(..., enable=0).

En paralelo a esas llamadas, se llamará repetidamente a la función poll para solicitar datos. Se puede llamar a poll incluso cuando no hay sensores activados.

módulo_sensor_t

sensors_module_t es el tipo que se usa para crear el hardware de Android. para los sensores. La implementación de la HAL debe definir un objeto HAL_MODULE_INFO_SYM de este tipo para exponer la función get_sensors_list. Consulta la definición de sensors_module_t en sensors.h y la definición de hw_module_t para obtener más información.

sensores_poll_device_t / sensor_poll_device_1_t

sensors_poll_device_1_t contiene el resto de los métodos que se definieron anteriormente: activate, batch, flush y poll Su campo common (del tipo hw_device_t) define el número de versión de la HAL.

sensor_t

sensor_t representa un objeto Android sensor de movimiento. Estos son algunos de sus campos importantes:

name: Una cadena visible para el usuario que representa el sensor. Esta cadena a menudo contiene el nombre de la pieza del sensor subyacente, el tipo de sensor y ya sea un sensor de activación. Por ejemplo, “Acelerómetro LIS2HH12”, "Giroscopio no calibrado MAX21000", "Barómetro BMP280 Wake-up", "Juego MPU6515 Vector de rotación”

handle: Es el número entero que se usa para hacer referencia al sensor cuando se registra en él. generar eventos a partir de ella.

type: El tipo de sensor. Consulta la explicación de los sensores escribe ¿Qué son los sensores de Android? para obtener más información y consulta Tipos de sensores para conocer los tipos de sensores oficiales. Para tipos de sensores no oficiales, type debe comenzar con SENSOR_TYPE_DEVICE_PRIVATE_BASE

stringType: el tipo de sensor como una cadena Cuando sensor tiene un tipo oficial, establecido en SENSOR_STRING_TYPE_*. Cuándo el sensor tiene un tipo específico de fabricante, stringType debe comenzar con el nombre de dominio inverso del fabricante. Por ejemplo, un sensor (p. ej., un detector de unicornios) definidos por el equipo de Cool-Product en Figion-Company podría utilizar stringType=”com.fictional_company.cool_product.unicorn_detector” El stringType se usa para identificar de forma exclusiva los sensores no oficiales de tipos de datos. Consulta sensors.h para obtener más información sobre los tipos y las cadenas. de tipos de datos.

requiredPermission: Es una cadena que representa el permiso. que las aplicaciones deben poseer para ver el sensor, registrarse en él y recibir sus datos. Una cadena vacía significa que las aplicaciones no requieren ningún permiso para acceder a este sensor. Algunos tipos de sensores, como el monitor de frecuencia cardíaca, tienen un requiredPermission obligatorio. Todos los sensores que proporcionan datos información del usuario (como la frecuencia cardíaca) debe estar protegida por un permiso.

flags: Son las marcas de este sensor que definen el modo de informe del sensor y si si el sensor es un sensor de activación o no. Por ejemplo, un sensor de activación único tendrá flags = SENSOR_FLAG_ONE_SHOT_MODE | SENSOR_FLAG_WAKE_UP. Los bits de la marca que no se usa en la versión actual del HAL debe ser igual a 0.

maxRange: el valor máximo que puede informar el sensor, en la misma unidad que para los valores informados. El sensor debe poder informar valores sin saturar en [-maxRange; maxRange]. Ten en cuenta que esto significa que el rango total de en el sentido genérico es 2*maxRange. Cuando el sensor informa valores durante varios ejes, el rango se aplica a cada uno de ellos. Por ejemplo, el valor "+/- 2g" el acelerómetro informará maxRange = 2*9.81 = 2g.

resolución: es la diferencia más pequeña en valor que el sensor puede medir. Por lo general, se calcula en función de maxRange y la cantidad de bits en la medición.

power: El costo de potencia de habilitar el sensor, en miliA Esto casi siempre es más que el consumo de energía informado en la del sensor subyacente. Consulta Sensores base != físico sensores para obtener más información y consulta Medición de energía para obtener detalles sobre cómo medir el consumo de energía de un sensor. Si el consumo de energía del sensor depende de si el dispositivo está en movimiento, el el consumo de energía en movimiento es el que se informa en el power .

minDelay: para sensores continuos, el período de muestreo, en microsegundos, que corresponden a la velocidad más rápida que admite el sensor. Consulta samples_period_ns detalles sobre cómo se usa este valor. Ten en cuenta que minDelay es se expresa en microsegundos, mientras que sampling_period_ns está en nanosegundos. Para los sensores del modo de generación de informes especial y en caso de cambio, a menos que de lo contrario, minDelay debe ser 0. En el caso de los sensores de un solo golpe, debe ser -1.

maxDelay: para sensores continuos y de cambio, la capacidad de tiempo en microsegundos, que corresponde a la velocidad más lenta a la que admite. Consulta samples_period_ns detalles sobre cómo se usa este valor. Ten en cuenta que maxDelay es se expresa en microsegundos, mientras que sampling_period_ns está en nanosegundos. Para sensores especiales y de un solo disparo, se debe cumplir con lo siguiente: maxDelay 0.

fifoReservedEventCount: la cantidad de eventos reservados para este sensor en el FIFO de hardware. Si hay un FIFO dedicado para este sensor, fifoReservedEventCount es el tamaño de este FIFO dedicado. Si el FIFO es compartido con otros sensores, fifoReservedEventCount es el tamaño de la parte de el FIFO reservado para ese sensor. En la mayoría de los sistemas FIFO compartidos y en que no tienen un FIFO de hardware, este valor es 0.

fifoMaxEventCount: la cantidad máxima de eventos que podrían en los FIFO de este sensor. Siempre es mayor o igual que fifoReservedEventCount Este valor se usa para estimar rápidamente, el FIFO se llenará cuando se registre en el sensor en un de procesamiento, suponiendo que no hay otros sensores activados. En los sistemas que no tienen FIFO de hardware, fifoMaxEventCount es 0. Consulta Agrupación en lotes para obtener más detalles.

En el caso de los sensores con un tipo de sensor oficial, algunos campos se reemplazan el framework. Por ejemplo, los sensores de acelerómetro. se ven obligados a tener un modo de informes continuos, y los monitores de frecuencia cardíaca forzadas a estar protegidas por las SENSOR_PERMISSION_BODY_SENSORS permiso.

evento_sensores

Los eventos de sensor que generan los sensores de Android y que se informan a través de la función de poll son de type sensors_event_t. Estos son algunos ejemplos campos importantes de sensors_event_t:

version: Debe ser sizeof(struct sensors_event_t)

sensor: El controlador del sensor que generó el evento, según lo define sensor_t.handle

type: El tipo de sensor del sensor que generó el evento, según lo definido por sensor_t.type

timestamp: Es la marca de tiempo del evento en nanosegundos. Este es el momento en el que evento específico (se realizó un paso o se realizó una medición con un acelerómetro), no la hora en que se informó el evento. timestamp debe sincronizarse con el elapsedRealtimeNano y, en el caso de los sensores continuos, el Jitter debe ser pequeño. A veces, el filtrado de marca de tiempo es necesario para satisfacer el CDD. como usar solo el tiempo de interrupción del SoC provoca un jitter demasiado alto y usas solo el tiempo del chip del sensor para establecer las marcas de tiempo pueden provocar una desincronización desde elapsedRealtimeNano, a medida que el reloj del sensor se desvía.

datos y campos superpuestos: Son los valores que mide la sensor. El significado y las unidades de esos campos son específicos para cada sensor el tipo de letra. Consulta sensors.h y la definición de los diferentes tipos de sensores para obtener una descripción de campos de datos. En el caso de algunos sensores, también se informa la precisión de las lecturas como parte de los datos, a través de un campo status. Este campo es solo canalizados para esos tipos de sensores seleccionados, que aparecen en la capa del SDK como un el valor de exactitud. Para esos sensores, el hecho de que el campo de estado se deba establecer se menciona en su tipo de sensor definición.

Eventos completos de limpieza de metadatos

Los eventos de metadatos tienen el mismo tipo que los eventos de sensores normales: sensors_event_meta_data_t = sensors_event_t Se devuelven junto con otros eventos de sensores a través de sondeos. Tienen los siguientes campos:

version: Debe ser META_DATA_VERSION

type: Debe ser SENSOR_TYPE_META_DATA

sensor, reservado y marca de tiempo: Debe ser 0.

meta_data.what: Contiene el tipo de metadatos para este evento. Actualmente hay un único tipo de metadatos válido: META_DATA_FLUSH_COMPLETE.

Los eventos META_DATA_FLUSH_COMPLETE representan la finalización de la limpieza de un sensor FIFO. Cuando meta_data.what=META_DATA_FLUSH_COMPLETE, meta_data.sensor debe fijarse en la manija del sensor que se purgó. Son Se genera solo cuando se llama a flush en un sensor. Consulta la sección sobre la función flush para obtener más información.