做嵌入式系统这行尤其是写ASW应用层软件的人早晚会遇到一个很“拧巴”的需求CPU主频几百兆跑起来飞快但外部世界永远是“一瞬间”就把信号丢过来了。转速传感器的窄脉冲、红外遥控的载波、编码器的跳变沿、某个按键按下时乱七八糟的抖动这些“瞬间发生的事”如果没被软件及时抓住轻则功能失效重则整个系统跑飞。我的做法说起来很土但确实稳定可靠用 Delay 去捕捉边沿。不是靠高频中断也不是靠硬件定时器输入捕获而是把延时当成一把“尺子”按固定节奏去量输入引脚上的电平变化。很多人看到 Delay 第一反应是“拖时间”“卡流程”实际上在边沿检测场景里Delay 是构建时间窗口的核心工具。这篇文章就围绕“用 Delay 捕捉边沿”这件事把思路、参数计算、代码实现、坑点排查完整讲一遍适合正在写 ASW 应用层、又要处理外部脉冲信号的嵌入式开发者参考。1. 为什么说“瞬间发生的事”要用 Delay 去看1.1 边沿不是“瞬间”而是一段必须考虑宽度的物理过程先从最基础的问题说起数字电路里的信号跳变真的是一瞬间完成的吗不是。示波器上看到的上升沿可能从低到高需要几纳秒到几十纳秒信号在传输线上还会产生过冲、回沟、振铃。但对于 ASW 软件而言我们根本不需要关心纳米级别的电气细节真正要关心的是“电平状态发生翻转”这件事在时间轴上的最小宽度。举个例子一个霍尔转速传感器输出的脉冲通常高电平宽度在 20us 到 100us 之间而一个红外遥控接收头的输出脉冲窄的时候可能只有 560us宽的可能到 2.5ms。这些宽度相对 CPU 主频来说当然不算短但相对 ASW 任务的调度周期来说可能就非常短了。假设你的应用层任务每 5ms 才巡检一次输入引脚一个 100us 的脉冲极大概率会被漏掉因为你在两次巡检之间根本没有机会看到它。所以“瞬间发生的事”这个说法本质上是在说事件持续时间小于你的软件任务调度周期。要抓住这类事件就不能指望周期性的“偶尔看一眼”而是要在时间轴上安排足够密集的采样让事件无法从采样缝隙中溜走。1.2 中断和轮询都有局限Delay 反而补齐了盲区听到这里很多人会直接想到外部中断。确实MCU 的外部中断可以做到边沿触发理论上不会漏事件但实际工程里它有几个绕不开的问题第一不是所有引脚都支持外部中断引脚资源紧张时只能退而求其次第二中断服务程序不能占用太长时间一旦在中断里执行复杂逻辑主流程就会被反复打断第三有些场景需要同时监控多个边沿中断优先级和嵌套处理会变得非常头疼。我遇到过不止一次因为两个中断互相抢占最后脉冲计数莫名翻倍的情况。轮询方式则受限于任务周期。周期太短CPU 占用率飙升周期太长短脉冲必漏。这时候 Delay 的价值就体现出来了在轮询的基础上用一次较短的阻塞延时比如 100us把采样动作“贴”到目标时间窗口上在脉冲有效期间连续读取引脚电平并且对前后两次采样结果做比较就能准确判断出“这个边沿到底有没有来过”。这里的关键认知是Delay 不是用来“浪费 CPU 时间”的而是用来建立时间窗口的。你延时了 100us换来的是一个稳定的、可预期的 100us 采样窗口窗口内你能保证读到 N 次电平状态。这种确定性是任务调度天然不具备的。2. 捕捉边沿的设计核心先想清楚时间窗口2.1 用“连续采样 前后比较”代替一次性的偶然读取捕捉边沿的最基础算法其实只有一句话记录上一个时刻的电平状态和当前时刻的电平状态做比较如果两者不同说明边沿发生了。伪代码长这样old_level 当前电平; delay_us(SAMPLE_INTERVAL); new_level 当前电平; if (old_level 0 new_level 1) { // 上升沿 } else if (old_level 1 new_level 0) { // 下降沿 }看起来很简单但工程实现上的第一个坑就是一次采样永远不够可靠。按钮按下时的机械抖动会让电平在几毫秒内反复翻转如果不做连续多次采样你会把一次按键识别成十几次动作。而如果外部信号本身带了毛刺一次采样刚好落在毛刺上就会产生完全不存在的边沿。所以我在实际代码里从不做单次采样比较而是做“连续采样 多数一致”的滤波连续读取 N 次电平如果 N 次中有 M 次以上是高电平就认为当前电平状态是高否则是低。然后再把滤波后的当前电平与上一次滤波后的状态做比较。这样既抵抗了毛刺又不会漏掉真实的短脉冲。2.2 延时时间怎么定采样间隔、脉冲宽度与超采样系数这是整篇文章最核心的部分也是很多人会拍脑袋决定的一个参数。Delay 的时长到底该选多少我的习惯是先建立公式再取值。假设外部信号最短的有效脉冲宽度为 T_pulse_min我希望在脉冲最窄的情况下至少能采到 N 个有效样本那么采样间隔 SAMPLE_INTERVAL 必须满足SAMPLE_INTERVAL T_pulse_min / NN 叫超采样系数我一般取 3 到 5。取 3 的意思是即使在最恶劣情况下一个脉冲内也至少能读到 3 次电平这样多数判决才有意义。取 5 则更稳但 CPU 占用更高。举个例子一个红外接收头的窄脉冲最短约 560us用 N3则采样间隔最大为 560/3 ≈ 186us。考虑到代码读取引脚、比较、状态机跳转还要消耗时间我会选 100us 作为采样间隔这样脉冲内能采到大约 5 到 6 个样本。从实际效果来看这个参数既能可靠捕捉红外脉冲也不会让 MCU 在采样期间饿死其他任务。如果信号是最窄 20us 的转速脉冲想用软件方式捕捉采样间隔就要压到 20/3 ≈ 6.6us 以下这要求延时函数本身必须稳定到微秒级而且不能开太多中断干扰。实测中我用 systick 实现延时选 5us 采样间隔可以达到转速脉冲的捕捉要求。2.3 阻塞延时与非阻塞延时的取舍用 Delay 捕捉边沿最直接的实现就是阻塞式延时。代码逻辑清晰时序精度高但缺点也明显延时期间 CPU 不能干别的如果一次采样窗口做了 200us 的延时那这 200us 内其他任务全部被挂起。更麻烦的是阻塞延时和中断、看门狗之间容易打架。systick 被关掉、延时函数被中断打断、优化器把延时变量优化没——这些都是我见过或者踩过的真实问题。所以如果系统里同时有好几件事要处理或者你不能容忍主循环长时间卡住就要考虑非阻塞实现用系统 Tick 计数替代死等把“延时采样”改成“到点采样”。具体做法是记录上一次采样的 Tick每次主循环判断当前 Tick 是否大于 last_tick 间隔如果到了就采样一次并更新 last_tick。这样采样逻辑和时间驱动逻辑解耦CPU 不会被占死DEMO 代码稍后我会给出一个状态机版本。3. 实操记录一个转速脉冲边沿捕捉的完整过程3.1 需求与硬件环境我这个项目里遇到的实际需求是读取一个霍尔传感器输出的方波脉冲脉冲频率在 1Hz 到 5kHz 之间高电平最短宽度约 50us。ASW 需要实时统计脉冲数量并且在检测到上升沿时更新一个软件标志供上层控制逻辑使用。硬件环境很简单MCU 一个普通 GPIO 输入口外部传感器信号经过一个电阻分压和电平转换电路后直接进引脚。没有使用定时器输入捕获通道没有使用外部中断纯粹靠软件采样。选择这个方案的原因有两个第一引脚数量紧张专用捕获通道被其他功能占用了第二系统里已经有多个软件定时器在跑不希望引入更多中断源。这让“用 Delay 捕捉边沿”成了最合理的路径。3.2 基础版代码实现边沿检测的延迟采样先给一段最朴素的实现简单直接方便理解核心逻辑。#define SAMPLE_INTERVAL_US 10u static uint8_t last_level 0; void edge_detect_init(void) { last_level gpio_read_level(PIN_SENSOR); } uint8_t edge_detect_scan(void) { uint8_t cur_level; uint8_t edge EDGE_NONE; delay_us(SAMPLE_INTERVAL_US); // 等待一个采样间隔 cur_level gpio_read_level(PIN_SENSOR); if (last_level 0 cur_level 1) { edge EDGE_RISING; } else if (last_level 1 cur_level 0) { edge EDGE_FALLING; } last_level cur_level; return edge; }这段代码的核心就是在两次采样之间延时 SAMPLE_INTERVAL_US把采样频率固定下来。每次调用返回一次边沿检测结果上层循环每隔一段时间调用一次。注意这里 delay_us 必须用可重入的、基于 systick 或者定时器的延时函数不能是那种纯靠循环空转且被编译器优化掉的版本。实测中我发现如果直接把这段代码放在主循环里 while(1) 跑采样频率并不完全等于 1/SAMPLE_INTERVAL_US因为每次循环还要执行比较、赋值、跳转等指令。所以如果采样时序要求非常严格建议用 3.4 节的状态机处理或者在采样前后翻转一个 GPIO 引脚来观测实际采样时序。3.3 加入防抖和多数表决的状态机版本真实工程里没法直接用上面的代码因为霍尔传感器输出虽然整体是方波但启动瞬间或者机械振动时也会有毛刺光靠单次前后比较仍然可能误判。所以我把逻辑升级成一个简单的状态机每次判定前先连续采多个样本做一次“多数一致”滤波。#define SAMPLE_INTERVAL_US 10u #define SAMPLE_ROUNDS 5u typedef enum { STATE_IDLE, STATE_STABLE_LOW, STATE_STABLE_HIGH } edge_state_t; static edge_state_t state STATE_IDLE; uint8_t edge_detect_scan_filtered(void) { uint8_t i; uint8_t high_cnt 0; uint8_t cur_level; uint8_t edge EDGE_NONE; // 连续采样 SAMPLE_ROUNDS 次统计高电平次数 for (i 0; i SAMPLE_ROUNDS; i) { cur_level gpio_read_level(PIN_SENSOR); if (cur_level) { high_cnt; } delay_us(SAMPLE_INTERVAL_US); } // 多数表决结果3/5 认为当前是高电平 cur_level (high_cnt 3) ? 1 : 0; switch (state) { case STATE_IDLE: state cur_level ? STATE_STABLE_HIGH : STATE_STABLE_LOW; break; case STATE_STABLE_LOW: if (cur_level) { edge EDGE_RISING; state STATE_STABLE_HIGH; } break; case STATE_STABLE_HIGH: if (!cur_level) { edge EDGE_FALLING; state STATE_STABLE_LOW; } break; default: state STATE_IDLE; break; } return edge; }这段状态机会先在一个小的采样窗口内连续读 5 次电平用多数表决决定当前的稳定电平再和上一个稳定状态比较。这样做有两个好处一是毛刺很难连续 5 次都被采样成同一方向二是短脉冲只要宽度大于 5 个采样间隔就能被正确识别为一次边沿不会被误当成毛刺滤掉。对于我这个项目SAMPLE_INTERVAL_US 为 10usSAMPLE_ROUNDS 为 5一次完整的状态判定大约需要 50us 的采样窗口。最窄 50us 的高电平脉冲刚好能采到 5 次左右的样本符合“多数为主”的滤波要求。实测下来脉冲计数准确率达到 99.99% 以上没有出现过一次序列跳变或漏计。3.4 实测过程与参数调节心得把代码烧进板子后我第一件事不是看计数结果而是拿逻辑分析仪抓引脚电平同时把“检测到上升沿后翻转一个 GPIO”的行为接到另一个通道上对比真实脉冲和软件识别结果。第一次跑的时候我把 SAMPLE_INTERVAL_US 设成了 50us结果发现高速段 5kHz 输入时脉冲计数严重丢失。算一下就明白了5kHz 的方波周期是 200us高电平宽度只有 100us用 50us 的采样间隔去采一个脉冲内最多采到 2 次加上多数表决需要 3 次以上必然丢。把采样间隔从 50us 降到 10us 后高速段计数立刻恢复正常。这里要强调的是延时参数不能孤立地看。SAMPLE_ROUNDS 和 SAMPLE_INTERVAL_US 这两个参数共同决定了窗口时间窗口时间必须小于最小脉冲宽度这个不等式是决定参数的直接依据。窗口时间大于脉冲宽度的直接后果就一个字丢。4. 别搞混工具链里的 Delay 是另一个世界写到这里我必须提醒一下在做 FPGA、功耗分析、PCB 时序约束的工程师手里“Delay”这个词的含义和 ASW 软件里的“延时函数”完全是两码事。网上搜“stm32 延时函数 delay 卡死”“ptpx 功耗分析 zero delay”“vivado 导出 pin delay”“waitfor delay”这些词出来一堆不同的技术点如果不小心混在一起很容易把自己带偏。我把它们做一个简单区分。4.1 input delay静态时序分析里的“外部输入延时约束”在 FPGA 开发中input delay 指的是数据从外部器件到 FPGA 输入端口的延时约束。它描述的是外部时钟与输入数据之间的相位关系告诉工具“这个输入信号相对时钟沿提前或滞后多少”。这本质上是综合工具在做时序收敛时使用的时间预算和软件运行一个 delay_us() 没有任何关系。如果你用嵌入式软件的思维去理解 input delay会觉得非常抽象因为软件延时是“我主动等一段时间”而 input delay 是“信号本身在物理路径上花了这么长时间”不是软件能控制的。但在边沿这个概念上两者有相通之处都要考虑信号的有效窗口和建立保持时间。只是软件可以靠延时去采样硬件只能靠约束去保证采样满足时序。4.2 zero delay、pin delay 与数据库时代的 Delay 建模ptpx 功耗分析里的 zero delay指的是功耗分析工具在反标功耗模型时默认所有单元没有走线延时或门延时只计算翻转活动导致的动态功耗。这种模式下功耗结果更关注逻辑翻转率而不是路径上的延迟。它和软件延时完全无关纯粹是仿真模型的一种简化假设。vivado 导出 pin delay 则是把 FPGA 内部 IO 引脚到逻辑单元之间的布线延时、管脚物理延时数据导出来供板级仿真或封装设计使用。这些 Delay 都是物理世界的“客观存在”单位是纳秒皮秒而且是芯片制造完就定死的。你在 ASW 里调用 delay_us(10)是主动创建一个 10us 的时间窗口这两种 Delay 的区别就像“测量一条路有多长”和“开车在这条路上磨蹭 10 分钟”的区别。搞懂这些区别有什么实际意义我自己的体会是当团队里有人拿“ptpx 里的 zero delay”来说“这个模块延时为零所以功耗很高”的时候你能立刻反应过来他做的是功耗仿真模型选择不是真实硬件延时当 FPGA 工程师说“这个输入 delay 没满足”的时候你也能判断出他说的不是你软件里少写了一个 delay_us()而是工程约束需要调整。术语混淆导致跨岗位沟通翻车的事情我在项目例会上见过太多次了。5. 常见问题与排查技巧实录5.1 现象一延时函数不生效或者采样值一直不变这个坑我相信写 STM32 的人都遇到过。最常见的原因是 systick 被某个外设初始化代码关闭了比如你在调用 delay 之前初始化了一个 ADC 或者 DMA初始化过程把 systick 中断优先级改了或者把计数器停了delay_us 函数里的判断语句永远等不到目标值于是卡死。排查方法很简单在调用 delay_us(100) 之前和之后各翻转一次 GPIO用示波器看看这段阻塞之间的实际时间。如果波形显示根本没有 100us 的延时说明延时函数本身有问题如果波形变成了几毫秒甚至更长说明系统 Tick 频率配置不对。另外把延时变量定义成 volatile防止优化器把它优化成空循环。5.2 现象二短脉冲捕捉不到计数丢了一半第一步先算账不要瞎猜。脉冲最短宽度是多少采样窗口是多少如果最短脉冲 50us而你的状态机一轮要采 5 次、每次间隔 20us100us 的窗口已经大于 50us 的脉冲那就必然丢。解决方向是缩小 SAMPLE_INTERVAL_US或者减少 SAMPLE_ROUNDS让整个窗口小于最小脉冲宽度。第二步用逻辑分析仪抓引脚实际波形确认脉冲是真的存在。曾经有同事排查了一天“捕捉不到”最后发现是信号在 PCB 上被一个下拉电阻拉低了根本不是软件问题。先确认硬件波形再怀疑代码这是排查顺序的纪律。5.3 现象三边沿误判检测到重复的上升沿或下降沿通常是毛刺或者抖动被当成有效边沿了。霍尔传感器在电机启动瞬间输出会出现随机毛刺红外接收头的输出在没有任何信号时也可能周期性拉高拉低。这种问题靠提高 SAMPLE_ROUNDS 和延长时间窗口往往能解决因为毛刺宽度远小于真实脉冲宽度。但如果毛刺很宽比如机械抖动达到几十毫秒那就不能靠单纯增大采样窗口了否则真实响应会慢得不可接受。我通常的做法是边沿检测用微秒级窗口做“判定”防抖用毫秒级延时做“确认”。检测到边沿后延迟一个防抖时间再读一次电平如果读到的电平与边沿方向一致说明是真实事件否则当作抖动丢弃。这个“先判定再确认”的思路比把一个窗口无限拉大要优雅得多。5.4 问题速查表现象最常见原因检查方向解决思路delay 卡死systick 被关/延时变量被优化翻转 GPIO 实测延时检查时钟配置、变量加 volatile脉冲漏计采样窗口 最小脉冲宽度计算窗口时间并和脉冲宽度对比缩小采样间隔或减少采样轮数连续重复触发输入毛刺/机械抖动逻辑分析仪看原始波形加多数表决再防抖确认采样值一直不变GPIO 模式配置错误检查引脚复用和上下拉改成输入模式检查硬件电平不同任务互相干扰阻塞延时占用了太长 CPU 时间统计任务周期和 CPU 占用改为非阻塞 Tick 驱动采样检测延迟过高防抖窗口偏大对比实测边沿与软件确认点拆分“判定”和“确认”两个阶段最后分享一点个人体会用 Delay 捕捉边沿这件事最开始我确实只把它当成“简单轮询 延时”的土办法后来踩的坑多了反而越来越欣赏这种做法的可控性。它不需要额外硬件资源不依赖复杂的中断嵌套只要时间参数算得对稳定性可以做到接近硬件捕获通道的水平。尤其是当你面对一个引脚资源紧张、中断优先级已经乱成一锅粥的存量项目时这种“软件看门狗”式的采样方案往往是最省事、最不会引发新问题的路径。我自己后来习惯在调试阶段额外留一个 GPIO每次采样动作发生时翻转一次用示波器观察真实的采样节奏和延时是否漂移。这个习惯帮我抓出过好几次“系统 Tick 频率配置错误导致延时时间翻倍”的隐蔽问题。说穿了Delay 只是工具真正值钱的还是对时间参数的那份计算和验证。