Newbee: USB Composite CDC Device - endpoints & application mapping

Discussion in 'Windows Vista Drivers' started by Skip Lankford, Mar 26, 2006.

  1. Background:
    We are developing a device with USB connectivity rather than RS232
    ports (first time for us). We need to have two different MS Windows
    applications communicate with two different embedded applications on
    this device. One of the MS Windows applications will be Hyperterm (or
    the like) communicating with a Command Line Interface (CLI) on the
    device. The other will be a custom MS Windows app communicating to a
    custom app on the device via some proprietary protocol.

    The USB Hardware on the peripheral device will likely be the Maxim
    MAX3520E, which supports 4 endpoints. The HW on the board is *very*
    tight, so adding a Hub chip and then using multiple peripheral
    controllers isn't an option (which is my understanding of what would be
    needed for a "Compound Device").

    Ideally, we'd like the peripheral device to be presented in MS Windows
    as two different devices: a Serial/COM port, and something that is
    clearly just for the custom app to use (so the user wouldn't
    accidentally connect Hyperterm to the wrong one of these two "ports").
    (However, if push came to shove, it *might* be acceptible to present
    both of these as serial/COM ports to the MS Windows application. Not
    ideal, but perhaps acceptable.)

    My understanding is that a "Composite CDC Device" could provide us the
    capability we need/desire, without requiring us to write a new MS
    Windows driver (which we definately would like to avoid if possible).
    Instead, we could make use of the standard drivers provided by
    Microsoft (i.e. the Composite driver and/or the CDC driver).

    My Questions:
    (1) Is my understanding correct that the CDC driver can be used with
    the Composite driver to present two different interfaces/ports to MS
    Windows Applications?
    (2) Will these two different interfaces/ports necessarily be presented
    as virtual COM ports, or can one of them be a virtual COM port while
    the other is clearly identified as "something else"?
    (3) If presenting one of them as "something else" is possible, can you
    tell me how this should be modeled in the .INF file?
    (4) Given that all of the data for both data-paths/applications will be
    coming through the same USB device (and presumably the same endpoints
    on the USB peripheral controller) how can the firmware on the
    peripheral device tell them apart (so it can route the data to the
    right embedded application, etc.)?

    Any help (answers, RTFM-links, whatever) would be appreciated.
    Skip Lankford, Mar 26, 2006
    1. Advertisements

  2. Skip Lankford

    henni Guest

    I don't know how configurable your MAX3520E would be,
    but for a true USB multi-function device you need
    full access to USB device functionality to build-up and
    handle a Device Descripter with two Interfaces.
    (I use Cypress AN2131 or CY7C68013 for my
    multi-function devices.)
    What is a CDC driver?
    I guess, this is a driver matching to MAX3520E.
    If so, it will work ONLY if you take another chip and resemble
    MAX3520E's functionality. :)
    It is easily possible.
    Surprisingly, this tends to require multiple INF files, because one INF
    covers exactly one device class.
    The match string looks like "USB\VID_1234&PID_5678&MI_01"
    MI_01 stands for the second "Multi"-Interface.
    Note that the rest of INF file is standard. And it is not necessary
    to be a Class=USB INF file. (For a port-like device, it SHOULD
    be a Class=Ports INF file.)
    This is done (a) by an appropriate Configuration Descriptor,
    and (b) by some firmware cases handling some interface-specific
    Endpoint Zero (EP0) control requests, mainly at wValue(?) parameter.

    Note that multiple Endpoints are not necessary for multiple
    interfaces. Interfaces may consist of no data endpoints at all,
    and all traffic goes from/to EP0.
    A configuration descriptor with multiple interfaces "automagically"
    instructs Windows to load its own Multifunction USB driver
    (a fork-like driver that loads its children after parsing the
    The child-drivers MAY interfere with EP0 traffic, but should not
    by always using the Interface number at wValue(?) member
    of control transfer header ("SETUPDAT").

    I don't know whether it's possible to use a non-EP0 Endpoint
    for multiple Interfaces, but I believe this is always a bad idea.
    henni, Apr 6, 2006
    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.