1. 为什么“赛前准备”比“现场发挥”更决定电赛成败

我带过七届电赛队伍，亲手送走23支参赛队，其中16支进了省一，5支拿了国奖。但最让我后怕的，不是决赛答辩时芯片烧了、不是调试到凌晨三点代码跑飞，而是——有三支队伍，连作品都没能完整上电。不是能力问题，是赛前准备塌了方。

电赛不是考试，它是一场72小时极限生存战。你面对的不是标准题库，而是“用STM32控制双路DCDC输出可调电压，精度±0.5%，带OCP/OVP保护，通过树莓派4B做本地Web监控，同时支持Arduino Uno作为备用手动调节终端”这种复合型命题。它不考你会不会写GPIO初始化，而考你能不能在断网、缺料、示波器故障、队友发烧的多重压力下，让整套系统在第68小时稳定跑满24小时无人值守测试。

所以我说：赛前准备不是“准备工作”，它是整场比赛的第一道、也是最硬的一道关卡。它决定了你有没有资格进入“发挥阶段”。很多同学把“准备”理解成“买齐模块+装好IDE+抄几个例程”，这就像登山前只检查了登山包颜色，却没测氧气瓶压力、没查天气预报、没练过冰镐使用——表面齐整，内里空虚。

真正有效的赛前准备，必须覆盖四个不可割裂的维度：硬件鲁棒性验证、软件最小闭环验证、环境容错预案、团队作战协同机制。这四条线，任何一条断裂，都会在比赛第三天凌晨两点把你钉死在调试台前。比如去年某省赛，一支强队用树莓派5跑ROS2节点做视觉识别，结果赛前没验证USB3.0供电稳定性，比赛第二天所有外设集体掉线，重刷系统耗去11小时，最终只拿了个省三。他们代码写得比谁都漂亮，但输在了“树莓派修改源”这种基础操作没纳入压力测试清单里。

再比如“DCDC电路”这个高频词，背后藏着多少坑？你选的DCDC芯片手册第37页写着“建议PCB铺铜面积≥8cm²”，但你画板时为了塞进外壳，把散热铜箔砍掉一半；你测试时用万用表量输出纹波，觉得“不到20mV，没问题”，结果接上STM32 ADC采样就出现周期性跳码——因为万用表测的是RMS值，而ADC敏感的是峰峰值噪声。这些细节，全靠赛前准备阶段用真实负载、真实信号链、真实电源条件去撞墙验证。

所以这篇分享，不讲“怎么写PID算法”，不教“如何配CubeMX”，而是带你拆解：在比赛开始前72小时，一个成熟队伍到底该把时间花在哪几件刀刃上？这些动作，没有炫技成分，全是血泪换来的“保命清单”。你照着做一遍，至少能避开80%的非技术性崩盘。

2. 硬件准备：从“能用”到“扛住72小时连续冲击”的质变

电赛硬件准备，核心矛盾从来不是“功能实现”，而是“极端工况下的可靠性维持”。我见过太多队伍，作品在实验室稳如泰山，一搬到赛场就频发故障：DCDC模块在高温高湿环境下输出漂移、树莓派OV5647摄像头模块在强荧光灯下出现滚动条纹、Arduino驱动数码管时因共阴极驱动电流分配不均导致某段持续暗灭……这些问题，99%都能在赛前用三步法堵死。

2.1 DCDC电路：不只是“升压/降压”，而是“动态负载下的稳态守门员”

DCDC是电赛电源系统的绝对心脏。但多数队伍对它的认知还停留在“输入12V，输出5V，接上就行”。错。DCDC在电赛中的真实角色，是应对瞬态大电流冲击的缓冲器。比如你的STM32控制电机启停，瞬间电流可能从100mA飙到2A，如果DCDC响应慢、环路补偿设计保守，输出电压会塌陷，导致MCU复位——这时你查代码、查逻辑，永远找不到原因。

我要求所有队伍，对主DCDC模块必须完成三项强制测试：

第一，阶梯负载冲击测试。
用电子负载（或自制MOSFET开关阵列）模拟真实负载变化：

• 阶梯1：100mA恒流 → 突变至500mA，保持1s → 回到100mA
• 阶梯2：500mA → 突变至1.5A，保持500ms → 回到500mA
• 阶梯3：1.5A → 突变至2.5A（电机堵转典型值），保持200ms

提示：示波器探头必须接地弹簧直接焊在DCDC输出电容负极，否则测出的“纹波”全是地线环路噪声。实测中，我们发现某款标称“纹波<30mV”的国产DCDC模块，在2.5A阶跃下输出跌落达1.2V，持续80ms——这足以让STM32硬复位。最终换用TI TPS54302，其COT架构响应速度提升3倍，跌落压仅0.18V/20ms。

