Simple Design Question

NTDEV
1

Sorry for the very elementary question, but the last time I did a windows device driver was before WDF even came out. So, I want to ensure that I am taking the correct approach to this.

I have a legacy application that has been talking to a USB device that has 2 Bulk Endpoints. 1 IN and 1 OUT. The Previous Driver was from some ESC/POS sample driver that I can’t find anything about. The previous driver had to handle a Serial Connection and A USB connection and did Serial over USB.

I was able to get the KMDF Example OSRUSBFX2 device to work with our application with a slight modification to the setup. Namely, I got rid of the interrupt Endpoint in the driver.

For our new hardware, we will have 3 Endpoints. 2 IN and 1 OUT. We no longer need to support anything except a USB Connection. So my thought was to have a thread monitoring each Endpoint via ReadFile. However, I am unsure how to signal to ReadFile which endpoint to read?

What is the best approach for allowing the Application to to talk to the 2 IN Endpoints? Is there a way I can have the Read Handler(OsrFxEvtIORead) determine which endpoint is intended?

Or, would you create an IOCTL to read that additional endpoint and just let ReadFile and WriteFile Read/Write to the main IN and OUT endpoints? If the Custom IOCTL is deemed a good approach, would you just have it pass the Endpoint into a Call to OsrFxEvtRead in order to reuse the code that already services the other endpoint? This doesn’t seem like the right way to go.

Further, Is it a good Idea to take OSRUSBFX2 as a starting point and then Just modify it to handle a few custom IOCTLS and the new Endpoint?

Note that the Application needs to be backwards compatible, so I will probably have to create an IOCTL to determine if I am talking to the new device. Or, possibly using one of the USB IOCTLS that will get the Device Descriptor to determine the PID of the Device. Goal here is to not have to rewrite the whole applicaiton layer and Minimal Device Driver work since our schedule is tight. However the old driver is inadequate and only Services one IN and one OUT Endpoint. So, I thought this might be a good chance to use the KMDF to solve this problem.

Hopefully, I didn’t sound like a complete idiot, but have been out of windows device drivers for about 8 years. I am enjoying relearning this, but it is a pretty steep curve. I would like to continue doing windows driver development. I have the debugger going and was able to get the sample working with our current hardware in fairly short order.

Thanks In Advance.

2

That was supposed to say before WDM even came out as opposed to WDF.

3

xxxxx@yahoo.com wrote:

For our new hardware, we will have 3 Endpoints. 2 IN and 1 OUT. We no longer need to support anything except a USB Connection. So my thought was to have a thread monitoring each Endpoint via ReadFile. However, I am unsure how to signal to ReadFile which endpoint to read?

There are several ways. One of my favorite ways is to expose a device
namespace, and then have the application open one handle per endpoint.
You can have \MyDriver\Stream1 and \MyDriver\Stream2, for example.

An alternative is to use DeviceIoControl instead of ReadFile.
Everything ReadFile can do, DeviceIoControl can do as well.

Further, Is it a good Idea to take OSRUSBFX2 as a starting point and then Just modify it to handle a few custom IOCTLS and the new Endpoint?

I think OSRUSBFX2 is a fine example.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

4

Thanks for the Info.

Another Quick Question:
When you create 2 interfaces, is there one copy of the DEVICE_CONTEXT? Asking regarding the synchronization of data such and the DeviceInterface String that I might want to store in that structure.

5

A device interface is just a symbolic link to your stack. 2 device interfaces for the same device (WDFDEVICE in this case) resolve to the same WDFDEVICE. this means that there is only one DEVICE_CONTEXT. If you want to have context data per interface, use a context on a WDFFILEOBJECT. You can specify a generic context for all file objects using WdfDeviceInitSetFileObjectConfig or you can create the context at handle creation time in EvtDeviceFileCreate.

You should also read my blog entry on reference strings and device interfaces, http://blogs.msdn.com/doronh/archive/2006/08/18/706717.aspx

d