Expand support for ads1x4s0x series ADCs

[TerryGeng]

The existing support is only for ADS114S08 (16-bit, 12-channel). It has one sister ADS114S06 (16-bit, 6-channel).

Meanwhile, there are the 24-bit variations ADS124S06 and ADS124S08, which are pin-to-pin compatible with the ADS114S0X series. Their documents are almost verbatim identical to the ADS114S0X series with a slightly different read format.

This PR expands support to the remaining three chips, ADS114S06, ADS124S06, and ADS124S08.

Since this is a refactor involving many name changes, I separate the file rename into a commit to make the changes to the actual code more visible. It will be squashed before this PR is ready for merging.

As for the other two commits:

• The first one follows the example set in drivers/adc/adc_lmp90xxx.c, introducing two variables in the config structure to save the resolution and number of channels for different variations. It also includes branching statements in the read functions to do the conversion from the raw data to integers correctly. It has a memory footprint of

Memory region         Used Size  Region Size  %age Used
      BOOT_FLASH:         256 B        256 B    100.00%
           FLASH:       74264 B    2096896 B      3.54%
             RAM:        8744 B       264 KB      3.23%
        IDT_LIST:          0 GB        32 KB      0.00%

• The second commit presents a different way of implementing the same. I define the read functions in a separate template file and populate the right resolution and channel number using macros. I would think this is more elegant since most boards will have only one type of ADS1X4S0X and it's a waste of resources to save the resolution and channel numbers into the stack, and use extra branching statement to perform the check every time the read is invoked. It has a slightly smaller memory footprint compared to the previous one.

Memory region         Used Size  Region Size  %age Used
      BOOT_FLASH:         256 B        256 B    100.00%
           FLASH:       74232 B    2096896 B      3.54%
             RAM:        8744 B       264 KB      3.23%
        IDT_LIST:          0 GB        32 KB      0.00%

I would leave the decision of which one to use to the reviewer. These three (or two) commits will be squashed into one before merging.
Our reviewer @benediktibk has pointed out a better way out. I implemented that instead.

Testing

Tested with an ADS124S06 chip with arpi_pico.

The 16-bit read was tested with setting compatible = "ti,ads114s06"; in the overlay. Since the 16-bit read will ignore the last byte of the response from the chip, it should still behave but with only reduced precision.

My overlay file:

&spi0 {
    status = "ok";
    cs-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
    pinctrl-0 = <&spi0_default>;
    pinctrl-names = "default";

	adc_ads124s06: ads124s06@0 {
		compatible = "ti,ads124s06";

        #io-channel-cells = <1>;
        #address-cells = <1>;
        #size-cells = <0>;
		reg = <0>;
		spi-max-frequency = <1000000>;
        drdy-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;

        ads124s06_gpio: ads124s06_gpio {
            compatible = "ti,ads1x4s0x-gpio";
            gpio-controller;
            ngpios = <4>;
            #gpio-cells = <2>;
        };

        channel@0 {
            reg = <0>;
            zephyr,gain = "ADC_GAIN_1";
            zephyr,reference = "ADC_REF_INTERNAL";
            zephyr,acquisition-time = <ADC_ACQ_TIME_DEFAULT>;
            zephyr,resolution = <24>;
            zephyr,input-positive = <0>;
            zephyr,input-negative = <1>;
        };

        channel@1 {
            reg = <1>;
            zephyr,gain = "ADC_GAIN_1";
            zephyr,reference = "ADC_REF_INTERNAL";
            zephyr,acquisition-time = <ADC_ACQ_TIME_DEFAULT>;
            zephyr,resolution = <24>;
            zephyr,input-positive = <2>;
            zephyr,input-negative = <3>;
        };

        channel@2 {
            reg = <2>;
            zephyr,gain = "ADC_GAIN_1";
            zephyr,reference = "ADC_REF_INTERNAL";
            zephyr,acquisition-time = <ADC_ACQ_TIME_DEFAULT>;
            zephyr,resolution = <24>;
            zephyr,input-positive = <4>;
            zephyr,input-negative = <5>;
        };
	};
}

Note: the 24-bit read will not work with the examples in samples/drivers/adc/ since they assume 16-bit input. One has to change the buffer to int32_t to see the correct behavior.

The correct conversion (assume the read buffer is buf):

int32_t val = (int32_t)buf;
float my_fval_mv = 2500.0 * val / (1 << 23);

or

 int64_t my_val_mv = (int64_t)val * 2500 >> 23;

[benediktibk]

I've skipped through the list of precision ADC from TI (there are astonishingly plenty of them) and it looks like the pattern ads1x4s0x does not match something this driver doesn't (or shouldn't) support.

[benediktibk]

The rename commit should already reflect the changes as well for instance in the CMakeLists.txt. Basically, the usual approach is not to squash the commits but keep them as they are, but ensure that every commit by itself can be used respectively built.

[TerryGeng]

@benediktibk Sorry about the force push... I scraped my macro commit. The only changes are around the lines you commented on. Also, I added two read_sample functions for 16 and 24 bit devices inside two #ifdef branches, plus the supporting code in perform_read function.

I think I'm ready for you to review again.

[benediktibk]

As you are changing an already existing binding, could you please add a section to the release notes?
https://github.com/zephyrproject-rtos/zephyr/blob/main/doc/releases/migration-guide-4.1.rst

[TerryGeng]

Ok, done another round of fixups.

[TerryGeng]

@benediktibk Since you mentioned this, maybe I should also write something into the release note.

[benediktibk]

Mentioning the added support for the other types in the release notes would be the cherry on the top.

[anangl]

Looks good. A few nitpicking comments only.

[TerryGeng]

Ok, fixed the format issues.

[anangl]

LGTM. The first commit says that "this commit shall be squashed into the next one before merging". Do you still intend to do this? I think it could stay as it is now.

[TerryGeng]

@anangl Ok. I will keep them as they are now and edit the commit message to remove that line.

[TerryGeng]

Fixed commit message and updated release note. Rebased against main. Should be ready to go.