Arduino Joins Zephyr Project

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

Thank you!

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.

I would suggest using either an Arduino w/ BLE shield or a raspberry pi pico w. Both platforms have great SDKs and a lot of online support/community. Raspberry Pi pico supports circuitpython if that is the route you want to go (i.e. if you are more familiar with python). But most embedded software is written in C/C++.