1. 通信模式的核心概念与常见误区1.1 从一条对讲机指令说起很多刚接触网络编程或者嵌入式开发的朋友第一次看到“单工、半双工、全双工”这三个词的时候脑子里冒出来的画面往往是这样的单工就是只能一个人说话半双工就是两个人轮流说全双工就是两个人同时说。这个理解方向没错但如果你只停留在“两个人说话”这个层面后面遇到串口通信配置、网络协议选型、工业总线调试的时候大概率会踩坑。我举个实际场景。之前帮一个做智能硬件的团队排查问题他们的设备用RS-485总线连接了十几个传感器节点主控每隔200毫秒轮询一次。调试的时候发现只要两个节点同时上报数据总线上的数据就全乱了接收端收到的全是乱码。他们一开始怀疑是波特率不匹配换了三四种波特率都没用。后来我让他们把示波器接上一看波形就明白了——两个节点同时驱动总线信号叠加在一起电平直接乱了。这就是典型的半双工总线冲突问题节点没有做好发送使能控制把半双工当全双工用了。这个案例说明一个事通信模式不是书本上的理论分类它直接决定了你的硬件电路怎么设计、软件协议怎么写、总线仲裁怎么做。你选错了模式或者配置错了模式系统要么通信效率极低要么根本跑不起来。1.2 三个模式的定义与本质区别先把定义说清楚不然后面没法展开。单工指的是数据只能在一个方向上传输发送方永远是发送方接收方永远是接收方两者角色固定不能互换。典型的例子是传统的广播电视、红外遥控器、以及一些单向传感器。单工模式下通信双方不需要协商谁先发谁后发因为只有一方能发。半双工指的是数据可以在两个方向上传输但同一时刻只能有一个方向在传输。也就是说A能发给BB也能发给A但不能同时进行。对讲机就是最直观的例子你按下PTT键说话的时候对方只能听不能同时回话。半双工的核心特征是“方向可逆时间互斥”。全双工指的是数据可以同时双向传输A发给B的同时B也能发给A。电话通话就是全双工双方可以同时说话同时听。全双工的核心特征是“方向可逆时间重叠”。这三个模式的区别本质上就两个维度方向是否可逆时间是否重叠。单工是方向不可逆半双工是方向可逆但时间不重叠全双工是方向可逆且时间重叠。但这里有一个常见的误区需要澄清很多人以为全双工就是“更快”半双工就是“更慢”。这个理解是片面的。全双工的带宽利用率确实更高因为它不需要切换方向但全双工对硬件的要求也更高——你需要独立的发送通道和接收通道比如以太网的双绞线里有两对线一对发一对收。而半双工只需要一对线成本更低在工业现场总线和一些低速场景里反而更常见。还有一个误区是认为“半双工就是落后的技术”。实际上很多现代协议仍然采用半双工或者半双工变体比如CAN总线、RS-485、以及无线通信里的CSMA/CA机制。选择哪种模式取决于你的应用场景对成本、距离、抗干扰能力、实时性的综合要求而不是简单地追求“全双工”。1.3 为什么这三个概念容易混淆我观察下来混淆主要来自三个地方。第一是物理层和协议层的混淆。比如RS-485在物理层是半双工的但你可以在上面跑全双工的协议吗不行因为物理层只有一对差分线同一时刻只能有一个方向。但RS-422物理层是四线制收发分开就可以支持全双工。很多人只看协议文档不看硬件手册结果配置错了。第二是“逻辑全双工”和“物理全双工”的混淆。比如某些无线模块标称支持全双工但实际上是通过时分复用实现的——快速切换收发方向让你感觉像是同时进行。这种“伪全双工”在低速率下没问题但在高速率或者低延迟要求的场景下就会暴露问题。第三是软件抽象层的混淆。比如TCP协议是面向连接的、可靠的、全双工的但TCP跑在什么物理介质上物理介质支持什么模式这是两回事。你可以在半双工的RS-485上跑TCP吗理论上可以但需要额外的协议转换和缓冲机制实际很少这么干。提示判断一个通信链路到底是什么模式不要只看协议名称要同时看物理层硬件、数据链路层仲裁机制、以及应用层的收发逻辑。三者一致才是真正的对应模式。2. 单工模式最简单也最容易被忽视的场景2.1 单工模式的典型应用与硬件实现单工模式听起来很简单但在实际工程里它的应用范围比你想象的要广。最常见的单工场景包括红外遥控器、无线广播、GPS模块输出、某些类型的传感器比如温度传感器只发不收、以及打印机的单向数据接收。以红外遥控器为例遥控器里的MCU通过红外LED发送编码信号电视里的接收头解调后送给主控。整个链路里遥控器只发电视只收方向永远不变。这种设计的优势是成本极低——遥控器不需要接收头电视不需要发射管双方硬件都简化了。再比如GPS模块它通过串口持续输出NMEA语句主控只需要接收解析不需要向GPS模块发送任何数据除非你要配置模块参数但那是另一个通道或者配置模式。这种场景下单工就足够了。硬件实现上单工模式最简单。你只需要一个发送器和一个接收器中间用一根信号线连接或者无线信道。不需要方向控制引脚不需要总线仲裁不需要冲突检测。代码层面也最简单发送方只管写接收方只管读没有状态机切换。但单工模式有一个隐含的风险你无法确认对方是否收到了数据。因为没有反向通道发送方不知道接收方是在正常工作还是已经挂了。所以在可靠性要求高的场景里单工往往需要配合其他机制比如定期的人工检查、或者额外的状态指示。2.2 单工模式下的数据完整性保障既然单工没有反向通道那怎么保证数据完整性这是很多新手会问的问题。答案是靠协议层的冗余和校验而不是靠重传。以GPS模块输出的NMEA语句为例每条语句末尾都有校验和。主控收到数据后先算校验和如果对不上就丢弃这条语句等下一周期的新数据。因为GPS模块是周期性输出的丢一条不影响整体定位下一周期就补上了。再比如红外遥控器它发送的编码里通常有引导码、地址码、数据码、以及数据码的反码。接收端通过比对数据码和反码来判断是否接收正确。如果不对就丢弃这次按键等用户再按一次。这种机制不需要反向通道靠冗余编码就能达到可接受的可靠性。注意单工模式下如果你需要确认机制就必须引入某种形式的反向通道哪怕是一个简单的GPIO信号或者指示灯。否则你永远不知道数据有没有到达。我在实际项目里遇到过一个问题某设备用单工方式通过无线模块上报数据现场运行了半年都没事突然有一天数据全断了。排查发现是接收端的天线接头氧化了信号变弱但发送端完全不知道还在拼命发。后来加了一个简单的机制——接收端每隔一段时间通过另一个通道比如4G模块上报一次心跳发送端如果连续几个周期没收到心跳就触发告警。这个心跳通道是独立的不影响原来的单工数据链路。2.3 单工模式的选型建议与避坑指南什么时候该用单工我的经验是当你的应用满足以下所有条件时单工是最优解——数据流向固定、不需要确认机制、成本敏感、或者反向通道会带来额外复杂度。但如果你满足以下任一条件就不要用单工需要确认数据到达、需要动态配置参数、需要双向交互、或者链路可靠性无法通过冗余编码保证。避坑指南第一条不要因为“简单”就无脑选单工。我见过一个项目本来用单工红外传输后来产品经理要求加一个“遥控器寻找”功能——按一下遥控器电视响一声。这就需要一个反向通道了但硬件已经定型改不了。最后只能加一个额外的无线模块成本反而更高。避坑指南第二条单工链路的调试要特别注意信号质量。因为没有反向通道你无法通过软件判断链路是否正常。必须用示波器或者逻辑分析仪看波形确认信号幅度、边沿、噪声余量都满足要求。特别是长距离单工传输比如RS-232单向传输线缆电容会导致边沿变缓接收端可能误判。避坑指南第三条单工模式下的数据格式要设计得足够健壮。建议包含帧头、长度、数据、校验、帧尾。帧头用于同步长度用于判断边界校验用于检错帧尾用于确认完整。不要只发裸数据否则一旦丢一个字节后面全乱。3. 半双工模式方向切换的艺术与陷阱3.1 半双工的核心机制方向控制与总线仲裁半双工的核心就两个字切换。A要发数据的时候把方向切到发送发完了切回接收等B回复。B也一样。这个切换动作在硬件上通常通过一个方向控制引脚比如RS-485的DE/RE引脚来实现在软件上通过读写寄存器的顺序来控制。但切换不是随便切的它涉及两个关键问题什么时候切以及切的时候会不会冲突。先说什么时候切。以RS-485为例发送前要把DE置高使能发送器发送完成后要等最后一个字节的停止位完全移出移位寄存器才能把DE置低。如果你提前置低最后一个字节可能只发了一半接收端收到的是残帧。这个等待时间怎么算假设波特率是9600一个字节10位1起始8数据1停止传输时间是10/9600≈1.04毫秒。你至少要在发送完最后一个字节后等1.04毫秒才能切回接收。实际工程里通常等1.5到2个字节时间留足余量。再说冲突。半双工总线上如果有多个节点必须有一套仲裁机制来决定谁先发。RS-485本身没有仲裁机制所以通常采用主从模式——主节点轮询从节点只有在被问到的时候才回复。CAN总线则有非破坏性仲裁通过ID优先级来决定谁先发。无线通信里的CSMA/CA则是先监听信道空闲才发冲突了退避重试。提示半双工总线的方向切换时间是一个关键参数。切换太慢吞吐量上不去切换太快数据可能丢失。建议用示波器同时抓方向控制引脚和总线波形确认切换时机。3.2 RS-485半双工实战从电路到代码RS-485是半双工最典型的应用场景。我拿一个实际项目来拆解从电路设计到代码实现把每个环节说清楚。电路部分RS-485收发器比如常见的MAX485或者国产替代有几个关键引脚RO接收输出、DI发送输入、DE发送使能高有效、RE接收使能低有效。通常把DE和RE接在一起用一个GPIO控制。GPIO高的时候发送使能接收禁用GPIO低的时候发送禁用接收使能。总线两端需要接终端电阻通常是120欧姆。这个电阻的作用是匹配线缆特性阻抗消除信号反射。如果线缆很短比如小于10米可以不接但如果线缆较长或者波特率较高不接终端电阻会导致波形振铃接收端误判。代码部分以常见的嵌入式开发为例发送一个字节序列的流程是这样的// 假设GPIO_DE_RE控制方向1为发送0为接收 void rs485_send(uint8_t *data, uint16_t len) { GPIO_SetHigh(GPIO_DE_RE); // 切换到发送 delay_us(10); // 等待收发器稳定 for (uint16_t i 0; i len; i) { UART_SendByte(data[i]); } while (!UART_TxComplete()); // 等待最后一个字节移出 delay_us(100); // 额外等待确保总线释放 GPIO_SetLow(GPIO_DE_RE); // 切回接收 }这段代码里有几个细节值得说。第一切换方向后要加一个小延时让收发器内部电路稳定。第二发送完成后要等UART的发送完成标志不能只等发送寄存器空。第三切回接收前再加一点延时确保总线上的最后一个停止位已经完全结束。接收部分相对简单因为默认就是接收状态。但要注意如果总线上有多个节点接收中断里要判断地址只处理发给自己的数据。3.3 半双工模式的效率瓶颈与优化思路半双工的效率瓶颈主要来自方向切换的开销。每次切换都要等待收发器稳定、等待最后一个字节发完、等待总线释放。这些时间加起来在低速场景下可能占整个通信周期的很大比例。举个例子。假设波特率9600每次发送10个字节传输时间约10.4毫秒。方向切换开销假设是2毫秒包括稳定延时和等待时间。那么有效数据传输时间占比是10.4/(10.42)≈84%。如果每次只发2个字节传输时间2.08毫秒切换开销还是2毫秒有效占比就降到51%了。这就是为什么半双工协议通常倾向于批量传输——攒一批数据一起发减少切换次数。优化思路有几个方向。第一增大单次传输的数据量把多个小包合并成一个大包。第二提高波特率减少传输时间但切换开销不变所以占比会改善。第三优化切换时序把不必要的延时去掉比如用硬件自动方向控制有些收发器支持自动切换。第四如果应用允许改用全双工物理层彻底消除切换开销。但要注意提高波特率会带来信号完整性问题。线缆越长波特率越高信号衰减和反射越严重。RS-485在1200米距离下通常只能跑到100kbps左右如果距离缩短到100米可以跑到1Mbps甚至更高。这个权衡要根据现场情况来定。4. 全双工模式同时收发的代价与收益4.1 全双工的物理层基础独立通道从哪来全双工的前提是物理层有独立的发送通道和接收通道。这个“独立”可以体现在不同的维度上。第一种是空间分离。比如RS-422用四根线两根发两根收收发各用一对差分线互不干扰。以太网的双绞线也是类似100BASE-TX用两对线一对发一对收。第二种是频率分离。比如某些无线通信采用频分双工FDD上行和下行用不同的频段同时工作互不干扰。第三种是时间分离但速度极快。比如某些高速串行链路通过极快的时分复用在微观上切换收发宏观上感觉是同时的。这种严格来说不算真正的全双工但在应用层看起来是一样的。第四种是回波抵消。比如电话线里的全双工通信发送和接收用同一对线但通过混合线圈和回波抵消电路把发送的信号从接收信号里减掉从而实现同时收发。这种技术复杂度最高但在某些场景下是唯一选择。注意全双工不等于“两根线”。RS-485是两根线半双工RS-422是四根线全双工。但以太网也是四根线两对全双工。关键不是线数而是收发通道是否独立。4.2 TCP全双工通信的编程实践在网络编程里TCP是全双工的典型代表。建立连接后双方可以同时发送和接收数据互不阻塞。但很多新手在写TCP代码的时候会不自觉地写成半双工的模式——发完请求等响应收到响应再发下一个请求。这种“请求-响应”模式虽然简单但没有发挥TCP全双工的优势。真正的全双工TCP编程应该把发送和接收放在独立的线程或者异步事件循环里。发送线程只管从发送队列取数据发出去接收线程只管从socket读数据放到接收队列。两个线程互不干扰可以同时工作。import socket import threading import queue class FullDuplexClient: def __init__(self, host, port): self.sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((host, port)) self.send_queue queue.Queue() self.recv_queue queue.Queue() self.running True def start(self): self.send_thread threading.Thread(targetself._send_loop) self.recv_thread threading.Thread(targetself._recv_loop) self.send_thread.start() self.recv_thread.start() def _send_loop(self): while self.running: try: data self.send_queue.get(timeout0.1) self.sock.sendall(data) except queue.Empty: continue def _recv_loop(self): while self.running: try: data self.sock.recv(4096) if not data: break self.recv_queue.put(data) except Exception: break这段代码的关键点是发送和接收完全解耦。发送方不需要等接收方回复接收方也不需要等发送方发完。这种模式在实时性要求高的场景里非常重要比如在线游戏、实时控制系统、视频会议等。但全双工也带来了新的问题流量控制和拥塞控制。如果发送方发得太快接收方处理不过来数据就会在接收缓冲区里堆积最终导致丢包或者内存溢出。TCP本身有滑动窗口机制来做流量控制但应用层也需要有自己的背压机制。比如接收队列超过一定长度时暂停发送或者降低发送速率。4.3 全双工模式下的资源竞争与同步问题全双工虽然收发独立但共享一些资源比如内存、CPU、以及应用层的状态。如果处理不好会出现资源竞争和数据不一致的问题。举个实际例子。某实时通信系统里发送线程和接收线程都要更新一个共享的连接状态结构体。发送线程发送成功后更新“最后发送时间”接收线程收到数据后更新“最后接收时间”。两个线程同时写这个结构体如果没有锁保护可能会出现写覆盖导致状态不一致。解决方案有两种。第一种是加锁用互斥锁保护共享结构体。但锁会带来性能开销在高频收发场景下可能成为瓶颈。第二种是无锁设计每个线程只写自己的字段读的时候用原子操作或者内存屏障保证可见性。比如“最后发送时间”只由发送线程写“最后接收时间”只由接收线程写其他线程只读。这样就不需要锁了。还有一种同步问题是应用层的请求-响应匹配。在全双工模式下你可能同时发出多个请求响应回来的顺序不一定和请求顺序一致。这时候需要给每个请求分配一个唯一ID响应里带上这个ID接收线程根据ID把响应分发给对应的请求处理逻辑。提示全双工编程的复杂度比半双工高一个量级。如果你的应用不需要同时收发或者收发频率很低用半双工模式反而更简单可靠。不要为了“先进”而强行上全双工。5. 四种模式在典型场景中的选型对比5.1 工业控制场景RS-485与CAN的取舍工业控制是半双工模式的主场。RS-485和CAN都是半双工总线但它们的适用场景有区别。RS-485成本极低收发器几毛钱线缆也便宜。它没有协议层只定义了物理层所以你可以跑Modbus、Profibus、或者自定义协议。缺点是没有任何仲裁机制多节点通信必须靠主从轮询效率较低。适合节点数量不多、实时性要求不极端的场景比如楼宇自动化、环境监测。CAN总线比RS-485复杂收发器贵一些但它有非破坏性仲裁机制多节点可以主动发送高优先级消息自动优先。CAN还有错误检测和自动重传机制可靠性更高。适合汽车电子、工业机器人、医疗设备等对实时性和可靠性要求高的场景。选型建议如果只是简单的数据采集节点少成本敏感选RS-485。如果需要多节点主动上报或者对实时性和可靠性要求高选CAN。如果距离很近比如板级通信可以用SPI或者I2C它们都是全双工的但距离通常不超过几十厘米。5.2 网络通信场景以太网全双工与半双工的自动协商以太网支持全双工和半双工两种模式通过自动协商机制来决定。自动协商的过程是双方发送快速链路脉冲FLP里面包含自己支持的模式列表然后取双方都支持的最高优先级模式。优先级顺序通常是1000M全双工 1000M半双工 100M全双工 100M半双工 10M全双工 10M半双工。也就是说全双工优先于半双工高速优先于低速。但自动协商有一个经典问题如果一端强制设为全双工另一端设为自动协商自动协商的那端会检测不到FLP于是降级到半双工。结果就是全双工端和半双工端互联产生大量冲突和CRC错误。这就是所谓的“双工不匹配”问题。注意以太网链路的两端要么都自动协商要么都强制设为相同的模式和速率。不要一端自动一端强制否则会出现双工不匹配导致性能急剧下降。排查双工不匹配的方法看交换机或者网卡的统计信息如果冲突计数collision或者CRC错误计数在快速增长而链路利用率并不高大概率就是双工不匹配。解决办法是把两端都改成自动协商或者都强制设为全双工相同速率。5.3 无线通信场景半双工为主全双工是例外无线通信绝大多数是半双工的因为无线电在同一频段同一时刻只能收或者发不能同时进行除非有特殊的双工器或者回波抵消技术。Wi-Fi、蓝牙、ZigBee、LoRa这些都是半双工。Wi-Fi的CSMA/CA机制就是典型的半双工仲裁发送前先监听信道空闲才发如果信道忙就退避一个随机时间再试。接收方收到数据后回一个ACK发送方收到ACK才知道发送成功。如果没有ACK就重传。真正的全双工无线通信目前还处于研究和早期商用阶段主要靠回波抵消或者天线隔离来实现。成本高、复杂度大主要用于基站等高端场景终端设备很少用。选型建议无线场景下默认按半双工来设计。如果你需要“同时收发”的效果可以通过协议设计来模拟比如时分复用或者频分复用。但物理层本质上还是半双工的。6. 实操中常见问题与排查技巧6.1 半双工总线冲突的排查与解决半双工总线冲突是最常见的问题表现是数据乱码、通信时断时续、或者完全不通。排查思路如下。第一步确认硬件。用示波器看总线波形正常空闲时应该是差分电压为0RS-485或者隐性电平CAN。如果空闲时波形就不对说明有节点一直在发送或者终端电阻不匹配。第二步确认方向控制。用逻辑分析仪同时抓方向控制引脚和总线波形看发送时方向是否正确切换发送完成后是否及时切回接收。如果方向切换太慢会导致总线冲突。第三步确认仲裁机制。如果是多节点总线检查是否有两个节点同时发送的情况。RS-485没有硬件仲裁必须靠软件保证同一时刻只有一个节点发送。CAN有硬件仲裁但也要检查ID优先级配置是否合理。第四步检查线缆和连接器。半双工总线对线缆质量敏感特别是长距离场景。检查线缆是否屏蔽、屏蔽层是否接地、连接器是否氧化、终端电阻是否匹配。常见问题速查表现象可能原因排查方法解决方案数据乱码总线冲突示波器看波形检查方向控制和仲裁通信时断时续终端电阻不匹配测量总线阻抗加装120欧姆终端电阻完全不通方向控制错误逻辑分析仪抓引脚修正方向切换时序距离短时正常长时异常信号衰减测量信号幅度降低波特率或加中继器多节点时异常单节点正常地址冲突检查节点地址配置确保地址唯一6.2 全双工链路的流量控制与背压处理全双工链路虽然收发独立但如果发送速率持续大于接收速率接收缓冲区最终会溢出。TCP有滑动窗口做流量控制但应用层也需要自己的背压机制。我常用的背压策略有三种。第一种是固定阈值接收队列超过一定长度时暂停发送或者降低发送频率。第二种是动态调整根据接收队列的增长速率动态调整发送速率。第三种是反馈信号接收方通过反向通道发送“暂停”或者“继续”信号发送方根据信号调整。以视频传输为例。发送方编码视频帧接收方解码播放。如果接收方解码速度跟不上缓冲区会堆积。这时候接收方可以发送一个“降低码率”的请求发送方收到后降低编码码率减少数据量。这就是RTCP反馈机制的基本思路。提示全双工链路的背压机制要在协议设计阶段就考虑进去不要等到上线后才发现缓冲区溢出。最简单的做法是给每个接收队列设一个上限超过上限就丢弃低优先级数据或者触发流控。6.3 模式误配导致的典型故障案例模式误配是实际工程中最隐蔽的问题之一。我整理了几个典型案例。案例一RS-485总线上的两个节点一个配置成半双工一个配置成全双工四线制。结果半双工节点发送时全双工节点也在发送总线冲突。排查了半天才发现是硬件跳线配错了。案例二以太网链路一端自动协商一端强制全双工。自动协商端降级到半双工导致冲突计数飙升。用户以为是网络拥塞换了交换机也没用。最后把两端都改成自动协商才解决。案例三某无线模块标称支持全双工实际是时分复用。在低速率下没问题速率提高后出现大量丢包。换成真正的半双工模式加上ACK重传机制反而稳定了。这些案例的共同点是问题不在代码逻辑而在模式配置。排查的时候要先确认物理层和链路层的模式是否匹配再去看应用层逻辑。7. 个人实操经验与建议7.1 选型时的三个优先原则根据我这些年的经验通信模式选型可以遵循三个优先原则。第一能用单工就不用半双工能用半双工就不用全双工。每增加一个方向复杂度就翻一倍。单工最简单半双工次之全双工最复杂。不要为了“先进”而过度设计。第二优先选择有硬件仲裁的协议。RS-485没有仲裁多节点通信全靠软件保证容易出问题。CAN有硬件仲裁可靠性高很多。如果场景允许优先选CAN或者类似的有仲裁机制的总线。第三优先选择成熟方案。RS-485、CAN、以太网都是经过几十年验证的成熟技术资料多、工具多、坑也被人踩过了。新兴技术虽然参数好看但实际部署中可能遇到各种意想不到的问题。7.2 调试工具与测量方法推荐调试通信问题工具很重要。我常用的工具组合是示波器、逻辑分析仪、协议分析仪。示波器用来看模拟波形确认信号幅度、边沿、噪声、反射。逻辑分析仪用来看数字时序确认方向控制、片选、时钟、数据的时序关系。协议分析仪用来看协议层解析帧结构、校验、地址、命令。对于RS-485和CAN还需要一个差分探头直接测量差分信号。普通单端探头测一根线看不到共模噪声和差分信号的完整情况。对于以太网可以用网络测试仪或者支持端口镜像的交换机抓包分析。Wireshark是必备工具可以解析各种协议看时序和重传。提示调试通信问题时先抓波形确认物理层正常再看协议层。物理层有问题协议层怎么调都没用。我见过太多人一上来就改代码结果发现是线缆接头松了。7.3 从项目经验中提炼的避坑清单最后整理一份避坑清单都是实际踩过的坑。半双工总线一定要加终端电阻除非线缆极短。不加终端电阻长距离通信必然出问题。方向切换后要加延时不要立刻收发。收发器需要时间稳定省这个延时会导致偶发错误。全双工不等于不会冲突。共享资源还是要加锁或者用无锁设计否则会出现数据竞争。自动协商不是万能的。关键链路建议强制配置避免协商出意外结果。无线通信默认按半双工设计。不要假设物理层能同时收发除非你确认过。单工链路要有冗余校验。没有反向通道只能靠协议层的校验和冗余来保证可靠性。模式配置要写进文档。硬件跳线、软件配置、协议参数都要记录清楚避免后人踩坑。调试时先抓波形再看协议最后改代码。顺序反了效率会低很多。这些经验看起来简单但每一条背后都有实际项目的教训。通信模式的选择和配置是嵌入式开发和网络编程的基本功基本功扎实了后面的事情才好办。
