Modbus从站站点设计实战：寄存器地图与RTU协议栈要点

这台设备要在总线上给上位机提供数据，过来人第一句多半是：先拿一张寄存器表出来。这其实就是“站点设计”的核心工作。所谓站点，就是挂在总线上、可以被主站按地址访问的一个从机节点，它对外暴露什么数据、暴露在哪里、怎么响应读写，全都由设计者先定好。Modbus 本身协议帧不复杂，但真正让项目跑得顺不顺的，往往不是 CRC 算得对不对，而是站点地址空间这张地图画得好不好。

这篇文章是嵌入式系列的第三十篇，专门聊我在实际项目里怎么做 Modbus 从站站点设计。内容从四个数据区的划分讲起，依次覆盖寄存器地址规划、映射数据结构、RTU 协议栈实现要点、以及现场调试排错经验。适合刚接手 Modbus 从站开发的工程师，也适合给只写过“读取-响应”demo、但对地址空间设计没有系统思路的朋友做一个参考。

1. Modbus 站点设计，到底在“设计”什么？

1.1 从“裸设备”到“总线上的一台设备”

我习惯把一个 Modbus 站点理解成“一栋对外开了几扇窗户的房子”。主站看不见设备内部的寄存器、变量、结构体，它只能隔着窗户递纸条：我读你这个编号的窗口，或者我往这个编号的窗口塞一张纸条。站点设计，就是把设备内部的物理世界，翻译成窗户编号和窗户尺寸的一整套规则。

很多初学嵌入式的人写 Modbus 从站，最容易犯的错误是“先把协议栈跑起来，再考虑地址怎么安排”。结果往往是代码写完了，发现上位机要的地址和设备实际能给的地址对不上，或者新加一个测量点就得改一堆硬编码的判断逻辑。我做了几个项目之后就固定下来：先画寄存器表，再写协议栈，写代码只是把画好的表执行出来而已。

这里说的“站点”不只是一个地址号。它包含三个层次：物理层上，站点是 RS485 总线上的一个节点，有唯一的从站地址；协议层上，站点是对一组功能码、一段地址区间的响应者；应用层上，站点是设备状态和参数的统一出口。三个层次都要在设计阶段一起定，否则现场会东补西补。

1.2 四个数据区是站点的“对外窗口”

Modbus 协议规定，一个从站最多可以暴露四种数据对象。理解它们之间差异，是站点设计的第一步，也是最容易忽略的一步。下面这张表是我在方案文档里经常复用的：

为什么要分成四类？主要是历史原因加使用习惯。线圈和离散输入都是位量，分别对应“可被上位机控制的开关”和“设备侧只读的状态干接点”；输入寄存器偏向外部采集量，保持寄存器偏向设备内部参数。实际嵌入式项目里，我见过很多设备只用保持寄存器就实现了几乎所有功能，这在功能上没问题，但和现成的组态工程对接时会遇到麻烦，因为组态里有时会默认“温度走 3x 输入寄存器、参数走 4x 保持寄存器”。所以我的建议是：语义分清楚，四个区都留出空间，哪怕只读点位只有一两个，也要按对应区设计。

还有个关键知识点必须在这里铺开：0x、1x、3x、4x 这套数据区符号是 PLC 工程师的叫法，并不是 Modbus 协议报文里携带的内容。真正在报文中出现的是 16 位地址偏移量，范围 0x0000 ~ 0xFFFF。这带来一个巨大的坑：同样的地址偏移 0，在不同人的嘴里可以是 00001、10001、30001、40001。站点设计文档里如果只写“温度地址是 100”，那这个项目大概率会在联调时吵架。

2. 寄存器地图：决定整个站点的“数据边界”

2.1 编址差异一定要先理清

协议报文里的“寄存器地址”和组态软件里的“寄存器编号”，是两种互相纠缠又容易混淆的东西。组态里常见的“40001”表示保持寄存器第一个寄存器，“30001”表示输入寄存器第一个。而 Modbus PDU 里只有一个 16 位偏移量，偏移 0 通常对应 40001。换句话说，完整地址等于“数据区符号 + 偏移 + 1”，很多人的 +1 就加错在这里。

