4 ms·

> What? It has its own tooling. It uses KConfig (which is Linux specific-tool) and devicetree (which has origins in OpenFirmware but is nowadays maintained by

> What? It has its own tooling. 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.

why-o-why 10mo ago
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.

why-o-why 10mo ago

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.