Back to News


In The News


Zephyr OS 1.14 (LTS) Bug Fixing Contest

By | Blog

The Zephyr Project community is preparing for the release of Zephyr OS 1.14, which is our largest collaborative endeavor to date! We are thankful for all of the support from members and talented developers for helping us meet so many technical milestones.

To show our appreciation, the Zephyr Project will be sending the 5 contributors with the most bugs fixed in Zephyr OS 1.14 an i.MX RT1050 from our Platinum member NXP!

This board combines high performance with real-time functionality. The i.MX RT series of crossover processors are designed to support next-generation IoT applications with a high level of integration and security balanced with MCU-level usability at an affordable price.  Using the i.MX RT1050 EVK, developers can simplify product design with MCU-like usability and leverage current toolchains, including MCUXpresso. The i.MX RT1050 EVK is a 4-layer through-hole USB-powered PCB. At its heart lies the i.MX RT1050 crossover processor, featuring NXP’s advanced implementation of the Arm® Cortex®-M7 core running at speeds up to 600 MHz.

To be eligible to win one of the i.MX RT1050 please send a list of all your closed bugs and issues to Be sure to include your name and links to the bugs you are responsible for fixing between October 2018 and the release of Zephyr OS 1.14 in mid April 2019. Zephyr Project TSC members are not eligible for this contest. Non-TSC members from Zephyr Project member companies are welcome and encouraged to participate.

There is still time to get involved!  If you are a new contributor to Zephyr Project a great place to get started is to check our Issues section of GitHub. Please follow the Contributor Guidelines to make sure your contribution adheres to our coding standards. Please contact Thea Aldrich at for questions.

Stay tuned to the Zephyr project blog for more contests and giveaways sponsored by NXP and other Zephyr Project members. The winners of this contest will be notified 1 week after the release of Zephyr OS 1.14 (LTS).

To learn more or ask questions, sign up for the Zephyr Project Slack Channel:

Endian Technologies Hosts Zephyr Hackathon at FOSS North 2019

By | Blog

Endian Technologies AB will be hosting a Zephyr hackathon during the FOSS North 2019 Community Day on April 7!

Zephyr Project member Nordic Semiconductor has provided all attendees with access to their new development board based on the nRF52840 chipset.  The nRF52840 is fully multiprotocol capable with full protocol concurrency. It has protocol support for Bluetooth 5, Bluetooth mesh, Thread, Zigbee, 802.15.4, ANT and 2.4 GHz proprietary stacks and has low energy consumption.

Pizza, soft drinks and coffee will be provided throughout the day.


The hackathon will kick off with an introductory presentation, bringing everyone up to speed on the Zephyr RTOS, the development process and the build system. After this, you’re free to work on one of the suggested topics, or go nuts on your own project.

If you’re interested in Zephyr but aren’t sure what to work on, don’t worry! A list of ideas will be provided that should appeal to all attendees, regardless of their experience level.

Do you have a topic you’d like to explore at the hackathon? Don’t be shy – share it with us! (see contact information below)


Only a basic understanding of writing and compiling C programs is necessary. All you need to bring is your laptop and a passion for development!  The development boards will be provided at the event, but you are of course welcome to bring their own boards, peripherals and tools as well.


Address: Endian Technologies AB, Flöjelbergsgatan 11, Mölndal.

Public transport: Bus 758 stops at Sörgärdesgatan. Suggestion: Take the 758 at 8.25 from Heden or 8.29 from Korsvägen.

Register for the event Here!


For questions, ideas or suggestions, please contact benjamin.lindqvist@endian.seIf if you have questions or comments, join the conversation on the Zephyr Slack Channel –

Getting Started with Zephyr RTOS on Nordic nRF52832 hackaBLE

By | Blog

Written by Mahesh Venkitachalam, Founder of Electronut Labs

This blog post first ran on the Electronut Labs Website. To see more content from Mahesh Venkitachalam or to learn more about Electronut Labs, visit


I worked for almost two decades in the software industry. In the early 2000s, I was developing applications on Windows, Linux, and various flavours of Unix. On the Windows side, we had Microsoft Visual Studio, MFC, NMake, and CL. On the Linux/Unix side, we had GCC, POSIX and various types of windowing toolkits (X-Window + Motif, anyone?). Cross platform development was a challenge, but even before the advent of fancy tools like Qt and wxWindows, we were able to structure the code so that large parts of it was compatible across the different operating systems.

