Hi and thanks for the excellent and comprehensive reply!
First of all, I should do apologize if my next questions are clumsily!
I have a “token” instead of “smart card&card reader”;
According to your explanation, I found that we don’t have any USB driver
library in Host Controller inside Windows XP (sp3) and we should use a
COM-to-USB converter driver instead;
Also, There should be a USB-to-COM converter in my usb token where it’s
Windows-based driver should introduce and register this built-in converter
to the windows as a “COM” port when we connect the token to the PC and
install it’s driver;
Therefore, we have only “COM” interface in windows to communicate with
serial&usb devices!
Is it right?!
Is there a USB-to-COM converter(hardware) in the PC to recieve data from the
usb device too?
As I understand, you have a library and sample code, so please use these
samples to get familiar with your device and its interfaces.
Is there a simple GUI in windows to show a USB device features, such as
configuration, number of interfaces, number and type of endpoints, …?
I get some token features in linux from a program called “hid_linux.cpp” as
below:
rawhid_open, max=1
device: vid=E854, pid=1230, with 1 iface
type 3, 0, 0
IN endpoint 1
OUT endpoint 2
hid interface (generic)
in use by driver “usbhid”
found rawhid device
number of sent bytes = 64
number of received bytes = 64
number of received bytes = 64
reading from token is done
But I need the full features of the usb token!
When we want to register a usb token’s built-in converter as a “COM” port to
windows via driver, how should we define the port number(COM ) of it?
> But I can’t understand why we have “COM1, COM2, …,COM9” in such
programming?!
Now, I think these port numbers are only an “Identifier” to communicate with
a special serial device (through “RS-232(9 pin)-to-USB” converter)!
BTW, if we have 4 USB port on PC for example, how they will be
named(COM0…COM4)?!
Are there 4 COM-to-USB hardware converter in PC, or only one converter to
support the 4 usb ports(slots)?
I appreciate you so much if answer my questions again and clear some of my
understanding ambiguities;
Best Regards.
On Mon, Jul 26, 2010 at 12:18 PM, Hagen Patzke wrote:
> Here is my personal “COM/USB backgrounder”:
>
> In the past, serial interfaces provided a proven, simple way of
> exchanging a few bytes between a PC and a device.
> Specifically the 16550 UART was very widespread.
>
> Serial ports were also catered for in the PC BIOS, in MS-DOS, and in
> Windows. MS-DOS and Windows exposed the serial interface in the form of
> “COM*” interfaces. (Unix traditionally exposes these interfaces in form
> of “device files”, usually in the /dev/ttyS* range.)
>
>
> With the advent of USB,…
>
> …many small-scale projects or older hardware did not want to implement
> their own USB interface into the hardware design. Internally, they
> wanted rather to stick to the simpler serial interface. Also some
> external components - specifically smart card readers - already use
> serial communication, so there a serial interface is a good choice.
>
> …unfortunately nobody integrated a simple way into Windows to exchange
> “just a few bytes” with another device. There was no simple “USB*”
> interface like it worked with “COM*”: each and every hardware vendor had
> to provide their own USB driver.
> [On Windows, many (if not most) of these are derived from the “infamous”
> BulkUSB sample (dropped from the latest WDKs).]
>
>
> Now, several years later…
>
> …for the hardware, the industry responded and many USB-to-serial
> converters became available. You can still buy external USB-to-Serial
> converter “cables”, but more often the converters are now directly
> integrated in the device you have (e.g. Smart Card reader). On Windows,
> the drivers of these converters usually register themselves as a “COM”
> port. This is likely what you see for your SC reader hardware.
>
> …for Windows, meanwhile Microsoft provides a relatively simple way for
> applications to directly open a USB device and send/receive a few bytes
> from it: via WinUSB. Also they introduced the UMDF and KMDF driver
> frameworks to ease driver development (and improve security). Soy ou can
> use the “COM” converter driver, but you also could talk to the reader
> directly.
>
> …for Linux, you don’t have an OS-internal COM-to-USB-mapping, and you
> don’t need one. Here you can just open the USB device directly (like a
> file), control it via IOCTLs, and send/receive data.
> As I understand, you have a library and sample code, so please use these
> samples to get familiar with your device and its interfaces.
>
>
> Sorry for the long post. Corrections/additions welcome.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>