Additional USB bulk pipes to FX2 Learning Kit Sample

NTDEV
1

Hi,

I am maintaining an old driver which was written based on USB FX2 learning kit. The driver is used in Windows Embedded Standard 2009 (a Xp code based OS). The hardware is communicating with client software via control pipes, an interrupt pipe (IN only), and a pair of bulk pipe (IN and OUT). The WDM sample uses exactly the same pipes configuration, so the task was easy, just remove the sample control code and added in my own.

Now, I have to add in a couple of additional bulk pipes to implement some new communication channels. In the sample, the bulk OUT and IN transfers are handled by UsbFx2LkWrite() and UsbFx2LkRead(), respectively. All those routines are in turn bound to IRP_MJ_WRITE and IRP_MJ_READ, respectively, during driver initial entry. In those UsbFx2LkWrite()/UsbFx2LkRead() routines, all the transfers are directed to BulkOutPipe/BulkInPipe, which are the only bulk pipes of the USBFX2LK kit.

I have been researching hard for more than a week now. How on earth that I could make the additional bulk pipes talk? From the client application’s CreateFile() to WriteFile()/ReadFile(), there is no way to pass any parameter/argument to UsbFx2LkWrite()/UsbFx2LkRead(), telling them which pipe this transfer is intended to.

Does this mean one driver can support only one bulk OUT/IN pair only? Oh, I do not believe this, and hopefully I am wrong. Obviously I have been missing something (simple?).

Really appreciate if someone could point me to the right direction.

Thanks and best regards,
WH Tan

2

You have a couple of choices

  1. don’t use read/write anymore, use your own IOCTLs (which have both input and output parameters) where you can specify the desired pipe number
  2. you support a file namespace in the driver and in the file path you append the desired pipe index you want to communicate with. you must capture that index in handling MJ_CREATE in the PFILE_OBJECT and then look up this index in your read/write routine

I would strongly recommend that you throw away your WDM version of this sample and move to the KMDF version. If you are using a subset of the WDM sample, you can use a subset of the KMDF sample just as easily. KMDF will allow you to implement either 1 or 2, but especially 2, in a very simple and clean way.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, March 25, 2015 10:49 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Additional USB bulk pipes to FX2 Learning Kit Sample

Hi,

I am maintaining an old driver which was written based on USB FX2 learning kit. The driver is used in Windows Embedded Standard 2009 (a Xp code based OS). The hardware is communicating with client software via control pipes, an interrupt pipe (IN only), and a pair of bulk pipe (IN and OUT). The WDM sample uses exactly the same pipes configuration, so the task was easy, just remove the sample control code and added in my own.

Now, I have to add in a couple of additional bulk pipes to implement some new communication channels. In the sample, the bulk OUT and IN transfers are handled by UsbFx2LkWrite() and UsbFx2LkRead(), respectively. All those routines are in turn bound to IRP_MJ_WRITE and IRP_MJ_READ, respectively, during driver initial entry. In those UsbFx2LkWrite()/UsbFx2LkRead() routines, all the transfers are directed to BulkOutPipe/BulkInPipe, which are the only bulk pipes of the USBFX2LK kit.

I have been researching hard for more than a week now. How on earth that I could make the additional bulk pipes talk? From the client application’s CreateFile() to WriteFile()/ReadFile(), there is no way to pass any parameter/argument to UsbFx2LkWrite()/UsbFx2LkRead(), telling them which pipe this transfer is intended to.

Does this mean one driver can support only one bulk OUT/IN pair only? Oh, I do not believe this, and hopefully I am wrong. Obviously I have been missing something (simple?).

Really appreciate if someone could point me to the right direction.

Thanks and best regards,
WH Tan

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

Hi WH,

This seems to be a perfect use case for libusb. Your device seems to
be a generic
device and you can forget about your custom driver and switch to
WinUSB driver and
use user mode application (libusb API) to talk to your device.

Of course you can also use native WinUSB API.

libusb (cross-platform): https://github.com/libusb/libusb/wiki
WinUSB (Windows only):
https://msdn.microsoft.com/en-us/library/windows/hardware/ff540174(v=vs.85).aspx

Regards,
Xiaofan

On Thu, Mar 26, 2015 at 1:48 PM, wrote:
Hi,

I am maintaining an old driver which was written based on USB FX2
learning kit. The driver is used in Windows Embedded Standard 2009 (a
Xp code based OS). The hardware is communicating with client software
via control pipes, an interrupt pipe (IN only), and a pair of bulk
pipe (IN and OUT). The WDM sample uses exactly the same pipes
configuration, so the task was easy, just remove the sample control
code and added in my own.

