Remove usage of DT_INST in samples

[mbolivar-nordic]

Is your enhancement proposal related to a problem? Please describe.

Various samples use DT_INST(0, compat) to get the node identifier for a particular compatible. Using instance numbers in samples does more harm than good: explaining the semantics is quite complicated.

(Don't believe me? Have a look at the awful amount of text describing them in the DT_INST documentation.)

Putting the DT_INST macro in front of users just for the sake of getting a device should be considered an antipattern. It also has the problem that it forces users to understand devicetree node identifiers etc., which is a whole additional pile of complexity that 99.9% of people who just want to get a working const struct device* and move on within a simple sample application don't and should not care about.

Describe the solution you'd like

• Add a new macro, DEVICE_DT_GET_ANY(compat). This takes a devicetree compatible (in lowercase-and-underscore form) and gives you a straight up const struct device* created for that devicetree compatible.
• Use this in samples that just want to get a device by any means necessary for the purposes of showing off an API or a particular driver's implementation of it

Describe alternatives you've considered

In #30536, I originally tried adding sample specific aliases, but this got shot down for good reasons.

[mbolivar-nordic]

#30536 adds DEVICE_DT_GET_ANY. I will postpone switching other samples over to using it until after we get a chance to discuss the idea in dev-review.

[erwango]

Fully supporting the approach.

[gmarull]

+1

[pabigot]

As suggested in the first discussion below, this could be an opportunity to provide a small library of routines that would help make samples more uniform. Candidates for that library include:

• A function to retrieve and validate a device pointer.
• API to get the current kernel time in millisecond resolution in a readable standard format which I currently have replicated in multiple samples that track values over time.

Perhaps there are more.

Such a library isn't directly related to this, except that if it were available reworking the way samples get devices could be combined with general review and cleanup of the samples.

[jfischer-no]

Would it be appropriate time to introduce aliases or zephyr_ node labels for the common sensors and replace all samples that do the same thing, like x temperature sensor samples, with generic one?

[mbolivar-nordic]

As suggested in the first discussion below, this could be an opportunity to provide a small library of routines that would help make samples more uniform.

My general experience with previous attempts to do things like this has been uniformly negative, so I have reservations.

The problem is that such things have generally worked for their developers, but it's easy for hardcoded assumptions that the library code and the application code live in zephyr/samples to slip in.

When that happens, as a user trying to recursively copy a sample directory somewhere else in order to start building on top of it as my own application, I've been frustrated by needing to fight the build system to get access to the common code.

If the functionality is so commonly needed by zephyr applications that a large fraction of samples require it, then IMO it should be placed somewhere outside of samples, to preserve the usual layering and ability to build it into out of tree apps with Kconfig.

[mbolivar-nordic]

Would it be appropriate time to introduce aliases or zephyr_ node labels for the common sensors and replace all samples that do the same thing, like x temperature sensor samples, with generic one?

We've debated this, but I think this issue stands anyway. I agree that having a general purpose "temperature sensor sample" would be a good idea, but in practice people are going to want samples for specific drivers no matter what.

[pabigot]

My general experience with previous attempts to do things like this has been uniformly negative, so I have reservations.

The problem is that such things have generally worked for their developers, but it's easy for hardcoded assumptions that the library code and the application code live in zephyr/samples to slip in.

Fair enough, though I think that could be averted by some reasonable review and API design. E.g. my "timestamp" format is good for arbitrary durations extending to years; the only clear flaw is it uses a static buffer and that could be easily worked around with a now_str_r() variant like asctime_r(). (The name, of course, is completely inadequate.)

(I'm really more interested in getting that specific functionality into Zephyr somewhere it can be re-used so I don't have to keep having to paste it into applications when I'm trying to get time values in a readable format.)

If the functionality is so commonly needed by zephyr applications that a large fraction of samples require it, then IMO it should be placed somewhere outside of samples, to preserve the usual layering and ability to build it into out of tree apps with Kconfig.

Oh, absolutely, I wouldn't suggest a library that's restricted for use in samples and/or tests.

[mbolivar-nordic]

(I'm really more interested in getting that specific functionality into Zephyr somewhere it can be re-used so I don't have to keep having to paste it into applications when I'm trying to get time values in a readable format.)

I haven't looked at this case, but yeah, my general feeling is that these things should be coded as helper functions that live in the files which provide the subsystem functionality, rather than a "libsample" directory. Sounds like this one could be solved that way.