Adafruit has always prided itself on going the extra mile. We always try to provide the the best breakouts possible, but we also put that extra bit of effort into making sure we have a driver for each of those products as well. You want to get started with your new HW as soon as you pull it out of that box … we’re happy to try to make that possible to the best extent that we can! Call it the Adafruit Difference. 🙂
That said … writing all those drivers can be pretty time consuming, and then you need to add some example code on top of them to show how the driver works. While I was digging around inside the Android source code for something different, I noticed the intelligent way they abstract away all sensor data down to a single C typedef. The dial went straight to 11 in my head, and the first thing I thought was: ‘why am I not doing this?!?’. I pulled out an MCU and tried to adapt the Android code (conveniently written in C), slimming the typedefs down a bit, adding a couple sensor types, … but keeping the same general structure. After a bit of trial and error, the Adafruit Unified Sensor Driver was born. Driver use and development will never be the same (at least for me)!
We have a reasonably complete tutorial on how the Unified Sensor Driver System works … but you can also have a look at the source code for Adafruit_Sensor on github. In a nutshell what does this do, though? Essentially, it takes any supported sensor type (accelerometers, gyroscopes, pressure sensors, light sensors, etc.) and converts the raw units used by the system (0..1023) into standard SI units on a specific scale. Every accelerometer using the system will report acceleration in m/s^2, pressure sensors will all use hectoPascal (hPa), light sensors use SI lux units, etc.! No more 0..1023 … you get units you understand out of the box and every time!
Don’t know which accelerometer to use, or what speed or resolution you need? No problem … start with whatever you’ve got, and you can just drop in any other ‘Unified’ sensor later. You’ll get exactly the same SI unit types and scales, call the same two functions, and all you need to change in the single line constructor! No more out of stock headaches … just take any other similar sensor and use that as a stand-in, and you don’t have to relearn a whole new driver and set of functions.
But have a look at the learning guide, the source code, and try it out if you have a product that currently has a ‘Unified’ drivers (there’s a list here). And above all, let us know what you think and what can be improved. This is still a bit of an experiment for us, but it definitely feels like the right direction to move things!
Looks cool, look forward to trying it, though I hope it doesn’t mean there will no longer be sensor-specific examples.
For instance, sometimes 0-1023 data is enough and doesn’t need to be converted to units, in applications where the sensor is modulating something else (light or music outputs, for example).
Still curious to try it out all the same!
AO: You still have the underlying functions (0..1023, etc.) since you need to implement them anyway to do anything useful, and you’re of course still free to call them … this is just another layer that sits on top to standardise things.