Re: USB/SCSI miniport driver source code

OK, my mistake. One usually talks about WinNT, Win2K and WinXP as three of the same. Hence the '++' trailing WinNT. But you are right, I probably should have specified Win2K, unless some WinNT4 service pack adds USB host controller support and hot-swap.

But the question still remains - example code anyone?

--
  ******************************************************
  Never ever underestimate the power of human stupidity.
 Click to see the full signature
Reply to
Geir Frode Raanes
Loading thread data ...

Stef Mientki wrote: : Geir Frode Raanes wrote: : :> I am looking for some kind of example device driver :> source code for USB devices on WinNT++. I'm not really :> sure as to what I am looking for, hence the muddy question. :> :> What I am certain of is that the example need to be dead :> simple - no multithreading, reentrant and who knows what. :> That rules out MS Developer Network. Block on all and :> everything, I do not care as long as it allows me to :> talk to the USB device one way or the other. : : why not use an USB chip that comes with complete win-whatsoever : drivers, like FTDI ?

"This is not the insight I'm looking for, move along..."

FTDI does not release source code. Is there really no publicly available USB miniport driver in source form?

--
  ******************************************************
  Never ever underestimate the power of human stupidity.
 Click to see the full signature
Reply to
Geir Frode Raanes

Michael N. Moran wrote: : Geir Frode Raanes wrote: :> I am looking for some kind of example device driver :> source code for USB devices on WinNT++. I'm not really :> sure as to what I am looking for, hence the muddy question. :> :> What I am certain of is that the example need to be dead :> simple - no multithreading, reentrant and who knows what. :> That rules out MS Developer Network. Block on all and :> everything, I do not care as long as it allows me to :> talk to the USB device one way or the other. :> : : Having said that, I have written several USB device drivers, : the latest one of which is a FAT16 storage system that uses : SCSI/Transparent Transport/Bulk-Only/USB.

Ooooh - Filesystems. Don't wanna go there... No Sir.

: Linux, however, does have source code for this, but : it takes a *little* effort to determine how things work.

In the Linux case, we have the Rubini/Corbet book. That makes life a lot easier, though I will not attemt to pass the illusion that I have read the complete book. The book is excellent on 'local' bus attached devices, but becomes sketchy when it comes to SCSI/USB.

: The USB bulk pipe mechanism is the "easiest" USB : pipe type to use. [Once you've gotten past enumeration, : etc ... nothing on the host side is *easy* in USB.]

Then bulk pipe is what I want. Sounds like it will work like a network socket from userland point of view. Good Thing(TM)

: The Transparent Transport mechanism wraps SCSI commands : and provides the message delimiting mechanism semantics : using two USB Bulk pipes, one in each direction. : : If I knew a little bit more about your application, : perhaps I could give you some more help. I do not have one (yet.) But for the sake of the argument lets pretend I have a typical simplistic USB-DAQ thingie.

I then need to do the following:

1) enumerate the device etc. 2) set up a data aquisition eg. as follows: - select DAC channel - set sampling rate - trig/start sampling either in HW or by SW - dump sampled data, ideally isochronously over USB or else from some buffer memory. - stop sampling 3) disconnect the device

In other words - the same thing one ususally do over the serial port by means of some proprietary protocol, just faster. I need access to a handful of setup/control registers, that typically will result in a bulk data transfer from USB device to PC host. Or vice versa. How hard can that be? Very, evidently...

--
  ******************************************************
  Never ever underestimate the power of human stupidity.
 Click to see the full signature
Reply to
Geir Frode Raanes

The only way this is trivial is if your device appears to the system as a "serial-port", and only uses bulk transfers. Otherwise, you'll be creating your own device/interface class, which has its advantages, but it means you'll be writing a class/interface driver for the host computer as-well-as the application.

I'll assume that you're going to go the more "difficult" route to expose some of the other fun stuff.

I would use a control pipe for these. Control transfers have a request/response type of interface that is ideal for configuration and polled status applications.

Isochronous pipes are cool, if you are going to display the data real-time, like an oscilloscope for example. The USB reserves bandwidth for isochronous pipes. However, isochronous transfers have no reliability guarantees, unlike bulk transfers, which re-transmit if packets are lost.

If you are not going to be displaying in real-time, then a single bulk IN pipe can be used to reliablby transfer the captured data to the host application.

Another control pipe command.

If you go the route of using a control pipe and a bulk IN pipe, there is no need to encapsulate command messages over a "serial stream-like" combination of a bulk IN and bulk OUT pipe.

If you do use the "serial port" type approach (one bulk IN and one bulk OUT pipe), then you will need to do all the usual message framing and parsing to multiplex the different commands and data over the link. Again, this approach is more familiar to many programmers, but much less elegant IMHO.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

I suggest you post this very same question in

microsoft.public.developement.device.drivers

cause there are definately people lurking around who do exactly this on a dayly basis. I'm also sure that the DDK will contain samlpes which are as simple as it can get. But again, people there should be able to be of more help than I.

HTH

Markus

Reply to
Markus Zingg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.