简介面向高校嵌入式系统课程学习者、实验课备查及报告撰写参考需求这份docx实验报告基于苏州大学金葫芦平台与AHL-STM32L431开发套件完整整理六个验证性实验。内容覆盖开发环境与GPIO编程、串口通信及中断、PWM信号生成、Flash读写擦除、SPI总线通信以及独立看门狗复位等基础技能并记录实验目的、准备、过程或要求、具体步骤与截图、实验总结对中断组帧、PWM占空比调整、Flash在线编程等要点有直观呈现便于对照硬件现象和程序配置进行复盘。压缩包共1个docx文件约10.04MB文档按实验逐项编排方便快速查找各模块操作记录与结果说明。已有400人学习下载可从中获得较完整的实验流程、参数调整思路和现象验证参考适合课程实验对照、知识点梳理与嵌入式软硬件交互入门。1. 六个实验的知识地图从点亮一盏灯到看住一颗芯片嵌入式系统实验的六个验证性实验看名字像六个孤立的知识点——GPIO、串口中断、PWM、Flash、SPI、独立看门狗。真按顺序跑完一遍会发现它们是一条链上的六个台阶前两个台阶解决“代码怎么进芯片、芯片怎么说话”后四个台阶解决“芯片怎么驱动外部器件、怎么记住数据、怎么在跑飞时自己拉回来”。这份笔记按“开发环境与 GPIO → 中断与串口 → 构件化外设四连 → 易漏点排查 → 复习清单”重新排了一遍适合正在写实验报告、或者考前想把零散操作压成一张地图的人。验证性实验的重点从来不是写代码而是把每一步的现象和背后的寄存器行为对上号。2. GPIO 与开发环境第一个工程里藏着最多的坑2.1 七步流水线与它对应的四个失败信号六个实验的动手流程几乎一模一样可以压成七步建工作目录、复制模板工程并重命名、导入工程、编译、硬件连接、连接目标板、选择 Debug 目录下的 .hex 下载并观察现象。后面五个实验无非是换一个模板工程、换一组参数剩下六步照抄。真正让人卡住的不是流程本身而是每一步失败时给出的信号写得很含糊只能靠经验翻译。第一类信号是导入后编译报一堆找不到头文件的错八成是模板工程的相对路径被移动过或者复制时把整个工程目录塞进了两三层子文件夹里。第二类是编译显示 0 error 却找不到 .hex这通常不是代码问题而是当前构建配置没选中、或者输出目录被上一次的残留文件占着。第三类是点“连接目标板”扫不到串口先查线、再查驱动、最后查有没有别的串口工具正占着这个口——串口是独占资源一个工具开着另一个就连不上。第四类最玄学现象和代码对不上改了半天没反应最后发现下载的是上一次编译留下的旧 .hex文件时间戳比源码还早。提示每次改完代码先看编译输出窗口里有没有重新链接的动作再去选 .hex。养成看文件修改时间的习惯能省掉一半“我明明改了”的血泪经验。工作目录的组织方式值得单独说一句。按“分门别类、各有归处”的原则建目录比如一级目录按实验编号二级目录里固定放原始模板、自己的工程、截图、报告草稿。验证性实验要交六份报告中途还要反复回头改参数重跑目录一乱找一张“改完参数后的现象截图”能找十分钟。2.2 GPIO 的两副面孔输出驱动与输入采样GPIO 这个知识点最容易被轻视因为它太简单了——输出就是写 0 写 1输入就是读 0 读 1。但配置项一展开坑就出来了。输出模式要选推挽还是开漏推挽能主动拉高也能主动拉低适合直接驱动 LED开漏只能拉低高电平靠外部上拉适合做电平转换或者线与总线。上下拉在输出模式下基本没用开了只是白白多一条漏电通路。速度档位也不是越高越好点灯这种低速信号开最高档边沿变陡、干扰变大示波器上一片振铃。输入侧的重点是默认电平由谁决定。按键一端接引脚一端接地如果内部不加上拉松开时引脚是悬空的读到的值随机跳这就是“不按键灯也乱闪”的根源。加了上拉之后松开读到 1、按下读到 0逻辑反过来了代码里的判断条件也要跟着反过来写。/* 把连接 LED 的引脚配成推挽输出函数名按所选构件库的实际接口替换 */ static void led_init(void) { gpio_cfg_t cfg; cfg.pin LED_PIN; /* 引脚编号照原理图填别照抄例程里的默认值 */ cfg.mode GPIO_OUT_PP; /* 推挽高、低电平均能主动驱动 */ cfg.pull GPIO_NOPULL; /* 输出脚开内部上下拉只会多耗电 */ cfg.speed GPIO_SPEED_LOW; /* 点灯是低速信号速度越高边沿越陡、干扰越大 */ gpio_init(LED_PORT, cfg); gpio_set(LED_PORT, LED_PIN, 1); /* 上电先给确定电平避免初始化前乱闪一下 */ }这段代码里真正需要自己判断的只有两个参数pin必须查原理图例程里那个编号大概率和你板子上的不一致mode取决于外部电路LED 接在引脚和地之间就用推挽输出高电平点亮接在引脚和电源之间就要反过来——输出低电平才亮。剩下两个属于默认安全值。很多人第一次做实验时“灯亮了但和预期相反”不是代码错是没确认 LED 的接法。同一个引脚换个方向就是输入。读按键时别只读一次就下结论机械按键按下和松开的瞬间会有 520 ms 的抖动程序跑得越快越容易读到一串来回跳变的电平。验证性实验里用最简单的软件延时消抖就够了读到低电平后隔 10 ms 再读一次两次都是低才认为是真按下。想写得像样一点就用状态机把“空闲—疑似按下—确认按下—等待松开”四个状态分开主循环里每次进来推进一步不阻塞其它逻辑。2.3 汇编和 C 互相调用以及 printf 到底怎么输出第一个实验里还有一个容易被跳过的点理解 C 程序和汇编之间怎么互相调用。这段知识在考试里不常考但它是理解中断服务函数、启动文件、库函数入口的基础。核心只有一条约定前四个整型参数放 r0r3返回值放 r0r4r11 由被调用方负责保护栈指针必须保持 8 字节对齐。/* C 侧告诉编译器这个符号在别处定义参数按 r0 传入返回值也在 r0 */ extern uint32_t asm_add3(uint32_t x); void demo(void) { uint32_t r asm_add3(7); /* 调用汇编实现实参 7 会被放进 r0 */ printf(r%u\r\n, r); }; 汇编侧导出符号遵守调用约定只碰 r0不破坏 r4-r11 EXPORT asm_add3 AREA |.text|, CODE, READONLY asm_add3 ADD r0, r0, #3 ; 入参在 r0结果也放回 r0 BX lr ; lr 里是返回地址直接跳回 C END两段代码能对上靠的是EXPORT和extern这一对声明把符号名对齐靠的是双方都遵守同一套寄存器约定。如果汇编函数里顺手用了 r4 却没保存回到 C 之后某个局部变量会莫名其妙变值这种 bug 极难定位因为它不在出错的那一行崩。printf 调试也在这个实验里第一次出现。嵌进芯片的 printf 和电脑上的不是一回事它最终要落到某个具体的输出通道上通常是串口。所以底层要提供一个“输出一个字符”的函数给标准库调用把字符塞进串口发送寄存器等发送完成再返回。这里最容易翻车的是缓冲区没有刷新——程序跑完了最后几行日志还在缓冲区里没发出去看起来像“打印到一半停了”。在每句日志末尾加\r\n是个便宜又有效的办法很多实现遇到换行会主动刷缓冲。3. 串口与中断一帧数据怎么才能收全3.1 中断的三段式使能、服务、退出中断这个知识点教材上写得很长实际动手只需要记住三段式。第一段是使能外设自己要开中断源接收寄存器非空、发送寄存器空、各类错误标志然后要把这个中断源接到中断控制器上最后整体开全局中断。三层漏一层中断都进不来而三层的开关名字在不同库里长得完全不一样这是初学者最容易卡住的地方。第二段是服务进中断后先读数据或者读状态把触发这次中断的标志清掉再干正事。第三段是退出返回指令会自动恢复现场。第二段里的顺序很讲究。有些芯片读一次数据寄存器就自动清了接收标志多写一句清标志反而会把下一次刚到的数据标志也清掉造成丢字节有些芯片必须手动清不清就会在退出中断的瞬间又立刻重进主循环一行都跑不到。判断方法是看现象如果程序卡在中断里出不来就是标志没清如果偶尔丢一两个字节多半是清早了或者清多了。服务函数还要遵守两条纪律。一是短中断里只做搬运和置标志解析、计算、打印全部丢给主循环。二是共享变量要加volatile否则编译器优化会把“主循环里反复读的那个标志”提升成寄存器变量永远读到进入循环时的旧值程序逻辑看着完全正确却永远不往下走。/* 中断只做搬运把字节塞进环形缓冲解析留给主循环 */ volatile uint8_t rx_buf[64]; volatile uint8_t rx_head 0; /* 只在中断里改 */ volatile uint8_t rx_tail 0; /* 只在主循环里改 */ void uart_rx_isr(void) { uint8_t d uart_read(); /* 读数据寄存器多数芯片靠这一步清接收标志 */ uint8_t next (uint8_t)((rx_head 1) 63); if (next ! rx_tail) { /* 满了就丢新的绝不覆盖还没处理的数据 */ rx_buf[rx_head] d; rx_head next; } uart_clear_flag(RX_FLAG); /* 读数据已清标志的芯片这一句可以删掉 */ }环形缓冲的好处是把“接收速度”和“处理速度”解耦。中断来得多快都只是往缓冲里塞主循环有空再慢慢取。head只有中断改、tail只有主循环改天然不需要临界区保护这是单生产者单消费者模型最省事的地方。缓冲区大小取 2 的幂取模运算直接换成按位与省掉一次除法。3.2 组帧从单字节回显到一帧完整数据实验里那个“收到一个字节减 3 再发回去”的小改动是理解串口通信的起点也是理解字符和数值区别的最佳教材。串口工具里敲一个 7发出去的是字符7它的编码是 0x37减 3 得到 0x34正好是字符4的编码所以屏幕上显示 4。整个过程做的是字符编码的算术不是十进制数的减法。如果发的是字母 A0x41减 3 就是 0x3E屏幕上出现的是一个符号不是数字。想清楚这一层后面处理协议数据时就不会把“收到的字节”和“它代表的数值”混为一谈。单字节能跑通就要做组帧了。裸串口没有边界概念两个字节之间隔多久算一帧结束全靠协议自己约定。最常见的格式是“帧头 长度 数据 校验”帧头是一个不会在数据里出现的固定字节长度告诉你后面还有几个字节校验用来判断这一帧有没有被干扰坏。/* 帧格式0xAA | LEN | DATA... | SUMSUM 为前面所有字节累加和的低 8 位 */ static void frame_feed(uint8_t b) { static uint8_t buf[32], idx 0, len 0; if (idx 0 b ! 0xAA) return; /* 没等到帧头直接丢掉 */ buf[idx] b; if (idx 2) len buf[1]; /* 第 2 个字节是数据长度 */ if (idx 2 idx len 3) { /* 头 长度 数据 校验 */ uint8_t sum 0; for (uint8_t i 0; i idx - 1; i) sum buf[i]; if (sum buf[idx - 1]) frame_handle(buf 2, len); idx 0; /* 无论校验对错都复位坏帧不能卡死状态机 */ } if (idx sizeof(buf)) idx 0; /* 缓冲区越界保护长度字段被干扰时的兜底 */ }这段解析的核心是最后那个无条件复位。校验失败也要把状态机清零否则一个坏帧会让后面所有好帧都错位。长度字段同样不可信——它本身也可能被打坏所以要有缓冲区上限兜底。组帧逻辑出错时最有效的调试手段不是加打印而是把每次收发的十六进制原始字节全打出来逐字节对。3.3 上位机那一端串口工具和 PC 端程序链路要通两头都得对。物理层三件事TX 接 RX、RX 接 TX 交叉接两块设备必须共地波特率两边完全一致。波特率误差是隐形杀手芯片内部时钟精度差一点短帧能通长帧就开始丢最后的字节看起来像“偶尔丢包”。遇到这种偶发问题先把波特率降下来试试能通就是时钟精度问题不是代码问题。用现成的串口工具能验证下位机发得对不对但实验里还要求写 PC 端的接收程序这就多了一层线程模型的知识。串口类库的接收事件是在后台线程里触发的直接把收到的字节往界面控件上写轻则界面卡顿重则抛跨线程异常。正确做法是在事件里只把数据追加进缓冲区然后切回界面线程去更新显示。/* 接收事件在后台线程触发只入队切回 UI 线程再刷新显示 */ private void port_DataReceived(object sender, SerialDataReceivedEventArgs e) { int n port.BytesToRead; byte[] tmp new byte[n]; port.Read(tmp, 0, n); /* 一次读完避免多次小读造成拆帧 */ lock (rxLock) { buffer.AddRange(tmp); } this.BeginInvoke(new Action(RefreshUi)); /* 把刷新动作投递回 UI 线程 */ }BytesToRead到Read之间理论上还会来新数据所以读的长度要按调用那一刻的值取不要按“以为应该有”的长度取。BeginInvoke是异步投递界面不会因为刷新而阻塞接收线程。这套模式在任何一个需要“后台收数据、前台显示”的场景里都通用不只是串口。4. 构件化外设四连PWM、Flash、SPI 与独立看门狗4.1 PWM三个参数决定一条波形后四个实验的共同点是“基于构件”——也就是不直接怼寄存器而是调用库提供的初始化、启动、读写接口。学这类实验重点是搞清每个接口背后对应哪几个硬件参数而不是背 API 名字。PWM 就是把这件事讲得最清楚的例子定时器时钟、预分频、自动重装值三者决定频率比较值决定占空比。频率公式可以记成f clk / ((PSC1) × (ARR1))占空比是CCR / (ARR1)。这两个式子里的加一是最容易漏的因为计数是从 0 数到 ARR一共 ARR1 个数。举个数定时器时钟 80 MHz预分频写 79计数频率就是 1 MHz自动重装值写 999周期就是 1000 个计数频率 1 kHz。要 30% 占空比比较值写 300。/* 目标1 kHz 方波占空比随亮度可调 */ /* f_pwm clk / ((PSC1) * (ARR1))占空比 CCR / (ARR1) */ tim_set_psc(TIM, 79); /* 80 MHz / 80 1 MHz 计数频率 */ tim_set_arr(TIM, 999); /* 1000 个计数一周期 - 1 kHz */ tim_set_ccr(TIM, 300); /* 300/1000 30% 占空比 */ tim_start(TIM);参数改动的连带关系是这一节的重点。只改 ARR 不改 CCR占空比会跟着变CCR 写成比 ARR 还大输出会一直保持有效电平看起来像“占空比 100% 卡住了”CCR 写 0 则是另一种极端。做呼吸灯效果时CCR 从 0 扫到 ARR扫到边界那两端会有明显的停顿感就是因为撞上了这两个极端值。PWM 的实验现象通常是灯的亮度变化但真正的考点在“参数和现象的对应关系”。改预分频亮度不变、闪烁频率变改比较值频率不变、亮度变。能把这两个现象分开描述说明真的理解了时基和占空比是两条独立的轴。这个理解直接迁移到电机调速、舵机角度控制、蜂鸣器音调全是同一套参数。4.2 Flash先擦后写按页对齐Flash 实验的知识点和 RAM 完全不是一套逻辑。RAM 可以随便改任意一个字节Flash 不行写操作只能把 1 变成 0要把 0 变回 1 必须擦除而擦除的最小单位是页或者扇区不是字节。这条物理限制推导出整个编程模型——想改一个字节得把整页读出来放到 RAM、改掉那一个字节、擦掉整页、再整页写回去。/* 先擦后写擦除单位是页写只能 1-0 */ #define PAGE_SIZE 2048 uint8_t buf[PAGE_SIZE]; flash_read(ADDR, buf, PAGE_SIZE); /* 1. 整页搬进 RAM */ buf[0] 0x5A; /* 2. 只改需要改的那几个字节 */ flash_erase_page(ADDR); /* 3. 擦整页变成全 0xFF */ flash_write(ADDR, buf, PAGE_SIZE); /* 4. 整页写回 */四个步骤的顺序不能换尤其是擦和写之间不能插别的写操作。省掉读这一步直接擦整页数据就没了擦完不写回读出来全是 0xFF。写完之后一定要读回来比对因为写失败不一定报错——接口返回成功数据却没进去这是 Flash 编程里最典型的一类“假成功”。还有两个工程上的注意点。一是擦写期间的取指问题如果程序本身就在同一块 Flash 里跑擦写过程中 CPU 取不到指令中断响应会被拖长实时性要求高的场景要先把中断关掉或者把关键代码搬到 RAM 里跑。二是寿命Flash 的擦写次数是有限的在循环里反复写同一页几十万次之后那页就废了所以参数存储通常要加磨损均衡或者至少做写前比对——值没变就不写。4.3 SPI四种模式加一根片选SPI 的知识密度比串口高因为它有四根线时钟、主出从入、主入从出、片选。前两根决定“什么时候采样”后两根决定“数据往哪走”。最容易出错的是时钟极性和相位的四种组合也就是常说的模式 0 到模式 3。空闲时时钟是高还是低决定极性第一个边沿采样还是第二个边沿采样决定相位。从器件的数据手册里一定会写清楚它要哪一种配错了现象是“数据全是 0xFF 或者全 0”而不是报错。/* 模式 0空闲低电平第一个边沿采样速率先给 1 MHz 保平安 */ spi_cfg_t cfg { .mode SPI_MODE_0, .bit_order SPI_MSB_FIRST, /* 大部分器件高位先出少数器件相反 */ .speed 1000000, /* 先低速跑通再逐步往上加 */ .cs SPI_CS_SOFT, /* 软件片选时序自己负责 */ }; spi_init(SPI1, cfg); spi_cs_low(SPI1); /* 片选拉低一帧的开始 */ spi_xfer(SPI1, tx, rx, len); /* 全双工发一个字节的同时收一个字节 */ spi_cs_high(SPI1);全双工这一点经常被忽略。SPI 没有“只读”这个动作你想读一个字节就必须发一个字节出去收到的那个字节才是有效数据。所以读函数里通常要填一个哑元字节。片选的时序也很讲究拉低到第一个时钟之间要有建立时间最后一个时钟到拉高之间要有保持时间软件片选的情况下这两段延时得自己加加少了低速能通、高速就丢。调试 SPI 的顺序建议固定成三步先降到最低速率确认有没有波形再用逻辑分析仪或者示波器看片选和时钟的关系对不对最后才去核对数据内容。反过来做先怀疑数据格式会在错误的方向上耗掉大半时间。4.4 独立看门狗喂狗的位置比喂狗的频率更重要看门狗的原理一句话讲完一个靠独立时钟跑的递减计数器减到零就复位芯片程序必须在它减到零之前把它重新装满这个动作叫喂狗。独立两个字是关键——它用的是自己的低速时钟源即使主时钟挂了、程序跑飞了它照样在数。配置只有两个参数超时时间、喂狗周期。超时时间按最坏情况下主循环跑一圈的耗时来定一般留两到三倍余量。喂狗周期的经验值是超时的三分之一以内。/* 超时约 1.6 s喂狗周期要明显小于它 */ wdt_init(1600); while (1) { task_a(); task_b(); wdt_feed(); /* 喂狗放主循环末尾任何一个任务卡死都会漏喂 */ }喂狗位置是这一节唯一需要动脑的地方。放在主循环开头任务卡死时仍然会先喂一次再卡住看门狗形同虚设放在主循环末尾只要任何一个任务死循环这一圈就走不完就不会喂超时复位。更隐蔽的错误是放在定时器中断里喂——主循环已经跑飞了定时器中断还在正常触发狗一直被喂着系统永远不会重启这个黑匣子能藏很久。还有一个现象值得一提调试器连着的时候某些环境会冻结看门狗计数于是“在线调试一切正常、脱机上电就反复重启”。遇到这种差异先怀疑看门狗把它临时关掉再验证一次。验证看门狗真的有效正确做法是故意在主循环里插一个死循环确认板子会周期性复位而不是只看“程序没重启过”就认为配好了。5. 易漏点排查六个实验里最容易翻车的五处5.1 改了代码下载的是旧固件这是六个实验中复现率最高的一处翻车。易漏点在于编译和下载是两个独立动作中间隔着一个文件选择框。为什么容易漏编译失败的提示在输出窗口一闪而过而下载界面的文件列表默认停在最近一次选中的位置看起来一切正常实际下进去的是上一次的产物。怎么补把“编译成功的时间戳”和“.hex 文件的修改时间”对一遍两个时间对不上就说明没重编或者干脆每次下载前先手动删掉输出目录逼迫自己走完整的编译流程。现象和代码对不上时第一反应应该是查固件版本而不是改代码。5.2 中断标志的清理时机搞反易漏点在服务函数里多清一次和少清一次的表现完全不同。为什么容易漏教材和例程里对清标志的写法不统一有的芯片读数据即清、有的要手动写 1 清零、有的写 0 清零照抄另一块板子的代码逻辑上没错、行为上全错。怎么补先用最笨的办法验证一次——在服务函数里只做“翻转一个 GPIO”不读数据不清标志看进中断的频率是不是符合预期再逐步把读数据和清标志加回去哪一步加完现象变了问题就在那一步。同时确认共享标志变量有没有加volatile编译器优化导致的“标志永远读到旧值”和“标志没清”现象很像但改法完全不同。5.3 把字符当成数值来算易漏点在串口实验的“收到字节减 3 再发回”这一步。为什么容易漏串口工具显示的是字符人的直觉会把它当成数字于是理所当然地认为发 7 收 4 就是十进制减法。实际上做的是编码运算7减 3 得4纯属巧合。怎么补把收发都切成十六进制显示敲一次 7 看发出去的是 0x37回显回来的是 0x34对应关系一目了然。再试一次发0减 3 得到的是个控制字符屏幕上什么也看不见——这个实验能把“字节”“编码”“数值”三层概念彻底分开比背十遍定义管用。5.4 Flash 写完不校验假成功骗过眼睛易漏点在 Flash 实验的写操作之后。为什么容易漏写接口返回成功程序继续往下跑一切看起来都对只有读回来的数据不对而验证性实验里往往只写不读、或者读了不比对。更隐蔽的情况是擦除没完成就写写进去的数据一半是新的一半是旧的。怎么补写完立刻整段读回来和设备内存里的缓冲区做逐字节比对不相等就打印出错地址。同时确认擦除的地址是按页对齐的擦除长度是页大小的整数倍这两条不满足时擦除操作可能静默失败。参数存储这类场景还要加上“值没变就不写”的判断顺手省下擦写寿命。5.5 看门狗在调试器下被冻结易漏点在验证环节。为什么容易漏调试连着的时候计数器被暂停程序故意写死循环也不复位于是得出“看门狗配好了”的结论等到脱机跑板子每隔一秒重启一次又找不到原因。怎么补验证看门狗必须脱机——拔掉调试连接、重新上电、观察复位间隔是否符合设定的超时时间。另外检查喂狗语句有没有落在中断里落在中断里等于给系统吃了后悔药主循环再卡也不会复位。最后确认初始化之后、进入主循环之前有没有先喂一次否则上电到第一次喂狗之间如果耗时超过超时时间会在启动阶段就被复位表现为“上电后不停地重启”。6. 复习清单把六份实验报告压缩成一张纸考前回头看六份报告加起来几十页真正需要记住的是一张对应表加三条通用纪律。下面这张表是我自己压出来的版本左列是实验右列是“一句话考点”和“最容易错的那一步”两分钟能扫完一遍。实验一句话考点最容易错的一步GPIO输出的推挽/开漏选择输入的默认电平由上下拉决定LED 极性搞反或按键没加上拉导致读数乱跳串口中断使能三层开关、标志清理时机、缓冲解耦服务函数里做耗时操作或忘加 volatilePWM频率由 PSC 和 ARR 定占空比由 CCR 定漏掉公式里的加一CCR 超过 ARR 卡在满占空比Flash先擦后写、按页对齐、写只能 1 变 0擦完忘了写回或写完不校验SPI四种模式的极性和相位、片选时序、全双工只读不发哑元字节或模式配错拿到全 0xFF看门狗独立时钟源、超时与喂狗周期的比例喂狗放在中断里或调试器下被冻结误判为通过三条通用纪律更值钱。第一条是“现象和代码必须一一对应”任何一个改动之后先能说清预期现象是什么再看实际现象说不清就先别改。第二条是“先降速再提速”串口波特率、SPI 时钟、PWM 频率全都先从最低档跑通再往上加出问题时降回去就能立刻判断是不是速率相关。第三条是“验证要脱机”尤其是看门狗和 Flash 这类带状态的功能连着调试器看到的行为和真实运行可能完全不同。查漏补缺的具体做法我习惯按“参数表”过一遍把六个实验各自的可调参数列出来逐个数一遍“这个参数改大改小分别会怎样”。能答上来的直接跳过答不上来的回去重跑一次实验只改那一个参数看现象。这个方法比重读报告快得多也更容易发现“以为自己懂了其实没懂”的地方。从那以后我每次做这类验证性实验都会在提交之前强迫自己走一遍“改参数、重编译、对时间戳、再下载、脱机复现”这五步任何一步跳过后面大概率要返工。这份笔记的整理方式也是这么磨出来的——先跑通再拆成参数最后压成表。希望帮到你。本文还有配套的精品资源点击获取