很多单片机竞赛的省一作品看起来并没有特别炫的算法也没有昂贵的开发板。真正让它们和普通作品拉开差距的是几个很容易被忽略的细节拿到题目之后有没有先画需求框图外设资源有没有提前列清楚现场演示是不是准备过两遍。这次广东赛区的G题备赛过程给我最大的一个感受是单片机的价值不在于把某个花哨功能做出来而在于把一个完整小系统做得稳定、完整、可以被解释。这个判断听起来简单但真正执行下去需要一整套工程习惯。如果把这类竞赛题目当成一个“单片机应用项目”你会发现它其实不是一道程序题而是一道系统题。你需要在有限时间内把传感器、执行机构、显示或通信模块接到同一个单片机上让它按照题意协同工作并保证演示时不掉链子。G题往往不是题号靠后所以简单而是它把采集、处理、控制、显示这些环节全部串在了一起任何一个模块出问题整个系统都会卡住。这篇文章不打算复述比赛题目也不打算贴一整套源码而是想聊聊为什么有些队伍能稳定拿省一有些队伍功能做完了却总在演示时翻车。这里面有方案选型的门道有调试顺序的把控也有展示环节的经验值得每一个做单片机项目的人参考。1. 拿到题目先别写代码把需求拆成一张框图1.1 先给系统画一张数据流图我记得比赛刚拿到G题时现场很容易出现一种气氛大家都很兴奋有人马上打开数据手册有人开始接传感器有人直接敲初始化代码。这种“抢跑”看起来很高效但实际上最容易被带偏。因为单片机项目一旦外设接错了地方、资源分配打架后面返工的成本远远高于多花半小时做规划。在常见实践里我拿到题目后第一件事往往不是打开开发环境而是先画一张数据流图。你不需要画得很正式白纸上写清楚三块就够了输入有哪些传感器、按键、外部信号要进单片机。处理单片机需要采样、计算、控制什么涉及哪些定时器、中断、ADC。输出显示模块、电机、蜂鸣器、通信接口分别接在哪里。以G题常见的“测量控制显示”类任务为例数据流通常是这样传感器把物理量变成电压或数字信号单片机通过ADC或GPIO读取再经过滤波、换算或控制算法得到结果最后送到LCD/OLED显示同时输出PWM或开关信号驱动执行机构。图一画出来你会立刻明白这是一个完整回路不是单独写一段“采样程序”或“显示程序”就能完成的。画框图还有一个额外好处它能帮你在写代码之前发现哪些模块需要共用一个外设。比如你要用定时器输出PWM驱动电机同时又要用另一个定时器做捕获测速那在引脚表里就得提前避开通道冲突。如果没有这层规划代码写到一半发现定时器被占用只能推倒重来。1.2 区分“必需功能”和“加分功能”比赛时间有限所有人的精力都是稀缺资源。我倾向于拿到题目后先把题目的要求拆成两列一列是“不实现就扣分/没分”的必需功能另一列是“实现了更好、但优先级靠后”的加分功能。这里可以做一个简单的需求优先级表优先级功能类型常见例子策略P0题目明确要求的核心功能测量物理量、完成控制、显示结果优先实现并反复验证P1题目要求但允许简化报警提示、阈值设置、数据保存在P0稳定后完成P2没有硬性要求但能提升完整度状态指示灯、开机自检、人机交互时间充裕再补为什么要分得这么清楚因为在现场我见过太多队伍花了一整个上午去调一个“更有科技感”的显示界面结果到了下午才发现核心测量功能还没跑通。G题最终看的是完整度和稳定性不是单一加分项的华丽程度。先把P0全部跑通再考虑P1最后才是P2。这个顺序不要乱因为一旦核心功能不稳定后面的加分项全都建立在沙子上。1.3 什么人适合选G题什么时候应该避开G题并不是所有队伍的最佳选择。从这类竞赛的常见情况看G题的任务量通常放在一个完整的小系统上它要求你对单片机的GPIO、定时器、中断、ADC这些基础资源都比较熟悉同时还要有耐心做联调。如果你已经非常熟悉51或STM32这类单片机手里有现成的开发板和模块G题会比纯算法类题目更适合你因为它把“工程实现能力”作为主要考察点而不需要临时去啃大量数学工具。反过来如果团队里大部分人连点灯、串口打印都没跑通过选G题风险就比较大。表面上看G题好像没有特别高深的理论门槛但它是“细节陷阱”任何一个接线错误、时序不对、电源不稳都有可能让你卡住一整晚。更合适的做法是先选一个你熟悉的题目类型而不是选一个“看起来简单”的题目。总之选G题的本质不是选“容易”而是选“你大概率能在规定时间内做得完整”的题目。这句话也是后面所有方案设计的基本出发点。2. 单片机方案的核心不是选型是外设资源分配2.1 选型在“熟悉”和“够用”之间做平衡很多人拿到题目后的第一个问题是用什么单片机这个问题重要但没有想象中那么重要。G题的任务量通常在常见单片机能力范围内关键不是芯片性能有多强而是你团队有没有人能在三天内把它调通。以常见的单片机为例可以做个简单对比单片机优势适用场景注意点51系列寄存器直观、资料多、上手快任务量不大、逻辑简单的控制/测量外设较少、主频低复杂处理会比较紧张STM32外设丰富、定时器/ADC/DMA强采集频率较高、控制较复杂、需要多路信号初始化配置多新手容易在这一步耗时间ESP32自带无线性能较强需要联网、日志远程查看、物联网场景模块本身复杂度高普通G题用不上反而增加故障点从这个表可以看出一件事选型的基本原则是“我能快速跑通”而不是“参数最漂亮”。如果团队在51上已经写过不少代码那51完全够用如果题目明显需要多路ADC、高频采样或复杂控制那STM32会是更稳的选择。这里没有统一答案但有一个很重要的判断标准你选的这个单片机能不能在半天内把最小系统跑起来如果不能说明你们对它的熟悉度还不够支撑比赛节奏。另外要注意一点不要因为某个板子功能多就选它。多出来的Wi-Fi、蓝牙、USB、音频接口如果根本用不上它们不会帮你加分反而会占用引脚、拉高功耗、增加初始化代码量。比赛里“克制”是很重要的能力。2.2 先列外设清单再写引脚表选好单片机之后不要直接开始写驱动。我习惯在一张纸上或者表格里把要用到的外设和对应引脚全部列出来。这张表就是后面写代码和接线时的索引。一个常见的外设清单大概长这样功能模块建议外设/引脚说明显示GPIO并行或I2CLCD1602或OLED注意数据/控制引脚不要乱按键GPIO输入尽量复用行列扫描避免每个按键独占中断测速/编码器定时器外部捕获和PWM输出尽量用不同定时器PWM输出定时器通道确认通道和引脚对应关系ADC采集ADC通道确认参考电压避免超出量程调试串口UART一定留一个串口给日志打印这张表的价值不是形式主义而是它能提前暴露很多问题。比如你的单片机有2个定时器一个要做PWM驱动一个要做外部计数那剩下的延时/按键扫描就不能再依赖定时器得改成主循环调度。又比如UART只有2路一路接蓝牙模块一路接调试串口那传感器如果还想走串口就得换I2C或者SPI否则就得把某一路让出来。在实际项目中外设冲突是排在最前面的坑之一。很多“代码明明没问题但就是工作不正常”的现场事故最后查出来都是引脚复用、外设占用冲突。提前花十分钟列引脚表后面能省几个小时。2.3 程序结构主循环 定时器调度而不是全局delayG题程序的复杂度通常介于“流水账”和“简单状态机”之间。如果全用delay堵塞你会发现一个很经典的问题按下按键没反应因为单片机正卡在某个延时里显示屏刷新变慢因为采样函数占用了太多时间电机一转动显示数据就抖动。这些问题的根源不是代码不会写而是程序结构太脆。我有一个很常用的思路主循环里只做三件事扫描输入、更新状态、刷新输出。具体逻辑可以用一个简易伪代码表示while (1) { Key_Scan(); // 读取按键状态 Process_State(); // 根据输入和传感器更新系统状态 Display_Refresh(); // 刷新显示 }如果任务里需要定时采样或定时PWM再配合定时器中断。以51内核单片机为例常见的定时器初始化可以这样写// 常见写法定时器0方式1定时时长约50ms void Timer0_Init(void) { TMOD 0xF0; // 保留定时器1配置 TMOD | 0x01; // 定时器0方式1 TH0 (65536 - 50000) / 256; TL0 (65536 - 50000) % 256; ET0 1; EA 1; TR0 1; } void Timer0_ISR(void) interrupt 1 using 1 { // 重新装初值 TH0 (65536 - 50000) / 256; TL0 (65536 - 50000) % 256; // 置标志位不要在这里做耗时处理 flag_50ms 1; }这段代码是常见写法不是特定题目的标准答案具体寄存器名称和位定义需要根据你实际用的芯片型号调整。我想强调的核心观点是中断函数里尽量不要做耗时操作不要放串口打印、不要显示刷新、不要长时间循环最好只有“置标志位、修改变量”这类简单动作。真正复杂的处理放到主循环里去判断标志位。这个结构虽然简单却能让系统稳定不少。你会发现按键扫描灵敏了显示不再因为电机启动而卡住调试也更容易定位问题。它不要求你掌握复杂操作系统只是把一个最基本的“事件驱动”思想用到单片机上。3. 调试不是碰运气按输入、环境、参数、边界来排查3.1 先确认最小系统再调业务逻辑G题现场最容易出现的一种情况是程序下载进去了单片机没反应。很多人第一反应是“代码写错了”于是在代码里翻来覆去找问题最后折腾半天发现是电源线松了或者是晶振没起振甚至下载器根本没连上。我把这种问题归为“最小系统没跑通”。不管后续功能多复杂最小系统永远是第一道关卡。拿到板子上电后先确认几件事电源电压是否正常万用表量一下VCC和GND确认不是5V输出却接到3.3V模块。复位引脚状态是否正确有些单片机需要外部上拉有些需要手动复位确认没有异常拉低。晶振或内部时钟是否起振如果使用的是外部晶振用示波器看晶振引脚有没有波形或者干脆先用内部时钟跑通再说。程序能不能下载进去用开发板的LED先跑一个最基础的点灯程序确认下载链路和芯片本身没问题。这个过程看起来很基础但它能帮你把“硬件问题”和“软件问题”切分开。如果最小系统都没跑通后面所有的驱动代码都是空中楼阁。很多看似“代码为什么不行”的现场事故最后查出来是电源接触不良。3.2 输入侧和输出侧分开验证G题系统一般都有明确的输入和输出。调试时最忌讳把整个系统一次性跑起来然后看“整体效果不对”因为你很难判断问题出在输入、处理还是输出。更稳的做法是分段验证。输入侧以ADC采集传感器信号为例我习惯先用串口把原始采样值打出来。不要急着滤波、不要急着换算物理量先看原始值是否稳定、是否在合理范围内。如果原始值跳得厉害先检查传感器供电、参考电压、接线屏蔽和共地问题再决定要不要加软件滤波。如果原始值根本不是预期量级那大概率是硬件接错了而不是滤波参数不对。输出侧以PWM驱动电机或执行机构为例先用示波器看输出引脚有没有波形频率和占空比是否随参数变化。如果引脚有波形但电机不动检查驱动电路和供电电流如果引脚根本没有波形检查定时器配置和使能位。这套路径一执行很多“莫名其妙”的问题会立刻现形。这里可以整理一个简单的分段验证检查表验证对象检查方式通过标准输入传感器/ADC串口打印原始值数值稳定、范围合理按键/开关串口打印键值按下和释放状态正确显示模块单独测试显示字符串无乱码、无闪烁PWM输出示波器看波形频率、占空比可调执行机构观察动作 测量电流动作准确、供电不跌落3.3 常见坑电平、噪声、溢出、中断耗时调试过程中真正花时间的往往不是“某个功能不会”而是“某个功能有时候好有时候不好”。这种不稳定的问题通常来自几个固定原因。第一个坑是电平不匹配。5V单片机和3.3V传感器之间没有做电平转换导致信号读不到或烧毁引脚。遇到这类问题先查逻辑电平。第二个坑是电源噪声。电机启动瞬间电流拉大导致ADC参考电压跌落采集数据突然跳动。遇到这类问题先做“电源分隔”把大电流负载和传感器分别供电或者加去耦电容不要一开始就怀疑算法。第三个坑是变量溢出。定时器初值、计数器方向、数据类型位数都可能导致程序跑了几分钟后行为异常调试时要特别注意溢出点。第四个坑是中断里做耗时操作比如在中断里刷屏、打印、延时导致主循环卡顿表现为整个系统响应迟钝。针对这些常见坑我自己的排查顺序是稳定的先看现象再看输入再看环境再看参数最后才怀疑工具边界。换句话说不要一上来就改代码。先确认输入信号有没有问题再确认供电和接线是否正常然后检查参数配置最后才考虑是不是这个单片机/模块本身做不到。这个顺序能帮你在现场少绕很多弯子。3.4 一个针对现场故障的五层排查法把上面的经验收拢一下可以沉淀成一个非常通用的排查框架比赛、课程设计、DIY项目都能用现象层先描述清楚“到底哪里不对”是不动、乱跳、卡死、还是显示错。输入层采集信号、按键、外部数据是否正常用串口打印原始值。环境层电源、接线、电平、共地、干扰是否正常用万用表确认。参数层代码里的初值、阈值、中断配置、时钟频率是否合理。工具层是不是芯片/模块能力不够或者是否选错了方案方向。这套方法听着朴素但特别有用。因为在现场人的心态一旦紧张就会想彻底重写代码。而重写代码往往是最耗时的选择。先按照5层逐层确认通常问题会在第2层或第3层就露头。4. 效果展示不是把作品放到评委面前就行4.1 做一个3分钟演示脚本G题评分不只是看硬件和代码还要看现场演示。我见过很多作品功能全部做出来了但演示时选手手忙脚乱评委看不到重点最后得了一个不太匹配的分数。这很可惜因为“展示效果”完全是可以提前准备的。我更建议每个队伍准备一个3分钟左右的演示脚本顺序是固定的第1分钟演示完整流程。让评委看到系统从上电、自检、采集、处理到输出的整个闭环。第2分钟演示关键指标。比如测量精度、响应速度、控制效果把具体数据显示出来最好有一个前后对比。第3分钟演示异常处理或边界情况。比如超阈值报警、按键调整参数、断电重启后恢复等这能体现作品完整度。演示脚本的背后有一个原则评委在短时间内能接收的信息有限。你要把最有说服力的数据放在前面把“能体现完整度”的细节放在后面而不是让评委在台前等你慢慢操作。4.2 如果现场演示失败了怎么办比赛现场最容易翻车的不是“功能没实现”而是“刚刚还好好的怎么上台就不动了”。造成这个问题的原因有很多拔插线缆时接触不良、供电换了电池电压不稳、环境光照干扰传感器、上次调试改了参数没改回来。遇到这种情况我的建议是先不要慌也不要直接打开代码重刷。先看板子上的电源指示灯是不是亮的再看显示屏有没有反应然后看执行机构有没有动作。如果都没有从电源和接线开始排查如果只是某个数据不对检查传感器探头是否被遮挡、参数是否被人动过。备用的做法是预置多套参数方案通过按键一键切换。这样即便现场环境和你调试时不一样也能快速切到另一套配置而不是临场改代码编译下载。另外演示前多带几根杜邦线、一块备用电源、一个万用表这些小物件不一定用得上但真出问题时能救命。4.3 把效果沉淀成素材照片、波形、日志“效果展示”不应止于比赛现场的几分钟。赛后整理资料同样重要。我一般会保留这几样东西系统框图或引脚分配表方便复盘和复用。核心代码片段尤其是定时器配置、状态机、调试信息打印。实测数据包括串口日志、传感器标定数据、误差分析。示波器截图、演示照片、实物接线图。这些素材有什么用它们能让你的项目从“做完了”变成“可复现、可讲解、可迭代”。后续面试、保研、找实习、写博客、做课程设计甚至下一场比赛都可以直接拿出来用。G题省一只是一个结果真正沉淀下来的是这套“从需求到实现再到展示”的完整链路。你也可以靠这套素材把一次比赛经验变成自己的技术资产。5. 省一的底层逻辑稳定性和完整度永远排在炫技前面5.1 为什么朴素的完整方案常常赢回过头看这次G题的经验我的核心判断是竞赛评分不会奖励“看起来复杂但动不动就崩”的方案。反而是那些功能完整、演示顺畅、每个交互都有效的朴素设计更容易拿到高分。原因很简单。评委打分的时候关注的是题目要求有没有全部实现、实测数据是否稳定、操作是否流畅、设计文档是否统一。如果你花了很多时间做一个“语音控制”加“手机App显示”的加分项结果现场Wi-Fi连不上语音识别偶尔失灵评委记住的就不是“这个队伍做了很多”而是“这个作品不稳定”。我并不是说不能做加分项而是说加分项必须放在核心功能非常稳定的前提下并且要有兜底方案。比如语音控制失效时还能用按键操作App连不上时显示屏依然能完整工作。这样加分项才真的是加分而不是减分。5.2 这套经验适用哪里不适用哪里写到这里需要明确一下适用边界。这篇文章里的方法和经验最适合的场景是单片机竞赛、课程设计、综合实训。学习阶段做完整小项目目标是跑通全流程、整理文档、展示效果。DIY原型验证希望快速把想法变成能演示的样机。但它并不适合直接照搬到生产级产品。商业产品还需要考虑可靠性设计、故障恢复、外壳结构、EMC、生产测试、批量一致性、长期稳定性、代码规范和版本管理这些远不是一场比赛能覆盖的。换句话说比赛经验的价值在于培养工程思维和调试能力而不是说比赛代码可以直接量产。如果你把一个比赛作品直接当作产品原型去谈合作或投项目后续会踩很多坑。这两者的边界要分清楚。5.3 一个可复用的五步框架最后把这次G题经验收成一套可以带走的方法。以后无论接到什么单片机项目哪怕不是竞赛只是课设或DIY都可以按这个顺序推进画需求框图。先不写代码把输入、处理、输出三层画清楚确定完整回路。列外设资源表。把引脚、定时器、UART、ADC、GPIO全部列出来提前发现冲突。先跑最小系统。点灯、串口打印确认硬件和下载链路没问题。分段验证输入输出。输入侧看原始值输出侧看波形或动作别把系统当黑盒。做演示脚本和文档。把流程、数据、指标、异常处理准备成可讲解的素材。这套框架看起来朴素但它是很多“省一”作品背后的共同点。它不代表你一定能拿奖但它能把“能不能拿奖”从随机事件变成可以主动控制的工程过程。对做单片机的人来说这比一块奖牌更实用。省一不是终点。真正值钱的是你在这个过程中建立起来的判断力和做事方式接一个项目先画链路调一个bug先分层排查做一次展示先准备脚本。下一次当你面对一个完全陌生的单片机模块时这些习惯依然会帮你找到入口。这也是那次G题留给我最实在的东西。