Re: Sensor Drivers and File Location

> On Nov 10, 2016, at 11:08 AM, Kevin Townsend 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

Re: Sensor Drivers and File Location

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

Re: Sensor Drivers and File Location

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,

Re: Sensor Drivers and File Location

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’m not sure to what extent people

Re: Sensor Drivers and File Location

Hi Kevin, I have some thoughts, but I’m 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

Re: Sensor Drivers and File Location

> On Nov 10, 2016, at 9:01 AM, Kevin Townsend 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

Re: Sensor Drivers and File Location

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

Re: Sensor Drivers and File Location

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 a écrit : > I would actually go about this slightly differently ... > > All of these sensors come in,

Re: Sensor Drivers and File Location

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

Re: Sensor Drivers and File Location

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//” and "hw/drivers/sensors/”. Reference drivers are nice to have. Meta-data and SI units can be part of the

Re: Sensor Drivers and File Location

> On Nov 9, 2016, at 5:59 PM, 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

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