Although having the family in the path would have been nice but it seems as though the sensors performing multiple functions could be confusing.
so, +1 for either "hw/drivers/sensors/<manufacturer>/<sensor_name>” and "hw/drivers/sensors/<sensor_name>”. Reference drivers are nice to have. Meta-data and SI units can be part of the description in each package but conversion factors could be sys cfg settings. Regards, Vipul Rahane > On Nov 9, 2016, at 7:03 PM, will sanfilippo <wi...@runtime.io> wrote: > >> >> On Nov 9, 2016, at 5:59 PM, Kevin Townsend <ke...@adafruit.com >> <mailto:ke...@adafruit.com>> wrote: >> >> There are no sensor drivers in the system at present, but now that the HAL >> rework is complete I wanted to port a few drivers over to Mynewt just to >> properly test the HW and HAL out. Existing sensor drivers is one of the key >> factors to draw people into any embedded RTOS/system, so I think it's >> important to get this right to pull people into the Mynewt ecosystem. >> >> I'm curious what kind of organization would make the most sense moving >> forward, though. Assuming some drivers are included in the core mynewt repo >> instead of being in independent libraries, what would be an ideal root >> location to place them in the file structure? >> >> - hw/drivers/sensors ? >> > +1 this is where I would put them >> The problem is that hw/drivers already has things like adc and uart >> implementations or nimble which is quite a different concept, though it's >> not entirely inappropriate all the same. >> >> And inside sensors (or wherever) you'll have another problem: should you >> have a single flat list of all drivers by device name, or do you want to >> organize them by type/manufacturer/etc.: >> >> * hw/drivers/sensors/bmp085/* >> * hw/drivers/sensors/bmp280/* >> * hw/drivers/sensors/tsl2651/* >> * hw/drivers/sensors/lsm303dlhc/* >> * hw/drivers/sensors/bno055/* >> > +1 although manufacturer is OK as well. I dont like by family but dont have > really strong feelings. > >> Or do you want to organize them by family (which is nice in some ways but >> very awkward in others with certain SoCs): >> >> * hw/drivers/sensors/pressure/bmp085/* >> * hw/drivers/sensors/pressure/bmp280/* >> * hw/drivers/sensors/light/tsl2561/* >> * hw/drivers/sensors/accelerometers/lsm303dlhc/* <-- This is also a >> magnetometer! >> * hw/drivers/sensors/orientation???/bno055/* <-- this is an accel, mag >> and gyro with sensor fusion for orientation >> >> Or does manufacturer make more sense: >> >> * hw/drivers/sensors/bosch/bmp085/* >> * hw/drivers/sensors/bosch/bmp280/* >> * hw/drivers/sensors/bosch/bno055/* >> * hw/drivers/sensors/taos/tsl2561/* <-- Complicated since Taos was >> purchased and is now AMS, which is a recurring theme these days >> * hw/drivers/sensors/st/lsm303dlhc/* >> >> It would likely be useful to have some sort of basic meta-data as well about >> the sensor types since some ICs can contain multiple sensors, such as the >> bmp280 being a pressure sensor but also having temperature data, or the >> lsm303dlhc being a 3 axis accelerometer and magnetometer. This meta-data >> isn't critical, but could be useful as a filter at some point using the newt >> tool or the newt 'newt vals' type functionality. >> >> Adding drivers to the core repo is problematic in that it creates a >> maintenance burden, but I think drivers are also a huge pull for people to >> use the system and an important reference to keep up to date with changes in >> the HAL over time. There should at least be one reference for each bus like >> I2C, SPI, ADC and UART (GPS etc.) that makes use of the power management >> API, etc. Having a maintained reference driver will reduce support >> requirements long term, and ensure best practices are followed by people >> contributing other drivers in the future. >> > +1 for reference drivers in core repo. Hopefully these are not a huge > maintenance burden. We should pick these wisely though. >> Kevin >> >> PS: Some sort of sensor API is also worth considering to have a common data >> type and standard SI units and meta-data for all sensors (min/max data >> values, output speed, etc.), but that's another discussion entirely.
