3 ms·

>> Zephyr loves to reuse Linux tooling but it simply doesn't fit. What? It has its own tooling. >> What is implemented and tested directly by SoC vendors work

>> Zephyr loves to reuse Linux tooling but it simply doesn't fit. What? It has its own tooling. >> What is implemented and tested directly by SoC vendors works, Yes, that's the point. >> And HAL for MCUs is simply a pipedream. Huh? What does this even mean? >> Want to read this I2C sensor once an hour? Too bad, the build-in driver can only poll it constantly in a dedicated thread That's literally how it an RTOS works. I'm baffled by your complaint. It sounds like you just don't understand embedded programming. >> There is no common denominator like there is on desktop. Ah ok, there we go: found the problem. If you expect linux, then of course you'll miss all of the embedded patterns that Zephyr solves cross-platform. Their HAL works, their stacks work, the portability is incredibly smooth compared to other vendors. I just disagree with everything you've said in my experience using it, and working with companies that use it.

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

tliltocatl 10mo ago

> 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.