You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Kevin Townsend <ke...@adafruit.com> on 2016/11/10 01:59:13 UTC
Sensor Drivers and File Location
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.
Re: Sensor Drivers and File Location
Posted by Kevin Townsend <ke...@adafruit.com>.
Hi Sterling,
I think this makes a lot of sense and the API is critical here. I
definitely agree with the comments below that starting with the API is
the right place. Being able to interrogate devices would also be very
valuable, as well as some high level system to control sampling rates,
power management, etc.
I really need to test out the I2C and SPI pins on our board so we can go
into production, so I'll put a couple hacky drivers together for some
common sensors for now just to play with the I2C and SPI HAL.
Let me know when you're back from London and I'll get you setup at
Runtime with some common sensors since it's always useful to test this
against real devices. I'm happy to contribute drivers, but if everyone
has a set of a few common sensors it's nice to be able to make sure the
ideas match reality.
I definitely have quite a few thoughts on what a sensor API should look
like to maintain generic data across similar sensor types so that all
accelerometers return standards SI units like m/s2, magnetometers return
uTesla, etc., though I've never used OIC so I'll have to do some digging
there first.
K.
On 10/11/16 16:42, Sterling Hughes wrote:
> Hi Kevin,
>
> I have some thoughts, but I\u2019m not sure they all directly address your
> concerns :-)
>
> More details on directory re-org and drivers below, but I wanted to
> mention upfront: I really think its worth thinking through the sensor
> api you mention in your PS, and then doing the directory org after
> that. Because I would imagine that these drivers fit directly into
> that API, which I think is crucially important. It would be really
> good to understand whether that API was sufficient for 99% of use
> cases as well, because if so, we would just want to have the
> implementations map into that API.
>
> Additionally, I wanted to mention, that a worthy goal here would be to
> make these sensors discoverable, in a way that can be mapped into
> OIC. One of the nice things about OIC is that it supports
> standardized resource discovery, and I think it would be awesome,
> especially for Maker applications, if you could connect to a device
> with a phone, and automatically get a list of sensors available, and
> interact with them. If we make sure that the sensor APIs are
> introspectable, this should be easy to do.
>
> I also want to point out how we\u2019ve done certain drivers, like the ADC
> driver. Essentially, we have a top-level package, \u201cadc\u201d, which
> contains the interface for all ADC drivers, and then we have the
> individual implementation of the driver itself. The following source
> files point to this:
>
> * high-level ADC API: hw/drivers/adc/include/adc/adc.h
> - note: 2 interfaces defined here. The driver implementation
> interface: adc_driver_funcs, and the user interface calls.
>
> * implementation of ADC for NRF52:
> hw/drivers/adc/adc_nrf52/src/adc_nrf52.c
> - note: only exported call is int nrf52_adc_dev_init(struct os_dev
> *, void *), which is passed as a function pointer to os_dev_create()
> in hal_bsp.c, when the adc device is created.
>
> So the idea is that there is an API for the driver, and then
> sub-packages to that driver that can implement that API. You have
> flexibility in the sub-packages, so you could do something like:
>
> hw/drivers/sensors/src/sensors.c (*) main sensors driver
> hw/drivers/sensors/pressure/bosch/bm32/src/bm32.c (*) bm32
> implementation.
>
> Users would then create the device, with the bm32 sensor:
>
> os_dev_create(\u201cmy_sensor\u201d, bm32_init_func);
>
> But can then open and use the device with the generic sensor API,
> without knowing the underlying implementation.
>
> sensor = (struct sensor *) os_dev_open(\u201cmy_sensor\u201d)
> sensor_read(sensor, &val);
>
> I assume you read most of this, but I just wanted to point this out.
>
> As an aside: I certainly think we should use pkg.keywords extensively
> in the drivers directory, and make it easy to search for drivers. We
> should also make sure that \u201cnewt pkg search\u201d: a) works, and b)
> provides useful information about each of the drivers when there are
> matches. There is going to be no _perfect_ way to organize this for
> ease of discovery, but I think newt can help a lot.
>
> On 10 Nov 2016, at 1:59, Kevin Townsend 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.
>>
>
> +1 - I totally agree!
>
>> 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 ?
>>
>
> Do we think that 90% of sensors will have a unified interface. I.e.
> sensors have discoverable channels, and those channels have value types.
>
> sensor_discover(sensor, &sensor_chan_types);
>
> assert(sensor_chan_types[0]->type == SENSOR_ACCEL_X);
>
> sensor_read(sensor, 0, &accel_x);
>
> And you can have unified interface to configure these (e.g.
> sensor_config()), that might take an opaque blob, but is pretty standard.
>
> If so, I think you have a driver of type: sensor, that defines the
> sensor API, and then you have subdirectories from there, which
> implement the sensor API.
>
>> 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.
>>
>
> Yeah. we\u2019re going to have to be very disciplined about how we
> organize this directory and break drivers into groups.. Irregardless
> of where we put sensor, I think this is the case.
>
>> 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/*
>>
>
> My preference would probably be by manufacturer. As you mention,
> often sensors are multi-purpose. I also think that the collection of
> code that is common is likely going to be by manufacturer (e.g. bosch.)
>
> so you have hw/drivers/sensor as the API, and
> hw/drivers/sensor/bosch/bmp085/src/bmp085.c as the implementation.
>
>> 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.
>>
>
> +1
>
> I also think it would be great if this could be
> introspectable/discoverable at runtime. I\u2019m thinking it would make
> things like a TI sensor tag really easy to implement from a phone
> perspective.
>
>> 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.
>>
>
> I think this is a no-brainer. The value of an operating system is
> that a community of people maintains this software, and for the type
> of devices Mynewt goes into, sensors are a very common thing. Even if
> writing each individual driver isn\u2019t that hard, there are certainly
> edge cases with this type of hardware, and having other people find
> and maintain those for you is very valuable.
>
> Sterling
Re: Sensor Drivers and File Location
Posted by "David G. Simmons" <sa...@mac.com>.
> On Nov 10, 2016, at 11:08 AM, Kevin Townsend <ke...@adafruit.com> wrote:
>
> Raw data is still important in my opinion. 90% of the time a shares API for all accels or mags is the best choice, but there are instances where you will want the raw data for DSP filtering, etc., and I think there should be a mechanism to get standard SI as well as 'raw' values back from a device.
+1 for access to raw data.
--
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.
Re: Sensor Drivers and File Location
Posted by Kevin Townsend <ke...@adafruit.com>.
Raw data is still important in my opinion. 90% of the time a shares API
for all accels or mags is the best choice, but there are instances where
you will want the raw data for DSP filtering, etc., and I think there
should be a mechanism to get standard SI as well as 'raw' values back
from a device.
On 10/11/16 16:46, Sterling Hughes wrote:
> I should also mention, another option that we could do is have drivers
> for the individual sensors (just have them expose native APIs as
> drivers, e.g. bmp2085_read_val()), but also map into a generic sensor
> API, that we locate in hw/sensors, as an example.
>
> I\u2019m not sure to what extent people using these sensors want raw access
> to them (i.e. this sensor has special features I care about), versus
> just treating them as a generic sensor. If we think it will be common
> to have special features per-sensor, i\u2019d say it makes sense to have:
>
> hw/sensors \u2014 generic sensor API
>
> and then
>
> hw/drivers/sensors/
>
> contain individual sensor drivers organized by manufacturer, that
> create their own device APIs, but also can register with the sensor
> API in hw/sensors.
>
> Sterling
>
> On 10 Nov 2016, at 15:42, Sterling Hughes wrote:
>
>> Hi Kevin,
>>
>> I have some thoughts, but I\u2019m not sure they all directly address your
>> concerns :-)
>>
>> More details on directory re-org and drivers below, but I wanted to
>> mention upfront: I really think its worth thinking through the sensor
>> api you mention in your PS, and then doing the directory org after
>> that. Because I would imagine that these drivers fit directly into
>> that API, which I think is crucially important. It would be really
>> good to understand whether that API was sufficient for 99% of use
>> cases as well, because if so, we would just want to have the
>> implementations map into that API.
>>
>> Additionally, I wanted to mention, that a worthy goal here would be
>> to make these sensors discoverable, in a way that can be mapped into
>> OIC. One of the nice things about OIC is that it supports
>> standardized resource discovery, and I think it would be awesome,
>> especially for Maker applications, if you could connect to a device
>> with a phone, and automatically get a list of sensors available, and
>> interact with them. If we make sure that the sensor APIs are
>> introspectable, this should be easy to do.
>>
>> I also want to point out how we\u2019ve done certain drivers, like the ADC
>> driver. Essentially, we have a top-level package, \u201cadc\u201d, which
>> contains the interface for all ADC drivers, and then we have the
>> individual implementation of the driver itself. The following source
>> files point to this:
>>
>> * high-level ADC API: hw/drivers/adc/include/adc/adc.h
>> - note: 2 interfaces defined here. The driver implementation
>> interface: adc_driver_funcs, and the user interface calls.
>>
>> * implementation of ADC for NRF52:
>> hw/drivers/adc/adc_nrf52/src/adc_nrf52.c
>> - note: only exported call is int nrf52_adc_dev_init(struct
>> os_dev *, void *), which is passed as a function pointer to
>> os_dev_create() in hal_bsp.c, when the adc device is created.
>>
>> So the idea is that there is an API for the driver, and then
>> sub-packages to that driver that can implement that API. You have
>> flexibility in the sub-packages, so you could do something like:
>>
>> hw/drivers/sensors/src/sensors.c (*) main sensors driver
>> hw/drivers/sensors/pressure/bosch/bm32/src/bm32.c (*) bm32
>> implementation.
>>
>> Users would then create the device, with the bm32 sensor:
>>
>> os_dev_create(\u201cmy_sensor\u201d, bm32_init_func);
>>
>> But can then open and use the device with the generic sensor API,
>> without knowing the underlying implementation.
>>
>> sensor = (struct sensor *) os_dev_open(\u201cmy_sensor\u201d)
>> sensor_read(sensor, &val);
>>
>> I assume you read most of this, but I just wanted to point this out.
>>
>> As an aside: I certainly think we should use pkg.keywords extensively
>> in the drivers directory, and make it easy to search for drivers. We
>> should also make sure that \u201cnewt pkg search\u201d: a) works, and b)
>> provides useful information about each of the drivers when there are
>> matches. There is going to be no _perfect_ way to organize this for
>> ease of discovery, but I think newt can help a lot.
>>
>> On 10 Nov 2016, at 1:59, Kevin Townsend 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.
>>>
>>
>> +1 - I totally agree!
>>
>>> 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 ?
>>>
>>
>> Do we think that 90% of sensors will have a unified interface. I.e.
>> sensors have discoverable channels, and those channels have value types.
>>
>> sensor_discover(sensor, &sensor_chan_types);
>>
>> assert(sensor_chan_types[0]->type == SENSOR_ACCEL_X);
>>
>> sensor_read(sensor, 0, &accel_x);
>>
>> And you can have unified interface to configure these (e.g.
>> sensor_config()), that might take an opaque blob, but is pretty
>> standard.
>>
>> If so, I think you have a driver of type: sensor, that defines the
>> sensor API, and then you have subdirectories from there, which
>> implement the sensor API.
>>
>>> 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.
>>>
>>
>> Yeah. we\u2019re going to have to be very disciplined about how we
>> organize this directory and break drivers into groups.. Irregardless
>> of where we put sensor, I think this is the case.
>>
>>> 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/*
>>>
>>
>> My preference would probably be by manufacturer. As you mention,
>> often sensors are multi-purpose. I also think that the collection of
>> code that is common is likely going to be by manufacturer (e.g. bosch.)
>>
>> so you have hw/drivers/sensor as the API, and
>> hw/drivers/sensor/bosch/bmp085/src/bmp085.c as the implementation.
>>
>>> 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.
>>>
>>
>> +1
>>
>> I also think it would be great if this could be
>> introspectable/discoverable at runtime. I\u2019m thinking it would make
>> things like a TI sensor tag really easy to implement from a phone
>> perspective.
>>
>>> 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.
>>>
>>
>> I think this is a no-brainer. The value of an operating system is
>> that a community of people maintains this software, and for the type
>> of devices Mynewt goes into, sensors are a very common thing. Even
>> if writing each individual driver isn\u2019t that hard, there are
>> certainly edge cases with this type of hardware, and having other
>> people find and maintain those for you is very valuable.
>>
>> Sterling
Re: Sensor Drivers and File Location
Posted by Sterling Hughes <st...@apache.org>.
I should also mention, another option that we could do is have drivers
for the individual sensors (just have them expose native APIs as
drivers, e.g. bmp2085_read_val()), but also map into a generic sensor
API, that we locate in hw/sensors, as an example.
I\u2019m not sure to what extent people using these sensors want raw access
to them (i.e. this sensor has special features I care about), versus
just treating them as a generic sensor. If we think it will be common
to have special features per-sensor, i\u2019d say it makes sense to have:
hw/sensors \u2014 generic sensor API
and then
hw/drivers/sensors/
contain individual sensor drivers organized by manufacturer, that create
their own device APIs, but also can register with the sensor API in
hw/sensors.
Sterling
On 10 Nov 2016, at 15:42, Sterling Hughes wrote:
> Hi Kevin,
>
> I have some thoughts, but I\u2019m not sure they all directly address
> your concerns :-)
>
> More details on directory re-org and drivers below, but I wanted to
> mention upfront: I really think its worth thinking through the sensor
> api you mention in your PS, and then doing the directory org after
> that. Because I would imagine that these drivers fit directly into
> that API, which I think is crucially important. It would be really
> good to understand whether that API was sufficient for 99% of use
> cases as well, because if so, we would just want to have the
> implementations map into that API.
>
> Additionally, I wanted to mention, that a worthy goal here would be to
> make these sensors discoverable, in a way that can be mapped into OIC.
> One of the nice things about OIC is that it supports standardized
> resource discovery, and I think it would be awesome, especially for
> Maker applications, if you could connect to a device with a phone, and
> automatically get a list of sensors available, and interact with them.
> If we make sure that the sensor APIs are introspectable, this should
> be easy to do.
>
> I also want to point out how we\u2019ve done certain drivers, like the
> ADC driver. Essentially, we have a top-level package, \u201cadc\u201d,
> which contains the interface for all ADC drivers, and then we have the
> individual implementation of the driver itself. The following source
> files point to this:
>
> * high-level ADC API: hw/drivers/adc/include/adc/adc.h
> - note: 2 interfaces defined here. The driver implementation
> interface: adc_driver_funcs, and the user interface calls.
>
> * implementation of ADC for NRF52:
> hw/drivers/adc/adc_nrf52/src/adc_nrf52.c
> - note: only exported call is int nrf52_adc_dev_init(struct os_dev *,
> void *), which is passed as a function pointer to os_dev_create() in
> hal_bsp.c, when the adc device is created.
>
> So the idea is that there is an API for the driver, and then
> sub-packages to that driver that can implement that API. You have
> flexibility in the sub-packages, so you could do something like:
>
> hw/drivers/sensors/src/sensors.c (*) main sensors driver
> hw/drivers/sensors/pressure/bosch/bm32/src/bm32.c (*) bm32
> implementation.
>
> Users would then create the device, with the bm32 sensor:
>
> os_dev_create(\u201cmy_sensor\u201d, bm32_init_func);
>
> But can then open and use the device with the generic sensor API,
> without knowing the underlying implementation.
>
> sensor = (struct sensor *) os_dev_open(\u201cmy_sensor\u201d)
> sensor_read(sensor, &val);
>
> I assume you read most of this, but I just wanted to point this out.
>
> As an aside: I certainly think we should use pkg.keywords extensively
> in the drivers directory, and make it easy to search for drivers. We
> should also make sure that \u201cnewt pkg search\u201d: a) works, and b)
> provides useful information about each of the drivers when there are
> matches. There is going to be no _perfect_ way to organize this for
> ease of discovery, but I think newt can help a lot.
>
> On 10 Nov 2016, at 1:59, Kevin Townsend 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.
>>
>
> +1 - I totally agree!
>
>> 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 ?
>>
>
> Do we think that 90% of sensors will have a unified interface. I.e.
> sensors have discoverable channels, and those channels have value
> types.
>
> sensor_discover(sensor, &sensor_chan_types);
>
> assert(sensor_chan_types[0]->type == SENSOR_ACCEL_X);
>
> sensor_read(sensor, 0, &accel_x);
>
> And you can have unified interface to configure these (e.g.
> sensor_config()), that might take an opaque blob, but is pretty
> standard.
>
> If so, I think you have a driver of type: sensor, that defines the
> sensor API, and then you have subdirectories from there, which
> implement the sensor API.
>
>> 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.
>>
>
> Yeah. we\u2019re going to have to be very disciplined about how we
> organize this directory and break drivers into groups.. Irregardless
> of where we put sensor, I think this is the case.
>
>> 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/*
>>
>
> My preference would probably be by manufacturer. As you mention,
> often sensors are multi-purpose. I also think that the collection of
> code that is common is likely going to be by manufacturer (e.g.
> bosch.)
>
> so you have hw/drivers/sensor as the API, and
> hw/drivers/sensor/bosch/bmp085/src/bmp085.c as the implementation.
>
>> 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.
>>
>
> +1
>
> I also think it would be great if this could be
> introspectable/discoverable at runtime. I\u2019m thinking it would make
> things like a TI sensor tag really easy to implement from a phone
> perspective.
>
>> 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.
>>
>
> I think this is a no-brainer. The value of an operating system is
> that a community of people maintains this software, and for the type
> of devices Mynewt goes into, sensors are a very common thing. Even if
> writing each individual driver isn\u2019t that hard, there are certainly
> edge cases with this type of hardware, and having other people find
> and maintain those for you is very valuable.
>
> Sterling
Re: Sensor Drivers and File Location
Posted by Sterling Hughes <st...@apache.org>.
Hi Kevin,
I have some thoughts, but I\u2019m not sure they all directly address your
concerns :-)
More details on directory re-org and drivers below, but I wanted to
mention upfront: I really think its worth thinking through the sensor
api you mention in your PS, and then doing the directory org after that.
Because I would imagine that these drivers fit directly into that API,
which I think is crucially important. It would be really good to
understand whether that API was sufficient for 99% of use cases as well,
because if so, we would just want to have the implementations map into
that API.
Additionally, I wanted to mention, that a worthy goal here would be to
make these sensors discoverable, in a way that can be mapped into OIC.
One of the nice things about OIC is that it supports standardized
resource discovery, and I think it would be awesome, especially for
Maker applications, if you could connect to a device with a phone, and
automatically get a list of sensors available, and interact with them.
If we make sure that the sensor APIs are introspectable, this should be
easy to do.
I also want to point out how we\u2019ve done certain drivers, like the ADC
driver. Essentially, we have a top-level package, \u201cadc\u201d, which
contains the interface for all ADC drivers, and then we have the
individual implementation of the driver itself. The following source
files point to this:
* high-level ADC API: hw/drivers/adc/include/adc/adc.h
- note: 2 interfaces defined here. The driver implementation
interface: adc_driver_funcs, and the user interface calls.
* implementation of ADC for NRF52:
hw/drivers/adc/adc_nrf52/src/adc_nrf52.c
- note: only exported call is int nrf52_adc_dev_init(struct os_dev *,
void *), which is passed as a function pointer to os_dev_create() in
hal_bsp.c, when the adc device is created.
So the idea is that there is an API for the driver, and then
sub-packages to that driver that can implement that API. You have
flexibility in the sub-packages, so you could do something like:
hw/drivers/sensors/src/sensors.c (*) main sensors driver
hw/drivers/sensors/pressure/bosch/bm32/src/bm32.c (*) bm32
implementation.
Users would then create the device, with the bm32 sensor:
os_dev_create(\u201cmy_sensor\u201d, bm32_init_func);
But can then open and use the device with the generic sensor API,
without knowing the underlying implementation.
sensor = (struct sensor *) os_dev_open(\u201cmy_sensor\u201d)
sensor_read(sensor, &val);
I assume you read most of this, but I just wanted to point this out.
As an aside: I certainly think we should use pkg.keywords extensively in
the drivers directory, and make it easy to search for drivers. We
should also make sure that \u201cnewt pkg search\u201d: a) works, and b)
provides useful information about each of the drivers when there are
matches. There is going to be no _perfect_ way to organize this for
ease of discovery, but I think newt can help a lot.
On 10 Nov 2016, at 1:59, Kevin Townsend 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.
>
+1 - I totally agree!
> 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 ?
>
Do we think that 90% of sensors will have a unified interface. I.e.
sensors have discoverable channels, and those channels have value types.
sensor_discover(sensor, &sensor_chan_types);
assert(sensor_chan_types[0]->type == SENSOR_ACCEL_X);
sensor_read(sensor, 0, &accel_x);
And you can have unified interface to configure these (e.g.
sensor_config()), that might take an opaque blob, but is pretty
standard.
If so, I think you have a driver of type: sensor, that defines the
sensor API, and then you have subdirectories from there, which implement
the sensor API.
> 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.
>
Yeah. we\u2019re going to have to be very disciplined about how we
organize this directory and break drivers into groups.. Irregardless of
where we put sensor, I think this is the case.
> 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/*
>
My preference would probably be by manufacturer. As you mention, often
sensors are multi-purpose. I also think that the collection of code
that is common is likely going to be by manufacturer (e.g. bosch.)
so you have hw/drivers/sensor as the API, and
hw/drivers/sensor/bosch/bmp085/src/bmp085.c as the implementation.
> 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.
>
+1
I also think it would be great if this could be
introspectable/discoverable at runtime. I\u2019m thinking it would make
things like a TI sensor tag really easy to implement from a phone
perspective.
> 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.
>
I think this is a no-brainer. The value of an operating system is that
a community of people maintains this software, and for the type of
devices Mynewt goes into, sensors are a very common thing. Even if
writing each individual driver isn\u2019t that hard, there are certainly
edge cases with this type of hardware, and having other people find and
maintain those for you is very valuable.
Sterling
Re: Sensor Drivers and File Location
Posted by Vipul Rahane <vi...@runtime.io>.
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 <kevin@adafruit.com <ma...@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.
Re: Sensor Drivers and File Location
Posted by will sanfilippo <wi...@runtime.io>.
> On Nov 9, 2016, at 5:59 PM, Kevin Townsend <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.
>
Re: Sensor Drivers and File Location
Posted by Kevin Townsend <ke...@adafruit.com>.
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 <sa...@mac.com> 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 <kevin@adafruit.com
> <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.
>
>
>
Re: Sensor Drivers and File Location
Posted by "David G. Simmons" <sa...@mac.com>.
> On Nov 10, 2016, at 9:01 AM, Kevin Townsend <ke...@adafruit.com> 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.
Re: Sensor Drivers and File Location
Posted by Kevin Townsend <ke...@adafruit.com>.
> 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.
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.)
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.
K.
Re: Sensor Drivers and File Location
Posted by "David G. Simmons" <sa...@mac.com>.
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 <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 ?
>
> 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.