PiyushPatle26 commented on issue #18648: URL: https://github.com/apache/nuttx/issues/18648#issuecomment-4166237808
@linguini1 thanks for the suggestion, will include test suite in nuttx-apps! I’ll address each point below: > What do you mean by using mmap as future work? (p. 6) For DMA-capable ADCs, a zero-copy interface could be exposed as an optional capability, but it introduces synchronization, cache coherency, and multi-reader challenges. This is why it is deferred to future work pending stabilization of the core API. > Are you sure that every ADC can signal when a new value is ready? actually correct, that was too broadly stated. What I meant is that every compliant ADC driver eventually calls `adc_receive()` when a sample is available. However, how the lower-half detects that varies by hardware: some MCUs (like STM32/ESP32) use end-of-conversion interrupts, while others (like RP2040) trigger based on FIFO thresholds. From the upper-half perspective, poll/notification still works in all cases, only the timing and latency differ depending on the hardware. > What is the RP2040s round-robin ADC scheduling? The RP2040 ADC uses a round-robin mode: you select a set of channels, and the hardware continuously cycles through them, pushing results into a FIFO and triggering interrupts at a set threshold. There’s no way to sample a specific channel on demand, it always rotates through enabled channels. Because of this, I set `supports_set_channel = false`. I also didn’t expose it as `ANIOC_START_STREAM`, since its behavior (FIFO + interrupts) is quite different from STM32-style DMA streaming, and treating them the same would hide that difference. > What is the benefit of the per-fd state structs? With a device-global channel setting, two applications opening `/dev/adc0` can interfere: one `ANIOC_SET_CHANNEL` call overwrites the other, leading to incorrect or inconsistent data. Per-fd state avoids this. Each open gets its own channel configuration and buffer, so samples are delivered only to the relevant file descriptor. This isolates multiple users and prevents them from affecting each other. It also makes channel switching cleaner, since only that fd’s buffer is reset rather than changing global device state. There can be few alternatives, but each has some trade-offs. > I think capabilities are bitter implemented as a single caps bitfield as opposed to bool members, but someone else can correct me if that's misguided It would allow us checking multiple capabilities efficiently, and aligns with existing patterns in NuttX. so I think this way is btter > What is the value of `max_open_fds`? Real thing is If too many opens occur, `adc_open()` will naturally fail with `-ENOMEM` when the heap is exhausted. It's more like how many concurrent opens are realistically supported based on memory and buffering. I’m open to removing it if it’s not considered useful. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
