It uses KConfig (which is Linux specific-tool) and devicetree (which has origins in OpenFirmware but is nowadays maintained by Linux). And these are over-complicated overkill for MCUs. KConfig is oriented towards generating a nice-looking menu interface for kernel builders to pick and match from a set of well-tested configurations, it provides no debug aid for "where the option I enabled but didn't got into the build actually got rejected". DTS originally works as boot-time configuration format, which is silly for a MCU so Zephyr process it into a set of C macros. Not a bad idea in itself, but the error messages are as cryptic as it gets - and sometimes stuff get silently disabled because of a missing dependency with no build warning.
> Huh? What does this even mean?
You cannot have a portable interface for timers, comparators, peripheral interconnect, programmable logic - all the MCU goodies.
> That's literally how it an RTOS works.
You don't allocate a separate thread stack for something you do once an hour - not unless it's a high-criticality task. You don't constantly poll a sensor that consumes 10mA on a device that has 10µA idle consumption budget. Zephyr does have the facility to do this the right way: workqueues (which is also a ripoff of Linux workqueues nee bottom halves). But most stock device drivers (or the network stack for that matter) don't play well with these, I guess because of the bulky callback-driven interface.
>If you expect linux
I don't expect Linux. That's my point - you can't have Linux on embedded so why even bother with all the abstractions? Why bother with DTS and Kconfig when you still end with a set of header files to debug - except now they are also auto-generated unreadable mess?
> portability is incredibly smooth compared to other vendors
Oh, kconifg is great. Do you think arduino is better? lolno. Check out NXP or STM's solution, and kconfig makes way more sense. Again, my opinion.
>> You don't allocate a separate thread stack for something you do once an hour - not unless it's a high-criticality task. You don't constantly poll a sensor that consumes 10mA on a device that has 10µA idle consumption budget.
I know. But you said you were TRYING to do that. You invent a scenario then you explain why it is wrong.
I don't like to argue for the sake of arguing. Peace out.
It uses KConfig (which is Linux specific-tool) and devicetree (which has origins in OpenFirmware but is nowadays maintained by Linux). And these are over-complicated overkill for MCUs. KConfig is oriented towards generating a nice-looking menu interface for kernel builders to pick and match from a set of well-tested configurations, it provides no debug aid for "where the option I enabled but didn't got into the build actually got rejected". DTS originally works as boot-time configuration format, which is silly for a MCU so Zephyr process it into a set of C macros. Not a bad idea in itself, but the error messages are as cryptic as it gets - and sometimes stuff get silently disabled because of a missing dependency with no build warning.
> Huh? What does this even mean?
You cannot have a portable interface for timers, comparators, peripheral interconnect, programmable logic - all the MCU goodies.
> That's literally how it an RTOS works.
You don't allocate a separate thread stack for something you do once an hour - not unless it's a high-criticality task. You don't constantly poll a sensor that consumes 10mA on a device that has 10µA idle consumption budget. Zephyr does have the facility to do this the right way: workqueues (which is also a ripoff of Linux workqueues nee bottom halves). But most stock device drivers (or the network stack for that matter) don't play well with these, I guess because of the bulky callback-driven interface.
>If you expect linux
I don't expect Linux. That's my point - you can't have Linux on embedded so why even bother with all the abstractions? Why bother with DTS and Kconfig when you still end with a set of header files to debug - except now they are also auto-generated unreadable mess?
> portability is incredibly smooth compared to other vendors
That's an extremely low bar.