Questions about DEVICE_DEFINE() macro

[ofirshe]

1. I want to use the DEVICE_DEFINE() macro to define a device outside of Device Tree. However, when I define it in one file like this:

DEVICE_DEFINE(device_0, "device@0", NULL, NULL,
              NULL, NULL,
              POST_KERNEL, 0, NULL);

and then try to access it in another file using:
dev = DEVICE_GET(device_0);

I get the following error:
zephyr/include/zephyr/device.h:96:41: error: '__device_device_0' undeclared here

How can I resolve this issue?

2. Why can APPLICATION initialization level no longer be used for devices? I found it very useful because I want to initialize a device only after a module, which I initialize using SYS_INIT in APPLICATION level. I can achieve this by setting the device's initialization priority higher than the priority in SYS_INIT.

EDIT:
I noticed that the APPLICATION initialization level was removed in this PR by @gmarull: Remove a few deprecated items. Could you explain the reasoning behind this change? Also, what alternatives are available for developers who need to initialize non-DTS devices at the APPLICATION level? I'm asking because I want to set a device API (specifically sensor_api), which doesn't seem achievable with SYS_INIT.

Best Regards

[jukkar]

I get the following error:
zephyr/include/zephyr/device.h:96:41: error: '__device_device_0' undeclared here

It looks like the device is declared static so it cannot be accessed from other file like that.
But you can do const struct device *dev = device_get_binding("device@0"); in other file to get the device pointer.

[gmarull]

I already said why: you can't guarantee global variable name uniqueness, and so potential build failures due to clashing names.

[ofirshe]

the dev_id parameter passed to DEVICE_DEFINE could be used for uniqueness. In the documentation, it’s also described as "a unique token."

[gmarull]

And tell me how to do that on a tree where there's freedom on what you can write in there, plus app level devices, etc.

[ofirshe]

Sorry, I’m not sure I understand your question. My point is that all the macros—DEVICE_DEFINE, DEVICE_DT_DEFINE, DEVICE_GET, and DEVICE_DT_GET—are defined in the device.h header, so I would expect them to function similarly, especially since they take nearly the same parameters. I believe DEVICE_DEFINE is an excellent tool for defining a "virtual" device as needed by the user. Additionally, why restrict users from initializing these virtual devices at the application level?

[ofirshe]

Hey @gmarull,

Thanks for your responses. Could we revisit the issues I mentioned above? Would it be problematic to allow the creation of application-level virtual devices ? I'm not talking about DT devices that should be treated in kernel.

Thanks.

[jukkar]

For the reasoning of the removal of the APPLICATION level, see the commit beec8b0 that deprecated it.

[ofirshe]

Unfortunately, with this removal, I don’t see any feasible solution for the issue I raised in the second point. Can you maybe help @gmarull ?

[gmarull]

Device drivers should not be tied to any SYS_INIT. This can be problematic for pseudo-devices, like it happened in the past for LVGL "devices".

[ofirshe]

I don’t associate SYS_INIT with device drivers. In my case, I have a module providing a TCP-based communication interface, which I initialize using SYS_INIT at the application level. I set the priority higher than CONFIG_NET_CONFIG_INIT_PRIO to ensure it’s initialized only after the network device. This module exposes an API for other modules to use. I also want a non-DTS device to be initialized only after this module, as I need it for communicating with the device I'm interfacing with.