STM32移植FX3U兼容PLC：软元件、指令解释器与编程口通信

简介：这份 ZIP 包面向学习三菱 FX3U 系列 PLC 编程与仿真的开发者、嵌入式学习者及自动化方向学生，核心提供 FX3U V8.8 相关源码升级资料，并涉及 STM32 与仿三菱方案的结合，可用于理解指令逻辑、固件升级思路和软硬件协同调试。包内共 713 个文件，约 78.89MB，以 C 与 H 源文件为主体，辅以 O、D、CRF 等编译中间文件，另有 PDF 文档、SCHDOC 预览、HEX 固件及 Keil 工程配置等，便于按源码、文档和固件线索分层查阅。已有 1558 人学习下载，说明其在 PLC 学习社区中具备一定参考热度。资料包含升级版与基础版本痕迹，适合对照研究版本差异、梳理工程结构、通信实现与外设配置，并作为课程设计、原型验证和排错分析的辅助材料；也可借此熟悉嵌入式工程组织与现场调试思路，使用时需注意仅作学习参考并遵守版权与使用条款。

1. FX3U V8.8 源码包定位：STM32 上跑一套兼容指令系统

拿到这个包，第一件事不是编译，而是先看懂它到底是什么东西。它不是跑在 Windows 上的仿真软件，也不是一个带界面的梯形图编辑器，而是一套纯 C 实现的 FX3U 指令解释器，加上编程口通信栈和 STM32 侧的硬件抽象层，编译出来烧进板子，就是一台能接受上位机下载、能在线监控、能带动 IO 的仿三菱 FX3U 兼容控制器。它最适合两类人：一类是产线维保的工程师，手上有一堆按 FX3U 指令表写的老程序，想低成本做备件替换；另一类是想把 PLC 指令系统拆开看清楚内部结构的嵌入式开发者。边界得提前摆明：它做的是指令级兼容和编程口协议兼容，不涉及原厂主机的安全认证等级，也不涉及任何硬件级的可靠性背书，拿它上产线之前该做的隔离、浪涌、看门狗冗余一样都不能省。

包名里的 V8.8 是这份源码自己的迭代号，跟硬件版本无关。整个工程按层切得很干净：最底下是寄存器定义和启动文件，中间是软元件区、指令译码与执行引擎、定时器计数器子系统，最上面是编程口协议和参数掉电保存。这个分层对移植很友好，你只需要改最底下一层，中间那层逻辑几乎不用动。下面按实际动手顺序拆：先把地址算清楚，再谈指令怎么跑，然后是通信怎么对上，最后是那些不看就会翻车的地方。

2. 软元件与内存布局：先把 D/M/X/Y 的地址算清楚

2.1 位软元件与字软元件的编号规则

软元件的编号规则是移植阶段最容易埋雷的地方。FX3U 的 X 和 Y 是八进制编号，X0 到 X7 之后直接跳到 X10，这个 X10 在内存里排在第九位而不是第十位；M、S、T、C 是十进制编号；D 和 R 是十进制编号但上位机界面上有时按十六进制显示。这意味着上位机发过来的一个字符串 "X17"，你不能直接当十进制 17 处理，要按八进制解析成十进制 15。我在第一次移植时就是在这里翻的车：接在 X10 上的一个按钮，实际触发的是逻辑里 X8 的位置，排查了两个晚上才发现是编号进制问题。

FX3U 的点数上限也要按手册对齐，不能凭感觉开数组。X0 到 X367 是八进制编号，折算成十进制是 0 到 247，也就是 248 个点；M0 到 M7679 是通用辅助继电器，另外还有 M8000 往上的特殊继电器段单独开；D0 到 D7999 是通用数据寄存器，D8000 往上的特殊寄存器段也要单独切出来。这些数字如果不齐，程序里越界的访问不会报错，只会默默踩到旁边的变量上，表现出来就是玄学——某个定时器莫名跑飞，或者某个输出乱抖。

