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