> On Nov 10, 2016, at 9:01 AM, Kevin Townsend <[email protected]> wrote: > > >> 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. > Missed this when I replied on my phone, sorry. > > I can see the argument here, but to be honest I would rather maintain 1 > driver that support both I2C and SPI simply because there is still a lot of > overlapping code above the transport. Registers, data conditioning, etc., and > there is a non neglible risk with two drivers that bugs get fixed in one > driver but not the other.
All true, no argument here. But are you proposing that a driver for a sensor that has both I2C and SPI interfaces would be a single driver? While I agree that will reduce the complexity of supporting such sensors, won't it also increase the size of those drivers to a (possibly prohibitive) degree? Again, no right answer that I can see, just asking the question. > That said ... there isn't a clear right answer here. I'm worried about what > happens when you have 40-50 drivers in a flat folder, which is entirely > realistic over time since embedded generally = sensors, although that still > feels like the only solution that doesn't run into problems quickly > separating files by functionality or bus. > > hw/drivers/sensors/<manufacturer>/<sensors_name> will reduce this to a > certain extent. > > Another question is what about chips that aren't technically sensors: > > * Motor drivers > * Display drivers or integrated displays (SSD1306, ILI9341, etc.) Right, these are the things I classified as 'actuators'. Servos, stepper Motors, linear actuators, display drivers, piezos, etc. > These are all commonly used in embedded systems. > > > Perhaps a parent`ic` folder is a better label than 'sensors', so: > > * hw/drivers/ic/display/ssd1306 > * hw/drivers/ic/sensors/tls2561 > * hw/drivers/ic/sensors/bno055 > * hw/drivers/ic/motor/drv2605l > > You don't want to end up with something 10 layers deep, but I think it is > important to keep this clean and well organised since it is bound to be a key > part of the system moving forward, although I expect a lot of drivers will be > stored outside the core repo of course. +1, though I fear that we end up with "clean, well organized and not 10 layers deep. Pick 2" :-) dg -- 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.
