It’s an interesting thought, as you point out there are kinda two
things at work here.
1- A driver needs to be “config’ed” by default, and where the
driver init is called is not the right place to do that.
2- The driver doesn’t have any user specific data to call, there
should be a reasonable/sane default, and I don’t 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
“config” 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)?
