9 years, 4 months ago.

Is there a common API (interface) for different sensors that is used in mbed?

We are connecting multiple different sensors to ARM based CortexM0 CPU for real time monitoring of environment and later doing some computation based on those data or storing it. We decided to use mbed as a base platform for developing our firmware.

Right now we already have sensors for motion detection: ADXL362, MPU9250; barometric pressure: MS5611,MS5803, BMP280; ECG monitoring ADS1292. Right now all of our sensors are communicating through SPI but we consider exchangebility of communication protocol as an important feature of the API.

As we investigate protocols all of them have a common functionality but different business value. So we think it will be good to have it abstracted into design. Other important thing is that most of them have already libraries for them but without any specific API which makes it hard to incorporate it to our software.

Is there some work in mbed that we can based our API design on?

Do you think that this kind of API in import or necessary to be defined in mbed ecosystem?

3 Answers

9 years, 4 months ago.

There is something going in this direction: look at https://github.com/adafruit/Adafruit_Sensor

Accepted Answer

There is also similar discussion if it is worth or not to have some common layer in the thread under that repository: https://github.com/adafruit/Adafruit_Sensor/issues/2

Thanks for sharing that. I will base my API on that and we will see if it founds any acceptance in mbed community.

posted by Marek Smigielski 21 Jan 2015

I agree with that issue report, hardcoding the different options like the code currently does is bad imo. General code based on number of dimensions would be better. Although I think it will continue to be a challenge.

Also before finalizing it, please make a topic about it, then people can give some feedback :).

posted by Erik - 21 Jan 2015
9 years, 4 months ago.

The only API's in the Mbed system are for the integrated peripheral parts of the MCU.

Anything else externally connected will need it's relevant library to be added to your program code. This is because individual devices, although sharing common interface protocols will have different communication and operational set up's.

Simply add the library for the device you want to use. There are many available on Mbed, just search the device and pick the one that looks good for you.

Consider following example, we have three different sensors for barometric pressure that we want to try out and our firmware have to be adopted individual for each. As you know it is possible but not really convenient.

I have strong java background and I am thinking to what extend concept like dependency injection or loose coupling are available here, in mbed world.

posted by Marek Smigielski 20 Jan 2015

Well if you can convince the component designers and manufacture's to 'standardise' digital interface protocols then it would be possible.

It's never happened and I can't see it happening in the future otherwise that would impede future development.

Todays devices will be forgotten by tomorrow, so who will keep the API up to date?

However it certainly would be convenient to have a sensor API and Display API, etc.

posted by Paul Staron 20 Jan 2015
9 years, 4 months ago.

You mean you want a general API for sensors? I know it was tried briefly, you can of course always propose one and ask that owners of the sensor libraries use them, but then you first need to have a good idea what such an API would provide. I can't imagine for example a single API for both an accelerometer, pressure sensor and ECG sensor.

Yes, that is something I am thinking of.

For me all of this sensors produce numbers in several dimensions. Simple accelerometer produce 3dimensional time series, sensors like MPU9250 - 9 dimensions (3 for each sensor) and ECG that is the number of dimension there is channels provided by your sensor i.e. ADS1292 provides two channels so two dimensions.

Common steps are setup of the sensor, it can be parametrised differently for different hardware, self test procedure, access to incoming data.

posted by Marek Smigielski 20 Jan 2015