These classes and subclasses are defined by the USB Implementers Forum in documents that you can find here: The device you made could be called a "CDC ACM device" because it uses the CDC class and the ACM subclass.
CDC is a USB device class, and ACM is a subclass that I assume you are using. You should learn a little bit about USB device classes. If you need to connect to a "real" serial port, you should use a real UART - which are far more ubiquitous than USB controllers on microcontrollers in any case. The purpose of the CDC/ACM class is primarily to allow "legacy" software to work on a PC. In theory you could connect a microcontroller that has a USB host controller to one that has a USB device controller, but you need host and device software stacks on each respectively, and once you have the USB connection, implementing CDC/ACM is a somewhat inefficient use of the available bandwidth. There are devices that act as UART/USB bridges (from FTDI and Prolific for example), and you could (somewhat expensively) build your own from a microcontroller that has a USB device controller and a UART, but the bridge is a USB device and must still connect to a USB host these are normally used to connect a PC to a microcontroller that lacks a USB controller or where the software/CPU overhead of using a USB controller is too great. There is an awful lot going on under the hood to make it look like a PC serial port, but none of it resembles UART communications at the physical level. It looks like a serial port at the software level, but does not implement a UART physical layer. The device cannot initiate data transfer it must be continuously polled by the by the host.Ī CDC/ACM class device presents a virtual COM port on a PC host, but that does not allow the device to communicate with a UART interface. It requires a host and a device in a master/slave relationship. A USB connection is not a peer-to-peer connection like a UART.
0 kommentar(er)
