Re: [SensorAPI] Default Sensor Config

[Sterling Hughes <st...@apache.org>]

It\u2019s an interesting thought, as you point out there are kinda two 
things at work here.

1- A driver needs to be \u201cconfig\u2019ed\u201d by default, and where the 
driver init is called is not the right place to do that.

2- The driver doesn\u2019t have any user specific data to call, there 
should be a reasonable/sane default, and I don\u2019t think requiring the 
user to call:

driver->config(NULL);

Is particularly good API design.  I think we should probably dictate 
that config() can be called as many times as possible, and have a 
\u201cconfig\u201d phase of the sensor API, i.e. when the task gets started, 
or a new sensor gets registered, the sensor API calls config(NULL) to 
set default parameters, and then users can call config(data), if they 
want to reconfigure defaults.

On 29 Dec 2016, at 2:29, Kevin Townsend wrote:

> One issues I saw working on some sensor drivers (based on the 
> simulated accel as a starting point) is that no 'default' config 
> settings are currently being set, and it seems possible that a sensor 
> might be initialised without calling the config function explicitly.
>
> The config system is great (highly flexible and easy to understand), 
> but would it be better to have a default config setting that is set 
> when the sensor is initialized, or should running the config function 
> at least once be considered mandatory and the assumption made that it 
> is always being called? In that case, should we return an error if 
> something like a read function is called but the sensor hasn't been 
> configured yet to put it into a known state (and probably wake the 
> sensor up since many devices will default to booting into power down 
> mode)?

Re: [SensorAPI] Default Sensor Config

[Kevin Townsend <ke...@adafruit.com>]

This sounds reasonable to me and at least leaves room for sensible 
defaults, or setting any internal variables to match HW defaults.

K.


On 04/01/17 04:13, Sterling Hughes wrote:
> It\u2019s an interesting thought, as you point out there are kinda two 
> things at work here.
>
> 1- A driver needs to be \u201cconfig\u2019ed\u201d by default, and where the driver 
> init is called is not the right place to do that.
>
> 2- The driver doesn\u2019t have any user specific data to call, there 
> should be a reasonable/sane default, and I don\u2019t think requiring the 
> user to call:
>
> driver->config(NULL);
>
> Is particularly good API design.  I think we should probably dictate 
> that config() can be called as many times as possible, and have a 
> \u201cconfig\u201d phase of the sensor API, i.e. when the task gets started, or 
> a new sensor gets registered, the sensor API calls config(NULL) to set 
> default parameters, and then users can call config(data), if they want 
> to reconfigure defaults.
>
> On 29 Dec 2016, at 2:29, Kevin Townsend wrote:
>
>> One issues I saw working on some sensor drivers (based on the 
>> simulated accel as a starting point) is that no 'default' config 
>> settings are currently being set, and it seems possible that a sensor 
>> might be initialised without calling the config function explicitly.
>>
>> The config system is great (highly flexible and easy to understand), 
>> but would it be better to have a default config setting that is set 
>> when the sensor is initialized, or should running the config function 
>> at least once be considered mandatory and the assumption made that it 
>> is always being called? In that case, should we return an error if 
>> something like a read function is called but the sensor hasn't been 
>> configured yet to put it into a known state (and probably wake the 
>> sensor up since many devices will default to booting into power down 
>> mode)?