
Zephyr: A scalable Real-Time operating system for IoT embedded devices - kqr2
https://www.zephyrproject.org/
======
jpm_sd
[https://www.zephyrproject.org/what-is-
zephyr/](https://www.zephyrproject.org/what-is-zephyr/)

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.

~~~
morning_gelato
Zephyr seems like the best shot at getting an open source RTOS in safety-
critical environments, pretty exciting.

~~~
joezydeco
I’ve been developing on Zephyr for about a year now and “exciting” isn’t the
word I would use here.

~~~
sickcodebruh
Can you tell us about your experience with it?

~~~
joezydeco
The build system is a mess. Recently switched from GNU make to CMake and it’s
still doing all kinds of weird stuff.

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

~~~
SlowRobotAhead
Does that make FreeRTOS out to be FreeRTOS for when your boss says you can’t
use Amazon?

------
an_d_rew
So I've contributed a couple of (tiny!) patches to Zephyr and wrote my own
board support / devicetree setup for a custom Cortex-M4F setup that I
designed.

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...)!

~~~
SlowRobotAhead
Total opposite. I’m having much more luck with FreeRTOS now that it’s an
Amazon product than I was with Zephyr. I’m using it with AWS though, so this
isn’t much of a surprise.

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.

~~~
bsder
Nordic signed on for Zephyr and Segger Embedded Studio.

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.

~~~
SlowRobotAhead
Agreed! They insist they aren’t dumping their stack (yes they are) but
incorporating ideas in to Zephyr.

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.

------
smarx007
Is there an comparison to FreeRTOS and mbed? I could not find a good article
online so far. There is a "Why create another RTOS?" section under
[https://www.zephyrproject.org/what-is-
zephyr/](https://www.zephyrproject.org/what-is-zephyr/) but it's very light on
details.

~~~
travisgriggs
I found this link ([https://www.osrtos.com/](https://www.osrtos.com/)) really
useful 2 years ago. I don't know how up to date it is. In the end I went with
a little known entry called TNEO because I liked Frank Dmitry's writup about
it.

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.

------
louib
I think this is one of the OSes that PINE64 intends to support for their
upcoming PineTime
[https://wiki.pine64.org/index.php/PineTime](https://wiki.pine64.org/index.php/PineTime)

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

------
xvilka
Still C... I have more hopes for Rust-written RTOS. Like Tock[1][2] or Drone
OS[3][4].

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

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

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

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

~~~
bfrog
I'm quite fond of the idea of single stack, rtfm and drone are particularly
interesting!

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

------
bfrog
Zephyr is quite nice and I've personally contributed some stuff, the general
issues with it I think stem from IoT as a whole. People build products and
move on to the next one. So sometimes drivers can be broken at times. It's
still a RTOS and leads to common RTOS issues. The most frustrating to me is
stack sizing. It's very easy to undersize a stack for a thread and not find
out for quite awhile until something goes annoyingly wrong.

------
SEJeff
It supports the esp32, but not the esp8266 :(

------
baybal2
> VxWorks

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.

~~~
TickleSteve
Contrary to your experience, VxWorks has a very good reputation in the
embedded/real-time industry. I've used it in many projects myself.

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.

------
amq
How does it compare to ARM Mbed OS?

------
bborud
It is fun until you have to actually use it for development. Then it is not so
much fun.

