单片机竞赛省一的关键：从需求框图到稳定演示的工程细节

很多单片机竞赛的省一作品，看起来并没有特别炫的算法，也没有昂贵的开发板。真正让它们和普通作品拉开差距的，是几个很容易被忽略的细节：拿到题目之后有没有先画需求框图，外设资源有没有提前列清楚，现场演示是不是准备过两遍。这次广东赛区的G题备赛过程，给我最大的一个感受是：单片机的价值不在于把某个花哨功能做出来，而在于把一个完整小系统做得稳定、完整、可以被解释。这个判断听起来简单，但真正执行下去，需要一整套工程习惯。

如果把这类竞赛题目当成一个“单片机应用项目”，你会发现它其实不是一道程序题，而是一道系统题。你需要在有限时间内，把传感器、执行机构、显示或通信模块接到同一个单片机上，让它按照题意协同工作，并保证演示时不掉链子。G题往往不是题号靠后所以简单，而是它把采集、处理、控制、显示这些环节全部串在了一起，任何一个模块出问题，整个系统都会卡住。这篇文章不打算复述比赛题目，也不打算贴一整套源码，而是想聊聊：为什么有些队伍能稳定拿省一，有些队伍功能做完了却总在演示时翻车。这里面有方案选型的门道，有调试顺序的把控，也有展示环节的经验，值得每一个做单片机项目的人参考。

1. 拿到题目先别写代码：把需求拆成一张框图

1.1 先给系统画一张数据流图

我记得比赛刚拿到G题时，现场很容易出现一种气氛：大家都很兴奋，有人马上打开数据手册，有人开始接传感器，有人直接敲初始化代码。这种“抢跑”看起来很高效，但实际上最容易被带偏。因为单片机项目一旦外设接错了地方、资源分配打架，后面返工的成本远远高于多花半小时做规划。

在常见实践里，我拿到题目后第一件事往往不是打开开发环境，而是先画一张数据流图。你不需要画得很正式，白纸上写清楚三块就够了：

• 输入：有哪些传感器、按键、外部信号要进单片机。
• 处理：单片机需要采样、计算、控制什么，涉及哪些定时器、中断、ADC。
• 输出：显示模块、电机、蜂鸣器、通信接口分别接在哪里。

以G题常见的“测量+控制+显示”类任务为例，数据流通常是这样：传感器把物理量变成电压或数字信号，单片机通过ADC或GPIO读取，再经过滤波、换算或控制算法得到结果，最后送到LCD/OLED显示，同时输出PWM或开关信号驱动执行机构。图一画出来，你会立刻明白：这是一个完整回路，不是单独写一段“采样程序”或“显示程序”就能完成的。

画框图还有一个额外好处：它能帮你在写代码之前发现哪些模块需要共用一个外设。比如你要用定时器输出PWM驱动电机，同时又要用另一个定时器做捕获测速，那在引脚表里就得提前避开通道冲突。如果没有这层规划，代码写到一半发现定时器被占用，只能推倒重来。

1.2 区分“必需功能”和“加分功能”

比赛时间有限，所有人的精力都是稀缺资源。我倾向于拿到题目后，先把题目的要求拆成两列：一列是“不实现就扣分/没分”的必需功能，另一列是“实现了更好、但优先级靠后”的加分功能。

这里可以做一个简单的需求优先级表：

为什么要分得这么清楚？因为在现场，我见过太多队伍花了一整个上午去调一个“更有科技感”的显示界面，结果到了下午才发现核心测量功能还没跑通。G题最终看的是完整度和稳定性，不是单一加分项的华丽程度。先把P0全部跑通，再考虑P1，最后才是P2。这个顺序不要乱，因为一旦核心功能不稳定，后面的加分项全都建立在沙子上。

1.3 什么人适合选G题，什么时候应该避开

G题并不是所有队伍的最佳选择。从这类竞赛的常见情况看，G题的任务量通常放在一个完整的小系统上，它要求你对单片机的GPIO、定时器、中断、ADC这些基础资源都比较熟悉，同时还要有耐心做联调。如果你已经非常熟悉51或STM32这类单片机，手里有现成的开发板和模块，G题会比纯算法类题目更适合你，因为它把“工程实现能力”作为主要考察点，而不需要临时去啃大量数学工具。

反过来，如果团队里大部分人连点灯、串口打印都没跑通过，选G题风险就比较大。表面上看G题好像没有特别高深的理论门槛，但它是“细节陷阱”，任何一个接线错误、时序不对、电源不稳，都有可能让你卡住一整晚。更合适的做法是先选一个你熟悉的题目类型，而不是选一个“看起来简单”的题目。

总之，选G题的本质不是选“容易”，而是选“你大概率能在规定时间内做得完整”的题目。这句话也是后面所有方案设计的基本出发点。

2. 单片机方案的核心不是选型，是外设资源分配

2.1 选型：在“熟悉”和“够用”之间做平衡

很多人拿到题目后的第一个问题是：用什么单片机？这个问题重要，但没有想象中那么重要。G题的任务量通常在常见单片机能力范围内，关键不是芯片性能有多强，而是你团队有没有人能在三天内把它调通。

以常见的单片机为例，可以做个简单对比：

