> Zephyr blows away Arduino<p>Zephyr is basically "let's have the nice things from Linux on small MCUs" and it sucks. Yes, it is numbers of magnitude better than vendor-specific not-quite-RTOS crap. It blows away Arduino because Arduino is an educational environment just a step above Scratch. Zephyr still sucks. And there is no hope of fixing it because it doesn't suck because the authors did a bad job. They did a fantastic job and it still sucks because the approach fundamentally doesn't work.<p>Zephyr loves to reuse Linux tooling but it simply doesn't fit. Kconfig silently disabling options because of missing dependencies sucks. No, I'm not using menuconfig, thank you very much, navigating a million of menus is the last thing I need. DTS to C macros abomination sucks. Tons of CMake scripts scattered over every directory suck.<p>The build in-drivers? What is implemented and tested directly by SoC vendors works, the rest is unusable for anything but example project. Want to use an external SPI flash? Too bad the driver doesn't implement any power management, program it all yourself or accept a constant 12mA draw (fine for many projects, absolutely unacceptable for some). Want to read this I2C sensor once an hour? Too bad, the build-in driver can only poll it constantly in a dedicated thread, just write one yourself. Not like that's a big job, but the build-in driver would be infinitely more useful if it just defined the register map in a header.<p>And worse yet, Zephyr doesn't do anything to actually solve the silicon lock-in problem, because it's not something that can be solved by new abstractions. Peripheral interconnect, interval timers and basically any peripheral that isn't I2C or UART is simply impossible to abstract over in a useful way. There is no common denominator like there is on desktop.<p>IMHO, FreeRTOS is a much better system simply because it doesn't tries to be a HAL. It switches between threads and that's it. And HAL for MCUs is simply a pipedream. If you can afford a HAL, go with Linux on a SoC large enough for that.
Nothing you've said is wrong, but I strongly disagree that it sucks.<p>The DTS error messages are awful, but having declarative configs with compile time validation is amazing once you've figured out what the errors actually mean. Writing drivers is just something you accept for board bringup, so that's basically a non-issue for me.<p>West's main problem is that it's just a weird little custom tool, not that it's annoying in itself. It's a large improvement over most other
embedded build systems, especially the config tools offered by TI and NXP.<p>And in exchange for those things you get an extremely capable RTOS with a decent shell, good features, and one of the best RTOS networking stacks out there. When you want to rev the layout 2, 3, 4 times or even make a new board entirely, it's straightforward to reuse all the effort in your initial bringup. A FreeRTOS system is much less reusable and has proportionally more schedule risk.
I guess that's depends on the application. What I had was a series of wireless DAQ devices with a common application core but different sets of sensors (and hence drivers). Some are as simple as "read and I2C value and put in into uplink queue" and that's where I often made the mistake to assume I could rely on stock drivers. Other are fully driven from the MCU's analog guts. Once the application core was there on one board I quickly found myself spending 50% of my time fighting against DTS.<p>FreeRTOS is much less reusable, but that means you are confidently pessimistic about schedule risk. That's an RTOS and that's it. The rest is on you and you know it. With Zephyr you get tons of support infrastructure, but you also risk finding that it doesn't fit too late in the process. E.g. the flash chip power management issue was quite bad - we ended up dropping the features that required an external flash altogether.<p>Then again, Zephyr is the best we have got, but I feel it's due to the Zephyr team's dedication to details - and in spite, not thanks to, the general approach.
>> Zephyr loves to reuse Linux tooling but it simply doesn't fit.<p>What? It has its own tooling.<p>>> What is implemented and tested directly by SoC vendors works,<p>Yes, that's the point.<p>>> And HAL for MCUs is simply a pipedream.<p>Huh? What does this even mean?<p>>> Want to read this I2C sensor once an hour? Too bad, the build-in driver can only poll it constantly in a dedicated thread<p>That's literally how it an RTOS works. I'm baffled by your complaint. It sounds like you just don't understand embedded programming.<p>>> There is no common denominator like there is on desktop.<p>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.<p>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.
> What? It has its own tooling.<p>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.<p>> Huh? What does this even mean?<p>You cannot have a portable interface for timers, comparators, peripheral interconnect, programmable logic - all the MCU goodies.<p>> That's literally how it an RTOS works.<p>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.<p>>If you expect linux<p>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?<p>> portability is incredibly smooth compared to other vendors<p>That's an extremely low bar.
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.<p>>> 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.<p>I know. But you said you were TRYING to do that. You invent a scenario then you explain why it is wrong.<p>I don't like to argue for the sake of arguing. Peace out.