Device Simulator for USB
in [Device Drivers]
|
Prev: already has a body
Next: problem in using ksevent
From: goldrake on 23 Jan 2007 11:40 I implemented a SoftUSBDevice as a COM client. It's part of an application. This "dialog box" device is self pluggable (plug/unplug) button. Communication is implemented by ISoftUSBEndpointEvents. A CSink class manages a single endpoint, vector<CSink*> collects all the endpoints' references for startup/cleanup purposes. The system is: Dev simulator <-> kmdf driver <-> Test App Up until now, the system worked correctly. I tested ReadFiles (... passed) and DeviceIoControls that provide data to the device (InBuffer). In this case the device receives the data carried by InBuffer. (... passed) On the other hand, DeviceIoControls which require the device to send data back (OutBuffer) have some issue. The DeviceIoControl doesn't fail but it always reports 0 bytes received. Useless to say that the buffer is not filled. I filter the vendor request issued by the driver in the EP0's OnDeviceRequest callback (Simulator). At this point i'm required to CoTaskMemAlloc the buffer that holds the data to be returned. the following should let me enqueue the data: *ppbResponseData = (BYTE *)pbData; *pcbResponseData = 4; *pbSetupStatus = USB_ACK; *RequestHandle = 45; // for testing OnDeviceRequestComplete OnDeviceRequestComplete is also fired and handles me back 45. Not much to do here just a test and let *pbFinalRequestStatus = USB_ACK again. ************************* * So the transaction is complete * but my DeviceIoControl * never sees any data !!! ************************* I also hooked the OnSetupTransfer event. It seems to give me the right request "C0 B0 00 00 00 00 04 00". ( This should be fired before OnDeviceRequest is fired. But i notice that - if i hook OnSetupTransfer - let *pbStatus = USB_ACK; - and return S_OK; the driver and the app hang until i unplug the device and OnDeviceRequest is not called ) There are not many details about it in the doc and if you GoogleFor("ISoftUSBDevice") you would be feeling luckier than me if you could find more than three links. Any clue?
From: goldrake on 25 Jan 2007 10:06 Well, i installed a "USB Monitor". I could see that the "response" data packet sent by the device really comes out. So i programmed the SoftDevice correctly. I'll turn my attention to the driver and to WdfUsbTargetDeviceSendControlTransferSynchronously (sorry for the "short" name :) whose BytesTranferred parameter reports 0 "goldrake" <pl(a)net.earth> wrote in message news:45b639a5$0$22125$4fafbaef(a)reader3.news.tin.it... > I implemented a SoftUSBDevice as a COM client. It's > part of an application. This "dialog box" device is self > pluggable (plug/unplug) button. Communication is > implemented by ISoftUSBEndpointEvents. A CSink class > manages a single endpoint, vector<CSink*> collects all > the endpoints' references for startup/cleanup purposes. > > The system is: > > Dev simulator <-> kmdf driver <-> Test App > > Up until now, the system worked correctly. I tested > ReadFiles (... passed) and DeviceIoControls that > provide data to the device (InBuffer). In this case > the device receives the data carried by InBuffer. > (... passed) > > On the other hand, DeviceIoControls which require the > device to send data back (OutBuffer) have some issue. > The DeviceIoControl doesn't fail but it always reports > 0 bytes received. Useless to say that the buffer is not > filled. > > I filter the vendor request issued by the driver in > the EP0's OnDeviceRequest callback (Simulator). At > this point i'm required to CoTaskMemAlloc the buffer > that holds the data to be returned. > > the following should let me enqueue the data: > > *ppbResponseData = (BYTE *)pbData; > *pcbResponseData = 4; > *pbSetupStatus = USB_ACK; > *RequestHandle = 45; // for testing OnDeviceRequestComplete > > OnDeviceRequestComplete is also fired and handles me back 45. > Not much to do here just a test and let > *pbFinalRequestStatus = USB_ACK again. > > ************************* > * So the transaction is complete > * but my DeviceIoControl > * never sees any data !!! > ************************* > > I also hooked the OnSetupTransfer event. It seems to give > me the right request "C0 B0 00 00 00 00 04 00". > > ( This should be fired before OnDeviceRequest > is fired. But i notice that > > - if i hook OnSetupTransfer > - let *pbStatus = USB_ACK; > - and return S_OK; > > the driver and the app hang until i unplug the device > and OnDeviceRequest is not called ) > > There are not many details about it in the doc and > if you GoogleFor("ISoftUSBDevice") you would be feeling > luckier than me if you could find more than three links. > > Any clue? > > >
From: goldrake on 27 Jan 2007 13:20 Got it. The local variable bytesTranferred (initialized to "0") was actually shaded by a variable with the same name that i inadvertely also declared inside a "case" block. When WdfRequestCompleteWithInformation(..., ..., bytesTranferred ); was called (after the switch) it always passed zero to the I/O manager so that zero bytes were copied from SystemBuffer. "goldrake" <pl(a)net.earth> wrote in message news:45b8c68e$0$30029$4fafbaef(a)reader4.news.tin.it... > Well, i installed a "USB Monitor". I could see that > the "response" data packet sent by the device really > comes out. So i programmed the SoftDevice correctly. > > I'll turn my attention to the driver and to > WdfUsbTargetDeviceSendControlTransferSynchronously > (sorry for the "short" name :) whose BytesTranferred > parameter reports 0 > > > "goldrake" <pl(a)net.earth> wrote in message > news:45b639a5$0$22125$4fafbaef(a)reader3.news.tin.it... > > I implemented a SoftUSBDevice as a COM client. It's > > part of an application. This "dialog box" device is self > > pluggable (plug/unplug) button. Communication is > > implemented by ISoftUSBEndpointEvents. A CSink class > > manages a single endpoint, vector<CSink*> collects all > > the endpoints' references for startup/cleanup purposes. > > > > The system is: > > > > Dev simulator <-> kmdf driver <-> Test App > > > > Up until now, the system worked correctly. I tested > > ReadFiles (... passed) and DeviceIoControls that > > provide data to the device (InBuffer). In this case > > the device receives the data carried by InBuffer. > > (... passed) > > > > On the other hand, DeviceIoControls which require the > > device to send data back (OutBuffer) have some issue. > > The DeviceIoControl doesn't fail but it always reports > > 0 bytes received. Useless to say that the buffer is not > > filled. > > > > I filter the vendor request issued by the driver in > > the EP0's OnDeviceRequest callback (Simulator). At > > this point i'm required to CoTaskMemAlloc the buffer > > that holds the data to be returned. > > > > the following should let me enqueue the data: > > > > *ppbResponseData = (BYTE *)pbData; > > *pcbResponseData = 4; > > *pbSetupStatus = USB_ACK; > > *RequestHandle = 45; // for testing OnDeviceRequestComplete > > > > OnDeviceRequestComplete is also fired and handles me back 45. > > Not much to do here just a test and let > > *pbFinalRequestStatus = USB_ACK again. > > > > ************************* > > * So the transaction is complete > > * but my DeviceIoControl > > * never sees any data !!! > > ************************* > > > > I also hooked the OnSetupTransfer event. It seems to give > > me the right request "C0 B0 00 00 00 00 04 00". > > > > ( This should be fired before OnDeviceRequest > > is fired. But i notice that > > > > - if i hook OnSetupTransfer > > - let *pbStatus = USB_ACK; > > - and return S_OK; > > > > the driver and the app hang until i unplug the device > > and OnDeviceRequest is not called ) > > > > There are not many details about it in the doc and > > if you GoogleFor("ISoftUSBDevice") you would be feeling > > luckier than me if you could find more than three links. > > > > Any clue? > > > > > > > >
From: goldrake on 27 Jan 2007 17:48 (... passed) "goldrake" <pl(a)net.earth> wrote in message news:45bb96fd$0$33375$4fafbaef(a)reader4.news.tin.it... > Got it. The local variable bytesTranferred (initialized to > "0") was actually shaded by a variable with the same > name that i inadvertely also declared inside a "case" block. > When WdfRequestCompleteWithInformation(..., ..., > bytesTranferred ); was called (after the switch) it always > passed zero to the I/O manager so that zero bytes were > copied from SystemBuffer. > > "goldrake" <pl(a)net.earth> wrote in message > news:45b8c68e$0$30029$4fafbaef(a)reader4.news.tin.it... > > Well, i installed a "USB Monitor". I could see that > > the "response" data packet sent by the device really > > comes out. So i programmed the SoftDevice correctly. > > > > I'll turn my attention to the driver and to > > WdfUsbTargetDeviceSendControlTransferSynchronously > > (sorry for the "short" name :) whose BytesTranferred > > parameter reports 0 > > > > > > "goldrake" <pl(a)net.earth> wrote in message > > news:45b639a5$0$22125$4fafbaef(a)reader3.news.tin.it... > > > I implemented a SoftUSBDevice as a COM client. It's > > > part of an application. This "dialog box" device is self > > > pluggable (plug/unplug) button. Communication is > > > implemented by ISoftUSBEndpointEvents. A CSink class > > > manages a single endpoint, vector<CSink*> collects all > > > the endpoints' references for startup/cleanup purposes. > > > > > > The system is: > > > > > > Dev simulator <-> kmdf driver <-> Test App > > > > > > Up until now, the system worked correctly. I tested > > > ReadFiles (... passed) and DeviceIoControls that > > > provide data to the device (InBuffer). In this case > > > the device receives the data carried by InBuffer. > > > (... passed) > > > > > > On the other hand, DeviceIoControls which require the > > > device to send data back (OutBuffer) have some issue. > > > The DeviceIoControl doesn't fail but it always reports > > > 0 bytes received. Useless to say that the buffer is not > > > filled. > > > > > > I filter the vendor request issued by the driver in > > > the EP0's OnDeviceRequest callback (Simulator). At > > > this point i'm required to CoTaskMemAlloc the buffer > > > that holds the data to be returned. > > > > > > the following should let me enqueue the data: > > > > > > *ppbResponseData = (BYTE *)pbData; > > > *pcbResponseData = 4; > > > *pbSetupStatus = USB_ACK; > > > *RequestHandle = 45; // for testing OnDeviceRequestComplete > > > > > > OnDeviceRequestComplete is also fired and handles me back 45. > > > Not much to do here just a test and let > > > *pbFinalRequestStatus = USB_ACK again. > > > > > > ************************* > > > * So the transaction is complete > > > * but my DeviceIoControl > > > * never sees any data !!! > > > ************************* > > > > > > I also hooked the OnSetupTransfer event. It seems to give > > > me the right request "C0 B0 00 00 00 00 04 00". > > > > > > ( This should be fired before OnDeviceRequest > > > is fired. But i notice that > > > > > > - if i hook OnSetupTransfer > > > - let *pbStatus = USB_ACK; > > > - and return S_OK; > > > > > > the driver and the app hang until i unplug the device > > > and OnDeviceRequest is not called ) > > > > > > There are not many details about it in the doc and > > > if you GoogleFor("ISoftUSBDevice") you would be feeling > > > luckier than me if you could find more than three links. > > > > > > Any clue? > > > > > > > > > > > > > > >
From: stefanes on 22 Feb 2007 08:37
Hi! I'm trying to get a simulated USB device to work using a MFC application, with no luck... I have a simulated USB device in a COM dll, and I want to "plug it in" using my MFC application. What a do have is a working modified VBScript from the SoftUSBAudio sample (Test2.0HubWithAudio.wsf), but I don't want to do this using a VBScript... I've tried all different approaches, with no luck. The solution I would like to use is something like this; #import "progid:SOFTUSB.SoftUSBDevice" no_namespace, no_auto_exclude #import "progid:SoftEHCI.SoftEHCI" no_namespace #import "progid:MyDevice.MyDevice" no_namespace ... ISoftEHCI *m_piEHCI; HRESULT hr = ::CoCreateInstance(CLSID_SoftEHCI, NULL, CLSCTX_INPROC_SERVER, __uuidof(ISoftEHCI), reinterpret_cast<void**>(&m_piEHCI)); ... Best regards, Stefan "goldrake" wrote: > I implemented a SoftUSBDevice as a COM client. It's > part of an application. This "dialog box" device is self > pluggable (plug/unplug) button. Communication is > implemented by ISoftUSBEndpointEvents. A CSink class > manages a single endpoint, vector<CSink*> collects all > the endpoints' references for startup/cleanup purposes. > > The system is: > > Dev simulator <-> kmdf driver <-> Test App > > Up until now, the system worked correctly. I tested > ReadFiles (... passed) and DeviceIoControls that > provide data to the device (InBuffer). In this case > the device receives the data carried by InBuffer. > (... passed) > > On the other hand, DeviceIoControls which require the > device to send data back (OutBuffer) have some issue. > The DeviceIoControl doesn't fail but it always reports > 0 bytes received. Useless to say that the buffer is not > filled. > > I filter the vendor request issued by the driver in > the EP0's OnDeviceRequest callback (Simulator). At > this point i'm required to CoTaskMemAlloc the buffer > that holds the data to be returned. > > the following should let me enqueue the data: > > *ppbResponseData = (BYTE *)pbData; > *pcbResponseData = 4; > *pbSetupStatus = USB_ACK; > *RequestHandle = 45; // for testing OnDeviceRequestComplete > > OnDeviceRequestComplete is also fired and handles me back 45. > Not much to do here just a test and let > *pbFinalRequestStatus = USB_ACK again. > > ************************* > * So the transaction is complete > * but my DeviceIoControl > * never sees any data !!! > ************************* > > I also hooked the OnSetupTransfer event. It seems to give > me the right request "C0 B0 00 00 00 00 04 00". > > ( This should be fired before OnDeviceRequest > is fired. But i notice that > > - if i hook OnSetupTransfer > - let *pbStatus = USB_ACK; > - and return S_OK; > > the driver and the app hang until i unplug the device > and OnDeviceRequest is not called ) > > There are not many details about it in the doc and > if you GoogleFor("ISoftUSBDevice") you would be feeling > luckier than me if you could find more than three links. > > Any clue? > > > > |