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.