从这个表可以看出一件事：选型的基本原则是“我能快速跑通”，而不是“参数最漂亮”。如果团队在51上已经写过不少代码，那51完全够用；如果题目明显需要多路ADC、高频采样或复杂控制，那STM32会是更稳的选择。这里没有统一答案，但有一个很重要的判断标准：你选的这个单片机，能不能在半天内把最小系统跑起来？如果不能，说明你们对它的熟悉度还不够支撑比赛节奏。

另外要注意一点：不要因为某个板子功能多就选它。多出来的Wi-Fi、蓝牙、USB、音频接口，如果根本用不上，它们不会帮你加分，反而会占用引脚、拉高功耗、增加初始化代码量。比赛里“克制”是很重要的能力。

2.2 先列外设清单，再写引脚表

选好单片机之后，不要直接开始写驱动。我习惯在一张纸上或者表格里，把要用到的外设和对应引脚全部列出来。这张表就是后面写代码和接线时的索引。

一个常见的外设清单大概长这样：

这张表的价值不是形式主义，而是它能提前暴露很多问题。比如你的单片机有2个定时器，一个要做PWM驱动，一个要做外部计数，那剩下的延时/按键扫描就不能再依赖定时器，得改成主循环调度。又比如UART只有2路，一路接蓝牙模块，一路接调试串口，那传感器如果还想走串口，就得换I2C或者SPI，否则就得把某一路让出来。

在实际项目中，外设冲突是排在最前面的坑之一。很多“代码明明没问题但就是工作不正常”的现场事故，最后查出来都是引脚复用、外设占用冲突。提前花十分钟列引脚表，后面能省几个小时。

2.3 程序结构：主循环 + 定时器调度，而不是全局delay

G题程序的复杂度通常介于“流水账”和“简单状态机”之间。如果全用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驱动电机或执行机构为例，先用示波器看输出引脚有没有波形，频率和占空比是否随参数变化。如果引脚有波形但电机不动，检查驱动电路和供电电流；如果引脚根本没有波形，检查定时器配置和使能位。这套路径一执行，很多“莫名其妙”的问题会立刻现形。

这里可以整理一个简单的分段验证检查表：

3.3 常见坑：电平、噪声、溢出、中断耗时

调试过程中真正花时间的，往往不是“某个功能不会”，而是“某个功能有时候好有时候不好”。这种不稳定的问题，通常来自几个固定原因。

第一个坑是电平不匹配。5V单片机和3.3V传感器之间没有做电平转换，导致信号读不到或烧毁引脚。遇到这类问题，先查逻辑电平。第二个坑是电源噪声。电机启动瞬间电流拉大，导致ADC参考电压跌落，采集数据突然跳动。遇到这类问题，先做“电源分隔”，把大电流负载和传感器分别供电，或者加去耦电容，不要一开始就怀疑算法。第三个坑是变量溢出。定时器初值、计数器方向、数据类型位数都可能导致程序跑了几分钟后行为异常，调试时要特别注意溢出点。第四个坑是中断里做耗时操作，比如在中断里刷屏、打印、延时，导致主循环卡顿，表现为整个系统响应迟钝。

针对这些常见坑，我自己的排查顺序是稳定的：先看现象，再看输入，再看环境，再看参数，最后才怀疑工具边界。换句话说，不要一上来就改代码。先确认输入信号有没有问题，再确认供电和接线是否正常，然后检查参数配置，最后才考虑是不是这个单片机/模块本身做不到。这个顺序能帮你在现场少绕很多弯子。

3.4 一个针对现场故障的五层排查法

把上面的经验收拢一下，可以沉淀成一个非常通用的排查框架，比赛、课程设计、DIY项目都能用：

1. 现象层：先描述清楚“到底哪里不对”，是不动、乱跳、卡死、还是显示错。
2. 输入层：采集信号、按键、外部数据是否正常，用串口打印原始值。
3. 环境层：电源、接线、电平、共地、干扰是否正常，用万用表确认。
4. 参数层：代码里的初值、阈值、中断配置、时钟频率是否合理。
5. 工具层：是不是芯片/模块能力不够，或者是否选错了方案方向。

这套方法听着朴素，但特别有用。因为在现场，人的心态一旦紧张，就会想彻底重写代码。而重写代码往往是最耗时的选择。先按照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，都可以按这个顺序推进：

1. 画需求框图。先不写代码，把输入、处理、输出三层画清楚，确定完整回路。
2. 列外设资源表。把引脚、定时器、UART、ADC、GPIO全部列出来，提前发现冲突。
3. 先跑最小系统。点灯、串口打印，确认硬件和下载链路没问题。
4. 分段验证输入输出。输入侧看原始值，输出侧看波形或动作，别把系统当黑盒。
5. 做演示脚本和文档。把流程、数据、指标、异常处理准备成可讲解的素材。

这套框架看起来朴素，但它是很多“省一”作品背后的共同点。它不代表你一定能拿奖，但它能把“能不能拿奖”从随机事件变成可以主动控制的工程过程。对做单片机的人来说，这比一块奖牌更实用。

省一不是终点。真正值钱的，是你在这个过程中建立起来的判断力和做事方式：接一个项目，先画链路；调一个bug，先分层排查；做一次展示，先准备脚本。下一次，当你面对一个完全陌生的单片机模块时，这些习惯依然会帮你找到入口。这也是那次G题留给我最实在的东西。