libopencm3
libopencm3 copied to clipboard
libopencm3
st_usbfs: Double buffering for isochronous endpoints
As always, please add some way of testing this. I realise isochronous wasn't supported before, but this must have regression tests added.
Please use the existing gadget zero style, or something similar that can be tested, so we can track regressions in paths that were outside your own scope. I am straight up not merging usb changes that don't include tests.... (someone else might)
Yes, regression tests would be nice. My whole motivation for this is to make test devices that we can use for regression testing in libusb (and pyusb). I will look at the gadget-zero stuff.
Would you prefer fixup commits or repushing?
I'll probably not get to this for a while. My plan is to rebase the commits based on feedback, and I am also awaiting answers on my questions above. The major remaining work is to construct the tests, if you or anyone can help on that it would speed up things.
UPD: I confirm that this does work for stm32f103 chip, where the st_usbfs_v1_usb_driver is used.
But, this does not work for the stm32f401 chip where the other stm32f107_usb_driver USB driver is used... sadly..
fixup or squishes make no difference to me right now, we can handle that when we're happy with it. I'm not sure what else this is waiting for me on, it must have tests before I'll merge it, as I've tried saying, and will say again and again and again I believe :)
To be honest, I have not ideas how to test it at all.
F.e. I faced with the interesting situation (using the DWC OTG FS && STM32F4x) when the libopencm3 also does not support the isochronous stream, but the stream is transferred somehow.
I have created the FW which implements the fake USB microphone which produces a sine wave.
When I record the audio stream using any external software (e.g. Audacity or any other), then I got a correct data (a pure sine wave).
But, when I try to listen the microphone stream directly (e.g. to forward the stream to the speaker, that is possible in Windows as "out in box"), then I hear the sound distortion (pulsation).
So, I meant, that it is impossible to detect that a stream is corrupted using auto-tests, because it receives correctly (hello Audacty). ;)
You should absoltuely be able to use something akin to the gadget zero source/sink endpoints to have it programmatically generate expected sequences, and use pyusb to programmatically read them. If you can hear distortion, you are most definitely not getting the expected data!
I cannot do regression tests on things that require listening for distortion in audio capture, that's simply untenable. I completely believe that this fixes things for you, no doubt, my concern is next year....