举个具体例子。我要读保持寄存器区偏移 0x0063（十进制 99）这个点位，上位机面板地址应该是 40100，而报文里功能码 03 后面跟的地址是 0x0063。如果我的嵌入式代码里正好有一个数组，下标 99 存的是这个变量，直接往下标 99 取值是没问题的；但如果我按“面板地址 40100 减去 40001 再减 1”得到 98，再取下标 98，那就偏了一位。

我踩过一次很深的坑：设备端明明按正确偏移响应，现场组态工程师却一直报读到的数据和设备的显示值对不上。后来发现他的组态点位表里用的是 4x 符号，地址从 40101 开始。原因就是他在做点位表时下意识把第一个寄存器的编号设成了 40101 而不是 40001。从那以后，我给出的站点文档里永远写两列：一列是“PDU 偏移（十六进制）”，一列是“PLC 完整地址（十进制）”。两边都能直接照抄，避免二次换算。

2.2 用结构体连续映射做站点内存布局

规划好地址空间之后，接下来要想的是：寄存器数据在设备端内存里以什么形态存在。我见过两种主流方案，一是“结构体连续映射”，二是“表驱动映射”。这两种方案我都会用，但绝大多数项目我会优先选结构体连续映射。

结构体连续映射的思路很简单：把站点对外暴露的数据，按寄存器间隔定义成一个固定布局的结构体，结构体的字节偏移除以 2，就是寄存器偏移。

typedef struct { uint16_t status; /* 偏移0：运行状态位 */ uint16_t fault_code; /* 偏移1：故障码 */ int16_t temperature; /* 偏移2：温度，单位0.1℃ */ uint16_t pressure[8]; /* 偏移3~10：八路压力值 */ uint32_t total_count; /* 偏移11~12：累计量 */ uint16_t config[16]; /* 偏移13~28：可配置参数 */ } device_map_t;

这种方法最大的好处是：读取连续寄存器时根本不需要逐项查表，直接算好目标偏移，按长度从结构体内存里拷出来就行，响应速度极快，代码也干净。但要注意，结构体字段必须按 2 字节边界设计，否则编译器一旦插入填充字节，寄存器偏移就全乱了。我一般禁止在这个结构体里出现 uint8_t 类型，宁可让它占 16 位。

真正让结构体映射变得有点麻烦的是字段宽度和字节序。Modbus 寄存器是 16 位无符号数，报文按大端传输。如果 MCU 是常见的小端 ARM 架构，结构体里的 uint32_t 在内存里是低字节在前，直接 memcpy 出去再打包进寄存器，字节序就会出错。这个问题放到下一节细说，它比地址偏移更容易让人一头雾水。

至于表驱动映射，适合变量分散、地址需要灵活拼凑的项目。它的核心是一张描述表，每个元素记录偏移量、数据类型、读写属性、缩放系数、指向变量的指针：

typedef struct { uint16_t offset; uint8_t type; /* 0:u16 1:s16 2:u32 3:f32 */ uint8_t attr; /* 0:只读 1:可写 */ float scale; void *ptr; } map_item_t;

这种方案好处是新增点位体现为“加一行表项”，地址还可以随意留空洞。坏处是块读场景下要逐条匹配表项再拼装帧，代码复杂度和 CPU 开销都会上升。所以我的实际选择标准是：数据点集中的设备用结构体连续映射；点位零散又有历史包袱、必须给上位机凑特定地址时，才用表驱动。

2.3 数据类型宽度与字节序，绕不开的硬骨头

Modbus 协议本身只定义了 16 位寄存器，32 位整数、浮点数这类数据都要靠多个寄存器拼接。拼接顺序是站点设计里最容易出事故的地方，没有之一。

先说 16 位。一个 uint16_t 或 int16_t 直接占用一个寄存器，协议规定高字节在前。也就是说，内存里如果存 0x1234，报文数据区应该依次是 0x12、0x34。这个约定清晰，基本不踩坑。

麻烦的是 32 位和浮点。以一个 float 或 uint32_t 的四个字节 A、B、C、D 为例，拆进两个 16 位寄存器时，常见排列就有这么几种：AB CD、CD AB、BA DC、DC BA。不同厂家的设备、不同组态软件，对“32 位数据在 Modbus 里的字序”理解完全可能不一样。我自己碰到过，同一个型号的仪表，说明书里写了一行“32 位数据按 CD AB 方式存放”，但现场组态工程师没看见这一行，默认用 AB CD 去解析，结果本来应该读出的 100.5 变成了某个人眼完全看不出规律的数字。

我的建议是：设备端统一采用“大端字节序 + 高字在前”，即 ABCD 排列，然后在站点文档的第一页用加粗大字写清楚。不要为了迁就某一家上位机去改设备端的字序，因为改字序只是临时解决问题，下一次换组态平台又会踩一遍。会去适配设备字序的上位机毕竟是少数，多数平台都允许配字节序，把文档递给组态工程师，让他按 ABCD 设置即可。

再讲一个很容易被忽视的坑：有符号 32 位负数。int32_t 拆成两个寄存器时，高位寄存器在负数情况下可能是 0xFFFF。有些简易主站脚本只把两个 16 位寄存器无脑拼接成 uint32，负数就变成了一个巨大正数。如果设备数据里可能有负数，文档里要写清楚“按有符号 32 位解析”，否则现场会看到一些非常无语的读数。

浮点数的处理我单独说一句：能用定点尽量用定点。温度 25.6℃，与其用 float 传，不如用 int16 传 256，再配一个“缩放系数 0.1”标注在寄存器表里。定点数没有字节序歧义，也便于现场用脚本验算。只有当业务确实需要很大动态范围的浮点数据时才用 IEEE754，而且要固定大小端再测试一遍。结构体连续映射如果直接放 float 字段，记得在打包到寄存器前做字节序转换，不能想当然地把内存原样发出去。

2.4 地址分区要留白，别把一个区间塞满

寄存器地址空间很大，但实际设计时很容易犯一个毛病：从偏移 0 开始有序地往下排点位，排到哪算哪。短期看没问题，等产品迭代到第二版、第三版时，新加的测量值就只能硬挤在原有地址之间，或者把后面整段地址往后挪。后者意味着之前部署出去的设备全部要更新上位机组态，代价极大。

我现在固定用分区策略。比如一个典型设备是这样的规划：

这种分区的优势不只是整洁，更重要的是隔离。实时数据和配置参数分开，主站扫描只读区间时就不用担心误写；版本信息单独一个区，现场排查固件问题时可以快速读出。保留区我一般要求从站对未实现的地址返回异常码 02，而不是静默忽略，这样主站工具就能直接提示“该地址不存在”，而不是一直读到重复数据或者超时。

预留空洞看起来浪费了地址，但这种浪费非常值得。我做过的一个设备刚开始只用了 0x0000 ~ 0x0020，后来增加了七个测量点、三段历史统计，全部落在 0x0021 ~ 0x00FF 的空洞里，旧上位机一点不用改。如果当初贪图“紧凑美观”，这七个点就把布局全部打乱了。这是站点设计最需要“忍住”的地方。

3. 串口 RTU 从站的协议栈实现要点

3.1 收帧状态机：别用阻塞式接收

地址空间设计好之后，就到了协议栈本身的实现。很多刚从裸机开发转过来的朋友，第一版代码喜欢这样：while 循环里等串口收到一个字节，收到后判断地址对不对，对的话继续等下一个字节，直到收满一帧。这种实现最大的问题，是任何一根线的干扰都会让程序卡在“等字节”的状态里，主循环里其他任务全部被拖死。

正确做法是把接收过程拆成状态机，配合一个帧结束定时器。常用的状态划分是：空闲态、接收态、帧完成态。

• 空闲态：串口来了第一个字节，进入接收态，启动帧定时器。
• 接收态：每个字节都存入环形缓冲区，同时刷新帧定时器。
• 帧完成态：帧定时器超时，或者 USART 空闲中断触发，表示一帧结束，进入处理流程。

这里要解释一下为什么要用“超时判定帧结束”。Modbus RTU 没有帧长度字段，帧长由功能码和参数决定，可以固定，也可以变化。协议标准规定，两个帧之间的间隔至少是 3.5 个字符时间，超过这个间隔就认为上一帧结束了。3.5 个字符时间怎么算？一个字符包括起始位 1 + 数据位 8 + 校验位 1 + 停止位 1，共 11 位。波特率 9600 时，3.5 × 11 / 9600 ≈ 4.01ms；波特率 19200 时约 2ms。

