I wonder if anyone knows of some sort of reference for building a driver for a USB device?

We also have to integrate it with LabView so I guess I'll also look at their site.

What we have here currently uses DLL's, which I'm not really comfortable using. Doesn't XP now encapsulate DLL's away from Ring0? Can DLL's still access the USB ports even in XP? Does Windows have some kind of higher-level interface for USB ports?
Posted on 2004-10-07 04:21:05 by AmkG
For a fast and simple solution you can use FTDI USB hardware and drivers that simulate a high speed serial at 3Mbit per second.

This way you can use USB for external devices/PC and still use it as an very fast serial interface internally in your program/application
Posted on 2004-10-07 06:13:35 by BogdanOntanu
Windows does not have a general purpose high level USB interface. The closest you get are the file APIs (CreateFile, ReadFile, WriteFile) and DeviceIOControl. You use these APIs to talk to the device driver. The USB driver is not exposed to ring3 applications, so you normally have a device-specific driver communicating with the USB driver.

There are also built-in drivers for specific classes of devices, such as HID (human interface) devices, communication (modem-like) devices, and mass storage (disk-like) devices.
Posted on 2004-10-07 16:06:02 by tenkey
We're mostly building generic tools for data transfer, usually from a test device to the computer. This means we build our own drivers.

To be honest I have yet to see the code for the drivers (gosh, you mean I have to read C code?? What, you don't want me to code it in Win32Asm?? What, because no one else in the company can understand it?? waaa..... :o This is when I start to regret studying assembly, waa)

We are currently using a USB interface chip called "Cypress FX2" whose core is based on an 8051 controller, and has a fully automated FIFO buffer so that it is possible (but not REQUIRED) that all the 8051 has to do is to configure the FIFO and then shut down and let the device talk to the computer. Pretty cool too IMHO because a lot of the USB interfacing (particularly endpoint zero interfacing for control transfers) is done by FX2 hardware and is NOT even done by the 8051 core.

What I'm mostly concerned with now is the driver. Can a DLL access the USB in WinME/XP/beyond? Doesn't ME/XP now put DLL's in ring1 or something, leaving only "real" drivers (vxd's? have my wires gotten crossed?) in ring0? Or can DLL's still access hardware or the USB port? Or maybe we actually have generic drivers and maybe all the DLL does is provide an interface to the DeviceIOControl stuff so that LabView can do stuff? (maybe I better go read the C code first)

Bogdan PM me here when the next version of HE comes out hey? ;)
Posted on 2004-10-07 21:57:28 by AmkG
Your company is probably using a generic driver that the DLL communicates with, using DeviceIOControl, ReadFile, or WriteFile.

The USB host controller in a PC is designed to automatically multiplex USB transactions. You share it with other devices (consider that some engineers might be using USB mice and keyboards.) You also need to navigate through any existing external hubs. That's quite a bit of work that's already in Windows. And that's only the start.

XP and Win2k use the NT driver model. USB drivers are also WDM for plug-and-play functionality, (and also because Win98 and ME support WDM.)

Walter Oney's book on WDM, is a reference for all WDM drivers, including USB drivers. Jan Axelson has a book specifically for USB. You may want to have books on "old school" NT drivers as well.

As for online references, some folks here recommend Four-F KMD Kit for general driver information.
Posted on 2004-10-08 00:13:54 by tenkey
You're right. I looked at the DLL they were using and they just have a generic driver, provided with the hardware, that they interface to using DeviceIOControl. The source code for the driver is included (in C, so I still have to review C). The DLL was needed to interface with LabView (although I still have to hack apart NI's site to look at where the information for that is). Peculiarly the DLL has i/o support for two devices, DEVICE0 and DEVICE1, but only opens DEVICE0. And yeah: I caught myself mentally compiling the C source just to understand it (damn, like, it's been three years since I wrote in C)

I can't seem to find a decent (i.e. english) copy of four-f's KMD Kit.
Posted on 2004-10-11 19:14:11 by AmkG
Only the first few are translated. They could be found at http://masmforum.com/website/tutorials/kmdtute/index.html
Posted on 2004-10-12 02:49:02 by roticv
I think you can use generic HID interface
Posted on 2004-10-12 03:14:22 by greenant
So what is the reason for building a driver?

Simplification? This is a good goal, as the generic Cypress driver is a bit on the heavy side.

Direct control over USB hardware? This is a bad goal. The USB interface is shared, with event driven interfaces. If your customer has USB hubs, mice, or keyboards, then taking full control of the host controller disables the event driven system for handling them. There are other services such as bandwidth allocation which you will bypass, too.

Avoiding DLLs? I don't recommend this, but it's your judgement here. If your apps need to use DeviceIoControl often, then it's not worth avoiding the DLL.

Specializing and ownership? Good goals, but should be coupled with another goal. Do not try to put too much functionality in the driver. You want the driver to be "lightweight".
Posted on 2004-10-13 15:54:29 by tenkey
Originally to avoid the DLL's. Anyway I've tried to find some way for LabView to communicate directly to a USB device or some way to do DeviceIoControl in it, but LabView gives me the creeps. It's like I just want to drag around the control structures and connect them randomly and stuff. Gosh, it feels like a RTS GAME interface or something, complete with a little information window. Units and structures and stuff wahahaha. LabView, attack!

The Cypress kit includes the generic USB driver source code and yeah I see it's QUITE a bit generic, however I think we'll stick with it since we will want to design lots of different projects using the FX2.

However they inform me that most of the development time they have is in the development of the DLL - they give it as three-quarters of the whole project (!). Seems strange, since I would presume that a generic enough DLL could be made and just reused. Maybe they're just not used to programming DLL's? I mean, my impression on programming DLL's is that it is similar to programming a library, you just need to export the procedures in the .def, right? I did do some DLL programming but that was a long time ago, it didn't seem QUITE that hard.

We're building our own devices, and I think most of them will not be able to fit easily into an HID.
Posted on 2004-10-19 19:44:29 by AmkG
There are at least two ways to use DLLs. As libraries containing reusable code, or as application extensions containing custom code. It appears LabView expects DLLs to be extensions, which may explain why a good portion of the project is devoted to development of a DLL. The device driver would be the reusable code.
Posted on 2004-10-19 21:45:57 by tenkey
LabView is *supposed* to be a programming language. Somehow it seems to me that some of that functionality can be implemented in LabView so that a generic, reusable, DLL should have been possible. In particular, since most of the other engineers here are more comfortable with LabView (damn, I just can't stop playing around with the damn interface, I don't like using LabView), I would assume that that would be a much more logical (for them) way of doing things.

...or maybe they're just misreporting their mandays spent just to play StarCraft or something...
Posted on 2004-10-21 08:18:22 by AmkG