软元件	编号范围	进制	位宽	建议实现方式
X 输入	X0~X367	八进制	1 bit	位图数组，扫描头刷新
Y 输出	Y0~Y367	八进制	1 bit	位图数组，扫描尾刷新
M 辅助	M0~M7679	十进制	1 bit	位图数组
D 数据	D0~D7999	十进制	16 bit	uint16 数组
T 定时器	T0~T255	十进制	1 bit + 16 bit 当前值	状态位 + 时间戳
C 计数器	C0~C255	十进制	1 bit + 16/32 bit 当前值	状态位 + 计数寄存器

提示：特殊继电器和特殊寄存器不要塞进通用区一起开，单独开一块并加偏移宏。后面做在线监控回显特殊寄存器的时候会省很多事。

2.2 结构体落地：一份能直接编译的软元件区

软元件区是整个解释器的地基，写法直接决定了访问速度和越界安全。我一般不用裸指针到处飘，而是收进一个结构体，所有指令只通过结构体加宏来访问。这样后面加掉电保持、加在线监控快照、加双机热备镜像，都只需要动一处。

#include <stdint.h> #define FX_X_POINTS 248u /* X0~X367 八进制，折合 248 点 */ #define FX_Y_POINTS 248u #define FX_M_POINTS 7680u /* M0~M7679 通用区 */ #define FX_D_POINTS 8000u /* D0~D7999 通用数据寄存器 */ typedef struct { uint8_t x[FX_X_POINTS / 8u]; /* 输入映像区 */ uint8_t y[FX_Y_POINTS / 8u]; /* 输出映像区 */ uint8_t m[FX_M_POINTS / 8u]; /* 辅助继电器 */ uint16_t d[FX_D_POINTS]; /* 数据寄存器，字寻址 */ } fx_dev_t; extern fx_dev_t g_dev; /* 位访问宏：n 必须是已经折算成十进制的下标 */ #define FX_BIT_GET(arr, n) (((arr)[(n) >> 3] >> ((n) & 7u)) & 1u) #define FX_BIT_SET(arr, n) ((arr)[(n) >> 3] |= (uint8_t)(1u << ((n) & 7u))) #define FX_BIT_CLR(arr, n) ((arr)[(n) >> 3] &= (uint8_t)~(1u << ((n) & 7u))) /* 八进制字符串编号转十进制下标：X17 传 17，返回 15 */ static inline uint16_t fx_oct2idx(uint16_t oct) { return (uint16_t)(((oct / 1000u) % 10u) * 512u + ((oct / 100u) % 10u) * 64u + ((oct / 10u) % 10u) * 8u + (oct % 10u)); }

这段代码里有两个点值得展开。第一，位图数组用>> 3和& 7做索引，比用n / 8和n % 8更稳，编译器在任何优化等级下都会生成移位指令，不会引入除法库函数，在 M3 这种没有硬件除法的核上差别很明显。第二，fx_oct2idx的实参是「看起来像十进制」的八进制数，比如上位机发来 X367，你解析出的整数是 367，传进去要返回 247。这个函数必须只用在 X 和 Y 上，M 和 D 千万别乱调，否则 D100 会变成 64。

参数上还有一个容易忽略的：FX_D_POINTS开到 8000，单个结构体在 32 位机上大概占 17KB 左右，加上 X/Y/M 的位图不到 18KB。这个尺寸对 F103 的 48KB RAM 来说有点紧，如果你的用户程序还要开指令缓冲和通信缓冲，建议把 D 区裁到 2000 或 4000，特殊寄存器段按实际用到的部分单独映射。裁剪的时候把所有引用 D 区上限的地方统一走一个宏，别散落在各个指令实现里。

2.3 掉电保持与 Flash 落盘

D 区里有一部分是要掉电保持的，M 区里的保持型辅助继电器也一样。STM32 内部 Flash 的擦写寿命有限，写入策略直接决定这块板子能不能撑过一年。我见过最典型的翻车写法是每条 MOV 指令执行完都往 Flash 里刷一次，跑了半天就把扇区写穿了。

