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


Mirza Krak
 

2016-11-08 8:51 GMT+01:00 Amit Kucheria <amit.kucheria(a)verdurent.com>:
Hi Erwan,

On Thu, Nov 3, 2016 at 8:07 PM, Erwan Gouriou <erwan.gouriou(a)linaro.org> wrote:
Hi all,


There are growing number of STM32 based boards being ported in Zephyr
by the community. As part of ST, I can say that we are pleased to contribute
this way to Zephyr impact in IoT world.

In order to ease porting of STM32 devices, we'd like to introduce STM32Cube
SDK into Zephyr. Aim is to make porting fast and easy thanks to ST CSMIS
files, reduce code duplication and provide mature software with STM32Cube
adaptation layers (HAL and LL).
I'm all for allowing Zephyr to quickly add support for as much
hardware as possible and if HALs are the way to do it, then so be it.

However, I'd like to hear from Zephyr maintainers on whether this is
just a short-term strategy to get broad hardware support or the long
term goal because HALs do make for hard-to-read code[1] and each
vendor's HAL is different leading to further maintenance issues.

I ask this coming from a Linux development mindset where HALs are
actively discouraged.

About STM32Cube CMSIS files:
Proposition for now is to move progressively towards the support of
STM32Cube
on available STM32 based boards and that new boards include STM32Cube CMSIS
files from start.
Shouldn't you import all possible HALs _today_ in order to enforce
that? Otherwise it'll lead to unnecessary churn when people are doing
platform/SoC ports.

Regards,
Amit
[1] What is it with vendor code and camel-case and excessive use of
typedefs? :-)
+1 on that comment :).

Interesting topic and I will follow this with interest.

Best Regards
Mirza

Join devel@lists.zephyrproject.org to automatically receive all group messages.