Søk etter:

Started 9Jul2019 as chapters being moved from other notes. Updated 25Sep2023 («A9 SoC on Xilinx»)

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 might be of interest to me is 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. Update 3Nov2022: that link told me I had to pay! to even see my own «slack». How slack is that..

Update 28Nov2022: There is a virtual machine on top of Zephyr, called SynchronVM, see https://github.com/SynchronVM/SynchronVM. It does run CPS channels. (Erling, thanks for the info!)

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. However, as of 3Nov2022 I see that the Wikipedia history section has been updated. Some of my below «aside» would then now also be present in Wikipedia:

Aside: The operating system came from Eric Verhult’s company Eonic Systems that had developed the RTOS Virtuoso at the time they were acquired by Wind River. Wind River then developed Virtuoso into Rocket. I have met Verhulst and his people on several conferences. The first time was at The First Nordic Transputer Conference that we arranged in Trondheim in Nov. 1991, where he told about a scheduler for transputer. This was later to evolve into Virtuoso. It was written in C and caught a lot of attention. (Nested aside: Denis Nicole from University of Southampton also had an interesting presentation there, the Virtual Channel Router for occam on transputers. Processes (tasks) could be moved around to different transputers, and the communication chans followed like rubber bands. The via tasks and routing were taken care of by the VCR.) Verhulst’s 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 still active in Altreonic and kurt.mobi. Along the way they did a formal analysis of their operating system (they even published a book called «Formal Development of a Network-Centric RTOS», see Formally proven kernels:[065]). 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 claimed it, of all places here, but on 3Nov2022 they seem to have removed all mention if this. But there is a a snapshot at Wayback Engine, 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 www.zephyrproject.org. Observe that Wind River Systems since 2009 has been a wholly owned subsidiary of Intel Corporation.

Comments from Eric Verhulst

On 8Jan2019 I had this comment from Erik Verhulst (at Altreonic and kurt.mobi). 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)

An update from Eric Verhulst on 21Sep2023:

The last port is to an multicore A9 SoC on Xilinx.