Re: STM32 Support Roadmap
toggle quoted messageShow quoted text
Hi Neil, all,
I can only acknowledge that, despite hard work from community, we still currently miss important drivers
on STM32 SoCs.
On ST side, roadmap was to port Disco L475 IoT board, and after adding sensors support, and use it as
a support for development, to enable wider driver support, such as connectivity (BT, WIFI, NFC, ...) and
other basic drivers.
On the quite short term, I'd like to complete transition of clock-control to full LL support (F1 family
remains). Then migrate UART driver from HAL to lightweight LL API (following new API promoted by
Then, there are some active members of the community working on drivers. As mentioned by Daniel,
this is not part of a roadmap. Anyway, here is the summary of on-going, or recently merged, driver
works you should be aware of (sorry if I'm forgetting someone):
SPI: Jorge from Linaro is currently working on a STM32Cube LL API based driver in order to enable
SPI support on all STM32 series available on Zephyr.
I2C: Mani kindly contacted me to propose his help and is now working on a LL based I2C as well (spare
USB: Daniel also proposed to liven up work initiated by Chister Weinigel on a Cube HAL USB driver
MPU: Support recently provided by Vincenzo
Flash: Generic F4/L4 driver based on Linaro F4 driver committed last week by Neil
Other works I'm aware of (once again, apologizes if I forgot someone)
Bootloader: Taken in charge by David via mcuboot work
FOTA: Linaro 96boards team is working on via Carbon board.
Then, I know some other people, like Florent or Adam have helped on providing board support and drivers,
but I don't know their current plan.
I'd like to add a quick message on ST strategy about STM32Cube:
In order to fasten the complete the support of driver support on STM32 family, we'd like to promote the
use of CMSIS and STM32Cube Low-Layer APIs API. I know that some of you could be
reluctant to the use of HAL. Though, interest we see is the ability to maximise code re-use and minimize
maintenance effort so that one a driver is available on a series, it could be reused with minimum effort
(only testing and minor adjustments ideally) on other series. Hence, we promote the use of:
1. LL API being light weight/modular, we think it is well fitted to Zephyr code base and should help
development on most of the drivers
2. HAL API is a more complete/full feature API, but we think it could be useful on drivers requiring a big
amount of development and testing effort (such as USB, Ethernet). Indeed, on this driver, we thing the
extraload brought by HAL is reduced vs a native driver and could be compensated by its maturity and
hence gain in validation. Hence it could allow to get quick support for rich features on whole STM32
I hope this could help member of zephyr community working on different STM32 series to contribute to
and take benefit from a complete STM32 generic driver support.
In the end, we welcome all efforts made on STM32 support.
On 22 May 2017 at 14:40, Neil Armstrong <narmstrong@...> wrote: