FreeMODBUS：工业嵌入式通信的“静默引擎”——不靠堆资源，而靠精设计
你有没有遇到过这样的现场调试时刻：
PLC主站发来一串0x03读保持寄存器命令，你的MCU却始终没回响；
示波器上明明看到RS-485总线有数据流过，但FreeMODBUS日志里只打印出MB_EILLSTATE；
换了一块同型号开发板，TCP连接能建上，RTU却死在T3.5超时——连串口助手上都看不到任何接收中断触发。
这些不是玄学，而是FreeMODBUS在真实工业边缘设备中落地时最常撞上的“软性墙”。它不像Linux下的Modbus库那样有glibc兜底、有动态内存撑腰、有内核定时器保底；它运行在裸机或轻量RTOS之上，没有退路，每一步状态迁移、每一次寄存器访问、每一毫秒定时器抖动，都直通硬件本质。理解FreeMODBUS，本质上是在学习一套“用确定性对抗不确定性的嵌入式通信哲学”。
它为什么小？因为把所有“假设”都剥掉了
很多工程师第一次看FreeMODBUS源码，第一反应是：“这也能叫协议栈？”
没有面向对象封装，没有配置宏自动展开，没有YAML式协议描述文件——只有mb.c、mbrtu.c、mbtcp.c三个核心文件，外加一个必须由你亲手填满的port/目录。
它的“小”，不是功能阉割，而是主动拒绝一切平台假设：
- 它不假设你用FreeRTOS——所以
xMBPortEventPost()只是个函数指针，你传进来的可以是队列、信号量，甚至是一个全局标志位； - 它不假设你有硬件CRC外设——所以
vMBUtilCRC16()是纯查表+移位实现，兼容所有无CRC加速单元的Cortex-M0+/RISC-V E21； - 它不假设你用标准HAL库——
xMBPortSerialPutByte()只要求你把一个字节塞进UART发送寄存器，并在TXE中断里清零发送完成标志； - 它甚至不假设你用以太网——
xMBTCPPortRecv()只约定输入是一个void *pucBuffer, uint16_t usLength，至于这个buffer是从LwIP的pbuf拷贝来的，还是从自研TCP栈的ring buffer里取的，它一概不管。
这种“去假设化”设计，让FreeMODBUS在GD32F303上跑起来只需要：
- ROM：5.8KB（启用RTU+TCP+基础功能码）
- RAM：1.6KB（含256字节RX/TX缓冲区 + 寄存器映射表）
而代价是：你必须亲手把它和你的硬件缝在一起。这不是缺陷，是契约——它给你最小的代码体积，你给它最明确的硬件行为定义。
RTU帧边界：不是靠“等空闲”，而是靠“数沉默”
RS-485总线上的MODBUS RTU通信，最反直觉的一点是：帧头和帧尾根本不存在物理标识符。没有起始位之外的同步字，没有结束标记，全靠“线路沉默时间”来界定。
FreeMODBUS对此的实现，是一套极其克制的状态机：
// mbporttimer.c 中的核心逻辑（简化） static volatile uint8_t ucTimerStatus = TIMER_STOPPED; void vMBPortTimersEnable( uint8_t ucTimerMode ) { if( ucTimerMode == T