Now, I have to add in a couple of additional bulk pipes to implement
some new communication channels. In the sample, the bulk OUT and IN
transfers are handled by UsbFx2LkWrite() and UsbFx2LkRead(),
respectively. All those routines are in turn bound to IRP_MJ_WRITE
and IRP_MJ_READ, respectively, during driver initial entry. In those
UsbFx2LkWrite()/UsbFx2LkRead() routines, all the transfers are
directed to BulkOutPipe/BulkInPipe, which are the only bulk pipes of
the USBFX2LK kit.

I have been researching hard for more than a week now. How on earth
that I could make the additional bulk pipes talk? From the client
application’s CreateFile() to WriteFile()/ReadFile(), there is no way
to pass any parameter/argument to UsbFx2LkWrite()/UsbFx2LkRead(),
telling them which pipe this transfer is intended to.

Does this mean one driver can support only one bulk OUT/IN pair only?
Oh, I do not believe this, and hopefully I am wrong. Obviously I have
been missing something (simple?).

Really appreciate if someone could point me to the right direction.

Thanks and best regards,
WH Tan

4

Hello Doron,

Thanks very much for the pointers. I appreciate it.

Let me figure out the concepts of the file namespace first. I just found this:
http://www.wd-3.com/archive/namespace.htm , which looks like what you’re talking about.

Thanks again.
WH Tan

5

Hello Xiaofan,

Thanks for your information.

Unfortunately, using WinUSB at this point (for an old project and just a maintenance update) which might impose a lot of work in code reviewing or/and rewriting - from F/W to driver to client apps. If I were doing new project, I will consider WinUSB seriously.

Thanks again and best regards,
WH Tan

6

xxxxx@gmail.com wrote:

Unfortunately, using WinUSB at this point (for an old project and just a maintenance update) which might impose a lot of work in code reviewing or/and rewriting - from F/W to driver to client apps. If I were doing new project, I will consider WinUSB seriously.

I understand what you are saying, but in many cases the transition to
WinUSB is almost painless. Most custom USB drivers end up exposing
individual transfers anyway, so there’s nearly a one-for-one trade.
Often, a simple adapter-plate DLL is all that it takes.

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

7

Tim,

Could you elaborate on “a simple adapter-plate DLL…” a little bit (or maybe it’s in WinUSB’s manual)?

We’re in a similar situation - made our WDM USB drivers (along with our own firmware and Win/Mac apps) in Win98 days. The last revision was for Win7 x64’s signing requirement, and I haven’t touched USB stuff since.

Please pardon my ignorance about WinUSB though I’ve read/heard about it (just a little).

Thanks,
JC

8

xxxxx@oyogeospace.com wrote:

Could you elaborate on “a simple adapter-plate DLL…” a little bit (or maybe it’s in WinUSB’s manual)?

What I mean is that many projects don’t expose the DeviceIoControl calls
directly to applications. Instead, they have their own DLLs with
functions like “ReadBuffer” or “SendCommand”, etc., and those functions
deal with the driver and the ioctls. If you have that kind of design,
then you can simply replace that DLL with one that exposes the same
interface but calls WinUSB instead.

If your client apps call DeviceIoControl directly, then it’s not as easy.

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

9

Thanks. Crystal clear.

…client apps call DeviceIoControl directly, then it’s not as easy.

Unfortunately, that’s our case and we are doomed. We’re going to embark on a new hardware design (along with client apps) soon, and definitely will go with WinUSB.

10

On Tue, Mar 31, 2015 at 5:10 AM, Tim Roberts wrote:
> xxxxx@oyogeospace.com wrote:
>> Could you elaborate on “a simple adapter-plate DLL…” a little bit (or maybe
>> it’s in WinUSB’s manual)?
>
> What I mean is that many projects don’t expose the DeviceIoControl calls
> directly to applications. Instead, they have their own DLLs with
> functions like “ReadBuffer” or “SendCommand”, etc., and those functions
> deal with the driver and the ioctls. If you have that kind of design,
> then you can simply replace that DLL with one that exposes the same
> interface but calls WinUSB instead.

That is what Microchip deals with their custom driver (mchpusb and dll).
I believe the older driver was developed by Walter Oney and later
they switch to WinUSB driver, they just need to replace the dll with
a wrapper based on WinUSB API.

Ref:http://www.microchip.com/forums/m598365.aspx

> If your client apps call DeviceIoControl directly, then it’s not as easy.

–
Xiaofan

11

On Mon, Mar 30, 2015 at 4:09 PM, wrote:
> Hello Xiaofan,
>
> Thanks for your information.
>
> Unfortunately, using WinUSB at this point (for an old project and just a
> maintenance update) which might impose a lot of work in code
> reviewing or/and rewriting - from F/W to driver to client apps. If I were
> doing new project, I will consider WinUSB seriously.
>

I do not think you need to change FW at all. And the client apps
may only only need very minor modification if the HW access
is segregated well with the other parts of the function. Then you
only need to write wrapper functions with the WinUSB API and
slot them in your application.

–
Xiaofan