Use of ISSDK Middleware with On-board Sensor

[purdurnr]

Amit and I discussed using this solution for the same sensors that are on an evk board.
The evk should show existence of sensor. (ss_* is Shield board; bb_* is base board)

This actually shows the 3rd scenario that was presented with customer board Layer file.
It would have unique Int and interface outside of Arduino.
This will be a good example to provide in the pack. Showing how sensor is captured in layer file on Shield vs. Board.
Board Layer YAML could provide #Arduino interface. However, it could also have "provides FXLS8974_I2C and FXLS8974_INT1".

• Possible conflict in build?
• Would user be capable of creating solution with 2 instances of 8974? 2 sensors, 1 from board and 1 from shield
• Would user be able to resolve conflicts or select amongst 2 options? Error, 2 sources found for FXLS8974_I2C. They comment out or select to resolve?

[APurohit10]

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:

• FRDM-K22F SCH:
  

• FRDM-K22F MCUXpresso SDK on-board sensor example:
  

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.

[RobertRostohar]

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

[APurohit10]

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.

[RobertRostohar]

I believe this ticket can be closed since on-board sensors are also supported within this concept.

[APurohit10]

It will be good to have an example for on board sensor enabled using this concept.