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
pyusb test suite #235
Comments
The most common problems with using this library seem to mostly be hardware or environment/OS issues, which are pretty hard to catch with automated tests. I could see some utility in writing tests that exercise the API, but those are most effective when they're written before or during development and pyusb is fairly inactive/stable at this point. They could help detect regressions though. Did you have example test cases in mind? |
I was mostly looking for smoke test type tests, in order to validate that the openSUSE package is working correctly. We need to validate that it is compatible with Python 3.7. Also need to check it works with the system dsos, and some integration problem hasnt occurred. |
Well, I totally forgot that there are actually are tests, they just don't run in a CI environment. It seems to me after a quick glance that most of the tests depend on some kind of hardware device to be present (see I think @SimplicityGuy is the person with the keys to the repo and would be the person to talk to about getting tests running automatically if it makes sense to try and do so. Unfortunately the original author appears to be unable to contribute to the project these days, so this will probably take quite a bit of effort. |
Wow, I dont know how I missed that. A good way to get more visibility for the tests is to include them in the sdist, and add a note about that at the top of the changelog. That should get some distros attempting to run them, reporting problems, etc and hopefully providing patches. I'll see if I can get some of them working. |
I have the utils and find components tested at https://build.opensuse.org/package/show/home:jayvdb:branches:devel:languages:python/python-usb. I'll tidy it up a bit and submit it. The rest does require a device, and I couldnt quickly see how to emulate that. Some interesting projects doing that in https://github.com/search?l=Python&q=usbip&type=Repositories , and https://github.com/smulikHakipod/USB-Emulation/blob/master/USBIP.py Very likely more of the codebase can be tested using some https://github.com/vpelletier/python-libusb1/blob/master/usb1/testUSB1.py has some example tests which get a bit deeper into the codebase, and they have logic to skip certain tests when there is no device to test. |
I found |
The test is for a Microchip FW based device, but you can use other device and adapt the test codes. |
FW codes are here. It is based on the FW codes written by Travis, the author of libusbK. |
I definitively need to build/get a test device for myself... could you suggest a device and setup that's easy to configure for this? |
Any Arm Cortex M0/M3/M4 device should be good if you want to port to the more popular MCU platform. If you want to use PIC, then I think the following board is low cost and very powerful. |
I myself use an old PIC18F87J50 USB PIM. I also have Explorer 16 with PIC32 and USB Pictail board. But I have not touched it for a while. |
For STM32, I think this is a good start. Travis has created a WinUSB demo here. You can get it work on cheap STM32 discovery boards or Nucleo boards. |
Thanks @mcuee , I'll look into these. |
FWIW, I have the same issue with PyFtdi: how to run CI, for example with GitHub Actions... I looked at various HW solutions: STM32, MSP430, even small FPGAs. The problem here is that it requires a LOT of work to make a configurable remote device to simulate and/or catch errors, and be versatile enough to be reconfigured for each kind of tests. It would be definitely great, but it is nearly the same work effort than the project I want to test... I have not enough spare time to deal with both. For now, I kept this idea in mind as it would definitely be a interesting solution. Moreover to test PyUSB you would need a HS capable device to validate real use cases, which brings its own challenges. Another issue is that it reduces the count of people that can run the tests, as they need the test HW, and the tools to program it. It is not something you can download and easily get up and running whenever you want to troubleshoot an issue, unfortunately. I ended up writing a virtual backend so that it is possible to describe virtual USB devices using simple Yaml config files and test several APIs. Obviously, it is not possible to test everything this way, but it gives much more confidence in the changes as it enables to catch many errors nonetheless. This virtual backend is added on demand to the list of PyUSB backend candidates. This means that it is not possible to exercise the code of the existing backends, only the core and util modules of PyUSB - but I guess a similar solution could be implemented to test a backend by faking Yaml files describe the USB device hierarchy (device, configurations, interfaces, endpoints) and support multiple devices. The virtual backend then handles the control and bulk requests. Vendor calls are redirected to the second emulation level which handles the FTDI HW API, so it can emulate the HW behavior. At this point the test code may access this virtual HW to check what’s going on and handle the virtualized IOs. It’s still a work in progress but I already found several issues that have been silently hiding in PyFtdi for years, and I’ve been able to develop new features and test them first with the virtual HW then check how it behaves with the real one. The most challenging part will be to simulate the real time behavior of an actual HW. A similar solution might be useful for PyUSB, at least to check some parts of its base code. I’m interested in whatever solution is implemented to test PyUSB (HW, virtual, any other idea) as I think I have the same needs. HTH, |
For Linux, look at gadget driver. |
https://raspberrypi.stackexchange.com/questions/71613/how-to-use-raspberry-pi-3-as-a-usb-gadget Take note the following from the above answer: |
The above link to an example on RASPBERRY PI ZERO. |
@jonasmalacofilho The following is of particular interests as it supports isoc transfer and bulk transfer.
But you can start with the loopback first as it is simpler (only bulk transfer). |
It looks like https://github.com/eblot/pyftdi/blob/master/pyftdi/tests/mockusb.py is what @eblot was referring to. |
👍 |
As mentioned in #373, I can rebuild the test FW by Wander under Windows 10. Legacy Microchip MCU SW tools used:
HW used: PIC18F87J50 USB PIM But you can use other HW tools mentioned here as well, for example, you can use PICkit 2. There are quite some cheap PICkit 2 clones online. It should be possible to port the FW to new MPLAB X IDE and XC8/XC16/XC32 based compilers and new USB PIC based boards. On the other hand, I understand USB PICs are not that popular. I think it is probably not that difficult to port this to USB ARM based MCUs. |
Just dig out my Orange Pi Zero board and it seems to me OTG is working as I can see g_serial driver is working (I can log in to the system using serial connection from my Mac Mini M1 using Cool Term). I will need to know how to get the SourceSink loopback gadget to work (usb_f_ss_lb.ko), modprobe seems to work but I can not see the device from the host side. OrangePi Zero But Raspberry Pi Zero should be easier. |
First progress. From orange pi zero (the first two commands are just to play safe).
From macOS (you can use Linux as well).
|
Now someone needs to port the following tool to libusb and pyusb. Device side (Orange Pi Zero)
Host side (Raspberry Pi 400)
|
For people who want to try SuperSpeed USB, then the following Cypress kit may be a good value buy at US$49 (ARM9 CPU Core with 512KB RAM). |
Some interesting articles: you can use simple scripts to create USB Gadgets
|
I just got the Cypress 3 demo board and it is very good. I just mock up a quick pyusb codes from the example here (make it to be usable with Python3)
And here is the test results under Windows 10 and libusb-0.1 backend (with libusbk driver) using the Cypress default bulk loopback firmware ( cyfxbulklpautoenum.img).
|
And here is the test results under Windows 10 and libusb-0.1 backend (with libusbk.sys driver and libusb-0.1.dll from libusb-win32 project) using the Cypress default bulk source sink firmware ( cyfxbulksrcsink.img). Quick mod of pyusb codes
|
Using libusb-1.0.24 release and WinUSB driver, I got a bit worse result than the above but still very decent.
|
Native libusbk Windows API is very fast (similar to Cypress Cyusb API under Windows), it can nearly reach 5Gbps (max speed for Cypress FX3).
|
Maybe this is the way to go as it is more generic and not depending on hardware. Hardware specific things can be added as examples if needed. |
For those who wat to look at using python for creating Linux USB gadgets using functionfs, you can look at this: vpelletier/python-functionfs#20 Other ways:
|
With dummy_hcd, I think python-functionfs can be a powerful tool to create test device on Linux machine (even without the dedicated usb device controller) as dummy_hcd is emulated and you can use your normal Linux PC. Ref: https://www.collabora.com/news-and-blog/blog/2019/06/24/using-dummy-hcd/ |
Is there no test suite for this package?
Seems strange not to have one as the project has been around so long.
The text was updated successfully, but these errors were encountered: