-
Notifications
You must be signed in to change notification settings - Fork 75
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
How to manage testing usb-device? #100
Comments
There is also this repo for a different driver: https://github.com/Disasm/stm32-usbd-tests |
Ah, cool, thanks @Disasm . I'll open a PR to the main usb-device README.md as a start. Do you have links to boards that someone interested in testing STM32s might be able to buy? Does the USB2 test suite pass? I've not got a login handy but could have a look at that at work sometime. |
The various STM32 "Discovery" boards are high quality and include a debugger compatible with |
Following on from discussion in PRs #101 and #103 - my feeling is that the hardware specific code+documentation should not live in This thinking comes down to the scenario where that device-specific code is used: someone is trying to test a change made to some combination of Basically, it seems easier to work on Thinking ahead to CI too - if |
Ah, gotcha. In terms of embedded Rust, I'm mostly coming at this from an ATSAMD background, and in that world our typical projects are more per-board than per-MCU. So, if a person wanted to use the test firmware I made, they should have the same board, not just the same chip. That said, we have a few rough edges in this area (mainly around maintenance/examples) and I think for something like this work, it might make sense to make the usb-device test firmware only MCU-specific. The only thing that's really per-board in that firmware currently is a blinking heartbeat LED, obviously that's not critical. (Edit to add: I believe the ATSAMD examples currently use an on-board oscillator, so a second dependency on the board, but the MCUs can behave as a USB device without an external oscillator) |
I can get onboard with keeping hardware-specifics out - I had an MQTT project where HITL code was checked it, and it was in disrepair incredibly quickly. Is there any USB test-class code that we need to have in |
Yep, this file is used by the firmwares mentioned in the first couple comments of this thread. I don't have strong opinions on where it lives within |
I'll pursue merging the ATSAMD Beyond the location of the pieces of test code - how much testing should we require of PRs? For example, I started this issue in the context of #60 so will shamelessly refer to that :). Is the test coverage there sufficient? Is it necessary? Does someone with a particular role in this project need to confirm the tests pass, since they currently need to be manually run? |
Some parts of While initially intended for testing Classes, it turned out that it also can test This works by having a (very crude) software UsbBus implementation which provides methods to send and receive data from the endpoints, and a test case has access to both the Class and the emulated UsbBus with |
For this PR I've thrown together a firmware and minimal documentation to use this crate's
TestClass
. @Disasm has an implementation for a different micro here.I wonder if we should associate test firmware sources with this project somehow? It's not clear to me whether that should look more like a link in usb-device documentation, checking test firmware sources in to usb-device, or putting the test firmwares with HALs that implement usb-device support. Any thoughts?
For me, this was a bit of a mission (partly down to flaky SWD, it seems), and I think it would be good to reduce friction around testing as much as practical.
The text was updated successfully, but these errors were encountered: