Runtime.io and Nordic Semiconductor join Zephyr Project

Welcome our newest project members!

The project is pleased to announce that Runtime.io and Nordic Semiconductor have joined as Silver members of Zephyr Project!

Both Runtime.io and Nordic Semiconductor have been active contributors to the project since its launch. Both organizations bring development expertise in the development of IP and networking technologies, and in particular for resource constrained devices. We’re thrilled to formally include them as corporate sponsors.

While Zephyr Project is an open source project and welcomes contributions from the community, the project also has an established governing model to decide strategy and direction. The project has two levels of membership: Platinum where those at this level have a seat on the governing board to make decisions about the overall direction of the project and Silver where those at this level are represented by those who are voted into position. The goal of the governing and development model is to be lightweight and nimble, and leverage a proven method of open source development.

For more information about the project or to find out about membership, please contact the project at info@zephyrproject.org

Neonatal Wearable for the Developing World

Zephyr and Curie Team Up

The Zephyr Project is still a babe in the technological woods, so it’s only fitting that the open source real-time operating system is driving an innovative wearables solution that aims to improve healthcare for infants.

Read more at Linux.com

nRF5x support within the Zephyr Project RTOS

The Zephyr Project RTOS is a recent effort by the Linux Foundation to provide the embedded world with a free, secure and fully-featured Real Time Operating System. It is designed from the ground up to be a modern, scalable, secure and responsive RTOS with a clear focus on IoT protocols and foundations. This open-source RTOS is Apache 2.0 licensed and has a fully open development model.

Read the full post at Nordic Semiconductor

Announcing Zephyr OS v1.6.0

By Maureen Helm

The Zephyr Project development team is excited to announce the release of Zephyr OS v1.6.0! In the three months since our last release, we have added new features and boards, welcomed new developers to our open source community, and been out and about sharing cool Zephyr Project based demos at various trade shows.

Development within the ARM® ecosystem has been particularly busy lately, as this release introduces kernel support for the ARM Cortex®-M0/M0+ architecture, new ARM-based system-on-chips (SoCs), and wide adoption of the ARM Cortex Microcontroller Software Interface Standard (CMSIS). We started leveraging vendor drivers, including those from the new software development kit (SDK) for NXP®’s Kinetis® and LPC microcontrollers, MCUXpresso SDK. These drivers build upon CMSIS peripheral register definitions to help us expand support for more ARM-based SoCs. Instead of developing brand new I2C or Ethernet drivers from scratch, for example, we built lightweight shims on top of mature and tested SDK drivers.

This release also introduces a new unified kernel, which streamlines the old nanokernel and microkernel into one. After much consideration, we determined it often created challenges for developers that wanted to support both. The nanokernel and microkernel each had their own set of APIs, which meant that drivers, middleware stacks, and applications effectively had to target two operating systems. The new kernel unifies the APIs yet still supports both cooperative and pre-emptible threads. In many cases (specifically those that used the microkernel), the unified kernel also improves performance and reduces code footprint.

But the Zephyr Project development team hasn’t just been developing code, we’ve also been putting on our Zephyr Project hoodies and showing off demos at the Embedded Linux Conference Europe and ARM TechCon. Our newest demo shows a BLE heart rate monitor that utilizes the award-winning Hexiwear IoT and Wearables Development Platform with the NXP Kinetis K64F MCU onboard. The Zephyr BLE host stack, originally developed on an Intel® x86 device, now runs on an NXP Kinetis K64F MCU (ARM Cortex-M4) and utilizes a large number of onboard sensors found on the Hexiwear platform, including the NXP Kinetis KW40Z multimode radio. Support for Hexiwear is included in Zephyr OS v1.6.0, making it a great multi-purpose platform for developing wireless IoT applications with Zephyr OS.

We invite you to download Zephyr OS v1.6.0 and share your feedback on the mailing list. For extra credit, contribute some patches to help make the next release, coming in March 2017, even better.Maureen Helm
MCU Software Architect
NXP Semiconductors

NXP, the NXP logo and Kinetis are trademarks of NXP B.V. All other product or service names are the property of their respective owners.  ARM and Cortex are registered trademark of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. © 2016 NXP B.V.

