My Zephyr RTOS notes

Started 9Jul2019 as chapters being moved from other notes. Updated 16Jul2019

This page is in group Technology and is a blog note where I will try to keep a scratchpad of what I might find out about the Zephyr RTOS.

Sharing Zephyr with others

Because I was rather confused I have had help from a Zephyr project member to set up this list.

  • There is a How to contribute page (here)
  • The Zephyr developers and community’s main forum seems to be mostly present on Slack (here). I registered and am quite confused at the moment. But I finally found it in Wikipedia (here). Slack Technologies is a company and they provide four plans: Free, Standard, Plus and Enterprise Grid. I hope all Zephyr stuff that’s interesting to me as available on the Free plan. They say that “your workspace is currently on Slack’s Free plan”. Good to know. I have ID UL7923B4G
    • I think what Slack means when they talk about “Your organisation” is the Zephyr project
    • Most activity happens on the #General channel. #Random is the more informal chatroom channel
  • There are a number of mailing lists (here)
  • There also are public weekly calls (here)
  • Old fashioned(?) forums don’t seem to be used so much. I think there is one at Google’s place, but that’s kind of not where the action is (here)

Zephyr on Nordic Semiconductor

See here.

CSP examples of Zephyr?

16Jul2019: I think/hope started my first thread at Slack, starting with I wonder where I could find the most channel/select-like examples of Zephyr usage.

Historical note

See Wikipedia, here – where it says that Zephyr was originally developed as Rocket by Wind River Systems, for IoT, then it became a project for the Linux Foundation. It is based on Wind River’s Microkernel Profile for VxWorks.

Aside: The operating system came from Eric Verhult’s company Eonic Systems that had developed the RTOS Virtuoso at the time they were aquired by Wind River. Wind River then developed Virtuoso into Rocket. I have met Verhulst and his people on several conferences. The first time I met him was at a conference that we arranged in Trondheim around 1992, where he told about what was later to become Virtuoso. Virtuoso had been inspired by occam on transputers, a “running subset of CSP“. Even now Zephyr threads with negative priority are “cooperative threads” and non-preemptive. Some of these people are now active in Altreonic and Along the way they did a formal analysis of their operating system (search for Verhulst here). And: “The most recent example of the technology’s success is the successful Philae Landing on Comet Churyumov–Gerasimenko and the accompanying Rosetta Orbite”, (they claim it, of all places here). This was in 2014. I have talked with Verhulst after this and he said he’d almost forgotten that the code was on its way to that comet. After all, it had been launched almost 11 years earlier

Zephyr is supported by corporations like Intel, Linaro, NXP and Nordic Semiconductor. But in this context I guess that the most important factor is that (from Wikipedia) “A BSD licensed fork occurs in the Arduino 101 software source package from Intel”. Also see Zephyr’s home page at Observe that Wind River Systems since 2009 has been a wholly owned subsidiary of Intel Corporation.

A comment from Eric Verhulst

On 8Jan2019 I had this comment from Erik Verhulst (at Altreonic and I was allowed to copy/paste it here:

“Zephyr is indeed the old Virtuoso RTOS (v.3.1), after WRS refactored the API à la posix. Along the way they claim they developed the original code, but if you look in the source code, you know better.

The reality is that the RTOS at that time was become “bloated”. Some engineers with a C++ background had been adding too many nice-to-haves.

We developed OpenComRTOS from 2004/2005 from scratch using formal methods (see the book) but with a similar philosophy and even cleaner API/ semantics. It s a completely new development with a graphical modelling front-end and many meta-models based front-end and code generators. We use XML for this.

The formal development resulted in a code size reduction of a factor 5 to 10 (depending on the target) and the official introduction of “hubs” (a bit like active CSP channels).

A few years ago, we decided to rebrand OpenComRTOS as VirtuosoNext. This went together with the support for fine grain partitioning (each task can run protected in its own memory space) and real-time fault tolerance (e.g. we can recover from exceptions in microseconds).

Now today, being tired of hearing “too advanced for us” (the real reason is in-house job protection, not understanding the real benefits (of small code and trustworthiness, productivity), or not wanting to change what free source and Linux claim to offer) we stopped active prospecting and use it now for our own benefit in the KURT vehicle concept. Fault tolerant by design but that also is difficult to explain to people who think autonomous driving software can be upgraded over the air.

The real killer: the law of Moore (which made software writers lazy) and education (high in the cloud and assuming that a PC is like an embedded device).

I see some signs that some people become aware that their current approach is not really scalable, but should I care?” (Eric Verhulst, 8Jan2019)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.