The Zephyr Project’s goal is to establish a neutral project where silicon vendors, OEMs, ODMs, ISVs, and OSVs can contribute technology to reduce the cost and accelerate time to market for developing the billions of devices that will make up the majority of the Internet of Things

The Zephyr Project is perfect for building simple connected sensors, LED wearables, up to modems and small IoT wireless gateways. Because the Zephyr OS is modular and supports multiple architectures, developers are able to easily tailor an optimal solution to meet their needs. As a true open source project, the community can evolve the project to support new hardware, developer tools, sensor and device drivers. Enhancements in security, device management capabilities, connectivity stacks and file systems can be easily implemented.

The Zephyr kernel is derived from Wind River’s commercial VxWorks Microkernel Profile for VxWorks. Microkernel Profile has evolved over 20 years from DSP RTOS technology known as Virtuoso. The RTOS has been used in several commercial applications including satellites, military command and control communications, radar, telecommunications and image processing. The most recent example of the technology’s success is the successful Philae Landing on Comet Churyumov–Gerasimenko and the accompanying Rosetta Orbiter.

Uses Devicetree to configure drivers but doesn’t use it like Linux, stuff gets munged into C #define macros and there’s no runtime access like a DTB section.

Scheduler is still doing bad stuff, preemption is broken on certain architectures.

There is no mainline Cortex-A port yet. Some chipmakers have done it but won’t share it.

Drivers are constantly in flux.

Ugh I could go on but won’t.

I would label Zephyr as “FreeRTOS for when your boss says you can’t use Linux.”

I compile with ARM’s GCC toolchain, nothing exotic about compile time or other safety checks on C code.

Zephyr is awesome and the community is awesome, IMHO.

Using CLion to manage the CMake-based build is awesome.

What's not quite so awesome? The plethora of Kconfig items. Even with "make menuconfig" it can be very difficult to keep track of what you've configured in and what you've configured out.

For 90% of most projects, I'd expect the defaults to be sane. In fact, probably better than the ones an inexperienced dev would select.

But when you want that last 10%, it can be a real challenge.

I've had much more luck with Zephyr than I did with FreeRTOS or mbed (and I've used mbed a lot...)!

I’m not sure it’ll go anywhere, but I think it’s no coincidence zephyr is setting up to support multiple cores - and Nordic just released a dual core chip and signed on early to Zephyr.

Nordic clearly are signaling "we're tired of spending money on infrastructure software".

I hope they know what they are doing. IMO, the Nordic BLE stack was one of their primary competitive advantages.

That said, they were definitely on the wrong track with SDKs that wildly changed every 6 months and were almost impossible to keep up with!

Their stack being FCC certified is a huge bonus. Saves weeks of work and $10,000 or so to not have to do full FCC cert instead of just emission testing.

As to Segger Studio, it’s Rowley Crossworks and while I miss a couple of things from Keil it has been an overall better experience for some reason.

It's really hard to compare these things though. Zephyr is like a mini Linux complete with device tree, build system, configuration files and drivers. All of which you get to determine the correctness of.

Something like FreeRTOS can seem both much simpler and harder. It's mostly just C Source. If you need a stack or a driver, you get to own that yourself. But it's like, right there in front of you. No need to learn somebody else's favorite build system, etc. Do what makes most sense for you.

We went with TNEO because the ultimate feature we needed was aggressive processor sleep ability for power savings. I have not found any that solve this well out of the box. They're built for demo boards that stay plugged into the wall. And to be fair, there's a size-able chunk of IoT devices that sit near lots of power.

I asked a former coworker who helped me with TNEO (and before that he and I had worked quite a bit with FreeRTOS and RIOT as well as a lot of just no RTOS) how he's liking Zephyr in his new job. He said it was hell to set up and get working right, but the slack community around it had been helpful, but seemed to be nice at the moment, especially since they were using chipsets it was know to work well on. He did note that the power save story was no better than our previous experiences, but he's working on powered devices.

[1] https://www.tockos.org/

[2] https://github.com/tock/tock

[3] https://www.drone-os.com/

[4] https://github.com/drone-os

I really appreciate the shared libraries in rust for soc support and Hal's. It's quite nice

I wonder what's the development status, they were initially aiming to ship around Q1 2020.

For me, this is enough to cross it out on day one.

C style tooling on proprietary MCU platforms is bad beyond any redemption.

Vx ecosystem has given me sooo much bad blood over the past decade. I have a lot of reservations about if just slapping an opensouce facelift on their SDK can right all its wrongs.

It performs well, integrates well, runs on most things you can want and everything supports it. Its pretty much the de-facto standard in defence circles.