|
|
这两个月在折腾“易语言 + 硬件”的小实验，主要是串口通讯和USB的入门。之前我一直把易语言当做做小工具的顺手家伙，真到跟硬件对接，才发现它既“够用”，也有不少容易踩坑的细节。这里把一路摸索的经历和思路写下来，给后来者避避坑。
先说串口。选择串口是因为简单稳定、
调试工具也一抓一大把。用易语言玩串口，核心是把握波特率、校验位、数据位、停止位这些参数的一致性。我一开始就踩了经典坑：板子默认115200-8-N-1，我在程序里手抖成了9600，表现就是“偶尔能读到几串乱码”。后来加了一个启动自检：先尝试多组常见波特率，收到有效包头再锁定，这样对不确定外设很友好。
数据收发的节奏也要讲究。很多人用
“收到事件就立刻读”的写法，结果把串口缓冲区当队列用，时序一乱就丢包。我后来改成双缓冲+状态机：中断/事件里只搬运字节到环形缓冲，业务线程按协议帧头、长度、校验去拼包，再丢给上层处理。这样既不阻塞，也方便做超时与重传。日志也别省，至少要把时间戳、端口号、方向(TX/RX)、帧摘要打出来，排查干扰和线材问题时非常直观。顺便一提，虚拟串口驱动质量参差不齐，遇到偶发断开，先换根数据线、换USB口、关掉省电策略，成功率能上去一大截。
协议上，能自定义就自定义清楚：固定包头+长度+CRC16 是最低限度。易语言里算CRC的模块很多，别盲信现成代码，拿标准用例过一遍。我还加了“固件版本/能力查询”的指令，程序启动先握手，拿到版本再决定启用哪些功能，避免“同名设备不同协议”的迷惑。
再说易语言这边的实现细节。很多朋友图省事，用“串口通讯支持库”里现成的例子直接改变量名就上，短期能跑，长期维护很痛。我更推荐把“设备协议”抽象成一个独立模块：输入是字节流，输出是结构体/记录；上层业务只关心“读到一条传感器数据”“写入一条配置指令”，不碰字节指针。这样做的好处是，换设备、改协议、加加密，都是替换同一层，不至于牵一发动全身。
USB 这块，入门难度比串口高半级。最容易下嘴的是 HID 设备，因为免驱，Windows 自带栈，易语言能用 WinAPI 直接枚举、打开、读写。不过 HID 的报告长度固定、带 Report ID，吞吐量也有限，做配置类、按钮类设备很舒服，想要大数据流就会憋屈。我踩过的坑：有些厂商自称“自定义 HID”，但其实报告描述符写得一团糟，Windows 能识别但读写花样异常。解决思路是先用 USBlyzer/USBPcap 抓一遍官方上位机的包，对照描述符确认 Report ID、IN/OUT 长度，再在易语言里严格对齐发送缓存。另外，记住 HID 走中断端点，轮询间隔别想当然，系统调度和电源策略都会影响时延。
如果要更通用，走 WinUSB（或 libusb）是条正路：你只要知道设备的 Vendor ID / Product ID、接口号和端点，就能直接收发 Bulk/Interrupt 传输。我当时做法是用 SetupAPI 找设备路径，再通过 WinUSB 初始化句柄，易语言调用外部 DLL 不难，但要小心指针与缓冲区长度的匹配，尤其是异步 IO 的 OVERLAPPED 结构。一个很实用的策略是：先写一个极小的 C 封装 DLL，把易语言不擅长的指针/结构体打包成“送入字节数组、返回字节数组”的函数，再在易语言侧专心做协议和 UI，开发效率会高很多。
USB 的稳定性
USB 的稳定性，核心在于“让上层对抖动免疫”。几条经验：
- 设备热插拔要当常态处理。易语言里用设备监听（SetupAPI 定时枚举或注册设备通知），发现路径变更就触发重连逻辑；重连别一股脑儿重置全局状态，尽量把未完成的业务请求做幂等或可重试。
- 传输分片与粘包心态要摆正。Bulk 传输层面没有“消息”概念，只有字节流，帧边界全靠你自己协议定义；在上层维持一个收包拼装器（帧头/长度/CRC/超时），不要指望一次 Read 就读到整帧。
- 超时和取消要一视同仁。异步读写（OVERLAPPED）一定配合取消/关闭句柄的收尾路径，避免界面卡死；UI 层给用户可感知的“正在连接/已断开/重试中”状态，别用静默失败。
- 供电与线材是隐形杀手。USB 集线器、细长数据线、笔记本节能 |
|
发表于 
微信公众号
官方抖音号