aboutsummaryrefslogtreecommitdiff
path: root/chre_api/legacy/v1_4/chre/sensor.h
diff options
context:
space:
mode:
Diffstat (limited to 'chre_api/legacy/v1_4/chre/sensor.h')
-rw-r--r--chre_api/legacy/v1_4/chre/sensor.h1018
1 files changed, 0 insertions, 1018 deletions
diff --git a/chre_api/legacy/v1_4/chre/sensor.h b/chre_api/legacy/v1_4/chre/sensor.h
deleted file mode 100644
index 88cfce8e..00000000
--- a/chre_api/legacy/v1_4/chre/sensor.h
+++ /dev/null
@@ -1,1018 +0,0 @@
-/*
- * Copyright (C) 2016 The Android Open Source Project
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-#ifndef _CHRE_SENSOR_H_
-#define _CHRE_SENSOR_H_
-
-/**
- * @file
- * API dealing with sensor interaction in the Context Hub Runtime
- * Environment.
- *
- * This includes the definition of our sensor types and the ability to
- * configure them for receiving events.
- */
-
-#include <stdbool.h>
-#include <stdint.h>
-
-#include <chre/common.h>
-#include <chre/event.h>
-#include <chre/sensor_types.h>
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-
-/**
- * Base value for all of the data events for sensors.
- *
- * The value for a data event FOO is
- * CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_FOO
- *
- * This allows for easy mapping, and also explains why there are gaps
- * in our values since we don't have all possible sensor types assigned.
- */
-#define CHRE_EVENT_SENSOR_DATA_EVENT_BASE CHRE_EVENT_SENSOR_FIRST_EVENT
-
-/**
- * nanoappHandleEvent argument: struct chreSensorThreeAxisData
- *
- * The data can be interpreted using the 'x', 'y', and 'z' fields within
- * 'readings', or by the 3D array 'v' (v[0] == x; v[1] == y; v[2] == z).
- *
- * All values are in SI units (m/s^2) and measure the acceleration applied to
- * the device.
- */
-#define CHRE_EVENT_SENSOR_ACCELEROMETER_DATA \
- (CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_ACCELEROMETER)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorOccurrenceData
- *
- * Since this is a one-shot sensor, after this event is delivered to the
- * nanoapp, the sensor automatically goes into DONE mode. Sensors of this
- * type must be configured with a ONE_SHOT mode.
- */
-#define CHRE_EVENT_SENSOR_INSTANT_MOTION_DETECT_DATA \
- (CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_INSTANT_MOTION_DETECT)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorOccurrenceData
- *
- * Since this is a one-shot sensor, after this event is delivered to the
- * nanoapp, the sensor automatically goes into DONE mode. Sensors of this
- * type must be configured with a ONE_SHOT mode.
- */
-#define CHRE_EVENT_SENSOR_STATIONARY_DETECT_DATA \
- (CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_STATIONARY_DETECT)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorThreeAxisData
- *
- * The data can be interpreted using the 'x', 'y', and 'z' fields within
- * 'readings', or by the 3D array 'v' (v[0] == x; v[1] == y; v[2] == z).
- *
- * All values are in radians/second and measure the rate of rotation
- * around the X, Y and Z axis.
- */
-#define CHRE_EVENT_SENSOR_GYROSCOPE_DATA \
- (CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_GYROSCOPE)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorThreeAxisData
- *
- * The data can be interpreted using the 'x', 'y', and 'z' fields within
- * 'readings', or by the 3D array 'v' (v[0] == x; v[1] == y; v[2] == z).
- *
- * All values are in micro-Tesla (uT) and measure the geomagnetic
- * field in the X, Y and Z axis.
- */
-#define CHRE_EVENT_SENSOR_GEOMAGNETIC_FIELD_DATA \
- (CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_GEOMAGNETIC_FIELD)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorFloatData
- *
- * The data can be interpreted using the 'pressure' field within 'readings'.
- * This value is in hectopascals (hPa).
- */
-#define CHRE_EVENT_SENSOR_PRESSURE_DATA \
- (CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_PRESSURE)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorFloatData
- *
- * The data can be interpreted using the 'light' field within 'readings'.
- * This value is in SI lux units.
- */
-#define CHRE_EVENT_SENSOR_LIGHT_DATA \
- (CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_LIGHT)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorByteData
- *
- * The data is interpreted from the following fields in 'readings':
- * o 'isNear': If set to 1, we are nearby (on the order of centimeters);
- * if set to 0, we are far. The meaning of near/far in this field must be
- * consistent with the Android definition.
- * o 'invalid': If set to 1, this is not a valid reading of this data.
- * As of CHRE API v1.2, this field is deprecated and must always be set to
- * 0. If an invalid reading is generated by the sensor hardware, it must
- * be dropped and not delivered to any nanoapp.
- *
- * In prior versions of the CHRE API, there can be an invalid event generated
- * upon configuring this sensor. Thus, the 'invalid' field must be checked on
- * the first event before interpreting 'isNear'.
- */
-#define CHRE_EVENT_SENSOR_PROXIMITY_DATA \
- (CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_PROXIMITY)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorOccurrenceData
- *
- * This data is generated every time a step is taken by the user.
- *
- * @since v1.3
- */
-#define CHRE_EVENT_SENSOR_STEP_DETECT_DATA \
- (CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_STEP_DETECT)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorThreeAxisData
- *
- * The data can be interpreted using the 'x', 'y', and 'z' fields within
- * 'readings', or by the 3D array 'v' (v[0] == x; v[1] == y; v[2] == z).
- *
- * All values are in SI units (m/s^2) and measure the acceleration applied to
- * the device.
- */
-#define CHRE_EVENT_SENSOR_UNCALIBRATED_ACCELEROMETER_DATA \
- (CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_UNCALIBRATED_ACCELEROMETER)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorThreeAxisData
- *
- * The data can be interpreted using the 'x', 'y', and 'z' fields within
- * 'readings', or by the 3D array 'v' (v[0] == x; v[1] == y; v[2] == z).
- *
- * All values are in radians/second and measure the rate of rotation
- * around the X, Y and Z axis.
- */
-#define CHRE_EVENT_SENSOR_UNCALIBRATED_GYROSCOPE_DATA \
- (CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_UNCALIBRATED_GYROSCOPE)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorThreeAxisData
- *
- * The data can be interpreted using the 'x', 'y', and 'z' fields within
- * 'readings', or by the 3D array 'v' (v[0] == x; v[1] == y; v[2] == z).
- *
- * All values are in micro-Tesla (uT) and measure the geomagnetic
- * field in the X, Y and Z axis.
- */
-#define CHRE_EVENT_SENSOR_UNCALIBRATED_GEOMAGNETIC_FIELD_DATA \
- (CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_UNCALIBRATED_GEOMAGNETIC_FIELD)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorFloatData
- *
- * The data can be interpreted using the 'temperature' field within 'readings'.
- * This value is in degrees Celsius.
- */
-#define CHRE_EVENT_SENSOR_ACCELEROMETER_TEMPERATURE_DATA \
- (CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_ACCELEROMETER_TEMPERATURE)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorFloatData
- *
- * The data can be interpreted using the 'temperature' field within 'readings'.
- * This value is in degrees Celsius.
- */
-#define CHRE_EVENT_SENSOR_GYROSCOPE_TEMPERATURE_DATA \
- (CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_GYROSCOPE_TEMPERATURE)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorFloatData
- *
- * The data can be interpreted using the 'temperature' field within 'readings'.
- * This value is in degrees Celsius.
- */
-#define CHRE_EVENT_SENSOR_GEOMAGNETIC_FIELD_TEMPERATURE_DATA \
- (CHRE_EVENT_SENSOR_DATA_EVENT_BASE + CHRE_SENSOR_TYPE_GEOMAGNETIC_FIELD_TEMPERATURE)
-
-/**
- * First value for sensor events which are not data from the sensor.
- *
- * Unlike the data event values, these other event values don't have any
- * mapping to sensor types.
- */
-#define CHRE_EVENT_SENSOR_OTHER_EVENTS_BASE \
- (CHRE_EVENT_SENSOR_FIRST_EVENT + 0x0100)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorSamplingStatusEvent
- *
- * Indicates that the interval and/or the latency which this sensor is
- * sampling at has changed.
- */
-#define CHRE_EVENT_SENSOR_SAMPLING_CHANGE \
- (CHRE_EVENT_SENSOR_OTHER_EVENTS_BASE + 0)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorThreeAxisData
- *
- * The data can be interpreted using the 'x_bias', 'y_bias', and 'z_bias'
- * field within 'readings', or by the 3D array 'bias' (bias[0] == x_bias;
- * bias[1] == y_bias; bias[2] == z_bias). Bias is subtracted from uncalibrated
- * data to generate calibrated data.
- *
- * All values are in radians/second and measure the rate of rotation
- * around the X, Y and Z axis.
- *
- * If bias delivery is supported, this event is generated by default when
- * chreSensorConfigure is called to enable for the sensor of type
- * CHRE_SENSOR_TYPE_GYROSCOPE, or if bias delivery is explicitly enabled
- * through chreSensorConfigureBiasEvents() for the sensor.
- */
-#define CHRE_EVENT_SENSOR_GYROSCOPE_BIAS_INFO \
- (CHRE_EVENT_SENSOR_OTHER_EVENTS_BASE + 1)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorThreeAxisData
- *
- * The data can be interpreted using the 'x_bias', 'y_bias', and 'z_bias'
- * field within 'readings', or by the 3D array 'bias' (bias[0] == x_bias;
- * bias[1] == y_bias; bias[2] == z_bias). Bias is subtracted from uncalibrated
- * data to generate calibrated data.
- *
- * All values are in micro-Tesla (uT) and measure the geomagnetic
- * field in the X, Y and Z axis.
- *
- * If bias delivery is supported, this event is generated by default when
- * chreSensorConfigure is called to enable for the sensor of type
- * CHRE_SENSOR_TYPE_GEOMAGNETIC_FIELD, or if bias delivery is explicitly enabled
- * through chreSensorConfigureBiasEvents() for the sensor.
- */
-#define CHRE_EVENT_SENSOR_GEOMAGNETIC_FIELD_BIAS_INFO \
- (CHRE_EVENT_SENSOR_OTHER_EVENTS_BASE + 2)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorThreeAxisData
- *
- * The data can be interpreted using the 'x_bias', 'y_bias', and 'z_bias'
- * field within 'readings', or by the 3D array 'bias' (bias[0] == x_bias;
- * bias[1] == y_bias; bias[2] == z_bias). Bias is subtracted from uncalibrated
- * data to generate calibrated data.
- *
- * All values are in SI units (m/s^2) and measure the acceleration applied to
- * the device.
- *
- * If bias delivery is supported, this event is generated by default when
- * chreSensorConfigure is called to enable for the sensor of type
- * CHRE_SENSOR_TYPE_ACCELEROMETER, or if bias delivery is explicitly enabled
- * through chreSensorConfigureBiasEvents() for the sensor.
- *
- * @since v1.3
- */
-#define CHRE_EVENT_SENSOR_ACCELEROMETER_BIAS_INFO \
- (CHRE_EVENT_SENSOR_OTHER_EVENTS_BASE + 3)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorFlushCompleteEvent
- *
- * An event indicating that a flush request made by chreSensorFlushAsync has
- * completed.
- *
- * @see chreSensorFlushAsync
- *
- * @since v1.3
- */
-#define CHRE_EVENT_SENSOR_FLUSH_COMPLETE \
- (CHRE_EVENT_SENSOR_OTHER_EVENTS_BASE + 4)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorThreeAxisData
- *
- * The data of this event is the same as that of
- * CHRE_EVENT_SENSOR_GYROSCOPE_BIAS_INFO, except the sensorHandle field of
- * chreSensorDataHeader contains the handle of the sensor of type
- * CHRE_SENSOR_TYPE_UNCALIBRATED_GYROSCOPE.
- *
- * This event is only generated if the bias reporting is explicitly enabled
- * for a nanoapp through chreSensorConfigureBiasEvents() for the sensor of type
- * CHRE_SENSOR_TYPE_UNCALIBRATED_GYROSCOPE.
- *
- * @see CHRE_EVENT_SENSOR_GYROSCOPE_BIAS_INFO
- *
- * @since v1.3
- */
-#define CHRE_EVENT_SENSOR_UNCALIBRATED_GYROSCOPE_BIAS_INFO \
- (CHRE_EVENT_SENSOR_OTHER_EVENTS_BASE + 5)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorThreeAxisData
- *
- * The data of this event is the same as that of
- * CHRE_EVENT_SENSOR_GEOMAGNETIC_FIELD_BIAS_INFO, except the sensorHandle field
- * of chreSensorDataHeader contains the handle of the sensor of type
- * CHRE_SENSOR_TYPE_UNCALIBRATED_GEOMAGNETIC_FIELD.
- *
- * This event is only generated if the bias reporting is explicitly enabled
- * for a nanoapp through chreSensorConfigureBiasEvents() for the sensor of type
- * CHRE_SENSOR_TYPE_UNCALIBRATED_GEOMAGNETIC_FIELD.
- *
- * @see CHRE_EVENT_SENSOR_GEOMAGNETIC_FIELD_BIAS_INFO
- *
- * @since v1.3
- */
-#define CHRE_EVENT_SENSOR_UNCALIBRATED_GEOMAGNETIC_FIELD_BIAS_INFO \
- (CHRE_EVENT_SENSOR_OTHER_EVENTS_BASE + 6)
-
-/**
- * nanoappHandleEvent argument: struct chreSensorThreeAxisData
- *
- * The data of this event is the same as that of
- * CHRE_EVENT_SENSOR_ACCELEROMETER_BIAS_INFO, except the sensorHandle field
- * of chreSensorDataHeader contains the handle of the sensor of type
- * CHRE_SENSOR_TYPE_UNCALIBRATED_ACCELEROMETER.
- *
- * This event is only generated if the bias reporting is explicitly enabled
- * for a nanoapp through chreSensorConfigureBiasEvents for the sensor of type
- * CHRE_SENSOR_TYPE_UNCALIBRATED_ACCELEROMETER.
- *
- * @see CHRE_EVENT_SENSOR_ACCELEROMETER_BIAS_INFO
- *
- * @since v1.3
- */
-#define CHRE_EVENT_SENSOR_UNCALIBRATED_ACCELEROMETER_BIAS_INFO \
- (CHRE_EVENT_SENSOR_OTHER_EVENTS_BASE + 7)
-
-#if CHRE_EVENT_SENSOR_UNCALIBRATED_ACCELEROMETER_BIAS_INFO > \
- CHRE_EVENT_SENSOR_LAST_EVENT
-#error Too many sensor events.
-#endif
-
-/**
- * Value indicating we want the smallest possible latency for a sensor.
- *
- * This literally translates to 0 nanoseconds for the chreSensorConfigure()
- * argument. While we won't get exactly 0 nanoseconds, the CHRE will
- * queue up this event As Soon As Possible.
- */
-#define CHRE_SENSOR_LATENCY_ASAP UINT64_C(0)
-
-/**
- * Special value indicating non-importance, or non-applicability of the sampling
- * interval.
- *
- * @see chreSensorConfigure
- * @see chreSensorSamplingStatus
- */
-#define CHRE_SENSOR_INTERVAL_DEFAULT UINT64_C(-1)
-
-/**
- * Special value indicating non-importance of the latency.
- *
- * @see chreSensorConfigure
- * @see chreSensorSamplingStatus
- */
-#define CHRE_SENSOR_LATENCY_DEFAULT UINT64_C(-1)
-
-/**
- * Special value indicating non-importance of the batch interval.
- *
- * @see chreSensorConfigureWithBatchInterval
- */
-#define CHRE_SENSOR_BATCH_INTERVAL_DEFAULT UINT64_C(-1)
-
-// This is used to define elements of enum chreSensorConfigureMode.
-#define CHRE_SENSOR_CONFIGURE_RAW_POWER_ON (1 << 0)
-
-// This is used to define elements of enum chreSensorConfigureMode.
-#define CHRE_SENSOR_CONFIGURE_RAW_REPORT_CONTINUOUS (1 << 1)
-
-// This is used to define elements of enum chreSensorConfigureMode.
-#define CHRE_SENSOR_CONFIGURE_RAW_REPORT_ONE_SHOT (2 << 1)
-
-/**
- * The maximum amount of time allowed to elapse between the call to
- * chreSensorFlushAsync() and when CHRE_EVENT_SENSOR_FLUSH_COMPLETE is delivered
- * to the nanoapp on a successful flush.
- */
-#define CHRE_SENSOR_FLUSH_COMPLETE_TIMEOUT_NS (5 * CHRE_NSEC_PER_SEC)
-
-/**
- * Modes we can configure a sensor to use.
- *
- * Our mode will affect not only how/if we receive events, but
- * also whether or not the sensor will be powered on our behalf.
- *
- * @see chreSensorConfigure
- */
-enum chreSensorConfigureMode {
- /**
- * Get events from the sensor.
- *
- * Power: Turn on if not already on.
- * Reporting: Continuous. Send each new event as it comes (subject to
- * batching and latency).
- */
- CHRE_SENSOR_CONFIGURE_MODE_CONTINUOUS =
- (CHRE_SENSOR_CONFIGURE_RAW_POWER_ON |
- CHRE_SENSOR_CONFIGURE_RAW_REPORT_CONTINUOUS),
-
- /**
- * Get a single event from the sensor and then become DONE.
- *
- * Once the event is sent, the sensor automatically
- * changes to CHRE_SENSOR_CONFIGURE_MODE_DONE mode.
- *
- * Power: Turn on if not already on.
- * Reporting: One shot. Send the next event and then be DONE.
- */
- CHRE_SENSOR_CONFIGURE_MODE_ONE_SHOT =
- (CHRE_SENSOR_CONFIGURE_RAW_POWER_ON |
- CHRE_SENSOR_CONFIGURE_RAW_REPORT_ONE_SHOT),
-
- /**
- * Get events from a sensor that are generated for any client in the system.
- *
- * This is considered passive because the sensor will not be powered on for
- * the sake of our nanoapp. If and only if another client in the system has
- * requested this sensor power on will we get events.
- *
- * This can be useful for something which is interested in seeing data, but
- * not interested enough to be responsible for powering on the sensor.
- *
- * Power: Do not power the sensor on our behalf.
- * Reporting: Continuous. Send each event as it comes.
- */
- CHRE_SENSOR_CONFIGURE_MODE_PASSIVE_CONTINUOUS =
- CHRE_SENSOR_CONFIGURE_RAW_REPORT_CONTINUOUS,
-
- /**
- * Get a single event from a sensor that is generated for any client in the
- * system.
- *
- * See CHRE_SENSOR_CONFIGURE_MODE_PASSIVE_CONTINUOUS for more details on
- * what the "passive" means.
- *
- * Power: Do not power the sensor on our behalf.
- * Reporting: One shot. Send only the next event and then be DONE.
- */
- CHRE_SENSOR_CONFIGURE_MODE_PASSIVE_ONE_SHOT =
- CHRE_SENSOR_CONFIGURE_RAW_REPORT_ONE_SHOT,
-
- /**
- * Indicate we are done using this sensor and no longer interested in it.
- *
- * See chreSensorConfigure for more details on expressing interest or
- * lack of interest in a sensor.
- *
- * Power: Do not power the sensor on our behalf.
- * Reporting: None.
- */
- CHRE_SENSOR_CONFIGURE_MODE_DONE = 0,
-};
-
-/**
- * A structure containing information about a Sensor.
- *
- * See documentation of individual fields below.
- */
-struct chreSensorInfo {
- /**
- * The name of the sensor.
- *
- * A text name, useful for logging/debugging, describing the Sensor. This
- * is not assured to be unique (i.e. there could be multiple sensors with
- * the name "Temperature").
- *
- * CHRE implementations may not set this as NULL. An empty
- * string, while discouraged, is legal.
- */
- const char *sensorName;
-
- /**
- * One of the CHRE_SENSOR_TYPE_* defines above.
- */
- uint8_t sensorType;
-
- /**
- * Flag indicating if this sensor is on-change.
- *
- * An on-change sensor only generates events when underlying state
- * changes. This has the same meaning as on-change does in the Android
- * Sensors HAL. See sensors.h for much more details.
- *
- * A value of 1 indicates this is on-change. 0 indicates this is not
- * on-change.
- */
- uint8_t isOnChange : 1;
-
- /**
- * Flag indicating if this sensor is one-shot.
- *
- * A one-shot sensor only triggers a single event, and then automatically
- * disables itself.
- *
- * A value of 1 indicates this is one-shot. 0 indicates this is not
- * on-change.
- */
- uint8_t isOneShot : 1;
-
- /**
- * Flag indicating if this sensor supports reporting bias info events.
- *
- * This field will be set to 0 when running on CHRE API versions prior to
- * v1.3, but must be ignored (i.e. does not mean bias info event is not
- * supported).
- *
- * @see chreSensorConfigureBiasEvents
- *
- * @since v1.3
- */
- uint8_t reportsBiasEvents : 1;
-
- /**
- * Flag indicating if this sensor supports passive mode requests.
- *
- * This field will be set to 0 when running on CHRE API versions prior to
- * v1.4, and must be ignored (i.e. does not mean passive mode requests are
- * not supported).
- *
- * @see chreSensorConfigure
- *
- * @since v1.4
- */
- uint8_t supportsPassiveMode : 1;
-
- uint8_t unusedFlags : 4;
-
- /**
- * The minimum sampling interval supported by this sensor, in nanoseconds.
- *
- * Requests to chreSensorConfigure with a lower interval than this will
- * fail. If the sampling interval is not applicable to this sensor, this
- * will be set to CHRE_SENSOR_INTERVAL_DEFAULT.
- *
- * This field will be set to 0 when running on CHRE API versions prior to
- * v1.1, indicating that the minimum interval is not known.
- *
- * @since v1.1
- */
- uint64_t minInterval;
-};
-
-/**
- * The status of a sensor's sampling configuration.
- */
-struct chreSensorSamplingStatus {
- /**
- * The interval, in nanoseconds, at which the sensor is now sampling.
- *
- * If this is CHRE_SENSOR_INTERVAL_DEFAULT, then a sampling interval
- * isn't meaningful for this sensor.
- *
- * Note that if 'enabled' is false, this value is not meaningful.
- */
- uint64_t interval;
-
- /**
- * The latency, in nanoseconds, at which the senor is now reporting.
- *
- * If this is CHRE_SENSOR_LATENCY_DEFAULT, then a latency
- * isn't meaningful for this sensor.
- *
- * The effective batch interval can be derived from this value by
- * adding the current sampling interval.
- *
- * Note that if 'enabled' is false, this value is not meaningful.
- */
- uint64_t latency;
-
- /**
- * True if the sensor is actively powered and sampling; false otherwise.
- */
- bool enabled;
-};
-
-/**
- * The nanoappHandleEvent argument for CHRE_EVENT_SENSOR_SAMPLING_CHANGE.
- *
- * Note that only at least one of 'interval' or 'latency' must be
- * different than it was prior to this event. Thus, one of these
- * fields may be (but doesn't need to be) the same as before.
- */
-struct chreSensorSamplingStatusEvent {
- /**
- * The handle of the sensor which has experienced a change in sampling.
- */
- uint32_t sensorHandle;
-
- /**
- * The new sampling status.
- *
- * At least one of the field in this struct will be different from
- * the previous sampling status event.
- */
- struct chreSensorSamplingStatus status;
-};
-
-/**
- * The nanoappHandleEvent argument for CHRE_EVENT_SENSOR_FLUSH_COMPLETE.
- *
- * @see chreSensorFlushAsync
- *
- * @since v1.3
- */
-struct chreSensorFlushCompleteEvent {
- /**
- * The handle of the sensor which a flush was completed.
- */
- uint32_t sensorHandle;
-
- /**
- * Populated with a value from enum {@link #chreError}, indicating whether
- * the flush failed, and if so, provides the cause of the failure.
- */
- uint8_t errorCode;
-
- /**
- * Reserved for future use. Set to 0.
- */
- uint8_t reserved[3];
-
- /**
- * Set to the cookie parameter given to chreSensorFlushAsync.
- */
- const void *cookie;
-};
-
-/**
- * Find the default sensor for a given sensor type.
- *
- * @param sensorType One of the CHRE_SENSOR_TYPE_* constants.
- * @param handle If a sensor is found, then the memory will be filled with
- * the value for the sensor's handle. This argument must be non-NULL.
- * @return true if a sensor was found, false otherwise.
- */
-bool chreSensorFindDefault(uint8_t sensorType, uint32_t *handle);
-
-/**
- * Get the chreSensorInfo struct for a given sensor.
- *
- * @param sensorHandle The sensor handle, as obtained from
- * chreSensorFindDefault() or passed to nanoappHandleEvent().
- * @param info If the sensor is valid, then this memory will be filled with
- * the SensorInfo contents for this sensor. This argument must be
- * non-NULL.
- * @return true if the senor handle is valid and 'info' was filled in;
- * false otherwise.
- */
-bool chreGetSensorInfo(uint32_t sensorHandle, struct chreSensorInfo *info);
-
-/**
- * Get the chreSensorSamplingStatus struct for a given sensor.
- *
- * Note that this may be different from what was requested in
- * chreSensorConfigure(), for multiple reasons. It's possible that the sensor
- * does not exactly support the interval requested in chreSensorConfigure(), so
- * a faster one was chosen.
- *
- * It's also possible that there is another user of this sensor who has
- * requested a faster interval and/or lower latency. This latter scenario
- * should be noted, because it means the sensor rate can change due to no
- * interaction from this nanoapp. Note that the
- * CHRE_EVENT_SENSOR_SAMPLING_CHANGE event will trigger in this case, so it's
- * not necessary to poll for such a change.
- *
- * @param sensorHandle The sensor handle, as obtained from
- * chreSensorFindDefault() or passed to nanoappHandleEvent().
- * @param status If the sensor is valid, then this memory will be filled with
- * the sampling status contents for this sensor. This argument must be
- * non-NULL.
- * @return true if the senor handle is valid and 'status' was filled in;
- * false otherwise.
- */
-bool chreGetSensorSamplingStatus(uint32_t sensorHandle,
- struct chreSensorSamplingStatus *status);
-
-/**
- * Configures a given sensor at a specific interval and latency and mode.
- *
- * If this sensor's chreSensorInfo has isOneShot set to 1,
- * then the mode must be one of the ONE_SHOT modes, or this method will fail.
- *
- * The CHRE wants to power as few sensors as possible, in keeping with its
- * low power design. As such, it only turns on sensors when there are clients
- * actively interested in that sensor data, and turns off sensors as soon as
- * there are no clients interested in them. Calling this method generally
- * indicates an interest, and using CHRE_SENSOR_CONFIGURE_MODE_DONE shows
- * when we are no longer interested.
- *
- * Thus, each initial Configure of a sensor (per nanoapp) needs to eventually
- * have a DONE call made, either directly or on its behalf. Subsequent calls
- * to a Configure method within the same nanoapp, when there has been no DONE
- * in between, still only require a single DONE call.
- *
- * For example, the following is valid usage:
- * <code>
- * chreSensorConfigure(myHandle, mode, interval0, latency0);
- * [...]
- * chreSensorConfigure(myHandle, mode, interval1, latency0);
- * [...]
- * chreSensorConfigure(myHandle, mode, interval1, latency1);
- * [...]
- * chreSensorConfigureModeOnly(myHandle, CHRE_SENSOR_CONFIGURE_MODE_DONE);
- * </code>
- *
- * The first call to Configure is the one which creates the requirement
- * to eventually call with DONE. The subsequent calls are just changing the
- * interval/latency. They have not changed the fact that this nanoapp is
- * still interested in output from the sensor 'myHandle'. Thus, only one
- * single call for DONE is needed.
- *
- * There is a special case. One-shot sensors, sensors which
- * just trigger a single event and never trigger again, implicitly go into
- * DONE mode after that single event triggers. Thus, the
- * following are legitimate usages:
- * <code>
- * chreSensorConfigure(myHandle, MODE_ONE_SHOT, interval, latency);
- * [...]
- * [myHandle triggers an event]
- * [no need to configure to DONE].
- * </code>
- *
- * And:
- * <code>
- * chreSensorConfigure(myHandle, MODE_ONE_SHOT, interval, latency);
- * [...]
- * chreSensorConfigureModeOnly(myHandle, MODE_DONE);
- * [we cancelled myHandle before it ever triggered an event]
- * </code>
- *
- * Note that while PASSIVE modes, by definition, don't express an interest in
- * powering the sensor, DONE is still necessary to silence the event reporting.
- * Starting with CHRE API v1.4, for sensors that do not support passive mode, a
- * request with mode set to CHRE_SENSOR_CONFIGURE_MODE_PASSIVE_CONTINUOUS or
- * CHRE_SENSOR_CONFIGURE_MODE_PASSIVE_ONE_SHOT will be rejected. CHRE API
- * versions 1.3 and older implicitly assume that passive mode is supported
- * across all sensors, however this is not necessarily the case. Clients can
- * call chreSensorInfo to identify whether a sensor supports passive mode.
- *
- * When a calibrated sensor (e.g. CHRE_SENSOR_TYPE_ACCELEROMETER) is
- * successfully enabled through this method and if bias delivery is supported,
- * by default CHRE will start delivering bias events for the sensor
- * (e.g. CHRE_EVENT_SENSOR_ACCELEROMETER_BIAS_INFO) to the nanoapp. If the
- * nanoapp does not wish to receive these events, they can be disabled through
- * chreSensorConfigureBiasEvents after enabling the sensor.
- *
- * @param sensorHandle The handle to the sensor, as obtained from
- * chreSensorFindDefault().
- * @param mode The mode to use. See descriptions within the
- * chreSensorConfigureMode enum.
- * @param interval The interval, in nanoseconds, at which we want events from
- * the sensor. On success, the sensor will be set to 'interval', or a value
- * less than 'interval'. There is a special value
- * CHRE_SENSOR_INTERVAL_DEFAULT, in which we don't express a preference for
- * the interval, and allow the sensor to choose what it wants. Note that
- * due to batching, we may receive events less frequently than
- * 'interval'.
- * @param latency The maximum latency, in nanoseconds, allowed before the
- * CHRE begins delivery of an event. This will control how many events
- * can be queued by the sensor before requiring a delivery event.
- * Latency is defined as the "timestamp when event is queued by the CHRE"
- * minus "timestamp of oldest unsent data reading".
- * There is a special value CHRE_SENSOR_LATENCY_DEFAULT, in which we don't
- * express a preference for the latency, and allow the sensor to choose what
- * it wants.
- * Note that there is no assurance of how long it will take an event to
- * get through a CHRE's queueing system, and thus there is no ability to
- * request a minimum time from the occurrence of a phenomenon to when the
- * nanoapp receives the information. The current CHRE API has no
- * real-time elements, although future versions may introduce some to
- * help with this issue.
- * @return true if the configuration succeeded, false otherwise.
- *
- * @see chreSensorConfigureMode
- * @see chreSensorFindDefault
- * @see chreSensorInfo
- * @see chreSensorConfigureBiasEvents
- */
-bool chreSensorConfigure(uint32_t sensorHandle,
- enum chreSensorConfigureMode mode,
- uint64_t interval, uint64_t latency);
-
-/**
- * Short cut for chreSensorConfigure where we only want to configure the mode
- * and do not care about interval/latency.
- *
- * @see chreSensorConfigure
- */
-static inline bool chreSensorConfigureModeOnly(
- uint32_t sensorHandle, enum chreSensorConfigureMode mode) {
- return chreSensorConfigure(sensorHandle,
- mode,
- CHRE_SENSOR_INTERVAL_DEFAULT,
- CHRE_SENSOR_LATENCY_DEFAULT);
-}
-
-/**
- * Convenience function that wraps chreSensorConfigure but enables batching to
- * be controlled by specifying the desired maximum batch interval rather
- * than maximum sample latency. Users may find the batch interval to be a more
- * intuitive method of expressing the desired batching behavior.
- *
- * Batch interval is different from latency as the batch interval time is
- * counted starting when the prior event containing a batch of sensor samples is
- * delivered, while latency starts counting when the first sample is deferred to
- * start collecting a batch. In other words, latency ignores the time between
- * the last sample in a batch to the first sample of the next batch, while it's
- * included in the batch interval, as illustrated below.
- *
- * Time 0 1 2 3 4 5 6 7 8
- * Batch A B C
- * Sample a1 a2 a3 b1 b2 b3 c1 c2 c3
- * Latency [ ] [ ] [ ]
- * BatchInt | | |
- *
- * In the diagram, the effective sample interval is 1 time unit, latency is 2
- * time units, and batch interval is 3 time units.
- *
- * @param sensorHandle See chreSensorConfigure#sensorHandle
- * @param mode See chreSensorConfigure#mode
- * @param sampleInterval See chreSensorConfigure#interval, but note that
- * CHRE_SENSOR_INTERVAL_DEFAULT is not a supported input to this method.
- * @param batchInterval The desired maximum interval, in nanoseconds, between
- * CHRE enqueuing each batch of sensor samples.
- * @return Same as chreSensorConfigure
- *
- * @see chreSensorConfigure
- *
- * @since v1.1
- */
-static inline bool chreSensorConfigureWithBatchInterval(
- uint32_t sensorHandle, enum chreSensorConfigureMode mode,
- uint64_t sampleInterval, uint64_t batchInterval) {
- bool result = false;
-
- if (sampleInterval != CHRE_SENSOR_INTERVAL_DEFAULT) {
- uint64_t latency;
- if (batchInterval == CHRE_SENSOR_BATCH_INTERVAL_DEFAULT) {
- latency = CHRE_SENSOR_LATENCY_DEFAULT;
- } else if (batchInterval > sampleInterval) {
- latency = batchInterval - sampleInterval;
- } else {
- latency = CHRE_SENSOR_LATENCY_ASAP;
- }
- result = chreSensorConfigure(sensorHandle, mode, sampleInterval,
- latency);
- }
-
- return result;
-}
-
-/**
- * Configures the reception of bias events for a specific sensor.
- *
- * If bias event delivery is supported for a sensor, the sensor's chreSensorInfo
- * has reportsBiasEvents set to 1. If supported, it must be supported for both
- * calibrated and uncalibrated versions of the sensor. If supported, CHRE must
- * provide bias events to the nanoapp by default when chreSensorConfigure is
- * called to enable the calibrated version of the sensor (for backwards
- * compatibility reasons, as this is the defined behavior for CHRE API v1.0).
- * When configuring uncalibrated sensors, nanoapps must explicitly configure an
- * enable request through this method to receive bias events. If bias event
- * delivery is not supported for the sensor, this method will return false and
- * no bias events will be generated.
- *
- * To enable bias event delivery (enable=true), the nanoapp must be registered
- * to the sensor through chreSensorConfigure, and bias events will only be
- * generated when the sensor is powered on. To disable the bias event delivery,
- * this method can be invoked with enable=false.
- *
- * If an enable configuration is successful, the calling nanoapp will receive
- * bias info events, e.g. CHRE_EVENT_SENSOR_ACCELEROMETER_BIAS_INFO, when the
- * bias status changes (or first becomes available). Calibrated data
- * (e.g. CHRE_SENSOR_TYPE_ACCELEROMETER) is generated by subracting bias from
- * uncalibrated data (e.g. CHRE_SENSOR_TYPE_UNCALIBRATED_ACCELEROMETER).
- * Calibrated sensor events are generated by applying the most recent bias
- * available (i.e. timestamp of calibrated data are greater than or equal to the
- * timestamp of the bias data that has been applied to it). The configuration of
- * bias event delivery persists until the sensor is unregistered by the nanoapp
- * through chreSensorConfigure or modified through this method.
- *
- * To get an initial bias before new bias events, the nanoapp should get the
- * bias synchronously after this method is invoked, e.g.:
- *
- * if (chreSensorConfigure(handle, ...)) {
- * chreSensorConfigureBiasEvents(handle, true);
- * chreSensorGetThreeAxisBias(handle, &bias);
- * }
- *
- * Note that chreSensorGetThreeAxisBias() should be called after
- * chreSensorConfigureBiasEvents() to ensure that no bias events are lost.
- *
- * If called while running on a CHRE API version below v1.3, this function
- * returns false and has no effect. The default behavior regarding bias events
- * is unchanged, meaning that the implementation may still send bias events
- * when a calibrated sensor is registered (if supported), and will not send bias
- * events when an uncalibrated sensor is registered.
- *
- * @param sensorHandle The handle to the sensor, as obtained from
- * chreSensorFindDefault().
- * @param enable true to receive bias events, false otherwise
- *
- * @return true if the configuration succeeded, false otherwise
- *
- * @since v1.3
- */
-bool chreSensorConfigureBiasEvents(uint32_t sensorHandle, bool enable);
-
-/**
- * Synchronously provides the most recent bias info available for a sensor. The
- * bias will only be provided for a sensor that supports bias event delivery
- * using the chreSensorThreeAxisData type. If the bias is not yet available
- * (but is supported), this method will store data with a bias of 0 and the
- * accuracy field in chreSensorDataHeader set to CHRE_SENSOR_ACCURACY_UNKNOWN.
- *
- * If called while running on a CHRE API version below v1.3, this function
- * returns false.
- *
- * @param sensorHandle The handle to the sensor, as obtained from
- * chreSensorFindDefault().
- * @param bias A pointer to where the bias will be stored.
- *
- * @return true if the bias was successfully stored, false if sensorHandle was
- * invalid or the sensor does not support three axis bias delivery
- *
- * @since v1.3
- *
- * @see chreSensorConfigureBiasEvents
- */
-bool chreSensorGetThreeAxisBias(uint32_t sensorHandle,
- struct chreSensorThreeAxisData *bias);
-
-/**
- * Makes a request to flush all samples stored for batching. The nanoapp must be
- * registered to the sensor through chreSensorConfigure, and the sensor must be
- * powered on. If the request is accepted, all batched samples of the sensor
- * are sent to nanoapps registered to the sensor. During a flush, it is treated
- * as though the latency as given in chreSensorConfigure has expired. When all
- * batched samples have been flushed (or the flush fails), the nanoapp will
- * receive a unicast CHRE_EVENT_SENSOR_FLUSH_COMPLETE event. The time to deliver
- * this event must not exceed CHRE_SENSOR_FLUSH_COMPLETE_TIMEOUT_NS after this
- * method is invoked. If there are no samples in the batch buffer (either in
- * hardware FIFO or software), then this method will return true and a
- * CHRE_EVENT_SENSOR_FLUSH_COMPLETE event is delivered immediately.
- *
- * If a flush request is invalid (e.g. the sensor refers to a one-shot sensor,
- * or the sensor was not enabled), and this API will return false and no
- * CHRE_EVENT_SENSOR_FLUSH_COMPLETE event will be delivered.
- *
- * If multiple flush requests are made for a sensor prior to flush completion,
- * then the requesting nanoapp will receive all batched samples existing at the
- * time of the latest flush request. In this case, the number of
- * CHRE_EVENT_SENSOR_FLUSH_COMPLETE events received must equal the number of
- * flush requests made.
- *
- * If a sensor request is disabled after a flush request is made through this
- * method but before the flush operation is completed, the nanoapp will receive
- * a CHRE_EVENT_SENSOR_FLUSH_COMPLETE with the error code
- * CHRE_ERROR_FUNCTION_DISABLED for any pending flush requests.
- *
- * Starting with CHRE API v1.3, implementations must support this capability
- * across all exposed sensor types.
- *
- * @param sensorHandle The handle to the sensor, as obtained from
- * chreSensorFindDefault().
- * @param cookie An opaque value that will be included in the
- * chreSensorFlushCompleteEvent sent in relation to this request.
- *
- * @return true if the request was accepted for processing, false otherwise
- *
- * @since v1.3
- */
-bool chreSensorFlushAsync(uint32_t sensorHandle, const void *cookie);
-
-#ifdef __cplusplus
-}
-#endif
-
-#endif /* _CHRE_SENSOR_H_ */