Date
1 - 4 of 4
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,
toggle quoted messageShow quoted text
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-----
|
|
|
|
Erwan Gouriou
Hi Christer,
toggle quoted messageShow quoted text
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,
|
|
|
|
Christer Weinigel
Hi Erwan,
toggle quoted messageShow quoted text
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, Before I spend a lot of time trying to do this, is anyone else working
|
|
|