Category

Blog

Using Renode to run real multi-node Zephyr setups without physical hardware

By | Blog

Written by Michael Gielda, Zephyr Project Community Member and Business Development and Board Member for Antmicro

If you’re working with multi-node Internet of Things (IoT) systems, you probably have experienced problems related to testing, security, interoperability, reuse, lifecycle management, and code quality involved in building real-life networks.

To address these problems, new tools and workflows are needed that allow developers to collaborate around code more effectively. These tools and workflows must increase the test coverage and understanding of the software and protocols running on the devices that form the backbone of our homes, offices, factories, and cities, both now and in the future.

The open source Renode framework from Antmicro, which started a collaboration with the Zephyr project in 2017, is aimed at doing exactly that: Renode lets you simulate complex wireless (and wired) setups running real binaries so that you can do testing, continuous integration, and debugging to an extent that wasn’t possible before.

Sound promising? We hope it does. And it’s not as complex as it sounds. In this blog note, we’ll explain how Renode can help you in your daily development without forcing you to rewrite your software or abandon your familiar toolset.

Renode can simulate physical hardware systems – including the CPU, peripherals, sensors, environment, and wireless medium between nodes. Just develop your IoT software, including software based on the Zephyr RTOS (real-time operating system) using your familiar processes, and then use Renode to debug and test it in various circumstances. The tests includes protocols and applications that span multiple nodes. You can run them in a joint virtual environment with full determinism and control over the execution parameters.

For example, at the 2017 Embedded Linux Conference (ELC) Europe, the Renode and Zephyr teams jointly showcased a fairly complex simulated wireless setup. With nodes based on two architectures (x86 and ARM) and running two different RTOSes (Zephyr and Contiki), the demo showed how easy it is to perform interoperability testing with Renode.

