简介：面向Tina Linux嵌入式开发者的USB转串口通信实现方案已经过真机验证，尤其适配全志系列处理器，并可为其他支持Tina Linux的嵌入式平台提供参考。资源聚焦CH340、FTDI、PL2303等主流转串口芯片，从硬件接口建立到数据收发给出完整实现思路，压缩包共2个文件，包含一个C驱动示例与一份PDF实现指南，整体大小仅305KB，轻量且便于查阅。已有797人学习下载，适合需要快速解决USB转串口通信问题的嵌入式工程师与驱动开发初学者。通过驱动编译集成、修改kernel/configs配置启用对应模块并使用make重新编译内核、编写udev规则生成/dev/ttyUSB0设备节点并配置权限，以及调用open/write/read/close等串口API完成参数设置与数据读写，开发者可系统掌握从底层驱动到应用层通信的全部要点。同时涵盖dmesg内核日志排查、返回值检查等调试思路，能够有效避免连接失败、数据同步与硬件故障等常见问题。
1. 先说结论：Tina Linux 上 USB 转串口，一条从内核到应用的全链路活
在全志 Tina Linux 平台上做 USB 转串口通信，很多人第一反应是“插个 USB 转串口线，打开 /dev/ttyUSB0 就能收发”。实际动手就知道，这中间隔着内核驱动、设备节点、权限、串口参数四道关，任何一道没到位，表现都是“设备没反应”或“全是乱码”。这篇文章要拆的方案是一套已经在 Tina Linux 上完整验证过的实现路径：从内核开启 USB serial 驱动，到设备节点自动生成，再到用户态配置串口参数和实际收发测试，每一步都给出可抄的配置和验证方法，同时也把最容易让人翻车的几个坑单独列出来。
这套方法适合三类人：一是正在用全志 Tina Linux 做产品开发、需要接外接串口设备的工程师，比如调试蓝牙模块、读传感器数据、对接工业控制板；二是刚接触 Tina SDK、对内核配置还不熟的入门开发者，照着步骤走能省下不少试错时间；三是想弄明白 USB 转串口在 Linux 下完整工作链路的同学。文中的所有配置和命令都基于 Tina Linux 的 SDK 环境，芯片平台以全志系列为主，重点在链路本身，不绑定具体板卡型号——这正好也是这套方案能直接复现的原因。下面从驱动层开刀。
2. 驱动层配置：内核开启 USB serial 支持并烧录固件
2.1 驱动选型：CP210x、CH340、FTDI 各自在 Tina 上的差异
USB 转串口芯片的选型直接决定你要在内核配置里勾哪一项。Tina Linux 的 SDK 里已经包含主流芯片的驱动源码，路径在 kernel/drivers/usb/serial/ 下。我拆过的项目里最常见的是三类：Silicon Labs 的 CP210x、南京沁恒的 CH340（CH341）、FTDI 的 FT232。三者的驱动文件名分别是 cp210x.c、ch341.c、ftdi_sio.c，在 menuconfig 里对应的配置项也不一样。
| 芯片系列 | 内核配置项 | 常见型号 | 备注 |
|---|---|---|---|
| CP210x | CONFIG_USB_SERIAL_CP210X | CP2102/CP2104 | 最省心，驱动稳定 |
| CH340/CH341 | CONFIG_USB_SERIAL_CH341 | CH340G/CH341A | 国产低成本方案，注意兼容性 |
| FTDI | CONFIG_USB_SERIAL_FTDI_SIO | FT232RL/FT2232 | 老牌，但假货多 |
选型建议上，工业级应用优先 CP210x，抗干扰和驱动稳定性都更好；消费类或成本敏感项目用 CH340 没有问题，但要注意别买到打磨片；FTDI 虽然老牌，但市面上仿品太多，买到假芯片反而容易出玄学问题。确定芯片后再进内核配置，这一步错一个字母，后面就是白费功夫。
在 Tina SDK 里改内核配置有两个入口：一个是直接在 SDK 根目录跑 make kernel_menuconfig，这个命令打开的是内核自己的配置界面；另一个是在 SDK 主配置里通过 make menuconfig 进 Kernel 子菜单间接配置。我一般直接用前者，改动更精准，避免被 SDK 顶层的配置逻辑干扰。内核配置的修改最终会写进 board 相关目录下的 defconfig 文件，编译后固化到固件里，所以这一步的产出是烧录镜像。
2.2 menuconfig 内核配置：勾选 CONFIG_USB_SERIAL 及其子项
进入内核配置界面后，按路径找到 USB support 再进 USB Serial Converter support 子菜单，这里面就是所有 USB 转串口芯片的开关。我以 CP210x 为例讲完整的勾选清单，CH340 和 FTDI 的操作路径一样，只是勾选的项目名不同。
# 在 Tina SDK 根目录执行 make kernel_menuconfig进入界面后依次操作方向键：Device Drivers → USB support → USB Serial Converter support，确认以下项目状态为 [*]（编译进内核）而不是 [M]（编译成模块）。这一点非常重要，Tina 平台很多项目默认不会自动加载内核模块，做成 [M] 会导致开机后驱动不生效，设备节点压根不出现。
- <*> USB Serial Converter support —— 总开关，必须开启
- <*> USB CP210x family of controllers —— CP210x 芯片驱动
- <*> USB WinChipHead CH341 and CH340 —— CH340/CH341 驱动
- <*> USB FTDI Single Port Serial Driver —— FTDI 驱动
勾完后保存退出，内核 .config 文件里会多出这几行配置。确认的方法是把 .config 文件里的相关项 grep 出来看一眼：
# 在内核源码目录或 SDK 对应路径下 grep -E "CONFIG_USB_SERIAL_(CP210X|CH341|FTDI_SIO)" .config如果输出全是 =y，说明这三类芯片的驱动都已经编进内核。注意 CONFIG_USB_SERIAL_CH341 在部分内核版本里写作 CONFIG_USB_SERIAL_CH341，不会两个都出现，认准当前内核源码里的实际 Kconfig 定义为准。这一步完成后，真正的产出是配置生效，给下一步编译做准备。
2.3 编译烧录与启动日志确认驱动生效
内核配置改完成后，回到 SDK 根目录重新编译内核和打包固件。Tina SDK 的编译命令和路径在版本间有细微差异，常见做法是在 SDK 根目录执行 source build/envsetup.sh 后，用 lunch 选择目标平台，再执行 make 或 make -j8 编译整个镜像。如果只想快速验证驱动配置，可以单独编内核：
# Tina SDK 根目录 source build/envsetup.sh lunch # 选择你的全志平台配置 make kernel # 仅编译内核，验证配置 make # 完整打包固件编译完成后把烧录镜像（通常在 out/ 目录下）通过全志的烧录工具写入板卡。烧录完开机，用串口终端连上 Tina 系统的调试串口，重点看内核启动日志里有没有 USB 相关的枚举信息。插上 USB 转串口设备后，dmesg 输出里应该有类似下面的内容：
# 插入 USB 转串口设备后执行 dmesg | tail -50正常情况下你能看到 usb 1-1: new full-speed USB device number 2 加一行 cp210x 设备绑定的日志，比如 cp210x ttyUSB0: cp210x converter now attached to ttyUSB0。看到这两行，驱动层就通了。如果只有 USB 枚举日志而没有 cp210x 绑定日志，基本可以断定驱动没编进去，回头检查内核配置项。
3. 用户态设备节点：/dev/ttyUSBx 的从无到有
3.1 设备节点生成原理与确认方法
驱动绑定成功后，内核会通过 usbserial 核心自动创建设备节点，这个节点在用户态表现为 /dev/ttyUSB0、/dev/ttyUSB1 这种递增编号。节点由 devtmpfs 或 mdev 负责生成，Tina 平台默认用的是 devtmpfs，也就是说只要驱动探测成功，节点会自动出现，不需要手动 mknod。
确认节点是否生成，最直接的方法是插上设备后 ls /dev/ttyUSB*：
ls -l /dev/ttyUSB*正常输出形如 crw-rw---- 1 root dialout 188, 0 ... /dev/ttyUSB0，主设备号 188 是 usbserial 的固定主设备号，次设备号从 0 开始递增。如果 ls 不到节点，先不要急着怀疑硬件，大概率是驱动没加载。此时查一下驱动模块状态：
lsmod | grep usbserial cat /proc/devices | grep 188如果 /proc/devices 里没有 188 这个主设备号，说明 usbserial 核心根本没起来，回去查内核配置里的 USB Serial Converter support 总开关。这里要提一个 Tina 平台的常见情况：内核里驱动编译成模块（[M]）但根文件系统没有对应的模块加载逻辑，导致开机后驱动不生效。这也是我在 2.2 节强调必须编成 [*] 的原因——Tina 的模块加载机制在某些版本里比较弱，编进内核是最省事、最不容易出问题的做法。
3.2 权限设置与 udev 规则
设备节点生成了，但用户态程序往往打不开它。原因是节点默认属主是 root，所属组是 dialout，权限是 660，普通用户没有读写权限。实际项目里，设备节点通常由某个应用进程打开，比如通过 systemd 服务或自定义 init 脚本在 root 下运行，所以权限问题多数时候不突出。但如果你的应用是作为一个非 root 用户进程运行，就得处理权限。
常见做法是写一个 udev 规则，让特定芯片的节点自动设置权限。在 /etc/udev/rules.d/ 下新建一个规则文件，比如 99-usb-serial.rules，内容是：
# /etc/udev/rules.d/99-usb-serial.rules SUBSYSTEM=="tty", DRIVERS=="cp210x", MODE="0666" SUBSYSTEM=="tty", DRIVERS=="ch341", MODE="0666"保存后执行 udevadm control --reload-rules 让规则生效，重新插拔设备后节点权限就会变成 crw-rw-rw-。规则里用 DRIVERS 匹配芯片驱动名，比用 VID/PID 匹配更通用，因为同一驱动可能对应多个型号的芯片。如果你的产品里只有固定一种芯片，用 VID/PID 匹配更精确，需要先从系统里读出芯片的 VID/PID：
lsusb输出里形如 Bus 001 Device 002: ID 10c4:ea60 Silicon Labs CP210x UART Bridge 的字段中，10c4 是 VID，ea60 是 PID。用这个可以写更精确的规则，防止别的 USB 设备被误伤。
3.3 用 stty 初始化串口参数
节点有了、权限有了，接下来就是把波特率、数据位、停止位、校验位这些参数设到串口上。Tina Linux 自带的 busybox 里有 stty 命令，可以直接操作终端设备参数。这个环节最常见的问题是：应用层打开设备后读不到数据，就是因为串口参数没初始化而被某些驱动默认值干扰。
我一般会在应用启动前，先用 stty 做一次参数确认。标准配置是 115200 波特率、8 数据位、1 停止位、无校验、无硬件流控，对应命令：
stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb -crtscts参数里每个配置项都可以在 stty 的输出里再确认一遍：
stty -F /dev/ttyUSB0 -a输出里 speed 115200 baud; 这行确认波特率，cs8 表示 8 位数据，-cstopb 表示 1 位停止位，-parenb 表示无校验，-crtscts 表示关闭硬件流控。要注意的是，stty 设置的是当前打开这个设备的终端参数，如果应用在使用期间自己调用 tcsetattr 重新配置，那 stty 的设置会被覆盖。所以 stty 只适合快速调试验证，产品代码里还是应该在应用初始化时用 termios 接口设置参数，不要依赖外部命令。
4. 数据收发验证：回环测试确认收发通路完整
4.1 从 PC 端发，Tina 端读
驱动层和设备节点都确认没问题后，进入真正的数据收发验证。这是整个项目里最让人心里踏实的一步——看到数据从一端发出另一端收到，才算真正打通。最简单的验证方法是把 USB 转串口模块通过一根杜邦线把 TX 和 RX 短接，在 Tina 端自发自收，但这一步只验证了 Tina 侧链路；更完整的验证需要在 PC 和 Tina 之间双向对发。
PC 端用任意一款串口调试工具打开对应的 COM 口，Tina 端用 cat 命令挂到设备节点上读取：
cat /dev/ttyUSB0 &执行后 cat 进程阻塞在设备节点上等待数据。此时 PC 端串口工具发送一串测试文本，比如 hello tina usb serial。如果 Tina 端终端里立即打印出同样的文本，说明 PC → USB 模块 → Tina 内核 → 用户态读的整条下行链路是通的。这一步出问题的话，九成是 PC 端的 COM 口选错或波特率两边不一致，极少数是 USB 模块本身焊点虚。
4.2 从 Tina 端发，PC 端读
下行通了还要验证上行，也就是 Tina 端把数据发到 PC。最简单的方式是直接把一段文本 echo 到设备节点：
echo "hello pc from tina" > /dev/ttyUSB0PC 端串口工具应该收到这行文本。如果 PC 端什么都没收到，优先排查三处：第一，echo 命令有没有报错，报 Permission denied 说明权限没配好；第二，端口打开有没有被别占用，PC 端串口工具和别的调试终端同时打开同一 COM 口会冲突；第三，波特率一致性，这个最容易被忽视，两边标称 115200 但实际有误差时，短数据可能碰巧能通，长数据一多就断。
双向收发都通之后，可以做一次持续稳定性测试，比如用 PC 端工具每 100ms 发一条带序号的数据，Tina 端持续接收记录，观察有没有丢包。这个测试在量产阶段非常有用，能提前暴露 USB 供电不稳、杜邦线接触不良这类间歇性问题。
4.3 误码率与缓冲处理：为什么都是 115200 8N1
收发测试通了，很多人会问：为什么大家都在用 115200 8N1，而不是更高的波特率或更复杂的帧格式？这里有个容易被忽略的现实：USB 转串口本身是个桥接设备，芯片内部的 UART 控制器和 USB 控制器之间有一个缓冲区，数据从 USB 侧进来先暂存在缓冲区，再按串口时序从 UART 侧发出。波特率越高，单位时间内两侧的数据速率差就越明显，缓冲区溢出的概率越大。
Tina 平台上的 USB 转串口，驱动里通常自带 16 字节或更大的硬件 FIFO，配合内核的 tty 缓冲层，115200 8N1 这个配置下稳定性最好。更高波特率不是不行，比如 460800 或 921600，但受限于杜邦线材质、模块布局和地线质量，很容易出现字节丢失。也就是说，现实项目里能把 115200 跑稳，比把 921600 跑通但偶尔丢一个字节，更有实际价值。如果你的应用确实需要高波特率，建议把数据包设计得短一些，并在应用层加 CRC 校验，出错了重传，而不是盲目指望链路不丢。
5. 避坑记录：五个我实际踩过的 USB 转串口坑
5.1 现象一：lsusb 能看到芯片，但没有 /dev/ttyUSB0
插上 USB 转串口模块后，lsusb 里能看到芯片的 VID 和 PID，说明 USB 枚举成功了，但 ls /dev/ttyUSB* 什么都查不到。
原因：驱动没加载。Tina Linux 内核里 USB serial 驱动编译成了模块，但平台默认的模块加载机制没有自动加载，导致内核虽然枚举到了 USB 设备，却没有对应的串口驱动去绑定它。
解决：把 2.2 节里的配置项从 [M] 改成 [*]，让驱动直接编进内核。改完重新编译内核烧录固件，问题就消失。我在拆某跨平台系统时遇到过一模一样的情况，当时以为是芯片坏了，换了三块芯片无果，最后 grep .config 才发现驱动是模块。
5.2 现象二：能开设备但一配置波特率就失败
设备节点存在，open 也没报错，但一执行 stty -F /dev/ttyUSB0 9600 就报 Invalid argument。
原因：用户态对设备节点执行了 tcsetattr 设置波特率，但 tty 驱动返回错误，这通常是 USB 转串口芯片没有正确识别时钟源，或者驱动版本与芯片型号不完全匹配。CH340 在某些内核版本上出现过这类问题，表现为低速波特率比如 9600 配置失败，而 115200 反而正常。
解决：先确认内核里的 ch341 驱动是不是新的，去内核源码里看 drivers/usb/serial/ch341.c 是否支持你的芯片版本。另一个常见做法是在驱动源码里加上芯片的 VID/PID 到设备表里，重新编译。这个问题本质上就是芯片型号太杂，驱动表不完整，补上就好了。
5.3 现象三：收到数据是乱码
数据能收到，但内容对不上，PC 发 hello，Tina 这边收到的是乱码符号。
原因：波特率不一致，这个问题在调试串口和 USB 转串口同时插着的时候特别容易犯。板上调试串口是 1500000，USB 转串口是 115200，两边配混了就乱码。
解决：stty -F /dev/ttyUSB0 -a 先确认当前波特率，再和 PC 端工具核对。排除波特率后，检查 USB 模块的地线连接。USB 转串口模块的 GND 必须和目标板卡共地，否则 TX 和 RX 的电平参考点不一致，就会出现数据偶尔错位的乱码现象，这也是最常见误导性极强的问题。
5.4 现象四：插上即识别，但高波特率丢包
设备能识别，115200 下也正常，但把波特率调到 460800 或更高后，传输数据出现随机性丢字节，用示波器看 TX 波形也正常。
原因：USB 转串口模块的地线和供电质量在高波特率下暴露了问题。模块用杜邦线从板卡取电时，线太长或接触电阻大，瞬态电流不够，UART 时序就会偶发失真。这不是 Tina 系统的配置问题，是硬件链路问题。
解决：换短粗的杜邦线，模块电源单独从稳压输出引，不要和电机等大电流负载共用。还有一种做法是降低波特率，回到 115200，牺牲速率换稳定。在我接触过的量产项目里，USB 转串口长期跑 921600 的很少，大多数最终都回到 115200 或 230400，这不是能力问题，是成本与稳定性的平衡。
5.5 现象五：换了芯片型号，同样配置却无法识别
项目开始用的是 CP2102，一切正常，后来因成本原因换成了 CH340，结果同样的电源配置和代码，插上后 dmesg 里连 USB 枚举都看不到。
原因：不是驱动问题，是硬件设计问题。CH340 的 VCC 引脚需要接一个去耦电容，有些方案还要在 D+ D- 上串电阻。换芯片时只换芯片没换电路，新芯片的电源引脚纹波过大导致 USB 枚举失败。
解决：对照新芯片的数据手册补全外围电路，CH340 的典型电路里 VCC 处接 0.1uF 去耦电容，TXD/RXD 引脚按芯片要求接上拉电阻。换芯片不是只改封装，整个外围电路都要跟着核对一遍。
6. 进阶玩法：多路 USB 转串口的设备固定与可靠性测试
6.1 用 udev 规则固定 ttyUSB 编号
产品里只接一个 USB 转串口模块时，/dev/ttyUSB0 的编号是稳定的，基本不用操心。但一旦接了两个或更多模块，拔插顺序一变，ttyUSB0 和 ttyUSB1 可能互换，这会直接导致应用打开错误的设备。解决办法是用 udev 规则按芯片的 VID/PID 结合物理端口位置创建固定别名。
先读取每个模块的 VID 和 PID：
udevadm info -a -n /dev/ttyUSB0 | grep -E "idVendor|idProduct"然后写一条规则，给特定 VID/PID 的芯片固定一个别名节点：
# /etc/udev/rules.d/99-usb-serial-alias.rules SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="tty_debug_module"规则保存后执行 udevadm control --reload-rules && udevadm trigger，重新插拔模块，/dev/tty_debug_module 这个固定别名就会出现。应用代码里直接打开这个别名，不管物理上是 ttyUSB0 还是 ttyUSB3，都不会串。这个方法在多传感器采集的板子上尤其有用，我一般调试阶段就会把规则的写成固定的，省得每次拔插都要重新确认设备号。
6.2 自测脚本与可靠性测试
方法验证完，最后给自己留一个测试脚本，每次改完内核或更新固件后快速回归一遍：
#!/bin/sh # /usr/bin/usb_serial_test.sh DEVICE="/dev/ttyUSB0" BAUD="115200" stty -F $DEVICE $BAUD cs8 -cstopb -parenb -crtscts # 自环测试：TX 与 RX 短接后自发自收 echo "test-$RANDOM" > $DEVICE sleep 0.1 timeout 1 cat $DEVICE把 TX 和 RX 用杜邦线短接后执行这个脚本，如果能在终端看到 test- 开头的字符串，说明驱动加载、节点生成、串口配置、数据收发整条链路都是通的。这个脚本成本极低，但每次改完内核心里都踏实。从那以后我每次改完 Tina 内核配置，都会强制先跑一遍这个自测，不通过就不往下走。这套流程看着简单，但正是它帮我挡住了后面无数次改配置带来的回归问题。希望帮到你。
本文还有配套的精品资源，点击获取