第二，温升边界测试。
把DCDC模块放在密闭盒内（模拟实际外壳散热条件），输入电压取最低标称值（如12V标称，实测用10.5V），输出带最大负载，连续运行2小时。用红外热像仪（或至少两支不同位置的热敏电阻）监测：

• 开关管结温（需换算，手册给出θJA）
• 输出电感表面温度
• 输入/输出电解电容顶部温度

注意：电解电容寿命与温度呈指数关系。某队伍用普通105℃电容，在外壳内温达78℃时，比赛第三天电容ESR飙升，导致输出纹波暴涨至120mV，ADC采样完全失真。后来改用固态电容+强制风冷，温控在65℃以内，全程零故障。

第三，输入扰动兼容性测试。
电赛现场电源质量极差。我们用自耦调压器+可控硅调功模块，模拟三种典型扰动：

• 输入电压跌落：12V → 9V，维持50ms（模拟电网波动）
• 输入电压尖峰：12V叠加±100V/1μs脉冲（模拟继电器断开感应电动势）
• 输入纹波：叠加1kHz/2Vpp正弦纹波（模拟劣质适配器）

合格标准：输出电压波动≤±3%，无锁死、无重启。不合格的DCDC，必须加LC滤波或更换型号。去年国赛某题要求“双路DCDC独立控制”，我们给两路分别加了TVS+π型滤波，才扛住赛场UPS切换时的输入尖峰。

2.2 主控平台：STM32、树莓派、Arduino不是并列选项，而是分层协作的“作战梯队”

很多队伍纠结“用STM32还是树莓派”，这是伪命题。真实电赛中，它们是分工明确的三层架构：

• STM32（如F407/F767）：实时控制层，负责ADC采样、PWM生成、电机FOC、DCDC数字PID、高速通信（CAN/USB）——毫秒级响应，不容中断。
• 树莓派（推荐4B/5，非Pico）：智能管理层，负责Web服务、图像处理（OpenCV）、数据存储、远程通信（MQTT）、人机交互（Qt界面）——秒级任务，可容忍短暂卡顿。
• Arduino（Uno/Nano）：应急备份层，当树莓派崩溃或网络中断时，接管基础显示（数码管）、手动调节（电位器）、状态指示（LED）——功能极简，但必须100%可靠。

关键准备动作：
① STM32的GPIO操作必须脱离HAL库裸写。
HAL库方便，但中断响应延迟不可控。我们要求所有PWM、ADC、EXTI相关引脚，必须用寄存器操作。例如操作STM32的GPIO控制LED：

// HAL方式（不推荐用于关键IO） HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET); // 寄存器方式（精准到cycle） GPIOA->BSRR = GPIO_BSRR_BR0; // 直接置位BSRR寄存器，1个cycle完成

实测对比：HAL方式在168MHz主频下，GPIO翻转延迟约1.2μs；寄存器方式为12ns。对需要微秒级同步的DCDC相位控制，这0.1μs就是精度天花板。

② 树莓派的“毕设级”配置必须精简到骨子里。
“树莓派毕设”热搜背后，是大量冗余服务拖垮系统。赛前必须执行：

• sudo systemctl disable bluetooth（蓝牙服务常吃15% CPU）
• sudo systemctl disable hciuart（串口蓝牙模块）
• 修改/boot/config.txt：gpu_mem=16（GPU内存压到最低，留足RAM给OpenCV）
• 用raspi-config关闭桌面环境，启动即进systemd服务
• Web服务用轻量级uWSGI + Flask，禁用nginx（多一层代理=多一层故障点）

③ Arduino作为“最后防线”，必须物理隔离供电。
不能和树莓派共用5V电源！我们给Arduino单独配一路LDO（如AMS1117-5.0），输入接电池或独立DCDC。这样即使树莓派电源管理IC失效，Arduino仍能亮起红灯报警，并通过I2C向STM32发送“主控异常”信号。

2.3 传感器与执行器：别信“模块参数”，要测“系统级噪声”

“arduino智能小车”“stm32鱼缸”这类项目，成败常系于一个廉价传感器。但模块标称的“精度±1%”，在真实系统中可能变成±15%。原因在于：

• 电源噪声耦合（DCDC纹波串入传感器VCC）
• 地线共阻抗干扰（电机驱动地与ADC地未单点连接）
• 信号线辐射拾取（未用屏蔽双绞线）

我们的验证流程：
第一步：电源纯净度测试。
用示波器AC耦合档，直接测量传感器VCC对地电压。要求：

