Coordinating I/O with Your Device Simulator

  • 项目

Testing your driver with a device simulator typically requires initiating I/O with the device while also running actions in the simulator to satisfy those I/O requests. Test cases can be positive (where I/O is expected to complete successfully) or negative (where I/O is expected to complete with a specific error).

If your test includes multiple instances of your device, you must match an instance of your device simulator with the Plug and Play (PnP) device instance. Currently, there is no facility within DSF to positively match a simulated USB device with a given device instance ID. Alternatively, your test program can do one of the following:

  • Enumerate instances of your device (for example, by using Microsoft Windows Device Testing Framework [WDTF]), plug in a simulated device, and then re-enumerate to find the additional instance of your device.

  • Handle WM_DEVICECHANGE messages or register for device notifications by using RegisterDeviceNotification to receive notification of device arrival and wait for notification after plugging in the simulated device. For more information about WM_DEVICECHANGE and RegisterDeviceNotification, see the MSDN Library Web site.

After you have positively identified your device and can initiate I/O to it, you must ensure that the device simulator responds accordingly to the I/O requests. For example, consider the DSF USB Loopback Device Simulation, which has a single interface with one bulk IN endpoint and one bulk OUT endpoint. The Rwbulk.exe sample program (which you can find in your WDK installation in the \src\usb\bulkusb\exe folder), calls the CreateFile Microsoft Win32 API function to open the device interface that the bulkusb driver (in the \src\usb\bulkusb\sys folder) exposes, and then calls the ReadFile and WriteFile Win32 API functions to send it I/O requests. A WriteFile call causes the controller to send a data transfer to the bulk OUT endpoint. The loopback device handles this I/O event in the CLoopbackDevice::OnWriteTransfer function (in the \src\Test\DSF\USB\SoftUSBLoopback folder) by queuing the received data to the bulk IN endpoint. A subsequent ReadFile call from Rwbulk.exe causes the controller to request a data transfer from the bulk IN endpoint, which then consumes the queued data.

You can design a definitive positive test case so that the loopback device fires an event into the test application to indicate receipt of the bulk OUT transfer. The test application could call WriteFile, wait for the event that confirms receipt of the bulk OUT transfer, and then wait for the WriteFile call to complete. This process requires two threads or use of asynchronous overlapped I/O because the WriteFile call would be blocked until the I/O completed.

You can design a negative test case so that the loopback device is programmed to return a transaction error from the bulk OUT endpoint on the next transaction. You can complete this situation by adding a property to the loopback device (for example, LoopbackDevice.ErrOnNextBulkOUT = True).

The loopback device could check that property at the start of each call to CLoopbackDevice::OnWriteTransfer, and if the property is true, return USB_ERR as the transaction status and reset the property to false. After setting this property, the test application could call WriteFile and then check that it returns the corresponding error.

 

 

Send comments about this topic to Microsoft

Build date: 9/21/2010