2026 年电赛 G 题的单片机方案很多队伍从备赛第一天就在纠结到底用 51 还是 STM32要不要上 RTOS要不要提前把各种模块驱动都写好这些问题当然重要但我看了这么多年参赛团队的实际过程真正拉开差距的往往不是用了哪块芯片而是拿到题目之后能不能在有限时间里把一条从传感器输入到控制输出的完整链路跑稳。这篇内容不打算去预测 2026 电赛 G 题的具体题目因为官方题目没有公布之前任何“精准押题”都不可靠。我更想聊的是一套通用做法当你面对一个陌生题目时如何用单片机方案快速拆解、选型、写驱动、做联调、应对现场突发问题。这套做法不仅对电赛 G 题有效对明年、后年甚至对以后做课程设计、毕业设计、小型工程项目都有用。1. 拿到赛题后先别写代码先拆成三大模块电赛单片机组题目通常不会只考一个点。它往往包含传感器采集、按键输入、显示输出、执行机构控制、电源变换等多个环节。如果一上来就开 Keil 写代码很容易写到一半发现结构不对改动成本极高。我建议拿到题目后先花半小时到一小时做一件事把整套系统拆成三个大块——感知、决策、执行。感知包括所有输入信号比如按键、拨码、温度传感器、光电编码器、电流电压采样。决策就是单片机程序本身包括逻辑判断、算法运算、状态切换。执行则是输出部分比如电机驱动、继电器、蜂鸣器、LCD 显示、数码管、加热管控制。这样拆完之后你会得到一张模块图而不是一团代码压力。1.1 控制核心输入、处理、输出先不要纠结“单片机最小系统到底要不要自己画板”而是先弄清楚题目里的被控对象是什么。比如搜热词里经常出现“51 单片机实现电磁炉功能代码”“单片机小车测速”“温度上下限报警”这些对应的是加热控制、测速、阈值判断。哪怕具体题目不同它们的共性是都需要把物理信号变成电平或数字量再由单片机处理后输出控制信号。所以第一件事是把“输入端口”和“输出端口”在纸面上标出来。输入端口不需要只理解成 GPIO它可以是定时器捕获、外部中断、ADC 采样、串口数据。输出端口也不只是高低电平还可以是 PWM 波、串口指令、I2C/SPI 总线数据。比赛时你会发现题目里很多隐藏考点不在功能本身而在信号类型和时序配合上。1.2 用一张画布完成模块级解耦我习惯在 A4 纸上画一个简单的方块图左边是输入中间是单片机右边是执行机构下边是电源和调试接口。每个方块之间用箭头连接箭头旁边标出信号类型。这个动作看起来简单但它能帮你快速发现两个问题输入信号和单片机引脚的电平范围是否匹配输出信号的驱动能力是否足够直接驱动负载很多队伍在联调时才暴露这两个问题因为画图时没有考虑电平匹配和驱动电流。比如 51 单片机 GPIO 高电平驱动能力有限直接驱动继电器或者大功率设备时要么加三极管/MOS 管要么改用达林顿芯片或光耦隔离。这些不是写代码能解决的必须在方案阶段就确定。1.3 给每个子任务设一个“快照版本”拆完模块后建议给每个模块定义一个“最小可运行版本”。例如“按键按下能点亮一个 LED”“电机能转起来”“LCD 第一行能显示一个变量”“ADC 能读到电压并串口打印”。这些快照不要求功能完整只要求链路通。这样做的好处是联调时一旦出问题可以迅速定位到具体模块而不是面对一个几千行代码的工程从头查。我记得早期参赛时吃过一次亏把所有代码一次性写完结果上电完全不工作串口也没有任何输出。后来花了两小时才发现是晶振配置和延时函数不匹配而这个问题在写第一个点灯程序时就能发现。如果你也给每个子任务保留快照当时最多五分钟就能定位。2. 51 单片机还是 STM32G 题选型的四个判断标准“选 51 还是 STM32”永远是备赛群里的热门话题。如果只看社区讨论你可能会以为 51 已经过时应该直接上双核处理器。但电赛和做产品的逻辑不一样比赛比的是在有限时间内稳定完成题目的能力不是比芯片数量和外设复杂度。我建议用四个标准来决策而不是用“哪个更高级”来判断。2.1 选型先看外设够不够而不是芯片贵不贵第一题目里要求的采样频率、通信协议、PWM 输出通道数、中断数量决定你需要什么级别的单片机。如果题目只是开关量控制、LCD 显示、速度测量、温度报警51 单片机通常完全够用。它用外部中断做按键用定时器做测速用定时器产生 PWM用 GPIO 模拟 I2C 或 SPI基本都能覆盖。优势是真的熟悉资料多遇到问题好找参考。劣势是 ADC 精度、Flash 大小、主频都比较有限不适合做复杂 DSP 处理和大量浮点运算。如果题目要求实时性比较高的信号处理、FFT、PID 调参、屏幕刷新或者要同时挂多个传感器和通信模块那 STM32 或其它 32 位 MCU 更从容。核心原因是它的定时器外设更丰富、主频更高、ADC 和 DMA 配合更好用能减少 CPU 被低速外设拖累。所以选型的第一步不是看“哪个更先进”而是把题目需要的资源清单列出来做一次匹配。2.2 比赛时间表下的学习成本第二团队已经熟悉哪种平台比平台本身的性能更重要。如果你以前一直写 51并且对定时器、中断、GPIO 操作都很熟那遇到陌生题目稳定发挥比临时换平台更划算。比赛时间是以小时计的没有一个月让你边学边踩坑。但反过来说如果距离比赛还有几个月并且你现在还没有太深的单片基础我建议从 51 入手因为它能帮你把“单片机的工作原理、定时器计数、中断、寄存器操作、内存映射”这些底层逻辑搞清楚。之后再转 STM32你会少很多玄学问题。因为 32 位 MCU 的核心流程并不是“更难”而是外设更多、配置更复杂底层逻辑并没有本质变化。2.3 从热搜词看51 系的备赛知识点依然高频我们看今年和近期的热搜词会看到大量“51 单片机定时器计数器工作原理”“51 单片机电子时钟”“51 单片机收音机代码”“51 单片机控制 MOS 管电路”“用 51 单片机实现电磁炉功能”等。这其实说明很多参赛队伍在备赛时仍然把 51 作为基础训练平台。这里要提醒一个误区搜到很多 51 代码并不等于你能直接用。很多借来的工程是别人为了特定板卡写的引脚定义、晶振频率、延时函数、头文件都和你的环境不同。直接复制大概率会跑不出预期结果。更合理的做法是把它当成一份“实现逻辑参考”然后把 IO 映射和时序重新对到自己的板子上。2.4 推荐一套最低风险配置如果让我给一个最低风险配置我会推荐“手头最熟的平台 能力范围内性能有余量的型号”。比如熟 51 就选 STC8 系列因为它在传统 51 基础上增加了 ADC、PWM、更高主频内部资源也更丰富熟 STM32 就选 STM32F103 或 F407社区资料多出问题容易找。不要为了炫技选一块团队没人用过的新型号电赛现场没有时间给你看数据手册从头学。注意选型并不是越强越好。赛题验收只看功能完成度和稳定性。你用一个四核处理器做温度报警并不会比一块 STC8 更容易拿高分反而可能因为配置复杂导致不稳定。3. 核心外设设计定时器、LCD1602、测速与电源管理确定主控之后真正花时间的不是点灯而是把每个外设都用到“可控、可调、可诊断”的程度。下面这几个模块是电赛单片机题里的高频元素也是最近热搜里出现频率较高的知识点。3.1 定时器与中断先定时间骨架再写业务逻辑单片机的定时器计数器工作原理并不复杂多数教材会讲“计数器从初值开始在时钟脉冲下递增溢出时触发中断”。但在实际工程中很多人会在一开始就把定时器配置复杂化。我建议先把时间骨架定出来你需要一个 1ms 或者 10ms 的系统时基。所有周期性任务比如按键扫描、动态显示、状态刷新、速度采样都挂到这个时基上。这样可以避免大量使用“毫秒级延时函数”阻塞主循环。参考结构volatile uint16_t sys_tick_ms 0; void Timer0_Init(void) { // 以 12MHz 晶振、方式 1 为例 TMOD 0xF0; TMOD | 0x01; // 定时器0方式116位定时器 TH0 0xDC; // 初值结合晶振频率计算 TL0 0x00; ET0 1; // 开定时器0中断 TR0 1; // 启动定时器0 EA 1; // 开总中断 } void Timer0_ISR(void) interrupt 1 { TH0 0xDC; TL0 0x00; sys_tick_ms; }这段代码是把一个时间节拍作为整个系统的“心跳”。其它任务不要再自己重新搞一套延时。你要做的是在主循环里判断节拍是否到达然后执行对应逻辑。这种方式比“死等延时”强很多也是后面做任务调度的底层基础。3.2 LCD1602 调试界面把状态变量做成人眼可见的窗口很多电赛题目离不开显示模块LCD1602 凭借成本低、资料多、接口简单依然是很多队伍的首选。但很多人只把 LCD 当成“最终显示结果”的界面这个定位浪费了 LCD 的调试价值。我更建议把 LCD 同时当调试窗口。比赛时数据对不对不能靠猜。你可以在 LCD 上分行显示当前模式、传感器原始值、设定阈值、输出 PWM 占空比、定时器捕获值。这样当你按下按键改变参数时能立刻看到变量是否按照预期变化。LCD1602 的关键点在于初始化和时序。如果你的 LCD 显示乱码或者不显示不要急着换模块先检查三个位置VCC 和 GND 是否接对背光电压是否独立。电位器是否把对比度调到合适位置常见问题是对比度太低导致纯黑。时序延时是否足够很多 51 单片机的 LCD 驱动需要延时等待不能连续快速写。如果使用 STM32 或其它芯片还要检查 GPIO 的上下拉设置和复用配置。3.3 测速与编码器输入捕获模式的关键细节“单片机小车测速”几乎是历年的常客。测速通常利用光电编码器输出脉冲单片机测量单位时间内的脉冲数再换算成速度。这个逻辑听起来简单但实际代码里最容易踩坑的是“如何在不漏脉冲的情况下完成测量”。如果你用 GPIO 轮询读取编码器电平速度快一点就可能丢脉冲。更合理的做法是用外部中断或定时器捕获模式。51 单片机可以用外部中断引脚接入编码器 A 相信号每产生一个下降沿中断在中断里计数。STM32 则可以直接用定时器的编码器模式由硬件完成计数软件只需要定期读取计数器值。测量时还要区分“测频法”和“测周法”。高速旋转时适合在固定时间内计脉冲数低速旋转时适合测量脉冲周期再换算速度。很多队伍在低速测试时发现速度特别不稳就是因为固定时间窗口内只采到少数几个脉冲误差被放大。这时可以减少采样周期或者改用测周法同时做多次平均。3.4 电源模块再好的代码也经不起供电抖动电赛电源模块是热搜里另一个高频词。很多单片机系统看起来逻辑正常但一接执行机构就复位、乱码、输出异常。第一个要怀疑的不是代码而是电源。我见过很多参赛团队用电脑 USB 口同时给开发板和电机驱动供电结果电机一转单片机上电欠压直接复位。正确的做法是把数字电源和功率电源分开。强电部分比如电机、电磁铁、加热管用独立电源单片机、传感器、显示模块用稳压后的数字电源。如果题目需要使用 MOS 管控制大功率负载还要注意 MOS 管的栅极驱动电压和单片机 GPIO 输出电平是否匹配。很多 51 单片机的 GPIO 高电平只有 3.3V 或 5V 左右而 MOSFET 完全导通需要更高的栅极电压这时需要加驱动电路或选择逻辑电平 MOSFET否则管子工作在放大区发热严重。4. 从单模块验证到全流程联调一种三步推进法很多参赛队伍的时间线是前两三天准备模块中间一天写主程序最后一天联调。结果联调时各种问题集中爆发改到凌晨也没有全通。更合理的做法是把联调拆成三个可执行阶段每个阶段都有明确出口。4.1 第一步用最小点亮法验证每个模块“最小点亮”是我自己的说法意思是让每个模块先进入“可观测的最简单状态”。比如按键按下时点亮板载 LED。传感器串口打印原始值确认数值范围。LCD先显示一行固定的字符串不驱动任何业务变量。电机发送一个固定的 PWM 占空比看电机是否转动。上位机能通过串口接收一条字符串并返回 ACK。这个阶段不追求功能完整只追求“链路通”。这样一旦后面出问题你可以非常肯定地说“传感器模块 OK问题出现在信号换算逻辑”而不是全系统乱抓。4.2 第二步搭一个“裸机状态机”把多个任务串起来当每个模块单独都能工作后再开始串联。常见做法是写一个状态机把整个系统运行流程拆成几个状态比如“待机”“参数设置”“运行”“报警”“暂停”。每个状态对应一组行为状态切换由按键、传感器阈值或命令触发。状态机的好处是让主循环清晰新增功能时不容易打乱已有逻辑。一个简单的结构如下void main_loop(void) { while(1) { switch(current_state) { case STATE_IDLE: // 待机逻辑 break; case STATE_RUNNING: // 运行逻辑 break; case STATE_ALARM: // 报警逻辑 break; default: break; } // 1毫秒节拍任务按键扫描、显示刷新等 } }这一步能把前期的模块快照真正组合成一个“系统”。你不需要第一时间把所有功能都塞进状态机可以先从关键路径开始按键设置阈值传感器读取执行机构动作显示结果。4.3 第三步压测边界条件和异常恢复系统能跑通之后还要主动“找麻烦”。常见压测方法有连续快速按键看界面是否错乱。传感器输入在阈值附近反复波动看会不会频繁进入报警。增加执行负载比如电机堵转、负载变化看电源是否还稳。把供电断一下再上电看系统能否自动恢复到正常状态。长时间运行一小时看会不会出现定时器漂移、显示闪烁、内存泄漏。这些边界测试才是真正区分“能做出来”和“能稳定跑完”的关键。很多队伍平时只在正常条件下测试比赛现场只要有一点干扰就崩了。注意压测并不是比赛前才做。每完成一个关键功能就应该跑一次边界测试。比赛前一天再压测发现问题也来不及改了。5. 代码工程化让参赛代码可调试、可回滚、可复用电赛代码虽然只跑一次但它的质量决定了你调试时的效率。很多同学写代码习惯全堆在 main.c 里几千行没有函数划分没有调试开关一旦出问题根本不敢改动。到了比赛现场这种代码就是定时炸弹。5.1 分层写代码驱动、应用、调度我建议把代码至少分成三层驱动层直接操作寄存器或外设比如lcd1602_write_command()、motor_set_pwm()、adc_read_channel()。应用层完成业务逻辑比如temperature_check()、speed_calculation()、key_process()。调度层决定什么时候调用哪个应用层函数比如 main 循环和定时器中断服务。这样做的好处是当显示有问题时你只需要看驱动层里的 LCD 初始化当逻辑判断错误时你只需要看应用层里的阈值判断函数当整个节奏不对时你只需要关注时基和调度。三层之间不要交叉调用否则又变回一团乱麻。5.2 给代码加调试开关和错误码比赛调试时我们经常要临时打印很多中间变量。但如果每次都在代码里随便加printf调试完还要手动删除容易误删有效逻辑。更稳妥的做法是定义调试宏#define DEBUG_ENABLE 1 #if DEBUG_ENABLE #define DEBUG_PRINT(...) printf(__VA_ARGS__) #else #define DEBUG_PRINT(...) #endif这样你可以在代码里放大量调试输出比赛时如果担心串口拖慢速度就把宏改为 0不需要删代码。同时定义一套错误码比如ERROR_LCD_TIMEOUT、ERROR_SENSOR_RANGE、ERROR_MOTOR_STALL把这些错误码显示到 LCD 或者通过串口发送。这样出问题时你看到的是一个具体原因而不是一个诡异的画面。5.3 用日志和串口反向验证时序问题有一些问题不是模块坏了而是时序不对。比如传感器读数只能在特定时刻更新但你却在自己定义的“某个时刻”读取或者电机控制需要先使能再给 PWM但你的代码顺序反了。这类问题用 LED 指示灯也看不出来更好的方式是在关键位置打上时间戳。比如记录进入中断的时间、退出中断的时间、某次测量完成的时间。然后把时间戳通过串口发到电脑你就能看到运行序列是否符合预期。在 51 单片机上串口打印会占用主循环时间建议只在调试时开启正式比赛可以关闭。在 STM32 上可以更激进一点用 DMA 发送日志避免阻塞。6. 常见坑点与排查链路比赛时最怕的不是不会做而是“一切都看着正常但结果不对”。下面我总结几个高频故障现象和对应的排查顺序。6.1 现象跑起来但数据不对先查输入和格式如果是传感器采集的数据明显不合理不要先怀疑算法先确认原始值是否可信。排查顺序传感器供电电压是否正确参考电压是否稳定。信号线是否接触良好有没有被电机电源线干扰。ADC 通道选择是否正确有没有切错通道。数据手册里传感器的曲线是线性的还是分段的你的换算公式是否匹配。单位有没有换算错误比如温度传感器输出的是 mV 不是 °C。很多人在这里直接去调软件滤波反而越调越乱。其实先解决输入问题后面一大半逻辑就正常了。6.2 现象周期性中断卡死怀疑资源占用和优先级如果系统运行一段时间后突然不再响应常见原因不是逻辑卡死而是中断异常。比如定时器中断和外部中断同时触发或者你在中断里调用了耗时过长的函数导致定时器节拍丢失。排查顺序把中断服务函数里的内容尽量精简不要写延时不要做复杂计算。检查两个中断标志是否在进中断后清除了。检查定时器初值重新装载是否正确。检查是否存在全局变量被中断和主循环同时访问导致数据不一致。必要时可以临时关闭中断访问临界变量。如果是用 51还要注意寄存器组切换和interrupt关键字的正确性。6.3 现象上电不稳定先量电源再查初始化顺序有的系统上电后屏幕亮但按键没反应过几秒又自动正常。这种“玄学”通常和上电时序有关。单片机和外设的供电建立时间、复位时间、初始化顺序如果不对就可能出现某次上电失败。排查顺序用万用表或示波器量单片机电源引脚确认上电瞬间有没有低于最低工作电压。看复位引脚有没有外部干扰。在外设初始化之前加一个几百毫秒延时等待电源稳定。检查 LCD 和传感器模块的复位时序看它们的启动时间是否比单片机慢。尝试手动复位看是否每次都能正常工作。很多时候“上电不稳定”的根本原因是外部设备需要先完成自检但单片机在它自检完成前就发送了初始化命令。这时加一个延时或者查询外部设备状态位就能解决。6.4 一套从现象到根因的排查顺序总结成一套通用排查链路先复现现象记录出问题时 LCD 或串口显示的现场信息。从输入开始查确认传感器、按键、编码器信号是否正常。再查主控内部确认定时器、中断、GPIO 配置是否和硬件一致。接着查输出PWM 波形、继电器动作、MOS 管驱动是否按预期执行。最后查环境和边界电源波动、干扰、长时间运行是否导致状态漂移。这套链路不是从零开始猜而是按信号流的方向层层缩小范围。比赛现场时间宝贵最怕的就是东改一下西改一下最后都不知道哪一步修好了问题。7. 从现在开始准备的备赛时间表和最后一周清单如果你看到这篇文章时还有几个月备赛时间恭喜你这是最容易建立系统能力的窗口期。如果只剩一周也不要慌但你更应该有策略地安排时间。7.1 备赛周期怎么分配三个月、一个月、三天如果还有三个月前一个月用来打基础重点是把 51 或 STM32 的定时器、中断、GPIO、ADC、UART、PWM 这些基本功练熟。不要急着做整套题先做三个经典小项目按键控制 LED、定时器测速、LCD 显示实时数据。中间一个月开始做往年真题。注意做真题不是只看题目要求而是设定一个完整的 4 小时或 8 小时工作段模拟比赛节奏。每次做完后复盘记录哪些环节耗时长、哪些 bug 反复出现、哪些模块资料查得最多。最后一个月进入套题训练。用一块接近比赛规格的板子把常用模块组合起来比如传感器 按键 显示 执行机构 电源。训练目标是拿到任何一道题能在一小时内完成模块拆分一小时完成驱动验证剩下时间全部留给逻辑和联调。如果只剩三天不要去做新模块。三天时间只做三件事第一天把所有会用到的模块驱动跑一遍确保没有硬件问题第二天搭一个状态机框架把题目最核心的控制逻辑做出来第三天做整体的边界测试和现场预案。7.2 最后一周不要碰新代码只做回归最后一周最重要的是“不折腾”。不要因为看到别人用某个新方法就临时改代码。新的功能、新的封装、新的传感器如果没有提前两天验证过比赛现场大概率会出问题。这一周应该每天做一次全流程回归测试上电、初始化、按键输入、采集、算法、输出、显示、异常处理。记录每次测试的通过情况。如果有任何一个环节不稳定不要靠“多试几次”蒙混过去必须找到原因。因为比赛现场的压力会让所有不稳定因素放大。7.3 比赛当天的时间管理先稳后快比赛当天拿到题目不要急着写代码。先花 20 分钟通读题目把功能点和评分点标出来。很多时候题目给的分数分布并不平均某些功能可能占很大比重但实现很简单某些功能分不高但需要大量调试。你要做的不是“做完全部”而是在有限时间里拿到尽量多的分。所以我通常建议“先稳后快”先把最简单的核心功能做成稳定的闭环哪怕界面丑一点、算法粗糙一点但整个链路是通的。然后在剩余时间里逐步增加其它功能。这样即使中途遇到问题你已经有了一版保底的系统而不是等到最后交一个跑不起来的半成品。回到经验层面电赛 G 题看起来考的是单片机方案实际上考的是工程取舍能力。你需要在“用熟不用新”“先跑通再优化”“稳定优先于功能”这些原则之间反复权衡。真正有价值的能力不是背下某个型号的寄存器表而是拿到一个陌生系统后能快速拆出输入、处理、输出能设计出可验证的流程能在出问题时按链路排查。所以与其纠结 2026 电赛 G 题到底考什么不如现在先选一块你以后愿意反复用的单片机把定时器、中断、显示、测速、电源这几个基本功练扎实。等到题目公布时你手里有足够多的“可用积木”剩下的只是在有限时间里把它们拼成一个稳定运行的系统。这就是我眼里最稳妥的单片机备赛方案。