Compared to that, cross-platform development in the embedded world today is far more difficult. First of all, there are many chip architectures – AVR, ARM, Xtensa, RISC-V, etc., and these chips vary hugely in their capabilities and supported peripherals. Then there are different sorts of toolchains, libraries, and development environments. Not all them can run an OS (or an RTOS) and in many cases, people don’t prefer to. Overall, good luck trying to port your code from once device to another! Although efforts like mbed try to address the cross-platform issue, they are restricted to certain chip families.

Why not just use embedded Linux then? You certainly can in many cases, as the huge success of Raspberry Pi shows. But when it comes to resource constrained low power systems, Linux is just too heavy. Enter Zephyr – an RTOS (Real Time Operating System) that is very much influenced by Linux, but designed specifically with the above constraints in mind.


In this project, we will build a BLE (Bluetooth Low Energy) device that broadcasts data from a BME280 temperature/humidity sensor. For this, we will use the Zephyr RTOS on the Electronut Labs hackaBLE board based on the Nordic nRF52832 SoC. For programming hackaBLE, we will use the Electronut Labs BumpySWD debugger based on the blackmagicprobe project.

Getting Started

The first thing to do of course, is to install Zephyr. For this task and for all tasks ahead, the official documentation page is your best reference. You can install Zephyr on Linux, Mac, or Windows. But I did it on Linux, and hence this article will reflect that experience. As you go through the official installation procedure, I recommend that you install the Zephyr SDK as well, since it has the required toolchain. Makes it easy to get started.

Now, before we proceed to build our “hello world” application with Zephyr, let’s look at a few concepts that are central to working with this RTOS.


If you have worked with embedded systems for any considerable time, you’re probably familiar with Makefiles. Well, CMake is a system that makes Makefiles. CMake is a cross-platform tool that uses configuration files to create build files specific to your system. Zephyr uses CMake, and building a project goes something like this:

Ninja is a build system designed to use with CMake. Apparently it’s faster – as ninjas tend to be. In addition to CMake/Ninja, Zephyr is also working on a “meta-tool” called west which will replace the above eventually. But for now you can still use our masked friend.

Device Trees

Your embedded device has a complex hierarchy of components, starting from higher level elements like LEDs and Buttons, down to SoC peripherals like I2C and ADC. In Linux, and in Zephyr, this hierarchy is represented as a device tree. The device tree resides in DTS (Device Tree Source) files – these are human readable text files. In Linux, these are compiled into binary DTB (Device Tree Blob) files using a DTC (Device Tree Compiler). In Zephyr, to reduce overhead, the DTS information is just used during compile time. The DTS files are naturally hierarchical. For example the nrf52840_pca10056.dts includes nrf52840_qiaa.dtsi, which in turn includes nrf52840.dtsi – going from board to chip variant to the core SoC.

If you are not familiar with device trees, the whole thing might seem a bit odd. But consider this: how does the Linux kernel support such a huge variety of third party devices without having to recompile the code every time? Because the device information can be passed into the kernel as a binary “blob” – the DTB.

So how do you get Zephyr to talk to your particular device? Chances are that a variant of this device is already supported by the kernel. So you take the relevant DTS and either make a modified copy of it, or write an overlay for it – something that adds or modifies the existing device so it matches yours. The DTS file along with some other configuration files constitute the “board files” for your device. We’ll be creating these files for hackaBLE in this project, so things will become clearer further ahead.

Config Files

Device Trees help you describe the hardware. There is another level of application-specific customisation required, which will let you enable only those features you really need. In Zephyr, this is done via the Kconfig configuration system. The “board files” we talked about earlier contain some default configurations, which can be further refined using application specific configurations. For example, if you want to enable the Bluetooth subsystem, you would have this in your project’s prj.conf file:

Enabling only what you need is critical for embedded systems, since it has a direct impact on things like power consumption, memory, and performance.

Kconfig also provides an interactive UI for setting all the configuration options. Doing a ninja menuconfig in the builddirectory with bring up this UI:

menuconfig gives you the entire configuration tree. You can search and navigate through this tree to set your relevant options. It’s a clunky interface, but it’s lightweight, and works across platforms. Once you set your options, save, and quit, you can rebuild your application with the new options. But here’s the catch – these options are saved inside your build directory, and will be blown away if you delete this directory. So to save these options for the future, you need copy these to your prj.conf file. (Here’s a menuconfig tip – while you are on a configuration option, press Shift-?, and you will get a help file that gives you the exact name of that option.)

