做嵌入式这行定时器就是你手里最常用的那几把螺丝刀之一。设备上电要延时、通信要超时判断、传感器要周期采样、电机要按固定时序换向桩桩件件背后都是定时器在默默数着节拍。前面几篇咱们把 Zephyr 的时钟节拍、延时 API、线程调度相关的东西过了不少今天这一篇专门把 k_timer 这个正经的定时器模块拆开聊透。它适合谁看只要你在 Zephyr 上写过需要到点干某件事的逻辑就都绕不开它。新手能用它替代乱七八糟的延时循环老手也能从回调上下文、低功耗 tickless 这些细节里找到些平时容易踩的坑。1. 定时器在Zephyr里的定位别再用k_sleep倒计时了1.1 一个五分钟停机需求背后的真相先说个特别常见的场景。设备收到启动指令后必须在 5 秒内收到安全确认信号否则就执行急停。这种逻辑用延时好不好写如果直接在线程里k_sleep(K_SECONDS(5))这 5 秒内线程什么都干不了那谁去接收那个安全确认信号你只能另开一个线程专门负责睡5秒然后急停再靠几个全局变量在两个线程之间做同步。代码能跑但看着就别扭改起来更是牵一发动全身。k_timer 就是为这类需求准备的。你把一个定时器设好 5 秒时长注册好超时回调然后你的业务线程该收信号收信号、该处理数据处理数据到点没收到确认内核在时钟中断里自动帮你调用那个超时回调急停逻辑自然而然执行。一个定时器就把等待和执行解耦了业务代码清爽一大截。1.2 k_sleep、忙等、k_timer 三者到底有什么不同很多人刚上手时搞不清楚这三个东西的区别我简单捋一下。k_busy_wait()是忙等CPU 空转耗完这段时间中间响应不了任何中断以外的事情一般只适合几微秒到几十微秒的超短延时。k_sleep()或者k_usleep()是让出 CPU 的阻塞延时当前线程被挂起系统可以去跑别的线程但当前线程在这段时间内就是睡着状态你没法一边睡一边干正事。k_timer的核心区别在于定时器本身不占用任何线程。它只是在内核里挂了一个超时节点系统时钟节拍每次走到该触发的位置就调用你注册的回调函数。你的业务线程在定时器计时期间始终是活的、能跑的、能响应其他事件。打个比方k_sleep 就像你抱着闹钟睡觉闹钟不响你醒不来k_timer 是你把闹钟设好后继续看电视到点闹钟自己响你该干嘛干嘛。1.3 k_timer 在内核里是怎么工作的Zephyr 内核维护了一个按到期时间排序的超时队列。每次系统 tick 中断到来时内核会检查队列头部的超时节点把到期的节点取出并执行其回调。k_timer 本质就是在这个超时队列上做了一层封装额外记录了用户回调、周期值、运行状态等元数据。理解这一点对排查问题很有帮助。比如你发现定时器回调延迟了几个 tick 才执行那大概率是系统当前关着中断或者在更高优先级的中断处理程序里耽搁了如果你的系统有很多超短周期定时器每个 tick 都要检查一堆节点系统负载自然会上去。这些现象用定时器是独立硬件外设的思路去想是想不通的它背后就是一颗软件定时器依赖系统的时钟节拍来推动。2. k_timer包里六个必懂API定义、启动、停止、查询2.1 定义定时器K_TIMER_DEFINE的三参数Zephyr 里定义定时器用K_TIMER_DEFINE一行宏搞定。宏的三个参数是定时器名字、到期回调函数、停止回调函数。两个回调都可以传 NULL。void my_expiry(struct k_timer *timer); void my_stop(struct k_timer *timer); K_TIMER_DEFINE(my_timer, my_expiry, my_stop);回调函数参数都是指向该定时器对象的指针。为啥要把 timer 指针传回来因为你可以用同一个回调函数处理多个定时器收到指针后判断是哪一个触发的。比如两个传感器共用一套超时处理逻辑回调里比较指针就能区分。2.2 启动定时器duration 和 period 的魔鬼细节启动函数是k_timer_start()最核心的就是搞明白两个时间参数。k_timer_start(my_timer, K_MSEC(500), K_NO_WAIT); /* 单次定时500ms后触发一次 */ k_timer_start(my_timer, K_MSEC(500), K_MSEC(500)); /* 周期定时每500ms触发一次 */第一个参数duration是从现在开始多久之后第一次触发第二个参数period是第一次触发之后每隔多久再触发。period设为K_NO_WAIT或者 0表示这是单次定时器触发一次后自己消停。period设为非零值就是周期定时器。需要注意duration不要设成 0 或者K_NO_WAIT那表示立即到期定时器启动后下个节拍就来一次回调很容易造成刚复位又触发的误判。另外定时器如果已经在运行你再次调用k_timer_start()会把它先停掉再按新的参数重新开始计时之前的计时进度作废。这个行为可以用来做看门狗刷新式逻辑每次收到心跳包重新 start 一下超时时间从头算。2.3 停止定时器什么时候会触发停止回调停止用k_timer_stop()k_timer_stop(my_timer);停掉一个正在运行的定时器内核会调用注册的stop回调。但这里有个非常容易踩的误区定时器自然到期单次定时器触发完毕后不会调用停止回调。停止回调只在显式调用k_timer_stop()时触发或者在定时器还没到期的情况下被重新 start相当于先 stop 再 start时触发。所以不要把stop回调当成定时任务结束通知它是定时器被取消通知。这个区别在后面的急停保护例子里会体现得淋漓尽致。2.4 查询状态和剩余时间别靠猜有时候你不想用回调想主动查询定时器的状态。Zephyr 提供了几个查询接口。enum k_timer_state state k_timer_state_get(my_timer); /* K_TIMER_STOPPED 或 K_TIMER_RUNNING */ uint32_t rem_ticks k_timer_remaining_ticks(my_timer); /* 返回剩余的 tick 数 */k_timer_state_get()返回运行状态k_timer_remaining_ticks()返回剩余时间。这两个接口适合在主循环里做超时判断比如实现一个非阻塞的这周内必须完成某个操作否则提示。还有一个容易被用错的接口是k_timer_status_get()uint32_t expired k_timer_status_get(my_timer);它返回的是自上次调用该函数以来定时器已经到期的次数并且会把内部计数清零。对周期定时器来说假设你 1 秒查一次而定时器周期是 200ms那读到的expired可能是 5。对单次定时器读到的只能是 0 或 1。如果你在主循环里高频调用这个函数它每次基本都返回 0因为还没来得及到期。这个函数适合做低频状态轮询不适合做事件检测。2.5 生命周期状态机一张表看懂状态进入方式回调触发情况退出方式未启动定义后初始状态无调用 start运行中调用 start到期回调按 period 触发调用 stop或单次定时器自然到期已停止调用 stopstop 回调触发一次再次调用 start单次定时器自然到期后内部状态实际是未启动但停止回调不会被调用。如果你需要知道定时器已经触发完了得靠到期回调自己置标志或者用k_timer_status_get()查到期次数。2.6 回调的两种触发场景汇总到期回调duration到期时刻触发周期定时器每个周期末触发。停止回调显式k_timer_stop()时触发运行中的定时器被重新k_timer_start()时先触发一次旧的停止回调再按新参数运行。这两个回调的语义完全不同写代码前一定想清楚要用哪个。3. 三个可直接抄的定时器Demo从LED闪烁到工业保护3.1 周期任务LED心跳灯最简单的周期任务就是 LED 闪烁。很多开发板例程里都用k_sleep来实现但如果你希望闪烁的同时主循环还能处理按键、通信就得上定时器。#include zephyr/kernel.h #include zephyr/drivers/gpio.h #define LED0_NODE DT_ALIAS(led0) static const struct gpio_dt_spec led GPIO_DT_SPEC_GET(LED0_NODE, gpios); void led_toggle_expiry(struct k_timer *timer) { gpio_pin_toggle_dt(led); } K_TIMER_DEFINE(led_timer, led_toggle_expiry, NULL); void main(void) { if (!gpio_is_ready_dt(led)) { return; } gpio_pin_configure_dt(led, GPIO_OUTPUT); gpio_pin_set_dt(led, 0); k_timer_start(led_timer, K_MSEC(500), K_MSEC(500)); while (1) { /* 主循环里干其他正事LED照样闪 */ k_sleep(K_MSEC(10)); } }这个例子里 LED 翻转直接放在到期回调中。GPIO 操作在中断上下文执行是允许的只要操作足够快、不阻塞。500ms 周期回调里就一次寄存器操作没有任何问题。如果你要在回调里做更重的活比如更新一个大型显示缓冲区那就得考虑把活丢给线程去做。3.2 超时保护5秒未确认就急停下面这个场景我觉得最能体现 stop 回调的价值。设备启动后5 秒内如果收不到安全确认信号就执行急停如果提前收到了则正常继续运行。K_TIMER_DEFINE(safety_timer, safety_timeout, safety_cancelled); static void safety_timeout(struct k_timer *timer) { /* 5秒内没有确认执行急停 */ shutdown_machine(); } static void safety_cancelled(struct k_timer *timer) { /* 定时器被取消说明确认信号及时到达标记安全 */ set_safety_confirmed(true); } void start_safety_window(void) { set_safety_confirmed(false); k_timer_start(safety_timer, K_SECONDS(5), K_NO_WAIT); } void on_safety_confirm_received(void) { /* 收到确认信号取消等待触发 stop 回调 */ k_timer_stop(safety_timer); /* 注意stop 回调里会置 safety_confirmed */ }这个设计很优雅。超时和取消是两条完全不同的路径没确认 → 系统走急停分支确认了 → 系统走安全分支。一条k_timer_stop()就把取消定时等待和置安全标志两个操作绑定在一起了不会出现线程里忘了置标志导致误急停的情况。这里有个细节我要特别提醒k_timer_stop()触发停止回调是同步的还是异步的在 Zephyr 中如果你在线程上下文调用k_timer_stop()停止回调会在调用线程的上下文里同步执行。所以on_safety_confirm_received返回时set_safety_confirmed(true)已经执行完了。3.3 并行周期任务一路采样一路上报定时器的好处之一是多个任务互不干扰。假设你要一个 100ms 周期采集传感器同时 1 秒周期上报数据。用两个定时器很简单。void sensor_sample_tick(struct k_timer *timer) { sensor_trigger_sample(); } void report_tick(struct k_timer *timer) { report_enqueue_packet(); } K_TIMER_DEFINE(sample_timer, sensor_sample_tick, NULL); K_TIMER_DEFINE(report_timer, report_tick, NULL); void start_schedule(void) { k_timer_start(sample_timer, K_MSEC(100), K_MSEC(100)); k_timer_start(report_timer, K_SECONDS(1), K_SECONDS(1)); }两个定时器的到期时刻不会互相阻塞内核的超时队列会分别处理。你不用担心一个定时器触发了会影响另一个的计时精度它们都是基于同一个系统节拍在推进。4. 定时器回调的硬规矩中断上下文与低功耗精度的平衡4.1 回调到底跑在什么上下文这是 Zephyr 定时器最重要、也最容易被忽视的约束。k_timer 的到期回调和停止回调默认是在系统时钟中断上下文中被调用的不是在某个线程的栈上跑。什么意思呢你在回调里不能调用任何可能阻塞的 API比如k_sleep()、k_sem_take()、获取互斥量、分配大块内存这些行为轻则造成系统死锁重则直接触发内核断言。一个常见的错误写法是在回调里调用k_sleep做延时。这是因为线程上下文和中断上下文的栈环境完全不同睡眠逻辑需要一个线程来挂起中断上下文里没有这种条件。我自己早期写代码就犯过这个错回调里加了个打印函数打印函数内部用了锁结果整个系统跑一会儿就卡死。4.2 重活不要直接在回调里干转发给工作队列如果回调逻辑比较重比如要处理数据、要做浮点运算、要发消息给其他线程正确的姿势是把任务提交到系统工作队列。static struct k_work my_work; void timer_expiry(struct k_timer *timer) { /* 中断上下文里只做一件事提交工作项 */ k_work_submit(my_work); } void my_work_handler(struct k_work *work) { /* 这个函数在线程上下文执行可以放心干重活 */ process_data(); notify_other_thread(); } K_WORK_DEFINE(my_work, my_work_handler);这样定时器回调只做最小动作耗时的事情全部移到工作队列线程里去执行。测试下来系统调度稳定很多也避免了在中断上下文里处理复杂逻辑带来的优先级反转风险。4.3 tickless 模式下定时器精度会怎样Zephyr 支持 tickless idle也就是系统空闲时不再产生周期性时钟中断而是设置一个定时器在下一个最近的事件点唤醒。这对低功耗很有帮助但对定时器精度有影响。tickless 模式下定时器到期是靠硬件定时器来唤醒系统的如果硬件定时器分辨率有限或者系统在深度睡眠中醒来需要恢复时间回调触发时刻会略有延迟。这个延迟通常在微秒到毫秒级别取决于你的硬件平台和电源管理配置。如果你的业务对定时精度要求极高比如微秒级的脉宽输出那 k_timer 本身就不合适得用硬件定时器或者 PWM 外设。k_timer 适合的是毫秒级、事件驱动这一类定时需求。5. 定时器常见坑位速查排查顺序和规避技巧5.1 典型问题对照表现象可能原因解决思路到期回调完全没有执行定时器没有启动或 duration 传了 0 被立即触发但回调被误认为没跑检查k_timer_start调用位置必要时用状态 API 确认在运行单次定时器触发后又触发了一次period 误设了非零值确认period传的是K_NO_WAIT或 0回调里调用某个 API 导致系统卡死/断言该 API 不允许在中断上下文调用把重活移到工作队列回调里只提交工作停止回调没触发定时器是自然到期的而不是调用k_timer_stop()停的确认业务路径上确实调用了 stop定时器周期不准误差越来越大系统 tick 频率配置问题或回调耗时过长检查CONFIG_SYS_CLOCK_TICKS_PER_SEC缩短回调低功耗睡眠后定时器唤醒偏晚tickless 模式精度受限用硬件定时器替代或评估是否可接受毫秒级误差5.2 排查定时器问题的推荐顺序先查状态再查参数最后查上下文。第一件事用k_timer_state_get()确认定时器到底跑没跑起来。第二件事检查k_timer_start()的参数特别是 duration 和 period 是否填反了位置这两个参数填反之后的现象很隐蔽定时器会变成立刻触发一次然后长期不触发或者每隔很长时间触发一次。第三件事确认回调里没有调用阻塞类 API。大多数定时器问题照着这个顺序都能揪出来。5.3 几个老手常留的口袋技巧我在实际项目里用定时器总结了几条小经验。第一周期定时器的回调里尽量别做与定时器对象相关的销毁、停止操作容易在中断上下文里处理自己时出现竞争。第二如果你的定时器只用来唤醒一个线程完全可以用k_sem_take(sem, K_MSEC(500))配合超时参数实现不一定非得上 k_timer省一个内核对象。第三小心并发调用k_timer_stop()和到期回调同时发生。一个极端情况定时器刚好到期到期回调已经在中断里排队了此时线程调用k_timer_stop()停止回调先执行随后到期回调还是会被调用。代码里要用标志位或者锁保证逻辑幂等别假设停了就一定不会再触发。5.4 与系统节拍配置的联动最后提醒一下定时器的所有时间参数最后都会换算成 tick 数所以CONFIG_SYS_CLOCK_TICKS_PER_SEC直接影响定时分辨率。假设系统节拍是 1000Hz一个 tick 是 1msK_MSEC(50)就是 50 个 tick如果系统节拍是 100Hz一个 tick 是 10msK_MSEC(50)还是 5 个 tick但实际到期误差可能到 10ms。节拍率越高定时越准CPU 中断负载也越高。做产品时这个参数要根据你所有定时任务的精度需求综合权衡不是越高越好。我自己调过一块低功耗板子原来节拍设 1000Hz设备空载时功耗偏高后来降到 100Hz大部分毫秒级定时任务的精度可以接受功耗降了一截但有一个 30ms 的协议超时判断变得不稳定最后还是把那个特定模块改成了硬件定时器才两全。这个经验说明定时方案没有银弹k_timer 是灵活便捷的通用方案但真到微秒级和低功耗极端场景还得结合硬件资源一起设计。