PiyushPatle26 opened a new issue, #18648: URL: https://github.com/apache/nuttx/issues/18648
### Is your feature request related to a problem? Please describe. **Piyush Patle** Related: #16916 ## Overview This project aims to define a clear and portable interface contract for the ADC subsystem in Apache NuttX. Currently, ADC behavior varies significantly across drivers, making it difficult to write applications that work across platforms without conditional compilation. This proposal introduces a capability-driven, layered API that standardizes core functionality while preserving hardware flexibility and backward compatibility. ## Motivation While studying the ADC subsystem, several structural issues became evident: - Ambiguous `read()` behavior: The return format depends on `buflen % N`, which can silently omit channel information. This is already flagged by an upstream `REVISIT` comment. - No standard channel selection mechanism: Applications must use a poll-and-discard loop, which is inefficient and non-deterministic. - No capability discovery mechanism: Hardware differences (resolution, DMA, calibration, etc.) require `#ifdef`-based application logic. - Driver inconsistency: For example, `rp2040_adc.c` returns `-ENOTTY` for IOCTLs implemented by STM32 and ESP32, indicating no defined conformance model. These issues collectively indicate the absence of a well-defined subsystem contract. ### Describe the solution you'd like ## Proposed Approach The proposed solution adds a layered API model to the ADC subsystem to make it more organised and consistent while still allowing for different hardware capabilities. The design's main idea is to create a small required interface that all drivers must use. This means that `read()` will always return a struct `adc_msg_s`, `ANIOC_GET_CAPS` will be used to find out what capabilities are available, and `ANIOC_SET_CHANNEL` will be used to make sure that channels can be chosen in a predictable way. Optional layers add more features to platforms that support them, like controlling the resolution, calibrating the runtime, setting the voltage reference, streaming over DMA, and triggering events based on thresholds. To make sure that older drivers still work, existing driver-specific IOCTLs stay the same. The main goal is to make things portable by finding out what they can do, make sure unsupported features are handled clearly with `-ENOTSUP`, and not break any apps that are already out th ere. For more Detailed Version: [Proposal](https://drive.google.com/drive/folders/14_vlDyCJPuWQDStnAJ9qKqaF8XEIOASe?usp=sharing) ### Describe alternatives you've considered _No response_ ### Verification - [x] I have verified before submitting the report. -- 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]
