drivers: rename ads101x driver to ads1x1x

[baptleduc]

Contribution description

This PR renames the existing ads101x driver to ads1x1x.
The purpose of this change is to prepare the codebase and to simplify the review process for supporting both the ADS101x and ADS111x families in a unified driver.

No functional changes are introduced in this PR.
Only file names, Kconfig symbols, defines macros, and related references have been updated to reflect the new driver name.

This rename will simplify the review process for upcoming PR that extend the driver to handle the ADS111x family.

Testing procedure

Build and run existing tests/drivers/ads1x1x (now renamed accordingly) to confirm no regressions.

Issues/PRs references

A follow-up PR will introduce ADS111x support and internal handling of family-specific differences.

[riot-ci]

Murdock results

✔️ PASSED

9dfd1d1 drivers/ads101x: rename driver to ads1x1x

Success	Failures	Total	Runtime
10949	0	10950	10m:18s

Artifacts

• Documentation preview

[baptleduc]

The macro defines weren’t documented before I renamed them, which caused the CI to fail after the renaming.
What I don’t understand is how the CI passed before, since it shouldn’t have.

[leandrolanzieri]

The failure seems to be related to moving the Kconfig file:

kconfiglib.KconfigError: /tmp/dwq.0.1912543697952842/44aa831c8a8590889923f0e364609cb7/drivers/Kconfig:32: '/tmp/dwq.0.1912543697952842/44aa831c8a8590889923f0e364609cb7/drivers/ads101x/Kconfig' not found (in 'rsource "ads101x/Kconfig"'). Check that environment variables are set correctly (e.g. $srctree, which is unset or blank). Also note that unset environment variables expand to the empty string.

You probably need to also update this line:

RIOT/drivers/Kconfig

Line 32 in db7a67b

rsource "ads101x/Kconfig"

[baptleduc]

Ok it passed Murdock CI. But the static tests always failed because I didn't touch the documentation during the renaming process, and it was missing from the start.

[baptleduc]

So do I need to comment the macros for the review ?

[maribu]

The alternative to adding Doxygen comments documenting the macros would be to update the list of expected Doxygen errors. That list will contain exceptions for the old file, but is missing them for the new file.

[Teufelchen1]

Nice! Almost there.
You overlooked a name change for the dependency resolution and I would like to see an error message for the users of the old name, instructing them to switch to the new name. (Okay, that will be super short lived and obsolete once the followup PR is merged but eh, better do it right.)

I would propose this change to address both issues:

--- a/drivers/Makefile.dep
+++ b/drivers/Makefile.dep
@@ -4,8 +4,11 @@ ifneq (,$(filter adc%1c,$(USEMODULE)))
   USEMODULE += adcxx1c
 endif
 
-ifneq (,$(filter ads101%,$(USEMODULE)))
-  USEMODULE += ads101x
+ifneq (,$(filter ads101x,$(USEMODULE)))
+  $(error "Module ads101x got renamed to ads1x1x.")
+endif
+ifneq (,$(filter ads1x1%,$(USEMODULE)))
+  USEMODULE += ads1x1x
 endif
 
 ifneq (,$(filter apds99%,$(USEMODULE)))

[baptleduc]

+ifneq (,$(filter ads101x,$(USEMODULE)))
+  $(error "Module ads101x got renamed to ads1x1x.")
+endif
+ifneq (,$(filter ads1x1%,$(USEMODULE)))
+  USEMODULE += ads1x1x
 endif

Thanks for pointing that out, it should be fixed now!

I guess I also need to include this change in the branch of the follow-up PR.

However, I'm still a bit unsure about the purpose of this file. You mentioned that the change will be short-lived, but it should still be valid in the next PR, right?

[Teufelchen1]

I guess I also need to include this change in the branch of the follow-up PR.

Yes, you will have to rebase the other PR on this branch.

However, I'm still a bit unsure about the purpose of this file.

That file maps module names as provided by the user to actual drivers. For 1:1 matches that is indeed curious and seems unneccessary. But if you look closely at the old code that you just replaced, you can see a trailing % in the module name. Thats a placeholder telling make to match on any name that has this given prefix. Take a look GNU Make section $(filter pattern…,text).
Here it was used so that USEMODULE += ads1011 and += ads1010 would have triggered that the actual module ads101x would have been included.

ifneq (,$(filter ads101%,$(USEMODULE)))
   USEMODULE += ads101x
endif

(this made me just realise that we might have made a mistake and the error should also match on ads101% instead of ads101x? Can't look into it right now.)

You mentioned that the change will be short-lived, but it should still be valid in the next PR, right?

Yes'ish. I haven't thought about the exact implication for the follow-up driver. Maybe the followup will match on all names, including the old drivers name, in that case the error makes no sense. Maybe as an warning as compilation with old code will not work without adjusting the names? We will see once this is merged and the other PR becomes ready.

[baptleduc]

I guess I also need to include this change in the branch of the follow-up PR.

Yes, you will have to rebase the other PR on this branch.

However, I'm still a bit unsure about the purpose of this file.

That file maps module names as provided by the user to actual drivers. For 1:1 matches that is indeed curious and seems unneccessary. But if you look closely at the old code that you just replaced, you can see a trailing % in the module name. Thats a placeholder telling make to match on any name that has this given prefix. Take a look GNU Make section $(filter pattern…,text). Here it was used so that USEMODULE += ads1011 and += ads1010 would have triggered that the actual module ads101x would have been included.

ifneq (,$(filter ads101%,$(USEMODULE)))
   USEMODULE += ads101x
endif

Thank you for the explanation.

(this made me just realise that we might have made a mistake and the error should also match on ads101% instead of ads101x? Can't look into it right now.)

Yes you're right, I'm going to fixed this immediately.

You mentioned that the change will be short-lived, but it should still be valid in the next PR, right?

Yes'ish. I haven't thought about the exact implication for the follow-up driver. Maybe the followup will match on all names, including the old drivers name, in that case the error makes no sense. Maybe as an warning as compilation with old code will not work without adjusting the names? We will see once this is merged and the other PR becomes ready.
ok no problem

[baptleduc]

Hi @Teufelchen1, is it ok for you ? can we move forward by merging this PR ?

[Teufelchen1]

Two changes accidentally slipped into this PR and need to be removed.

[baptleduc]

Two changes accidentally slipped into this PR and need to be removed.

Sorry it was a mistake, it should be fixed now.