I would actually go about this slightly differently ... All of these sensors come in, typically, one flavor. So there are SPI-based sensors, and ADC-based sensors, etc. Grouping them by the bus they use makes a certain amount of sense to me.
Hw/drivers/SPI/... hw/drivers/ADC/... ... That way I know that if I have a SPI-based sensor, I know exactly where to look for the driver for that sensor. This may also come in handy when we look at the other side of peripherals, actuators. hw/drivers/servo/... hw/drivers/pwm/... hw/drivers/stepper/... This avoids the problem of a sensor that is has an accelerometer AND a magnetometer as they will typically both use the same bus. In the case of sensors that can use, say, I2C or SPI, you'd need 2 drivers anyway, so rather than having /hw/drivers/sensors/bno055/spi/ and /hw/drivers/sensors/bno055/I2C you'd have a bno055 driver in both the /hw/drivers/SPI and /hw/drivers/I2C areas. Hope that makes sense. dg > On Nov 9, 2016, at 8:59 PM, Kevin Townsend <[email protected]> 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 ? > > 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/* > > 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. > > 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. > -- David G. Simmons (919) 534-5099 Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_blog> • Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter <http://twitter.com/TechEvangelist1> • GitHub <http://github.com/davidgs> /** Message digitally signed for security and authenticity. * If you cannot read the PGP.sig attachment, please go to * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your email!!! * Public key available at keyserver.pgp.com <http://keyserver.pgp.com/> **/ ♺ This email uses 100% recycled electrons. Don't blow it by printing! There are only 2 hard things in computer science: Cache invalidation, naming things, and off-by-one errors.