Open source continuous integration (CI) for Zephyr at ELC

Cloud-based continuous integration /klaʊd beɪst kənˈtɪnjʊəs ɪntɪˈɡreɪʃ(ə)n/

a software development practice that pretty much nobody would associate with microcontrollers … 

I found myself last month representing Linaro at the Zephyr booth on the demo area floor in the Maritim Hotel in Berlin for ELC-E. I had a rather unusual microcontroller demo.

Microcontroller demos often tend to be a product prototype running an RTOS, often extended to sending data to a cloud-based application and/or to a mobile device. There were certainly some very cool microcontroller demos on the Zephyr booth at ELC. In our Zephyr demo we wanted to show how open the source code, tooling, and configuration could be, and how transparent collaboration could flow from the engineering behind the deeply embedded RTOS code.

Read more at Linaro

Zephyr™ Project at the OpenIOT Summit Europe

By Gajinder Vij

It seems like such a long time ago, but it’s only been a short month since the Zephyr™Project had a great showing at the OpenIoT Summit and Embedded Linux Conference in Berlin. The conference was as at the Maritim Hotel, a short distance from the historic Berlin Wall. The beautiful fall weather was a perfect complement to the excellent material shared at the conference.

It was great to see the Zephyr Project mentioned throughout the conference and hear from key maintainers who participated in a closing keynote panel. The Zephyr Project technical sessions were heavily attended and developers had great questions. The Zephyr Project booth seemed constantly busy with demos from all our member companies showcasing their different technologies on Zephyr. We also had Neopenda in the booth with a prototype of their Zephyr based product. It was exciting to meet some of the new contributors and listen to their perspectives on the project.

The conference ran for three jam packed days and covered a broad range of topics. All the slides from the OpenIoT Summit are available on the conference website.  I’ve also included some individual links for key topic areas below.

Key Zephyr Project topics from  the Open IoT Summit Europe 2016:

Leveraging IoT Biometrics and Zephyr RTOS for Neonatal Nursing in Uganda
By Teresa Cauvel, Neopenda

Unified Kernel
By Benjamin Walsh, Wind River

Creating memory efficient and high performance IP stack for Zephyr OS
By Jukka Rissanen, Intel

Creating Bluetooth-based IoT solutions with Zephyr
By Johan Hedberg, Intel

Improving System Configuration for Zephyr and Beyond
By Andy Gross, Linaro

Linux+Zephyr: IoT made easy
By Pantelis Antoniou, Konsulko group

There are some significant enhancements coming into the Zephyr kernel over the next few releases, with Kernel updates, a new IP stack, new IoT Protocols and support for a number of new boards from across the industry. I’m looking forward to seeing what topics are shared during the next OpenIOT Summit in February.

Don’t forget to check out our Zephyr Community page for instructions on joining the project.

10 Intriguing Technologies from ARM TechCon

Zephyr Project aims to bring real-time to the IoT
For as little as 8kB IoT device developers can have a real-time operating system in their design, thanks to the Zephyr Project. This open-source, community-created code is available through the Linux Foundation under the permissive Apache 2.0 license to make it as uncomplicated to use and deploy as possible.

Read more at eetimes

10 Intriguing Technologies from ARM TechCon

Zephyr Project aims to bring real-time to the IoT
For as little as 8kB IoT device developers can have a real-time operating system in their design, thanks to the Zephyr Project. This open-source, community-created code is available through the Linux Foundation under the permissive Apache 2.0 license to make it as uncomplicated to use and deploy as possible.

Read more at eetimes

Introducing JavaScript* Runtime for Zephyr™ OS

By Geoff Gustafson, Intel Corporation

JavaScript* is one of the most widely used programming languages today, and in recent years has jumped from its origins on desktop web browsers to servers with Node.js*. But it can also be useful in the smallest devices for the Internet of Things (IoT) with the JavaScript Runtime for Zephyr™ OS (ZJS) environment. ZJS is based on JerryScript (a lightweight JavaScript engine) and the Zephyr real-time operating system (RTOS). The ZJS project provides a subset of Node.js APIs and JavaScript APIs that employ sensors, actuators, and communications, as well as the tools to build applications with them. The ZJS environment is easy to learn and great for rapid prototyping, especially for developers who have existing JavaScript skills.