In this note, we’d like to focus on how a simple multi-node setup can be reproduced from the comfort of your chair. This short tutorial can act as a starting point for your development with Renode and Zephyr.

  1. Installing Renode
    The Renode framework is hosted on GitHub - https://github.com/renode/renode. You can use the README file to download and install it, but the easiest way to start is by downloading a binary release from https://github.com/renode/renode/releases. The precompiled packages are provided as deb and rpm packages for Linux, a dmg package for macOS, and a zip archive for Windows.

  2. Starting Renode
    This tutorial uses the Renode command line interface, which is one of many ways to interact with Renode. After installation, run the renode command. Alternatively, look for the Renode.exe binary. Once Renode is started, you will see two windows: one for Renode’s smart logger (you can control what’s being logged) and one for the command line interface (CLI) called the Monitor.

    From this CLI window you can create and control the whole emulation environment.

  3. Scripts
    While you can type all commands interactively, it’s a good idea to group them into reusable Renode scripts, which typically have the .resc extension. The scripts can be used to load binaries, set starting conditions, prepare the environment, connect machines to the network, and other tasks.

    This tutorial uses scripts available in the Renode package named: scripts/many-nodes/quark-c1000-zephyr/demo.resc and scripts/many-nodes/quark-c1000-zephyr/quark_c1000.resc. For details on the scripts, please review the commented files in the Renode installation directory. (For Linux, opt/renode/scripts is the default.)

  4. Loading our setup
    The tutorial setup consists of two Intel Quark C1000 nodes with a TI CC2520 radio connected via SPI. The nodes run applications based on Zephyr demos, an echo_server and an echo_client, compiled as normal for the target hardware. (The provided scripts use precompiled binaries hosted online, but you can provide your own binaries by changing the relevant $BIN variable in the scripts.)

    In Renode, the nodes are assigned coordinates in a virtual 3D space. By manipulating the maximum range of the wireless medium or moving the nodes around, we can put them in or out of each other’s range, and form different topologies, building routing scenarios of various complexity. In this simple example, the nodes are within each other’s range and we won’t move them around or make them lose packets.

    To run a script, use the include command (or i, for short), with a path to the script to load, prepended with the @ sign, like this:

    include @scripts/many-nodes/quark-c1000-zephyr/demo.resc

    After the script is loaded, you will see two new terminal windows. These are UART windows opened for each machine.

    The emulation is now loaded, but not started. You can control it using start and pause and other commands that are described in the next section.

  5. Simple commands
    1. Start and pause
      To control whether the simulation is running, use start and pause.
    2. Machines
      In the provided scripts, we use the mach create command to create new machines. This switches the context in the Monitor. All subsequent commands are executed with regard to the current machine.

      To change the machine, use the mach set command. Use a number or the name of the machine, for example, mach set 1 or mach set servername.

      All machines can be listed with the mach command. To clear the current selection, use mach clear.

    3. Accessing peripherals
      All peripherals are accessible in the Monitor, with most of their methods and properties exposed to the user. To list all available peripherals, use the peripherals command.

    4. Peripheral methods and properties
      To access a peripheral, you have to provide its path. All peripherals are registered in sysbus, so use sysbus.uartB to access the second UART or sysbus.spi1.radio to access the CC2520. The using sysbus command is used in most of the provided demos, allowing you to drop the sysbus. prefix. Typing a peripheral name gives you a list of available methods, fields, and properties. The list is automatically generated, and most of the accessible members are not designed for the end user. The list shows examples of correct Monitor syntax for each member type.

    5. Other commands
      To find information about built-in Monitor commands, type help and refer to the documentation. Running help prints out the help for the given command.

  6. Debugging and inspection
    Renode provides many ways to verify the behavior of your applications. Thanks to having full control over the environment, you can add logging, hooks on events, interactive code debugging, and more in a way that is completely transparent to the emulated application. Since this is a simple tutorial, only a few debugging options are listed below, however, many more are available.

    1. Function name logging
      When the application is stuck or misbehaves, it is a good idea to inspect the trace of function calls. To enable logging of function names in a selected machine, run cpu LogFunctionNames true (use false to disable it). Since the amount of logged data may be too overwhelming to be useful, you can filter the logged functions to the ones that begin with a specified prefix. For example cpu LogFunctionNames true “uart_ qm_” only logs functions that begin with either the uart_ or qm_ prefix.

    2. Logging of peripheral accesses
      If your driver does not behave correctly, it may be beneficial to investigate communication with the device it controls. To enable logging of each interaction between the CPU and the UART peripheral, run the sysbus LogPeripheralAccess uartB command. This feature is available only for peripherals registered directly on the system bus.

    3. Wireshark
      Network traffic analysis is a common task in every multi-node system. Since Wireshark is a tool of choice for programmers, Renode supports it for both Ethernet and wireless networks. There are multiple options for choosing which interfaces should be logged, but the easiest way to observe all packets in an IEEE 802.15.4 network is to run the emulation LogWirelessTraffic command.
      This command opens a new Wireshark window. If you close it, you can always reopen it by running host.wireshark-allWirelessTraffic Run.

    4. GDB (GNU Project Debugger)
      A popular tool for debugging, GDB can be used to analyze applications running in Renode. It uses the same remote protocol as OpenOCD, so it can be easily integrated with most GDB-based IDEs, such as Eclipse. To start a GDB stub in Renode, run cpu StartGDBServer 3333 (where 3333 is a sample port number) and connect from GDB by calling (gdb) target remote :3333. To start the emulation, you have to run both start in Renode and continue in GDB.
      You can use most of GDB’s regular features: breakpoints, watchpoints, stepping, reading/writing to variables, etc. You can also use the monitor command in GDB to send commands directly to the Renode CLI, to avoid switching between two console windows.

We hope that this short tutorial will help you get started with Zephyr and Renode, which has recently become one of Zephyr’s recommended developer tools: https://www.zephyrproject.org/developers/developer-tools/.

In a future blog post we’ll continue this tutorial with details on more complex wireless setups – stay tuned!

RenodeTM is a software development framework from Antmicro, a technology company building software-driven IoT systems. If you need help with implementing your platforms and setups in Renode, adopting a Continuous Integration workflow inside your organization, integrating with your tools or building custom ones, or IoT system development services using the Renode methodology, please contact them at contact@renode.io.

Zephyr Leverages HALs to Accelerate Viability

By | Blog

By Maureen Helm and Frank Ohlhorst

For many, the debate continues on the applicability of incorporating HALs (hardware abstraction layers) developed by vendors into open source projects. However, no one can deny the power of HALs when it comes to accelerating development.

HALs have long acted as the bridge between software and hardware for numerous commercial products, as evidenced by the rise of commercial virtualization products and the hardware components that are virtualized.

The ideology behind developing and incorporating HALs originated in the realm of closed source and proprietary projects, where vendor control reigns supreme and open source ideologies may be eschewed or ignored. So that begs a question: “Why would any open source project want to be involved with HALs, instead of creating their own hardware stacks?”

The answer to that question comes down to balancing expediency with reliability, along with the promise of cooperation. The Zephyr Project community is undertaking work with HALs to make sure the project moves ahead at a rapid pace and effectively addresses the ever-growing IoT market.

Zephyr, HALs and SoCs

Most IoT (Internet of things) devices are built around SoCs (system on chips), necessitating either that drivers be written to directly access the hardware, or some form of hardware abstraction is used to act as an intermediary between the hardware and the device’s operating system.