Now let’s put this above knowledge to some use by building a couple of Zephyr applications on hackaBLE.

Required Hardware

You need the following hardware to build this project.

  1. Electronut Labs hackaBLE
  2. Electronut Labs Bumpy SWD programmer
  3. BME280 breakout board
  4. Breadboard, connecting wires

Hello World on hackaBLE

The hackaBLE board is not directly supported by Zephyr, so the first thing we want to do is create the required board files. hackaBLE uses the Nordic nRF52832 SoC, so we’ll just modify the board files for the Nordic nRF52832-DK board which is already supported by Zephyr, and listed under nrf52_pca10040.

Adding hackaBLE to Zephyr

First, we need to copy boards/arm/nrf52_pca10040/ to a new directory boards/arm/nrf52_hackable/. Then we rename the files as follows:

The next step is to replace the occurrences of pca10040 inside the above files with hackable. The next important edit is for board.cmake which will contain just: include(${ZEPHYR_BASE}/boards/common/blackmagicprobe.board.cmake)

This is required for us to program hackaBLE using the Bumpy SWD debugger, which is based on blackmagicprobe. Next, we’ll edit the DTS file to map the correct pins to the peripherals we will be using.

We need to use I2C and UART in this project, so we’ve correspondingly mapped the nRF52832 SoC peripherals to convenient pin numbers on hackaBLE.

Code Setup

The Zephyr build system allows you to easily build your project outside the installation folder. It’s usually easiest to just copy a sample project over and then modify the configuration. In our case, the folder looks like this:

Here’s what our prj.conf looks like:

Remember our discussion on Kconfig? The above file tells CMake that we want to enable GPIOs and the UART console.

Our main.c is very simple:

Let’s go through the above code quickly. The first thing it does is to get the GPIO_0 device binding – again, this come from the DTS file, and nRF52832 has only one GPIO port – P0. We then configure P0.17 – the LED red channel – as an output. In the main loop, all we do is flash the LED and print “hello world”, with delays in between. The printk outputs to the serial port, as per our config file which has enabled UART console – CONFIG_UART_CONSOLE=y.

Now we go into the build directory and build our project as follows:

Before we upload the code, let’s take a look at the hardware hookup.

Hardware Connections

For this project, hook up the hardware as follows so it matches up with our DTS and config files.

Upload and Test

The last step is to flash the code:

To test the output, we open a serial terminal using picocom:

In the attached screenshot below, you can see the output:

From the above, you also get an idea of my workflow. I use the byobu terminal multiplexer, and the four screens from top left, going anti-clockwise are – zephyr build, USB monitoring using dmesg -w, picocom output, and a Python shell for calculations.

Now that we’ve got “hello” going. let’s try something more interesting.

Building a BLE Temperature/Humidity Monitor

In this project, we’re going to enable the Zephyr BLE stack, communicate with the BME280 sensor using I2C, and then send the temperature and humidity data in two ways – via BLE advertisement packets, as well as via GATT characteristics – once a connection is made by a BLE central device like a mobile phone.

Configuring BLE and BME280

To enable BLE, you need the following in your prj.conf:

Oh, I didn’t come up with all the above stuff by myself. Zephyr has fine BLE examples that I pilfered from. The above enables BLE and sets up various parameters – for example, CONFIG_BT_PERIPHERAL=y says that our device is a peripheral, not a central, and CONFIG_BT_DEVICE_NAME=”hackaBLE” sets the name we advertise by.

Next we need to configure the BME280 sensor, which, luckily is already supported by Zephyr:

Above, we first configure I2C, and there are some special settings for NRF which you can see above. Once I2C is enabled, we then enable the sensor subsystem on Zephyr, and more specifically, the BME280 sensor.

The Code

I won’t go through the whole code here, but here are the highlights.

We start by defining the main BLE service and the two characteristics we will be using – Temperature and Humidity:

These are added to the BLE subsystem as follows:

In the code above, you can see read/write functions assigned to each characteristic, as well as permissions, and the Client Characteristic Configuration Descriptor (CCCD) which lets the client (the central) enable notifications.

Here’s how we set up the BLE advertisement packet.

