I2C support by the boards

[KostyaEsmukov]

Hello,

In order to refactor the call_bar plugin, which uses I2C, I need to implement I2C program interface on devices.

We need to come up with a unified API exposed by devices which could be implemented on any I2C-supporting device. At least we should take into account:

• arduino-linio;
• Raspbery PI;
• Intel Edison.

As I2C devices are actually Linux dev nodes (i.e. /dev/i2c-1) we may try to use some generic package like i2c and barely expose it's instance. It will be easier in support, but I'm personally against this approach, because some board-specific workarounds might be required in some cases, which might be not possible to be handled easily. But if you are sure that this is not the case, then this is probably the most convenient option.

Another approach is to use board-specific I2C bindings. For example:

• arduino-linio: https://github.com/ideino/ideino-linino-lib/blob/master/board.js
• Raspbery PI: https://www.npmjs.com/package/i2c-bus
• Intel Edison: https://www.npmjs.com/package/i2c-bus

The problem here is ideino-linino-lib-related actually, because it provides very poor I2C interface.
More specific:

1. synchronous read always reads exactly 6 bytes and tends to return only floats from string representation of data. Thus it's not possible to synchronously read some specific amount of raw data.
2. there's a driver field , though none of nodejs I2C packages(see below) mention any kind of drivers. It seems to be unused by ideino-linino-lib internally too.

So, here are the options:

1. Use some generic I2C package
2. Use board-specific I2C packages and provide our own interface
   1. change ideino-linino-lib's interface making it more similar to other I2C wrappers (i.e. get rid of driver and expose raw synchronous read)
   2. provide the same poor interface on our side (with that unused driver field and with synchronous read returning only floats from 6 text bytes)

I can't make this decision by myself, because I have no rich experience with I2C bus on different boards, so I ask you to decide.

npm I2C wrappers

https://www.npmjs.com/package/i2c
https://www.npmjs.com/package/rasp2c
https://www.npmjs.com/package/i2c-bus

[flongo82]

Hi Kostya,
as I mention in another bug the abstraction layer of which you are talking about should be implemented through Stack4Things drivers. The call_bar plugin is just an example. I would say do not waste time on refactoring it.

What we can do instead is to produce an example of driver that abstracts the bar sensor and then write a plugin that uses it.

Maybe @npeditto can help on that.

There should already be an example of driver somewhere. If I'm not wrong about a temperature sensor.

[KostyaEsmukov]

Hi Francesco,

Thank you for your response.

Ok, that makes sense. I haven't looked at the drivers part of the LR yet, so this would hang open for a while.