While creating native drivers offers more control over a device, it is a very time-consuming process, which requires extensive testing to prevent failures, security issues, and numerous other problems from arising. In contrast, HALs provided by IoT vendors with SoC implementations can prove to be more refined and have gone through QA testing, removing that burden from open source project developers. However, those developers need to work within the confines of the provided HAL.

The Zephyr Project focuses on delivering a small footprint RTOS (real-time operating system), that works across different architectures, including ARM, x86, ARC, NIOS-II, RISC-V, and Xtensa. Developing direct access code for those numerous platforms, as well as keeping a small footprint, would be a time-consuming chore fraught with potential problems. With that in mind, the Zephyr Project technical community researched the advantages offered by SoC vendor-derived HALs for quickly advancing the project.

Advantages of HAL Adoption for Zephyr

For Zephyr, SoC vendor HALs offer several advantages, including:

  • Code is maintained elsewhere, meaning that there is less to write, review, and maintain. What’s more, permissive licensing and regular vendor-provided updates reduce overhead.
  • Code is used elsewhere, bringing a higher level of maturity, as well as more extensive QA testing.
  • Expanded levels of abstraction provided by HALs allow for a range of new or reusable Zephyr code.

These advantages, combined with the expediency offered by SoC-provided HALs, make integrating HAL-driven abstraction a logical choice for the Zephyr Project.

More to HAL than Meets the Eye

While the advantages of leveraging HALs for Zephyr OS are clear, there may still be questions around the level of abstraction needed and how that impacts cross-platform compatibility across differing IoT devices—a concept that has driven the adoption of three different levels of HAL abstractions, each impacted by developmental tradeoffs when integrated into Zephyr.

  • The highest level of abstraction is within transactional HAL drivers, where the greatest amount of vendor code is reused and relatively little new Zephyr code is written. In the Zephyr community, members such as Intel and NXP leverage such an approach.
  • The next level of abstraction is a “low-level” or stateless HAL driver, where some custom Zephyr code needs must be written to support HAL integration, and some code reuse can be leveraged. The driver sets developed by STMicro use this approach.
  • Finally, the lowest level of abstraction is accomplished at the register level, where integration of HAL support requires creation of a near-native Zephyr driver reusing vendor-provided register definitions. Atmel and Nordic use such an approach.

Understanding how HALs are derived and implemented proves to be just as important as the level of integration chosen. They are a critical element for advancing the Zephyr Project, especially since code reuse can be accomplished when using the highest levels of abstraction, without closing the door on drivers that require registry-level abstraction.

Zephyr Project Brings IoT Expertise to the Embedded Linux Conference Europe

By | Blog

The Adoption of IoT (Internet of Things) technology has grown at an enormous pace. Forbes.com has reported that spending on IoT will increase to $267 billion by the year 2020, indicating how important that the technology will become to businesses around the world. Nevertheless, IoT is not without its challenges. These include security, connectivity, and choosing the right OS best suited to address those issues.

The open source Zephyr Project is setting out to resolve these issues. However, solving those problems is only one part of the IoT puzzle. What is needed is innovation and normalization — two specific components that fit well into the world of open source, giving  IoT adopters the ability to delve deeper into the software that underpins IoT functionality.

The Zephyr Project entered into the small OS and RTOS market with the intent of reducing fragmentation for developers in the IoT and embedded arena. One of the biggest stumbling blocks for software with respect to IoT adoption is trying to provide a solution that solves the problems of embedded development like connectivity, security, safety certification, and in the case of small OSs and RTOSs, all with the intent of ultimately delivering real-time responsiveness.

The Zephyr Project leverages the best-known methods of open source community development, like the Linux OS, to build an RTOS for IoT that attempts to address these types of issues. This mission has helped to create a collaborative community, which is constantly growing. The community includes a broad swath of those working in the embedded development space and encourages communications, collaboration, and the sharing of knowledge to continuously improve the project.

Growing the community and encouraging more to participate will help to accelerate the evolution of the Zephyr project and bring more capabilities to the table. With that in mind, the Zephyr Project is creating opportunities for additional community outreach.

To better serve the community and encourage additional participation, the Zephyr Project team will be hosting a booth at the forthcoming Embedded Linux Conference Europe, which takes place Oct. 23-25, 2017, at the Hilton Prague, Prague, Czech Republic. The Zephyr Project aims to expose the advanced features offered by Zephyr OS V1.90, as well as host technology sessions on Bluetooth Mesh with Zephyr OS and Linuxand Using SoC Vendor HALs in the Zephyr Project.

