Re: USB/SCSI miniport driver source code

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
: I don't remember Windows NT4 as supporting USB.
: You had to upgrade to Windows 2000 or XP to get support for USB.
:
:> I am looking for some kind of example device driver
:> source code for USB devices on WinNT++. I'm not really

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.
We've slightly trimmed the long signature. Click to see the full one.
Re: USB/SCSI miniport driver source code
:
:> 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.
We've slightly trimmed the long signature. Click to see the full one.
Re: USB/SCSI miniport driver source code
:> 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.
We've slightly trimmed the long signature. Click to see the full one.
Re: USB/SCSI miniport driver source code
Quoted text here. Click to load it
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.

Quoted text here. Click to load it
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.
Quoted text here. Click to load it
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.

Quoted text here. Click to load it
Another control pipe command.

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: USB/SCSI miniport driver source code
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

Site Timeline