Above, we’ll use the third and fourth bytes in mfg_data to send the most significant digits of temperature and humidity respectively.

We access the sensor in a manner similar to what we did with GPIO before:

Here’s how you get the BME280 data:

In Zephyr, sensor data is stored in a struct as follows:

So in our code, we retrieve the temperature and humidity, and store them both for advertisement packets and for the characteristics.

Here’s our main loop:

What we’re doing above is notifying the connected device with the new sensor values as well as updating the advertising data.

Build and Test

You can build and flash the code similar to the hello example. To test the device, we will be using the Nordic nRFConnect mobile app. Here’s what you see when you scan:

In the above screenshot, you can see that the last two bytes of the advertisement packet manufacturer data is 0x1b21 – 27 degree C with a humidity of 33%.

Now, let’s connect to it.

You can see the UUID of the primary service we defined. If you click on it, you will see the characteristics:

Taking some help from Python, we get:

Hence, T = 27.900000 deg C, H = 34.182617 %. If you enable notifications, you will see that these values update on the phone every two seconds, as per our code.

So here we are – a BLE device based on Nordic nRF52832 that transmits weather data, powered by the Zephyr RTOS!

Programming hackaBLE without Bumpy

It’s perfectly possible to program hackaBLE without Bumpy. If you want to use the Nordic nRF52832-DK (PCA10040) for that purpose, you need to use the same board.cmake as the PCA10040 in the board files. You’ll also need to match the Rx/Tx lines of hackaBLE and the DK in the DTS file to get the serial output.


I learned a lot of programming on Linux. I always liked the “everything is a file” idea and standard programming concepts that worked across systems. Thinking in terms of processes, threads, inter-process communication mechanisms, sockets, etc. was natural, and these were concepts and programming conventions that were portable. But working with embedded systems today, vendor lock-in is a worrying trend, whether it be proprietary hardware programmers, expensive development tools, non portable APIs, or closed protocol stacks. There is a dire need for open, vendor-neutral frameworks like Zephyr, and the fact it follows the Linux model is a big plus in my view. We are definitely looking at Zephyr as the primary platform for our upcoming projects and products.


You can download the source code for this article at the link below:


I thank Tavish Naruka for introducing me to Zephyr, as well as troubleshooting issues on various occasions.

ProGlove Introduces New IoT Wearable for Industrial, Logistics and Trade

By | Blog

Last week, you learned more about Zephyr RTOS powering drones. This week, we’re shining the spotlight on smart gloves, specifically the next generation of IoT Industrial wearables from ProGlove!

Most industrial companies struggle with the same issue – how to streamline technology to confirm work orders or document process steps. Many companies employ mobile handheld scanners that are clunky and unwieldy and sometimes not dependable. They bring unnecessary weight, must be turned off, and are often lost or quickly broken. This delays work processes, leads to errors and affects the quality. The ProGlove’s smart gloves addresses these problems and turns the handheld to smart, wearable barcode scanners that ensures greater efficiency, flexibility, ergonomics, quality and process reliability. Employees can easily trigger the scanning process, they no longer have to constantly search for the scanner, and above all they have their hands free at all times. By eliminating the need to pick up a regular barcode scanner, ProGlove is able to speed up processes by up to 50% and gives users feedback on the tasks performed. This reduces mistakes, improves quality, and provides tangible data for future decisions.

Part of the smart glove solution is Zephyr RTOS. Zephyr is scalable, optimized for resource constrained devices, and built with safety and security in mind. It’s perfect for ProGlove – which just launched MARK 2, the second generation of the intelligent glove, based on the operating system.

Compared to its predecessor, it is characterized above all by the support of Bluetooth Low Energy (BLE), a larger scan range, a faster image processing and a significantly longer runtime. The Smart Wearables of the Munich-based Start Ups are designed for use in industrial environments and are used in particular in production and logistics, but also in retail.

Like its predecessor, MARK 2 is specially designed for use in production, logistics and retail. BLE makes connecting the Plug and Play device to the corporate network even easier. In combination with tablets, smartphones and other portable devices, employees can work hands-free and without a station. The 1D and 2D barcode engine is twice as fast and much more accurate than before.

If you’re currently at the Global Industry Show at Eurexpo Lyon, stop by the ProGlove booth to see the new MARK 2! For more about how Zephyr RTOS powers innovative products, join the conversation on the Zephyr Slack Channel –