常见做法是双备份加魔数校验，两个扇区轮流写，写之前先算 CRC，读取时哪块 CRC 对就用哪块，两块都不对就回落到默认值并置一个故障标志。写入时机不要挂在指令执行上，而是挂在扫描周期的尾巴上，并且加两个门槛：D 区内容相对上次落盘有变化，且距上次落盘超过若干秒；或者检测到停机命令时强制落一次。

#define FX_KEEP_WORDS 512u #define FX_KEEP_MAGIC 0x46583355u /* 'FX3U' */ typedef struct { uint32_t magic; uint16_t d[FX_KEEP_WORDS]; /* 保持型 D 区镜像 */ uint16_t crc; } fx_keep_blk_t; /* 上电加载：先验魔数再验 CRC，两块都坏就走默认值 */ int fx_keep_load(void) { const fx_keep_blk_t *a = (const fx_keep_blk_t *)FLASH_KEEP_A_ADDR; const fx_keep_blk_t *b = (const fx_keep_blk_t *)FLASH_KEEP_B_ADDR; const fx_keep_blk_t *p = 0; if (a->magic == FX_KEEP_MAGIC && fx_crc16(a->d, FX_KEEP_WORDS) == a->crc) p = a; else if (b->magic == FX_KEEP_MAGIC && fx_crc16(b->d, FX_KEEP_WORDS) == b->crc) p = b; if (!p) { fx_keep_default(); return -1; } for (uint32_t i = 0; i < FX_KEEP_WORDS; i++) g_dev.d[i] = p->d[i]; return 0; }

逻辑说明：magic放在结构体最前面，是为了在结构体布局变化时快速判废，避免旧数据被当成新格式读进来。CRC 覆盖的是数据区而不是整个结构体，这样魔数本身损坏和内容损坏能分开判断。参数上FX_KEEP_WORDS要和你的保持区起始地址对齐，比如从 D200 开始保持 512 个字，那g_dev.d[i]的下标就要改成g_dev.d[200 + i]，这个偏移写错了不会报错，只会让保持区错位。

注意：STM32F1 的 Flash 擦除单位是页，写之前必须整页擦。两个扇区轮流写的时候，擦除动作会阻塞几十毫秒，这段时间扫描周期会被拉长，如果板子上有高速计数或脉冲输出在跑，务必在擦除前把相关输出冻结。

3. 指令解释器：指令表怎么译码、扫描周期怎么切

3.1 指令表编码与译码表设计

用户程序从上位机下载下来之后，是一串顺序码加指令码加操作数的数据。这份源码里的做法是先做一遍译码，把原始字节流转成固定长度的内部指令记录，再交给执行引擎跑。这样做的代价是多占一份内存，好处是执行阶段不用再做变长解析，扫描周期稳定，在线监控回显顺序号也方便。

typedef struct { uint16_t step; /* 原始顺序号，在线监控时按它回显 */ uint8_t op; /* 操作码，索引译码表 */ uint8_t flag; /* bit0 上升沿，bit1 下降沿，bit2 脉冲执行 */ uint16_t arg1; /* 软元件下标，已折算成十进制 */ uint16_t arg2; /* 常数或第二操作数 */ } fx_insn_t; typedef void (*fx_op_fn)(const fx_insn_t *ins); static const fx_op_fn g_op_tbl[OP_MAX] = { [OP_LD] = op_ld, [OP_LDI] = op_ldi, [OP_AND] = op_and, [OP_OUT] = op_out, [OP_MOV] = op_mov, [OP_ADD] = op_add, [OP_CMP] = op_cmp, [OP_ZRST]= op_zrst, }; void fx_exec_program(void) { uint32_t pc = 0; while (pc < g_prog_len) { const fx_insn_t *ins = &g_prog[pc]; if (ins->op < OP_MAX && g_op_tbl[ins->op]) g_op_tbl[ins->op](ins); pc = g_next_pc ? g_next_pc : (pc + 1); /* 跳转指令改写下一条 */ g_next_pc = 0; } }

