about the difference of device tree use method compare with linux?
I know the device tree mechanism is also applied in zephyr sdk, but it seems something diffferent compare with in linux.
in linux, the dtsi script file would be compiled to a binary blob which would be pared in running time, so, the driver would do some dynamically decision in running time to different branch.
but in zephyr sdk, the dts are commpiled to a intermidate dts script file, which would be parsed by tools before building process are held.
finally, the dts configuration would convert to header files,and just used in compile time, so cant used to do the branch control like linux.
is this right? and is there anyway to get the configuration in runtime in zephyr?
thnks for your help.
Your comment is correct - there is such a difference.
It is not dynamic because of performance reasons. All drivers would simply be bigger - thing not welcome in uC world.
Personally I am not convinced DTS should be used in Zephyr due to this limitation. Since it is not a separate system component you cannot embed HW configuration that would stay on the board regardless of the FW. Anyway somebody thought it would be nice to separate things related to HW into DTS. I think however that this splits configuration into two (HW vs FW) without any good use case.
If you want to keep configuration in runtime you should use settings. Otherwise you can create your own dedicated partition and store things there in any way you prefer.
On 22 Nov 2019, at 00:25, firstname.lastname@example.org wrote:
Run-time aspects aside, I (naively?) believe using a different language enforces a much cleaner and maintainable separation between generic code and hardware specific configuration.
The Linux kernel had both - weren't board files messy because mixing up the two? With a lot of duplication? It'd be nice if someone who remembers board files could comment.
Now this doesn't come for free: just google "device tree stable ABI" - which... I think indirectly proves the point about board files.
PS: I doubt anyone would suggest using C code for (K)configuration.