From SEGGER Wiki
Jump to: navigation, search

Communication Device Class - Abstract Control Model (CDC-ACM) This USB class is usually used for serial port emulation and as a modem interface. The class is also often used in combination with older software which previously used RS-232 to communicate with an external device.

Accessing CDC

Accessing CDC on Linux

On Linux no drivers are needed, the device should show up as /dev/ttyACM0 or similar. "sudo screen /dev/ttyACM0 115200" can be used to access the device.

CDC ACM Linux 1.png

CDC ACM Linux 2.png

Accessing CDC on Windows

On Windows 8.1 and below the "usbser" driver is not automatically assigned to the CDC-ACM device. An .inf file for the CDC-ACM device must be installed on these older systems. The device can be accessed via COM port emulation programs e.g. PuTTY.

CDC ACM Windows 10 1.png

CDC ACM Windows 10 2.png

CDC ACM Windows 10 3.png

Accessing CDC on macOS

On macOS no drivers are needed, the device should show up as /dev/tty.usbmodem13245678 or similar. The "screen" terminal program can be used to access the device.

CDC ACM macOS 1.png

CDC ACM macOS 2.png

CDC-ACM issues on Windows 10

Windows 10 comes with a re-designed driver for CDC-ACM. At the time of writing (June 2019) Windows 10 has an issue with large IN CDC transfers. Sometimes packets seems to disappear inside the Windows 10 USB stack.

The only workaround is to read in small chunks. Or to add a delay to the transfers. We have analysed this using a hardware USB analyser and a test program which reads data from the device. The device (USB high-speed) sends out data continuously in 512 bytes packets. Each packet has a unique, consecutive ID. The test application checks that the received packet always has the ID of the previous packet + 1. After a couple dozen packet the error usually appears and a packet ends up missing. When comparing the packets which are seen "on the wire" using the USB analyser with the packets which the Windows 10 program received it can be seen that sometimes packets are missing even though they were clearly successfully received by Windows 10. E.g. on the analyser one can see packets 30, 31, 32, 33 and on Windows 10 one can see 30, 31, 33. It would appear that the method through which data is read from the COM port (Windows API ReadFile, ReadFile overlapped or ReadFileEx) has no effect on the missing packets.

When using the same program on Windows 7 no issues can be seen.