Many sensors support both i2c and SPI though which might pose a problem or oblige you to have two drivers, one for each bus?
Le jeudi 10 novembre 2016, David G. Simmons <[email protected]> a écrit : > 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] > <javascript:;>> 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. > > >
