串口编程那点事

是的，就聊串口编程那点事！

还有我编的那点小玩意……

.NET串口编程避坑指南4：SerialPort.GetPortNames() 在 Linux 下并不能返回所有“可用”的串口

SerialPort.GetPortNames() 在 Linux 上只做了“有限规则的设备枚举”，而不是“系统层面的有效串口发现”。这是一个极容易在跨平台时踩中的坑，而且非常隐蔽。一、现象：在 Linux 下，GetPortNames() 返回的串口不全在 Windows 上，大多数人对下面这段代码是高度信任的： var ports = SerialPort.GetPortNames(); 你期望它返回： COM1 COM3 COM5 迁移到 Linux 之后，你也自然会期望类似的效果，比如： /dev/ttyS0 /dev/ttyUSB0 /dev/ttyACM0 但现实往往是：明明系统里存在串口设备你手动 ls /dev/tty* 能看到甚至你用 minicom / screen 能连上 👉 SerialPort.GetPortNames() 却返回空数组，或者只返回一部分这在以下场景尤为常见： USB‑Serial 转接器工控机 / ARM Linux Docker / 容器环境非 root 用户运行程序二、为什么这是一个“必坑” 因为它违反了一个强烈的心理预期： “GetPortNames() 应该返回所有可用串口” 但在 Linux 上，这个假设是错的。而且这个错误不是偶发的，是设计层面的必然结果。三、根本原因：Linux 上不存在“串口列表”这一概念这是理解这个问题的关键。 1️⃣ Windows 的世界观在 Windows 中： ...

.NET串口编程避坑指南3：Linux 下多个 USB 转串口重启后顺序变化 —— ttyUSB0 并不属于任何一个固定接口

在 Windows 上做串口开发多年后，我理所当然地认为： “串口号一旦确定，就会一直对应同一个物理接口。” 直到在 Linux 上踩了一个让我困扰很久的坑。一、现象：重启后 ttyUSB0~3 顺序发生变化在一台 Linux 工控机上，我插了 4 根 MOXA USB 转串口线：分别插在 4 个固定 USB 口上程序中分别使用： /dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2 /dev/ttyUSB3 程序运行正常。但是—— ✅ 电脑一重启 ✅ 再启动程序发现串口对应的设备完全错乱。原本：物理口设备 USB 口 A ttyUSB0 USB 口 B ttyUSB1 USB 口 C ttyUSB2 USB 口 D ttyUSB3 重启后可能变成：物理口设备 USB 口 A ttyUSB2 USB 口 B ttyUSB0 USB 口 C ttyUSB3 USB 口 D ttyUSB1 没有规律。 ...

.NET串口编程避坑指南2：SerialPort.BaseStream.ReadAsync 是个假异步

结论先行：在 .NET 中，SerialPort.BaseStream.ReadAsync(...) 在很多情况下是一个“假异步”，它并不能被 CancellationToken 中断，甚至可能长时间阻塞线程。如果你是第一次踩到这个坑，恭喜你 —— 你已经进入了「开始读 BCL 源码」的阶段。一、问题现象：ReadAsync 为啥“卡住不动”？很多人都会写类似这样的代码： using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5)); await serialPort.BaseStream.ReadAsync(buffer, 0, buffer.Length, cts.Token); 直觉上你会认为： 5 秒没读到数据 CancellationToken 触发 ReadAsync 抛 OperationCanceledException 一切结束 ✅ 但现实是：串口没数据 await 一直等 token 已经 Cancel 了但 ReadAsync 毫无反应这就是很多人遇到的： ❗ ReadAsync “假死” / “不可取消” 问题二、真相：ReadAsync 默认实现只是“历史兼容层” 问题不在你代码，而在 .NET 对 Stream 的默认实现。我们先看 Stream.ReadAsync(byte[]) 的核心实现逻辑（简化后）： public virtual Task<int> ReadAsync( byte[] buffer, int offset, int count, CancellationToken cancellationToken) => cancellationToken.IsCancellationRequested ? Task.FromCanceled<int>(cancellationToken) : BeginEndReadAsync(buffer, offset, count); 关键点就在这里。 ...

.NET串口编程避坑指南1：USB串口意外拔出后，关闭端口为何会“僵死”？

作为嵌入式、工控或物联网开发者，你一定对这个场景不陌生：调试设备时用USB转串口连接PC，写好的.NET程序正在和设备通信，不小心碰掉了USB线，再想关闭程序时却发现窗口僵死、鼠标转圈——调用SerialPort.Close()的地方永远卡着不动，只能通过任务管理器强制结束进程。今天我们就来拆解这个经典的.NET串口编程坑，从问题重现、底层原因到解决方案，一次性讲透如何优雅应对USB串口的“突然失踪”。一、背景：USB转串口的普及与痛点如今消费级PC几乎取消了原生RS232串口，USB转串口（CH340、PL2303、FT232等芯片方案）成为连接嵌入式设备、工控模块、传感器的标配。但它的便利性也带来了新问题：调试场景下插拔频繁，设备连接状态极不稳定；工控现场可能因震动、接触不良导致设备意外断开；原生System.IO.Ports.SerialPort类对“设备突然消失”的异常处理存在底层缺陷，直接引发阻塞。二、问题重现：一行代码触发“僵死” 先看一段极简的.NET控制台程序，模拟最常见的串口操作流程： using System; using System.IO.Ports; namespace SerialPortBlockDemo { class Program { static void Main(string[] args) { // 替换为你的USB串口名称（如COM3、COM4） string targetPort = "COM3"; SerialPort serialPort = null; try { // 初始化并打开串口 serialPort = new SerialPort(targetPort, 9600, Parity.None, 8, StopBits.One); serialPort.Open(); Console.WriteLine($"✅ 串口 {targetPort} 已成功打开"); Console.WriteLine("⚠️ 请现在拔出USB转串口线，然后按任意键尝试关闭串口..."); Console.ReadKey(); // 关键：此处调用Close()会无限阻塞！ Console.WriteLine("🔄 正在尝试关闭串口..."); serialPort.Close(); Console.WriteLine("✅ 串口关闭成功"); } catch (Exception ex) { Console.WriteLine($"❌ 发生错误：{ex.Message}"); } finally { serialPort?.Dispose(); } Console.WriteLine("程序结束"); Console.ReadKey(); } } } 运行程序后按提示拔出USB线，再按任意键——你会发现程序永远停在“正在尝试关闭串口…”这一步，主线程彻底僵死。 ...