逻辑说明：step保留原始顺序号很关键，上位机做在线监控时是按步号来请求的，如果你只存压缩后的下标，回显会对不上。flag里的上升沿和下降沿标记，在译码阶段就要算好，不要在执行阶段临时比较上一次的状态，否则每个指令都要额外存一份历史值，内存吃不消。

参数说明：arg1里存的是已经折算好的数组下标加区号，常见做法是把区号编码到高 4 位，比如0x1xxx表示 D 区、0x2xxx表示 M 区，低位是下标。这样op_mov里只需要一次分支就能知道该往哪个数组写。区号编码如果放错位置，表现是写入的数据跑到了另一个软元件上，而且不会越界报错，很难查。

译码表本身建议做成稀疏索引加默认空指针，未实现的操作码在执行时直接跳过并置一个诊断位，这样遇到不支持的指令不会让整个扫描卡死，你还能从诊断位里看出是哪一条没实现。

3.2 三阶段扫描与看门狗

扫描周期必须严格切成三段：采样输入、执行程序、刷新输出。这三段的顺序不能乱，也不能在执行中间穿插 IO 刷新。原因很简单：如果某条指令执行到一半去读了实时输入，同一次扫描里同一个输入点前后状态可能不一致，逻辑就会出现毛刺。

void fx_cycle(void) { uint32_t t0 = fx_us(); fx_read_inputs(); /* 物理输入 -> X 映像，只在扫描头做 */ fx_timer_tick(); /* 定时器按时间戳推进，不阻塞 */ fx_exec_program(); /* 逐条执行用户程序 */ fx_write_outputs(); /* Y 映像 -> 物理输出，只在扫描尾做 */ g_scan_us = fx_us() - t0; fx_wdt_feed(); /* 喂狗必须放在周期末尾，不能放中断里 */ }

逻辑说明：fx_timer_tick()放在执行程序之前，是为了让本次扫描里所有定时器触点看到的是同一个时间基准，避免同一条程序里前半段和后半段读到不同的定时器值。fx_wdt_feed()放在最后，是为了让程序跑飞或者死循环时看门狗能真正复位，如果放在定时器中断里喂，执行引擎卡死也照样喂狗，狗就白养了。

参数上g_scan_us要暴露给在线监控，上位机读扫描周期就是读它。这个值的抖动范围是判断程序负载的直接依据，一般要求在设定扫描周期的一半以内，超出就说明用户程序里存在长指令或者循环。

3.3 定时器、计数器、脉冲类指令的实现边界

定时器最容易写错。新手写法是在指令里 while 等，等够时间再往下走，这直接把扫描周期锁死。正确做法是用毫秒时间戳做非阻塞计时，扫描时比较当前时间和启动时间的差值。

/* T0~T199 按 100ms 基准，T200~T255 按 10ms 基准 */ void fx_timer_tick(void) { uint32_t now = fx_ms(); for (uint32_t i = 0; i < 256u; i++) { if (!g_t[i].run) continue; uint32_t base = (i < 200u) ? 100u : 10u; uint32_t ticks = (now - g_t[i].start) / base; g_t[i].cur = (uint16_t)ticks; if (ticks >= g_t[i].set) { g_t[i].done = 1; g_t[i].run = 0; } } }

参数说明：base是时间基准，100ms 和 10ms 两组要分开算，混在一起算会导致 T200 往后的定时器全部慢十倍。g_t[i].cur存的是已经过去的基准数，上位机读定时器当前值读的就是它。如果某条定时器指令被复位，run清掉、cur清零、done清零，三个状态必须同时清，漏一个就会出现「复位后仍然导通」的现象。

计数器走的是边沿检测，每个扫描周期比较一次输入条件，从 0 变 1 时加一。这里的关键是「上一次状态」要按计数器编号单独存，不能共用一份全局变量，否则两个计数器交替执行时会互相污染。

高速计数和脉冲输出这两块不建议用软件在扫描里做。STM32 的定时器有编码器模式和 PWM 加单脉冲模式，直接把 PLSY、PLSR 这类指令映射到硬件定时器上，扫描周期只负责读取计数结果和启动停止，精度能到纳秒级。如果用软件在扫描里翻转 IO 产生脉冲，扫描周期一抖动频率就跟着抖，带步进电机的时候会听出明显的顿挫，这个坑很典型。

