Define HAL above or below driver layer? [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 9 years ago.

Improve this question

When defining an embedded system architecture, there are two options when it comes to defining the HAL -

• Define the HAL above the driver layer (which means one'll need to rewrite drivers for every platform you port to)
• Define the HAL below the driver layer (which means one'll need to rewrite the HAL for every platform you port to)

Which one is better and why?

Answer 1

Short answer: yes.

Having a HAL ( or Stable driver ABI below drivers is nice, especially for driver writers) Having a HAL above drivers is nice for Application programmers.

You can do both: look at Unix device drivers; fairly portable.[Endian-ness still bites though]

Which is better depends on the embedded architecture's product development roadmap.

Lets try some examples.

Lets' say it's a commercial product and your company doesn't see a need to port across platforms. In this case you don't care.

If your company is using it in, for example a TV set, and it's expected the platform will change but the devices will stay the same ( A TV is a TV is a TV, but the cheapest micro will change over time) Then you'd go with hal-below-driver, and keep your investment in drivers.

If your company makes, for example smart-phones, the processor changes and so do the devices, as resolutions change, extra sensors get added... so in this case, you'd go with hal-above-driver, and keep the big part of the software load common.

If you put in two HAL's, for embedded, you run the risk of turning into an architecture astronaut. If the cost of the two HALs ( runtime and design time) exceeds the labor saved in porting across platforms then it's a waste of time and money.

How much effort goes into a HAL is equally a tradeoff. Too much abstractin in a tiny embedded system cannot be afforded.

Again, this trade-off depends on a tiny platform being the right choice for your application, which ultimately depends on the relative importance of time-to-market and features vs cost-per-device. Much is said about needing to go cheap for volume markets; little scientific proof is provided. One of the most profitable embedded device manufacturers is Apple, not using a tiny platform. ( Heck, they're not on the NASDAQ anymore because they distorted it so much)

If you have no HAL, and you have to change platform, e.g. your processor goes end of life, you have a big hard rewrite.

If you try applying the YAGNI rule (You Aren't Going to Need It) without a tradeoff study you may cost the company a fortune later.

Now, if you get blind-sided by technology taking a turn you didn't expect, then your tradeoff studies will be wrong and your company will suffer.