Linux下使用USB模拟ACM串口设备【转】
本文转载自：https://www.cnblogs.com/pied/p/4549614.html
这个想法之前就在脑袋里有过，最近公司产品要用到，所以多做了些了解。
1. USB 简介
USB 是 Universal Serial Bus 的缩写，从字面上看，就是通用串行总线的意思。从物理上看，其实就是一对差分线，连接两台设备后，相互间进行数据传输。加上另外两路供电（ 5V 和 GND）线，一共是 4 根线。
那么，既然是只有一对差分线，那么该如何决定由谁传给谁呢（如果两边同时在线上建立电平，线路上的电平会是不确定态的，以致无法通信）？这就要说到 USB 传输的一个重要基础：“询问-应答” 机制—— Device（slave） 设备通常是处在等待状态，只有 HOST 侧设备发起询问、请求，它才会在接下来的时间片中使用数据线向 HOST 发送数据。
那么，谁是 HOST，谁是 SLAVE 又是由什么来决定的呢？答案是硬件。也就是说，你 USB 后面的那块驱动芯片如果是 HOST，那么，这个 USB 只能做 HOST 用了。反之，SLAVE 亦然。比如我们经常见到的，PC 上的 USB HOST 连接到 U盘、鼠标、键盘这些 SLAVE 设备。
后来有人觉得这样一个设备只能是 HOST 或者只能是 SLAVE 太死板了，所以又发明了 USB OTG。USB OTG（on-the-go，大意为在使用时切换身份）是在原来 4 根线的基础上，又加了一根线，ID。那块 USB 后面的驱动芯片，就可以根据这根线，来选择自己到底该扮演 HOST 还是 SLAVE 的角色。后面我们单独介绍。
另外，因为使用一对差分线进行数据传输，所以，USB 又采用了基于 HUB 的星形拓扑结构（包括根控制器，最多7 层拓扑，且7层已不具备挂载 HUB 能力，只能是功能设备）。所以，更确切来说，“HOST-SLAVE“ 是在由 HUB 支持的物理链路之上的传输机制。同时，HUB 本身也是一个 USB SLAVE 设备。
2. USB 连接过程概述
下图很好的解释了 USB 的连接过程。需注意，1）如上图的拓扑结构所示，每个网络内只能有一个 HOST。2） HOST 和 SLAVE 之间，可以一对一直连，也可以通过 HUB ，一个 HOST 对应多个 SLAVE。
基本状态包括：设备插入、设备上电、设备复位、设备获得地址、设备配置完成、挂起状态。下面略做解释。
设备插入：HOST 侧（可能是在 HUB 上，也可能是直接在 host controller 上）根据 D+ 和 D- 口的阻抗变化，来判断是否有 device 插入，以及判断插入设备的速度类型。
设备上电：因为 USB 口有供电功能（5V DC，多为 500-1000 mA ），所以，设备又分为 Bus powered 和 self powerd。当然，即使是设备自己供电，我们也认为只有当设备已连接，它才进入powered 状态。设备一旦重新上电，后面的连接操作要重新执行一次。
设备复位：因为只有一对差分线，如果两边同时操作，那线路上的电平将是不确定态，根本无法通信。所以，上电后，USB device（slave）默认为等待状态，不进行任何动作，直到 HOST 发给它一个 Reset 请求。复位完成，意味着低速/全速/高速的物理通路已经建立。
设备获得地址：设备复位成功后，将获得一个由 HOST 分配的地址。分配地址的对话，将在设备的 endpoint0 上完成。
设备配置完成：握手？配置？反正这一阶段完成，意味着设备已经 ready了。
挂起状态：所有 USB Device（slave）在空闲一段时间后，都必须将自己挂起，并保持自己的状态，无论设备已经被分配地址还是没有分配地址。
3. OTG
OTG 增加了一根可以动态配置为 HOST 或者 DEVICE（slave）的数据线，以 micro USB 接头为例，其引脚分配如下：
因为传统的 USB 线缆为 4 根线，所以，要将 OTG 设备接入，需对其进行配置（硬件短接）：
1. 当配置 OTG 设备为 USB Device（slave） 时，将 ID 脚悬空。
2. 当配置 OTG 设备为 USB HOST时，将 ID 脚接地。
所以，我们这里，需要将OTG脚悬空，来将其配置为 Slave 设备。硬件上面，买来的 OTG 转接线默认把 OTG USB 设备设置为 HOST，他们 ID 脚都是接地的。而我们是需要把 OTG 设备当作 Device（slave）来用，所以，最终选择了将板子上的 ID 线割断，使其悬空。
4. 一般的实现结构
前面我们讨论了硬件部分，同时，作为通讯接口，不可能不需要系统及软件层面的协作。先给出一张比较常见的 USB 通讯模型图，然后我们再做解释：
对于整个 USB 通讯过程，我们可以粗略的将其分为“总线层”、“功能层”和“设备层”三个层次。这三个层次的划分，主要是为了问题的集中解决。其中：
a. 总线层负责解决“点到点”的问题，主要是保障上一层可以和相邻的端点“对话”，一般还会提供硬件 buffer 公上层使用；
b. 设备层才有了设备的概念，HOST 通过 Device（Slave）的 Endpoint0 对其进行配置，准备好数据管道给上一层使用；
c. 功能层在是 Device（Slave）功能的具体实现，才能看到一个个“鲜活”的设备，才是我们看得到的 U盘、鼠标这些设备。
以某安装 Linux 的 PC 为例，作为 HOST，其中这三部分工作分别由控制器（如 EHCI 、UHCI 、OHCI），USB CORE （对前面控制器的内核支持、设备管理功能等）和 USB 上层驱动（usbmouse、usbkbd、usb-storge）。
我们要实现的 USB 串口，就是属于 USB 上层驱动部分的实现。只不过，我们是通过类似于这里 HOST 的结构，实现了一个 Device(Slave)。
5. g_serial.ko
当前内核 3.0.8 支持 Gadget Serial 接口。也就是说，如果我们有一个硬件的 USB SLAVE（可以是由 OTG 支持的）， 这一驱动可以支持我们实现一个软件的 USB 串口；就像由 PL2303 或者 HM340 硬件实现的 USB Serial 一样。 只有 HOST 控制器是不行的。不管是对 HOST 侧的PC，还是我们添加 Gadget Serial 驱动支持的 PC，这条链路看起来都只是一个普通的串口连接。其源代码在 /drivers/usb/gadget/serial.c，另外还有文档 Documentation/usb/gadget_serial.txt。可自行阅读。（其实，谷歌的 ADB 工具和这个是差不多的东西，可能甚至只有驱动号不一样。）
具体应用时，我们并不需要做太多修改。。。只需要配置，编译就足够了。我把它编译成了 module，所以，需要在文件系统起来之后再做一次 modprobe。
至于 HOST 侧，据说是都不需要驱动的，但是，我在 Windows 上用的时候，还是安装了 gadget serial v2.4 的（据说不支持 64 位系统，未验证），UBUNTU 上即插即用。
无论在哪里做什么，只要坚持服务、创新、创造价值，其他的东西自然都会来的。
