Marcus Shawcroft <marcus.shawcroft@...>
On 15 November 2016 at 13:22, Amit Kucheria <amit.kucheria(a)verdurent.com> wrote:
Yeah I didn't want to bring this up (binary size, memory consumption)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.