Thesycon’s USB CDC/ACM device driver provides a serial port emulation on Windows operating systems by implementing a serial link emulation protocol on USB. The driver exposes a Win32-compatible COM port and in addition provides some unique features such as a Plug&Play compliant device instance enumeration method. This avoids confusion about COM port numbers and improves usability.
The driver supports all Windows desktop operating versions. A similar driver is also available for Windows CE. See USB CDC/ACM Class Driver for Windows CE for more information.
The driver works with devices that are compliant to the Communication Device Class (CDC) specification, subclass Abstract Control Model (ACM). However, the driver supports three different USB protocol types, which are described in more detail below.
Thesycon also offers the Embedded USB Device Stack with CDC/ACM device class for implementing the firmware of a USB CDC/ACM device. With these development kits Thesycon provides the support for implementing the firmware and the device driver for USB CDC/ACM devices quickly and cost-effectively.
The device needs to implement the Abstract Control Model (ACM) subclass defined in the USB Communication Device Class (CDC) specification. This protocol requires two USB interfaces, a data interface which consists of two endpoints (bulk in + bulk out) and a control interface which consists of one interrupt in endpoint. Furthermore, on EP0 the device must implement the class-specific requests defined by the CDC specification. Because this USB protocol is compliant to the CDC/ACM standard on some operating systems (e.g. Linux, MacOS) the device can work with in-box drivers.
This mode uses the CDC data interface (bulk in + bulk out endpoint) only. No control interface (interrupt in endpoint) is required. The device needs to implement the CDC class-specific requests, so that is still possible to support baud rate settings and serial control/status lines. This mode is useful if the number of available endpoints is limited by hardware restrictions. However, as the protocol is proprietary, a specific device driver is required for every operating system platform to be supported by the device.
The device implements only the data interface (bulk in + bulk out endpoint). The device does not provide an additional control interface and does not need to implement any class-specific requests on EP0. Because bulk transfer mode provides flow control, there is no need to support serial control/status lines. The advantage of the bulk-only protocol is that the implementation efforts on the device side are reduced to a minimum. However, because the protocol is proprietary, a specific device driver is required for every operating system platform to be supported by the device.
Depending on the driver configuration, the CDC/ACM device driver exposes an emulated COM port or a modem. The standard Windows mechanism is used to assign a COM port number to each device instance. This COM port can be opened and used by standard programs such as HyperTerminal.
In addition to the COM port naming scheme, the driver supports a PnP compliant enumeration mechanism which is based on device interfaces. Custom applications can enumerate and open available device instances by using Windows API functions such as SetupDiGetClassDevs and SetupDiEnumDeviceInterfaces. So the user is not required to enter a COM port number. Applications can automatically locate, identify and open available device instances. By using the function RegisterDeviceNotification, applications can receive notification messages when devices are connected or disconnected. Thus, an application can implement full USB Plug&Play support.
Thesycon also offers an ACM class driver for Windows CE and Windows Mobile.
Using Thesycon’s PnP Driver Installer it is very easy to create a specific setup wizard that handles driver installation, un-installation and update in a comfortable and reliable way. For more information on PnP Driver Installer, check out http://www.thesycon.de/pnpinstaller.
The demo version is time-limited but has full functionality. After the device is connected the driver can be used for used for 4 hours before the driver disables itself and the computer must be rebooted in order to use the demo again. The demo package includes the driver and the documentation.
Current Version: 2.14
NOTE: The driver described on this page is *not for use by end users*. It will not help solve any problems you may experience with a consumer device such as a webcam, camcorder, card reader, external sound card, etc. Thesycon’s device drivers are software components intended to be used by hardware or software manufacturers to create end products.
For each USB device model an official USB vendor ID (VID) is required. Vendor IDs must be unique and will be assigned by the USB Implementers Forum (www.usb.org). Registration fees will be charged.
Thesycon owns a USB vendor ID and offers a subset of product IDs (PID) to device vendors. For customers who have licensed USB software from Thesycon this service is free of charge.
If you would like to be kept informed of product updates, please subscribe to the Thesycon newsletter.