The initial goal for the ZJS project was to work well on the Arduino 101* board. The Arduino 101 is an Intel® x86-based, entry level Arduino platform. The features are similar to the Arduino Uno*, but it adds Bluetooth® Low Energy and an accelerometer and gyroscope.

PREVIEW

Before we get into the details, let’s take a sneak peek at what it can look like to develop a JavaScript application for a small device. This script controls a pair of peril sensitive sunglasses.

var aio = require('aio');
var gpio = require('gpio');
var pins = require('arduino101_pins');

var sensitivityUp = 1500;
var sensitivityDown = 1200;  // hysteresis to avoid flicker

var perilDetector = aio.open({device: 0, pin: pins.A0});
var sunglasses = gpio.open({pin: pins.IO4, direction: 'out'});
var dark = false;

setInterval(function () {
    var perilLevel = perilDetector.read();
    if (perilLevel > sensitivityUp && !dark) {
        print('Peril detected, enabling sunglasses');
        sunglasses.write(true);
        dark = true;
    }
    else if (perilLevel < sensitivityDown && dark) {
        print('Peril averted');
        sunglasses.write(false);
        dark = false;
    }
}, 10);

The peril sensor reports a voltage proportional to the amount of danger detected. The Arduino 101 converts the voltage to a number with 12 bits of precision (a range of 0 to 4095). When the danger level is too high the glasses turn totally black, and the glasses’ wearer is kept free from alarm.

BACKGROUND

The Zephyr Project is an open source real-time operating system first released February 2016 by the Linux Foundation. It supports x86, ARM*, and ARC* processors on a growing number of boards, such as the Arduino 101, Minnowboard Turbot, NXP* FRDM-K64F, and Arduino Due.

JerryScript is an open source, lightweight JavaScript engine fully implementing ECMAScript 5 for constrained devices, supporting even devices with less than 64 KB of RAM or 200 KB of ROM. It already supports x86 and ARM processors on various boards and operating systems.

Intel started working to combine these two technologies in early 2016, with the idea of providing an alternative development environment for the Arduino 101 and future IoT boards using the Zephyr OS. Currently, Zephyr Project applications are written in C, and the programming model requires a fair amount of expertise. A JavaScript interface hides a lot of this complexity. We also wanted to explore the benefits of having JavaScript available at every level, from small embedded devices to the largest servers, and from prototyping to seamless end-to-end applications.

The resulting project is called Javascript Runtime for Zephyr™ OS (ZJS) and provides a JerryScript environment, adds APIs to expose IoT hardware features, and provides tools to simplify the developer experience.

ARCHITECTURE

When you build a Zephyr OS application, you create a monolithic image dedicated to running your single application with only the OS components that your application actually uses, which keeps the image small. The Zephyr OS supports execution thread services, timer services, memory management, synchronization, and data passing services, each of which can be individually included or excluded depending on whether the service is needed. It also provides drivers for the various hardware features of the SoCs and boards it supports, such as general purpose I/O (GPIO), analog-to-digital conversion (ADC), pulse width modulation (PWM), I2C bus, SPI bus, UART, and Bluetooth Low Energy. Again, these can be individually included or excluded to minimize the image’s ROM and RAM profile.

ZJS builds on top of the Zephyr OS’s configurability by simple static analysis of the incoming JavaScript code. If the GPIO interface is used, the needed driver and corresponding ZJS API code will be built and included; otherwise, it won’t. If you use every possible driver, the resulting image will be too large for small devices. For example, adding Bluetooth Low Energy support (including both the Zephyr OS drivers and the ZJS API layer) currently uses an additional 7.2 KB of RAM and 56 KB of ROM. But if you keep an eye on the image size as you develop and limit including additional dependencies as necessary, you can balance these constraints.

