I2C BLE service

[sandeepmistry]

Hi,

Are there any plans on creating a BLE service for I2C?

I've been working on a [Johny-Five}(http://johnny-five.io) IO plugin for the micro:bit and have been able to bridge most of the existing BLE services that the micro:bit has to the J5 API. More details on this here: https://github.com/sandeepmistry/node-bbc-microbit-io

It would be very cool to bridge the remaining I2C API's in the IO plugin to unlock more J5 external h/w support.

I can definitely go ahead and create my own custom service using mbed, however wanted to see if this was on the roadmap before starting.

[jamesadevine]

@sandeepmistry Very cool stuff! :smile:

I completely agree about the integration of some form of I2C service over bluetooth, that would be cool.

I think there are questions around how this would integrate into the runtime. Certainly with a large majority of the services in the runtime at present, there is very little coupling between user land and system land. With I2C, this is a little different as it is used by both user and system threads.

For example, lets say the background thread is writing a new configuration to the accelerometer and at the exact time a Bluetooth interrupt begins writing to another I2C component, this would have two effects:

1) the accelerometer will likely be left in an undefined state 2) the operation requested by the user would likely never complete.

So perhaps a more detailed discussion about an approach here would be useful!

My gut instinct is to provide some basic mutex locking here, but it is unclear how that would work with Bluetooth in the mix. :smiley:

@finneyj @bluetooth-mdw

[finneyj]

@sandeepmistry @jamesadevine

No plans in the pipeline for I2C over BLE (but it would be a great addition). @bluetooth-mdw would know if there are any standard BLE services for this, but I suspect not, so adding a new service in here would be most welcome.

@jamesadevine is quite right though - such a service can't assume total ownership of the I2C interface. The interface on the pins is the same as is used on the main board to interface with the accelerometer and magnetometer. if we can decouple the read/write operations via a fiber, that would be fine though, as this alone would guarantee mutual exclusion.

You could considers decoupling this by sending yourself an event. This is easy, and essentially acts like a delayed procedure call with the default parameters. I did something similar in the Magnetometer service:

https://github.com/lancaster-university/microbit-dal/blob/master/source/bluetooth/MicroBitMagnetometerService.cpp#L84

https://github.com/lancaster-university/microbit-dal/blob/master/source/bluetooth/MicroBitMagnetometerService.cpp#L96

https://github.com/lancaster-university/microbit-dal/blob/master/source/bluetooth/MicroBitMagnetometerService.cpp#L128

p.s. Thanks for the node.js support @sandeepmistry - awesome stuff! :-)

[ghost]

There's no standard i2c service.