• 峰峰值纹波 ≤ 10mV（对12bit ADC，此为量化误差1LSB阈值）
• 无高频振荡（>1MHz）

第二步：地线隔离验证。
将传感器GND、MCU GND、电机驱动GND，全部引到PCB上同一铜箔区域，用0Ω电阻短接。然后用万用表二极管档测任意两点间电阻，必须＜10mΩ。若＞50mΩ，说明PCB地平面被分割，必须重铺。

第三步：信号链抗扰实测。
以“树莓派OV5647摄像头模块”为例：

• 在摄像头工作时，用手机靠近排线，观察图像是否出现条纹（检验屏蔽效能）
• 用直流电机在旁启停，观察图像是否闪动（检验电源/地隔离）
• 将摄像头供电从树莓派5V改为独立LDO，对比图像信噪比（实测提升12dB）

去年有个“基于stm32的数字温湿度计”项目，DHT22模块在实验室读数稳定，赛场却每10分钟跳变2℃。最终发现是DCDC电感磁场耦合到DHT22数据线上，加磁环+缩短走线后解决。这种坑，只能靠赛前实测撞出来。

3. 软件准备：构建“最小可行闭环”，而非堆砌功能

电赛软件最大的误区，是追求“功能完整”。我看过太多队伍，赛前一周还在调“树莓派基于ads-b的系统”，结果比赛第一天STM32的ADC采样都飘了。电赛不是产品开发，是在有限时间内交付一个可验证、可演示、可解释的最小闭环系统。这个闭环，必须包含：感知→决策→执行→反馈四个环节，且每个环节都经受过压力测试。

3.1 STM32工程：CubeMX只是起点，真正的战场在startup.s和链接脚本

很多同学以为CubeMX配置完就万事大吉。错。CubeMX生成的代码，是“能跑”，但离“可靠运行”差三个层级：启动文件、中断向量表、内存布局。

① startup.s必须手改三处：

• 堆栈大小：默认0x400太小，STM32F407建议设为0x1000（4KB），避免malloc失败
• 中断向量表偏移：若用IAP升级，必须将向量表重映射到SRAM，否则中断全失效
• 系统时钟校准：添加__HAL_RCC_PLLCLK_CONFIG(RCC_PLLCFGR_PLLN_168)确保PLL锁定

② 链接脚本（.ld文件）是隐形杀手。
默认脚本把.data段放在RAM，但未考虑DMA缓冲区冲突。我们强制规定：

/* RAM区域划分 */ MEMORY { RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K } SECTIONS { .dma_buffer (NOLOAD) : { *(.dma_buffer) } > RAM /* 其他段... */ }

并在代码中定义：

uint8_t dma_rx_buffer[4096] __attribute__((section(".dma_buffer")));

这样DMA缓冲区与堆栈物理隔离，杜绝因malloc导致DMA地址越界。

③ 关键外设必须加“心跳监护”。
例如DCDC数字PID控制，我们不只写PID算法，还加：

• 看门狗喂狗点嵌入PID计算循环（防止算法死锁）
• ADC采样值与上次偏差＞10%时触发软复位
• PWM占空比突变＞30%时记录日志并限幅

实战教训：某队DCDC输出失控，查代码发现PID积分项饱和未防溢出，int32_t累加超范围变负，占空比反向。我们在pid_calculate()函数开头加：

if (abs(pid->error) > 500) pid->integral = 0; // 大误差时清零积分，防饱和

3.2 树莓派软件：放弃“完美框架”，拥抱“够用即止”

“树莓派4b”“树莓派5 ubuntu ros2 固件”这些热搜，反映的是过度工程化倾向。电赛中，ROS2是核弹打蚊子——启动慢、资源占多、调试复杂。我们坚持：树莓派只做三件事：收数据、算简单逻辑、展网页。

精简方案：

• 数据接收：用pyserial直连STM32 UART，协议极简：$DATA,CH1,1234,CH2,5678*XX\n（校验和XX为异或和）
• 简单逻辑：温度超限报警，用if temp > 35: GPIO.output(led_pin, GPIO.HIGH)，不用MQTT发消息
• 网页展示：用Flask+Chart.js，前端JS每5秒AJAX拉一次/api/data，JSON格式：{"ch1":1234,"ch2":5678,"ts":"2023-08-20T14:30:00"}

关键技巧：“用vscode替代arduino编辑器”本质是统一开发体验。我们给树莓派装VS Code Server，所有代码（STM32 C、树莓派 Python、Arduino.ino）都在同一界面编辑，Git仓库也统一管理。避免在Keil、Arduino IDE、PyCharm间切换导致的版本混乱。