工程上我不会卡标准算出来的值，因为 MCU 主循环调度有抖动，取稍宽的值更稳。9600 波特率我常用 5ms，19200 用 3ms，115200 用 2ms。太短会把一个完整帧判成两段，太长则响应变慢。另外现在很多 MCU 的 USART 自带空闲检测中断，用空闲中断判定帧结束比定时器更省资源，配合 DMA 收帧时可以做到几乎不占 CPU。我自己项目里优先用空闲中断，没有这个外设时再用定时器方案。空闲中断还有个好处，它检测的是总线上的空闲状态，天然等价于“间隔超时”。

3.2 CRC 校验的工程选型

Modbus RTU 用的 CRC16 有固定算法，通常叫 CRC-16/MODBUS，参数是：多项式 0x8005，初始值 0xFFFF，输入输出都做反射，结果异或值 0x0000。工程实现上有位运算和查表两种常见做法。

位运算写的代码占空间小，任何 MCU 都能跑，但逐位循环速度慢。查表法要一张 256 项的 16 位表，占用 512 字节 Flash，换来的是一字节一步完成，速度大幅提升。对于从站这种“收到请求后要在很短时间里组织应答”的场景，我更推荐查表法，尤其是主频不高的 MCU 上，CRC 计算往往能占到响应时间的相当比例。

位运算核心代码很短：

uint16_t modbus_crc16(uint8_t *buf, uint16_t len) { uint16_t crc = 0xFFFF; while (len--) { crc ^= *buf++; for (uint8_t i = 0; i < 8; i++) { if (crc & 0x0001) { crc = (crc >> 1) ^ 0xA001; } else { crc >>= 1; } } } return crc; }

注意一个细节：发送 CRC 时是低字节在前。如果计算得到的 CRC 是 0x0BC4，那么报文末尾应该先发 0xC4，再发 0x0B。很多第一次调试的朋友在这里栽过跟头，主站一直报错，实际上只是高字节和低字节发反了。标准测试向量可以拿它验证：请求帧01 03 00 00 00 02，CRC 应当是C4 0B。

CRC 还有一个常见坑：计算范围。CRC 覆盖从站地址开始到最后一个数据字节，不包括 CRC 本身。应答帧组织完毕之后，把整段数据交给 CRC 函数计算，再把结果填到末尾。不要先把 CRC 位置占上全 0 再算，也不要顺手把别的 CRC16 算法（比如 xmodem、ccitt）拿过来套用，上位机端会永远报错，而你还觉得“我设备明明发了数据啊”。

3.3 功能码分发与异常应答

协议栈处理帧的主流程可以概括为“先过滤，后分发”。先判断地址是否匹配，CRC 对不对；再按功能码分发给对应处理函数。

void modbus_process(uint8_t *frame, uint16_t len) { uint8_t slave = frame[0]; if ((slave != dev_addr) && (slave != 0)) { return; /* 不是发给本机的帧，静默丢弃 */ } if (!crc16_ok(frame, len)) { return; /* CRC 错误，静默丢弃 */ } switch (frame[1]) { case 0x03: handle_read_holding(frame, len); break; case 0x04: handle_read_input(frame, len); break; case 0x06: handle_write_single(frame, len); break; case 0x10: handle_write_multiple(frame, len); break; case 0x01: handle_read_coil(frame, len); break; case 0x02: handle_read_discrete(frame, len); break; case 0x05: handle_write_single_coil(frame, len); break; case 0x0F: handle_write_multiple_coil(frame, len); break; default: send_exception(frame[1] | 0x80, 0x01); break; } }

从站的“三个不”要学会：地址不匹配不响应，CRC 错误不响应，广播帧不响应。这里说的静默丢弃，是指从站完全不往总线上发任何字节，因为总线上可能有别的从站在响应，你插嘴会扰乱整条链路。但如果功能码不支持，就要回异常帧，异常功能码在原功能码基础上加 0x80，异常码按情况填：

• 01：非法功能
• 02：非法数据地址，比如寄存器偏移越界或数量越界
• 03：非法数据值，比如写入的配置超出量程
• 04：从站设备故障，比如写 Flash 失败、固件处于升级状态

广播地址 0 要单独拎出来说。广播帧所有从站都要接收，处理写类功能码，但任何从站都不允许应答，连异常也不回。有些新手写了广播响应，结果总线上一堆从站同时发异常帧，总线直接冲突。站点设计时要明确：哪些写命令允许广播，哪些不允许。比如“恢复默认参数”这种命令适合广播，“单独校准某台设备”这种绝对不行。

