Re: HALs in Zephyr (was Re: STM32Cube SDK in Zephyr)

Chuck Jordan <Chuck.Jordan@...>

I would only that add that a HALL or SHIM layer should be implemented two different ways, depending on whether the user wants a size optimization or a speed optimization. For size, commonly called functions are good for smaller size, but bad for performance.
If speed is wanted, macros and/or inline functions are wanted.
Further, if speed is wanted, any argument checking or PARANOID code checks should be STRIPPED.

Some targets have large amounts of memory for code, and so size is not an issue, but speed is the issue.
Some targets have tiny memories, and thus size is the only optimization that matters.


-----Original Message-----
From: Marcus Shawcroft [mailto:marcus.shawcroft(a)]
Sent: Tuesday, November 15, 2016 7:14 AM
To: Amit Kucheria <amit.kucheria(a)>
Cc: Tomasz Bursztyka <tomasz.bursztyka(a)>; devel <devel(a)>
Subject: [devel] Re: Re: Re: Re: Re: HALs in Zephyr (was Re: STM32Cube SDK in Zephyr)

On 15 November 2016 at 13:22, Amit Kucheria <amit.kucheria(a)> wrote:

Yeah I didn't want to bring this up (binary size, memory consumption)
until I'd actually done some comparative studies which is hard since
you basically have to write two different drivers - one with HAL and
one without. I'll take the porting opportunity to do some
We have one data point already in the ksdk ethernet driver that Tomasz referred to. Due to the architectural difference in buffer handling between zephyr and the underlying HAL abstraction the shim needs a spare ethernet packet sized buffer available in order to copy data from the network stack to the driver and likewise in the opposite direction. Further, the HAL driver itself has one set of buffers sufficient to hold at least one frame, while the network stack has its own buffers. Hence we are wasting order of 3k RAM above what a bespoke driver might be expected to need.

The ksdk driver could be adjusted to provide a scatter/gather interface which would remove the need for at least one set of buffers, but a proper solution, one that allowed the third set of duplicate buffers to be removed, would require the ksdk implementation be adapted such that we could plumb in the host os's buffer abstraction.
This would be a much more invasive change.

The other point worth mentioning is that these HAL abstractions generally provide at least two features.
1) Definitions, consts, #defines, structs etc that define the register interface to a bit of hardware
2) Functions that provide pre-canned functionality (sometimes quite elaborate).

The former are generally useful but don't impose architecture on the user, the latter are more problematic if the pre-canned architecture clashes with the host os architecture.

The issue mentioned above w.r.t the ksdk ethernet driver is due to the architecture of the pre-canned functions provided in KSDK. One could imagine a version of the ksdk ethernet shim driver that used the ksdk register definitions (and some of the low level plumbing) while providing its own higher level functions.

It isn't clear to me that this is an either/or discussion. I don't see a compelling technical, stability, quality or maintenance reason why we should not have co-existing native and hal/shim based drivers. The HAL/shim route providing rapid scale out of device coverage with bespoke drivers written and dropped in where the hal/shim driver characteristics are unpalatable.

Given that we have the HALs in the tree along with their low level definitions, it would be pragmatic that we use those definitions where possible even if we choose not to use (some of the) pre-canned higher level functionality. Since doing so should have no impact on footprint, performance etc, minimises code duplication in the tree, and minimises overall effort in moving zephyr forward.


Join to automatically receive all group messages.