5 ms·

Arduino Joins Zephyr Project

43 points by manchoz 3y ago

gmiller123456 3y ago
Can anyone explain what this means for Arduino users? The article seems to be a lot of marketing speak, and for people familiar with Zephyr already.
- SAI_Peregrinus 3y ago
  Zephyr is a real-time operating system (RTOS). It's got a lot of compile-time configuration capability, and a (IMO) very nice module system that makes organizing embedded code easier. Being able to use Device Tree to organize hardware peripherals is particularly nice. It's also got a lot of peripheral drivers included, many useful libraries, a unit testing framework, and a nice set of built-in samples. Zephyr does have some obvious downsides: it uses a custom build tool (West) to in turn use KConfig to select various options for CMake which then uses Ninja or Make to build the actual source. That means the build process is complex, hard to understand fully, and difficult to troubleshoot. The included libraries and drivers are usually good, but as with any code it's always harder to understand code you didn't write (or wrote a long time ago), and tend to be a higher level of abstraction than you might need (and thus a bit less efficient in some cases than you'd want). Arduino's base APIs with the Arduino "IDE" are similarly opaque. Zephyr will make quite a few things easier, since it'll come with device tree files for the various Arduino boards. If you're doing particularly simple projects, Zephyr is overkill. If you've got multiple interacting components, an RTOS becomes extremely helpful.
bfrog 3y ago
It makes sense if you consider the devices being made now are faster and more complex than ever. Multi core SoCs with different archs and memory protection schemes all sharing a bus. This complexity can be wrangled with device tree and Zephyr readily and has good company with other large silicon vendors being contributors. I for one am looking forward to seeing more contributions and companies joining.
- crote 3y ago
  It's a bit of a tradeoff, really. The upside is that you no longer have to essentially write an entire OS if you just want to make a light blink, making it way easier to get started with a complicated project. The downside is that all those layers of abstraction make it really hard to figure out what is actually going on, and they can quickly get in the way when you are trying to do something which isn't a 1:1 match to the high-level model used.
lionkor 3y ago
I've had the pleasure of using Zephyr OS on an embedded bluetooth project with a few others. We were using NRF52x chips, with a dev board, and Zephyr was one of the least painful parts of the whole thing. Can absolutely recommend Zephyr in general.
- kenmacd 3y ago
  Zephyr has a lot of good points, but I really wish it didn't use Kconfig. Getting a working config seems to be mostly a matter of copying an already working example. It might be okay for hardware side of things, but it's a really bad at software/feature dependency. Set https://docs.zephyrproject.org/latest/build/kconfig/tips.html#select-pitfalls https://docs.zephyrproject.org/latest/build/kconfig/tips.htm... and the issue: https://github.com/zephyrproject-rtos/zephyr/issues/52575 https://github.com/zephyrproject-rtos/zephyr/issues/52575. And don't even get me started on trying anything to group options together.
  - elevation 3y ago
    Could Zephyr's difficulties be resolved if Kconfig supported an additional operator besides 'select' and 'depends on'? Or perhaps with an overlay capability like bitbake has? Since Kconfig is used to configure the kernel, why aren't the kernel devs experiencing similar issues with their configurations?
    - tonyarkles 3y ago
      I need to double-check this, but I’m pretty sure it does have an overlay-type capability through West. Definitely does on the devicetree side, but I’m pretty sure it does on the Kconfig side too.
    - kenmacd 3y ago
      I would think so. I've tried to do 'feature' groups of options, but without any way to do optional includes I gave up on that idea. Maybe I'm just doing it wrong with just trying to add the dependencies I want. It might work better if I used the menuconfig GUI. To me though it seems if I decide I want to enable 'CONFIG_NET_TCP' on my project, I shouldn't also have to specify 'CONFIG_NETWORKING'. As for why it works better in the kernel, that's a good question that I don't know the answer to as it's been years since I tried to build a kernel with a minimum configuration.
genmud 3y ago
Zephyr is such a great project, I really have enjoyed working with it and the Nordic (NRF5x) is awesome. I think over the next 3-5 years it is really going to get more and more adoption compared to alternatives like freertos or vxworks.
idank 3y ago
is Zephyr a good option in a project that aims to expose a UART device through BLE using an nrf52x chip? At a glance it seems pretty low level, capable and possibly overkill. If not, what's more suitable? Hopefully that makes sense, I'm new to all of this.
- bathMarm0t 3y ago
  Just recalling what I did a couple years ago. Bluetooth is an absolute nightmare if you don't understand the majority of what's going on (which in and of itself takes... a lot of time). There's a bunch of logic going on and most of it is handled in callbacks that you will never see, except the dreaded timeout/failure to handle print at the end of the main loop. Zephyr will ease a lot of those painpoints, with the understanding that you're ignoring a lot of the machinery humming under your feet. Things that stood out to me: 0. If this is your first embedded project / you're actually new to all of this, get ready to take a beating. "Abandon all hope, ble who enter here." 1. Do yourself a huge favor and get two* dev kits. Nordic provides walkthroughs on getting setup with two flavors of code (zephyr, or low-level drivers). Each has a tutorial for uart forwarding/handling. Expanding on that tutorial will take a lot of futzing around, or actually learning what the machinery is doing under the hood. Learning the stack did not come naturally / I found it very difficult. Why two? Two lets the bluetooth abstraction handle itself / you don't have to deal with it right away when you're getting started. https://www.nordicsemi.com/Products/Development-hardware/nRF52-DK https://www.nordicsemi.com/Products/Development-hardware/nRF... 2. If / when you want to attach your bluetooth device to something more useful (e.g. a computer or mobile device), do yourself a second huge favor and develop using linux + a laptop. I tried to do development on windows + WSL and there were many, many hangups with the hardware handoffs from PyBlues to the local bluetooth drivers. Maybe it's gotten better, but I doubt it. My other alternatives were driving direct from Windows bluetooth libraries (behemoths that would take time to setup / understand), or develop for mobile (which also will take time to setup / understand). Neither was an enjoyable experience. so in summary: Is Zephyr overkill? - Absolutely. But the path is well trodden.
  - idank 3y ago
    Thank you!

43 points by manchoz 3y ago

Can anyone explain what this means for Arduino users? The article seems to be a lot of marketing speak, and for people familiar with Zephyr already.

SAI_Peregrinus 3y ago
Zephyr is a real-time operating system (RTOS). It's got a lot of compile-time configuration capability, and a (IMO) very nice module system that makes organizing embedded code easier. Being able to use Device Tree to organize hardware peripherals is particularly nice. It's also got a lot of peripheral drivers included, many useful libraries, a unit testing framework, and a nice set of built-in samples. Zephyr does have some obvious downsides: it uses a custom build tool (West) to in turn use KConfig to select various options for CMake which then uses Ninja or Make to build the actual source. That means the build process is complex, hard to understand fully, and difficult to troubleshoot. The included libraries and drivers are usually good, but as with any code it's always harder to understand code you didn't write (or wrote a long time ago), and tend to be a higher level of abstraction than you might need (and thus a bit less efficient in some cases than you'd want). Arduino's base APIs with the Arduino "IDE" are similarly opaque. Zephyr will make quite a few things easier, since it'll come with device tree files for the various Arduino boards. If you're doing particularly simple projects, Zephyr is overkill. If you've got multiple interacting components, an RTOS becomes extremely helpful.

bfrog 3y ago

It makes sense if you consider the devices being made now are faster and more complex than ever. Multi core SoCs with different archs and memory protection schemes all sharing a bus. This complexity can be wrangled with device tree and Zephyr readily and has good company with other large silicon vendors being contributors. I for one am looking forward to seeing more contributions and companies joining.

crote 3y ago
It's a bit of a tradeoff, really. The upside is that you no longer have to essentially write an entire OS if you just want to make a light blink, making it way easier to get started with a complicated project. The downside is that all those layers of abstraction make it really hard to figure out what is actually going on, and they can quickly get in the way when you are trying to do something which isn't a 1:1 match to the high-level model used.

lionkor 3y ago

I've had the pleasure of using Zephyr OS on an embedded bluetooth project with a few others. We were using NRF52x chips, with a dev board, and Zephyr was one of the least painful parts of the whole thing. Can absolutely recommend Zephyr in general.

kenmacd 3y ago
Zephyr has a lot of good points, but I really wish it didn't use Kconfig. Getting a working config seems to be mostly a matter of copying an already working example. It might be okay for hardware side of things, but it's a really bad at software/feature dependency. Set https://docs.zephyrproject.org/latest/build/kconfig/tips.html#select-pitfalls https://docs.zephyrproject.org/latest/build/kconfig/tips.htm... and the issue: https://github.com/zephyrproject-rtos/zephyr/issues/52575 https://github.com/zephyrproject-rtos/zephyr/issues/52575. And don't even get me started on trying anything to group options together.
- elevation 3y ago
  Could Zephyr's difficulties be resolved if Kconfig supported an additional operator besides 'select' and 'depends on'? Or perhaps with an overlay capability like bitbake has? Since Kconfig is used to configure the kernel, why aren't the kernel devs experiencing similar issues with their configurations?
  - tonyarkles 3y ago
    I need to double-check this, but I’m pretty sure it does have an overlay-type capability through West. Definitely does on the devicetree side, but I’m pretty sure it does on the Kconfig side too.
  - kenmacd 3y ago
    I would think so. I've tried to do 'feature' groups of options, but without any way to do optional includes I gave up on that idea. Maybe I'm just doing it wrong with just trying to add the dependencies I want. It might work better if I used the menuconfig GUI. To me though it seems if I decide I want to enable 'CONFIG_NET_TCP' on my project, I shouldn't also have to specify 'CONFIG_NETWORKING'. As for why it works better in the kernel, that's a good question that I don't know the answer to as it's been years since I tried to build a kernel with a minimum configuration.

genmud 3y ago

Zephyr is such a great project, I really have enjoyed working with it and the Nordic (NRF5x) is awesome. I think over the next 3-5 years it is really going to get more and more adoption compared to alternatives like freertos or vxworks.

idank 3y ago

is Zephyr a good option in a project that aims to expose a UART device through BLE using an nrf52x chip? At a glance it seems pretty low level, capable and possibly overkill. If not, what's more suitable? Hopefully that makes sense, I'm new to all of this.

bathMarm0t 3y ago
Just recalling what I did a couple years ago. Bluetooth is an absolute nightmare if you don't understand the majority of what's going on (which in and of itself takes... a lot of time). There's a bunch of logic going on and most of it is handled in callbacks that you will never see, except the dreaded timeout/failure to handle print at the end of the main loop. Zephyr will ease a lot of those painpoints, with the understanding that you're ignoring a lot of the machinery humming under your feet. Things that stood out to me: 0. If this is your first embedded project / you're actually new to all of this, get ready to take a beating. "Abandon all hope, ble who enter here." 1. Do yourself a huge favor and get two* dev kits. Nordic provides walkthroughs on getting setup with two flavors of code (zephyr, or low-level drivers). Each has a tutorial for uart forwarding/handling. Expanding on that tutorial will take a lot of futzing around, or actually learning what the machinery is doing under the hood. Learning the stack did not come naturally / I found it very difficult. Why two? Two lets the bluetooth abstraction handle itself / you don't have to deal with it right away when you're getting started. https://www.nordicsemi.com/Products/Development-hardware/nRF52-DK https://www.nordicsemi.com/Products/Development-hardware/nRF... 2. If / when you want to attach your bluetooth device to something more useful (e.g. a computer or mobile device), do yourself a second huge favor and develop using linux + a laptop. I tried to do development on windows + WSL and there were many, many hangups with the hardware handoffs from PyBlues to the local bluetooth drivers. Maybe it's gotten better, but I doubt it. My other alternatives were driving direct from Windows bluetooth libraries (behemoths that would take time to setup / understand), or develop for mobile (which also will take time to setup / understand). Neither was an enjoyable experience. so in summary: Is Zephyr overkill? - Absolutely. But the path is well trodden.
- idank 3y ago
  Thank you!