做FPGA开发这些年我经手过不少测控类的项目从简单的传感器采集到多通道同步控制系统都有涉及。说实话测控程序和纯通信或图像处理类的FPGA设计有本质区别——它更像是在写一套“实时操作系统”只是这个系统跑在硬件逻辑上每个“任务”都是真实的硬件模块每条“消息”都是一组并行翻转的信号。今天我就把FPGA里测控程序的那点事掰开揉碎从框架搭建、模块划分到数据流设计把我在实际项目中沉淀下来的经验一次性讲清楚。这篇文章适合刚入门FPGA、想了解工程化开发流程的同学也适合已经写了几个小模块但感觉代码越来越乱、想要重构设计思路的朋友。我会尽量用我在项目里真实踩过坑、验证过有效的方案来讲解不是教科书式地罗列概念。1. 整体框架与模块划分思路1.1 为什么测控程序比普通逻辑更吃框架很多人写FPGA逻辑是从点灯开始加个按键消抖、加个串口发送看起来功能都能跑但一旦涉及测控程序情况就完全不同了。测控系统的典型特征是通道数多、接口协议杂、时序约束紧而且往往需要实时响应外部事件。你没法像写串口收发那样把所有逻辑堆在一个always块里因为不同功能会互相干扰调试起来更是噩梦。我见过不少新手写测控程序最先犯的错就是把所有逻辑全部铺开在顶层模块里传感器数据解析、PID运算、PWM输出、通信协议全部平铺在一个.v文件里。这种代码在仿真阶段通常问题不大上板之后偶尔也work但一旦要加一路新传感器、换一种通信协议改动就会牵一发动全身。更麻烦的是功耗和时序问题所有逻辑挤在一起导致布线拥塞时序收敛困难Fmax怎么也拉不上去。所以我要强调的第一个原则是FPGA测控程序必须有清晰的框架。框架的意义不在于好看而在于把不确定因素隔离开——通信协议的变更不影响控制算法控制算法的迭代不影响底层IO驱动。这样每一部分都能独立仿真、独立优化、独立复用。1.2 我惯用的四层结构设计经过几个项目的反复迭代我最终固定下来一套四层结构按需增删基本能应对绝大多数测控场景。这里用最直白的方式解释它。接口层Interface Layer负责所有外部物理接口的数据收发比如UART、SPI、I2C、LVDS、以太网。这一层的模块只关心时序协议的准确实现不关心收到数据的业务含义。字节对齐、帧格式校验、CRC计算都在这里完成。控制层Control Layer测控程序的“大脑中枢”包括状态机、命令分发、参数配置管理。它接收接口层解析出来的命令决定整个系统下一步做什么。它不直接碰硬件引脚只是下发控制字和配置参数。计算层Processing Layer做实际的测量计算或控制算法比如滤波、FFT、PID、阈值判断。这一层是纯逻辑运算不依赖具体IO所以可以脱离硬件做仿真验证。资源层Resource LayerFPGA内部的底层资源管理包括FIFO、RAM、时钟管理单元MMCM/PLL、全局复位。为上层提供稳定的数据存储和时钟同步基础。这个分层模型的本质是把数据采集、处理、输出和管理四条链路解耦任何一层的改动都不应该影响其他层。实际项目中我通常用三个主要的Verilog模块对应其中几层功能接口层1-2个模块、控制层1个主状态机模块、计算层1-2个算法模块、资源层单独例化全局时钟和复位每个模块内部再细分小模块而不是真的创建几十个顶层文件。分层思路是框架的灵魂文件数量则是灵活组织的外形。直接用代码来体现这个框架的话顶层模块的例化风格大概长这样// 顶层模块测控系统框架示例 module top_measure_ctrl ( input wire clk_ext, // 外部时钟输入 50MHz input wire rst_n, // 外部复位低有效 // UART接口 input wire uart_rxd, output wire uart_txd, // 传感器接口 output wire spi_sclk, output wire spi_cs_n, output wire spi_mosi, input wire spi_miso, // PWM输出 output wire [3:0] pwm_out ); // 内部信号全局时钟和复位 wire clk_sys; wire rst_sys_n; // 第1层资源层 - 时钟管理 clk_wiz_0 u_clk_mgr ( .clk_in1 (clk_ext), .clk_out1(clk_sys), .locked (clk_locked) ); // 生成系统复位外部复位和时钟锁定相与 assign rst_sys_n rst_n clk_locked; // 第2层接口层 - UART接收和发送 wire [7:0] uart_rx_data; wire uart_rx_valid; wire [7:0] uart_tx_data; wire uart_tx_valid; wire uart_tx_busy; uart_byte_rx u_rx ( .clk (clk_sys), .rst_n (rst_sys_n), .rxd (uart_rxd), .rx_data (uart_rx_data), .rx_valid (uart_rx_valid) ); uart_byte_tx u_tx ( .clk (clk_sys), .rst_n (rst_sys_n), .tx_data (uart_tx_data), .tx_valid (uart_tx_valid), .tx_busy (uart_tx_busy), .txd (uart_txd) ); // 第3层控制层 - 命令解析状态机 wire [15:0] ctrl_cmd; wire ctrl_cmd_valid; cmd_parser u_cmd ( .clk (clk_sys), .rst_n (rst_sys_n), .rx_data (uart_rx_data), .rx_valid (uart_rx_valid), .cmd_out (ctrl_cmd), .cmd_valid (ctrl_cmd_valid) ); // 第4层计算层 - 测量与控制算法 wire [15:0] meas_value; wire [15:0] ctrl_param; measurement_core u_measure ( .clk (clk_sys), .rst_n (rst_sys_n), .spi_clk (spi_sclk), .spi_cs (spi_cs_n), .spi_mosi (spi_mosi), .spi_miso (spi_miso), .value_out (meas_value) ); pwm_generator u_pwm ( .clk (clk_sys), .rst_n (rst_sys_n), .freq_ctrl(ctrl_param), .pwm_out (pwm_out) ); // 控制层接收计算层反馈调整参数示意 assign ctrl_param meas_value 16d100; // 示例偏移 endmodule这里我把顶层模块的例化结构展示得很清楚——每个层次被例化为独立子模块内部的数据流通过信号线连接互不干扰。提示框架设计阶段多花一小时后面调试阶段能省一整天。这是我在多个项目中反复验证过的经验。1.3 模块划分的边界怎么拿捏框架定了之后模块划分是紧接着的问题。这里我总结三条经验原则听起来很朴素但极其实用。按数据流方向划分每个大模块对应一个数据处理阶段比如“采集模块→预处理模块→算法模块→输出模块”模块间的接口用明确的valid/ready握手信号连接。好处是仿真时可以单独给每个模块灌测试向量定位问题特别快。按变更频率划分经常要改的参数比如控制算法的系数、通信协议版本独立成模块或至少独立成参数文件不经常动的物理接口驱动SPI时序、UART波特率做成固定模块。这样你升级算法逻辑时不需要碰接口层降低回归测试范围。按复用价值划分SPI主机接口、UART收发器、FIFO读写控制器这类通用模块单独抽出来建立自己的IP库新项目直接例化使用不需要重新调试。这也是很多大公司推行IP复用的原因个人开发同样受益。举个例子我做过一个八通道温度采集系统最开始的划分是按物理通道划分——每个通道一套采集逻辑结果代码量巨大而且每路的滤波参数要单独维护。后来我改成按功能划分——先做一个SPI采样核心模块再用一个仲裁逻辑分时复用这个核心去控制八个传感器通道代码量直接缩减三分之二而且新增通道只需改仲裁逻辑的配置表。这就是模块划分带来的杠杆效应。2. 核心模块细节解析2.1 时钟与复位的系统化设计测控程序最怕时钟复位出问题而这两个偏偏又是新手最容易忽略的细节。很多开发板给的demo都是直接把外部时钟拿来做所有逻辑的时钟复位也是直接异步复位图省事。但一到真正的测控场景这种粗放做法会带来两个隐患。第一个隐患是时钟不干净。外部晶振或开发板时钟的质量通常一般抖动 jitter 较大而测控系统里往往有ADC采样时钟、PWM载波时钟、通信波特率时钟等不同频率要求。直接拿原始时钟分频出来的时钟在FPGA内部不是全局时钟网络布线延时会导致不同模块看到不同沿这就是毛刺和亚稳态的根源。正确做法是用FPGA内部的MMCM或PLL生成所需频率的时钟并尽量让所有模块使用同源时钟分频操作只在必要时才在局部做且尽量通过使能信号clock enable而不是直接分频时钟来实现低速逻辑。第二个隐患是异步复位的亚稳态。FPGA的复位信号通常来自按键、外部控制器或者上电时序电路这些信号与系统时钟毫无关系如果不做处理直接接到触发器的异步复位端极可能在高频时钟下出现复位释放时序违例。稳妥的做法是给复位信号做同步处理也就是把外部异步复位先打两拍用同步后的信号作为整个系统的全局复位// 异步复位同步释放模块 module reset_sync ( input wire clk, input wire rst_async_n, // 外部异步复位 output wire rst_sync_n // 同步后的复位 ); reg rst_ff1; reg rst_ff2; always (posedge clk or negedge rst_async_n) begin if (!rst_async_n) begin rst_ff1 1b0; rst_ff2 1b0; end else begin rst_ff1 1b1; rst_ff2 rst_ff1; end end assign rst_sync_n rst_ff2; endmodule这段代码是FPGA开发者最熟悉的标准复位同步电路两级触发器串接可以消除复位释放时采到亚稳态的风险。我在所有测控模块里都统一用同步后的rst_sys_n绝不混用原始外部复位这个习惯帮我避免了至少两个项目中的“薛定谔式”偶发故障——就是你明知有问题但复现不出来的那种。2.2 总线接口模块与寄存器组的套路测控系统通常需要一个主控端单片机或上位机来下发命令、读取状态。FPGA和主控端之间最常见的接口就是寄存器组——一组由地址读写控制的寄存器主控端通过并行总线或串行协议访问它们。这里的核心不是握手协议的实现而是寄存器组的架构设计。我设计寄存器组时坚持一个原则寄存器地址规划必须预留扩展空间。比如控制寄存器占据0x00-0x0F状态寄存器占据0x10-0x1F参数寄存器占据0x20-0x3F。每个非连续区间都留一半空地址宁可让地址译码逻辑稍微复杂一点也不要把寄存器塞得满满当当。为什么因为测控项目的需求几乎一定会变——今天要加一路传感器校准系数明天要加一个工作模式切换位。如果地址从0x00一路排到0x20新需求只能硬塞到已有地址的位扩展或者推到地址空间末尾打补丁代码越来越乱。寄存器的读写逻辑用标准写法即可关键是要对寄存器字段做注释。我会在代码里给每个寄存器位起一个可读性强的信号名而不是直接用mon[5:0]这种裸信号这样仿真波形里查问题会快得多// 控制寄存器 bit7: 使能采集 // 控制寄存器 bit6: 使能PWM输出 // 控制寄存器 bit5: 工作模式选择 // 控制寄存器 bit4: 软复位这套注释看似简单但真实调试的时候能帮你省去大量翻代码、推bit位的时间。寄存器组模块还需要设计好两套接口——一套是对外的总线接口一套是对内其他模块的配置/状态端口。对内端口建议用独立的wire连接每个功能模块而不是让所有模块都去地址总线上抓数地址总线若复用给多个模块当某个模块时序紧张时会影响整体时序并且接口混杂后仿真容易出僵尸值项目越改越难维护。一个可控寄存器通常对应一个使能信号或一组参数直接连到目标模块上。2.3 状态机设计——不要让状态机裸奔测控程序里最核心的控制逻辑就是状态机。状态机的质量某种程度上决定了整个程序的稳定性。这里我分享几个从实践中总结出的设计约束。第一状态机的状态编码要选好。二进制连续编码最省寄存器但状态跳转逻辑复杂还容易受毛刺干扰。格雷码适合相邻状态跳变多的场景但状态多了之后相邻关系难维护。我推荐在测控程序里用独热码one-hot现代FPGA有丰富的触发器资源多一些寄存器影响不大但独热码的状态译码特别快——每个状态对应一个bit不存在译码组合逻辑延时整体Fmax能明显提升而且状态跳转逻辑直观代码也更容易读懂。第二状态机必须有默认状态处理。很多人写状态机只写case分支却忘记写default这样如果状态跑到非法编码整个状态机会锁死在未知状态。我习惯在状态机的输出逻辑里要么用组合逻辑给默认值要么在每个case分支都完整赋值所有输出宁多勿漏always (posedge clk or negedge rst_sys_n) begin if (!rst_sys_n) state ST_IDLE; else case (state) ST_IDLE: state ST_CMD_PARSE; ST_CMD_PARSE: state ST_MEASURE; ST_MEASURE: state ST_PWM_UPDATE; ST_PWM_UPDATE: state ST_IDLE; default: state ST_IDLE; // 兜底回到空闲态 endcase end第三和状态机配套的组合逻辑输出要做寄存打拍。FPGA内部逻辑延时会导致组合逻辑输出的glitch毛刺虽然功能性影响通常不大但测控系统对信号质量敏感输出最好在always时序块内寄存一拍再送出去。这也是时序收敛的基本要求——尽量减少组合逻辑路径长度。2.4 FIFO与RAM的合理使用测控程序里FIFO几乎是必然要用到的资源尤其是跨时钟域、数据缓冲这两个场景。我见过的错误是把FIFO当成万能存储不分场景地到处例化导致资源浪费和管理复杂。实际上FIFO的使用场景足够聚焦速率不匹配时的缓冲、跨时钟域数据传递、突发数据暂存。关键的取舍在于是用FPGA厂商的IP核还是自己写FIFO。我早期为了学习自己写过异步FIFO逻辑上实现了格雷码指针同步、空满标志生成也能工作。但真实项目中我强烈建议用厂商IP核原因很简单——他们实现的异步FIFO经过了充分的时序验证还有面积优化选项和仿真模型能正确处理跨时钟域同步问题。自研FIFO在时序边界情况、异步读写冲突时极容易出错而这类Bug最难定位因为你很难在生产环境下稳定复现。IP核虽然要花一点时间学配置界面但背后体现的是“不重复造轮子”的工程思维。FIFO的深度设计也是一个经常被拍脑袋的决定。一个经验值是缓冲深度至少要能容纳最差情况下的突发数据量。假设ADC以1MHz速率持续输出16bit数据而处理模块每接收256个采样点才做一次批量处理那FIFO最小深度应该是256再留50%裕量取512。太浅会丢数据太深浪费BRAM资源总要有个依据。3. 数据流设计与时序分析3.1 主数据通路的设计要点测控程序的数据流通常是一个环传感器/ADC采样→数据预处理→控制算法→执行器/PWM输出→状态反馈回控台。这个环路里每一跳的数据宽度、速率、有效性标志都必须明确设计。我给每个数据通路都规定了一套“总线风格”最简单最常用的是valid/ready握手协议。发送方在数据有效时拉高valid接收方在准备好接收时拉高ready当两者同时为高时数据完成一次传输。这套协议来自AXI总线体系用在模块间互联里特别自然而且天然支持背压——接收方忙不过来时拉低ready发送方自然暂停不会有丢数据问题。数据宽度选择也有讲究。ADC是12位就按12位传输不要为了对齐随便扩展成16位如果后级算法需要更高精度在算法模块内部做定点扩展。每个模块的输入输出宽度要做到代码可读、约束可控。不要在整个链路上用别人看不懂的“魔法宽度”。3.2 跨时钟域的处理策略测控系统几乎一定存在跨时钟域CDC问题。比如系统主时钟100MHzADC采样时钟20MHz通信接口时钟可能又是另一个频率。跨时钟域信号如果不做处理采到的数据可能是亚稳态——触发器既不满足建立时间也不满足保持时间输出处在一个不可预测的中间电平。这是FPGA里最难排查的问题类型之一因为它在逻辑仿真中几乎不出现只在真实硅片上偶发。处理跨时钟域问题我有三招按适用场景排列。单bit控制信号用两级同步器打两拍。第一拍可能采到亚稳态第二拍采到稳定值的概率几乎是100%这就是标准双触发器同步器。多bit数据总线用异步FIFO。写时钟域负责写入读时钟域负责读出FIFO内部指针用格雷码同步能有效避免多个bit同时变化时的采样错误。握手协议对于不频繁发送的多bit信号用请求-应答握手机制确保目标域在数据稳定后才采样。这里容易踩的坑是把对单比特控制信号的同步方法照搬到多比特数据上。你可能会觉得多打两拍不就行了多bit信号各个位到达目标时钟域的延时并不相同即使打两拍也会出现某一拍里有的位已经更新有的位还没更新采到一个完全错误的值。这就是必须用异步FIFO或握手的根本原因。3.3 时序收敛的实操心得测控程序综合实现后最让人头疼的是时序报告不干净。Setup time违例、Hold time违例这些术语听起来高深本质上就是数据跑得太慢或者太快时钟采到了不稳定的数据。我处理时序问题的排查顺序通常是这样。第一步查时钟约束是否完整。很多人直接跑综合不写XDC约束工具默认自动推断时钟频率这跟实际设计差得很远。你要主动告诉工具每个时钟的频率、相位关系还要用set_clock_groups声明不同时钟域的异步关系这样工具才知道哪些路径不需要收敛。第二步看关键路径报告。Vivado的时序报告会列出最差的几条路径从起点到终点标出每一段延时。我常见的两个瓶颈组合逻辑链路过长比如一个always块里连续做了多次乘法和加法或者扇出太大一个信号驱动了几百个触发器的使能端。前者要用流水线切割——在组合逻辑中间插寄存器把一条长路径分成两条短路径后者要复制寄存器或优化设计结构。第三步检查代码风格是否利于综合。if-else嵌套过深、case分支的优先级设计不当、在时序逻辑里使用阻塞赋值这些都会让综合器生成意想不到的结构拉低Fmax。说实话大多数时序违例的根源不是工具不会优化而是写代码的人给了工具一个不好优化的设计。4. 常见问题与调试实战4.1 仿真波形不会骗人调试FPGA测控程序我的第一原则是先在仿真里把问题解决掉再上板debug。仿真波形里每个信号都是确定的、可控的、可回溯的而示波器抓到的信号是物理世界充满了噪声和不确定性。写好testbench是仿真调试的基本功。不要只写个激励信号然后人眼盯着波形图找信号效率太低。我习惯在testbench里加入自动化断言比如检查握手协议是否满足valid/ready同时拉高的时序、检查状态机的非法状态跳转有没有发生、检查FIFO空满标志是否与实际数据个数一致。断言失败会自动报错仿真结束就知道哪个模块出了问题。iverilog -o tb_top.vvp tb_top.v top_module.v vvp tb_top.vvp顺便说一句开源工具链这几年轻量级仿真用Icarus Verilog加GTKWave已经完全够用不需要动辄几GB的商用仿真器。尤其在教学和中小型测控项目里这套组合跑仿真非常顺手还能在CI里自动跑回归测试。4.2 常见问题速查表我把这些年遇到的高频问题整理成一个速查表格方便你在调试时对照参考。现象可能原因排查方向波形显示正常但上板无输出复位释放太早MMCM未锁定检查locked信号是否接入复位逻辑偶发数据错误时好时坏跨时钟域信号未同步检查CDC路径确认是否使用异步FIFO或双触发器状态机卡住不跳转状态编码非法或default分支缺失仿真中检查状态寄存器值确认状态跳转条件FIFO读出的数据错位读写时钟域相位未约束在XDC中声明异步时钟组避免工具乱优化PWM频率不对时钟分频逻辑与使能信号混用尽量用时钟使能而非分频时钟避免毛刺外部接口偶发异常引脚约束错误IO标准不匹配查看综合报告和引脚分配文件检查bank电压数据采集有固定偏差ADC采样时序不满足采样点太早用ILA实际抓取采样时刻检查建立保持时间最典型的案例是“仿真全对、上板出错”。这个问题几乎每个FPGA开发者都会遇到核心原因就是仿真环境里没有时序概念所有信号都是理想化的而在真实芯片上信号有延时、有竞争、有时序约束限制。解决路径也简单——把上板现象当一个额外的输入回到仿真中还原合理的时序场景通过ILA采集芯片内部真实信号来反推问题模块。4.3 ILA上板调试的姿势Vivado集成的ILA逻辑分析仪是我上板调试最常用的工具它能实时抓取FPGA内部感兴趣的信号相当于给芯片内部装了一个示波器。但我发现很多人用ILA的姿势不太对抓到的信号要么不是自己想要的要么触发条件设不对导致抓到一堆无关数据。正确做法是先想清楚你要验证什么假设再选探针信号。比如怀疑UART接收状态机在特定字节时出错那ILA的触发条件就设成“接收到特定数据且状态机处于特定状态”而不是笼统地抓UART的所有信号。ILA探针深度也有讲究。深度太大BRAM开销大还会影响布局布线深度太小抓不到突发事件。经验值是先设1024深度能覆盖一次完整的数据处理周期即可。另外要注意探针数量不要太贪心尽量只抓关键信号组信号太多同样会占用大量BRAM。我用ILA排查过最难忘的一个Bug是一个温度采集系统的数据每隔256个采样点会出现一个巨大的跳变值。一开始怀疑是传感器问题后来用ILA抓ADC采到的原始数据和FIFO读出的数据对比发现跳变发生在FIFO读出的数据上而不是ADC原始值于是顺藤摸瓜查到是我的跨时钟域FIFO深度设置得不够突发写满后覆盖了尚未读走的数据。问题定位只花了半小时因为ILA探针直接戳到了问题链路的关键节点。5. 系统联调的完整流程5.1 先调试接口层再做算法验证很多人的习惯是写完代码立刻全系统联调这是效率最低的做法。因为接口层一错上层全部白跑问题分布在各层之间就像多个变量互相耦合根本无法定位。我推荐的顺序是先调接口层。单独给UART或SPI模块写testbench验证发送和接收数据的时序确保字节级正确。然后用回环测试验证物理链路——把发送脚短接到接收脚发一串数据看是否完整收回来。接口通了之后再做控制层状态机的功能验证——模拟各种命令输入检查状态跳转是否符合预期。最后才是算法模块验证——用仿真数据测试滤波、PID等控制算法确认数值正确。每层都能独立仿真验证联调时出错概率会大幅降低。5.2 数据流全链路追踪的黄金方法联调阶段最核心的任务是追踪数据在系统里如何流动。我说的追踪不是指人眼盯波形而是主动在关键数据通路上设计“监控点”让数据在每一级处理环节都留下可观测的痕迹。具体做法是在每个模块的输出端口加一个断言或计数寄存器。比如数据经过预处理模块后可以用仿真断言确认输出的数据范围和预期一致再用一个计数器记录数据通过的数量联调时对照计数器值就能知道数据处理到哪一级、在哪一级产生丢数或重复。这个思路是受软件行业“链路追踪”概念的启发移植到硬件调试里同样有效。还有一个高性价比的方案是利用FPGA的在线调试能力把关键中间变量的值通过UART或以太网实时上传到上位机在上位机画成曲线或表格。这样联调时你看到的不再是一堆孤立信号而是完整的数据流。我之前做一个电机控制系统时就把编码器反馈、PID输出、PWM占空比三重信号通过串口上传在上位机画实时曲线。联调过程中的所有异常几乎都能在曲线上直接看出端倪——比如PID输出饱和时曲线是平的负载突变时反馈值的延迟暴露无遗。5.3 从原型验证到工程发布的细节原型验证通过后离正式发布还有一段路。这里列几个我每次项目收尾都会过一遍的检查项。时钟约束检查重新审查XDC文件确认所有时钟都正确约束包括那些经由IP核产生的时钟。功耗评估测控系统很多是嵌入式场景功耗超标会导致发热和稳定性问题综合后要看功耗报告评估是否需要调整时钟频率或关掉空闲模块。引脚约束与文档核对确保每条外部接口的引脚都绑定正确电平标准匹配这点在换板子、改板子的时候最容易出错。上电稳定性和长时间老化测试测控系统经常要7x24小时运行短时间功能正常不代表长时间稳定。我的项目一般至少连续运行48小时观察是否有偶发错误累积同时检查温度指标。代码管理给项目打tag记录综合实现时的Vivado版本、IP核版本、约束文件哈希。几个月后回来维护时能快速重建出完全相同的bitstream环境。这些工程化细节往往不像写出一个漂亮模块那样有成就感但恰恰是这些细节决定了你的设计能不能从一个演示demo变成一个可靠的产品。6. 项目总结与经验沉淀回到最初的问题FPGA里的测控程序究竟该怎么写我的体会是大多数人遇到的困难不是某个具体模块实现不了而是缺少一套从框架到细节的完整思维路径。框架层面想清楚分层和模块边界细节层面把时钟、复位、跨时钟域这些基础功做扎实数据流层面用握手协议和FIFO把各模块衔接起来调试层面充分利用仿真、断言和ILA这些工具整个设计就会进入一个良性循环——每一层都清晰可控每一个Bug都能快速定位。最后分享一个我的个人习惯每做完一个项目我会花一晚上把整个工程的架构图和数据流图重新画一遍包括最终版本的模块划分、接口定义、关键时序参数。这件事看起来像是额外工作但下一次做类似项目时这些图纸就是我最宝贵的起点资料。测控程序的复杂性不会因为换了个项目就消失但你的经验积累会让下一次起步更高、踩坑更少。