Currently, ZJS provides APIs for GPIO, ADC, PWM, I2C, BLE, and a simplified interface for the Grove LCD panel with RGB backlight (an I2C device). It also supports setInterval/setTimeout, a simplified implementation of Promises, and a subset of the Node.js Buffer and Events APIs. Additionally, ZJS includes support for the Open Connectivity Foundation (OCF) specification for IoT interoperability, with the same JavaScript API that the iotivity-node module provides in Node.js. We are working on supporting the Serial Peripheral Interface (SPI) bus, the W3C Generic Sensor API, and other Node.js APIs.

The Intel® Quark™ SE processor inside the Arduino 101 has two MCU cores: one with x86 architecture and one with ARC architecture. Taking full advantage of the hardware requires using both cores, which the C programmer has to deal with directly. But fortunately ZJS makes all the hardware features available from the same JavaScript context. The ZJS runtime communicates with the ZJS support image running on the ARC core seamlessly when necessary. (See Figure 2.)

The Arduino 101 includes 80 KB of RAM and 384 KB of flash memory. By default the flash memory is partitioned to allocate 144 KB to the x86 application and 152 KB to the ARC application. ZJS needs minimal code on the ARC side, so it is beneficial to repartition the device with more room for the x86 application. We have developed a patch for the released Arduino firmware that lets you migrate from the 144 KB x86 partition to a 256 KB partition, and back again. This provides enough room to run much larger ZJS applications. Additionally, we will provide binary flashpacks that make changing or restoring your partitions simple.

ADVANTAGES AND TRADEOFFS

There are several advantages to bringing JavaScript to small, embedded devices.

  • Many people know JavaScript already. This should make development within the ZJS environment more accessible to more people.
  • Javascript enables the ability to reuse code between different environments—desktop, cloud, mobile, and IoT devices.
  • We gain the potential to use a common data exchange format, JSON, between these systems, which reduces the overhead of marshaling boilerplate. JavaScript also opens the possibility of more easily simulating device behavior within a browser.
  • As is typical to any interpreted language, including JavaScript, the development cycle from making a change to seeing the change in action is fast. Admittedly, this advantage is initially lost with our system because you need to compile the Zephyr OS with your application and flash it to the device. But we can reclaim some of this benefit with the ashell feature, which is an insecure developer mode that lets you interact with the device and upload new JavaScript to run without flashing. We plan to build on top of this to provide a browser-based IDE, which might give us the ability to develop entirely in the browser with a simulator.

Of course, there are tradeoffs to using JavaScript in small, embedded devices. Native code is generally going to be faster and smaller. This problem is much more acute on a constrained device because the overhead of the JavaScript engine consumes a significant portion of the system RAM and ROM. This limits the resources left for your application. At the time of this writing, the minimal HelloWorld.js sample requires about 133 KB of ROM. A larger WebBluetoothDemo.js sample requires about 199 KB of ROM and 42 KB of RAM. For comparison, a C implementation of the same WebBluetooth sample requires about 65 KB of ROM and 18 KB of RAM. (The RAM difference includes a large heap allocated for JavaScript which is not all being used.)

The performance differences will also be quite noticeable in cases where a C application might have handled something simple in an interrupt handler. To perform this logic in JavaScript, we have to first queue up an event to be handled in the task context (the Zephyr OS equivalent of process context), make the context switch, then make a callback into the JavaScript engine, and finally have that call into the native API again to have an effect.

There is also the problem of JavaScript being less deterministic in terms of real-time performance. For example, garbage collection can introduce a surprise hiccup in a regular pulse of activity. So JavaScript might not be suitable for apps that have strict real-time requirements, but it is very suitable for general purpose apps. However, as the project matures we might be able to mitigate these types of issues.

DETAILED EXAMPLE

Now let’s take a closer look at some sample code using ZJS that we can use to implement part of an altitude controller for a miniature hot-air balloon. We’ll measure the altitude with an analog sensor and use a PWM pin to control the flow of gas to the burner. Then we’ll blink an LED light for the safety of other air travellers. Finally, we’ll add an abort switch and a vent control for a quick landing.

Figure 3: Hot air balloon
“Hot air balloon” by Rona Proudfoot is licensed under Creative Commons Attribution Share-Alike 2.0.

