Linux Foundation Celebrates Zephyr Project's Small Real-Time Operating System (linuxfoundation.org) 30
This week the Linux Foundation shared an update on the Zephyr Project, a small real-time operating system for connected, resource-constrained and embedded devices:
The project recently achieved several milestones including surpassing 80,000 commits since it was released in open source in 2015. This is an average of almost 2 commits per hour, which was made recently by 490 individuals, including 166 first-timers, who contributed to the 3.4 release. Zephyr RTOS supports over 450 boards running embedded microcontrollers from Arm and RISC-V to Tensilica, NIOS, ARC and x86 as single and multicore systems...
Zephyr RTOS has a growing set of software libraries that can be used across various applications and industry sectors such as Industrial IoT, wearables, machine learning and more. It is built with an emphasis on broad chipset support, security, dependability, long-term support releases and a growing open source ecosystem...
The Zephyr community will be at the Zephyr Developer Summit, which takes place on June 27-30 in Prague, Czech Republic, and virtually as part of the first-ever Embedded Open Source Summit. [Register here for virtual attendance.]
Arduino will be joining Zephyr's Technical Steering Committee, along with Technology Innovation Institute and the American multinational semiconductor company Analog Devices (or ADI, who will also be joining its governing board). Arduino's CEO said "We believe that Zephyr OS is a truly special project that will play a significant role in the Arduino ecosystem and will be a big priority for us."
As a "Platinum"-level sponsor, ADI joins Antmicro, Baumer, Google, Intel, Meta, Nordic Semiconductor, NXP, Oticon, Qualcomm Innovation Center and T-Mobile.
Zephyr RTOS has a growing set of software libraries that can be used across various applications and industry sectors such as Industrial IoT, wearables, machine learning and more. It is built with an emphasis on broad chipset support, security, dependability, long-term support releases and a growing open source ecosystem...
The Zephyr community will be at the Zephyr Developer Summit, which takes place on June 27-30 in Prague, Czech Republic, and virtually as part of the first-ever Embedded Open Source Summit. [Register here for virtual attendance.]
Arduino will be joining Zephyr's Technical Steering Committee, along with Technology Innovation Institute and the American multinational semiconductor company Analog Devices (or ADI, who will also be joining its governing board). Arduino's CEO said "We believe that Zephyr OS is a truly special project that will play a significant role in the Arduino ecosystem and will be a big priority for us."
As a "Platinum"-level sponsor, ADI joins Antmicro, Baumer, Google, Intel, Meta, Nordic Semiconductor, NXP, Oticon, Qualcomm Innovation Center and T-Mobile.
Zephyr and MISRA (Score:4, Interesting)
Ah, yes, Zephyr. I fondly remember the day when I found a bug in Zephyr caused by them applying MISRA 2012 rule 7.2 to the macros that make up NSEC_PER_SEC. It finally proved to me that blindly following MISRA doesn't automatically improve code quality.
Oops, the bug still exists four years later. Maybe I should post a patch...
Re: (Score:1)
“Oops, the bug still exists four years later. Maybe I should post a patch...”
Why didn't you report the bug at the time?
Re: (Score:2)
This was just one of several things I had to change inside Zephyr to create a proof of concept for our customer. He dropped the project in this early stage and I've never had the chance to work in a Zephyr project since then. At home I don't have the hardware.
Re: (Score:2)
At home I don't have the hardware.
Good news! Zephyr will run on a $15 ESP32 dev board, according to their site anyway.
Re: (Score:2)
That particular bug is inside the ethernet driver of an Atmel SoC.
Re: (Score:2)
They don't take kindly to bug reports.
Everyone has a status level next to their name. It's on every issue, PR, and comment to be sure you always know where you stand and where your betters stand.
It creates a Stanford Prison Experiment [wikipedia.org] like atmosphere. A prisoner can't tell a guard they did something wrong. It would upset the order and weaken their status to admit fault to an inferior.
They'll pretend obvious bugs aren't bugs [github.com]. Then of the fix to the thing that was not a bug yet somehow has a bug fix [github.com]
Re: (Score:2)
Oops, the bug still exists four years later. Maybe I should post a patch...
I believe you because I have exactly zero experience with Zephyr or the build system or MISRA 2012 rule 7.2 or anything else related to this project. But your post got me curious so I dug up what I believe are those macros and I would, honestly, like to understand the bug. I could see how the u/U suffix could cause problems in C macros but surrounding all those with parentheses seems appropriate to me to avoid that type of bug. What did I miss?
#define NSEC_PER_USEC 1000U
#define USEC_PER_MSEC
Re: (Score:1)
Re: (Score:3)
In ptp_clock_sam_gmac_adjust they compare a signed value to -NSEC_PER_SEC and NSEC_PER_SEC. Since the constant is unsigned, everything is implicitly converted to unsigned values before it are compared. The expression always evaluates to true, the function never adjusts the clock.
Re: (Score:2)
Maybe that was one of the useless MISRA rules? From Assessing the Value of Coding Standards: An Empirical Study [researchgate.net]:
"In addition, 25 out of 72 rules had a zero true positive rate. Taken together with Adams’ observation that all modications have a non-zero probability of introducing a fault [1], this makes it possible that adherence to the MISRA standard as a whole would have made the software less reliable. This observation is consistent with Hatton’s earlier assessment of the MISRA C 2004 standard [9]"
eCos (Score:2)
Re: (Score:2)
It seems you are mixing up eCos and eComStation.
Re: (Score:2)
Just use Linux (Score:3)
I feel like these mega-embedded projects are in a weird space right now, as microcontrollers are advancing so rapidly. My experience with embedded is that you either have an extremely resource constrained system (because $$ or power consumption) or you've got loads of performance available.
In the first instance, which still comes up in many projects, you're just never going to get away from C on bare metal with, perhaps, something like FreeRTOS. It's just hugely fast and most of these projects are not complex enough that you benefit from having a big framework or pre-packed code libraries.
For the second type of project, well, this stuff has been seeing an absolute revolution over the last decade. MCUs with huge amounts of memory and performance are very cheap, to the point where it is almost always more economical to use a more powerful chip than spend $ optimising code these days (this was the complete opposite only 10 or so years ago).
We are probably only a few years away from just being able to run a full linux stack on an LQFP48 cortex-M for dirt cheap. At that point, something like Zephyr just gets stuck in the middle and not really doing either very well.
Re: (Score:3)
We are probably only a few years away from just being able to run a full linux stack on an LQFP48 cortex-M for dirt cheap. At that point, something like Zephyr just gets stuck in the middle and not really doing either very well.
Using Linux isn't necessarily a good solution because it's not very realtimey. Instead of spending a bit more on hardware, you have to spend a lot more to get acceptable performance, or you have to not use significant parts of the system in order to get it — at which point you're already system-constrained and having to alter your behavior and/or your program behavior in order to get RT performance.
Re: (Score:3)
Exactly, and this goes hand in hand with deterministic behavior.
I can test and tune a microcontroller-based system and after that can be certain that it will behave almost identical if deployed in a remote location, inside a larger machine, etc. With a linux-based system there are many more moving parts, some driver can run several threads in the background, on x86-hardware there are the NMIs that can cause a lot of jitter, etc.
Most likely there will be pressure from both sides, a Teensy microcontroller is
Re: (Score:2)
The size of the Linux kernel and userspace has also grown greatly since the first RPi too. Some of the smallest embedded systems I designed with Linux 20 years ago could never work with a 6.4 kernel. The kernel alone wouldn't fit into RAM, much less the rest of their software.
And cheap micro controllers have a lot more flash and ram than they used too as well.
So at some point will the cheapest and lowest power processors grow to the point where they can run Linux acceptably? Or will Linux continue to gr
Re: (Score:2)
at some point will the cheapest and lowest power processors grow to the point where they can run Linux acceptably? Or will Linux continue to grow in complexity at a greater rate and this will never happen?
There is some upper bound to Linux complexity that would cause it to be unmanageable as a monolithic kernel. If you want to add more complexity to the system at some point you have to move it to user space. Parts of the kernel have already gone that way.
From the other end, we will eventually move to new technologies (maybe just new substrates and dopants, maybe wholly different tech like rod logic) and then we will start the miniaturization and march towards greater complexity all over again in a new medium
Re: (Score:2)
"Why do this thing when something already does it!"
If nerds thought like that, we wouldn't have never made any progress
Re: (Score:2)
"Why do this thing when something already does it!"
If nerds thought like that, we wouldn't have never made any progress
In this case though, I'd argue it's about not reinventing the wheel (linux). As micro ontroller capabilities increase they will add more and more features to zephyr to the point that it just becomes another Linux distribution.
I understand what they're trying to do, but I just think the window where something like this will be relevant is going to be very small.
Re: (Score:2)
Zephyr is owned by the companies that pay to be members. So while it might well become just another Linux, it'll be a Linux where the chip vendors have absolute power.
Add support for a clone device, like a knock-off FTDI chip or the HTU21D sensor? Not if the original vendor has paid for the power to block that.
Don't want to be locked into a driver that depends on a bad and proprietary vendor HAL? Not allowed. It's like giving Nvidia veto power over Nouveau being allowed.
Re: (Score:2)
I sort of agree with you, but as linux cant really do hard realtime, something like Zephyr needs to still exist. BOM costs and power consumption aren't the only reasons to choose an "embedded stack" over "linux."
Linux running as a management plane in a Zephyr process a la RTLinux might make some sense here.
Re: (Score:2)
I think it's a bit shy of proper "linux" on these boards, but for realtime stuff it's often not an option to have a full scheduler and O
Advertising (Score:2)
Re: (Score:1)
Lots of people run bare metal on the simplest micros Zephyr runs on, but probably literally nobody is running bare metal on the most complex ones...
Boot time? (Score:2)
How long does it take to boot up including networking and other essential services?
Okay but what does it do? (Score:1)
Zephyr RTOS has a growing set of software libraries that can be used across various applications and industry sectors such as Industrial IoT, wearables, machine learning and more
What environments is it expected to be used in? What are the advantages over alternatives? Why should a user care which OS is being used for these applications? For that matter which applications and sectors? "IoT, wearables, machine learning and more" may as well read "It will