libusb_stm32
libusb_stm32 copied to clipboard
dmitrystu
Porting this library to other devices, round two
This recommendation is a continuation of the issue #2 but regarding the two USB peripherals found on STM32F2, F4 and F7 families. The existing v2 driver may work for the OTG_FS peripheral, but is there any consideration about the OTG_HS, either in built-in FS PHY mode, or in external HS PHY mode?
I am considering building a STM32F405RG USB 2.0 Hi-Speed Experiment Board for this, with all three USB connections being made available (OTG_FS, OTG_HS with external PHY and OTG_HS with internal FS PHY). Are you interested?
Yes, it's interesting. The core can utilize as many USB devices as available. It don't use any static variables. As far as i know the ST's OTG_HS machine is similar to OTG_FS. But i haven't read the datasheet yet.
I have two boards with STM32F407 and '417 up respectively in OTG_FS mode. I will test port this ASAP. Also to be tested is STM32L433, likely will work with some existing driver.
Another few chips I have down the pipeline is F405 (OTG_HS, both internal FS PHY mode and external HS PHY mode, they have the same OTG_FS as F407/F417,) F411, F107 (both have only one OTG,) F722 and F756 (both chips, both OTG_FS and OTG_HS.)
@kisielk I am on it. I do hope that the F417's OTG_FS is similar enough with F413's so you can just take and use it.
@xcvista is it different from the existing v2 driver? or just a matter of adding the necessary defines?
@kisielk It is fairly different as how the VBUS detect is handled changed. A lot of stuff in enable() and connect() are throwing out errors, and I have to remove dependency from a few #define's in stm32.h since that header file plainly won't work in my build environment.
Maybe we need to come up with a better naming scheme for things, as the usb_32vx will become unmanageable soon after more parts are introduced, especially when OTG_HS are being introduced. I already have a few in the pipeline here.
I got a Nucleo-F767ZI second hand. So now I have three chips ready to test: STM32F407ZGT6 OTG_FS, STM32F417ZGT6 OTG_FS and STM32F767ZIT6 OTG_FS.
Fine. I've bought NUCLEO-F429 just before New Year and made otgfs driver. But i have no time for test and debug. I hope i'll do it at weekend.
I have an STM32F746G-DISCO I can test on, but don't have time to work on the code at the moment. If someone gives me a basic firmware I can try and help debug though.
@dmitrystu
- I will test the stm32f429-otgfs code on STM32F417, F407 and F767 as soon as you put it online. (I spent way too much time on sorting out the platform code and code generators...)
- I have a Chinese workalike of STM32F103, GD32F103CBT6, to test the stm32f103_devfs code on.
- I have a chip report: my two projects based on STM32F042 have been working stable for a while, using the stm32l052_devfs driver. I think you can list STM32F042K6T6, STM32F042F6P6 and STM32F042F4P6 as tested. (Yes I squeezed this into a 32-bit microcontroller with only 16kB Flash, implementing a USB HID using 9kB of unoptimized code. In contrast the STM32CubeMX boilerplate with maximum optimization takes 13kB.)
@kisielk I think the same F429 code would work on most F4/F7 chips, hopefully without too much modifications.
@dmitrystu I added support for the STM32F105/F107 based on the STM32F429 driver, would you accept a PR?
I also ported the bootloader.
Has anyone made progress porting this to an F7 series chip yet? Using the F429 driver and the cdc demo I've got as far as receiving a bus reset event, but nothing after that.
Cool ! I've tried to use OTG-HS with Waveshare USB3300+NUCLEO-F429ZI but failed. Perhaps i've had a problems with interconnection wires @60MHz ULPI clock.
Let me put the schematics and Gerber on here, and put up a Tindie link if you want to buy one. It is STM32F405RGT6 + USB3300 on one board, with the intention to be used as a CMSIS-DAP debugger with a USB 2.0 Hi-Speed link.
Here is my STM32F405 + USB3300 board: https://www.tindie.com/products/maxtch/stm32f405-usb-2-hi-speed-evaluation-board-dap405/