Porting this library to other devices about libusb_stm32 HOT 14 CLOSED

You can try to use usb_stmv1 driver for F103.
Check the "usb.h" for the USE_STMV1_DRIVER variable.
It should work if F103 is equal to L1xx in

• USB peripheral and named USB registers
• RCC for USB clock and reset
• SYSCFG for USB pullup control

Anyway i will make F103 port when i get my ordered F103 board.

from libusb_stm32.

I got enumeration on F303, by removing any mention to SYSCFG from the L1xx driver. F103 and F303 have no internal DP pull up on the USB peripheral, so it is usually either controlled using an GPIO, or built on the board as a permanent pull up.

Also, F303 does not have a UID_BASE macro, so I have to #define it myself. Maybe for F103 and F303 this macro should be defined in usb.h

I will send in a pull request, naming this driver usb_stmv3. You can check if the F303 driver work as-is on your F103 board, and if so, add F103 into the supported device list for the v3 driver.

from libusb_stm32.

I think it's better to adjust V1 driver. But i'm not sure even if i want to do DP control trough GPIO.
Also i have checked the includes for F103x6 (V4.1.0) and F303x8 (V2.3.1). The UID_BASE macro is defined in both.

from libusb_stm32.

I don't want to introduce GPIO-based DP control too, knowing that for some projects there is no DP control at all... The submitted pull request for F303 completely leaves the DP control out, and it is up to the user of the library to implement their own.

I think I need to update my include files then...

from libusb_stm32.

Speaking of, where did you get those high versioned files? I could not find those in the Keil packs. Also, F303x8 does not have USB, you need to step up to F303xC or xE to use it.

from libusb_stm32.

From ST. It's a parts of the CubeMX, but it can be downloaded separately.

from libusb_stm32.

Even from my copy of Cube I am only seeing STM32F1 v1.6 and STM32F3 v1.9 libraries. Where did you get that high version of Cube? Can you provide a link?

from libusb_stm32.

Sometimes ST makes me crazy. Latest (V1.6) version contains V4.2.0 stm32f103x6.h

from libusb_stm32.

That is weird... I am going to try this on my F103 and F407 board (F407 will likely receive a fork of V2 driver.) Just to be curious, I will also try the GD32F103 chip. (GD32 is a Chinese semi-clone of STM32 line.)

from libusb_stm32.

I have pull requested the F103 patch.

The F407 would require some rework though, as it have two OTG instances (OTG_FS and OTG_HS.) It would also be better for the OTG_HS instance to support both internal FS PHY and external HS PHY. I would need to cook up a board with F405 (register compatible, smaller chip, but a lot cheaper) and bring out both OTG_FS and OTG_HS for this.

from libusb_stm32.

Thank you.
But i want to make some fixes and improvements first.

from libusb_stm32.

Some ideas I have about the improvements:

• The driver should also be made aware of the object they are being called with. This is crucial for reusing code across the two USB OTG instances on F4 and F7 series.
• Make usbd_connect() generate callbacks. This is useful when manual DP pull-up management is required (F1 and F3)

from libusb_stm32.

The core code and drivers contains no static variables and can be reused.
I think it's a bad idea to make callbacks from asynchronous control functions. It should be a macro or it should be integrated into V3 driver using something like USBD_DP_GPIO and USBD_DP_PIN defines. GPIO control for DP will be activated if both defined.

from libusb_stm32.

When I talked about code reuse means reusing code between the two instances of USB OTG peripheral for F4 and F7 chips. They have OTG_FS and OTG_HS, which may share code.

from libusb_stm32.