Using Yoctopuce modules in WSL

We recently had the opportunity to install the latest version of WSL (Windows Subsystem for Linux) on a Windows development machine, so that we could run test procedures designed to run under Linux. As it works quite well, we figured we wouldn't be the only ones to do so, and that it would be a good idea to document the use of Yoctopuce modules in this environment.



The integration of Linux into WSL is so transparent in some aspects (integration of the Linux shell into command windows, mixing of Linux and Windows windows, and so on) that it's easy to forget that it's actually an integration by virtualization: when you launch the first shell, a whole virtual machine with a Linux system is launched for you, although Windows only shows you a small part of it. And since Linux programs run in this virtual machine, they don't have direct access to USB peripherals.

So if you want to use Yoctopuce modules from within a WSL process, you need to set up a mechanism that allows Windows to share devices with the Linux virtual machine. There are two solutions for this: Yoctopuce's plug-and-play solution, VirtualHub, and a generic (but less plug-and-play) solution offered by Microsoft, based on the USB/IP solution and the open source software usbipd-win.

Solution 1: VirtualHub

VirtualHub is a software package made available by Yoctopuce for testing and configuring Yoctopuce modules, which can also provide access to USB modules via an IP network, and share access to USB modules between several applications. It can therefore quite naturally be used to share access to USB modules with Linux programs running in WSL.

To do this

1. Install VirtualHub under Windows. You can choose to run it automatically as a service to ensure that it is always available.
2. To access modules from a Windows program, use the IP address 127.0.0.1. For example, in your program, initialize the Yoctopuce library with the call:
   
   YAPI.RegisterHost("127.0.0.1")

   
   or if you're using the command line library:
   

   YModule -r 127.0.0.1 inventory

3. To access modules from a Linux program, use the Windows virtual IP address, dynamically allocated by WSL. You can find it with the following bash command:
   
   ip route show default

   
   As a rule, it will look something like 172.25.128.1. In your Linux program, initialize the Yoctopuce library with the call:
   

   YAPI.RegisterHost("172.25.128.1")

To avoid having to search for this IP address at each startup (it may change), you can add the following line to the ~/.bashrc file:

After restarting bash, if you have installed the Yoctopuce command line library, you can use:

Warning: if you ask ChatGPT, it may advise you to use the IP address in /etc/resolv.conf. Do not follow this advice, as it will not work if your WSL is configured in NAT mode.

Solution 2: USB/IP

The USB/IP solution is made up of two components: a Linux driver capable of conjuring up virtual USB devices, and a usbipd program that provides this driver with exclusive remote access to selected USB devices on the host where usbipd is run. This is the solution documented on Microsoft site as the official method sharing USB devices with WSL, but it's actually an open source project maintained by developers outside Microsoft.

The USB/IP solution requires you to explicitly specify which USB device is to be captured on the Windows machine and attached to the Linux virtual machine. You can do this with the usbipd command-line tool. The easiest way to install and use this tool is to use a Windows PowerShell window with administrator rights. Follow the steps below:

1. Install the usbipd-win tool with the following command:
   winget install --exact dorssel.usbipd-win

2. Connect to your machine the Yoctopuce module you wish to transfer to Linux.
3. List the USB modules detected by Windows using the following command:
   usbipd list

   
   The list should look something like this:
   

   BUSID  VID:PID    DEVICE                            STATE
   1-9    06cb:00bd  Synaptics UWP WBDI                Not shared
   1-10   056a:51a0  Wacom Device                      Not shared
   1-14   8087:0029  Intel(R) Wireless Bluetooth(R)    Not shared
   17-3   1e7d:2de6  USB Input Device                  Not shared
   17-4   046d:c349  USB Input Device                  Not shared
   20-1   058f:8468  USB Mass Storage Device           Not shared
   26-1   24e0:00c7  USB Input Device                  Not shared

4. Find the Yoctopuce module in the list: it's the one for which the VID:PID value starts with 24e0, which is Yoctopuce's VendorID. Note its BUSID, in this case 26-1.
5. To share this device and attach it to WSL, use the following commands:
   usbipd bind -b 26-1
   usbipd attach -w -b 26-1

6. Under Linux, you should then be able to access the module. Be sure to read our introduction to using Yoctopuce modules under Linux if you're not familiar with using USB under Linux, as it's not as trivial as under Windows.

This is where things get a little complicated with USB/IP. If for any reason the USB device disconnects, even temporarily for a firmware update for example, it will not automatically re-attach to Linux. The usbipd system has memorized the bind command for this module on this particular USB socket, but not the attachment to WSL. And if you plug the same module into another USB socket, it won't even be binded to usbipd. So it's a fairly partial solution.

To improve the situation, we recommend using automatic bind and attach. Still in a Windows Powershell window with administrator rights, run the following commands:

This last command doesn't give back control: it remains active and monitors the USB socket to automatically attach any detected device to the Linux system under WSL. Similarly, the policy add command automatically binds any device connected to this USB socket. The combination of these two commands is therefore literally equivalent to allocating a USB socket to the Linux system, which is a more comprehensible behavior than the basic solution provided by USB/IP. But be aware that if you close the PowerShell, the automatic attachment disappears...

In any case, whether after a manual or automatic bind, when you no longer need to share your USB devices with Linux, take care to deactivate all bindings made by usbipd, otherwise you risk ending up with Yoctopuce modules that no longer appear under Windows. In a Windows Powershell window with administrator rights, run the following commands:

This will restore visibility of all USB modules for Windows.

Which approach to choose?

If you have a choice between the two approaches, the VirtualHub solution is clearly simpler to set up and supports dynamic connection/disconnection of USB modules much more easily. We therefore recommend it.

However, if you need to test the native USB access code under Linux, or if you don't have access to the program's source code and it only supports connection via USB, you'll have to use usbipd. This is clearly less practical, but if you take the option of a USB socket dedicated to your Linux and make a shortcut to an automatic PowerShell script that runs the bind andattach commands, it's perfectly usable.

If you're using USB/IP, even if only for a few tests, don't forget to run the three commands above to deactivate all bindings. If you don't do this, you're likely to end up with USB devices that no longer appear in Windows or are unresponsive.