FT230XS串口转USB：Linux驱动、MTP与CBUS调试指南

简介：FT230XS UART to USB Driver 是面向嵌入式、工控与桌面软件开发者的串口通信驱动合集，针对采用 FT230XS 这颗高集成度 USB 转 UART 桥接芯片的硬件设备，解决主机与传统串行接口设备之间的数据互连与端口映射问题。压缩包共 30 个文件、约 1.59MB，以 10 个 dll 动态库、4 个 sys 驱动、4 个 lib 静态库和 3 个 exe 安装工具为主体，配合 2 个 inf 安装信息文件与 2 个 cat 数字签名文件，覆盖 32 位与 64 位 Windows 平台的驱动注册、签名校验与安装引导；另有头文件提供 API 函数声明，以及许可协议、使用须知等说明文档，便于开发者直接引用接口做二次开发或排查装不上、识别不到端口一类问题。目前已有 1505 人学习下载。驱动包兼顾 Windows 与 Linux 两种环境，前者可完成安装与虚拟串口配置，后者可结合 libftdi 等开源库调用，适合串口调试、固件烧录与设备联调时对照查阅。

1. FT230XS 串口转 USB：一颗 16 脚芯片为什么总占着调试口的位置

焊台边放着一块刚打样的控制板，4 pin 排针丝印着 GND、TX、RX、3V3，插上 USB 线，主机里多出/dev/ttyUSB0——这条链路中间那颗 SSOP-16 的小芯片，多半就是 FT230XS。它做的事很朴素：把 USB 2.0 全速设备的批量端点翻译成一路 UART 收发，波特率上限 3 Mbaud，带 RTS/CTS 硬件流控和几个可配置的 CBUS 引脚，配置参数存在片内 MTP 里，不需要外挂 EEPROM。对 linux 嵌入式项目来说，好处很直接：主线内核的ftdi_sio里已经登记了0x0403:0x6015这对 ID，插上就出节点，不依赖任何闭源驱动。这份串口转 USB 驱动资源要解决的，是让这条链路在板子上真正稳下来——枚举正常、参数对得上、换台机器不用重新折腾权限、高波特率下不丢字节。做底层调试、产线烧录、天天和 MCU 打交道的同学，照着后面几章能直接复现。

2. 链路拆开看：FT230XS 的端点、CBUS 与 Linux 驱动栈

很多人排查串口问题喜欢一上来就改波特率，改到最后发现是供电或者驱动匹配的事。把这条链路按「芯片侧—主机侧—板级侧」三段拆开，出问题时能快速定位到是哪一段，而不是在终端里反复试参数。

2.1 芯片这一侧：全速设备、一对批量端点与片内 MTP

FT230XS 在 USB 描述符里报的是厂商自定义类（bDeviceClass 0xFF），不是 CDC ACM。这个细节决定了后面所有的匹配逻辑：主机不是靠设备类来认它，而是靠 VID/PID 精确匹配。它跑 USB 2.0 全速 12 Mbps，批量端点最大包长 64 字节，数据方向上一进一出。真正的瓶颈在 UART 侧那 3 Mbaud，USB 全速带宽对一路串口来说完全够用，所以别指望换根更贵的线能提高吞吐上限。

配置存储是这颗芯片容易被误解的地方。FT230X 系列把参数放在片内 MTP 里，没有外挂 EEPROM 的引脚，所以工具里说的「烧 EEPROM」实际是擦写片内存储。字段包括 VID/PID、厂商与产品字符串、序列号、是否自供电、最大取电电流、CBUS 各引脚的功能分配。MTP 的擦写次数有限，不是无限次可写的，产线脚本里反复刷同一颗芯片是要付代价的——我的习惯是先在样片上把配置调稳，定型后再上批量。

还有一个隐藏行为值得知道：芯片往 USB 送数据时，每个 IN 包前面会附两个状态字节，一个带 modem 状态，一个带线路错误位（溢出、校验错、帧错误、断线）。驱动会剥掉这两字节，把纯数据交给 tty 层，错误位累加到 tty 的错误计数里。这意味着你在应用层看到的「数据突然少了几字节」，有可能不是丢包，而是芯片在 UART 侧就报了溢出——排查方向完全不同。

2.2 主机这一侧：ftdi_sio 怎么把 USB 变成 /dev/ttyUSBx

Linux 下这条链路走的是一套标准栈：USB 核心枚举设备，ftdi_sio用自己的 id 表去匹配 VID/PID，匹配成功后向 usb-serial 层注册，创建出/dev/ttyUSB0这样的字符设备，应用 open 之后 termios 里的波特率、数据位、流控再一路下发到芯片。老内核里它还挂在 usbserial 通用框架下面，新内核已经独立成单独的驱动，lsusb -t能直接看到绑定的驱动名。

这里有个常见误判：有人觉得内核自带的ftdi_sio性能不如厂商的 VCP 驱动，想换掉。实际经验恰好反过来——常规串口通信用ftdi_sio更省心，VCP 驱动额外装一个内核模块，反而多一层版本兼容问题，还容易和自带驱动抢设备。

另一条路是 libftdi。它走 libusb 直接操作端点，不经过 tty 层，好处是能随时改 CBUS 引脚状态、能做细粒度的 USB 传输控制、能拿到原始的状态字节；代价是设备被独占，ftdi_sio必须先 detach，minicom、pyserial这类基于 tty 的工具全部失效。选型上的分界线很清楚：只是收发串口数据，用ftdi_sio+ tty；要做引脚控制、CBUS 动态切换、或者需要看到每一包的状态位，才上 libftdi。

2.3 板级这一侧：供电、复位与 CBUS 的默认电平

硬件这一侧的坑往往比软件更隐蔽。FT230XS 内置 3.3V LDO，从3V3OUT引脚引出来，很多人顺手就拿它给整板供电。这个 LDO 的输出电流能力有限，只够带芯片自己和少量外围，拉一颗 MCU 加一颗无线模块，轻则枚举不稳定，重则上电瞬间电压塌陷、主机反复提示设备重新插入。正确做法是板子自供电，USB 的 VBUS 只做插入检测，不要和板上 3.3V 网络直接并联。

VCCIO 决定 IO 电平域。接 3.3V 的 MCU 就把 VCCIO 接 3.3V，接 1.8V 的低功耗主控就接对应电压。这一步接错不会立刻烧，但会出现「能收到数据、误码率随温度变化」这类玄学现象，非常难查。

RESET# 引脚建议保留上拉，必要时加 RC 延时，别直接悬空。CBUS 引脚在上电那一刻的电平取决于片内 MTP 里的配置，配置没写完之前状态是不确定的，所以任何用 CBUS 直接驱动功率器件（继电器、MOS 管栅极）的设计都该中间加一级缓冲，别让上电瞬间的毛刺替你按下开关。

3. Linux 下把设备跑起来：从枚举到 3 Mbaud 的完整操作

前面讲的都是判断依据，这一章落到命令和代码。整套流程我在不同板子上重复过很多次，顺序建议固定下来：先确认枚举，再定死串口参数，然后解决权限和设备名，最后才谈性能和延迟。跳过任何一步，后面都会以奇怪的形式找回来。

3.1 枚举、绑定与一次性能看懂的体检命令

插上设备先别急着开串口助手，用三条命令把状态摸清楚。

# 1) 设备有没有枚举出来：VID:PID 固定是 0403:6015 lsusb -d 0403:6015 # 2) 绑到了哪个驱动，正常应看到 ftdi_sio lsusb -t # 3) 内核日志里找关键行，正常会有 "now attached to ttyUSB0" dmesg | grep -Ei 'ftdi|ttyUSB' | tail -n 20 # 4) 节点是否生成，by-id 目录里带序列号，多设备时优先用它 ls -l /dev/ttyUSB* /dev/serial/by-id/ 2>/dev/null

逻辑说明：lsusb -d只按 VID/PID 过滤，如果这条命令没有输出，说明问题在枚举层——线材、供电、焊接，跟驱动无关，别往下查。lsusb -t输出的是树形结构，最后一列会显示Driver=ftdi_sio，没绑定驱动的话这里显示(none)。dmesg里最有价值的是 attach 那一行，它同时告诉你节点编号和驱动版本。/dev/serial/by-id/是按序列号生成的稳定软链，设备编号乱跳的问题从这一步开始就能规避。

参数说明：-d后面必须写成vid:pid的十六进制格式，不能省略前导零以外的任何一位。如果你的板子改过 PID，这里要换成改后的值，否则命令永远没输出。

3.2 用 termios 定死参数：波特率、流控、原始模式

串口参数不对，表现千奇百怪。用 pyserial 把每个参数显式写出来，比在图形工具里点勾选可靠得多。