4. 编程口通信：帧结构、RS422 接法与联调

4.1 帧结构与校验

编程口协议是这份源码里能直接决定「能不能跟现有上位机对上」的部分。典型帧由起始符、命令字节、数据段、结束符和两位 ASCII 校验和组成，校验和覆盖的是起始符之后、结束符之前的所有字节，取低 8 位转成两位十六进制。这个校验算法简单，但正因为简单，一旦算错范围就全盘错。

/* 组帧：stx + body + etx + 两位 ASCII 校验和 */ uint16_t fx_build_frame(const uint8_t *body, uint16_t len, uint8_t *out) { uint16_t sum = 0; uint16_t n = 0; out[n++] = 0x02; /* STX */ for (uint16_t i = 0; i < len; i++) { out[n++] = body[i]; sum += body[i]; } out[n++] = 0x03; /* ETX */ out[n++] = fx_hex_char((sum >> 4) & 0x0F); out[n++] = fx_hex_char(sum & 0x0F); return n; }

逻辑说明：sum只累加body，STX 和 ETX 都不参与，这是最容易写错的地方。校验和用大写还是小写十六进制，不同上位机容错程度不一样，稳妥做法是收的时候大小写都认，发的时候统一大写。fx_hex_char要处理 0 到 9 和 A 到 F 两段映射，写成查表比写成条件分支稳定。

参数上串口配置常见为 9600 波特率、7 位数据位、偶校验、1 位停止位。这个组合在 STM32 的 HAL 库里没有直接对应的枚举，得用 9 位数据字长加偶校验来实现，然后软件上把最高位剥掉。这一步如果不做，收到的字节最高位会一直置 1，解析出来全是乱码。

4.2 STM32 侧串口实现

逐字节中断收是新手最常见的写法，9600 波特率下每字节约 1ms 一次中断，看起来不重，但一帧几十个字节下来中断次数很可观，而且一旦主循环里有 Flash 擦除这种长阻塞，中断里没来得及取走的字节就被覆盖了。稳妥做法是 DMA 加空闲中断，收完一帧再交给协议层解析。

void fx_uart_init(void) { huart1.Instance = USART1; huart1.Init.BaudRate = 9600; huart1.Init.WordLength = UART_WORDLENGTH_9B; /* 7 数据位 + 1 校验位 */ huart1.Init.Parity = UART_PARITY_EVEN; huart1.Init.StopBits = UART_STOPBITS_1; huart1.Init.Mode = UART_MODE_TX_RX; huart1.Init.HwFlowCtl = UART_HWCONTROL_NONE; HAL_UART_Init(&huart1); /* DMA 循环接收，空闲中断触发帧结束判定 */ HAL_UART_Receive_DMA(&huart1, g_rx_buf, sizeof(g_rx_buf)); __HAL_UART_ENABLE_IT(&huart1, UART_IT_IDLE); }

逻辑说明：UART_WORDLENGTH_9B配UART_PARITY_EVEN，硬件实际发出的是 7 位数据加 1 位校验，正好对上 7E1。接收缓冲里每个字节的最高位是校验位残留，协议层解析前统一& 0x7F。空闲中断里用__HAL_UART_GET_FLAG判断后清标志，再把 DMA 剩余计数换算成已收长度，最后重启 DMA。

参数说明：g_rx_buf建议开到 256 字节以上，因为批量读软元件的响应帧会比较长，缓冲不够会截断。DMA 用循环模式的话，重启时要注意把读指针重置，否则第二帧会从中间开始读。这个细节不写对，表现是「第一帧正常，后面全乱」。

提示：RS422 是差分信号，A、B 两根线接反了也能收到数据，但误码率极高，表现出来的现象是「偶尔能通，大部分时候超时」。调试时先用示波器看差分波形幅度，别一上来就怀疑代码。

4.3 上位机联调验证