First, we use the require() function to make optional API modules available. This is a simplified version of what Node.js offers, which currently just lets you pick from existing components built into the ZJS system. This code is based on the early versions of the APIs, and we expect these APIs to undergo significant changes soon.

var aio = require('aio');
var gpio = require('gpio');
var pwm = require('pwm');
var pins = require('arduino101_pins');

Now that we have the API modules we need and the named pin shortcuts for the Arduino 101, we will set up the pins we’re using.

var led = pwm.open({channel: pins.IO3});
var altimeter = aio.open({device: 0, pin: pins.A0});
var gasValve = pwm.open({channel: pins.IO5});
var abort = gpio.open({pin: pins.IO2, direction: 'in', edge: 'rising'});
var vent = gpio.open({pin: pins.IO4, direction: 'out'});

The Arduino 101 supports PWM on pins 3, 5, 6, and 9. Note that vent is a GPIO output, while abort is a GPIO input. We enable an interrupt in the Zephyr OS by configuring the abort pin with a rising edge input.

Now let’s configure the LED on the balloon to blink on for one half second every four seconds:

led.setPeriod(4000);
led.setPulseWidth(500);  // values in milliseconds

Next, let’s write the main feedback loop to aim toward the desired altitude, assuming an ideal altimeter sensor that reports the altitude with 12 bits of precision and covers a range from 1000 m below sea level to 9,000 m above sea level. We’ll take a reading every 50 ms and adjust up or down as necessary.

var targetAltitude = 42 * 20;  // meters, enough to clear Burj Khalifa
gasValve.setPeriod(50);  // ms

var totalError = 0;
var lastError = 0;

timerID = setInterval(function () {
    var raw = altimeter.read();

    // convert raw reading to meters
    var altitude = raw / 4095.0 * 10000 - 1000;

    // implement simple PID controller
    var error = targetAltitude - altitude;
    totalError += error;

    // carefully tuned PID constants for our device
    var proportional = 0.042 * error;
    var integral = 0.00042 * totalError;
    var derivative = 0.0042 * (error - lastError);
    lastError = error;

    // limit pulse to range of valve
    var pulse = proportional + integral + derivative;
    if (pulse < 10000)
        pulse = 10000;
    else if (pulse > 20000)
        pulse = 20000;
    gasValve.setPulseWidth(pulse);
}, 50);  // every 50ms

Finally, let’s land fast if we detect that we’re out of gas or receive an abort command from a radio controller:

abort.onchange = function(event) {
    // open the vent
    event.write(true);

    // stop the loop (smooth landing left as an exercise for the reader)
    clearInterval(timerId);
}

When we set the onchange function, internally we set up a callback to handle the rising edge interrupt from the abort switch pin. When that interrupt comes, we store the updated value from the pin and signal a callback to be handled from task context in the main loop. When the main loop runs and processes that callback, it is safe to call into the JavaScript engine and update this onchange function with the new value (although we don’t bother to look at the event.value in this particular JavaScript callback).

This code should be pretty easy to understand if you have experience with JavaScript, and you can see the power of being able to work with real world sensors and actuators in such a straightforward way!

GETTING INVOLVED

We are just now opening up our repository on GitHub and it’s still quite early. We invite you to take our code for a spin, and welcome you to join us in defining the project’s future. There are plenty of areas waiting for contributions and ownership, such as new APIs, new platform support, improved debugging, image size optimization, software update, or whatever you can think of.

The project is hosted at http://github.com/01org/zephyr.js and development discussions happen on a #zjs channel on Freenode.

Intel and Quark are trademarks of Intel Corporation or its subsidiaries in the U.S. and/or other countries. Zephyr is a trademark of the Linux Foundation. The Bluetooth® word mark and logos are registered trademarks owned by Bluetooth SIG, Inc., and any use of such marks by Intel Corporation is under license. *Other names and brands may be claimed as the property of others.

Open Source RTOS for IoT Gains Support from Linaro

With more than 25 billion Internet connected things predicted to hit the market by 2020, the “Internet of Things” is evolving from a promise to an everyday reality. Whether it’s how we control our energy usage or secure our homes, smart devices are changing the world we live in and how we live.

Read more at Linux.com