2
0
mirror of synced 2025-02-23 23:08:14 +00:00
mobile/sensor/sensor_notandroid.go

35 lines
663 B
Go
Raw Normal View History

mobile/sensor: initialize the sensor package Sensors package will contain APIs to read data from a wide variety of movement, position and other physical signals. This CL contains the initial APIs that are targeting event-based sensors. Some of the concerns that influenced the APIs are: - Target game developers. Latency is critical, allow output rates up to ~10 samples per second. - It’s rarely possible to predetermine the minimally viable sample rate requirement of the app. - Allow users to set an upper bound rate to avoid garbage and preserve battery life. - Allow multiple instances of accelerometer, gyroscope, magnetometer and altimeter sensors to be started. Optimize the share of the underlying resources as long as it is not a bottleneck for the sample rate. - Prefer blocking APIs. An automatic poll-timeout could be useful if we’re far behind the sample rate. But, sensor initialization and waking-up significantly take longer and there is no easy way to determine a sensor is in either one of these states. - Provide timestamps for each event to determine the actual rate of the sensor data. - Allow user to return multiple events from each call. Buffering the events at the cost of additional latency is sometimes more neglectable than the overhead of a function call that polls the events one by one. Allow user to determine how many items they want to buffer. The typical latency of a read a single event is 56 usec. Reading 8-16 events at once has a relatively lower bound per event. For high precision throughput, the opportunity to minimize a function call overhead could be useful. - Allow users to check the sensor availability on the device. Change-Id: I9582c8f025d9f922d9635e247d60817f95bdacb9 Reviewed-on: https://go-review.googlesource.com/8174 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-27 14:53:09 -07:00
// Copyright 2015 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// +build !android
package sensor
import (
"errors"
"time"
)
mobile/sensor: initialize the sensor package Sensors package will contain APIs to read data from a wide variety of movement, position and other physical signals. This CL contains the initial APIs that are targeting event-based sensors. Some of the concerns that influenced the APIs are: - Target game developers. Latency is critical, allow output rates up to ~10 samples per second. - It’s rarely possible to predetermine the minimally viable sample rate requirement of the app. - Allow users to set an upper bound rate to avoid garbage and preserve battery life. - Allow multiple instances of accelerometer, gyroscope, magnetometer and altimeter sensors to be started. Optimize the share of the underlying resources as long as it is not a bottleneck for the sample rate. - Prefer blocking APIs. An automatic poll-timeout could be useful if we’re far behind the sample rate. But, sensor initialization and waking-up significantly take longer and there is no easy way to determine a sensor is in either one of these states. - Provide timestamps for each event to determine the actual rate of the sensor data. - Allow user to return multiple events from each call. Buffering the events at the cost of additional latency is sometimes more neglectable than the overhead of a function call that polls the events one by one. Allow user to determine how many items they want to buffer. The typical latency of a read a single event is 56 usec. Reading 8-16 events at once has a relatively lower bound per event. For high precision throughput, the opportunity to minimize a function call overhead could be useful. - Allow users to check the sensor availability on the device. Change-Id: I9582c8f025d9f922d9635e247d60817f95bdacb9 Reviewed-on: https://go-review.googlesource.com/8174 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-27 14:53:09 -07:00
type manager struct {
}
func (m *manager) initialize() {
mobile/sensor: initialize the sensor package Sensors package will contain APIs to read data from a wide variety of movement, position and other physical signals. This CL contains the initial APIs that are targeting event-based sensors. Some of the concerns that influenced the APIs are: - Target game developers. Latency is critical, allow output rates up to ~10 samples per second. - It’s rarely possible to predetermine the minimally viable sample rate requirement of the app. - Allow users to set an upper bound rate to avoid garbage and preserve battery life. - Allow multiple instances of accelerometer, gyroscope, magnetometer and altimeter sensors to be started. Optimize the share of the underlying resources as long as it is not a bottleneck for the sample rate. - Prefer blocking APIs. An automatic poll-timeout could be useful if we’re far behind the sample rate. But, sensor initialization and waking-up significantly take longer and there is no easy way to determine a sensor is in either one of these states. - Provide timestamps for each event to determine the actual rate of the sensor data. - Allow user to return multiple events from each call. Buffering the events at the cost of additional latency is sometimes more neglectable than the overhead of a function call that polls the events one by one. Allow user to determine how many items they want to buffer. The typical latency of a read a single event is 56 usec. Reading 8-16 events at once has a relatively lower bound per event. For high precision throughput, the opportunity to minimize a function call overhead could be useful. - Allow users to check the sensor availability on the device. Change-Id: I9582c8f025d9f922d9635e247d60817f95bdacb9 Reviewed-on: https://go-review.googlesource.com/8174 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-27 14:53:09 -07:00
}
func (m *manager) enable(t Type, delay time.Duration) error {
return errors.New("sensor: no sensors available")
mobile/sensor: initialize the sensor package Sensors package will contain APIs to read data from a wide variety of movement, position and other physical signals. This CL contains the initial APIs that are targeting event-based sensors. Some of the concerns that influenced the APIs are: - Target game developers. Latency is critical, allow output rates up to ~10 samples per second. - It’s rarely possible to predetermine the minimally viable sample rate requirement of the app. - Allow users to set an upper bound rate to avoid garbage and preserve battery life. - Allow multiple instances of accelerometer, gyroscope, magnetometer and altimeter sensors to be started. Optimize the share of the underlying resources as long as it is not a bottleneck for the sample rate. - Prefer blocking APIs. An automatic poll-timeout could be useful if we’re far behind the sample rate. But, sensor initialization and waking-up significantly take longer and there is no easy way to determine a sensor is in either one of these states. - Provide timestamps for each event to determine the actual rate of the sensor data. - Allow user to return multiple events from each call. Buffering the events at the cost of additional latency is sometimes more neglectable than the overhead of a function call that polls the events one by one. Allow user to determine how many items they want to buffer. The typical latency of a read a single event is 56 usec. Reading 8-16 events at once has a relatively lower bound per event. For high precision throughput, the opportunity to minimize a function call overhead could be useful. - Allow users to check the sensor availability on the device. Change-Id: I9582c8f025d9f922d9635e247d60817f95bdacb9 Reviewed-on: https://go-review.googlesource.com/8174 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-27 14:53:09 -07:00
}
func (m *manager) disable(t Type) error {
return errors.New("sensor: no sensors available")
mobile/sensor: initialize the sensor package Sensors package will contain APIs to read data from a wide variety of movement, position and other physical signals. This CL contains the initial APIs that are targeting event-based sensors. Some of the concerns that influenced the APIs are: - Target game developers. Latency is critical, allow output rates up to ~10 samples per second. - It’s rarely possible to predetermine the minimally viable sample rate requirement of the app. - Allow users to set an upper bound rate to avoid garbage and preserve battery life. - Allow multiple instances of accelerometer, gyroscope, magnetometer and altimeter sensors to be started. Optimize the share of the underlying resources as long as it is not a bottleneck for the sample rate. - Prefer blocking APIs. An automatic poll-timeout could be useful if we’re far behind the sample rate. But, sensor initialization and waking-up significantly take longer and there is no easy way to determine a sensor is in either one of these states. - Provide timestamps for each event to determine the actual rate of the sensor data. - Allow user to return multiple events from each call. Buffering the events at the cost of additional latency is sometimes more neglectable than the overhead of a function call that polls the events one by one. Allow user to determine how many items they want to buffer. The typical latency of a read a single event is 56 usec. Reading 8-16 events at once has a relatively lower bound per event. For high precision throughput, the opportunity to minimize a function call overhead could be useful. - Allow users to check the sensor availability on the device. Change-Id: I9582c8f025d9f922d9635e247d60817f95bdacb9 Reviewed-on: https://go-review.googlesource.com/8174 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-27 14:53:09 -07:00
}
func (m *manager) read(e []Event) (n int, err error) {
return 0, errors.New("sensor: no sensor data available")
}
func (m *manager) close() error {
return nil
mobile/sensor: initialize the sensor package Sensors package will contain APIs to read data from a wide variety of movement, position and other physical signals. This CL contains the initial APIs that are targeting event-based sensors. Some of the concerns that influenced the APIs are: - Target game developers. Latency is critical, allow output rates up to ~10 samples per second. - It’s rarely possible to predetermine the minimally viable sample rate requirement of the app. - Allow users to set an upper bound rate to avoid garbage and preserve battery life. - Allow multiple instances of accelerometer, gyroscope, magnetometer and altimeter sensors to be started. Optimize the share of the underlying resources as long as it is not a bottleneck for the sample rate. - Prefer blocking APIs. An automatic poll-timeout could be useful if we’re far behind the sample rate. But, sensor initialization and waking-up significantly take longer and there is no easy way to determine a sensor is in either one of these states. - Provide timestamps for each event to determine the actual rate of the sensor data. - Allow user to return multiple events from each call. Buffering the events at the cost of additional latency is sometimes more neglectable than the overhead of a function call that polls the events one by one. Allow user to determine how many items they want to buffer. The typical latency of a read a single event is 56 usec. Reading 8-16 events at once has a relatively lower bound per event. For high precision throughput, the opportunity to minimize a function call overhead could be useful. - Allow users to check the sensor availability on the device. Change-Id: I9582c8f025d9f922d9635e247d60817f95bdacb9 Reviewed-on: https://go-review.googlesource.com/8174 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-27 14:53:09 -07:00
}