写多寄存器还有一个容易忽略的性能陷阱：如果主站一次写 30 个寄存器，设备端边接收边逐个处理，耗时可能超过主站超时时间。稳妥做法是先整帧校验、再统一提交。先检查所有地址是否合法、所有数据值是否在范围内，全部通过后才一次性更新站点数据结构，任何一项不合法就返回对应异常码，不做部分写入。这样不会出现“前 20 个写进去了、后 10 个没写进去”的脏状态。

3.4 数据一致性：撕裂读与半更新状态

Modbus 协议本身没有数据一致性保障机制，主站可能在任意时刻读到你的站点数据。假设设备里有一个 int32_t 变量，采集任务正在更新它，主站同时发来读两个连续寄存器的请求。从站如果直接把结构体内存打包发出去，很可能第 1 个寄存器是新值的高字、第 2 个寄存器还是旧值的低字，拼出来的 32 位数完全错误。这种事偶发发生，现场排查极其闹心。

我的解决方案按项目级别从简单到复杂排：

第一级，也是最简单的一招：用双缓冲。采集任务先把数据整块写入影子缓冲区，全部写完后再快速 memcpy 到对外映射区。由于 memcpy 一个几十字节的结构体通常只要几微秒，主站请求即使此刻正好进来，也大概率能在完整数据上操作。但这不能百分之百保证不撞车，只能把概率降到很低。

第二级，在协议处理函数里加临界区。处理读请求时关中断，做完数据拷贝再开中断，这样能保证读取期间采集任务不会被调度。代价是关中断时间不能太长，几十字节的拷贝没什么问题。如果采集更新也发生在中断里，那就更需要这种方式。

第三级，从站点交互设计上规避。对于特别关键的 32 位参数，不要直接暴露原始寄存器，而是用“先写两个字，再触发提交”的方式。比如上位机先写数据影子寄存器 A、B，然后写一个“提交”寄存器，设备端在提交时一次性把 A、B 合成到正式变量里。这个模式适合配置类参数，能彻底避免写侧半个新值半个旧值的问题。

写 EEPROM / Flash 也是一致性问题的重灾区。每次写寄存器都立刻擦写 Flash 是不现实的，Flash 有寿命上限，而且擦写过程会阻塞主循环，直接导致总线响应超时。我常用的方案是：RAM 里的配置值立即更新并正常应答，后台延后 100ms 左右统一落盘。如果希望掉电也不丢，就加“脏标记 + 双备份区”，先写备份区再写主区，写坏了还能恢复。这个机制要写进站点设计文档里，否则现场会有人发现“断电后配置恢复默认了”然后误以为是硬件坏。

3.5 站点地址、RS485 总线与 Modbus TCP

站点地址的分配属于站点设计的一部分。地址 0 是广播地址，1~247 是有效地址，248~255 保留。很多设备的硬件上有拨码开关或者按键设置地址，固件上电时读取一次。拨码开关位数要规划好，常见 8 位拨码支持 1~247，但如果是二进制拨码，有些组合可能落在保留地址区间，文档里要提前圈出来。

RS485 总线上有一个隐蔽的坑：方向切换。收发器都有 DE/RE 方向控制引脚，发送结束后如果立刻把 DE 拉低，最后那个字节的停止位可能被切断，主站收到的帧就少了一个字节。正确做法是等最后一个字节完整发送完成，再延时至少 2 个字符时间后关闭发送方向。更省心的办法是用带自动方向控制的收发器芯片。

终端电阻的问题也值得提一句。RS485 总线规范要求在两端各接一个 120Ω 终端电阻，中间节点不接。室内短线不接电阻通常也能通信，但长线、强干扰环境不接就会偶发乱码。有些设计为了图省事，每块板子上都焊了 120Ω，节点一多，总线上的差分阻抗被压得很低，谁也发不出正确的电平。这些都是站点布局时就需要明确的硬件选项。

如果是 Modbus TCP 场景，站点概念还在，但侧重点变了。RTU 里的从站地址变成了 MBAP 头里的单元 ID，通常填 1。没有了 CRC，取而代之的是 MBAP 头里的长度字段，处理完成后要按长度正确截断。帧处理函数可以复用，但别忘了 TCP 连接是长连接，多条连接同时访问时，要保证应答帧里的事务 ID 与请求一致，否则上位机会把响应和请求配错。

