USB Serial Port Migration Products




The MCCI USB Modem Integration Package allows OEMs to create a USB modem quickly and cost-effectively. MCCI® combines firmware and hardware design services with WDM drivers that provide Plug and Play modem operation in Windows XP and later systems.

MCCI offers a family of USB drivers and firmware, targeted towards migrating existing applications based on serial ports to USB.

Migration can be based on the following approaches:
  1. The serial port can be relocated from the host to a remote USB device. MCCI calls this a "remote serial port".
  2. The serial port is eliminated, but serial-port "look and feel" is retained in both the host and the device. MCCI calls this a "virtual serial port".
  3. Eliminating the serial port altogether, and converting the semantics to the appropriate device class for the remote device.
MCCI serial port migration products support the first two approaches. MCCI generic USB drivers and MCCI USB DataPump® form a foundation for converting to a new application-specific device class.

From the host's perspective, the drivers for remote serial ports and virtual serial ports are the same. The firmware involved, however, is slightly different.

Virtual Serial Port Firmware Overview

The most common application of MCCI serial port migration technology is for eliminating the serial port altogether. This provides a convenient way of migrating external ISDN terminal adapters and other telecommunication devices from RS-232 to USB. Because RS-232 support is common to all major operating systems, it also is a convenient and cost-effective way to get multi-platform USB support.

The Virtual Serial Port package consists of:
  1. The VSP protocol, which includes all the USB "over-the-wire" protocol elements to allow portions of the host serial driver to operate remotely on the USB device. All the important changes made by the host to the host-serial interface are reflected through to the upper edge of the VSP protocol module; and all USB-specific housekeeping is performed internally to the VSP protocol module.
  2. The VSERIAL protocol which translates the semantics of a host-based UART into the semantics needed by the device.
Figure 1 illustrates how these components are related to a traditional serial link between a host computer and a data communication device.

Figure 1. RS-232 System Architecture Comparison

RS232_architecture

The upper half of the picture shows, for reference, a physical RS-232 (serial) communication channel. The lower half shows how each of these blocks is mapped onto the USB subsystem

Notice that the USB link is really part of the interface to the remote emulated 16550 all of the state of the USB class driver in the USB host is available to the firmware in the USB device. All of the details of the wire-level protocol used for communication are encapsulated in the "VSP" protocol module of the data pump.

The host driver architecture is specific to the operating system being used; we discuss that in detail below.

The VSERIAL protocol is a shim protocol that connects a virutal 16550 interface in the USB host to a device-side 16550 interface. Any baud-rate differences between the two ends are ignored, and the data transfer between the two simulated 16550s is interlocked; so that (unlike with real serial ports) the data transfer is completely interlocked.

The VSERIAL protocol is still abstract, in that it allows the VSP to be configured in a number of different ways.

From the software point of view, an instance of the VSERIAL protocol interfaces with other system modules as shown in Figure 2.

From the software point of view, an instance of the VSERIAL protocol interfaces with other system modules as shown in Figure 2.

Figure 2. VSERIAL Protocol System Block Diagram

VSERIAL

Only the serial drivers need to be modified in order to communicate with the VSERIAL protocol module; the rest of the application remains the same.

For example, an ISDN TA would be organized as shown in Figure 3:

Figure 3. ISDN TA Implementation

ISDN TA

Remote Serial Port Firmware Overview

The MCCI VSP package can also be used to implement remote serial ports, although this is generally only done as part of a multi-port or multi-function device.

The Remote Serial Port package consists of:
  1. The VSP protocol, which effectively has the semantics of being "inside" a host-based 16550 UART. All the important changes made by the host to the host-based UART-like interface are reflected through to the upper edge of the VSP protocol module.
  2. A hardware-specific driver that bridges the VSP protocol to the physical hardware.
Figure 4 illustrates this architecture.

Figure 4. Remote Serial Port System Diagram

Remote Serial

The upper half of the picture shows, for reference, a local RS-232 (serial) communication channel. The lower half shows how the VSP package is used to implement a remote RS-232 port.

Again, notice that the USB link is embedded in the emulated 16550 exported by the USB class driver. All of the details of the wire-level protocol used for communication are encapsulated in the "VSP" protocol module of the DataPump.

In some cases, only the host VSP drivers are supplied by MCCI; the remaining components are implemented directly in hardware or by special-purpose firmware supplied by the OEM or by MCCI.

Normally, a custom protocol is written that interfaces between the VSP protocol and the serial port, as shown in Figure 5.

Normally, a custom protocol is written that interfaces between the VSP protocol and the serial port, as shown in Figure 5.

Figure 5. Remote Serial Port Firmware Block Diagram

Remote Serial Firmware

Since the MCCI code is all sharable and reentrant, this architecture can be very efficient for supporting large numbers of serial ports, or serial ports in conjunction with other kinds of USB devices.

Enumeration and INF files

Enumeration of MCCI Communication drivers proceeds as follows:
  1. The system recognizes that a new USB peripheral is present and asks for the device descriptor.
  2. The system extracts the USB manufacturer ID and device ID from the device descriptor, and uses this as a key to search the INF databases.
  3. For multi-port devices, the system recognizes that a composite device is present, and loads a multiplexing driver. The system then creates a derived key from the base key created in step 2.
  4. A matching INF entry is found in the MCCI Communication driver INF file.
  5. The match causes the various drivers to be loaded in the normal way.
Communications Drivers for Windows XP, Vista, Windows 7, and Windows 8

The system driver architecture uses "Mccimdm.sys" to translate the "serial.sys" API into equivalent USB commands. However, since "serial.sys" is a native Windows NT API, much less infrastructure is required to make the serial port available to the rest of the system. Figure 6 shows the architecture we use.

Figure 6. Communication Driver Architecture for Windows XP, Vista, Windows 7, and Windows 8

communications driver architecture

  1. mccimdm.sys - the same driver that is used in legacy sitemaps.
  2. mccicmnt.sys - this module provides services that are specific to operating under Windows 2000
  3. mcciw32.dll - this module, generated by MCCI InstallRight™Womba, automates the installation procedure.
Complementing the Windows USB Class Driver product line for Windows XP through Windows 8, MCCI also offers serial emulation drivers for Windows CE and Windows Mobile platforms.

Communications Drivers for Mac OS X

The architecture for Mac OS X is shown in Figure 7.

Figure 7. Mac OS X USB Software Architecture - Serial Emulation

Mac OS X Software

The modules supplied are:
  1. "MCCI USB Serial Driver for Mac OS X " - The MCCI USB Serial Driver.
  2. "MCCI Driver Installer for Mac OS X " - The MCCI installation application which installs the drivers to the correct location.
  3. "MCCI Driver Uninstaller for Mac OS X" - The MCCI un-installation application which cleanly removes the drivers.



Back to top