import serial ser = serial.Serial( port="/dev/serial/by-id/usb-Demo_DebugBridge_DBG0001-if00-port0", baudrate=3_000_000, # 芯片上限 3 Mbaud，写更高会被静默近似 bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, timeout=0.05, # 读超时，避免阻塞到底 write_timeout=0.5, rtscts=True, # 硬件流控，对端真接了 RTS/CTS 才开 xonxoff=False, exclusive=True, # 独占打开，防止 minicom 同时抢 ) ser.reset_input_buffer() # 清掉上一次会话残留的数据 ser.write(b"\x55" * 64) # 交替位模式，方便示波器看波形 print(ser.read(64).hex()) ser.close()

逻辑说明：baudrate写 3000000 是芯片的物理上限，写 4000000 时 pyserial 不一定报错，但芯片内部会在分频器里取最接近的值，实际波特率就飘了，这类错误在示波器上一看便知，在终端里只会表现为偶发乱码。rtscts=True对应 termios 的CRTSCTS，只有对端确实接了 RTS/CTS 才有意义；如果对端没接，流控线悬空可能被当成「对方一直不允许发送」，结果就是数据卡死在缓冲里，这条坑后面还会细说。exclusive=True在 Linux 下走TIOCEXCL，能防止两个程序同时打开同一个节点互相踩数据。

不想写代码的时候，用stty对齐参数，尤其是raw这一项：

# 3 Mbaud、8N1、硬件流控、原始模式 stty -F /dev/ttyUSB0 3000000 cs8 -cstopb -parenb crtscts raw -echo # 打印当前配置，确认 -icanon -echo -opost 都生效了 stty -F /dev/ttyUSB0 -a

逻辑说明：raw会把行规程关掉，否则终端会做几件事——把0x0d翻译成0x0a、把0x11和0x13当作软件流控字符吞掉、把接收到的数据回显。跑二进制协议时，这几条任何一条生效都会让你怀疑人生，明明发送端没问题，接收端数据就是不对。

3.3 udev 规则：固定设备名与免 root 访问

插两块一样的板子，ttyUSB0和ttyUSB1每次上电顺序都可能变；再换个用户登录，又提示 Permission denied。这两个问题一次性解决掉。

# /etc/udev/rules.d/99-ft230xs.rules # 方案一：MTP 里写了唯一序列号，按序列号给固定名字 SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", \ ATTRS{serial}=="DBG0001", SYMLINK+="ttyDbg0", MODE="0660", GROUP="dialout" # 方案二：没写序列号（全是 00000000），退回按 USB 物理端口绑定 SUBSYSTEM=="tty", KERNELS=="1-1.2", SYMLINK+="ttyDbg1", MODE="0660", GROUP="dialout"

# 重新加载规则并触发，然后验证软链 sudo udevadm control --reload-rules sudo udevadm trigger --subsystem-match=tty udevadm info -a -n /dev/ttyUSB0 | grep -E 'serial|idVendor|KERNELS' ls -l /dev/ttyDbg0

逻辑说明：ATTRS会向上遍历父设备找属性，KERNELS匹配的是设备在 USB 树里的物理路径，两者语义不同。方案一依赖每颗芯片的序列号唯一——如果 MTP 里全是默认值，这条路走不通，只能用方案二。udevadm info -a是查属性树的正规手段，别靠猜字段名。

参数说明：MODE="0660"加GROUP="dialout"表示同组用户可读写；还要把当前用户加进这个组，sudo usermod -aG dialout $USER，然后重新登录才生效，只开一个新终端是不够的。规则文件名前面的数字决定加载顺序，99 表示尽量靠后，避免被其他规则覆盖。

3.4 libftdi 最小收发与 latency_timer 调优

需要绕开 tty 层、直接控制芯片的时候，libftdi 是更合适的入口。下面这段是最小可运行的收发示例。

#include <stdio.h> #include <string.h> #include <libftdi1/ftdi.h> int main(void) { struct ftdi_context *ftdi; unsigned char buf[64]; int ret; ftdi = ftdi_new(); if (!ftdi) return 1; /* 用序列号定位设备，比只给 VID/PID 稳，多设备时不会开错 */ ret = ftdi_usb_open_desc(ftdi, 0x0403, 0x6015, NULL, "DBG0001"); if (ret < 0) { fprintf(stderr, "open failed: %s\n", ftdi_get_error_string(ftdi)); return 2; } ftdi_set_baudrate(ftdi, 3000000); ftdi_set_line_property(ftdi, BITS_8, STOP_BIT_1, NONE); ftdi_tcioflush(ftdi); /* 清空芯片侧收发 FIFO，调试时必做 */ memset(buf, 0x55, sizeof(buf)); ftdi_write_data(ftdi, buf, sizeof(buf)); ret = ftdi_read_data(ftdi, buf, sizeof(buf)); printf("read %d bytes, first=0x%02x\n", ret, buf[0]); ftdi_usb_close(ftdi); ftdi_free(ftdi); return 0; }

编译命令是gcc demo.c -o demo -lftdi1。逻辑说明：ftdi_usb_open_desc的后两个参数分别是描述串和序列号，传 NULL 表示不限定；libftdi 在 Linux 下会自动 detach 已绑定的内核驱动，所以不用手动rmmod，但这也意味着设备打开期间 tty 节点不可用。ftdi_tcioflush清芯片 FIFO，不清的话第一次读很可能读到上一次会话的残留字节，调试初期容易误判成芯片有问题。ftdi_read_data返回 0 表示暂时没数据，负数才是错误。

延迟这块单独调，默认值会让小包数据很难受：

# 默认 16 ms，先看当前值 cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer # 低延迟场景压到 2 ms；CPU 很弱的板子别压到 1，USB 中断频率会上来 echo 2 | sudo tee /sys/bus/usb-serial/devices/ttyUSB0/latency_timer

参数说明：这个值是芯片把缓冲区数据推上 USB 前的最长等待时间，它不改变波特率，只影响「攒包」策略。16 ms 意味着一个 8 字节的小包最多可能在芯片里待 16 ms 才被主机看到，做交互式命令行或者主从问答协议时，延迟会稳定卡在十几毫秒，很难从协议层排查出来。这个设置重启后失效，要持久化就写进 udev 规则的RUN+=，别指望每次手动 echo。

4. 定制这颗桥：片内 MTP 改写与 CBUS 功能分配

同一颗芯片在不同项目里承担的角色并不一样：有的只需要一路干净串口，有的要用 CBUS 控制 RS485 方向，有的希望序列号唯一以便产线追踪。这些都能靠改写片内 MTP 一次做定，但顺序必须是先读、再改、再回读校验，跳步的代价往往是芯片被写成一个主机认不出的状态。

4.1 先读再改：ftdi_eeprom 的字段与含义

拿到板子第一件事不是写，是把原始配置读出来备份。

# 读出当前配置存盘，这就是你的回滚基线 sudo ftdi_eeprom --device 0x0403:0x6015 --read-eeprom ./ft230xs-backup.conf cat ./ft230xs-backup.conf

逻辑说明：不同的 ftdi_eeprom 版本对--device的支持不一样，如果这条命令报参数错误，就改用--serial指定序列号；再不行就把同类设备拔掉只留一颗，让工具自己找。备份文件别删，后面写坏了全靠它救。

关键字段的含义整理成一张表，改之前对照着看：

字段名在不同工具版本里略有出入，动手前用ftdi_eeprom --help对一遍，别照抄网上的配置模板。

4.2 写完必须回读校验，改 PID 后驱动要手动登记

配置改完最怕两件事：写进去了但没生效，或者写进去之后主机认不出。两条都要用回读来兜底。

# 1) 复制一份再改，原始备份永远不动 cp ./ft230xs-backup.conf ./ft230xs-custom.conf # 2) 编辑自定义配置，示例片段 # vendor_id=0x0403 # product_id=0x6100 # manufacturer="Demo" # product="DebugBridge" # serial="DBG0001" # self_powered=true # max_power=0 # cbus0=TXDEN # cbus1=RXLED # cbus2=TXLED # cbus3=PWREN # 3) 写入并回读 sudo ftdi_eeprom --device 0x0403:0x6015 --flash-eeprom ./ft230xs-custom.conf sudo ftdi_eeprom --device 0x0403:0x6100 --read-eeprom ./ft230xs-verify.conf # 4) 逐行比对，重点看 product_id、serial、cbus 几项 diff <(grep -v '^#' ./ft230xs-custom.conf) <(grep -v '^#' ./ft230xs-verify.conf)

逻辑说明：回读时设备已经是新 PID 了，--device要跟着换，否则工具找不到设备。diff只比有效行，注释行的差异不用管。如果 diff 输出不为空，先别插拔，重新写一次，写两次还对不上就说明 MTP 已经有问题，换一颗样片。

改了 PID 之后，lsusb能看到新 ID，但/dev下不会自动出现节点，因为ftdi_sio是静态 id 表，新 PID 不在里面。临时登记和持久化两种做法：

# 临时把新 ID 告诉驱动，重新插拔后生效，重启丢失 echo "0403 6100" | sudo tee /sys/bus/usb-serial/drivers/ftdi_sio/new_id # 持久化：写进模块参数，开机自动带上 # /etc/modprobe.d/ftdi_sio.conf options ftdi_sio vendor=0x0403 product=0x6100

参数说明：new_id的输入格式是vid pid，不带0x前缀；modprobe.d里的vendor和product是成对的数组参数，填多个 ID 就按顺序继续写。改完要sudo modprobe -r ftdi_sio && sudo modprobe ftdi_sio或者直接重启才能重新加载。

4.3 CBUS 做 TXDEN：RS485 半双工方向控制

半双工 RS485 最麻烦的是方向切换：发送时拉高收发器的 DE，发完立刻拉低。用 GPIO 控制，软件时序很难卡准最后一个停止位；把

本文还有配套的精品资源，点击获取