在板子还没接上位机之前，先用 PC 侧脚本把帧格式验一遍，能省掉大量来回烧录的时间。下面这段用 pyserial 组帧和解析，跑通之后再接真实上位机。

import serial def build(cmd: str, payload: str) -> bytes: body = (cmd + payload).encode("ascii") chk = sum(body) & 0xFF return b"\x02" + body + b"\x03" + f"{chk:02X}".encode("ascii") def parse(resp: bytes) -> str: assert resp[0] == 0x02, "缺 STX" assert resp[-3] == 0x03, "缺 ETX" body, chk = resp[1:-3], resp[-2:] assert int(chk, 16) == sum(body) & 0xFF, "校验和不匹配" return body.decode("ascii") if __name__ == "__main__": ser = serial.Serial("COM3", 9600, bytesize=7, parity="E", stopbits=1, timeout=1) ser.write(build("0", "D00000001")) # 读 D0 起 1 个字 print(parse(ser.read(64)))

逻辑说明：build里校验和只累加body，跟 C 侧实现保持一致，两边算法不一致是最常见的联调失败原因。parse先断长度再断标志位最后断校验和，这样出错时能直接定位是帧结构问题还是内容问题。

参数说明：bytesize=7和parity="E"必须跟板子上的串口配置一致，pyserial 支持 7 位数据位，这一点比很多串口助手强。timeout设 1 秒足够，设太长会让联调节奏变慢。读的长度给 64 字节是经验值，批量读响应一般不超过这个数。

5. 避坑与排查：五个把扫描周期和 IO 搞翻车的细节

5.1 IO 编号与扫描刷新类

现象：接在 X10 上的按钮，触发的是程序里 X8 的逻辑。原因：X 和 Y 是八进制编号，上位机下发的 "X10" 在内存里排第九位，代码里按十进制直接解析成 10，整体偏移了两位。 解决：所有来自上位机的 X/Y 编号统一走八进制转换函数，转换后再做边界检查。转换函数写完拿 X7、X10、X17、X367 四个值各测一遍，对得上再往下走。

现象：输出继电器有轻微抖动，接触器发出规律的哒哒声。原因：输出刷新写在了指令执行中间，同一次扫描里 Y 点被写了多次，物理输出跟着抖。 解决：把物理输出刷新严格挪到扫描末尾，执行阶段只改 Y 映像区。同时检查是否有指令直接操作了 GPIO，有的话全部改成操作映像区。

现象：扫描周期忽长忽短，最大能到设定值的五倍。原因：Flash 擦除、串口 DMA 重启、CRC 计算这几件事被放进了扫描周期里同步执行。 解决：把 Flash 落盘、CRC 计算搬到低优先级任务或者停机窗口里，扫描周期内只置标志。串口接收用 DMA 加中断，别在扫描里轮询等待。

5.2 通信、存储与复位类

现象：上位机在线监控读 D 区，数值比实际大 65536 倍。原因：32 位数据在 D 区里是由两个连续寄存器拼成的，低字在前高字在后，代码里把高低字顺序搞反了。 解决：统一约定低字在低地址，所有双字读写都走同一对宏，别在各个指令里各写一套。写完之后用 MOV D0 到 D10、D11 的方式验证一遍，看拼出来的是不是原值。

现象：板子断电重启后，保持型 D 区全部归零，但有时候又正常。原因：单块备份区写到一半掉电，整块数据损坏，加载时魔数和 CRC 都过不了，直接回落默认值。 解决：改成双扇区轮流写加 CRC 校验，加载时按 CRC 选块，两块都坏才回落默认值并置故障位。另外把写入动作限定在停机或者变化超过一定间隔时才触发。

现象：看门狗复位之后，输出点保持在上一次的状态，设备停不下来。原因：复位只清了 M 区和 Y 映像，物理输出引脚没被拉低，硬件上还保持着导通。 解决：在启动代码的最前面、初始化 GPIO 之前，先把所有输出引脚配成输入或者拉低，确保复位瞬间输出是断开的。这一步必须放在看门狗复位之后能立刻执行的位置。

