nmaggioni commented on issue #16916:
URL: https://github.com/apache/nuttx/issues/16916#issuecomment-3228526324
From my (quite limited) point of view, ADC interactions could be categorized
like this:
+ Active
- Infrequent reads
- Frequent reads from a single thread
- Frequent reads from multiple threads
+ Passive
- Interval based
- Threshold based
+ Ad-hoc
- Configuration
- Peculiar use-cases (?)
If I had to think about a unified approach compatible with all the
categories above, I would probably wish for it to have these capabilities:
1. Reading a single value from a single thread, without the need for
additional structures, and with ease of use being preferred over speed.
2. Reading a single value from a single thread, without the need for
additional structures, and with speed being preferred over ease of use.
3. Reading a single value from multiple threads, with the need of a shared
synchronization structure.
4. Having a background worker call a configurable callback function either
periodically or when the sampled value meets some threshold/window/delta (this
latter condition is a superset of the former?).
5. Being able to define custom device configurations in an arbitrary
structure, and then "push" them to the device through a standardized call.
6. Keeping the possibility of having device-specific `ioctl`s like it is
now, but only allowing their definition for unique use cases that aren't
included above.
All these functionalities would not necessarily be compatible with each
other, though: I would be fine with needing to code additional, board-specific
safeguards in case I wanted to switch between different reading methods at
runtime (e.g.: gating the periodic callback behind a semaphore to also be able
to run random one-off reads).
Also, I suppose that in most cases requirements 3 and 4 could be merged
together through some simple userland mux.
Taking inspiration from the current docs, I would translate these
requirements into these potential interfaces:
+ **`poll()`:** The foundations of this approach are solid, even if
supporting it involves quite a bit of work behind the scenes. However, I could
not easily find a complete reference implementation between the currently
supported ADCs.
+ **`read()`:** Simple and easy to use, perfect for non-critical code paths
where the interacting with the ADC is not part of the core functionalities
(think battery level monitoring). Quite simple to implement in the lower layer
in most cases.
+ **`ANIOC_READ` ioctl:** Similar to the approach above, but may take
additional options to improve speed or apply device-specific tweaks (see my
[`*_READ_FASTUNSAFE`](https://github.com/apache/nuttx/blob/585c25bac0099367553a0c53ee5bbd011baf2b56/drivers/analog/ads7046.c#L149)
idea).
+ **Worker thread:** This approach could build on top of the previous ones,
but threading library portability could be an issue? I haven't experimented
much on this with my hardware yet, so I'm going out on a limb here.
+ **`ANIOC_WDOG_*` ioctls:** These could configure and start/stop the
background worker. They could set the callback function, triggering conditions,
and such.
+ **`ANIOC_CONFIG` ioctl:** This call could be used, when applicable, to set
and get the current internal configuration of the device.
I hope that all these ramblings sound reasonable. I tried to analyze the
issue from a fresh point of view, even if I'm sure that I missed some quite
important caveats :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
