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
