[
https://issues.apache.org/jira/browse/MYNEWT-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vipul Rahane updated MYNEWT-828:
--------------------------------
Description:
- Add API for setting threshold based on polling mechanism
- Also allow the API to set thresholds based on interrupts mechanism
- Design is as follows:
i. It adds a list of structures sensor_traits_list to the sensor structure
which keeps track of per type thresholds, oic resources, algorithm, etc. These
thresholds are then compared with the readings from the sensor at the specific
poll rates based on algorithms decided by the developer:
<SENSOR_THRESH_ALGO_WINDOW> and <SENSOR_THRESH_ALGO_WATERMARK>.
<SENSOR_THRESH_ALGO_WINDOW>: Sensor data is compared to thresholds making a
window.
<SENSOR_THRESH_ALGO_WATERMARK>: Sensor data is compared to thresholds based on
watermarks
Notifications are sent if conditions are satisfied as per the above algorithms.
If a set_thresh callback is specified in the driver, this callback will get
called which will enable interrupts based notifications for specific sensor
drivers. An example of this can be seen in
[hw/drivers/sensors/lis2dh12/src/lis2dh12.c](https://github.com/apache/mynewt-core/compare/master...vrahane:sensor_notif?expand=1#diff-18789c89dd99a5f02122ee67a80b82a1).
ii. Syscfg <SENSOR_OIC_PERIODIC>: This is a new syscfg which enables or
disables periodic observation of sensor resources. By default it is enabled in
the sensors test app.
iii. There were two fields added to <struct sensor_itf>: <si_low_pin> &
<si_high_pin> which lets the developer specify the interrupt pins in the bsp
along with the interface and chip select if any.
iv. A lot of functions were added to the lis2dh12 driver to support interrupt
functionality.
(The current interrupt config for lis2dh12 enables the low thresh interrupts
and high thresh interrupts but it somehow only generates an interrupt on a
change in the accelerometer data crossing a threshold instead of generating one
based on threshold regardless, this needs to be investigated further).
was:
- Add API for setting threshold based on polling mechanism
- Also allow the API to set thresholds based on interrupts mechanism
- Design is as follows:
i. It adds a list of structures sensor_traits_list to the sensor structure
which keeps track of per type thresholds, oic resources, algorithm, etc. These
thresholds are then compared with the readings from the sensor at the specific
poll rates based on algorithms decided by the developer:
<SENSOR_THRESH_ALGO_WINDOW> and <SENSOR_THRESH_ALGO_WATERMARK>.
<SENSOR_THRESH_ALGO_WINDOW>: Sensor data is compared to thresholds making a
window.
<SENSOR_THRESH_ALGO_WATERMARK>: Sensor data is compared to thresholds based on
watermarks
Notifications are sent if conditions are satisfied as per the above algorithms.
If a set_thresh callback is specified in the driver, this callback will get
called which will enable interrupts based notifications for specific sensor
drivers. An example of this can be seen in
[hw/drivers/sensors/lis2dh12/src/lis2dh12.c](https://github.com/apache/mynewt-core/compare/master...vrahane:sensor_notif?expand=1#diff-18789c89dd99a5f02122ee67a80b82a1).
ii. Syscfg <SENSOR_OIC_PERIODIC>: This is a new syscfg which enables or
disables periodic observation of sensor resources. By default it is enabled in
the sensors test app.
iii. There were two fields added to <struct sensor_itf>: <si_low_pin> &
<si_high_pin> which lets the developer specify the interrupt pins in the bsp
along with the interface and chip select if any.
iv. A lot of functions were added to the lis2dh12 driver to support interrupt
functionality.
(The current interrupt config for lis2dh12 enables the low thresh interrupts
and high thresh interrupts but it somehow only generates an interrupt on a
change in the accelerometer data, this needs to be investigated further).
> SensorAPI: Sensor OIC notifications/triggers
> --------------------------------------------
>
> Key: MYNEWT-828
> URL: https://issues.apache.org/jira/browse/MYNEWT-828
> Project: Mynewt
> Issue Type: New Feature
> Security Level: Public(Viewable by anyone)
> Reporter: Vipul Rahane
> Assignee: Vipul Rahane
> Fix For: v1_2_0_rel
>
>
> - Add API for setting threshold based on polling mechanism
> - Also allow the API to set thresholds based on interrupts mechanism
> - Design is as follows:
> i. It adds a list of structures sensor_traits_list to the sensor structure
> which keeps track of per type thresholds, oic resources, algorithm, etc.
> These thresholds are then compared with the readings from the sensor at the
> specific poll rates based on algorithms decided by the developer:
> <SENSOR_THRESH_ALGO_WINDOW> and <SENSOR_THRESH_ALGO_WATERMARK>.
> <SENSOR_THRESH_ALGO_WINDOW>: Sensor data is compared to thresholds making a
> window.
> <SENSOR_THRESH_ALGO_WATERMARK>: Sensor data is compared to thresholds based
> on watermarks
> Notifications are sent if conditions are satisfied as per the above
> algorithms.
> If a set_thresh callback is specified in the driver, this callback will get
> called which will enable interrupts based notifications for specific sensor
> drivers. An example of this can be seen in
> [hw/drivers/sensors/lis2dh12/src/lis2dh12.c](https://github.com/apache/mynewt-core/compare/master...vrahane:sensor_notif?expand=1#diff-18789c89dd99a5f02122ee67a80b82a1).
> ii. Syscfg <SENSOR_OIC_PERIODIC>: This is a new syscfg which enables or
> disables periodic observation of sensor resources. By default it is enabled
> in the sensors test app.
> iii. There were two fields added to <struct sensor_itf>: <si_low_pin> &
> <si_high_pin> which lets the developer specify the interrupt pins in the bsp
> along with the interface and chip select if any.
> iv. A lot of functions were added to the lis2dh12 driver to support interrupt
> functionality.
> (The current interrupt config for lis2dh12 enables the low thresh interrupts
> and high thresh interrupts but it somehow only generates an interrupt on a
> change in the accelerometer data crossing a threshold instead of generating
> one based on threshold regardless, this needs to be investigated further).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
