第三章 通信协议入门：CAN总线基础、UART串口通信、以太网TCP/IP基础
各位同学，今天我们来聊聊半实物仿真里最核心的环节——通信协议。说实话，我见过太多项目在接口对接上翻车了。不是协议没选对，就是配置参数搞错了。嗯，这章咱们就把三种最常用的协议掰开揉碎讲清楚。
核心观点：半实物仿真的本质，就是让真实硬件和虚拟模型「说同一种语言」。通信协议就是这门语言的语法规则。
3.1 CAN总线基础——工业现场的老大哥
CAN总线，全称Controller Area Network。我在汽车电子项目里跟它打了十年交道。说白了，它就是为恶劣环境设计的「多路广播」通信系统。
为什么半实物仿真离不开CAN？
- 实时性高——消息优先级仲裁，不会卡死
- 抗干扰强——差分信号传输，工业现场随便用
- 节点多——一条总线挂110个设备没问题
我记得有一次在发动机台架测试中，现场电磁干扰特别大，RS485死活跑不稳。换成CAN之后，数据一次都没丢过。嗯，从那以后我对CAN就特别信任。
3.1.1 CAN帧结构
CAN报文分两种：标准帧（11位ID）和扩展帧（29位ID）。咱们做半实物仿真，大部分情况用标准帧就够了。
// CAN标准帧结构（我习惯这么记）
// 帧起始(1bit) + 仲裁场(12bit) + 控制场(6bit) + 数据场(0-8byte) + CRC(16bit) + 应答场(2bit) + 帧结束(7bit)
// 实际发送代码示例（基于SocketCAN）
struct can_frame frame;
frame.can_id = 0x123; // 11位ID
frame.can_dlc = 8; // 数据长度
frame.data[0] = 0x01; // 数据字节
// ... 填充数据
write(s, &frame, sizeof(frame)); // 发送个人经验：数据场最多8字节，别贪多。我见过有人硬塞9个字节进去，结果接收端死活解析不对。老老实实分两帧发，稳得很。
3.1.2 波特率与采样点
| 波特率 | 典型应用场景 | 我推荐采样点 |
|---|---|---|
| 125kbps | 设备诊断、低速传感器 | 87.5% |
| 250kbps | 工业控制、车载网络 | 87.5% |
| 500kbps | 动力系统、实时仿真 | 75% |
| 1Mbps | 高速数据采集 | 75% |
你想想看，采样点设不对，总线长度稍微长一点就出乱码。我曾经在一条50米的CAN总线上折腾了两天，最后发现是采样点从87.5%改到75%就全好了。
避坑指南：我曾经遇到过终端电阻忘接的情况。CAN总线两端必须各接一个120Ω电阻，少一个都不行。别问我怎么知道的——那次示波器一看，波形反射得一塌糊涂。
3.2 UART串口通信——简单但别轻视
UART，通用异步收发器。这玩意儿太基础了，以至于很多人觉得它「没什么好学的」。但我在项目里见过太多UART翻车的案例了。
UART的核心参数就三个：
- 波特率——双方必须一致，差一点就乱码
- 数据位——通常8位，偶尔7位（比如某些老设备）
- 停止位——1位或2位，看设备手册
// 典型的UART初始化配置（Linux下）
struct termios options;
tcgetattr(fd, &options);
cfsetispeed(&options, B115200); // 设置输入波特率
cfsetospeed(&options, B115200); // 设置输出波特率
options.c_cflag |= (CLOCAL | CREAD); // 启用接收
options.c_cflag &= ~PARENB; // 无校验
options.c_cflag &= ~CSTOPB; // 1位停止位
options.c_cflag &= ~CSIZE; // 清除数据位设置
options.c_cflag |= CS8; // 8位数据位
tcsetattr(fd, TCSANOW, &options); // 立即生效关键点：UART没有时钟线，全靠波特率对齐。所以两边晶振精度要够，否则跑久了就会累积误差。我建议用±1%以内的晶振。
3.2.1 流控制——用还是不用？
硬件流控制（RTS/CTS）在高速传输时很有用。但说实话，半实物仿真场景下我一般不用。为什么？因为多两根线就多两个故障点。而且很多仿真板卡的流控制引脚根本没接出来。
我建议的做法是：低速（115200以内）不用流控，高速（460800以上）必须用。中间档位看情况。
小技巧：调试UART时，先用示波器看TX脚有没有波形。我见过一半的UART问题都是「线没接对」或者「TX/RX接反了」。别笑，我自己就犯过这错。
3.3 以太网TCP/IP基础——灵活但复杂
以太网在半实物仿真里越来越流行。原因很简单：带宽大、距离远、生态好。但代价是协议栈复杂，实时性不好保证。
TCP vs UDP，怎么选？
| 特性 | TCP | UDP |
|---|---|---|
| 可靠性 | 有确认重传，可靠 | 无确认，可能丢包 |
| 实时性 | 较差（重传导致延迟抖动） | 好（无重传机制） |
| 适用场景 | 配置下发、数据记录 | 实时控制、高速数据流 |
我个人习惯：控制指令用UDP，日志和配置用TCP。你想想看，控制指令丢一包可能就出事故，但UDP至少延迟可控。TCP虽然可靠，但重传那一下可能就晚了。
3.3.1 Socket编程基础
// TCP服务端示例（简化版）
int server_fd = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in address;
address.sin_family = AF_INET;
address.sin_addr.s_addr = INADDR_ANY;
address.sin_port = htons(8080);
bind(server_fd, (struct sockaddr *)&address, sizeof(address));
listen(server_fd, 3);
// 接受客户端连接
int new_socket = accept(server_fd, (struct sockaddr *)&address, (socklen_t*)&addrlen);
read(new_socket, buffer, 1024); // 读取数据避坑指南：我曾经遇到过TCP粘包问题。发送端连续发了两次数据，接收端一次就读完了。解决方案很简单：自定义应用层协议，加上帧头和长度字段。别指望TCP帮你分帧，它只保证顺序，不保证边界。
3.3.2 实时性优化
半实物仿真对实时性要求高，标准TCP/IP协议栈不太够用。我常用的优化手段：
- 禁用Nagle算法——设置TCP_NODELAY，避免小包延迟发送
- 设置优先级——用SO_PRIORITY给仿真数据流提权
- 使用RAW Socket——绕过协议栈，直接操作以太网帧（慎用）
个人经验：如果实时性要求特别高（比如1ms周期），建议用UDP + 应用层ACK。我做过一个项目，用UDP在100Mbps以太网上实现了200μs的确定性延迟。当然，前提是网络不能太忙。
3.4 三种协议对比与选型建议
好了，三种协议都讲完了。咱们做个对比总结：
| 维度 | CAN | UART | 以太网 |
|---|---|---|---|
| 最大速率 | 1Mbps | 几Mbps（取决于硬件） | 100Mbps~10Gbps |
| 最大距离 | 40m@1Mbps | 15m（RS232） | 100m（铜缆） |
| 节点数 | 110个 | 2个（点对点） | 理论上无限 |
| 实时性 | 优秀（硬件仲裁） | 一般（无仲裁） | 较差（协议栈开销） |
| 抗干扰 | 优秀（差分信号） | 差（单端信号） | 良好（差分+变压器） |
| 开发难度 | 中等 | 简单 | 较复杂 |
我的选型建议：
- 汽车电子、工业控制 → CAN
- 简单传感器、调试接口 → UART
- 大数据量、跨平台互联 → 以太网
最后说一句：协议只是工具，别为了用而用。我见过有人用CAN传大文件，也见过用UDP做可靠传输。不是不行，但何必呢？选最合适的，别选最炫的。
嗯，这一章的内容就到这儿。三种协议各有千秋，关键是要理解它们的本质差异。下次你在半实物仿真项目里遇到通信问题，不妨回头看看这张决策树。
公众号:蓝海资料掘金营，微信deep3321