USB device cleanup

[bmcdonnell-ionx]

Description

Attn: @c1728p9: a little cleanup in the feature-hal-spec-usb-device branch.

• bmcdonnell-ionx@dbc60e9 - Don't #include "mbed.h" inside Mbed OS, like Add required header file and namespace element instead add all. #7864
• bmcdonnell-ionx@522da85 - Remove an apparently erroneous comment
• bmcdonnell-ionx@aee5873 - Avoid unnecessary floats

Pull request type

[ ] Fix
[X] Refactor
[ ] Target update
[ ] Functionality change
[ ] Breaking change

[bmcdonnell-ionx]

I did a test build (mbed compile -t GCC_ARM) for three devices - one using each of the currently supported targets:

• K22F
• LPC4088
• NUCLEO_F446ZE

[c1728p9]

Thanks for the enhancements @bmcdonnell-ionx

[c1728p9]

@bmcdonnell-ionx it looks like there are some build errors. If you build locally for the K64F you should get the same errors.

[bmcdonnell-ionx]

@c1728p9, OK, I think I got it.

[cmonr]

/morph build

[mbed-ci]

Build : FAILURE

Build number : 3136
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8125/

[0xc0170]

Please review the build failures (related to the changes)

[bmcdonnell-ionx]

@0xc0170, what changed? Didn't this pass the checks before?

I don't know where to begin. How do I see what's failed?

When I click on Details next to the failed "ci-morph-build", I get, "This site can’t be reached
"mbed-os.mbedcloudtesting.com took too long to respond."

When I click on "Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8125/", I get

[cmonr]

@bmcdonnell-ionx All of the failure logs are located within the FAIL directory. Looking at a random device's log, it looks like this PR doesn't pass the TESTS-USB_DEVICE-BASIC test against any target.

I'd recommend locally verifying that this PR works against that (and all other) tests.

[bmcdonnell-ionx]

I fixed some stuff and rebased. The test output is very verbose, I'm not sure what all to look for, and it looks like some things fail both locally for me with and without my changes here.

I can't see the details of the latest CI failure (site can't be reached), and I haven't seen a "Build : FAILURE" that I can look at yet, so I await further instruction.

[cmonr]

Interesting.
@ARMmbed/mbed-os-maintainers @ARMmbed/mbed-os-test This might be interesting feedback to take in.

@bmcdonnell-ionx It's a bit counter-intuitive, but the details link that the merge checks provide are internal-only. We generally point users to the log results that are sourced from AWS.

Unfortunately, it looks like these failures are in a test that I'm not use to navigating around.

@SeppoTakalo @JanneKiiskila Would y'all mind chceking why this PR failed the smoke test?

[JanneKiiskila]

Multiple failure reasons, K64F w IAR fails to this:

Building project mbed-cloud-client-example (K64F, IAR)

Scan: mbed-cloud-client-example

Scan: env

[ERROR] Feature 'BOOTLOADER' is not a supported features

[mbed] ERROR: "/usr/bin/python" returned error.

       Code: 1

       Path: "/builds/ws/mbed-os-ci-cloud-client-test-job@3/mbed-cloud-client-example"

       Command: "/usr/bin/python -u /builds/ws/mbed-os-ci-cloud-client-test-job@3/mbed-cloud-client-example/mbed-os/tools/make.py -t IAR -m K64F --source . --build ./BUILD/K64F/IAR"

       Tip: You could retry the last command with "-v" flag for verbose output

Must be some setup issue? @OPpuolitaival , @teetak01 any clues? Some issue with the mbed_app.json used?

GCC ARM has the same issue.

[0xc0170]

Based on the failures, I suspect the usb branch lacks behind (BOOTLOADER is not yet feature there) and the example that builds uses it. We might want to update the usb feature branch (@c1728p9 Please rebase)

[JanneKiiskila]

Right you are, BOOTLOADER is a 5.10 based feature and this branch is based on Mbed OS 5.9.3.
@0xc0170 - the PR guidance texts should be perhaps modified to advice people to rebase against the tip of the master?

[JanneKiiskila]

Definitely compiles once it is rebased, though the list of commits I get by doing the git pull origin master --rebase is a lot longer than just 4 commits.

I especially like the commit USB devices: avoid unnecessary floats - I never understood why we would use floats for waits in Mbed OS? Using that one float will pull in the whole floating point library, which we probably will not need for anything in quite a few embedded apps.

[cmonr]

/morph build

[mbed-ci]

Build : FAILURE

Build number : 3343
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8125/

[cmonr]

@bmcdonnell-ionx Please take a look at the build errors.

[cmonr]

Closing due to inactivity.

@bmcdonnell-ionx Feel free to reopen once an update is available.