On Thu, Mar 17, 2022 at 6:24 PM Tim <t...@jti.uk.com.invalid> wrote:
> Just a "thumbs up" from me if you do this (or find something that exists
> that'll do it) - it's a perfect fit for my current project :)
>
>
So the update matches your expectation, please watch github PR
notification, we will upstream the patch after two/three weeks.
> >-----Original Message-----
> >From: Matthew Trescott <matthewtresc...@gmail.com>
> >Sent: 17 March 2022 05:55
> >To: dev@nuttx.apache.org
> >Subject: Abstract "channels" driver model
> >
> >Hi everyone,
> >
> >I was thinking about how to implement the software for my project (control
> >module for a Formula SAE car) and realized that the basic ADC driver
> model is
> >a bit inconvenient and creates a lot of extra overhead in userspace
> threads
> >when implementing advanced features. Some features I think would make
> >sense in an abstract “channels” driver model that would benefit many
> controls
> >applications:
> >
> >- Only wake up a thread when a value has changed "significantly."
> >
> >- Support channels generated from bilinear/bicubic interpolation using a
> table.
> >
> >- Share the same ADC values among multiple threads with different
> priorities,
> >like a high-priority safing algorithm, a medium priority control
> algorithm, and a
> >low-priority CAN broadcast thread.
> >
> >- Share the same ADC values among threads with different needs—the three
> >listed above only care about the latest value, while a datalogging thread
> that
> >saves to flash memory would want to save data in chunks.
> >
> >- Implement software filters and allow binding to userspace control
> algorithms
> >for Kalman filtering.
> >
> >- Allow different threads to subscribe to epoll events at different rates.
> >
> >- Allow data received via an offboard, runtime-configurable serial bus
> like CAN
> >or UART to be assigned a meaningful name and seamlessly used for userspace
> >control functions just like ADC measurements, with a userspace helper
> thread
> >de-serializing the messages as they arrive.
> >
> >- Allow the application to wait for two or more channels to be consistent.
> >
> >- Avoid unnecessary copies and support ADC DMA transfers.
> >
> >~~~~~~~~
> >The model I have in mind is something like this:
> >
> >- Channels are char-devices; e.g. /dev/channels/throttle-position-1
> >
> >- A userspace application that only cares about the latest measurement
> would
> >do something like this to get a pointer that always points to the latest
> channel
> >value and avoid the overhead of read():
> >
> > uint32_t *throttle_position_1;
> > int tps1_fd;
> > tps1_fd = open("/dev/channels/throttle-position-1");
> > ioctl(tps1_fd, CHANIOC_SUBSCRIBE, (unsigned
> long)&throttle_position_1);
> > ioctl(tps1_fd, CHANIOC_SET_FILTER, ...);
> > poll(...);
> > // Do some calculations with *throttle_position_1
> > // Drive some output
> >
> >- A periodic userspace task that works with bulk data would read() from
> the
> >ring buffer, or get a pointer to the ring buffer with an ioctl (not sure
> which
> >would be better)
> >
> >- New data is copied to the ring buffer in the low- or high-priority work
> queue.
> >
> >- Boardctl or board-init logic is responsible for setting up special ADC
> triggering
> >(e.g. from a PWM module) and telling the ADC backend driver to register
> itself
> >as a channel. DMA can be set up so that ADC measurements are directly
> >copied to the "latest value" location if no filtering or conversion is
> needed.
> >
> >- Software-generated channels are created with a syscall; the userspace
> >thread can write to the resulting char device and the data will be stored
> in the
> >ring buffer and wake up any threads waiting on the software-defined
> >channel.
> >
> >~~~~
> >
> >Looking for prior art, I noticed that there are the Common Sensor Register
> >Interace and Sensor Cluster Driver Interface (drivers/sensors/README.txt).
> >However, these don't cover ADCs or address the overhead of having a
> >multiple-input control thread needing to use both epoll() and read(). Nor
> do
> >they support filtering or multiple userspace threads accessing the same
> >sensor in a convenient way.
> >
> >However, something like this might already exist, just not in mainline
> NuttX. If
> >you know of such a thing or have feedback on this idea, please let me
> know.
> >Otherwise, I'll move ahead with working on it.
> >
> >Best regards,
> >Matt
>
>
