-
Notifications
You must be signed in to change notification settings - Fork 3k
Fixed STM32 USB Device support for mbed Classic #4248
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…rs to unsupported features where they belong until USB support is officially introduced in mbed OS 5
Steps to reproduce:
|
Hello @screamerbg
With your PR we must update the USB library each time we want to add USB support on a new platform. Our way of locating files was avoiding this dependency. cc @jamike |
@adustm We are currently in a process of consolidating the differences of the USB Device on mbed.org and here in mbed-os on Github, after which we will start mirroring the mbed-os/unsupported/USBDevice to USBDevice on mbed.org and provide a way for regular updates of USBDevice. Currently the STM32 USBDevice files are in mbed-os/targets/, which is not backwards compatible with the USBDevice library on mbed.org as it exists today, where all USBDevice support files live under mbed-os/features/unsupported/USBDevice, not under mbed-os/targets. You may have also noticed that all USBDevice related PRs that were accepted in the past month are targeting mbed OS 5.0 (https://github.com/ARMmbed/mbed-os/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Aclosed%20usb see release-version tag), which means the current STM32 USBDevice implementation/files won't be officially released before mbed OS 5.5 is out (and mbed library respectively). Stitching all of the paragraphs above means that once we start the process of mirroring mbed-os/unsupported/USBDevice to mbed.org, and without this PR, then all ST platforms will end up with the current USBDevice support files under mbed-os/unsupported/USBDevice, but without the mbed-os/targets/ support files which will be landing in mbed OS 5 (see paragraph above), and therefore break the USBDevice support for STM32 targets. Note that once USBDevice is officially introduced in mbed OS 5, then:
|
Couldn't have said it better myself! Thanks @screamerbg |
Hello @screamerbg @sg- If the mirroring is in place, then we don't mind having STM32 files inside the feature directory. You can go for this PR. Kind regards |
@screamerbg The only thing that's making me a bit nervous about this change is that we have significantly increased the path lengths for these files and whether that may cause issues with the compiler (specifically on windows...). Have you tried compiling a test app with these changes just to check ? |
/morph test |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
OutputAll builds and test passed! |
@adbridge Good point! Here is a snippet of all files in the tree sorted by length (longest are last):
In other words, there are files with longer filepath under UVISOR and nanostack |
@screamerbg Thanks for checking , ok LGTM |
@adbridge someone at ARM should take the action of reducing directory names. It's been several times that we are mentioning the issue. Don't you agree (with the idea or with the fact that it should be done by Arm people or anything else.... ?) ? |
This is an option but its very disruptive for ongoing work. I'd suggest its done just before a release branch is created. |
Description
Fixed STM32 USB Device support for mbed 2 USB (backwards compatibility) by migrating all specific target headers to unsupported features where they belong until USB support is officially introduced in mbed OS 5
Status
READY
Migrations
NO
Note that without this PR the latest USB support for STM32 cannot be applied to the mbed Developer Site USBDevice library.
@adustm @bcostm @jeromecoutant @adbridge
CC @sg-