Zephyr on STM32F042/072/405 with USB?


Christer Weinigel
 

Hi all,

I have a bunch of STM32F042/072/405 based boards that I'm currently
running ChibiOS on. I'm thinking about porting Zephyr to these boards
and also try to add support for the USB device in them.

Before I spend a lot of time trying to do this, is anyone else working
on support for those MCUs or on the USB device? It would be kind of
silly of I someone else has already done that and I would duplicate
their work.

/Christer


Joseph, Jithu
 

Hi Christer,

We have a bunch of USB device stuff under "subsys/usb/*".

In brief we have support for the following device classes :
CDC ACM - uart over usb
Mass storage
Webusb

You can exercise them via the samples under :
"samples/usb/*"

I am poking around a bit on USB Ethernet related stuff.

Coming onto the lower layer(driver) stuff, currently our only support is for the QuarkC1000 SOC's usb device controller. You can find it under "drivers/usb/device/*". So the USB samples currently run on arduino_101 and quark_se_c1000_devboard board configurations.

The first step for the STM usb stuff would be to implement the device controller driver which expose the
include/usb/usb_device.h API . Once this is done I expect the device class implementations and samples to plug in directly.

We look forward for your contributions .

Thanks
Jithu

-----Original Message-----
From: Christer Weinigel [mailto:christer(a)weinigel.se]
Sent: Saturday, January 14, 2017 10:36 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Zephyr on STM32F042/072/405 with USB?

Hi all,

I have a bunch of STM32F042/072/405 based boards that I'm currently running
ChibiOS on. I'm thinking about porting Zephyr to these boards and also try
to add support for the USB device in them.

Before I spend a lot of time trying to do this, is anyone else working on
support for those MCUs or on the USB device? It would be kind of silly of
I someone else has already done that and I would duplicate their work.

/Christer

--
Have laptop, will travel. I'm a consultant looking for interesting jobs
anywhere in the world. I'm an experienced software engineer with a solid
understanding of hardware. Specialities: Linux, device drivers and
embedded systems in general. Find me at www.weinigel.se.


Erwan Gouriou
 

Hi Christer,

Thanks in advance for these tasks.

For USB support on STM32, it would be great that this work could benefit
to the whole STM32 family.
STM32Cube SDK could help you in implementing a single driver common to
STM32 SoCs thanks to HAL.
Should you prefer to implement a zephyr native driver, please note that
Cube SDKs
provides CMSIS defines, structures and macros that are useful for
abstracting
differences between SoC and keep genericity in your driver.

Good luck with this work
Erwan

On 15 January 2017 at 17:13, Christer Weinigel <christer(a)weinigel.se> wrote:

Hi all,

I have a bunch of STM32F042/072/405 based boards that I'm currently
running ChibiOS on. I'm thinking about porting Zephyr to these boards
and also try to add support for the USB device in them.

Before I spend a lot of time trying to do this, is anyone else working
on support for those MCUs or on the USB device? It would be kind of
silly of I someone else has already done that and I would duplicate
their work.

/Christer


Christer Weinigel
 

Hi Erwan,

well, it wasn't too hard. Almost everything is already implemented in
the STM Cube drivers and only a little bit of glue code was needed.

I've only implemented the functions needed by the cdc_acm driver so
other higher level drivers such as mass storage will probably not work.
It's not very heavily tested and might contain race conditions that will
show up under load. But it's a start.

https://gerrit.zephyrproject.org/r/#/c/10175/

Even if this driver doesn't break down under load, performance will suck
due to the way I've implemented the usb_dc_ep_read function. The upper
layers expect the usb_dc_read function to return data immediately while
the STM32 Cube HAL_PCD_EP_Receive function only starts a read and data
will not be available until HAL_PCD_DataOutStageCallback is called by
the HAL. The way I have worked around this for the moment is to have an
extra packet buffer in the usb_dc_stm driver that HAL_PCD_EP_Receive
reads into, and then when usb_dc_ep_read is called data from this buffer
is copied to higher level driver. In the case of cdc_acm driver, this
will be done 4 bytes at a time, and then the data in the cdc_acm buffer
is copied to yet another buffer one byte at a time and when data is read
from the serial buffer it's copied again.

To get decent performance out of the STM32 Cube drivers all higher level
drivers ought to split usb_dc_ep_read into a usb_dc_ep_start_read and a
usb_dc_ep_get_read_count function so that it matches what the HAL layer
does. It's a bit painful, but shouldn't be that hard.

If the higher level driver is also aware of USB packet boundaries and
alighment this could also allow DMA directly into the driver buffers for
hardware (such as the STM32F4xx) that supports it.

/Christer

On 2017-01-16 11:31, Erwan Gouriou wrote:
Hi Christer,

Thanks in advance for these tasks.

For USB support on STM32, it would be great that this work could benefit
to the whole STM32 family.
STM32Cube SDK could help you in implementing a single driver common to
STM32 SoCs thanks to HAL.
Should you prefer to implement a zephyr native driver, please note that
Cube SDKs
provides CMSIS defines, structures and macros that are useful for
abstracting
differences between SoC and keep genericity in your driver.

Good luck with this work
Erwan


On 15 January 2017 at 17:13, Christer Weinigel <christer(a)weinigel.se
<mailto:christer(a)weinigel.se>> wrote:

Hi all,

I have a bunch of STM32F042/072/405 based boards that I'm currently
running ChibiOS on. I'm thinking about porting Zephyr to these boards
and also try to add support for the USB device in them.
Before I spend a lot of time trying to do this, is anyone else working
on support for those MCUs or on the USB device? It would be kind of
silly of I someone else has already done that and I would duplicate
their work.

/Christer