Porting from FreeRTOS to Zephyr:

Project, Process, and Unexpected Benefits Within an Embedded System

The Boston Engineering software team recently Brief History of FreeRTOS and Zephyr
completed a project that involved porting the soft-
Released in 2003, FreeRTOS has been used in em-
ware for an existing system from FreeRTOS to
bedded devices for nearly twenty years. Amazon’s
Zephyr. Below is a review of why they performed support of FreeRTOS has been welcome news, in
this port, some thoughts about the two different Real addition, it establishes that there is strong continued
Time Operating Systems (RTOSes), and some inter- corporate support around the OS along side its wide
esting insights that were gained along the way. user base.

By comparison Zephyr is a newcomer, having its first

Challenge: Integrate embedded system with release in 2017. Though Zephyr lacks in overall ma-
CANopen devices turity, it’s fresh approach compensates with an abil-
ity to design without regard for decades of previous
Solution: Port FreeRTOS to Zephyr development.
Result: With this blank slate Zephyr devs were free to se-
• Requirements met lect technologies and approaches without being tied
to historical baggage, while also borrowing from the
• Savings gained through Zephyr Functionality best from systems and technologies, like FreeRTOS,
• Secured connectivity features for future use that came before them. Zephyr’s development pace
is amazing, with an average of some 200 commits
per week. FreeRTOS by comparison is a few dozen.

Presented by: Decision to Port to Zephyr

Chris Morgan, Director Software Engineering We have had success working with both FreeRTOS
Boston Engineering and Zephyr. In this situation the project had
requirements to add integration with CANopen
devices. While there is a CANopen integration with Both operating systems are able to run on low
FreeRTOS, the CANopen integration in Zephyr cost microprocessors. Each has documentation
was better developed and integrated, pointing to available online for easy download. FreeRTOS uses
a reduction in development time and effort. We STM32CubeIDE for it’s debiggunbg, while Zephyr
also looked at Zephyr’s support for a number of offer its own Zephyr SDK / VSCode + cortex-debug.
connectivity features. Almost all electronic devices Either systems offer minimal RAM/Flash footprint,
developed today have some integrated connectivity, with FreeRTOS needing 152k Flash and 169 RAM,
such as Bluetooth Low Energy, WiFi, cellular etc. Zephyr 178K Flash and 121K Ram to run both the
While the specific project being ported had a near term OS and App. WE considered these numbers to be the
need for CANopen support, it has longer term future same given our loose constraints.
connectivity needs. CANOpen plus IoT integrations
As a note, we have not looked to optimize consumption
led us to selecting Zephyr as our target RTOS.
of flash or ram for either FreeRTOS or Zephyr. The
microprocessor we are using has a lot of ram and
As a note, we did consider a number of other RTOSes flash available and we’ve been focusing on features
in addition to Zephyr, such as Mbed, embOS, and vs. tuning. We expect that a considerable amount of
Nuttx. Again, the integration of connectivity features savings could be found in both cases.
put Zephyr ahead of the others.

Comparison Against Project Requirements

This project required the following 9 characteristics:

• Integrated CANopen Stack,

• Wide range of connectivity features for future

use,

• Ability to run on low cost microprossesors,

• Real-Time operation,

• Minimal RAM/Flash Footprint,

We consider both FreeRTOS and Zephyr to be mature,
• Maturity (proven usage in the marketplace), with 20 and 6 years of use, respectively. Each system
is actively developed and supported, with over 20 top
• Active development and support, firms active in their respective development groups.
• Robust tooling/IDE integration of Debugger, and In fact, Many companies support both FreeRTOS
and Zephyr, recognizing that there are a number of
• Documentation use cases where each may be better suited. With
this corporate support often comes code updates
After reviewing several options, the decision came
and abstraction layers delivered to the code base for
down to two familiar options for Boston Engineering:
developers to utilize.
FreeRTOS and Zephyer. A Side by Side comparison
showed that while the systems are very similar, Driving our final decision to employ Zepher is the fact
Zephyr was the superior choice in this instance due that, while a robust solution, FreeRTOS does not offer
to having an integrated CANopen stack and a wide an integrated CANopen Stack – rather their solutions
range of connectivity features. Here is a summary of require porting by the developer – an added time and
those details, also shown in exhibit 1 below. expense. Zephyr’s options are integrated into the
 Exhibit 1: Comparing FreeRTOS & Zephyr Offering vs. Project Requirements

Project Requirements FreeRTOS Zephyr

Runs on low cost microprocessors Yes Yes

