第一次参加电赛的队伍体验往往不是从“兴奋”开始而是从“迷茫”开始学期初不知道要练什么题目公布后不清楚该先画板还是先写代码做完一版又发现电源纹波超限、ADC 数值乱跳、通信偶尔丢帧。这篇复盘不提供某个赛题的源码也不承诺按步骤就能拿奖而是把第一次参赛最容易忽略、也最影响结果的一整套流程梳理清楚备赛分工、工程环境、软硬件设计、功能测试、现场排错和时间管理。如果你正准备参加下一届电赛或者已经在备赛但进度有些乱可以直接收藏本文。文章偏工程实操适合承担硬件设计、嵌入式软件、算法调试或项目统筹的同学。看完之后你至少能回答三个问题赛前到底要准备什么赛题下发后怎么拆解任务评测之前为什么必须做分级测试。1. 核心能力速览一支电赛队伍需要哪些工程能力电赛比的不只是“谁的板子焊得快”也不是“谁的代码写得长”而是把需求、电路、代码、测试串成一条稳定流水线的工程能力。第一次参赛最容易低估的恰恰是那些看起来不起眼的环节数据手册阅读、接口定义、版本管理、电源测试、异常日志。从竞赛项目化管理的角度看一支队伍需要具备以下能力模块。能力模块关键任务常用手段硬件设计电源电路、传感器接口、驱动电路、PCB 绘制数据手册阅读、原理图设计、万用表/示波器调试嵌入式软件初始化外设、采集传感器、执行控制逻辑定时器、中断、ADC、DMA、状态机设计算法与数据处理数值滤波、标定、PID、逻辑判定Python/Matlab 离线仿真、MCU 在线调试项目管理任务拆解、进度控制、方案备份Git 版本管理、Checklist、阶段评审、测试记录文档与合规设计文档、测试记录、规则核对Markdown、表格记录、开源许可检查、实验室安全规范需要注意这五个能力模块不是五个人的分工。三人队伍通常要把一个模块拆成多个小任务不同人互相交叉。硬件负责人必须知道软件需要几个采样通道、通信协议用什么格式软件负责人也必须知道电源能提供多大电流、信号调理后输出范围是多少。第一次参赛的很多返工都来自模块之间的“接口没有谈清楚”。2. 适用场景与使用边界这篇文章更适合以下场景第一次参加全国大学生电子设计竞赛或同类校级、省级电子竞赛的队伍正在备赛项目实践课程的团队以及想用竞赛驱动的个人/小组完成一个完整电子系统的同学。它能帮大家梳理完整流程但不会替代你们所在赛区的赛题规则和器件限制。每个赛题都有自己的“隐含边界”比如题目规定了能够使用的电源电压、最高工作频率、是否允许使用成品模块、是否需要自己制作印制板等。这类信息必须以官方发布的最新规则为准不能因为某篇网络博客里这么写就直接照做。竞赛实践还需要遵守基本安全边界带电操作前确认电源关闭避免短路和触电。使用大功率器件时注意散热、电流余量和导线载流能力。使用无线模块时应按赛题规定选择频率和功率不干扰其他队伍。查阅并遵守竞赛章程不采用任何作弊手段。引用开源代码、别人的原理图或算法库时保留版权声明并遵守相应协议。不要拍摄和传播可能涉及他人隐私、竞赛保密要求的内容。第一次参加电赛确实容易焦虑但焦虑不能成为省略安全流程的理由。越是在时间紧张时越要用清单约束操作。3. 赛前准备与工程环境搭建3.1 三人先对齐任务边界电赛传统上按三人一队组织但三个人不能简单地分成“硬件、软件、算法”三个孤岛。更合理的分工方式是确认一人担任系统架构和总进度负责人另外两人分别负责硬件链路和软件链路同时有人专门负责文档、测试与现场设备管理。在第一周队伍需要共同输出一份“支持范围清单”越具体越好当前掌握的开发板型号和下载调试方式是什么。常用的传感器、电源、驱动模块是否有一份备用库存。每个模块是采购现成开发板还是需要自己做板。软件编译环境是否已经在两台以上电脑上跑通。测试用的电源、示波器、万用表、信号发生器是否能在固定时间段使用。如果这些内容开学第一周都不清楚后面很容易进入“边找器件边写代码”的状态。真正的赛题阶段只有几天临时找硬件、临时装编译器都会大量消耗时间。3.2 统一开发工具链第一次备赛不需要追求最新版本的开发环境但需要尽早统一选择队伍成员最熟悉的 EDA 工具做原理图和 PCB避免多人协作时互相打不开。选择与开发板匹配的编译环境并固定芯片型号、固件库版本。如果使用代码生成工具要约定先改配置再重新生成代码避免手动改完 MCU 配置后被自动生成覆盖。文档统一使用 Markdown 或可直接导出的 Word 模板放在同一目录下。工具链统一的好处是减少“能在我电脑上跑到另一台电脑上就不行”的问题。尤其是库文件路径、下载器驱动、版本号不一致现场换电脑时非常痛苦。3.3 从第一天就启用版本管理很多队伍是最后一天才用“最终的最终版_v7.rar”来管理代码。电赛现场容易出现临场改参数、恢复旧逻辑的场景没有版本管理会非常被动。比赛阶段建议至少保留一套 Git 仓库代码和文档一起跟踪。# 初始化代码仓库 git init # 每完成一个可编译功能节点就提交一次 git add . git commit -m v0.1 电源模块初始化完成 # 打标签记录关键版本 git tag v0.1_power_test # 重大改动前创建新分支 git checkout -b feature/sensor_calibration # 确认新分支稳定后再合并回主分支 git checkout main git merge feature/sensor_calibration即使团队不会用复杂的分支模型至少做到“每个实现阶段都 commit 一次”。调坏代码时能立刻回滚到上一个可用版本这一点对后期心理状态非常重要。4. 赛题选择与方案设计赛题下发后的第一个小时不要急着动手接线。先做“读题—提取指标—方案评估”。4.1 把自然语言转成指标表题目里的“基本要求”和“发挥部分”往往是模糊的表达需要逐条翻译成可测量、可验证的技术指标。比如要求“尽可能稳定”就应该转化为“在输入电压波动 X% 范围内输出偏差不超过 Y%连续运行 30 分钟关键参数在 Z 区间内”。这一类具体数据来自题目本身或现场测量条件不能写成模糊的主观感受。建议用表格区分需求优先级需求类型例子优先级核心功能能采集某类信号并显示结果必须完成精度要求测量误差限制在一定范围内必须完成附加功能能联网上报、语音播报尽量完成加分展示界面美观、交互友好最后考虑先保证核心链路能够跑通再做“锦上添花”的功能。第一次参赛最容易出现的错误是把时间花在了上位机界面或某颗传感器的精确选型上结果主控部分连最基础的闭环还没有完成。4.2 做一张风险表拿到题目后可以立刻组织一次短会评估每个子任务的风险。风险高不是不能做而是要提前准备备选方案。风险来源典型影响预防措施主功能工作量估错基础功能都完不成先做最小可运行闭环再逐步扩展精度/线性度不足评测失分提前做多组数据标定必要时提高 ADC 分辨率或增加硬件调零大功率器件发热电压跌落、器件损坏提前用假负载测试留温度裕量模块间地环路干扰采样值跳动检查接地方式避免功率回路与信号回路共用一段长导线题目风险点识别不足现场临时换方案方案评审时故意挑毛病逐一列出失效模式风险评估不是会议记录而是要在每个模块启动之前落地为具体动作。比如“防止采样值跳动”对应的动作就是“先分别测量传感器在空载和电机启动时的读数变化”。否则风险表只是挂在墙上的一页纸。5. 软硬件开发流程与工程组织5.1 先统一接口定义再写代码电赛团队合作困难经常是因为接口未经定义就各自开工。比如传感器模块输出的是模拟电压还是数字信号范围是多少通信波特率是多少数据帧格式是什么电机驱动板的使能脚是高有效还是低有效这些问题在画原理图之前就应该约定。一个简单做法是建立“接口文档”内容包括每个外设芯片或模块的供电电压、输入输出范围。主控与子模块之间的通信协议包括波特率、字节序、超时时间。关键 GPIO 的功能分配表尽量把不同类型的信号分开放置。电源域划分避免模拟信号和功率地混为一条杂散路径。接口文档不需要很长但需要随开发进度维护。等到联调时再发现两个模块“各说各话”排查成本往往会超过正常开发成本。5.2 项目目录保持清晰很多 MCU 工程一开始只有一个main.c最后变成几千行单文件。现场调参时改一个变量可能影响好几个中断服务函数风险极高。建议在建立工程时就开始按模块拆目录。以常见嵌入式工程为例目录可以是project/ ├── Core/ # 启动文件、时钟配置 ├── Drivers/ # 芯片外设驱动 ├── App/ │ ├── sensor.c │ ├── control.c │ └── display.c ├── Test/ # 测试脚本、日志文件 ├── Docs/ # 接口文档、调试记录 └── .gitignore这里的App是业务逻辑层Drivers是芯片底层库Test放测试脚本和采集日志。核心逻辑不要直接堆在中断回调里尽量拆成独立函数方便后期加日志或做单元验证。5.3 用状态机管理应用流程对于电赛这种“采集—计算—控制—显示”的循环流程用简单的状态机比一大堆 if-else 更容易定位问题。typedef enum { APP_IDLE, APP_SENSOR_ACQ, APP_CTRL_UPDATE, APP_DATA_SEND } AppState; AppState state APP_SENSOR_ACQ; while (1) { switch (state) { case APP_SENSOR_ACQ: // 读取传感器并完成滤波 state APP_CTRL_UPDATE; break; case APP_CTRL_UPDATE: // 执行控制算法 state APP_DATA_SEND; break; case APP_DATA_SEND: // 串口输出或屏幕刷新 state APP_IDLE; break; default: state APP_SENSOR_ACQ; break; } }这段代码不是唯一正确答案但它展示了一个容易被忽略的原则主流程必须可理解、可打断、可加日志。第一次参赛时调试不可见通常是因为程序逻辑本身混在一起缺少清晰的观察点。6. 功能测试与效果验证6.1 模块级验证先行每次把新的硬件/代码接入系统前先做模块级验证电源模块先在空载和额定负载下测试输出电压是否稳定再用示波器看纹波是否在可接受范围内。传感器模块固定输入条件连续读取若干次记录最大值、最小值和平均值判断是否需要软件滤波。通信模块在没有业务逻辑干扰的情况下循环收发数据确认不丢帧。驱动模块先用信号发生器等工具模拟控制输入确认输出逻辑正确再接真实执行器。“先验证模块再联调系统”听起来简单但第一次比赛时很多人会跳步。跳过模块测试的代价是系统某一处表现出问题后你根本不知道是该调算法还是该修硬件。6.2 把测试条件量化功能测试不能以“看起来正常”为通过标准每个测试都要写清输入条件、检查项和通过标准。例如记录如下测试矩阵。测试组输入条件检查项通过标准输入电源低电压边界用可调电源设置最低工作电压单片机复位、界面刷新、指示灯状态连续运行 10 分钟无复位传感器线性度依次给标准量记录读数测量输出与标准量差值偏差小于题目允许范围通信压力每秒发送一帧持续 5 分钟接收端统计丢包丢包率为 0控制曲线跟踪设定目标值并变化实际输出跟随时间超调量和调整时间满足要求通过标准必须可测量、可复核。现场评测时测试员往往会加一些边界条件比如快速切换档位、长时间连续运行。没有提前做过边界测试的系统很容易在评测现场暴露出只在特定条件下的 bug。6.3 电赛场景下的接口和批量测试电赛系统和互联网后端不同通常没有 HTTP API 和任务队列真正重要的是芯片之间的接口协议以及多组输入样本的连续测试。如果赛题包含通信功能建议单独编写一个“回环测试”主控发一帧数据另一个模块收到后原样返回主控校验内容是否一致。对于测量、控制类赛题不建议只测一两组数据。要把测试过程固化成连续样本并让串口输出结构化日志。time1200, voltage3.298, current0.012, stateOK time1250, voltage3.271, current0.014, stateWARN time1300, voltage3.299, current0.011, stateOK结构化日志可以保存到文件再用 Python 离线分析避免靠人眼看串口助手里的几千行数据。import re fail_count 0 with open(test_log.txt, r, encodingutf-8) as f: for line in f: match re.search( rvoltage([\d.])V, current([\d.])A, line ) if match: voltage float(match.group(1)) current float(match.group(2)) if not (3.1 voltage 3.4): fail_count 1 print(voltage out of range count:, fail_count)这样的脚本不需要很复杂关键是帮助队伍快速判断长时间运行是否稳定。第一次比赛时如果每个模块都有人工记录数据最后汇总时很难发现问题。用日志和脚本处理至少能让测试结果变得可复现。6.4 第一次联调要有明确顺序系统联调不能把“所有功能全部打开”当作第一步。建议顺序是跑通最小系统开发板能下载程序串口能输出调试信息。单模块闭环只接一个传感器和一个执行器验证开环逻辑。加控制算法先用手动模式确认执行器方向正确再进入自动模式。增加复杂交互加入按键、菜单、显示、通信等外围功能。回归测试改完一个功能后快速重跑一遍已通过的测试用例。第一次联调最容易出错的地方是把传感器数据、控制算法和显示刷新全部放在同一时刻处理造成相互延迟。建议用定时器划分不同任务周期比如传感器采样循环、控制计算循环、显示刷新循环分开避免一个任务占用过长时间导致其他任务超时。7. 资源占用与性能观察很多电赛队伍只关心代码能不能跑不关心 Flash、RAM、定时器和中断资源是否够用。等到功能越加越多程序可能出现莫名复位或执行顺序错乱。建议预留一段时间做资源盘点。资源维度查看方式常见瓶颈Flash 空间编译输出信息、MAP 文件固件库全功能开启后体积膨胀RAM 空间编译器链接报告、运行时栈检测大数组、缓存、多任务堆栈叠加外设资源引脚分配表、定时器/DMA通道表GPIO 和功能外设引脚冲突时钟与中断调试器查看中断触发计数中断频率过高或长时间占用主循环功耗与散热可调电源实时电流/电压显示大功率驱动连续工作发热比如测量类赛题可能会频繁触发 ADC 和 DMA 搬运。如果每个中断服务函数里都做耗时较长的浮点运算采样间隔可能不稳定最终表现为测量结果抖动。要观察这类问题最简单的方式是在固定任务开始和结束时切换一个 GPIO用示波器测量该 GPIO 的脉冲宽度从而判断任务执行耗时。功率类和驱动类题目还要重点看电源在动态负载下的表现。电机启动瞬间电流可能明显高于稳态电流如果稳压电路响应速度不够MCU 可能瞬间复位。评测现场大量板子因为共用地线、电源余量不足而出现“明明写好的程序放在展台上就乱跳”第一次参赛尤其要重视这个坑。8. 常见问题与排查方法电赛调试过程中遇到的绝大多数问题都不是“玄学”而是缺少合适的观察手段。下面的排查表可以作为通用参考。现象可能原因排查方式解决方向程序烧录不进去下载器驱动异常、目标供电不足、占用芯片引脚检查下载器连接和供电查看编译器报错重新安装驱动检查最小系统供电模块接上去后 MCU 不工作电源被拉低、模块电流过大测量模块供电电压断开模块单独跑 MCU增加独立电源或降低模块负载ADC 数据跳动严重采样抖动、信号源内阻高、布线引入干扰固定输入并连续打印原始值增加滤波电容软件做滑动平均通信偶尔丢帧波特率偏差、中断竞争、共地不足短距离回环测试打印接收错误标志统一参考地降低发送频率控制方向反了执行器接线、逻辑符号取反先开环测试观察执行器方向调整占空比极性或交换接线功能一多主循环变慢中断太频繁、显示刷新阻塞用 GPIO 翻转法测任务耗时分频采样、优化刷新逻辑调试正常、放到评测台上失败现场电源、信号源与实验室不一致提前用多组电源/信号源复测按最不利条件做边界测试代码改一处其他模块也崩全局变量耦合严重、堆栈溢出代码评审检查可能越界的数组模块化封装限制全局变量出现异常现象后不要立刻随机改代码。先把现象用一句话写清楚再列出可能影响该现象的全部变量让其中一个变量产生改变其他变量保持固定。真正难解决的问题大多不是方案复杂而是团队没有确定变量做了一次“东改一下、西改一下”的无效调试。如果现场遇到“调试环境正常但换一台设备不行”的问题优先检查双方供电电压、接线顺序、通信波特率和参考地是否完全一致。电赛评测环境和实验室环境不同使用笔记本电池供电、独立 USB 转串口、外部可调电源都可能改变地平面和干扰情况。9. 时间管理如何避免“很迷茫”的状态第一次参赛的“很迷茫”本质上是任务不可见。只知道最终目标是做出一个题目要求的系统但不知道每天该推进什么。破解方法不是更多熬夜而是把赛程做成倒排计划。赛题下发后的时间通常非常紧凑无论赛程是三天还是四天都需要倒推关键节点第 1 个半天只做读题、指标拆解、方案评审和接口定义不写代码、不接线。第 1 个 1/4 时间完成电源、采样、执行器的最小硬件链路跑通点灯级别的程序。第 2 个 1/4 时间把核心信号从传感器端读到逻辑处理端能完成开环动作。第 3 个 1/4 时间加入闭环控制和自动逻辑替换算法参数提升精度。最后 1/4 时间回归测试、写文档、整理现场检查单不再做高风险改动。如果进度落后优先砍“附加功能”保留“核心链路”。例如题目需要显示波形、曲线和数据记录但如果测试时间不够可以先实现简单数值显示停止做高分辨率绘图界面。很多队伍在最后半天因为坚持做上位机界面导致核心控制参数没有调优在评测现场反而失分。每天结束时用十分钟更新“任务状态表”哪些任务已经完成对应测试记录在哪。哪些任务正在进行负责人是谁。哪些任务已经卡住卡在哪个模块需要什么条件才能推进。明天优先级最高的一件事件是什么。第一次参赛时最容易出现的情况是三个人都很累但互相不知道对方在做什么。任务状态表不是给老师看的也不是最终文档的一部分而是让队伍内部随时知道当前可运行版本是什么、下一份可交付成果是什么。迷茫感大部分来源于不确定性当任务被拆到明天可以动手验证时焦虑就会明显下降。10. 复盘很累很迷茫但值得现在回头看第一次参加电赛的那一学期多数记忆不是颁奖时刻而是某个晚上反复调不通信号的挫败以及离截止时间越来越近时的无力感。赛前觉得别人什么都懂赛题出来后才发现很多题目要求也需要临时查手册自己并没有想象中那么准备不足。那些“卡了很久才通过”的问题最后都变成了判断问题的直觉。电赛真正留下的财富不是一块奖状或一个决赛名额而是一套被验证过的工作方法赛前先准备工具链和版本管理赛题下来先拆指标和风险设计阶段先定接口测试阶段先留日志。这套方法在未来的毕业设计、工作项目和研究生科研中都会不断复用。如果你还在迷茫期建议不要等到“完全准备好”再报名参赛。准备得再久赛题也会抛出意料之外的要求。第一次参赛的最大收益是让你知道自己离“能够独立完成一个电子系统”还差哪些具体能力然后愿意把每个环节按工程流程去补齐。等下一届赛题公布的时候从第一天就能 Git、第一晚就出接口文档、第一次联调就留结构化日志的队伍往往不会太慌。把这一整套流程跑完你也会发现这学期确实很累过程确实迷茫但最后亲手调试出的系统稳定运行、数据正确落在测试表里时之前的付出都是值得的。
第一次参加电赛的队伍体验往往不是从“兴奋”开始而是从“迷茫”开始学期初不知道要练什么题目公布后不清楚该先画板还是先写代码做完一版又发现电源纹波超限、ADC 数值乱跳、通信偶尔丢帧。这篇复盘不提供某个赛题的源码也不承诺按步骤就能拿奖而是把第一次参赛最容易忽略、也最影响结果的一整套流程梳理清楚备赛分工、工程环境、软硬件设计、功能测试、现场排错和时间管理。如果你正准备参加下一届电赛或者已经在备赛但进度有些乱可以直接收藏本文。文章偏工程实操适合承担硬件设计、嵌入式软件、算法调试或项目统筹的同学。看完之后你至少能回答三个问题赛前到底要准备什么赛题下发后怎么拆解任务评测之前为什么必须做分级测试。1. 核心能力速览一支电赛队伍需要哪些工程能力电赛比的不只是“谁的板子焊得快”也不是“谁的代码写得长”而是把需求、电路、代码、测试串成一条稳定流水线的工程能力。第一次参赛最容易低估的恰恰是那些看起来不起眼的环节数据手册阅读、接口定义、版本管理、电源测试、异常日志。从竞赛项目化管理的角度看一支队伍需要具备以下能力模块。能力模块关键任务常用手段硬件设计电源电路、传感器接口、驱动电路、PCB 绘制数据手册阅读、原理图设计、万用表/示波器调试嵌入式软件初始化外设、采集传感器、执行控制逻辑定时器、中断、ADC、DMA、状态机设计算法与数据处理数值滤波、标定、PID、逻辑判定Python/Matlab 离线仿真、MCU 在线调试项目管理任务拆解、进度控制、方案备份Git 版本管理、Checklist、阶段评审、测试记录文档与合规设计文档、测试记录、规则核对Markdown、表格记录、开源许可检查、实验室安全规范需要注意这五个能力模块不是五个人的分工。三人队伍通常要把一个模块拆成多个小任务不同人互相交叉。硬件负责人必须知道软件需要几个采样通道、通信协议用什么格式软件负责人也必须知道电源能提供多大电流、信号调理后输出范围是多少。第一次参赛的很多返工都来自模块之间的“接口没有谈清楚”。2. 适用场景与使用边界这篇文章更适合以下场景第一次参加全国大学生电子设计竞赛或同类校级、省级电子竞赛的队伍正在备赛项目实践课程的团队以及想用竞赛驱动的个人/小组完成一个完整电子系统的同学。它能帮大家梳理完整流程但不会替代你们所在赛区的赛题规则和器件限制。每个赛题都有自己的“隐含边界”比如题目规定了能够使用的电源电压、最高工作频率、是否允许使用成品模块、是否需要自己制作印制板等。这类信息必须以官方发布的最新规则为准不能因为某篇网络博客里这么写就直接照做。竞赛实践还需要遵守基本安全边界带电操作前确认电源关闭避免短路和触电。使用大功率器件时注意散热、电流余量和导线载流能力。使用无线模块时应按赛题规定选择频率和功率不干扰其他队伍。查阅并遵守竞赛章程不采用任何作弊手段。引用开源代码、别人的原理图或算法库时保留版权声明并遵守相应协议。不要拍摄和传播可能涉及他人隐私、竞赛保密要求的内容。第一次参加电赛确实容易焦虑但焦虑不能成为省略安全流程的理由。越是在时间紧张时越要用清单约束操作。3. 赛前准备与工程环境搭建3.1 三人先对齐任务边界电赛传统上按三人一队组织但三个人不能简单地分成“硬件、软件、算法”三个孤岛。更合理的分工方式是确认一人担任系统架构和总进度负责人另外两人分别负责硬件链路和软件链路同时有人专门负责文档、测试与现场设备管理。在第一周队伍需要共同输出一份“支持范围清单”越具体越好当前掌握的开发板型号和下载调试方式是什么。常用的传感器、电源、驱动模块是否有一份备用库存。每个模块是采购现成开发板还是需要自己做板。软件编译环境是否已经在两台以上电脑上跑通。测试用的电源、示波器、万用表、信号发生器是否能在固定时间段使用。如果这些内容开学第一周都不清楚后面很容易进入“边找器件边写代码”的状态。真正的赛题阶段只有几天临时找硬件、临时装编译器都会大量消耗时间。3.2 统一开发工具链第一次备赛不需要追求最新版本的开发环境但需要尽早统一选择队伍成员最熟悉的 EDA 工具做原理图和 PCB避免多人协作时互相打不开。选择与开发板匹配的编译环境并固定芯片型号、固件库版本。如果使用代码生成工具要约定先改配置再重新生成代码避免手动改完 MCU 配置后被自动生成覆盖。文档统一使用 Markdown 或可直接导出的 Word 模板放在同一目录下。工具链统一的好处是减少“能在我电脑上跑到另一台电脑上就不行”的问题。尤其是库文件路径、下载器驱动、版本号不一致现场换电脑时非常痛苦。3.3 从第一天就启用版本管理很多队伍是最后一天才用“最终的最终版_v7.rar”来管理代码。电赛现场容易出现临场改参数、恢复旧逻辑的场景没有版本管理会非常被动。比赛阶段建议至少保留一套 Git 仓库代码和文档一起跟踪。# 初始化代码仓库 git init # 每完成一个可编译功能节点就提交一次 git add . git commit -m v0.1 电源模块初始化完成 # 打标签记录关键版本 git tag v0.1_power_test # 重大改动前创建新分支 git checkout -b feature/sensor_calibration # 确认新分支稳定后再合并回主分支 git checkout main git merge feature/sensor_calibration即使团队不会用复杂的分支模型至少做到“每个实现阶段都 commit 一次”。调坏代码时能立刻回滚到上一个可用版本这一点对后期心理状态非常重要。4. 赛题选择与方案设计赛题下发后的第一个小时不要急着动手接线。先做“读题—提取指标—方案评估”。4.1 把自然语言转成指标表题目里的“基本要求”和“发挥部分”往往是模糊的表达需要逐条翻译成可测量、可验证的技术指标。比如要求“尽可能稳定”就应该转化为“在输入电压波动 X% 范围内输出偏差不超过 Y%连续运行 30 分钟关键参数在 Z 区间内”。这一类具体数据来自题目本身或现场测量条件不能写成模糊的主观感受。建议用表格区分需求优先级需求类型例子优先级核心功能能采集某类信号并显示结果必须完成精度要求测量误差限制在一定范围内必须完成附加功能能联网上报、语音播报尽量完成加分展示界面美观、交互友好最后考虑先保证核心链路能够跑通再做“锦上添花”的功能。第一次参赛最容易出现的错误是把时间花在了上位机界面或某颗传感器的精确选型上结果主控部分连最基础的闭环还没有完成。4.2 做一张风险表拿到题目后可以立刻组织一次短会评估每个子任务的风险。风险高不是不能做而是要提前准备备选方案。风险来源典型影响预防措施主功能工作量估错基础功能都完不成先做最小可运行闭环再逐步扩展精度/线性度不足评测失分提前做多组数据标定必要时提高 ADC 分辨率或增加硬件调零大功率器件发热电压跌落、器件损坏提前用假负载测试留温度裕量模块间地环路干扰采样值跳动检查接地方式避免功率回路与信号回路共用一段长导线题目风险点识别不足现场临时换方案方案评审时故意挑毛病逐一列出失效模式风险评估不是会议记录而是要在每个模块启动之前落地为具体动作。比如“防止采样值跳动”对应的动作就是“先分别测量传感器在空载和电机启动时的读数变化”。否则风险表只是挂在墙上的一页纸。5. 软硬件开发流程与工程组织5.1 先统一接口定义再写代码电赛团队合作困难经常是因为接口未经定义就各自开工。比如传感器模块输出的是模拟电压还是数字信号范围是多少通信波特率是多少数据帧格式是什么电机驱动板的使能脚是高有效还是低有效这些问题在画原理图之前就应该约定。一个简单做法是建立“接口文档”内容包括每个外设芯片或模块的供电电压、输入输出范围。主控与子模块之间的通信协议包括波特率、字节序、超时时间。关键 GPIO 的功能分配表尽量把不同类型的信号分开放置。电源域划分避免模拟信号和功率地混为一条杂散路径。接口文档不需要很长但需要随开发进度维护。等到联调时再发现两个模块“各说各话”排查成本往往会超过正常开发成本。5.2 项目目录保持清晰很多 MCU 工程一开始只有一个main.c最后变成几千行单文件。现场调参时改一个变量可能影响好几个中断服务函数风险极高。建议在建立工程时就开始按模块拆目录。以常见嵌入式工程为例目录可以是project/ ├── Core/ # 启动文件、时钟配置 ├── Drivers/ # 芯片外设驱动 ├── App/ │ ├── sensor.c │ ├── control.c │ └── display.c ├── Test/ # 测试脚本、日志文件 ├── Docs/ # 接口文档、调试记录 └── .gitignore这里的App是业务逻辑层Drivers是芯片底层库Test放测试脚本和采集日志。核心逻辑不要直接堆在中断回调里尽量拆成独立函数方便后期加日志或做单元验证。5.3 用状态机管理应用流程对于电赛这种“采集—计算—控制—显示”的循环流程用简单的状态机比一大堆 if-else 更容易定位问题。typedef enum { APP_IDLE, APP_SENSOR_ACQ, APP_CTRL_UPDATE, APP_DATA_SEND } AppState; AppState state APP_SENSOR_ACQ; while (1) { switch (state) { case APP_SENSOR_ACQ: // 读取传感器并完成滤波 state APP_CTRL_UPDATE; break; case APP_CTRL_UPDATE: // 执行控制算法 state APP_DATA_SEND; break; case APP_DATA_SEND: // 串口输出或屏幕刷新 state APP_IDLE; break; default: state APP_SENSOR_ACQ; break; } }这段代码不是唯一正确答案但它展示了一个容易被忽略的原则主流程必须可理解、可打断、可加日志。第一次参赛时调试不可见通常是因为程序逻辑本身混在一起缺少清晰的观察点。6. 功能测试与效果验证6.1 模块级验证先行每次把新的硬件/代码接入系统前先做模块级验证电源模块先在空载和额定负载下测试输出电压是否稳定再用示波器看纹波是否在可接受范围内。传感器模块固定输入条件连续读取若干次记录最大值、最小值和平均值判断是否需要软件滤波。通信模块在没有业务逻辑干扰的情况下循环收发数据确认不丢帧。驱动模块先用信号发生器等工具模拟控制输入确认输出逻辑正确再接真实执行器。“先验证模块再联调系统”听起来简单但第一次比赛时很多人会跳步。跳过模块测试的代价是系统某一处表现出问题后你根本不知道是该调算法还是该修硬件。6.2 把测试条件量化功能测试不能以“看起来正常”为通过标准每个测试都要写清输入条件、检查项和通过标准。例如记录如下测试矩阵。测试组输入条件检查项通过标准输入电源低电压边界用可调电源设置最低工作电压单片机复位、界面刷新、指示灯状态连续运行 10 分钟无复位传感器线性度依次给标准量记录读数测量输出与标准量差值偏差小于题目允许范围通信压力每秒发送一帧持续 5 分钟接收端统计丢包丢包率为 0控制曲线跟踪设定目标值并变化实际输出跟随时间超调量和调整时间满足要求通过标准必须可测量、可复核。现场评测时测试员往往会加一些边界条件比如快速切换档位、长时间连续运行。没有提前做过边界测试的系统很容易在评测现场暴露出只在特定条件下的 bug。6.3 电赛场景下的接口和批量测试电赛系统和互联网后端不同通常没有 HTTP API 和任务队列真正重要的是芯片之间的接口协议以及多组输入样本的连续测试。如果赛题包含通信功能建议单独编写一个“回环测试”主控发一帧数据另一个模块收到后原样返回主控校验内容是否一致。对于测量、控制类赛题不建议只测一两组数据。要把测试过程固化成连续样本并让串口输出结构化日志。time1200, voltage3.298, current0.012, stateOK time1250, voltage3.271, current0.014, stateWARN time1300, voltage3.299, current0.011, stateOK结构化日志可以保存到文件再用 Python 离线分析避免靠人眼看串口助手里的几千行数据。import re fail_count 0 with open(test_log.txt, r, encodingutf-8) as f: for line in f: match re.search( rvoltage([\d.])V, current([\d.])A, line ) if match: voltage float(match.group(1)) current float(match.group(2)) if not (3.1 voltage 3.4): fail_count 1 print(voltage out of range count:, fail_count)这样的脚本不需要很复杂关键是帮助队伍快速判断长时间运行是否稳定。第一次比赛时如果每个模块都有人工记录数据最后汇总时很难发现问题。用日志和脚本处理至少能让测试结果变得可复现。6.4 第一次联调要有明确顺序系统联调不能把“所有功能全部打开”当作第一步。建议顺序是跑通最小系统开发板能下载程序串口能输出调试信息。单模块闭环只接一个传感器和一个执行器验证开环逻辑。加控制算法先用手动模式确认执行器方向正确再进入自动模式。增加复杂交互加入按键、菜单、显示、通信等外围功能。回归测试改完一个功能后快速重跑一遍已通过的测试用例。第一次联调最容易出错的地方是把传感器数据、控制算法和显示刷新全部放在同一时刻处理造成相互延迟。建议用定时器划分不同任务周期比如传感器采样循环、控制计算循环、显示刷新循环分开避免一个任务占用过长时间导致其他任务超时。7. 资源占用与性能观察很多电赛队伍只关心代码能不能跑不关心 Flash、RAM、定时器和中断资源是否够用。等到功能越加越多程序可能出现莫名复位或执行顺序错乱。建议预留一段时间做资源盘点。资源维度查看方式常见瓶颈Flash 空间编译输出信息、MAP 文件固件库全功能开启后体积膨胀RAM 空间编译器链接报告、运行时栈检测大数组、缓存、多任务堆栈叠加外设资源引脚分配表、定时器/DMA通道表GPIO 和功能外设引脚冲突时钟与中断调试器查看中断触发计数中断频率过高或长时间占用主循环功耗与散热可调电源实时电流/电压显示大功率驱动连续工作发热比如测量类赛题可能会频繁触发 ADC 和 DMA 搬运。如果每个中断服务函数里都做耗时较长的浮点运算采样间隔可能不稳定最终表现为测量结果抖动。要观察这类问题最简单的方式是在固定任务开始和结束时切换一个 GPIO用示波器测量该 GPIO 的脉冲宽度从而判断任务执行耗时。功率类和驱动类题目还要重点看电源在动态负载下的表现。电机启动瞬间电流可能明显高于稳态电流如果稳压电路响应速度不够MCU 可能瞬间复位。评测现场大量板子因为共用地线、电源余量不足而出现“明明写好的程序放在展台上就乱跳”第一次参赛尤其要重视这个坑。8. 常见问题与排查方法电赛调试过程中遇到的绝大多数问题都不是“玄学”而是缺少合适的观察手段。下面的排查表可以作为通用参考。现象可能原因排查方式解决方向程序烧录不进去下载器驱动异常、目标供电不足、占用芯片引脚检查下载器连接和供电查看编译器报错重新安装驱动检查最小系统供电模块接上去后 MCU 不工作电源被拉低、模块电流过大测量模块供电电压断开模块单独跑 MCU增加独立电源或降低模块负载ADC 数据跳动严重采样抖动、信号源内阻高、布线引入干扰固定输入并连续打印原始值增加滤波电容软件做滑动平均通信偶尔丢帧波特率偏差、中断竞争、共地不足短距离回环测试打印接收错误标志统一参考地降低发送频率控制方向反了执行器接线、逻辑符号取反先开环测试观察执行器方向调整占空比极性或交换接线功能一多主循环变慢中断太频繁、显示刷新阻塞用 GPIO 翻转法测任务耗时分频采样、优化刷新逻辑调试正常、放到评测台上失败现场电源、信号源与实验室不一致提前用多组电源/信号源复测按最不利条件做边界测试代码改一处其他模块也崩全局变量耦合严重、堆栈溢出代码评审检查可能越界的数组模块化封装限制全局变量出现异常现象后不要立刻随机改代码。先把现象用一句话写清楚再列出可能影响该现象的全部变量让其中一个变量产生改变其他变量保持固定。真正难解决的问题大多不是方案复杂而是团队没有确定变量做了一次“东改一下、西改一下”的无效调试。如果现场遇到“调试环境正常但换一台设备不行”的问题优先检查双方供电电压、接线顺序、通信波特率和参考地是否完全一致。电赛评测环境和实验室环境不同使用笔记本电池供电、独立 USB 转串口、外部可调电源都可能改变地平面和干扰情况。9. 时间管理如何避免“很迷茫”的状态第一次参赛的“很迷茫”本质上是任务不可见。只知道最终目标是做出一个题目要求的系统但不知道每天该推进什么。破解方法不是更多熬夜而是把赛程做成倒排计划。赛题下发后的时间通常非常紧凑无论赛程是三天还是四天都需要倒推关键节点第 1 个半天只做读题、指标拆解、方案评审和接口定义不写代码、不接线。第 1 个 1/4 时间完成电源、采样、执行器的最小硬件链路跑通点灯级别的程序。第 2 个 1/4 时间把核心信号从传感器端读到逻辑处理端能完成开环动作。第 3 个 1/4 时间加入闭环控制和自动逻辑替换算法参数提升精度。最后 1/4 时间回归测试、写文档、整理现场检查单不再做高风险改动。如果进度落后优先砍“附加功能”保留“核心链路”。例如题目需要显示波形、曲线和数据记录但如果测试时间不够可以先实现简单数值显示停止做高分辨率绘图界面。很多队伍在最后半天因为坚持做上位机界面导致核心控制参数没有调优在评测现场反而失分。每天结束时用十分钟更新“任务状态表”哪些任务已经完成对应测试记录在哪。哪些任务正在进行负责人是谁。哪些任务已经卡住卡在哪个模块需要什么条件才能推进。明天优先级最高的一件事件是什么。第一次参赛时最容易出现的情况是三个人都很累但互相不知道对方在做什么。任务状态表不是给老师看的也不是最终文档的一部分而是让队伍内部随时知道当前可运行版本是什么、下一份可交付成果是什么。迷茫感大部分来源于不确定性当任务被拆到明天可以动手验证时焦虑就会明显下降。10. 复盘很累很迷茫但值得现在回头看第一次参加电赛的那一学期多数记忆不是颁奖时刻而是某个晚上反复调不通信号的挫败以及离截止时间越来越近时的无力感。赛前觉得别人什么都懂赛题出来后才发现很多题目要求也需要临时查手册自己并没有想象中那么准备不足。那些“卡了很久才通过”的问题最后都变成了判断问题的直觉。电赛真正留下的财富不是一块奖状或一个决赛名额而是一套被验证过的工作方法赛前先准备工具链和版本管理赛题下来先拆指标和风险设计阶段先定接口测试阶段先留日志。这套方法在未来的毕业设计、工作项目和研究生科研中都会不断复用。如果你还在迷茫期建议不要等到“完全准备好”再报名参赛。准备得再久赛题也会抛出意料之外的要求。第一次参赛的最大收益是让你知道自己离“能够独立完成一个电子系统”还差哪些具体能力然后愿意把每个环节按工程流程去补齐。等下一届赛题公布的时候从第一天就能 Git、第一晚就出接口文档、第一次联调就留结构化日志的队伍往往不会太慌。把这一整套流程跑完你也会发现这学期确实很累过程确实迷茫但最后亲手调试出的系统稳定运行、数据正确落在测试表里时之前的付出都是值得的。
