Re: HALs in Zephyr (was Re: STM32Cube SDK in Zephyr)
I'm also interested in this topic. I posted several weeks ago on gerrit someYou're right, it doesn't follow the Zephyr coding style, which is why we are importing these headers into ext/ and not into arch/arm/. Their style is defined by the ARM Cortex Microcontroller Software Interface Standard (CMSIS), specifically the CMSIS-CORE component of the standard, and has been widely adopted by ARM Cortex-M SoC vendors.
By reusing existing CMSIS peripheral register definitions from the SoC vendors as-is, there is a lot less custom code we need to write, test, and maintain for Zephyr. By importing them into ext/, we're keeping non-conformant code imported from other sources separate from the rest of the tree; everything else is expected to follow the Zephyr coding style.
As for vendor driver SDKs that are built on top of CMSIS register definitions, we are still in a bit of a learning period. For NXP SoCs, I would like to leverage the Kinetis SDK (ksdk) drivers with shims as much as possible for the same reasons as the CMSIS peripheral register definitions - less custom code to write, test, and maintain. For ST SoCs, Erwan recently started a similar exercise with STM32Cube. We've only done this for a handful of drivers, though, so it's possible we will find issues or incompatibilities as we fan out. When that happens, we should try to address them upstream with the vendors whenever possible.
I agree that we need to publish some guidelines. I'll work on writing an ARM SoC porting guide over the next few weeks, and hope you'll be willing to provide some feedback on it when I have a draft ready.
I disagree with preemptively importing all the HALs today as that would clutter the tree with a lot of unused code. We also don't know which SoCs people will want to port to. I'll make sure to include a section about importing HALs in the above-mentioned ARM SoC porting guide.About STM32Cube CMSIS files:Shouldn't you import all possible HALs _today_ in order to enforce