搞电赛的都知道“电子设计竞赛怎么备赛”这句话每年开学都会被问上几十遍。我从大二开始参加从省二一路走到国赛带过的队伍也有七八支了。今天不聊那些虚的理论直接把从组队到四天三夜的一条完整路线摆出来每一步该干什么、该避开什么坑按着这条线走就行。先说一个很多人容易搞错的前提电赛比的不是谁理论知识最扎实而是在有限时间、有限器件、高强度压力下谁能把一个完整的电子系统真正做出来、跑起来、测出数据、写进报告。这意味着备赛的核心不是“学了多少”而是“练过多少、踩过多少坑、手里攒了多少能直接用的模块”。这篇文章适合准备参加电赛的学生队伍、刚接手指导工作的老师也适合想突击冲刺的个人。全文按备赛的时间线推进组队、训练、器件准备、四天三夜实战每一段都是实操经验不是教科书。1. 组队思路比“找大佬”更重要的是搭配1.1 三人团队的分工模型电赛规定每队三个人这三年多带队伍下来我发现一个规律三人队形如果按“硬件软件文档”来切通常是最稳的而且容错率最高。硬件位负责电路设计、PCB绘制焊接、电源调试和整机装配。这不是“会焊几根线就行”而是要懂电源拓扑、信号调理、功率放大这些基本功还得在比赛现场快速手搓出能用的电路板。软件位负责单片机程序、传感器数据读取、控制算法和上位机调试。现在的电赛题目控制类和仪器类占了很大比重软件位的实际工作量往往最大。文档位负责设计报告、测试数据记录、图表绘制和现场答辩准备。这个分工不是把三个人割裂开而是让每个人有一个明确的主战场。比赛期间四天三夜时间碎片化严重如果三个人都在抢同一个任务基本就是灾难。之前我见过一个队伍两个人都想写主控程序结果硬件没人管到了第二天晚上电路还没搭起来直接崩盘。还要提醒一点主控芯片的选择尽量避免三个人各用各的。平时训练时如果三个人分别熟悉不同厂家的MCU比赛时临时统一会很痛苦。队伍里最好确定一个主控平台比如STM32全系列或者MSP430所有备赛训练都围绕这个平台来打这样才能积累出真正能复用的代码模块。1.2 选队友时容易踩的坑选队友的标准不是“成绩最好”而是“抗压能力强”和“做事有闭环”。电赛四天三夜是一个高压环境人会暴露很多平时看不出来的问题。有的队友平时交流很顺畅一熬夜就情绪失控有的队员只在最后两天才进入状态前面的时间全在磨洋工。我建议选人时看三样东西第一有没有完整做完过一个作品不一定是电赛作品哪怕是自己焊的一个桌面小闹钟都行这说明有闭环能力第二遇到bug时是冷静排查还是立刻烦躁这决定了比赛后期队伍的氛围第三能否接受“自己的方案被推翻”电赛里方案调整非常频繁太固执的人会让队伍在决策上浪费大量时间。队伍角色还有个容易被忽略的点队长的作用不是技术最强而是做决策。四个人就没有可能------三个人加一个文档不对电赛就是三个人所以队长最好由硬件位或软件位的人兼任但必须有一种特质在意见分歧时能果断拍板。比赛期间时间非常贵开会讨论超过20分钟没有结论就应该按队长的判断直接往下走。犹豫是高压环境下最大的敌人。2. 备赛时间线把备赛当项目做2.1 四阶段备赛法如果距离比赛还有三到四个月我一般会把备赛分成四个阶段基础期、模块期、真题期、冲刺期。每个阶段有明确的产出物而不是笼统的“学一学”。基础期大约占一个半月核心目标是让三个人把基本功磨到位。硬件位要能独立完成一块双层PCB的设计和焊接能调通Buck电路和线性稳压电路软件位要能熟练使用定时器、ADC、PWM、串口中断这几个最常用的外设文档位要掌握示波器、信号源、电子负载的读数记录方法知道设计报告的标准结构。模块期约一个月核心产出是“自己的模块库”。把电赛常考的方向拆开电源类的DC-DC模块和线性稳压模块、信号类的运放调理电路和滤波电路、控制类的电机驱动和姿态传感器、仪器类的ADC采集和LCD显示。每一类都做成标准模块画好原理图、写好驱动代码、测出典型参数然后按照统一格式存档。这个阶段做的模块库就是四天三夜里“抄作业”的素材库。真题期建议安排三到四周每周完整做一道近年真题严格按照四天三夜的时间来模拟。做完之后留一天复盘统计每个环节花了多少时间、哪些模块没能直接复用、哪个环节衔接拖沓。真题的选择要有针对性如果目标是电源方向就集中刷电源类题目想做控制类就刷小车或者飞行器类题目。不建议三道题混着刷深度比广度重要。冲刺期是赛前一到两周不再做新东西只做三件事把模块库里的文档再整理一遍、把常用的PCB封装库和代码模板做最后的检查、进行一次全流程模拟拉练从读题到交报告完整走一遍。2.2 平时训练的核心原则以赛代练以模块代知识很多队伍备赛时有个问题——花大量时间去啃理论教材比如运放的稳定性分析、PID的数学推导但真正到了比赛现场这些知识很难直接转化为作品。我个人的体会是电赛的训练一定要围绕“模块”来组织而不是围绕“知识体系”。举个具体的例子。PID控制这种控制类题目绕不开的东西理论推导很复杂但比赛中你需要的是“怎么让它跑稳”。重点练的是如何把PID参数存到MCU里、如何在调试时通过串口实时观察反馈值、如何处理传感器数据里的噪声和毛刺。这些能力靠的是反复上手调不是靠推公式推出来。每次训练结束后还要强制做一件事整理调试日志。很多队伍训练完就散了下次遇到同一类问题又从零开始。如果每次训完都把“问题现象、排查过程、最终原因、解决方法”四条记下来几轮训练下来队伍的问题库就会非常厚。这是比赛中找bug最快的信息源。2.3 器件与工具准备清单工具方面每个人至少要有自己顺手的焊台建议带数显调温的、万用表、风枪用于拆IC和BGA虽然比赛一般不会动BGA但总有意外。队伍共用的大型仪器里示波器必须有两台以上四天三夜时两个人同时调波形是常态稳压电源至少三路输出电子负载有条件就带电源题目测负载调整率的时候没有它会非常痛苦。器件方面分几个大类需要提前囤主控平台STM32F103系列和STM32F407系列各备两到三块最小系统板407的运算速度在姿态解算这类任务中很吃香。电源芯片LM2596、TPS5430、AMS1117-3.3/5.0、MC34063每种至少备五片以上。电源题目喜欢用Ti的芯片平时训练要专门练熟一两种Ti的DC-DC。运放与比较器OP07、LM358、NE5532、LM393仪表放大器INA128或AD620也要备。运放是电赛信号题的灵魂没它不行。传感器MPU6050姿态、红外对管和编码器测速、PT100和热电偶模块温度、电流传感器ACS712测流按队伍主攻方向重点配置。电机与驱动直流减速电机带编码器准备多套TB6612和DRV8870驱动芯片各备几片舵机和步进电机也各留一套。显示器与交互OLED屏I2C和SPI接口各备、12864液晶、矩阵键盘、旋转编码器。器件清单里必须强调一件事凡是比赛现场可能用到的小零件比如排针、杜邦线、电阻电容套装、不同规格的保险丝都要按“再犯一次错也够用”的量备好。四天三夜期间一个队伍的奥德赛往往不是卡在方案设计上而是卡在“xxx器件现场只剩最后一个还烧坏了”这种事上。每类易损器件我建议至少备两到三套冗余。3. 四天三夜的战术前6小时定生死3.1 选题决策的实操方法四天三夜真正进入主题第一天上午是最紧张也是最关键的时段。我的经验是拿到题目后的前两小时三个人不要立刻动手一定要坐下来把全部题目读完然后在白板上做一次系统的选题评估。评估维度有四项一是团队能力匹配——这道题的核心技术点是不是我们模块库里有积累的二是器件齐备度——题目标注不可替换的器件比如指定了某些芯片型号手里有没有现货没有的能不能在半天内搞到替代三是工作量评估——四天时间要做完完整的硬件搭建、软件调试、指标测试和设计报告估算下来是否有余量四是风险点识别——题目中哪些指标很容易刷不达标比如电源题的效率、控制题的精度这些关键参数有没有做过类似的经验数据。有些队伍选题目喜欢挑分数高的这是大忌。电赛的分数跟题目难度和你的完成度直接挂钩你做一个完成度普通的难题往往比做一个完成度很高的基础题分数低。我带过的队伍里拿省奖最多的往往不是选难题的那批而是把中等难度的题目做得滴水不漏的那批。3.2 四天时间分配参考表我常跟队员强调一句话四天三夜的时间池是有限的但不要把它均分。根据多轮模拟赛的经验我整理过一份时间分配参考表实战效果还不错分享出来第一天约16小时上午选题并确定整体方案下午开始搭建系统框架。硬件位焊主控板和电源板的最小系统软件位搭好工程模板和底层驱动框架文档位开始写“系统方案篇”的草稿。当晚最迟12点前要让最小系统跑起来LED闪烁就是里程碑。第二天约18小时这是模块联调的黄金期。上午把各功能模块逐个接入主控软件和硬件协同调试下午开始调核心功能比如控制类的小车循迹、电源类的闭环稳压晚上把大部分功能跑通留出一天的缓冲时间。第三天约20小时上午补测所有硬指标把速度、精度、效率等参数测好并记录下午做报表数据、完善设计报告里的结果分析和图表晚上进行整体系统的抗干扰测试和反复跑通把可能出现的问题提前排掉。第四天约12小时最后的完善和封装重点检查结构是否稳固、线缆是否松动、代码是否需要最后的注释写结题报告最终版反复核对题目要求的每一项是否完成。这个时间表的核心思想是前三天必须完成主要功能最后一天只做优化和收尾绝不把新功能留到第四天。3.3 分模块联调与系统整合方法电赛现场最容易出问题的不是单个模块不会用而是模块之间连在一起后出现莫名其妙的互相干扰。分模块联调是解决这个问题最好的办法。具体做法是这样先把主控最小系统跑起来通过串口打印或者LED指示确认各外设驱动正常然后逐个接入功能模块每接入一个就立即做一次全链路测试比如接上传感器就通过串口观察数据是否符合预期接上驱动电机就检查供电线是否会被拉低、是否产生干扰脉冲确认正常后才进入下一个小模块。全部模块都联调通过后再进入整体联调。整体联调阶段要做几次“全流程跑通”模拟比赛那天实际测试的环境看看整套系统能不能稳定工作。控制类题目特别注意连续跑五次、跑十次如果中间有一次失败就要找出是偶发还是必然问题。往往问题都是在“再跑一次”的时候暴露的。另外非常建议从比赛第一天开始就建立一个共享文档记录每块模块的状态。谁调试过、发现问题是什么、是否解决、解决人是谁都写清楚。四天时间很短记忆衰退很快有不记录的队伍经常会在半天后重复解决同一个问题。3.4 突发情况的应急预案四天三夜不可能一帆风顺我见过的突发情况太多了电源短路烧毁芯片、代码在保存时损坏、传感器瞬间失灵、整机跌落导致接线断裂。关口就是平时多准备几份“备份”。硬件端的应急预案很简单所有关键模块至少两套关键芯片MCU、驱动、ADC至少三片以上。上电前养成“看电流”的习惯稳压电源先设定在较低电流档然后逐渐增加发现电流飙升立即断电这样可以避免不少芯片白烧。焊接时注意静电防护我见过半夜赶工焊板子没放静电手环直接把一片新MCU静电击穿的。软件端必须有版本管理。哪怕不用Git也要每隔几个小时手动备份一次代码和工程文件存放在两个不同的设备里。比赛现场的电脑如果突然死机没备份对队伍来说就是毁灭性打击。我自己习惯用一个U盘专门做“每完成一个功能就备份一次”的冷备份同时把配置好的代码模板上传到云盘。现场心理层面的预案同样重要。赛前就约定一个原则如果出现短时间无法解决的bug先换成备用方案或降级实现不要把时间死磕在一个局部问题上。比如控制精度不达标先不要拼命调PID可以检查传感器安装是否牢固、供电是否充足这些更基础的环节。比赛中“看似高级的问题往往是低级的原因导致”的情况出现频率高得惊人。4. 常见问题与排查技巧实录4.1 硬件故障排查顺序硬件问题排查的顺序我总结为先供电、再信号、后逻辑。不要一上来就怀疑主控程序大部分硬件异常都能从供电源头找到原因。先说供电排查。上电异常时第一件事是测电源输出是否正常电压值对不对带负载后有没有跌落纹波大不大。曾经有一个队伍的小车原地转圈排查了半天最后发现是电源线杜邦线虚接接触电阻导致驱动芯片供电不足。这类问题的典型特征就是“系统时而正常时而异常”基本都跟接触和压降有关。再是信号链路排查。用示波器量关键信号点的波形和预期的做个对比。比如传感器输出信号在无遮挡时应该是高电平实际量出来却是乱跳就可能是上拉电阻问题或者信号被干扰。信号链一路上每个环节都看一遍通常就能定位到具体恶化点。最后才是逻辑排查。确认硬件电路没问题、供电正常后才开始怀疑代码里的逻辑bug。很多时候是中断优先级配置有问题或者ADC采样时序不对。这类问题不要靠猜直接用串口打印关键变量看程序实际走到的分支。4.2 软件调试的三个高频雷区软件调试里最常见的雷区有三个方面都是我在带队伍时反复遇到的第一是ADC采样数据不稳定。很多同学读出来的传感器数据跳变非常厉害其实原因往往不是传感器不行而是没有用平均滤波或滑动滤波。比赛现场时间紧不要现写复杂滤波算法用最朴素的先采集10次取平均值就能解决很大一部分问题。第二是PID调节调不出来。比赛里PID调不好的队伍非常多反思下来往往是因为先检查硬件问题了没有、传感器反馈值是否准确、PWM输出通道绑定是否正确。如果这些基础环节没问题PID参数调不出来大概率是“没有做积分限幅”或者“P值太大引发震荡”。我建议赛前就准备好一套“先P后I再D”的调参流程并打印每一步的效果不要调一会儿就换一种策略乱试。第三是程序跑飞或死机。晨会白天都好好的凌晨突然不断复位。排查思路是检查是否有数组越界检查中断服务函数里是否有耗时过长的代码检查看门狗是否溢出。尤其是用STM32的时候串口中断里如果有printf这种耗时函数就很容易拖垮系统。4.3 团队协作中的协作问题排查四天三夜开始后团队状态会随时间变化。第一天大家都精神振奋第二天晚上开始疲劳第三天凌晨最容易出现争执第四天是又疲惫又紧张的状态。处理团队问题要有几套预案。争执的根源多半是方案分歧。我的建议是赛前就约定“队长拥有一票决定权”任何技术路线争议限时15分钟讨论没有定论就按队长方案执行。这听起来有点一言堂但在高压力场景下快速达成一致比追求最优方案重要得多。体力管理方面我建议队伍采用“三班倒”式的作息策略但不要在白天分得太散。前三天的主要工作时间依然在白天晚上至少保证两个人在状态下推进任务一个人轮流休息四五个小时。把最容易出错的高风险操作比如焊接新板子、调整关键参数尽量安排在状态好的时段进行。文档位在团队中承担的压力容易被低估。赛的第二天开始就要把设计报告的数据表格、波形截图、测试环境描述逐步填充起来不要等到最后一天才开始写。很多队伍的文档位到最后一天才发现数据和测试记录不够只能临时补测质量大打折扣。5. 电赛之后还有一件重要的事复盘比赛交完作品、走出赛场整个备赛周期也还不算真正结束。如果花了几个月时间备赛却只是拿一个奖项回来其实亏了。我建议每支队伍在比赛结束后的两周内趁记忆还新鲜认真做一次复盘把“备赛计划与实际执行之间的偏差”“四天三夜中的关键决策点”“模块库中哪些模块真正复用了、哪些计划了但没有用上”“个人和团队的短板在哪里”这四个问题问一遍把答案写下来。这个总结比拿奖本身更有价值。这个复盘文档还有一个潜在用途——保研、考研复试、找工作的面试时你手里能拿出的“项目成果”绝不是一个奖状而是你关于这套系统从设计到实现、从问题排查到方案迭代的完整经历。面试官真正关心的是你有没有独立解决过复杂问题的能力。用复盘文档把这些过程讲清楚就是最好的证明。我带过的一个队员当年拿的是省二放在一堆省一国一的简历里根本不起眼。但他把四天三夜里“电源模块反复烧毁、最后通过改进热设计解决问题”的完整经历讲得极其清楚面试官当场就给了很高的评价。这就是复盘的含金量。最后再分享一个我个人的小习惯每次备赛周期开始前把上一年的模块库、问题库、复盘报告翻出来过一遍。电赛的题目每年都在变但底层的技术栈和团队协作逻辑变化不大。你手里积累的每一条经验、每一个踩过坑的记录都是下一年备赛最值钱的东西。