Re: STM32 Support Roadmap

Erwan Gouriou

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
         (spare time)
  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:
Hi Paul,

On 05/22/2017 02:04 PM, Paul Sokolovsky wrote:
> Hello Neil,
> I'm surprised to not see USB (at least device-side) support below. I'd
> think USB is a popular and generic interface to pose enough interest
> for wide array of users, and indeed, I know that there're different
> parties interested in STM32 USB support, though apparently critical
> mass is still lacking.

Yes, but since you were already working on it, I removed it from the list.

But Yes, it is important, and having a clean support here is critical.

> Besides usefulness of USB on its own, there would be following reasons
> to give priority to USB:
> 1. Intel Quark appears to be the only SoC in Zephyr with USB support.
> That means that USB support in Zephyr is in general skewed, e.g.
> recently there were patches to generic USB examples to workaround
> issues seen on just Arduino 101.

I still plan to take a look on the DW code and make it work on F4/L4...

> 2. USB support is required e.g. for Zephyr.js WebIDE:
> , which can make a cute demo
> engineers can show to managers to prove that Zephyr already can do cute
> things, to back increase of timeshare they spend working on Zephyr ;-).

Yes, it could help !


> Thanks,
> Paul
> On Mon, 22 May 2017 10:38:27 +0200
> Neil Armstrong <narmstrong@...> wrote:
>> Hi Erwann, Zephyr community,
>> I'm wondering about the next steps for the STM32 Platform support.
>> First of all, I'm still trying to push a SPI driver for STM32Lx, but
>> it seems it could work on STM32Fx platforms but it will lack the
>> clean CS management introduced in the Lx serie. I still need to
>> update it to the new SPI API.
>> I started trying to make the FMC work for PSRAM, SRAM and NOR devices
>> work, but is there a plan to support external memory-mapped devices ?
>> It's the same question for the QSPI mapped support. Some API should
>> be added to support dynamic mapping/unmapping, write protection and
>> so-on.
>> Other useful devices would be the I2C (for !Lx), ADCs, RTC, CAN and
>> integration with the DMA controller introduced earlier by Lee Jones.
>> (Since the F4x and L4x flash drivers has been merged, the F3x should
>> also be merged, but I need some testers since I do not own any F3x
>> boards...)
>> Finally, a strong point would be support for Ultra Low power modes
>> and dynamic SYSCLK switching, what is the stays of that for the
>> global Zephyr codebase ?
>> Thanks,
>> Neil

Join to automatically receive all group messages.