On Fri, Mar 18, 2022 at 3:17 AM Matthew Trescott
wrote:
> On Thu, Mar 17, 2022 at 2:41 AM Xiang Xiao
> 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 hol
On Thu, Mar 17, 2022 at 2:41 AM Xiang Xiao 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
> >- 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 a
we will upstream the patch after two/three weeks.
> >-Original Message-
> >From: Matthew Trescott
> >Sent: 17 March 2022 05:55
> >To: dev@nuttx.apache.org
> >Subject: Abstract "channels" driver model
> >
> >Hi everyone,
> >
>
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 :)
>-Original Message-
>From: Matthew Trescott
>Sent: 17 March 2022 05:55
>To: dev@nuttx.apache.org
>Subject: Abs
a 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."
>
&
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 amon
