What comms & networking support is available for the project today?
Early support for communication and networking technologies integrated for initial release including:
Bluetooth 4.2-compliant Bluetooth Low Energy software stack for HCI–based adapters.
GATT server (for sensors) and GATT client (for devices reading sensors),
L2CAP and GAP
Protocol stack and drivers for both 3- and 5- wire UART-based HCI adapters.
Initial verified drivers to work with TI CC2564 and with CSR8811-based BT830 adapters
IP stack supporting IPv6 and IPv4 (by 802.3 transceiver driver) , RPL, UDP, DTLS, CoAP
- IEEE 802.15.4 support with driver for TI CC2520 including 6LowPan support
What boards are supported by Zephyr Project now?
Zephyr Project supports multiple architectures including ARC*, ARM* and x86. Current ARC support is provided through the Intel® Curie* module found on the Arduino 101* platform. Support is provided via reference code that is available through the project. Use of the Zephyr Project on the Intel Arduino 101 development platform is solely for evaluation purposes. Details regarding functionality supported on the board can be found here: https://wiki.zephyrproject.org/view/Supported_Boards
What debugger will be used?
The kernel has several options that enhance debugging with GDB. GDB is the primary tool used for debugging although support for additional debugger could be added.
What compilers are supported?
GCC is supported as the default compiler. Clang is also supported but is not thoroughly tested.
On the tool chain, what C library are you using?
The Zephyr Project does provide a minimal C library that implements basic C functions to help primarily with testing and to support provided sample applications. It is possible to use an external bare metal C library such as newlib. Newlib is provided as part of the Zephyr SDK and can be configured to be used in place of the minimal C library.
To what extent is security integrated into the project and how ready is it for security audit?
The open source code is reference, and provided for product teams to build upon. It currently implements TinyCrypt, which provides SHA-256, AES-128 (CBC, CTR modes), HMAC (via SHA256), PRNG (via HMAC-SHA256), ECC and CMAC support.
Security audit, like safety certification, will be addressed during Governing Board meetings to discuss the degree of implementation. Early governance meetings have agreed to establish a security working group focused on ensuring security is integrated into the community branch, and this same body will investigate the possibility of maintaining a separate branch that is validated for security. The breadth of implementation will depend on guidance from community and steering committee members regarding readiness for any type of security audit and the resources assigned to advise on the security audit/ certifications of the code base
What is the project’s position on safety certification?
The project is open to safety certification. Safety certification requires a strict development process which could best be implemented with a parallel code base. This will require additional engineering resources and likely will require additional spending from the participating numbers to fund the certification. Given safety certification could save many organization’s significant time, there is likely financial advantage in sharing the cost of certifying the OS. The early governing board meetings would need to consider these factors and others before agreeing upon whether this is valued by all participating members.
What is the rationale for choosing the Apache 2.0 license?
here were three main factors influencing the decision to choose the current license model:
The licensing model needed to be permissive enough to allow the community and customers to use code, and contribute what they feel will be valuable back to the community.
We wanted an Open Source Initiative (OSI) approved, permissive license that is in broad use and is well known.
Apache 2.0 has a well understood patent grant
A permissive license gives the user the option to use proprietary extensions or share their code. Contributions are accepted without a Contributor License Agreement (CLA), and the expectation is that contributions will have the license captured as part of the headers in the code. IP compliance will be checked prior to acceptance into the codebase.
The project decided to use a well-known, permissive license to expand membership to a broad set of organizations including those who have not typically participated in open source development in the past. When we form the community, then we can re-open discussion about license through the governing board.
What is the reason for choosing the current implementation rather than others similar solutions like NuttX, ThreadX, or others?
The code base has been developed by borrowing the best-of-breed features from other projects-- such as MicroIP (Contiki), 802.15.4 (Contiki), Crypto libraries (TinyCrypt) -- and choosing those components that were the most mature and provided the most support for development. The Zephyr kernelis not “new” or built from scratch. It is derived from a DSP RTOS called Virtuoso* that has evolved over 20 years. Most recently, Wind River has developed a commercial version of this and has deployed it via their Wind River Rocket* product.
There are also non-technical reasons for choosing the current code base. As other alternatives were evaluated, other factors were taken into consideration, including community development, licensing model and fees, corporate investment, and the level of openness of the OS development. Many of these open source solutions are open source in the sense they’re distributed via an open source license, but they are lacking in the openness of development. For example, some projects are maintained and developed by only one person. In other instances, there is a licensing fee for integrating the solution into a product. In other cases, the project is developed via academia, where the development is open source in nature, but ongoing maintenance of the project and its long term viability for use in products is uncertain. Other projects lack licensing compatibility rigor, clear patent terms, corporate investment, or neutrality of trademark. We have chosen to establish a truly open source developed solution focused on creating a project that can be molded and evolved through community development. The goal is to allow commercial and open source developers alike to define and develop a solution best suited for their needs.
What makes the Zephyr project “open”?
The vision for the Zephyr Project is to create a truly community-based, open source RTOS that isn’t just called “open”, isn’t just licensed “open”, but actually lives and breathes the “open source way” (http://opensource.com/open-source-way and http://www.theopensourceway.org/). We want this project to be useful to the largest number of developers worldwide and in any industry that needs it. For that to happen, we are seeking discussion and active participation from a broad range of organizations. We want collaboration so that the Zephyr OS can evolve to meet the needs of its community.
The project has identified a core set of Maintainer roles – kernel, subsystem, architecture (ARM, x86, ARC, and others), security, and developer experience. As the Zephyr Project matures, the Maintainer roles will also grow to accommodate the need of managing the detailed subsystems, additional hardware support, and other features as well as documentation, advocacy, community management, financial management, and all the other trimmings needed for a healthy organization. We expect these roles to come from the member organizations, particularly those who have a proven track record of RTOS and small OS development. As with most open source developed projects, the Zephyr project seeks contributors willing to learn the codebase and contribute support via feedback, code, and feature development to evolve the software to become more modular and better suited to distributed and open development. Finally, the project seeks community managers with expertise in working and facilitating with open source development.
Contact us firstname.lastname@example.org now if you are interested in taking an active role.
What is Zephyr project?
Zephyr™ Project, a Linux Foundation Collaboration Project, is a small, scalable real-time operating system for connected, resource constrained devices. The project is an open source collaborative effort uniting leaders from across the industry to build a best-in-breed real-time operating system (RTOS) optimized for resource constrained devices, across multiple architectures.