A particular DEVICE may appear to be a COM port. Or multiple COM ports. Or a mix of COM ports and other interfaces.
The device, when it's plugged in, identifies itself to the host with a vendor ID / product ID combination. The host checks to see if it's got a driver that matches, and if so, loads it and hands communication with that device to the driver. The driver is usually supplied by the device vendor, and can pretty much do whatever it wants. In the case of a USB<>serial adapter, there's a serial UART in the adapter, and the driver presents a 'fake' COM port to the operating system. It's up to the driver to run that UART. Not all vendors do it the same way. With many devices the vendor doesn't even know what's going on there, because they're using a chip from a company like FTDI that provides their own drivers - it's all just a black box. There are also class drivers, where a common device (like a keyboard or flash drive) doesn't need a vendor-specific driver if it adheres to a published spec for that type of device. For serial devices it's part of the Communications Device Class spec, and it works, but I don't think most serial adapters use it. So basically, on top of all the complicated out-of-band stuff that USB defines for housekeeping, the in-band stuff is often opaque, undocumented, and very vendor-specific. It's a whole heck of a lot better than the days of daisy chaining stuff on the parallel port, but it's also not as easy to hack stuff together as with RS-232. Scott Lynn W. Deffenbaugh (Mr) wrote: > > > James Ewen wrote: > > USB is not RS-232. RS-232 is not USB. > > > > Regardless of the fact that it may appear to be a COM port on a Windoze PC. > > Lynn (D) - KJ4ERJ
