drivers/ads101x: Changes for Common ADC API

[gschorcht]

Contribution description

This PR provides

• the changes of ADS101x/ADS111x driver for compatibility with the ADC extension API in PR drivers/adc_ng: Added common ADC API #13247 which makes it possible to use ADS101x/ADS111x devices as ADC extensions.
• a shell based test application which demonstrates the use of the ADS101x/ADS111x devices
  as ADC extension

This PR serves as a proof-of-concept for the Common ADC API in PR #13247 using an example of an existing ADC driver.

Testing procedure

The test application can be used with up to two ADS101x/ADS111x devices. It is recommended to use two ADS1115 device where the the second ADS1115 is used as ADS1013 to see the differences between the two ADC extension devices. Compile the test application for any board that supports I2C.

CFLAGS="-DADS101X_PARAM_ADDR_2=\(0x49\) -DADS101X_PARAM_DEVICE_2=\(ADS101X_DEV_ADS1013\)" \
make flash -C tests/driver_ads101x_ext_api BOARD=...

Issues/PRs references

Depends on PR #13247

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[gschorcht]

Requires some work to make compatible with PR #13247.

[maribu]

Some comments inline.

I wonder if we couldn't get the test be driver independet. E.g. every non-peripheral driver could contain a check like this:

#if (ADC_NG_NUMOF == 1) && defined(MODULE_ADS101X)
const adc_ng_backend_t adc_ng_backends[ADC_NG_NUMOF] = {
    {
        .driver = &ads101x_adc_ng_driver,
        .handle = &ads101x_devs[0]
    }
};
#endif

Combined with auto-init this should just work without any support of either board or application, as long as exactly one ADC-NG driver (with only one entry in params) is used. I bet that this is also the common case. And only applications/boards actually having multiple ADCs would have go through the pain of providing the backends themselves.

Once the cross file arrays land in RIOT, this would also work without board/application support for any number of drivers :-)

[gschorcht]

Some comments inline.

I wonder if we couldn't get the test be driver independet. E.g. every non-peripheral driver could contain a check like this:

#if (ADC_NG_NUMOF == 1) && defined(MODULE_ADS101X)
const adc_ng_backend_t adc_ng_backends[ADC_NG_NUMOF] = {
    {
        .driver = &ads101x_adc_ng_driver,
        .handle = &ads101x_devs[0]
    }
};
#endif

Combined with auto-init this should just work without any support of either board or application, as long as exactly one ADC-NG driver (with only one entry in params) is used. I bet that this is also the common case. And only applications/boards actually having multiple ADCs would have go through the pain of providing the backends themselves.

Once the cross file arrays land in RIOT, this would also work without board/application support for any number of drivers :-)

👍 Seems to be a good idea. I suppose you would place that code fragment in the drivers code.

[gschorcht]

Seems to be a good idea. I suppose you would place that code fragment in the drivers code.

To place this in drivers code requires to make ads101x_devs visible, i.e. , to remove keyword static which is already the case for some other drivers. Furthermore, auto-init only works when saul is enabled.

[gschorcht]

Seems to be a good idea. I suppose you would place that code fragment in the drivers code.

To place this in drivers code requires to make ads101x_devs visible, i.e. , to remove keyword static which is already the case for some other drivers. Furthermore, auto-init only works when saul is enabled.

@maribu It works indeed without any board definition if module saul_default is used and the driver code reuses the devices that are auto-initialized in sys/aut-init/saul. In fact, the only difference to tests/adc_ng is that module adc_ng_default is no used and modules ads101x and saul_default are used. main.c is exactly the same.

The question is how we can test each ADC driver that supports adc_ng without duplicating the test. It would be great if RIOT's test architecure would support variants of the same test application.

[maribu]

if module saul_default

I'm working on a PR to split auto-initialization of the drivers and SAUL, so that sensors/actuators can also be auto-initialized in case SAUL is not used.

It would be great if RIOT's test architecure would support variants of the same test application.

Some tests can be controlled using environment parameters. E.g. we could introduce a variable like

BACKEND ?= periph_adc_ng

and if someone would run with BACKEND=ads101x make instead, the ads101x backend would be chosen instead. That might not be a solution for hardware in the loop testing, but for manual testing this should be fine.

[gschorcht]

if module saul_default

I'm working on a PR to split auto-initialization of the drivers and SAUL, so that sensors/actuators can also be auto-initialized in case SAUL is not used.

👍

Some tests can be controlled using environment parameters. E.g. we could introduce a variable like

BACKEND ?= periph_adc_ng

and if someone would run with BACKEND=ads101x make instead, the ads101x backend would be chosen instead. That might not be a solution for hardware in the loop testing, but for manual testing this should be fine.

Hm, that still can't be automated. What I meant is to have a script that automatically compiles and tests variants of the same test application, for example for different BACKEND modules.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[maribu]

Not stale, I'll resume work on the ADC-NG API hopefully soon. Then this can get in as well :-)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.