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.