避坑重点：

• 树莓派安装luvcview？放弃。用libcamera+OpenCV直接捕获，luvcview依赖老旧，易与新内核冲突。
• 树莓派修改源？必须做！国内镜像源不稳定，我们固定用清华源，并在/etc/apt/sources.list中注释掉所有非清华源，防止apt update时随机挂掉。
• 树莓派ov5647摄像头模块？驱动必须编译进内核，不能用modprobe动态加载——比赛时insmod失败将导致整个系统无法启动。

3.3 Arduino备份系统：功能越少，可靠性越高

Arduino在此的角色是“保险丝”，不是“处理器”。我们只允许它实现：

• 读取一个电位器（模拟手动电压调节）
• 显示两位数码管（当前设定电压）
• 一个LED指示主系统状态（绿=正常，红=故障）

代码必须满足：

• 全局变量全用volatile（防编译器优化）
• loop()中禁用delay()，用millis()非阻塞计时
• 所有IO初始化后立即写默认电平（防浮空）

volatile uint16_t set_voltage = 0; unsigned long last_read = 0; void setup() { pinMode(A0, INPUT); // 电位器 pinMode(2, OUTPUT); // 数码管位选1 digitalWrite(2, LOW); pinMode(3, OUTPUT); // 数码管位选2 digitalWrite(3, LOW); pinMode(LED_BUILTIN, OUTPUT); digitalWrite(LED_BUILTIN, HIGH); // 初始红灯，待握手后变绿 } void loop() { if (millis() - last_read > 50) { // 20Hz采样 int val = analogRead(A0); set_voltage = map(val, 0, 1023, 0, 500); // 0-5V映射0-50.0V last_read = millis(); } // 数码管动态扫描... }

经验：某队Arduino用delay(10)刷新数码管，结果在电机启停时，delay被中断打断，导致显示乱码。改用millis()后，72小时无一例显示异常。

4. 环境与协同：那些没人告诉你，但决定生死的“软准备”

技术准备再扎实，若环境与协同崩盘，一样前功尽弃。电赛现场不是实验室，是充满不确定性的“作战前线”。这里没有“标准环境”，只有你主动构建的“可控环境”。

4.1 赛场环境预演：把“未知”压缩到最小

我们要求队伍在赛前两周，进行三次“全要素模拟赛”：

• 第一次（硬件层）：在教室用插线板供电，用旧笔记本当上位机，只连STM32，跑通DCDC闭环控制。目标：验证硬件链路无硬伤。
• 第二次（软件层）：加入树莓派，用screen串口调试，实现“STM32采集→树莓派解析→网页显示”。目标：验证通信协议鲁棒性。
• 第三次（环境层）：租用酒店会议室（模拟赛场空间狭小、空调噪音大、WiFi干扰强），三人同场，限时72小时，完成一道往届真题。目标：暴露协同与抗压短板。

关键预演细节：

• 电源模拟：用调压器将输入从12V逐步降至9V，观察系统是否自动降频保稳。
• 网络模拟：用iptables在树莓派上随机丢包（iptables -A OUTPUT -p tcp --dport 80 -m statistic --probability 0.1 -j DROP），测试Web页面降级策略（如断网时显示本地缓存数据）。
• 干扰模拟：在设备旁开启2.4GHz WiFi路由器、蓝牙音箱、手机热点，用示波器看STM32晶振波形是否抖动。

血泪教训：某队赛前从未测试过“树莓派无屏幕安装ubuntu”，比赛当天显示器接口损坏，队员慌乱中用ssh连接失败（因未预装openssh-server），浪费3小时重刷系统。后来我们固化流程：所有树莓派镜像预装openssh-server，并生成ssh密钥对，U盘随身携带。

4.2 团队作战手册：把“默契”变成可执行的SOP

三人组队，不是1+1+1=3，而是乘法关系。一个环节卡死，全员停滞。我们制定《72小时作战手册》，核心是三条铁律：

① 角色动态轮换制（非固定分工）

• 每24小时，三人轮换角色：
  • 主控手：专注STM32代码、硬件调试、示波器分析
  • 系统手：管树莓派、网络、Web、文档
  • 保障手：物料管理、电源维护、环境协调、后勤补给
• 轮换前，必须完成15分钟交接：当前问题、已试方案、下一步猜想、关键参数记录（如DCDC当前PID参数Kp=2.3）。

② 问题分级响应机制（杜绝无效讨论）

③ 文档即时沉淀规则（拒绝“口头约定”）

• 所有调试过程，必须用Markdown记在共享Git仓库/log/20230820.md中，格式：

  ## 2023-08-20 14:30 **问题**：DCDC输出在负载突变时跌落1.2V **已试**：① 加大输出电容（无效）② 修改PID Kd（改善但未解决） **猜想**：环路补偿不足，需调整Type2补偿网络R/C值 **下一步**：主控手计算新参数，保障手备件，系统手更新文档

• 每日22:00，三人用Zoom快速过一遍当日文档，确认无遗漏。

4.3 物料与工具包：按“战场急救包”标准配置

我们把物料包分成三级：

• 一级（贴身包）：放口袋，含：
  • 3根Micro-USB线（不同品牌，防接触不良）
  • 5个0Ω贴片电阻（应急跳线）
  • 10个10kΩ电位器（备用调节）
  • 便携万用表（带蜂鸣档）
• 二级（桌面包）：放工作台，含：
  • 可调DC电源（0-30V/5A）
  • 双通道示波器（带FFT功能）
  • 逻辑分析仪（抓SPI/I2C时序）
  • 热风枪+镊子（返修BGA芯片）
• 三级（后备箱）：存放酒店，含：
  • 备用STM32F407ZGT6核心板（预烧Bootloader）
  • 备用树莓派4B（预装系统镜像）
  • 备用DCDC模块（同型号，已测试）
  • 散热硅脂、导热垫、扎带、绝缘胶布

关键细节：“dcdc电源模块电路设计”再完美，若没备好对应封装的替换件，故障时只能干等。我们要求所有DCDC模块，必须采购同一型号的3个以上，且提前焊接测试。

5. 最后72小时：从“准备”到“临战”的心态与节奏转换

赛前72小时，是准备期的终点，也是实战期的起点。此时技术方案已定，拼的是节奏掌控力与心理稳定性。我要求队伍执行“三三制”收尾法：

5.1 第一个24小时：全面压力测试，暴露所有“隐性缺陷”

不做新功能，只做破坏性测试：

• 高温老化：把整机放入恒温箱（45℃），连续运行12小时，监测DCDC温升、树莓派CPU频率、STM32 ADC漂移。
• 振动测试：用手机震动马达绑在机箱上，模拟运输颠簸，检查所有接插件是否松动。
• 断电恢复：每30分钟强制断电一次，验证系统能否自动重启并恢复上次状态（尤其树莓派SD卡写保护设置）。

实测案例：某队在45℃老化测试中，发现树莓派USB3.0接口在高温下识别率下降至60%。紧急方案：改用USB2.0接口接摄像头，并在/boot/config.txt中添加dtoverlay=usb2强制降速，问题解决。

5.2 第二个24小时：文档与演示固化，把“知道”变成“能说”

电赛答辩，30%看作品，70%看表达。我们要求：

• 每人独立完成3分钟演示稿：
  • 第1分钟：问题定义（为什么需要这个方案？）
  • 第2分钟：技术亮点（DCDC数字PID如何提升精度？树莓派Web如何降低使用门槛？）
  • 第3分钟：实测数据（表格呈现：负载调整率、纹波实测值、Web响应时间）
• 制作“一页纸技术摘要”：A4纸，分三栏：
  • 左栏：系统框图（手绘，标注关键芯片型号）
  • 中栏：核心参数表（DCDC效率、ADC精度、Web并发数）
  • 右栏：故障树（列出3个最可能故障及排查步骤）

5.3 最后24小时：生理与心理归零，进入“作战状态”

• 生理：
  • 20:00前睡觉，保证7小时深度睡眠
  • 禁咖啡因、禁高糖食物（防血糖波动影响专注力）
  • 准备电解质水（防长时间坐姿脱水）
• 心理：
  • 删除手机所有非必要APP，只留微信（团队群）、计算器、备忘录
  • 写下三句话贴在电脑旁：

    “问题必有解，只是还没找到”
    “代码可以重写，硬件不能重来”
    “72小时后，无论结果，我们都已是赢家”

最后分享一个真实场景：去年国赛，我们队伍在第65小时发现树莓派Web页面偶发白屏。按手册P1级响应，三人15分钟内定位是Flask模板缓存冲突。主控手写临时修复补丁，系统手部署，保障手更新文档。整个过程冷静、高效、无声——这就是赛前准备赋予的底气。

电赛不是天才的秀场，而是准备者的胜利。当你把DCDC的每一个纹波、STM32的每一次中断、树莓派的每一行Python、Arduino的每一个电位器读数，都提前在真实环境中撞过墙、流过血、记过账，那么走进赛场那一刻，你不是去“比赛”，而是去“交付”一个早已验证过的答案。