注意：这几条里最危险的是最后一条。看门狗复位的本意是让系统回到安全状态，如果复位后输出还是通的，那这个狗不但没用，还会让人误以为系统已经停了。

6. 上板验证：从空程序到跑通一段真实逻辑

调试顺序我一般是反着来的：先验证输出，再验证输入，最后才验证指令逻辑。原因是输出最容易用万用表和 LED 直接看到结果，输入需要外部信号源，指令逻辑最抽象。这个顺序能把问题分层隔离，不会一上来就在黑匣子里猜。

第一步是空程序加输出自检。板子上不接任何负载，烧一个只有OUT Y0到OUT Y7循环导通的程序，用万用表逐个量输出端子的通断。这一步验证的是 Y 映像到物理引脚的映射关系，映射表错了后面全白搭。我见过把 Y 映射表写反的，Y0 和 Y7 对调，程序逻辑怎么调都不对。

第二步是输入采样验证。用短接线逐个短接输入端子，在上位机或者串口调试助手上看 X 映像变化。这一步的重点是确认八进制换算正确，X7 之后必须跳到 X10 而不是 X8，X17 之后跳 X20。全部 248 个点都验一遍太费时间，挑 X7、X10、X17、X20、X367 这几个边界点就够。

验证项	方法	期望结果	失败时的排查方向
Y 映射	逐点导通，万用表量	编号与端子一一对应	Y 映像到 GPIO 的映射表
X 映射	逐点短接，上位机读	八进制跳号正确	八进制转换函数
定时器	100ms 与 10ms 各跑一次	与秒表误差在 1% 内	时间基准分组是否正确
保持区	改写后断电重启	数值不变	CRC 与双扇区逻辑
编程口	上位机批量读写	帧校验全通过	校验和范围与串口位数

第三步是跑一段真实逻辑。我一般用一个自锁加定时器的电路：X0 启动、X1 停止、Y0 自锁输出、T0 延时 3 秒后点亮 Y1。这段程序覆盖面很广，包含了触点、线圈、自锁、定时器四种基础元件，任何一层出问题都会在这里暴露。

/* 上板自检：不依赖上位机，跑一遍软元件区的基本读写 */ int fx_selftest(void) { for (uint32_t i = 0; i < FX_D_POINTS; i++) g_dev.d[i] = (uint16_t)(i & 0xFFFF); for (uint32_t i = 0; i < FX_D_POINTS; i++) if (g_dev.d[i] != (uint16_t)(i & 0xFFFF)) return -1; FX_BIT_SET(g_dev.m, 100); if (!FX_BIT_GET(g_dev.m, 100)) return -2; FX_BIT_CLR(g_dev.m, 100); if (FX_BIT_GET(g_dev.m, 100)) return -3; return 0; }

逻辑说明：这个自检函数跑在main里、进主循环之前，返回值直接点亮不同的故障灯。它不测指令解释器，只测软元件区本身的读写正确性，把地基问题挡在启动阶段。返回 -1 说明 D 区数组越界或者别名，返回 -2 和 -3 说明位操作宏有问题。

参数说明：循环上限用FX_D_POINTS而不是硬编码 8000，这样裁剪内存之后不用改测试代码。位测试选 M100 是因为它在通用区中间，既不会撞到特殊继电器段，也不会被启动代码清零。

最后说一个习惯。从那以后我每次拿到这类带通信协议的源码包，第一件事都是先用 PC 脚本把帧格式跑通，哪怕板子还没焊好，也要先用串口工具模拟一遍收发。因为协议层的错和逻辑层的错混在一起的时候，排查成本是分开排查的好几倍。这份 FX3U V8.8 的包我按上面这套顺序走了一遍，从软元件区到编程口联通大概花了一个下午，真正卡住时间的是八进制编号和串口 7E1 那两处。想直接上手的，按包名去找就行，解压之后先从自检函数和串口配置这两处看起，能少走不少弯路。希望帮到你。

本文还有配套的精品资源，点击获取