On Fri, Mar 18, 2022 at 3:17 AM Matthew Trescott <matthewtresc...@gmail.com> wrote:
> On Thu, Mar 17, 2022 at 2:41 AM Xiang Xiao <xiaoxiang781...@gmail.com> > wrote: > > > > We are working on this to provide multiple read/poll support. The basic > > idea is that: > > > > 1. Upper half driver hold FIFO shared by all client > > 2. Each client hold the offset into the share FIFO > > > > The benefit is that we don't need to maintain multiple queues and avoid > the > > memory duplication. > > Sounds interesting, but is it a FIFO or a ring buffer? The difference > being that the location of the head pointer doesn't advance upon reads > with a ring buffer so all threads get the same data. > It's a circle buffer. Each reader has unique head pointer, the upper half driver will update the head to point to the oldest data if the reader fails to fetch the data quickly. > > Did you already bring up this concept on the mailing list? I don't > recall.... The reason I brought this up before I started writing code > is because it's important to define the scope and details of the > problem and specify what the solution needs to do, before trying to > solve it. And get feedback. That would certainly help avoid > reinventing the driver model periodically. > > The basic driver(support single client) already mainline one year ago: https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/sensors/sensor.h https://github.com/apache/incubator-nuttx/blob/master/drivers/sensors/sensor.c Here is a simple test driver: https://github.com/apache/incubator-nuttx-apps/tree/master/testing/sensortest > > Nor do they support filtering or > > > > > > > Kernel side only support the resample filter to handle the different > sample > > frequency request: > > > > 1. Upper half collect the sample frequency from all client > > 2. Forward the fast request to the lower half > > 3. Down sample to match slow client in the read callback > > > > We think that other advanced filter or algorithm is better to put to the > > userspace, and will provide an interface compatible with uORB: > > https://docs.px4.io/master/en/middleware/uorb.html > > Ok... but that approach is not necessarily suitable for > resource-constrained applications. Performing the filtering in > userspace and copying the data around with sockets or message queues > means many extra context switches. > user space doesn't need socket or message queue to talk with each other, the buffer is managed by a common kernel virtual sensor driver which is naturally shared by all clients. Yes, it may impact on the performance by putting the algo to user space, this is a tradeoff between the architecture and performance. But, anyway you can write the algo in kernel space if you prefer. > > Besides, you need to implement some kind of filtering in kernel space > anyway to avoid aliasing when downsampling. > The algo can be improved step by step and selected through Kconfig. > > (Incidentally, who exactly is the "we" that thinks other advanced > filters are better put in userspace? Tim's email suggests that's not > quite everyone's opinion.) > > It come from Unix design philosophy: kernel provide the device abstraction and user space add more function and strategy on top of kernel facility. Again, nothing forbid you put filter to kernel space. It's more complex to support the filter in user space than kernel space. That's why we provide this common functionality just like file subsystem provide userfs and net subsystem provide usrsock. > ~~~ > > Greg, I did look at the sensor cluster driver; it might be possible to > extend that and retain API compatibility but otherwise it really > doesn't do enough for my needs. Would need to see if it can be > decoupled from SPI and I2C. > > Do you have feedback on the userspace pointer concept and its > POSIX-ness or lack thereof? > > Matt >
