1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

USB/SCSI miniport driver source code

Discussion in 'Embedded' started by Geir Frode Raanes, Nov 10, 2003.

  1. 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.


    Something along the lines of IgorPlug-USB (AVR) below:

    http://www.avrfreaks.net/filednload...ip&PHPSESSID=965023abee21f40eeee76a1f7a4618fd

    I believe this guy found and modified some kind of USB mouse device driver,
    but he does not let anyone in on this. Hence useless...

    Also, since USB and SCSI is supposed to use the same Device Driver model,
    I would appreciate some SCSI example code as well.


    --
    ******************************************************
    Never ever underestimate the power of human stupidity.
    -Robert Anson Heinlein


    ******************************************************
     
    Geir Frode Raanes, Nov 10, 2003
    #1
    1. Advertisements

  2. I don't remember Windows NT4 as supporting USB.
    You had to upgrade to Windows 2000 or XP to get support for USB.
     
    Earl Bollinger, Nov 10, 2003
    #2
    1. Advertisements

  3. : 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.
    -Robert Anson Heinlein


    ******************************************************
     
    Geir Frode Raanes, Nov 10, 2003
    #3
  4. Geir Frode Raanes

    Stef Mientki Guest

    why not use an USB chip that comes with complete win-whatsoever drivers,
    like FTDI ?
    Stef Mientki
     
    Stef Mientki, Nov 10, 2003
    #4
  5. : 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.
    -Robert Anson Heinlein


    ******************************************************
     
    Geir Frode Raanes, Nov 11, 2003
    #5
  6. <disclaimer>
    I don't write MickeySoft device drivers, and thus
    do not know their driver/kernel/usb API.
    </disclaimer>

    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.

    Since such devices are tied into the operating
    systems file-system (as a SCSI device), and thus you're
    not likely to find much straight forward "dead-simple"
    procedural code for this. Linux, however, does have
    source code for this, but it takes a *little* effort
    to determine how things work.

    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.]

    Bulk pipes have a behavior very much like a unix
    pipe, socket or serial port. The user puts bytes in at one
    end, and they arive at the other end in the same order
    and the delivery is generally assured.

    Its similarity to the familiar serial stream is the
    reason that the EZ-USB and many other embedded USB
    solutions use this mechanism, even though there are
    several other USB pipe types that might be a better
    fit for most applications. This also allows the
    implementor to write the host-side application treating
    the device as another serial port.

    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.


    --
    Michael N. Moran (h) 770 516 7918
    5009 Old Field Ct. (c) 678 521 5460
    Kennesaw, GA, USA 30144

    "... abstractions save us time working, but they don't
    save us time learning."
    Joel Spolsky, The Law of Leaky Abstractions

    The Beatles were wrong: 1 & 1 & 1 is 1
     
    Michael N. Moran, Nov 11, 2003
    #6
  7. : 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.
    -Robert Anson Heinlein


    ******************************************************
     
    Geir Frode Raanes, Nov 11, 2003
    #7
  8. 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
    Kennesaw, GA, USA 30144

    "... abstractions save us time working, but they don't
    save us time learning."
    Joel Spolsky, The Law of Leaky Abstractions

    The Beatles were wrong: 1 & 1 & 1 is 1
     
    Michael N. Moran, Nov 11, 2003
    #8
  9. Geir Frode Raanes

    Markus Zingg Guest

    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
     
    Markus Zingg, Nov 11, 2003
    #9
  10. Geir Frode Raanes

    Bob Stephens Guest

    Check out www.cygnal.com their development kit for the C8051f320 series usb
    chips has a Windows app complete with USB device driver source code.

    Now MY problem is to find a similar device driver for WINCE/PocketPC or a
    means to port the XP driver to CE.

    Any Ideas?

    Bob Stephens
     
    Bob Stephens, Nov 20, 2003
    #10
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.