Documentation Yes Yes

Real-time Yes Yes

Yes Yes
Robust Tooling / IDE integration of

Minimal ram/flash footprint Yes OS + app: 152k flash, 169k ram Yes OS + app: 178k flash, 121k ram

Yes: 9 Platinum Developer members

Actively developed and supported Yes: 23 development members

Mature Yes – 20 years Yes – 6 years

Integrated CANopen stack No Yes

Wide range of connectivity features Partially Yes

for future use Some - via 3rd party libraries Extensive - integrated into configuration
and build system

configuration and build system. The porting went relatively smoothly, we were able
Finally, Zephyr provides an extensive list of connectivity to learn more about Zephyr, and the results did
features, far outpacing those offered by FreeRTOS, in fact allow us to save the time and effort we had
and making it the clear choice for maintaining option anticipated. Below is an analysis and notes related to
for future builds. the actual process of porting each of these elements.
Threads and Thread Synchronization
Actual Porting Activities The thread and thread synchronization changes were
the most straight forward part of the porting activity.
For this project, the system is a typical embedded
FreeRTOS and Zephyr have very similar functions
system. We make use of the following:
for creating threads, creating, and waiting on events /
• Threads and thread synchronization
semaphores etc.
• Ringbuffer Ringbuffer
• Console shell During the Zephyr port it was (re-)discovered that the
• External flash application had implemented a ringbuffer, rather than
making use of the FreeRTOS streambuffer. Code
• Other devices: UARTs, RTC, i2c, spi review of the custom ringbuffer revealed a number
of conditions that could result in memory overruns.
In addition, there were no unit tests for this ringbuffer While there was a bit of a learning curve on how to
implementation. configure these devices in the devicetree, the port of
With these gaps it was decided that we should replace these devices from the STM32 HAL to Zephyr drivers
this ringbuffer implementation during the port. We went smoothly.
replaced this custom ringbuffer with a Zephyr pipes.
The Zephyr pipe provides thread synchronization and Unexpected Benefits to Zephyr
is widely used and unit tested. Dropping this custom
During the port we uncovered into multiple aspects of
code and leveraging a Zephyr primitive was a bonus.
the Zephyr system things that excited us. While these
aren’t features that would have swayed a decision to
port to Zephyr, they are extras that we thought were
nice touches or great time savers.
• Developer support: We’ve had quick
responses from the Zephyr developers when
opening support requests. For example we
uncovered a bug with usage of pipes from ISR
context that no one else had run into. We reported
it (by opening a PR to clarify the documentation)
on the Zephyr GitHub issue tracker. After some
discussion the root cause was understood and in
Console Shell two months the pipes functionality was rewritten
and the issue resolved. We were more than satisfied
The project makes use of a command line interface
with the quick identification phase and the time to
(cli), provided via a UART, view and configure system
resolve, especially given the complexity of the pipes
settings, and to aid in debugging. With the move
and underlying systems.
from FreeRTOS to Zephyr we transitioned from
FreeRTOS+CLI to the Zephyr Shell • Integrated tooling: Zephyr ships with an
sdk and the west command line tool that simplifies
getting up and running
External Flash
• Board support: Zephyr features broad
The FreeRTOS implementation had a few hundred support for most development boards that we
lines of application layer code to interface with an commonly use
external SPI flash, a W25X20 or similar. With global
• Testing framework: Zephyr features a built-in
supply chain issues, this code needed to be altered to
framework that allows for units tests to be created and
add support for an available Flash chip with a slightly
run against functions within your code. While many
different memory layout and command set (AT25SF).
similar frameworks exist, it can be cumbersome
Zephyr has SPI flash drivers which supports both to test code that includes (or is adjacent to) OS
the W25X20 and the AT25SF parts being used in the primitives such as tasks and semaphores. The
project. A nice feature, indeed. By making use of the built-in Zephyr framework - ZTests - allows these os
Zephyr driver we take advantage of software that has primitives to be compiled and tested alongside any
a lot more usage, testing, and development. other line of code.
• Devicetree: Like Linux, Zephyr makes use of
Other Devices the devicetree. This lets us leverage our knowledge
of Linux devicetrees and the devicetree itself lets
Zephyr has drivers for the processor family that was
us consolidate device configuration (UART pins, spi
used, in this case STM32, for uarts, i2c, spi, and rtc.
 data rates) with custom board settings, removing for OS configuration settings.
