5 ms·

What do you mean "vendor lock in"? Developers become accustomed to a particular SDK, and it is hard to move to new silicon because you need to relearn where the

What do you mean "vendor lock in"? Developers become accustomed to a particular SDK, and it is hard to move to new silicon because you need to relearn where the peripherals differ. If that's what you mean, I don't consider that lock-in, just inertia, but by your definition the Arduino SDK is "vendor lock in" (for all but the most trivial code it is portable). ESP32 integration with Arduino's ecosystem is severely limited to just a handful of APIs, and you need to use the ESP32 function calls if you want to do anything sophisticated (and idf.py). The Arduino API is too topical. I know from experience. Zephyr blows away Arduino, it has portable stacks, security, update, wifi/ble, etc... Also, near everyone is offering GCC/LLVM/IAR/ARMCC (except for Synopsys ARC and Renesas RX).

LarsKrimi 10mo ago
Zephyr is a baby project. From the embedded devs I know they have only started seriously considering Zephyr in the last 2-3 years for commercial projects. And you may call it inertia sure, but in the mid 2000's everyone was doing their own hardware abstraction. You had to get books and stuff because documentation sucked. MCU vendors seemingly made a point of making especially stuff like ADCs and timers very hard to abstract away between vendors. Back then you had a choice of GCC/IAR/KEIL/CCS/Codwarrior and probably more. Each worse and less standards-compliant than the next, except for GCC/avr-gcc as was the key enabler of Arduino All that text to say: The situation was different, and Arduino showed that there's a wider unmet demand for custom embedded stuff and that people will sacrifice a bit of performance for something that's easy to develop
- ACCount37 10mo ago
  "People will sacrifice a bit of performance" was also enabled by all the MCU advances. Those bytes of memory really mattered when 512B was all the RAM you'll ever get. Nowadays, you can buy a RTOS capable 32-bit MCU for $0.20. Why count bytes when you can just... not?
  - addaon 10mo ago
    > Why count bytes when you can just... not? The amount of memory used defines the size of the state space of the system — with exponential growth in the number of representable states. The amount of testing needed to have confidence in the behavior of a system grows (and I’d state based on experience, but without proof, grows faster than logarithmically) with the size of the state space. Building smaller, simpler systems is still the key to being able to realistically test and define behavior at high confidence levels, regardless of the price of a bit.
    - ACCount37 10mo ago
      I fail to think of many cases where such an approach would be warranted at all.
- why-o-why 10mo ago
  >> Zephyr is a baby project Most white box appliance makers use zephyr, so do some popular Wifi camera systems, and every major embedded SOC/MCU maker supports it. If that's a baby project, why don't you tell me what a "mature" project is?
  - LarsKrimi 10mo ago
    > Most white box appliance makers use zephyr Most? Like who? Looking at Zephyr's member page it's just chip vendors
    - why-o-why 10mo ago
      Can't say, and you're not obliged to believe me. The vendors are just the companies supporting it. Companies that use it aren't going to announce it. Think about it: if it is just vendors on the site that would mean nobody is using it.
tliltocatl 10mo ago
> Zephyr blows away Arduino 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. 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. 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. 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. 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.
- AlotOfReading 10mo ago
  Nothing you've said is wrong, but I strongly disagree that it sucks. 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. 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. 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.

LarsKrimi 10mo ago

Zephyr is a baby project. From the embedded devs I know they have only started seriously considering Zephyr in the last 2-3 years for commercial projects. And you may call it inertia sure, but in the mid 2000's everyone was doing their own hardware abstraction. You had to get books and stuff because documentation sucked. MCU vendors seemingly made a point of making especially stuff like ADCs and timers very hard to abstract away between vendors. Back then you had a choice of GCC/IAR/KEIL/CCS/Codwarrior and probably more. Each worse and less standards-compliant than the next, except for GCC/avr-gcc as was the key enabler of Arduino All that text to say: The situation was different, and Arduino showed that there's a wider unmet demand for custom embedded stuff and that people will sacrifice a bit of performance for something that's easy to develop

ACCount37 10mo ago
"People will sacrifice a bit of performance" was also enabled by all the MCU advances. Those bytes of memory really mattered when 512B was all the RAM you'll ever get. Nowadays, you can buy a RTOS capable 32-bit MCU for $0.20. Why count bytes when you can just... not?
- addaon 10mo ago
  > Why count bytes when you can just... not? The amount of memory used defines the size of the state space of the system — with exponential growth in the number of representable states. The amount of testing needed to have confidence in the behavior of a system grows (and I’d state based on experience, but without proof, grows faster than logarithmically) with the size of the state space. Building smaller, simpler systems is still the key to being able to realistically test and define behavior at high confidence levels, regardless of the price of a bit.
  - ACCount37 10mo ago
    I fail to think of many cases where such an approach would be warranted at all.
why-o-why 10mo ago
>> Zephyr is a baby project Most white box appliance makers use zephyr, so do some popular Wifi camera systems, and every major embedded SOC/MCU maker supports it. If that's a baby project, why don't you tell me what a "mature" project is?
- LarsKrimi 10mo ago
  > Most white box appliance makers use zephyr Most? Like who? Looking at Zephyr's member page it's just chip vendors
  - why-o-why 10mo ago
    Can't say, and you're not obliged to believe me. The vendors are just the companies supporting it. Companies that use it aren't going to announce it. Think about it: if it is just vendors on the site that would mean nobody is using it.

tliltocatl 10mo ago

> Zephyr blows away Arduino 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. 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. 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. 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. 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.

AlotOfReading 10mo ago
Nothing you've said is wrong, but I strongly disagree that it sucks. 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. 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. 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.