When it is practical to do so, Linux groups devices with similar functionalities under the same default device or interface names. Each vendor defined its own (usually proprietary) protocols, with commands allowing to control functions of the chips such as setting the baud rate or controlling additional signals used to implement hardware flow control.
Those vendors opted not to lie to the host computer in having the chips announce themselves as USB modems when they were not. Several vendors, such as FTDI or Prolific sell dedicated chips for a few euros. While it is possible to use a software-only USB stack, the additional constraints put onto the CPU and the usually small storage size often lead board designers to include a dedicated UART to USB bridge. Sometimes, the embedded microcontroller does not come with a hardware USB interface. Linux will not know that the device is lying, and will have it show up as /dev/ttyS0. Pretending the embedded device is a modem is the simplest way to communicate with it, even though it will probably never perform any modulation or demodulation task. This is why most people choose to implement CDC/PSTN with ACM (did you notice that the Linux kernel driver for /dev/ttyACM0 is named cdc_acm?) because it is the simplest way to exchange raw data.īut what about the mandatory V.250 command set? It is almost never implemented in such devices, but since the host has no reason to spontaneously generate V.250 commands by itself, the device will never have to answer them. When developping on a USB-enabled embedded microcontroller that needs to exchange data with a computer over USB, it is tempting to use a standardized way of communication which is well supported by virtually every operating system. When the commands are multiplexed with the data in the data stream, an escape sequence such as Hayes 302 (also known as “1 sec +++ 1 sec”) or TIES (that nobody remembers) must allow the host to put the modem into command mode. This model is used by some USB soft modems, which are very cheap because they mostly contain a DSP chip and some amplification and line adaptation layers.Īnother control model, aptly named abstract control model or ACM, lets the modem hardware perform the analog functions, and require that it supports the ITU V.250 (also known as Hayes in its former life) command set, either in the data stream or as a separate control stream through the communication class interface.
For example, the direct line control model controls how data is exchanged between the host and the modem through an audio class interface, with the host taking charge of the modulation, demodulation, data compression (such as V.42bis) and error correction (such as V.42). To discuss with the modem, the host USB driver must use one of the existing control models.
Those are known as modems because the data goes through a modulation operation on the sending side, which transforms the bits into analog signals that can be carried over phone wires, and then through a demodulation operation on the receiving side to convert the analog signal back into the original bits. The USB implementors forum also specified how CDC subclasses should act, including for those devices intended to talk with each other over the public switched telephone network (PSTN). The USB implementors forum organization has described how devices conforming to the Communications Device Class (CDC) should present themselves to the USB host. Warning: this is a Linux specific post, although it also contains genuine pieces of USB culture. Have you ever wondered why some USB devices used /dev/ttyUSB0 (or 1, or n) and others /dev/ttyACM0 (or 1, or n) when they are plugged into the host computer, while they seem to be acting as UART devices ( RS-232-like) over USB in both cases? Have you wondered why example USB firmwares for microcontrollers always end up with names such as /dev/ttyACM0 and never as /dev/ttyUSB0?
0 kommentar(er)
