Comments (5)
Most of the NXP MCU boards have on-board motion sensor (Accelerometer or legacy combo sensor Accelerometer + Magnetometer). As per my discussion with Kyle, we think that it extending the sensor interface concept for MCU on-board sensor would also make a good example (we used to support on-board with BB (base board) nomenclature and add-on board with SS (sensor shield)). MCU base SDK also provide a basic on-board sensor example (i2c_accel_value_transfer), please see below references for FRDM-K22F:
As Kyle mentioned, the on-board sensor use I2C pins which may or may not be mapped to Arduino pins (A4, A5 or D14, D15), BB_I2C GPIO pin along with slave/secondary address need to be configured to talk to on-board sensor and ISSDK example would work seamlessly.
Please let us know your view on supporting on-board sensors as well. Most of the new MCU EVKs have FXLS8974CF or pin/SW compatible FXLS8964AF accelerometer as on-board sensor.
from nxp_sensor_sdk.
It should be possible to use on-board sensors too.
The sensor application describes which sensor interfaces it consumes. Interfaces can be provided by the Board, Shield or custom target.
Let's first take a look at the scenario with no multiple instances of the same sensor type.
FRDM-K22F Board + A8974 Shield:
- Board: FXOS8700
- Shield: FXLS8974
FRDM-K22F Board layer:
provides:
- FXOS8700_I2C:
- FXOS8700_INT1:
- FXOS8700_INT2:
FRDM-K22F Header:
#define FXOS8700_I2C_DRIVER I2C_BB_DRIVER /* provided by the Board */
#define FXOS8700_I2C_DEVICE_INDEX I2C_BB_DEVICE_INDEX /* provided by the Board */
#define FXOS8700_I2C_SIGNAL_EVENT I2C_BB_SIGNAL_EVENT /* provided by the Board */
#define FXOS8700_BB_I2C_ADDR 0x1C
#define FXOS8700_BB_INT1 INT1
#define FXOS8700_BB_INT2 INT2
A8974 Shield layer (configuration I2C):
provides:
- FXLS8974_I2C:
- FXLS8974_INT1:
- FXLS8974_INT2:
A8974 Header:
#define FXLS8974_I2C_DRIVER I2C_S_DRIVER /* provided by the Board */
#define FXLS8974_I2C_DEVICE_INDEX I2C_S_DEVICE_INDEX /* provided by the Board */
#define FXLS8974_I2C_SIGNAL_EVENT I2C_S_SIGNAL_EVENT /* provided by the Board */
#define FXLS8974_SPI_DRIVER SPI_S_DRIVER /* provided by the Board */
#define FXLS8974_SPI_BAUDRATE SPI_S_BAUDRATE /* provided by the Board */
#define FXLS8974_SPI_DEVICE_INDEX SPI_S_DEVICE_INDEX /* provided by the Board */
#define FXLS8974_SPI_SIGNAL_EVENT SPI_S_SIGNAL_EVENT /* provided by the Board */
#define FXLS8974_I2C_ADDR 0x18
#define FXLS8974_CS D10
#define FXLS8974_MOSI D11
#define FXLS8974_MISO D12
#define FXLS8974_SCLK D13
#define FXLS8974_INT1 D2
#define FXLS8974_INT2 A0
Application:
consumes:
# FXOS8700
- FXOS8700_I2C:
- FXOS8700_INT1:
# FXLS8974
- FXLS8974_I2C:
- FXLS8974_INT1:
Application typically uses a single sensor and list it under "consumes". It is also possible to use both sensors. However, if sensors are using the same communication interface (ex: I2C0) mapped to the same pins, then exclusive access to the underlying peripheral needs to be ensured. Application could use a mutex when accessing the same driver instance.
Note: Application should only use sensor defines (ex: FXLS8974_...) and not specific Shield or Board defines.
Next, let's take a look at using multiple instances of the same sensor type.
The interface description "consumes/provides" already supports instances.
Example: FXLS8974 on board + FXLS8974 on shield
Board layer: FXLS8974 instance 0
provides:
- FXLS8974_I2C: 0
- FXLS8974_INT1: 0
- FXLS8974_INT2: 0
Shield layer: FXLS8974 instance 1
provides:
- FXLS8974_I2C: 1
- FXLS8974_INT1: 1
- FXLS8974_INT2: 1
Application:
consumes:
# any instance
- FXLS8974_I2C: *
- FXLS8974_INT1: *
# or instance 0
- FXLS8974_I2C: 0
- FXLS8974_INT1: 0
# or instance 1
- FXLS8974_I2C: 1
- FXLS8974_INT1: 1
Probably using a single instance at the same time is the most common use case. In such case the existing defines (without instance notation) would need to be mapped to the desired instance.
If both instances should be used at the same time, then defines would need to be extended with instance numbers.
Example:
#define FXLS8974_0_I2C_ADDR 0x1C
#define FXLS8974_1_I2C_ADDR 0x18
from nxp_sensor_sdk.
Thanks for considering extending this concept for on-board sensor. Ideally there shouldn't be conflict in I2C address for on-board vs shield sensor. Even if same sensor is available on-board and on shield, ideally SA0 or SA1 I2C addresses selection would allow talking to both (but you are correct, in such scenario it would be recommended to use either on-board or shield sensor). But extending this concept for MCU on board sensor would allow flexibility to end user to choose whether to use on-board sensor if available or use shield sensor.
from nxp_sensor_sdk.
I believe this ticket can be closed since on-board sensors are also supported within this concept.
from nxp_sensor_sdk.
It will be good to have an example for on board sensor enabled using this concept.
from nxp_sensor_sdk.
Related Issues (7)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nxp_sensor_sdk.