drivers/analog/ads1115: Add support for TI ADS1115

[justapotato213]

Summary

This PR is from inspace.

This PR adds an experimental driver for the Texas Instruments 4 channel 16 bit ADS1115 ADC. The driver uses I2c and a software trigger, and implements the ADC driver interface from NuttX.

The PR also includes proper documentation for the ADS1115.

Impact

The ADS1115 can be used with NuttX!

Testing

Testing was done using the I2C0 bus on a Pico.

Testing included running the adc example app, with software triggering enabled, a group sample size of 8 and ADC_FIFOSIZE set to 9 to store all 8 channels of measurement in the FIFO after a software trigger.

The ADS1115 was tested with a 3.3V source connected to A0. and another with a GND source connected to A1 and all other pins left floating. The PGA was set to the highest value, 6.144V, as other values are not large enough to capture the full voltage.

nsh> adc -n 1
adc_main: g_adcstate.count: 1
adc_main: Hardware initialized. Opening the ADC device: /dev/adc1
Sample:
1: channel: 0 value: 17446
2: channel: 1 value: 14276
3: channel: 2 value: 62656
4: channel: 3 value: 0
5: channel: 4 value: 17445
6: channel: 5 value: 65534
7: channel: 6 value: 2882
8: channel: 7 value: 2873

In this test, the values were within what was expected from the test setup.
Channel 0 measures the differential between A0 and A1, which is 3.3V and ground. After converting to volts (value * 6.144)/2^15, the result is 3.271125V, which is within the expected range.
Channel 1 measures the differential between A0 and A3, which is expected to be the difference between 3.3V and a floating pin, resulting in a measured value of 2.67675V, which once again is expected.
Channel 2 measures the difference between A1 and A3, which is gnd and a floating pin. The ADS1115 outputs a 16bit value in two's complement, but the adc example app does not support this, which is why the result is off. Converting to a voltage, this value is -0.54V, which is expected between gnd and a floating pin.
Channel 3 measures the difference between the two floating pins, which is why the value is 0.
Channel 4 through 7 are the single ended inputs, where it compares A0 to A3 to GND. Converting each value results in a voltage of 3.2709375V, -0.000375V, 0.540375V and 0.5386875V respectfully, which are all within the expected ranges.

Continuous and single shot modes were tested, and also work as expected.

The comparator / ALRT/RDY pin were also tested briefly by connecting an LED to the output and seeing it flash on and off. This test succeeded and showed the chip sending the signal, but I lack the equipment to test further beyond this.

[nuttxpr]

[Experimental Bot, please feedback here]

Fill In The Commit Message: This PR contains a Commit with an Empty Commit Message. Please fill in the Commit Message with the PR Summary.

The provided information is a good start but needs some improvements to fully meet the NuttX PR requirements. Here's a breakdown:

Strengths:

• Clear Summary: The summary explains the what, why, and how of the change.
• Impact Description: Addresses the impact on users and the build process.
• Detailed Testing: Provides specific testing scenarios, including the hardware setup and expected/observed results.

Weaknesses:

• Missing Issue References: No related NuttX or NuttX Apps issue/PR is mentioned. If this is a new feature and there's no corresponding issue, state that explicitly.
• Incomplete Impact Assessment: Several impact categories are missing:
  • Hardware: While you mention RP2040, be more specific. List all affected architectures/boards. Specify if any board configuration changes (e.g., defconfig modifications) are required.
  • Documentation: You say documentation is included. State where it is located (e.g., in the driver's source file or in the docs directory).
  • Security: Even if there are no security implications, explicitly state "NO."
  • Compatibility: Address backward/forward compatibility and interoperability explicitly, even if "NO" is the answer for each.
  • "Anything else to consider?": This is important for catching unusual edge cases. Even if there's nothing else, state "None."
• Incomplete Testing Information:
  • Build Host: Details about the build host system are missing.
  • Targets: While RP2040 is mentioned, mention the specific board used (e.g., Raspberry Pi Pico). Consider testing on other boards or the simulator if possible.
  • "Testing logs before change": While not strictly required if it's a new feature, it can still be helpful to show the behavior before the driver was added (e.g., an error message indicating the ADC is not found).
  • Two's complement handling: You've identified an issue with two's complement handling in the adc example app. This should probably be addressed in a separate issue/PR, and this PR should mention the limitation and the planned fix.

How to improve the PR description:

1. Link to related issues (if applicable): If there's a corresponding issue, include it. If not, say "No related issue."

2. Complete the Impact section: Fill in all the missing parts, even if the answer is "NO." Be very specific about hardware changes, documentation updates, and compatibility. For example:

   • Hardware: "This PR adds support for the ADS1115 ADC on RP2040-based boards (specifically tested on the Raspberry Pi Pico). It requires adding the CONFIG_ADC_ADS1115 and CONFIG_I2C_DRIVER options to the board's defconfig and enabling the I2C0 peripheral."
   • Documentation: "Documentation is provided in the drivers/adc/ads1115.c file and a new section will be added to the NuttX ADC documentation."
   • Security: "NO"
   • Compatibility: "Backward compatible. No forward compatibility issues anticipated. No interoperability concerns."
   • Anything else to consider?: "None."

3. Enhance the Testing section:

   • Build Host: "Linux (Ubuntu 22.04), x86_64, GCC 11.2.0" (or similar).
   • Targets: "RP2040 (Raspberry Pi Pico)"
   • Testing logs before change: If this is a new feature, consider adding a log snippet showing that the ADC wasn't available before.
   • Address the two's complement issue: Either fix it within this PR or create a separate issue/PR to track it and mention it in this PR's description.

By addressing these weaknesses, your PR will be much stronger and easier for the NuttX maintainers to review and merge. Remember, clarity and completeness are crucial for a successful contribution to an open-source project.

[lupyuen]

Looks great, please remember to set the PR to "Ready For Review". Thanks :-)

[lupyuen]

Also: Please squash the commits. Thanks :-)

• https://lupyuen.github.io/articles/pr#squash-the-commits

[justapotato213]

Yeah sorry, been a busy week, wanted to squash first before marking it ready. Thank you so much! :)