1. 先别急着骂这题我熟看到这个标题我就知道哥们儿你八成是刚从实验室出来或者是赛前刚开完分工会的电赛队长。被“软件一个人扛”搞到心态爆炸的不止你一个我当年带过队伍、也当过被压榨的那个“软件独苗”这里头的血泪、坑和教训我比绝大多数人都清楚。先说个背景全国大学生电子设计竞赛三人一组软硬件结合四天三夜要交一套能跑的完整系统。听起来是个团队赛但很多人组队的时候根本没想清楚一个问题——电赛到底分哪些活怎么分才能不炸大部分队伍默认的操作是两个硬件、一个软件。因为板子要画、电路要焊、器件要调这些工作肉眼可见地多所以硬件俩人属于“刚需配置”。软件呢呵在很多人潜意识里不就是写写单片机、调调参、烧个程序嘛一个人够了。于是“软件一个人扛”就成了电赛圈最常见的灾难现场。软件同学白天陪着调电路、晚上回去写代码、凌晨三点还在改中断优先级、第二天早上顶着黑眼圈给人焊板子。等到联调阶段全队6只眼睛盯着他一个人debug问他为什么波形不对、为什么屏幕不亮、为什么电机不转所有问题都指向他那颗小小单片机里的代码。这合理吗不合理。但这偏偏是绝大多数队伍的真实状态。所以这篇博文我不想只替软件同学骂街我想拆开讲清楚电赛三人组到底该怎么分工才科学软件为什么不能被一个人“扛”以及如果你已经被塞了这口锅怎么才能在死线上把局面救回来。2. 经典混乱分工的三个典型画像2.1 硬件两个大爷软件一个孙子这是最典型、也最坑的结构A负责电源和驱动B负责传感器和信号调理C负责全部的嵌入式软件、上位机、调试、演示准备。表面上看起来很合理对吧硬件任务确实多两个人忙四天都未必够。但问题在于硬件任务再复杂每个人负责的模块是独立的。A画板子的时候B不用在旁边看着B调传感器的时候A也可以继续干自己的活。软件呢他一个人要面对的是整个系统的集成。什么叫集成就是A的电源板、B的传感器板全部要靠C的代码串联起来。A和B每改一版硬件C的代码就可能要跟着改。A说“这个引脚我换一下哈”C就要去改GPIO定义B说“这个传感器型号换了输出是I2C不是模拟量”C就要去重写驱动。到最后整个系统能不能跑起来不是看A和B的硬件有多牛而是看C一个人能不能在四天里把所有模块缝起来。这不是软件开发任务重不重的问题而是系统集成的复杂度全压在一个人身上了。2.2 软件兼着队长、文档、后勤和外联有些队更狠软件同学因为“懂电脑”顺理成章地变成了全队最忙的人程序你写、报告你用Word排版、演示视频你剪、元器件上网买、甚至队长也在你头上。我就见过一支队伍软件小哥四天里写了3000行代码的同时还要负责全队的伙食预订、赛场踩点、测试记录和答辩PPT。最后硬件大爷们焊的板子虚焊他还要拿烙铁帮着补焊——因为硬件两位“不会用”实验室那台老旧的焊台。这种事情在电赛圈真不少见。原因特简单软件工作很难量化在很多人的脑子里就是“坐在电脑前敲敲键盘”。别的活儿都看得见摸得着只有敲键盘这件事看起来好像挺轻松。实际呢四天三夜电赛最累的那个永远是坐在电脑前的人。硬件再忙总有焊完板子等测试的间隙软件不一样代码的bug不会给你喘息的机会你上卫生间的时候脑子里还在过状态机。2.3 三个诸葛亮全在当臭皮匠还有一种混乱是反向的三个人都想干软件因为这个“看起来高级”三个人都不想焊板子、不想查数据手册、不想跑测试记录。结果是什么三个人一人写一个小模块代码风格天差地别变量名一个叫data一个叫shuju一个叫xIO口定义在三个不同的文件里引脚冲突了谁也不知道。联调的时候三个人互相问“你那个模块好了没有”每个人都觉得自己的部分没问题但系统就是跑不起来。这类队伍恰恰是“软件被一个人扛”的反面他们的本质问题是一样的没有搞清楚软件工作不能“切碎”了分给三个人但也不能全压给一个人。软件在电赛里是一个需要“统一架构、分散实现、集中联调”的活这个我们在后面细说。3. 软件到底包含哪些活你真以为只是写代码很多人说“软件一个人扛”的时候脑子里默认软件写C语言。但电赛里的软件工作量之杂、范围之大远超想象。我给你们拆一下3.1 底层驱动与配置MCU选型、时钟配置、GPIO、中断优先级、定时器、ADC/DAC、PWM、串口、SPI、I2C、CAN……每一个外设的初始化都是一个独立的子工程。遇到不熟的芯片光看数据手册配寄存器就能耗掉半天。这部分工作极度依赖经验用的还是C语言新手上来很容易一脸懵。但底层驱动恰恰是整个系统里最不容出错的部分——ADC采样率不对后面信号处理全是空中楼阁。3.2 算法与信号处理电赛信号题要FFT、要滤波、要锁相控制题要PID、要跟迹、要惯性导航解算电源题要闭环控制、要拓扑算法。这些算法不是说知道了公式就能写对还要跟硬件实测数据反复磨合。这些算法代码通常不长但调试时间极长。PID三个系数就能调一晚上FFT的窗函数选不对频域里全是鬼影。算法这部分是软件工作里最需要“静下心”的部分三位队友在旁边哐哐钉箱子的时候你在写滤波器这种切身体会谁干谁知道。3.3 调试工程与上位机这部分最容易被忽略。串口打印助手、波形显示、在线调参面板、数据分析脚本。一个成熟选手会在开赛前就搭好一套调试基础设施开关一开就能看波形、读数据、改参数。没有这些你就是在盲调。我自己的习惯是开赛前准备一个Python脚本配合串口把MCU吐出来的数据实时画成波形。硬件改了滤波电路软件滤波系数要不要跟着改看波形一眼就知道不用靠猜。3.4 人机交互与界面按键、旋钮、屏幕菜单、状态指示、甚至是语音播报。电赛测评的时候专家评委要看你的系统“好不好用”按键逻辑不清晰、菜单进入不了、显示数据不对直接影响测评分数。这部分工作量不大但很琐碎如果一个主程序员被这些事占满那算法那边基本就没时间了。3.5 联调、排错和文档联调不是把程序烧进去就完事是软硬件反复对表的过程。硬件说“我这边输出电压稳定了”软件说“我ADC读到的数据有毛刺”两边要一起找原因可能出在硬件滤波不良也可能是软件采样时序没对准。这种活极其耗时费神而且必须有软件人员参与。还有文档电赛最后要交设计报告代码逻辑框图、状态机流程、核心算法说明全都要写。这篇报告的分值不低但很多队伍都是最后一天熬夜潦草凑出来的原因就是软件人员根本没时间写而硬件队友又看不懂代码。顺便说一句2024年电赛的H题和G题以及2025年、2026年的好几个题目E题、G题、H题复杂度逐年上升越来越强调软硬协同。尤其是控制类和信号类题目系统架构复杂度上来了软件工作量已经不是一个人扛得动的量级了。4. 正确的分工逻辑三个人不是切模块是分主线4.1 推荐架构一人主软一人主硬一人主系统既然三个人就不要搞“两人硬件一人软件”这种按工作量拍脑袋的分法。推荐按“主线职责交叉支撑”的结构分角色主线职责交叉支撑主软件代码架构、底层驱动、核心算法、联调排错协助测试方案设计、参与硬件选型主硬件原理图/PCB、器件选型采购、焊接调试协助写文档、根据接口文档配置硬件参数主系统测试记录、指标验证、演示流程、设计报告参与代码评审、协助GUI/按键逻辑定义主系统这个角色特别关键不是“打杂”而是全队的质量官。他手里拿着题目里的每一项指标一项一项对照测试显示精度够不够、调节时间达不达标、超调量在不在范围、连续运行半小时会不会漂。这个人在电赛里简直救命。因为只盯着代码和板子的人很容易迷失在局部细节里需要一个“抬头看路”的人时不时说一句“哥们儿题目要求测量范围到100kHz你这波形在80kHz就衰减了”。4.2 为什么不能把软件切成三块分给三个人有人说好我们三个人都写代码行不行我的回答是如果你不想把四天三夜变成三人吵架四天的话最好别。原因很简单电赛代码的耦合度极高不要说写三个模块合到一起就是一个人写、另一个人改工作效率都是急剧下降的。因为代码里的状态变量是全局共享的按键扫描的变量可能在显示模块里被引用中断里修改的数据主循环要读这个系统是一张网不是一个一个独立的木桶。三个风格不同的人往一张网里塞代码最后就是变量冲突、函数重名、逻辑互相踩踏。联调压力不降反升而且出了问题三个人都不知道是谁的锅。正解是代码架构由一个人定具体模块可以由三个人实现但必须按清晰的接口拆分且代码风格统一到一个人维护主版本。4.3 硬件和软件的接口文档开赛前必须定死很多队伍忽略这个东西觉得“到时候调就行了”。但到了第三天你会发现因为一个接口定义不清晰硬件和软件之间来回扯皮两个小时是家常便饭。接口文档不需要多复杂A4纸一页就够接口项定义约定说明传感器数据输出8路ADC0~3.3V对应0~4095主控12bit ADC采样率默认10kHzPWM输出频率20kHz固定驱动板基于此设计滤波串口协议帧头0xAA 0x55 数据 CRC8调试用波特率115200按键逻辑短按切换/长按确认硬件只提供GPIO电平显示刷新5Hz刷新帧率刷太快会有闪烁软件定时器控制这张表三个人一人打一份放在工位上。任何一方要改必须当众喊一嗓子然后同步更新文档。这样做的目的不是为了规范而规范而是在四天三夜的高压状态下减少“我以为你知道”这类沟通废动作。5. 软件同学不被压垮的三个实操法则如果你就是那个被塞了软件主程序的倒霉蛋别慌下面这几个方法是我踩了无数坑之后总结出来的照着做起码能让你从“累死”变成“累但能活到测评”。5.1 开赛前48小时先搭基础设施电赛是四天三夜但真正写代码的时间其实只有前三天。最后一天基本是在联调、录视频、写报告、慌慌张张中度过。所以开赛前那几天是把“地基”打好的黄金时间。我会提前准备好几样东西配置好MCU工程模板时钟、GPIO、串口、定时器这些初始化代码提前写好并验证过。2024年以后的新题目趋势是越来越依赖高性能MCU建议至少提前熟悉STM32H7系列或树莓派Pico的SDK。搭好调试上位机Python的串口工具能画波形就行。上电第一件事就是确认串口通不通再谈其他。准备好代码目录结构/driver、/algorithm、/app、/doc四个目录。driver放底层驱动algorithm放滤波和控制算法app放主循环和状态机doc放接口文档。这样开赛后你不是从零开始而是从“框架”开始。你的队友也不会看着你从头敲键盘干瞪眼。5.2 主程序和状态机一晚上就要定稿电赛软件最大的陷阱是你以为题目读懂了主程序框架一个下午就能写完于是第一天就把所有时间花在调外设上。结果第二天发现系统逻辑根本不是你想的那样主程序推倒重来。我的经验是动手写代码之前三个人一起画一张状态机图。系统有哪些状态、什么条件触发切换、每个状态里要做什么全都在纸上画清楚。这张图定稿了主程序其实就是翻译的事。状态机画好之后主程序框架我通常第一个晚上就写完。之后的每一天都是往这个框架里填具体模块不会伤筋动骨。这个习惯还有个额外好处画状态机的过程就是全队对齐需求的过程。硬件队友会在旁边说“你这个状态切换得加一个延时因为我的继电器切换需要20ms”这种关键信息如果你直接闷头写代码根本不会有人想起来告诉你。5.3 代码要写成队友能看懂的样子很多软件选手有个执念代码要简洁、要炫技。位操作、函数指针、宏定义三层嵌套……队友一看直接摇头。电赛不是软件开发比赛代码是拿来跑系统的不是拿来欣赏的。我强烈建议三件事变量名用完整英文别用a、b、t这种。filtered_distance就比d强一百倍。关键函数写注释哪怕只有一行。队友改你的代码时一行注释能省他半小时。复杂逻辑单独写函数不要全堆在main里。main函数超过200行后面你必疯。代码模块化还有个好处你的硬件队友也能参与进来。比如说显示模块就是一个display_init()加一个display_update()他完全可以在你写算法的同时帮你去查显示驱动怎么配置。模块化之后软件不再是“一个人的黑盒”而是全队可以一起干活的白盒。6. 联调阶段软件硬件的真实配合联调是整个电赛最崩溃的阶段。硬件说“我的板子绝对没问题”软件说“我的代码逻辑肯定正确”两边一对就是不出结果。这时候最忌讳的就是互相甩锅我从实战里总结了一套联调节奏按这套走效率至少提高一倍。6.1 先点灯再通信最后跑闭环很多队伍联调一开始就期望系统直接跑满分性能这是不现实的。联调要分三步走第一步点灯。代码烧进去板子上的LED能按预期闪烁说明电源、MCU、程序框架都是通的。有些队伍连这一步都要卡一晚上原因五花八门程序烧不进去、引脚冲突、板子虚焊。第二步通信。MCU和PC串口打通、MCU和传感器之间I2C/SPI能读到数据、MCU和驱动板的PWM控制信号有输出。这一步通过就说明软硬件之间的“道路”是通的。第三步跑闭环。这时候才让控制算法或信号处理算法介入一点一点把指标调上去。PID先给一组保守参数看系统能稳住再逐步往激进里调。6.2 联调时软件不要一个人盯屏这是我见过最傻的场面软件小哥一个人弯着腰看串口输出硬件两位大爷在一边刷手机。这不是软件同学的工作多么需要集中精力而是团队配合出了问题。正确的做法是联调时三个人都在。A操作硬件B看着示波器和万用表C盯着软件状态。任何一个环节出异常三张嘴同时报出来问题定位速度是单人debug的三倍。而且硬件人员盯着软件跑他才能理解为什么软件需要那个10ms的延时、为什么采样率不能随便改、为什么中断里不能加串口打印。这种互相理解是后面避免扯皮的最好方式。6.3 出了问题先查硬件后查软件但不要“只查一边”联调排错有一条铁律先确认硬件供电和信号是否正常再怀疑代码。很多软件bug归根到底是硬件信号出了问题你的程序读到的就是错误的输入那你再怎么改代码都没用。但反过来硬件也不要一有问题就说“我这边正常”请拿示波器实测波形说话。我见过一个队伍功耗异常硬件说程序没进低功耗软件说低功耗状态机写好了两人吵了一下午最后发现是硬件板子上一个上拉电阻焊错了把MCU的某些引脚拉低了导致程序根本进不了休眠。如果硬件早点拿万用表测一测引脚电平这个bug十分钟就解决了。7. 关于文档和测评软件人员不能全甩给别人好就算你的分工合理了、联调顺利了还有一个每一个电赛队伍都绕不开的坑设计报告。我们当年拿过惨痛教训硬件做完了代码跑通了结果那个报告写得一塌糊涂代码流程图画得像涂鸦算法描述含糊其辞最后答辩环节被评委问得说不出话。等看到分数的时候三个人眼睛里全是血丝那几天全白熬了。设计报告这个活核心内容还是要软件人员来写。因为算法流程、状态机、代码结构这些内容硬件队友是真的写不了他们有心想帮你也使不上劲。我的建议是写报告不能放在最后一天而要在过程中同步推进。每天睡觉前主系统负责的同学拿出半个小时把当天完成的模块画成图、写成文字精简地存下来第二天直接集成进报告。你码代码的时候每写完一个功能模块顺手把关键数据结构和一个函数流程图用文字保存下来。这里有个小技巧把你画的状态机和模块划分图直接截图存成设计文档后头报告里直接引用图片永远比文字直观省时省力还显得专业。还有答辩PPT也不要最后一天熬夜做。演示流程从联调阶段就要彩排系统怎么上电、先展示什么指标、后展示什么功能、评委可能问什么坑。主系统负责的同学拿着题目指标一条一条过每一个指标后面都要有实测数据支撑这比临时抱佛脚强一百倍。8. 电赛分工的常见问题速查表我把这些年见过的、听过的电赛分工问题整理成一个表你对照看看自己踩了哪个坑症状根因解法软件同学凌晨三点还在改代码软件工作量严重超载重新审视分工代码模块化让队友介入驱动和调试工具部分硬件队友说“我这边好了”但系统跑不起来软硬件联调接口未对齐用接口文档状态机图同步两边的认知代码写完了队友看不懂没法帮忙代码风格不友好随意命名从第一天就约束变量命名和注释代码要“开放式”答辩时说不出算法原理设计文档没有同步写每天晚结束前花30分钟写进度日志三人各写各的模块联调时崩了没有统一的代码架构和风格接受“代码主权归一个人”其他人公共接口方式协作功能全做完了但指标过不了没有人专职测指标对照测评要求安排主系统角色每完成一项功能立刻对照题目验证一项指标这个表不是万能的但我见过的翻车队伍里八成以上都能对应到其中某一行。提前排查一遍比事后后悔有用得多。9. 最后的心里话电赛不是软件一个人的事写了这么多回过头来把最核心的一句话送给所有即将组队的电赛新人电赛是三个人的比赛不是一个人扛下所有的比赛。一个人扛下所有的后果从来都不是“这队真厉害一个人干了三个人的活”而是“这支队伍软件很强可惜其他方面拖了后腿”。到测评现场你就会发现评委看的不是谁代码写得漂亮而是整个系统有没有完成题目要求、数据是否稳定可靠、功能是否完整。软件代码是系统的灵魂但不是系统的全部。电机不转可能是驱动电路的问题也可能是PID参数没写好波形不对可能是模拟前端设计的问题也可能是FFT算法选错了窗函数屏幕不亮可能是LCD接线虚了也可能是初始化时序不对。电赛的每一个结果都是软硬件共同作用的结果。所以别再骂队友了也别再一个人死扛了——坐下来把这篇分工思路发给队友好好认领各自的职责。三个人各管一摊互相支撑四天三夜结束后还能一起去撸串喝酒这才是电赛该有的样子。
电赛三人组分工指南：软件一人扛是误区，如何科学协作
1. 先别急着骂这题我熟看到这个标题我就知道哥们儿你八成是刚从实验室出来或者是赛前刚开完分工会的电赛队长。被“软件一个人扛”搞到心态爆炸的不止你一个我当年带过队伍、也当过被压榨的那个“软件独苗”这里头的血泪、坑和教训我比绝大多数人都清楚。先说个背景全国大学生电子设计竞赛三人一组软硬件结合四天三夜要交一套能跑的完整系统。听起来是个团队赛但很多人组队的时候根本没想清楚一个问题——电赛到底分哪些活怎么分才能不炸大部分队伍默认的操作是两个硬件、一个软件。因为板子要画、电路要焊、器件要调这些工作肉眼可见地多所以硬件俩人属于“刚需配置”。软件呢呵在很多人潜意识里不就是写写单片机、调调参、烧个程序嘛一个人够了。于是“软件一个人扛”就成了电赛圈最常见的灾难现场。软件同学白天陪着调电路、晚上回去写代码、凌晨三点还在改中断优先级、第二天早上顶着黑眼圈给人焊板子。等到联调阶段全队6只眼睛盯着他一个人debug问他为什么波形不对、为什么屏幕不亮、为什么电机不转所有问题都指向他那颗小小单片机里的代码。这合理吗不合理。但这偏偏是绝大多数队伍的真实状态。所以这篇博文我不想只替软件同学骂街我想拆开讲清楚电赛三人组到底该怎么分工才科学软件为什么不能被一个人“扛”以及如果你已经被塞了这口锅怎么才能在死线上把局面救回来。2. 经典混乱分工的三个典型画像2.1 硬件两个大爷软件一个孙子这是最典型、也最坑的结构A负责电源和驱动B负责传感器和信号调理C负责全部的嵌入式软件、上位机、调试、演示准备。表面上看起来很合理对吧硬件任务确实多两个人忙四天都未必够。但问题在于硬件任务再复杂每个人负责的模块是独立的。A画板子的时候B不用在旁边看着B调传感器的时候A也可以继续干自己的活。软件呢他一个人要面对的是整个系统的集成。什么叫集成就是A的电源板、B的传感器板全部要靠C的代码串联起来。A和B每改一版硬件C的代码就可能要跟着改。A说“这个引脚我换一下哈”C就要去改GPIO定义B说“这个传感器型号换了输出是I2C不是模拟量”C就要去重写驱动。到最后整个系统能不能跑起来不是看A和B的硬件有多牛而是看C一个人能不能在四天里把所有模块缝起来。这不是软件开发任务重不重的问题而是系统集成的复杂度全压在一个人身上了。2.2 软件兼着队长、文档、后勤和外联有些队更狠软件同学因为“懂电脑”顺理成章地变成了全队最忙的人程序你写、报告你用Word排版、演示视频你剪、元器件上网买、甚至队长也在你头上。我就见过一支队伍软件小哥四天里写了3000行代码的同时还要负责全队的伙食预订、赛场踩点、测试记录和答辩PPT。最后硬件大爷们焊的板子虚焊他还要拿烙铁帮着补焊——因为硬件两位“不会用”实验室那台老旧的焊台。这种事情在电赛圈真不少见。原因特简单软件工作很难量化在很多人的脑子里就是“坐在电脑前敲敲键盘”。别的活儿都看得见摸得着只有敲键盘这件事看起来好像挺轻松。实际呢四天三夜电赛最累的那个永远是坐在电脑前的人。硬件再忙总有焊完板子等测试的间隙软件不一样代码的bug不会给你喘息的机会你上卫生间的时候脑子里还在过状态机。2.3 三个诸葛亮全在当臭皮匠还有一种混乱是反向的三个人都想干软件因为这个“看起来高级”三个人都不想焊板子、不想查数据手册、不想跑测试记录。结果是什么三个人一人写一个小模块代码风格天差地别变量名一个叫data一个叫shuju一个叫xIO口定义在三个不同的文件里引脚冲突了谁也不知道。联调的时候三个人互相问“你那个模块好了没有”每个人都觉得自己的部分没问题但系统就是跑不起来。这类队伍恰恰是“软件被一个人扛”的反面他们的本质问题是一样的没有搞清楚软件工作不能“切碎”了分给三个人但也不能全压给一个人。软件在电赛里是一个需要“统一架构、分散实现、集中联调”的活这个我们在后面细说。3. 软件到底包含哪些活你真以为只是写代码很多人说“软件一个人扛”的时候脑子里默认软件写C语言。但电赛里的软件工作量之杂、范围之大远超想象。我给你们拆一下3.1 底层驱动与配置MCU选型、时钟配置、GPIO、中断优先级、定时器、ADC/DAC、PWM、串口、SPI、I2C、CAN……每一个外设的初始化都是一个独立的子工程。遇到不熟的芯片光看数据手册配寄存器就能耗掉半天。这部分工作极度依赖经验用的还是C语言新手上来很容易一脸懵。但底层驱动恰恰是整个系统里最不容出错的部分——ADC采样率不对后面信号处理全是空中楼阁。3.2 算法与信号处理电赛信号题要FFT、要滤波、要锁相控制题要PID、要跟迹、要惯性导航解算电源题要闭环控制、要拓扑算法。这些算法不是说知道了公式就能写对还要跟硬件实测数据反复磨合。这些算法代码通常不长但调试时间极长。PID三个系数就能调一晚上FFT的窗函数选不对频域里全是鬼影。算法这部分是软件工作里最需要“静下心”的部分三位队友在旁边哐哐钉箱子的时候你在写滤波器这种切身体会谁干谁知道。3.3 调试工程与上位机这部分最容易被忽略。串口打印助手、波形显示、在线调参面板、数据分析脚本。一个成熟选手会在开赛前就搭好一套调试基础设施开关一开就能看波形、读数据、改参数。没有这些你就是在盲调。我自己的习惯是开赛前准备一个Python脚本配合串口把MCU吐出来的数据实时画成波形。硬件改了滤波电路软件滤波系数要不要跟着改看波形一眼就知道不用靠猜。3.4 人机交互与界面按键、旋钮、屏幕菜单、状态指示、甚至是语音播报。电赛测评的时候专家评委要看你的系统“好不好用”按键逻辑不清晰、菜单进入不了、显示数据不对直接影响测评分数。这部分工作量不大但很琐碎如果一个主程序员被这些事占满那算法那边基本就没时间了。3.5 联调、排错和文档联调不是把程序烧进去就完事是软硬件反复对表的过程。硬件说“我这边输出电压稳定了”软件说“我ADC读到的数据有毛刺”两边要一起找原因可能出在硬件滤波不良也可能是软件采样时序没对准。这种活极其耗时费神而且必须有软件人员参与。还有文档电赛最后要交设计报告代码逻辑框图、状态机流程、核心算法说明全都要写。这篇报告的分值不低但很多队伍都是最后一天熬夜潦草凑出来的原因就是软件人员根本没时间写而硬件队友又看不懂代码。顺便说一句2024年电赛的H题和G题以及2025年、2026年的好几个题目E题、G题、H题复杂度逐年上升越来越强调软硬协同。尤其是控制类和信号类题目系统架构复杂度上来了软件工作量已经不是一个人扛得动的量级了。4. 正确的分工逻辑三个人不是切模块是分主线4.1 推荐架构一人主软一人主硬一人主系统既然三个人就不要搞“两人硬件一人软件”这种按工作量拍脑袋的分法。推荐按“主线职责交叉支撑”的结构分角色主线职责交叉支撑主软件代码架构、底层驱动、核心算法、联调排错协助测试方案设计、参与硬件选型主硬件原理图/PCB、器件选型采购、焊接调试协助写文档、根据接口文档配置硬件参数主系统测试记录、指标验证、演示流程、设计报告参与代码评审、协助GUI/按键逻辑定义主系统这个角色特别关键不是“打杂”而是全队的质量官。他手里拿着题目里的每一项指标一项一项对照测试显示精度够不够、调节时间达不达标、超调量在不在范围、连续运行半小时会不会漂。这个人在电赛里简直救命。因为只盯着代码和板子的人很容易迷失在局部细节里需要一个“抬头看路”的人时不时说一句“哥们儿题目要求测量范围到100kHz你这波形在80kHz就衰减了”。4.2 为什么不能把软件切成三块分给三个人有人说好我们三个人都写代码行不行我的回答是如果你不想把四天三夜变成三人吵架四天的话最好别。原因很简单电赛代码的耦合度极高不要说写三个模块合到一起就是一个人写、另一个人改工作效率都是急剧下降的。因为代码里的状态变量是全局共享的按键扫描的变量可能在显示模块里被引用中断里修改的数据主循环要读这个系统是一张网不是一个一个独立的木桶。三个风格不同的人往一张网里塞代码最后就是变量冲突、函数重名、逻辑互相踩踏。联调压力不降反升而且出了问题三个人都不知道是谁的锅。正解是代码架构由一个人定具体模块可以由三个人实现但必须按清晰的接口拆分且代码风格统一到一个人维护主版本。4.3 硬件和软件的接口文档开赛前必须定死很多队伍忽略这个东西觉得“到时候调就行了”。但到了第三天你会发现因为一个接口定义不清晰硬件和软件之间来回扯皮两个小时是家常便饭。接口文档不需要多复杂A4纸一页就够接口项定义约定说明传感器数据输出8路ADC0~3.3V对应0~4095主控12bit ADC采样率默认10kHzPWM输出频率20kHz固定驱动板基于此设计滤波串口协议帧头0xAA 0x55 数据 CRC8调试用波特率115200按键逻辑短按切换/长按确认硬件只提供GPIO电平显示刷新5Hz刷新帧率刷太快会有闪烁软件定时器控制这张表三个人一人打一份放在工位上。任何一方要改必须当众喊一嗓子然后同步更新文档。这样做的目的不是为了规范而规范而是在四天三夜的高压状态下减少“我以为你知道”这类沟通废动作。5. 软件同学不被压垮的三个实操法则如果你就是那个被塞了软件主程序的倒霉蛋别慌下面这几个方法是我踩了无数坑之后总结出来的照着做起码能让你从“累死”变成“累但能活到测评”。5.1 开赛前48小时先搭基础设施电赛是四天三夜但真正写代码的时间其实只有前三天。最后一天基本是在联调、录视频、写报告、慌慌张张中度过。所以开赛前那几天是把“地基”打好的黄金时间。我会提前准备好几样东西配置好MCU工程模板时钟、GPIO、串口、定时器这些初始化代码提前写好并验证过。2024年以后的新题目趋势是越来越依赖高性能MCU建议至少提前熟悉STM32H7系列或树莓派Pico的SDK。搭好调试上位机Python的串口工具能画波形就行。上电第一件事就是确认串口通不通再谈其他。准备好代码目录结构/driver、/algorithm、/app、/doc四个目录。driver放底层驱动algorithm放滤波和控制算法app放主循环和状态机doc放接口文档。这样开赛后你不是从零开始而是从“框架”开始。你的队友也不会看着你从头敲键盘干瞪眼。5.2 主程序和状态机一晚上就要定稿电赛软件最大的陷阱是你以为题目读懂了主程序框架一个下午就能写完于是第一天就把所有时间花在调外设上。结果第二天发现系统逻辑根本不是你想的那样主程序推倒重来。我的经验是动手写代码之前三个人一起画一张状态机图。系统有哪些状态、什么条件触发切换、每个状态里要做什么全都在纸上画清楚。这张图定稿了主程序其实就是翻译的事。状态机画好之后主程序框架我通常第一个晚上就写完。之后的每一天都是往这个框架里填具体模块不会伤筋动骨。这个习惯还有个额外好处画状态机的过程就是全队对齐需求的过程。硬件队友会在旁边说“你这个状态切换得加一个延时因为我的继电器切换需要20ms”这种关键信息如果你直接闷头写代码根本不会有人想起来告诉你。5.3 代码要写成队友能看懂的样子很多软件选手有个执念代码要简洁、要炫技。位操作、函数指针、宏定义三层嵌套……队友一看直接摇头。电赛不是软件开发比赛代码是拿来跑系统的不是拿来欣赏的。我强烈建议三件事变量名用完整英文别用a、b、t这种。filtered_distance就比d强一百倍。关键函数写注释哪怕只有一行。队友改你的代码时一行注释能省他半小时。复杂逻辑单独写函数不要全堆在main里。main函数超过200行后面你必疯。代码模块化还有个好处你的硬件队友也能参与进来。比如说显示模块就是一个display_init()加一个display_update()他完全可以在你写算法的同时帮你去查显示驱动怎么配置。模块化之后软件不再是“一个人的黑盒”而是全队可以一起干活的白盒。6. 联调阶段软件硬件的真实配合联调是整个电赛最崩溃的阶段。硬件说“我的板子绝对没问题”软件说“我的代码逻辑肯定正确”两边一对就是不出结果。这时候最忌讳的就是互相甩锅我从实战里总结了一套联调节奏按这套走效率至少提高一倍。6.1 先点灯再通信最后跑闭环很多队伍联调一开始就期望系统直接跑满分性能这是不现实的。联调要分三步走第一步点灯。代码烧进去板子上的LED能按预期闪烁说明电源、MCU、程序框架都是通的。有些队伍连这一步都要卡一晚上原因五花八门程序烧不进去、引脚冲突、板子虚焊。第二步通信。MCU和PC串口打通、MCU和传感器之间I2C/SPI能读到数据、MCU和驱动板的PWM控制信号有输出。这一步通过就说明软硬件之间的“道路”是通的。第三步跑闭环。这时候才让控制算法或信号处理算法介入一点一点把指标调上去。PID先给一组保守参数看系统能稳住再逐步往激进里调。6.2 联调时软件不要一个人盯屏这是我见过最傻的场面软件小哥一个人弯着腰看串口输出硬件两位大爷在一边刷手机。这不是软件同学的工作多么需要集中精力而是团队配合出了问题。正确的做法是联调时三个人都在。A操作硬件B看着示波器和万用表C盯着软件状态。任何一个环节出异常三张嘴同时报出来问题定位速度是单人debug的三倍。而且硬件人员盯着软件跑他才能理解为什么软件需要那个10ms的延时、为什么采样率不能随便改、为什么中断里不能加串口打印。这种互相理解是后面避免扯皮的最好方式。6.3 出了问题先查硬件后查软件但不要“只查一边”联调排错有一条铁律先确认硬件供电和信号是否正常再怀疑代码。很多软件bug归根到底是硬件信号出了问题你的程序读到的就是错误的输入那你再怎么改代码都没用。但反过来硬件也不要一有问题就说“我这边正常”请拿示波器实测波形说话。我见过一个队伍功耗异常硬件说程序没进低功耗软件说低功耗状态机写好了两人吵了一下午最后发现是硬件板子上一个上拉电阻焊错了把MCU的某些引脚拉低了导致程序根本进不了休眠。如果硬件早点拿万用表测一测引脚电平这个bug十分钟就解决了。7. 关于文档和测评软件人员不能全甩给别人好就算你的分工合理了、联调顺利了还有一个每一个电赛队伍都绕不开的坑设计报告。我们当年拿过惨痛教训硬件做完了代码跑通了结果那个报告写得一塌糊涂代码流程图画得像涂鸦算法描述含糊其辞最后答辩环节被评委问得说不出话。等看到分数的时候三个人眼睛里全是血丝那几天全白熬了。设计报告这个活核心内容还是要软件人员来写。因为算法流程、状态机、代码结构这些内容硬件队友是真的写不了他们有心想帮你也使不上劲。我的建议是写报告不能放在最后一天而要在过程中同步推进。每天睡觉前主系统负责的同学拿出半个小时把当天完成的模块画成图、写成文字精简地存下来第二天直接集成进报告。你码代码的时候每写完一个功能模块顺手把关键数据结构和一个函数流程图用文字保存下来。这里有个小技巧把你画的状态机和模块划分图直接截图存成设计文档后头报告里直接引用图片永远比文字直观省时省力还显得专业。还有答辩PPT也不要最后一天熬夜做。演示流程从联调阶段就要彩排系统怎么上电、先展示什么指标、后展示什么功能、评委可能问什么坑。主系统负责的同学拿着题目指标一条一条过每一个指标后面都要有实测数据支撑这比临时抱佛脚强一百倍。8. 电赛分工的常见问题速查表我把这些年见过的、听过的电赛分工问题整理成一个表你对照看看自己踩了哪个坑症状根因解法软件同学凌晨三点还在改代码软件工作量严重超载重新审视分工代码模块化让队友介入驱动和调试工具部分硬件队友说“我这边好了”但系统跑不起来软硬件联调接口未对齐用接口文档状态机图同步两边的认知代码写完了队友看不懂没法帮忙代码风格不友好随意命名从第一天就约束变量命名和注释代码要“开放式”答辩时说不出算法原理设计文档没有同步写每天晚结束前花30分钟写进度日志三人各写各的模块联调时崩了没有统一的代码架构和风格接受“代码主权归一个人”其他人公共接口方式协作功能全做完了但指标过不了没有人专职测指标对照测评要求安排主系统角色每完成一项功能立刻对照题目验证一项指标这个表不是万能的但我见过的翻车队伍里八成以上都能对应到其中某一行。提前排查一遍比事后后悔有用得多。9. 最后的心里话电赛不是软件一个人的事写了这么多回过头来把最核心的一句话送给所有即将组队的电赛新人电赛是三个人的比赛不是一个人扛下所有的比赛。一个人扛下所有的后果从来都不是“这队真厉害一个人干了三个人的活”而是“这支队伍软件很强可惜其他方面拖了后腿”。到测评现场你就会发现评委看的不是谁代码写得漂亮而是整个系统有没有完成题目要求、数据是否稳定可靠、功能是否完整。软件代码是系统的灵魂但不是系统的全部。电机不转可能是驱动电路的问题也可能是PID参数没写好波形不对可能是模拟前端设计的问题也可能是FFT算法选错了窗函数屏幕不亮可能是LCD接线虚了也可能是初始化时序不对。电赛的每一个结果都是软硬件共同作用的结果。所以别再骂队友了也别再一个人死扛了——坐下来把这篇分工思路发给队友好好认领各自的职责。三个人各管一摊互相支撑四天三夜结束后还能一起去撸串喝酒这才是电赛该有的样子。