There is no doubt that the Zephyr OS codebase  is evolving and becoming more important to the purveyors of IoT community. Nonetheless, strength comes in numbers and the Zephyr Project welcomes more participation from experts in the embedded community to help develop its open source platform.

The technical leadership from the project will be available at Booth L9 to answer questions about the code, discuss how to become involved with Zephyr Project, and convey the importance of the Zephyr Project to the future of IoT development.

What’s more, the Zephyr Project team will be offering demos on important components and capabilities that highlight the disruptive nature of the Zephyr OS and why it will be so important to the world of IoT. Those demos include:

  • NXP Hexiwear
  • Renode.io
  • Bluetooth controller on Nordic
  • Bluetooth Mesh

At the event, the Zephyr Project team will bring together knowledge, action, and insight that will help to bring much needed normalization to the IoT market. Please visit us at the Zephyr Project booth at Embedded Linux Conference in Prague, Oct. 23-25 to learn more about the project and how to become part of the community.

Insider Advice on Getting Your Pull Request Accepted to the Zephyr Project

By | Blog

There are a lot of benefits to being a Zephyr Project contributor. You’ll have the opportunity to improve your existing skill sets, find mentors, teach others, work with like-minded individuals, create public artifacts, build a reputation, and even learn some people skills in the mix.

Although submitting some code to improve the project can be its own reward, there is a bigger picture here. One where participants have the opportunity to become part of the innovation behind what Zephyr Project is all about, a new real time OS that will have a significant impact on IoT.

Contributing to any open source project for the first time may seem somewhat complex and intimidating. We at the Zephyr Project understand this and want to officially welcome your ideas and code contributions.

It’s pretty common for new contributors to face some basic hurdles on the path to getting a “successful pull request,” a situation where code can be reviewed and discussed for inclusion in a project, ultimately becoming part of the upstream repository. Pull requests are further covered in the Zephyr Project’s community guidelines documentation and getting to one takes following some outlined instructions in that document.

To help smooth the process, we’ve gathered some tips and tricks on how to get a contribution noticed — straight from the project’s maintainers.

Things to Do Before Submitting a Pull Request on the Zephyr Project

Before you create a pull request, it’s a good idea to orient yourself to the community a bit and make sure to address some basic issues. This will increase the likelihood that the community embraces the ideas presented in a new code snippet and the required number of reviewers approve moving ahead.

  • Look at Existing Zephyr Code. Contributors should always look at the existing Zephyr code before they write any new code. There may be identifiable patterns or snippets that may ease the creation of new code and can ultimately help out when developing new code.
  • Leverage Git-Extras. Many platforms support the git-extras package, which can greatly simplify interactions with GitHub, speeding the process and submission of code as well as handling some of the basic housekeeping chores.
  • Don’t Forget About IRC. Many community members are available via IRC and in many cases an simple answer to a complex question may just be one post away. IRC gives contributors the ability to share information, ask questions, get advice, and ultimately build comradery that improves interactions.
  • Check the Maintainers File. It’s always a good idea to do a little research before diving into creating any new code. At the very least, contributors should delve into the maintainers file to contact a maintainer of a particular subsystem directly. That in turn may provide additional background that will be useful for creating any code and also may help smooth the path to a successful Pull Request.
  • Remember non-Apache 2.0 Components: The Zephyr Project is robust enough to support non-Apache 2.0 components, allowing an added level of creativity. However, contributors should make sure they contact the TSC mailing list before submitting a pull request to validate component inclusion. That helps to ensure that no efforts are wasted and that the components can be included.

Taking the Next Steps

After going through what you should think of as due diligence, there are some other steps that can help smooth the path to successfully contributing code to the Zephyr Project.

  • Understand When to Make a Pull Request. In other words, make sure you have your ducks in a row before making a Pull Request, perform due diligence, make sure all required info is included and standards are considered.
  • Communicate Meta Info. Contributors often forget to include metadata, which is often a critical element that a reviewer wants to see.
  • Communicate Professionally. Be courteous and professional in all of your communications with the community. Disagreements need not ever turn into arguments.
  • Be Willing to Revise. Changes, requests, and revisions are a part of community life. Be accommodating and be willing to address concerns and make changes if need be.
  • Adhere to the Project Standards. The rules and standards do serve a purpose. Ultimately, they exist to keep the submission process smooth and hopefully quell any errors or bugs.
  • Initially Propose Small, Backwards Compatible Changes. It is the quality of the code and the purpose that it serves that counts the most. In the beginning, it’s better to focus on small changes than to try and make huge changes to the code base.

By following some simple guidelines, accepting sage advice, and communicating with the community, contributors can see their code incorporated upstream and help advance Zephyr and the broader community of embedded technologies that promotes innovation and the development of open source code.