最近在整理过去几年电赛的笔记发现一个很有意思的现象很多同学在准备“发挥部分”时会不自觉地陷入一个误区把全部精力都扑在实现某个炫酷的、高难度的功能上比如复杂的算法、高速的数据处理或者精密的机械控制。这当然没错但往往忽略了“发挥部分”第一问的真正意图——它通常不是一个孤立的、需要你从零开始“创造”的难题而是一个检验你能否将“基础部分”的成果进行有效“延伸”和“系统化”的命题。就拿“吉林省电赛发挥部分第一问”这个场景来说虽然具体的题目细节没有给出但结合历年电赛的命题规律和相关的技术热词STM32、FPGA、信号处理、控制等我们可以提炼出一个核心的备战逻辑“发挥部分”的第一问本质上是在考察你从“单点功能验证”到“系统任务闭环”的工程化能力。它不要求你立刻拿出一个革命性的新算法而是要求你把基础部分已经跑通的模块稳定、可靠、高效地整合起来去完成一个更综合、更贴近实际应用的任务。很多人折戟于此不是因为技术不够前沿而是工程思维没跟上。他们能调通一个传感器能驱动一个电机能让屏幕显示波形但当这些模块需要协同工作、应对实时数据流、处理意外干扰时系统就变得脆弱不堪。所以今天我们不聊某个具体的芯片或算法而是聊聊如何构建一种应对这类“发挥部分第一问”的系统性工程思维和实操框架。1. 重新理解“发挥部分第一问”从炫技场到工程验收台在电赛的紧张氛围里“发挥”二字很容易被误解为“秀操作”。但评委老师想看到的绝不仅仅是一个能动的“玩具”。他们更关注的是你是否具备将一个初步想法转化为一个可工作、可测量、甚至具有一定鲁棒性的“系统原型”的能力。第一问通常扮演着“承上启下”的角色承上它必然建立在“基础部分”已实现的核心功能之上。例如基础部分要求你用STM32采集传感器数据并显示那么发挥部分第一问可能会要求你基于这些数据实现一个简单的闭环控制或者对数据进行滤波、拟合等处理后再显示。下它为后续更复杂的发挥部分第二问、第三问搭建了核心框架。第一问构建的数据流、控制逻辑或通信架构往往是后续功能扩展的基础。如果第一问的框架搭得乱七八糟后面加功能就会举步维艰。因此面对第一问你的首要任务不是打开芯片手册研究一个新外设而是拿出基础部分的代码和硬件画一张系统框图。问自己几个问题输入是什么传感器信号键盘指令上位机命令它们的物理接口ADC、UART、I2C和数据结构是否明确核心处理是什么是STM32进行PID运算是FPGA做高速滤波或编解码还是两者协作如STM32发指令FPGA做加速处理所需的时序、精度、资源是否满足输出是什么驱动电机点亮LED刷新屏幕发送数据到上位机输出的驱动能力、响应速度、协议是否正确数据如何流动从输入到处理到输出数据在模块间如何传递是全局变量队列DMA还是自定义的通信协议这里往往是bug的高发区。把这个框图厘清你就完成了从“功能清单”到“系统视角”的关键一跃。你会发现第一问的难点常常不在于某个点而在于点与点之间的连接与调度。2. 构建稳健的系统框架以状态机为核心的控制逻辑当多个任务采集、处理、控制、显示、通信需要并发或交替执行时一个清晰的控制流至关重要。很多同学喜欢用while(1)里塞满if-else或者依赖延时函数HAL_Delay()这在简单任务中尚可但在复杂的发挥部分系统中这会导致代码结构混乱、响应迟钝、难以调试。强烈建议引入“状态机”思想来构建主控逻辑。状态机不是FPGA的专利在STM32的C语言编程中用switch-case或函数指针数组完全可以实现一个清晰的状态机。2.1 为什么是状态机结构清晰将系统行为划分为明确的几个状态如IDLE,SAMPLING,PROCESSING,CONTROLLING,UPDATING每个状态只做特定的事。响应及时通过定时器中断定期检查状态并切换避免主循环被某个耗时任务阻塞。例如即使数据处理很慢也不影响每10ms一次的传感器采集。易于调试你可以很容易地知道系统当前处于哪个状态当出现问题时可以快速定位是哪个状态的行为出现了异常。便于扩展增加新功能时往往只需要增加新的状态或修改状态转移条件而不需要重写整个主循环。2.2 一个简单的STM32状态机示例框架// 定义系统状态 typedef enum { SYS_IDLE 0, SYS_ADC_SAMPLING, SYS_DATA_PROCESSING, SYS_MOTOR_CONTROLLING, SYS_LCD_UPDATING, SYS_UART_TX } SystemState_t; volatile SystemState_t g_current_state SYS_IDLE; // 当前状态 volatile防止优化 // 在定时器中断如1ms中断中执行状态调度 void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim-Instance TIMx_Handle.Instance) { // 你的调度定时器 static uint32_t adc_sample_tick 0; static uint32_t lcd_update_tick 0; // 状态转移逻辑 switch (g_current_state) { case SYS_IDLE: // 检查是否有触发条件例如定时采集 if (adc_sample_tick 10) { // 每10ms触发一次采样 adc_sample_tick 0; g_current_state SYS_ADC_SAMPLING; } break; case SYS_ADC_SAMPLING: // 启动ADC转换可能用DMA完成后通过回调或标志位切换到处理状态 if (ADC_ConversionComplete) { ADC_ConversionComplete 0; g_current_state SYS_DATA_PROCESSING; } break; case SYS_DATA_PROCESSING: // 执行滤波、算法等 DoDataProcessing(); g_current_state SYS_MOTOR_CONTROLLING; // 处理完立即控制 break; case SYS_MOTOR_CONTROLLING: // 根据处理结果更新PWM输出 UpdateMotorPWM(); g_current_state SYS_LCD_UPDATING; break; case SYS_LCD_UPDATING: // 刷新显示避免在中断中耗时可设置标志位在主循环刷新 lcd_update_flag 1; g_current_state SYS_IDLE; // 回到空闲等待下次调度 break; default: g_current_state SYS_IDLE; break; } } } // 主循环主要处理非实时或耗时任务如LCD刷新、串口发送 while (1) { if (lcd_update_flag) { lcd_update_flag 0; RefreshLCDDisplay(); } // 其他后台任务... }这个框架将时间敏感的任务采样、控制决策放在定时器中断中按状态执行保证了时序性将耗时任务显示、复杂计算放在主循环或更低优先级任务中避免了阻塞。这正是应对电赛实时性要求的有效手段。3. 关键模块的深度整合以传感器数据处理链为例假设发挥部分第一问涉及对某种传感器信号如加速度计、陀螺仪、视觉信号进行增强处理。我们以常见的“采集-滤波-融合-控制”链为例拆解其中的工程要点。3.1 数据采集稳定与精准是第一要务STM32的ADC如果使用片内ADC注意参考电压的稳定性软件上可启用过采样、均值滤波来提升有效位数。对于多路采样DMA是必需品它能极大减轻CPU负担并保证数据连贯性。注意ADC的采样率并非越高越好。根据奈奎斯特采样定理满足信号最高频率两倍即可。过高的采样率会给后续处理带来不必要的压力。与FPGA的分工如果信号频率很高几百kHz考虑用FPGA进行高速采集和预处理如数字下变频、抽取滤波再将降速后的数据通过SPI或FSMC等并行接口送给STM32。这时清晰的硬件接口协议和双缓冲机制是关键防止数据丢失。3.2 数据处理在资源与效果间权衡滤波算法选择简单滑动平均速度快资源占用小对高频噪声有效但会引入相位滞后。适合对实时性要求不高的数据显示。一阶低通滤波软件实现y[n] α * x[n] (1-α) * y[n-1]。计算量极小在STM32上几乎无开销是抑制随机噪声的常用手段需要根据信号特性调整α值。卡尔曼滤波如果系统模型比较明确如基于IMU的姿态估计卡尔曼滤波能提供最优估计。但在资源有限的MCU上实现需谨慎简化模型如线性、单维是关键。不要为了“高大上”而用要用就要理解其状态方程和噪声参数。算法定点化STM32没有硬件FPUF4/F7/H7系列除外时浮点运算很慢。将滤波、PID等算法中的关键参数和变量进行定点化Q格式能大幅提升速度。这是电赛优化中一个重要的得分点。3.3 控制输出从“能动”到“稳定”PWM生成利用STM32高级定时器的互补输出、死区插入等功能驱动电机或舵机。重点测试占空比从0%到100%变化时系统的响应是否线性、有无死区。PID实现先P再I最后D这是调参的黄金顺序。先给一个较小的Kp让系统有响应然后加入Ki消除静差最后谨慎加入Kd抑制超调D项对噪声敏感。抗积分饱和在输出限幅后要对积分项进行限制或冻结防止系统“失控”。输出限幅物理执行机构如电机都有安全范围PID输出必须进行硬限幅。离散化与定时执行PID计算必须在一个固定的时间间隔如定时器中断内进行dt的准确性直接影响效果。4. 调试与排错让系统问题无处遁形一个健壮的系统必须有强大的调试能力。在电赛现场快速定位问题比实现功能更重要。4.1 分层调试法不要一上来就让整个系统跑。遵循以下顺序模块独立测试确保每个硬件模块传感器、执行器、屏幕单独与MCU通信正常。使用简单的测试程序如读取传感器原始值并打印手动给PWM值看电机转动。数据流测试将模块串联但不加入控制算法。例如让传感器数据直接映射为执行器输出线性比例观察整个通路是否畅通。开环测试加入处理算法和控制算法但断开反馈。给定一个目标值观察系统输出是否符合预期。验证你的算法逻辑是否正确。闭环测试最后才闭合反馈环。从小目标、小参数开始逐步调整。4.2 利用好“数字仪表盘”串口打印是最直接的调试工具但打印大量数据会影响实时性。优化策略如下定时发送在低优先级任务或主循环中每100ms打包发送一批关键数据如状态、设定值、反馈值、输出值、错误码。二进制协议使用struct定义数据结构通过memcpy和union进行二进制传输上位机用Python等工具解析效率远高于字符串printf。关键事件触发仅当发生状态切换、错误或参数超过阈值时才打印信息。利用调试工具STM32的ITMInstrumentation Trace Macrocell功能可以通过SWD接口几乎零开销地输出调试信息到Keil或STM32CubeIDE的Debug Viewer是高级调试利器。4.3 常见问题排查清单当系统不工作或行为异常时按此顺序排查排查层级可能问题检查方法电源与复位电压不足、纹波大、复位电路异常测量各点电压观察复位引脚波形尝试手动复位。时钟与初始化晶振未起振、时钟配置错误、外设初始化顺序不对检查SystemClock_Config()用示波器看晶振引脚确认外设时钟使能。外设配置GPIO模式上拉/推挽、复用功能、中断优先级设置错误对照芯片手册和CubeMX配置检查代码。数据接口SPI/I2C/UART的速率、相位、地址、停止位错误用逻辑分析仪抓取总线波形与标准时序对比。实时性中断嵌套导致任务延迟、HAL_Delay阻塞关键循环简化中断服务程序将耗时任务移至主循环使用状态机。算法逻辑边界条件未处理、变量溢出、数据类型错误、传感器原始值未校准加入更多打印点检查中间变量值进行传感器零偏和标度因数校准。资源限制栈溢出、堆内存不足、中断过于频繁检查.map文件优化数组大小调整中断频率。5. 从完成到卓越那些容易被忽略的加分项在基本功能实现后以下细节能显著提升作品质量和评委印象系统自检与状态指示上电后通过LED或屏幕序列指示硬件初始化状态如“传感器OK”、“电机OK”、“通信OK”。出现故障时能有明确的错误代码显示。参数可配置将PID参数、滤波系数、阈值等关键参数设计为可通过串口命令或按键实时修改并掉电保存存入Flash。这展示了系统的灵活性和可调试性。抗干扰设计硬件电源入口处加磁珠、TVS信号线加滤波电容模拟地与数字地单点连接。软件对开关量输入进行消抖对模拟量进行软件滤波对通信数据加入校验和如CRC关键操作加入超时判断。代码结构与注释即使时间紧张也要保持代码模块化。将ADC采集、电机驱动、滤波算法、PID控制等写成独立的.c/.h文件。关键函数和全局变量要有简明注释。这不仅能方便调试也体现了良好的工程素养。总结一下应对“发挥部分第一问”乃至整个电赛的核心不是追求技术的孤峰而是构建系统的山脉。它考验的是你能否用工程化的思维将一个个独立的技术点编织成一张可靠、高效、可扩展的网络。从清晰定义系统框图开始用状态机驾驭控制流精心打磨每个处理环节并为自己准备好强大的调试工具链。当你不再只关注“能不能动”而是开始思考“怎么动得更稳、更快、更聪明”时你就已经站在了更高的备赛维度上。这份系统性的能力远比解决一道具体题目更为重要它将是你在未来任何工程项目中最为倚重的基石。