4. 调试、踩坑与现场排错

4.1 调试工具与分层排查流程

Modbus 从站开发调试，我最常用的三件套是：串口助手、主站模拟工具、逻辑分析仪。串口助手抓原始十六进制字节，主要用于确认“主站到底发了什么”；主站模拟工具用来循环读、写指定地址，验证站点响应；逻辑分析仪测 RS485 的差分波形，用于排查物理层时序问题。

调试流程我习惯分层走。第一步看物理层，确认 A/B 线没接反、终端电阻合理、设备确实在发数据；第二步看帧层，把抓到的请求帧按协议格式拆解，检查地址、功能码、CRC；第三步看功能层，对照寄存器表逐地址读一遍，看哪些地址返回异常、哪些返回值不对。这三步做完，九成的问题都能定位。流程上一定不要跳步，比如一上来就怀疑“寄存器字节序不对”，结果其实是 RS485 的 A/B 线接反了，整个数据都是乱的。

自己写简易主站脚本也是好办法。用 Python 的串口库发一条01 03 00 00 00 02 C4 0B，然后看设备回什么。这个测试帧是固定的，CRC 我可以直接写死，不用在脚本里实现校验函数，排查设备问题时特别干净。等设备应答帧也验证无误后，再把整个 CRC 计算脚本补齐。

4.2 常见问题速查表与排查路径

现场排错时，一张问题速查表比反复读协议文档管用得多。我把这几年最常见的现象和原因整理成下面这张表：

排查路径有一个基本原则：从物理层往应用层一层一层排除。如果主站有时候能读到数据有时候读不到，优先怀疑总线时序，而不是去翻寄存器值。如果完全通数据，只是结果不对，再集中排查地址和字节序。现场最浪费时间的操作就是“看着现象乱试”，手里明明有抓包工具却不用，凭感觉猜。

我还习惯在固件里留一个“调试模式”。通过一个保留寄存器写入魔数开启，比如往 0x3E00 写 0xA55A，设备就在串口日志里打印收到的每一帧和 CRC 计算结果。现场没有上位机只有笔记本时，这个功能能把“看不见的通信问题”变成“明文日志问题”，排查效率翻倍。

4.3 设计层面避免踩坑的经验

做过的 Modbus 项目多了以后，我发现大多数故障不是协议栈 bug，而是站点设计时留下的隐患。这里分享几条我自己总结的设计经验。

第一，配置参数必须做范围检查。主站往一个“温度报警阈值”寄存器里写了个离谱值，设备未必马上出事故，但可能让现场保护逻辑永远不触发。我的设计习惯是：每个可写参数在映射表里附带最小值和最大值，写请求进来先校验，超范围就回异常码 03。不要“照单全收”，否则出了问题很难解释清楚。

第二，版本信息寄存器一定要有。设备型号、固件版本、Modbus 规约版本这三项应该随时可读。现场最痛苦的事情之一是“同一型号的两台设备，一台固件是 1.0，一台是 2.0，寄存器表含义已经变了”。如果没有版本寄存器，远程维护时只能靠人肉猜，这个坑我踩过，后来所有新设备都强制加上。

第三，恢复默认值之类的危险操作要用魔数确认。往寄存器里写个 1 就恢复全部默认参数，太容易被误触发了。我常用固定魔数如 0xA55A 作为触发条件，同时要求设备进入一个“待确认”状态，下一次写入特定确认码才真正执行。牺牲一点便利，换来整体安全，非常值得。

第四，产线测试时把 Modbus 通信检查脚本化。用自动化脚本连续读多个关键地址，检查应答值是否在合理区间，同时统计无响应次数。这个方法比人工点按钮靠谱得多，也能提前发现批次性的焊接问题，比如某一块板的终端电阻没贴好导致通信偶发失败。

回到站点设计本身。这些年我越来越觉得，Modbus 从站项目的隐性成本不在协议栈，在于和上位机工程师、现场维护人员之间的协作。你永远不知道对方会按文档里的哪个地址去组态，也想不到他会用哪种字节序去解析 32 位数据。把地址空间设计得规整、可解释、留有余地，把每个数据点的单位、缩放系数、读写属性都写清楚，再给版本信息留一段只读区，这套工作做完，协议栈反而变成最简单的那部分。这也是我给后来者最想传递的一句话：先把窗口开好，再谈怎么递东西。