At Embedded Linux Conference Europe, NXP developer and Zephyr Project member Maureen Helm proposed that the benefits of vendor HALs outweigh the drawbacks.

The use of vendor-supplied HALs (Hardware Abstraction Layers) in open source projects has been a source of ongoing debate. At the October ELC Europe conference in Prague, Maureen Helm, an MCU Software Architect at NXP, discussed the pros and cons of the practice. Ultimately, she argued that that the benefits far outweigh the tradeoffs. This viewpoint was expanded upon in a recent Zephyr Project blog post by Helm and Frank Ohlhorst.

NXP’s Maureen Helm surveys the major HALs used in Zephyr
(click image to enlarge)

The main reason for using vendor-supplied HALs is to reduce coding and testing time, Helm told the ELCE attendees in “Using SoC Vendor HALs in the Zephyr Project.” The Zephyr Project maintains and develops the lightweight Zephyr OS for microcontroller units (MCUs), the number and variety of which have soared in recent years.

“A lot of these SoCs have thousands of different register and register fields,” said Helm, a member of the Zephyr Project Technical Steering Committee. “Vendor HALs give us core and peripheral registry definitions so we don’t have to build them ourselves. It’s a lot of boring code that’s difficult to check, so if we can reuse it we’re definitely interested.”

Helm noted there are tradeoffs in relying on code that is developed and updated by SoC vendors. If Zephyr developers find a new bug, “it’s much more difficult to update the code upstream,” said Helm. Yet, most of the SoC vendors are usually pretty good at finding and fixing bugs and sending out updates, she added. “This saves countless hours that would be required to maintain them at Zephyr Project.”

Licensing mismatches are another challenge. “Occasionally we see licenses that are not necessarily compatible, in which case we need to ask the governing board to determine if the license is acceptable,” said Helm. “However, it’s usually just a new open source license that turns out to be compatible with Zephyr’s permissive Apache 2.0 licensing. It’s typically BSD 3-clause.”

Another complication is that HALs are used by other products and projects within different contexts, and those use cases feed back into the code. For example, “you might find APIs that are not compatible with Zephyr, so it’s difficult to use the driver,” says Helm. “Sometimes a feature that’s available at the API level in Zephyr isn’t implemented in the lower level HAL driver.”

On the other hand, contributions by multiple projects also help the HAL to evolve more quickly. “You can get additional maturity through external usage,” said Helm. “The HALs have been tested in other contexts, so the drivers have usually gone through more QA testing.”

Addressing concern that use of vendor HALs can run counter to the open source process by turning it over to commercial vendors, she noted that “we have a lot of collaboration coming from different companies and vendors.” Indeed, Zephyr’s vendor HALs come from Arm, Atmel, Intel, Nordic, NXP, SiLabs, STMicroelectronics, and Texas Instruments (see main image above).

Most major MCU vendors are supporting Zephyr alongside two other wireless-savvy, open source RTOSes: FreeRTOS and Arm’s Mbed. One could argue that Zephyr is more vendor-neutral than Mbed and FreeRTOS.

 
Three Flavors of Vendors HALs

The Zephyr Project has made HALs more effective by splitting them into three categories: transactional, low-level stateless, and bare metal. This allows developers to choose from a range of abstraction levels. You can save coding and testing time with a high-level transactional HAL or get down and dirty by working with a stateless or bare metal driver.

Transactional HALs offer the highest level of abstraction, and therefore the most code reuse. These include Arm’s CMSIS (Cortex Microcontroller System Interface Standard), NXP’s MCUXpresso (formerly Kinetis SDK), and Intel’s QMSI (Quark Microcontroller Software Interface). “Transactional HALs are ideal because there’s a lot less custom code to write,” said Helm. “We can leverage something that’s already been tested. This is the thinnest type of driver in terms of Zephyr-specific code to enable a peripheral or API.”

Many vendor HALs also provide low-level stateless peripheral drivers, which limit code reuse, but offer more control. “These build on things like how do you set the baud rate when talking to a UART,” explained Helm. “There’s no state, so it’s up to a higher-level driver or application to manage that.” Some low-level stateless drivers are bare metal transactional drivers, which manage some of the peripheral state, but lack RTOS or threading awareness. “We use these to build a slightly larger Zephyr shim driver, which is common with STM32 parts.”

Finally, there are drivers that are limited to register definitions. “These offer the lowest level of abstraction with the least reuse,” said Helm. “In this case, the Zephyr driver is virtually a native driver. You see this in Atmel and Nordic drivers.”

Helm went on to take a deeper dive into CMSIS and MCUXpresso, and discussed how the Zephyr Project stores externally maintained code in an ext/ folder to differentiate it from native Zephyr code. “We try not to modify anything we put in ext/ — or modify it as little as possible,” she added.

Helm also explained the Zephyr Project’s new import process for vendor HALs, which requires that HAL contributors first determine if the new SoC is part of an existing family. The process requires that contributors look at potential code reuse, license compatibility, and compatible stateless drivers.

Helm hints that the resistance to vendor HALs may derive more from the origin of HALs than from today’s reality. “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,” wrote Helm and Ohlhorst in their blog post.

Yet, many SoC vendors have grown accustomed to working with open source projects, and have become more responsive in updating and upstreaming. Helm and Ohlhorst argue that these positive trends in combination with Zephyr’s flexible, three-layer approach and rigorous new import process make HAL integration crucial to Zephyr’s success. As their blog post points out: “No one can deny the power of HALs when it comes to accelerating development.”

You can watch the full video of the ELCE presentation below:

”Using SoC Vendor HALs in the Zephyr Project”

This article is copyright © 2017 Linux.com and was originally published here. It has been reproduced by this site with the permission of its owner. Please visit Linux.com for up-to-date news and articles about Linux and open source.