the need for build time #if / #ifdef conditionals. Having a menu driven configuration system is more
With FreeRTOS we were using STM32CubeIDE. critical for Zephyr than for FreeRTOS, given the
Built on Eclipse, the STM32CubeIDE also includes Zephyr’s range of integrated subsystems and drivers
the CubeMX GUI tool that generates configuration that can be enabled/disabled or configured.
source code for the processor and its devices. With
Zephyr the function of configuring hardware shifts to Ultimately, we really like Zephyr Kconfig support!
the device drivers, and the device drivers get their
configuration from the devicetree.
The shift from CubeMX to devicetree went relatively Trends We See
smoothly. The devicetree does require that we
know more about the hardware configuration and Connectivity features (IoT) have dominated product
CubeMX provides some helpful checks for invalid design for a number of years. There is a high value
configurations. Even still, it wasn’t tough to transition brought to usability and maintenance through
to devicetree files. Devicetree files are plain text, connectivity. We agree with projections that nearly all
which lets us version them in git and review changes. devices will become connected in some manner or
And, even though we aren’t using STM32CubeIDE another.
on the project we still make use of the CubeMX tool As the trend towards more powerful and capable
to aid in clock tree configuration! processors continues we also expect that many new
• Linux-feel: Many of us have been using and updated products will make use of more featureful
Linux and POSIX OSes for what seems like operating systems such as Linux.
forever. Along with support for Linux features like Even still, many products are sensitive to cost and will
Kconfig, devicetree and SocketCAN, Zephyr also feature the lowest cost SoCs that meet their feature
provides a Posix compatibility layer. Sharing these requirements. These Systems-on-Chips (SoCs) will
approaches, tools and API with Linux systems lets continue running RTOSes even as RTOSes continue
us leverage our existing knowledge. to develop features in the direction of the major OSes
• Kconfig: FreeRTOS is configured via like Linux.
FreeRTOSConfig.h. This is a perfectly reasonable While we continue to look forward to expanding
and simple way to configure OS options. Zephyr our use of Zephyr we hope that FreeRTOS and
has textual config files that you can edit. However, its developers will embrace its evolution towards
it uses Kconfig to provide a menu driven approach improved integration and connectivity features.
for configuring, reading option help, and searching
About the Author About Boston Engineering Software Development
Chris Morgan Boston Engineering’s Software Development process
Software Engineering Manager leverages the experience and knowledge gained
Boston Engineering through the development of dozens of software,
electromechanical, and robotic systems. Our Subject
matter experts have advanced knowledge of:
Chris has over 20 years of experience in software and
• Designing embedded systems that combine
hardware design. He enjoys all things engineering new features with unmatched performance and
and is an author and contributor of a number of open- reliability
source projects.
• Delivering precision motion control for robotics,
factory automation, and other applications
About Boston Engineering Embedded Systems • Conducting software testing, as well as
verification and validation (V&V)
Boston Engineering is a leader in the development of
custom embedded hardware and software systems. • Reducing risk and accelerating your project
development with simulation and software
Our integrated, cross functional team of electrical,
prototyping.
software, and mechanical engineers will advise, direct,
and manage any computing development project. Our skilled software developers are experts across
Whether the challenge is to modernize components, software development tools, including:
increase reliability, improve performance, or • UI development (Web, mobile, embedded)
synchronize I/O options, Boston Engineering thrives • Controls software
on solving the toughest challenges. • Embedded software
• Robotic systems (ROS2)
Embedded Systems is one of Boston Engineering’s • Operating systems:
Centers of Excellence. Contact us to learn more • Linux application development
about how our Centers of Excellence define and • RTOS (Zephyr, FreeRTOS)
support the commitment we make to our clients and
• Internet of Things (IoT)
the organizations we serve.
• Communications systems and protocols (WiFi,
Cellular, BLE, Iridium)

About Boston Engineering

Making a meaningful impact drove us to start the business in 1995 and it has driven every proj-
ect since. From designing advanced products and technologies to accelerating time to market, Bos-
ton Engineering thrives on solving tough client challenges. We provide product design and engineer-
ing consulting from concept development through commercialization. Clients benefit from our deep
product development capabilities, focused industry expertise, and ISO-certified quality management system.
Founded in 1995, Boston Engineering is headquartered in Waltham, Mass.

Contact us:
boston-engineering.com
[email protected]
781-466-8010
© 2023 Boston Engineering Corporation. All rights reserved. Boston Engineering and Imagine the Impact are trademarks of Boston Engineering Corporation. All other
brand or product names are trademarks or registered trademarks of their respective owners. CM230622v1