My thoughts: simple things should be simple. Getting temperature or
humidity values from a sensor only requires a few lines of code. A
simple character driver fells just right for me.
More code brings more potential bugs with it. The character drivers
should remain as an option for simple things.
Frank-Christian
Am 12.03.2023 um 12:44 schrieb Tim Hardisty:
I had a quick skip through the video. My initial thoughts are:
1) This seems to be aimed at multi-sensor, multi-message systems, using uORB;
and, perhaps even, really and perhaps only intended for PX4?
2) is it a "generic" solution, that is a really good idea, and NuttX is right to be
adopting it, or is it just "a" way of sensors interacting with higher level software?
3) was it discussed here before?
Part of me thinks that this should be a layer on top of the tried-and-tested
character driver approach, and it shouldn't actually be replacing it?
In the absence of any documentation, and even looking at the LTR-308 sensor as
an example, it seems to be geared towards a sensor that will take regular
readings (CONFIG_SENSORS_xxxxx_POLL_INTERVAL) and report timestamped changes.
Does it cater properly for "occasional" sensors that rarely need to send data? I can see
there is some kind of push event so I imagine "my" sensor driver could adopt this
methodology and send a message if the light level changes or a near/far proximity event occurs, but
it seems the(my) whole system has to adopt a more complex messaging system for no good reason: the
traditional poll_notify works well for me!
So, in summary, if this is the official way that sensors should be implemented, I will
revisit my working driver, pain though that is. If, however, it is just "a" way
I would rather leave it alone and see it merged once checked. In the future someone - or
I - can revisit it should there ever be a wish for the APDS-9922 to follow the uORB/rpmsg
approach.
Discuss! Guide me!
On 11/03/2023, 23:31, "Alan C. Assis" <acas...@gmail.com
<mailto:acas...@gmail.com>> wrote:
On 3/11/23, Xiang Xiao <xiaoxiang781...@gmail.com
<mailto:xiaoxiang781...@gmail.com>> wrote:
On Sun, Mar 12, 2023 at 12:12 AM Tim Hardisty <t...@hardisty.co.uk
<mailto:t...@hardisty.co.uk>> wrote:
I submitted a PR for a driver for the Broadcom APDS-9922 ambient light
and
proximity sensor, written with what one might call the "traditional"
method of setting up the device via ioctl, then reading data when
available
according to the device setup, via poll notify.
The reviewer (Hi Alan - I'm not complaining!!) has suggested it perhaps
ought to use the "new" sensor methodology with a sensor_lower_half_s etc.
Looking at sensors that use this I can't see any that have the range of
set-up options of this device and are just "there", in the main apart
from
calibration, for example. Nor any NuttX documentation I can see?
Is this following a Linux methodology, like the power devices now do?
When
I did a power supply device drive I was pointed in the direction of Linux
documentation that (after much reading and cogitation) helped explain
what
NuttX was essentially emulating and, with the addition of some more
members
to the regulator_desc_s struct it was then fine and I wrote it that way.
I am still not convinced that this ALS/Proximity sensor necessarily fits
the "new" sensor methodology but if someone can point me in the direction
of relevant documentation I will gladly take a look.
Here is an intro video: https://www.youtube.com/watch?v=ESpAE6wqy9o
<https://www.youtube.com/watch?v=ESpAE6wqy9o>
Thank you Xiang!
Since this subsystem is more complex than original char driver sensor,
is there plans for Documentation ?
Tim, I suggest you to take a look at LTR-308 sensoe (ltr308.c) is it
also an ALS. So you can use it as reference.
BR,
Alan
