Common accelerometer/magnetometer/etc API

[gfwilliams]

Posted at 2020-10-06 by @gfwilliams

Hi!

As there are more Espruino boards with sensors on them like accelerometers (Puck.js, Bangle.js, RAK boards, Micro:bit, etc) it's seeming like more of a problem that each one has its own sensor API.

If you're writing code for one device it's not a big deal, but I've been looking into an Espruino App Loader like the Bangle.js one, and it'd be nice if one single app could work across a bunch of different devices... Not to mention the ability to have a single block for graphical programming, or the benefits of having a tutorial be usable on any device.

Does anyone have any thoughts about this? Perhaps the easiest solution might be to have a lightweight module which converted all the different APIs into one coherent API - for instance Device.*.

Or, I could add the common API to all new firmwares and deprecate the old API. However on some devices we're a bit short on space and it could be problematic. Not to mention the fact that a lot of devices are used with the firmware they come with and not updated.

[espruino-discuss3]

Posted at 2020-10-08 by opichals

Hi Gordon!

Just for inspiration http://johnny-five.io/api/ seems to have a nice sensor-type generic APIs with a wide range of supported parts for each.

Also the Android HAL APIs might be interesting to look at https://source.android.com/devices/sensors/sensor-types.

Standa

---

Posted at 2020-10-09 by @gfwilliams

Thanks! There's some interesting stuff there. Actually having something like:

Device.accel.enable();
Device.accel.on('data', function(xyz) { ... });

Does sound nicer than the current solution of:

Device.accelOn();
Device.on('accel', function(xyz) { ... });

Also reporting 'raw' sensor data like Android (as well as processed data in proper units) sounds good.

I guess one question is whether we artificially split things like the Gyro (which is usually in the same chip as the accelerometer and would give data at the same time) off into their own classes with their own events. I guess it's more flexible, but worse for the programmer.

---

Posted at 2020-10-09 by @gfwilliams

Just as a reference, things I think we could add to a global Device (or maybe just HW for hardware?):

• getFeatures() - return a list of features the device has
• accelerometer
• gyro
• compass
• GPS
• LCD/TFT (just a link to Graphics?)
• LCD backlight
• touchscreen
• vibration
• speaker
• microphone?
• turn off
• ...?

And make it so you could extend it with JS - for instance to add a speaker to a Pixl or something like that.

---

Posted at 2020-10-09 by parasquid

Device.getFeatures() would be really useful :) I'm guessing modules would then eventually be written to "add" themselves to the device list? And also be written to have a generic api to return raw values in addition to "cooked" values.

---

Posted at 2020-10-09 by opichals

I wouldn't worry about the separate APIs for parts that provide both. And even that could I guess be done by providing the 'raw' data and allow external use of the raw -> units 'parsing' functionality somehow.

---

Posted at 2020-10-09 by opichals

To add an example of providing board independent abstractions for app logic (not just sensors but also actuators):

At one point I created LED.turnOn() and LED.turnOff() methods which depending on the board write 1 or 0 to the LEDx Pin depending on the wiring.

---

Posted at 2020-10-14 by @gfwilliams

I think for now given the potential headaches around this I'll make a JS library HW to abstract the board-specific stuff, and then when we're happy with the API I can look at building it in later - then the library should still be available to provide support on older firmwares.