Zephyr的時鐘體系初看起來無非就是“一個內(nèi)核節(jié)拍加幾個API”但真正去讀源碼、寫驅(qū)動、調(diào)調(diào)度延遲的時候才知道這一層?xùn)|西有多繞。尤其是“Kernel Clocks”這個標(biāo)題它指的并不是你在設(shè)備樹里配的那個外設(shè)總線時鐘而是系統(tǒng)級的時間底座——內(nèi)核拿它來做什么時間維護(hù)、調(diào)度器切換、超時管理。我最初也以為這東西不過是定時器封裝直到親手在三四個不同硬件上碰過壁才摸清里面的門道。這篇就把內(nèi)核時鐘講透適合已經(jīng)開始用Zephyr、想知道節(jié)拍怎么觸發(fā)、超時為什么有時候差幾個毫秒、以及如何準(zhǔn)確拿到運行周期的開發(fā)者。1 內(nèi)核時鐘的整體框架1.1 系統(tǒng)時鐘與硬件時鐘的區(qū)別Zephyr里“Clock”這個詞其實有兩個完全不同層次的含義。硬件時鐘指單片機(jī)內(nèi)部實實在在的定時器外設(shè)、計數(shù)器外設(shè)比如常見的32位定時器、系統(tǒng)節(jié)拍定時器甚至是低功耗定時器。它們由晶振或PLL驅(qū)動在真實世界里產(chǎn)生脈沖。內(nèi)核時鐘則是建立在硬件計數(shù)器之上的邏輯概念——內(nèi)核并不直接關(guān)心硬件的每一次脈沖而是通過驅(qū)動層維護(hù)一個“當(dāng)前運行到第幾個節(jié)拍”的整數(shù)這個整數(shù)是調(diào)度器安排任務(wù)、處理超時、記錄啟動時長的根據(jù)。我當(dāng)時理解不深就犯過大錯直接在應(yīng)用層調(diào)用驅(qū)動讀硬件計數(shù)器然后換算成毫秒再拿來跟k_uptime_get()返回的值作比較。兩者有時差幾個毫秒我一開始以為是bug最后才發(fā)現(xiàn)硬件計數(shù)器是底層真實時間內(nèi)核節(jié)拍是經(jīng)過驅(qū)動處理和累積的“邏輯時間”這兩者之間有一個同步過程和量化誤差不是隨隨便便能畫等號的。用一個生活類比硬件時鐘是心跳每一次跳動都真實存在內(nèi)核時鐘是日歷它基于心跳次數(shù)累加出“今天是幾號”但日歷不會因為心跳偶爾快慢而立刻體現(xiàn)它只在每個節(jié)拍對齊點更新。真正理解這一點后面很多看似奇怪的現(xiàn)象就容易解釋了。1.2 時鐘在調(diào)度和超時中的角色Zephyr調(diào)度器依賴內(nèi)核時鐘完成兩件核心事情任務(wù)切換時機(jī)和超時判定。以搶占式調(diào)度為例當(dāng)高優(yōu)先級線程就緒且低優(yōu)先級線程正在運行時調(diào)度器并不需要時鐘介入直接觸發(fā)切換。但如果是時間片輪轉(zhuǎn)那么每個線程能跑多久由節(jié)拍計數(shù)決定——時間片到了調(diào)度器才強(qiáng)占。超時機(jī)制是另一個大塊。所有等待操作比如信號量獲取、隊列接收、線程sleep都需要一個超時參數(shù)。內(nèi)核把這些超時請求掛在一個“超時隊列”里隊列按到期節(jié)拍數(shù)排序。當(dāng)內(nèi)核時鐘推進(jìn)到某個節(jié)拍對應(yīng)等待線程被喚醒并重新參與調(diào)度。這個過程看似簡單但設(shè)計上有幾個關(guān)鍵決策誰負(fù)責(zé)檢查超時是每個節(jié)拍中斷都掃描隊列還是等隊列頭部到期再處理Zephyr用的是后者配合tickless機(jī)制平時中斷極少超時精準(zhǔn)觸發(fā)。1.3 時鐘約定對多核場景的影響如果你用的是多核系統(tǒng)比如某些雙核芯片內(nèi)核時鐘的維護(hù)又不一樣了。Zephyr在SMP場景下會有“錨定核”的概念——通常由主核負(fù)責(zé)維護(hù)全局節(jié)拍計數(shù)次核發(fā)生超時后被喚醒但節(jié)拍累加操作只在主核的中斷上下文執(zhí)行。這么做是為了免去鎖競爭次核讀取節(jié)拍計數(shù)時不需要禁中斷但代價是次核上的超時判斷可能晚一個節(jié)拍。多核調(diào)試時鐘問題時最容易遇到的坑是你在次核上跑一個精度要求高的任務(wù)以為k_uptime_get()足夠準(zhǔn)結(jié)果發(fā)現(xiàn)存在持續(xù)的、穩(wěn)定的偏差。這不是內(nèi)核時鐘跑慢了而是由于跨核同步開銷次核看到的時間更新時機(jī)略滯后。類似的系統(tǒng)間差異需要結(jié)合具體的SoC架構(gòu)來調(diào)整調(diào)度策略而不是簡單改個頻率值就能解決。2 核心概念與關(guān)鍵API2.1 節(jié)拍、周期、超時的換算內(nèi)核時鐘里有三個關(guān)鍵單位周期、節(jié)拍、時間毫秒。周期指的是硬件計數(shù)器的一次計數(shù)它的頻率是CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC節(jié)拍是內(nèi)核累加的基礎(chǔ)單位每CONFIG_SYS_CLOCK_TICKS_PER_SEC個節(jié)拍對應(yīng)一秒也就是說每個節(jié)拍間隔是1000/ticks_per_sec毫秒毫秒就是應(yīng)用最常用的時間單位。換算關(guān)系看上去簡單ms ticks * 1000 / ticks_per_sec。但實際實現(xiàn)不是用浮點除法而是做了很多整數(shù)優(yōu)化和預(yù)計算。以常見的ticks_per_sec 100為例一個節(jié)拍是10毫秒。k_uptime_get()返回毫秒數(shù)內(nèi)核不是每毫秒更新一次而是每10毫秒整段更新所以這個函數(shù)的精度天然受限于節(jié)拍大小。如果你調(diào)用k_uptime_get()兩次間隔不到一個節(jié)拍結(jié)果可能完全一樣。真正高精度的“當(dāng)前時刻”由k_cycle_get_32()獲得它直接讀硬件周期計數(shù)器精度取決于計數(shù)器頻率。假設(shè)計數(shù)器跑在32MHz那就比10毫秒的節(jié)拍精細(xì)得多。我在日常開發(fā)里凡是對時間精度有要求的測量一律用周期計數(shù)不用節(jié)拍毫秒。2.2 必用API和它們的用途Zephyr為內(nèi)核時鐘提供了幾組API應(yīng)用層開發(fā)者最常用的有這么幾個k_uptime_get()返回內(nèi)核啟動以來的毫秒數(shù)32位約49天溢出k_uptime_get_32()只取32位性能和存儲更優(yōu)k_uptime_get_64()返回64位毫秒數(shù)適合長時間運行統(tǒng)計k_uptime_ticks()返回原始的節(jié)拍計數(shù)不換算成毫秒k_cycle_get_32()返回硬件周期計數(shù)用于精確時間戳k_cycle_get_64()底層支持64位計數(shù)器時可用能避免32位翻轉(zhuǎn)問題k_timeout_t是各種等待接口的超時參數(shù)類型支持毫秒、節(jié)拍、周期三種換算在設(shè)置超時時通常用K_MSEC(100)表示100毫秒也支持K_TICKS(10)、K_CYCLE(320000)等構(gòu)造。這些宏看著簡單背后其實做了溢出檢查和類型轉(zhuǎn)換。習(xí)慣用法是能描述業(yè)務(wù)時間用K_MSEC需要精確對齊節(jié)拍邊界用K_TICKS需要跟硬件事件精確同步則用K_CYCLE。2.3 24位/32位/64位計數(shù)器的差異不同SoC上的硬件計數(shù)器寬度差異很大這是很多人低估的坑。一種典型的低功耗計數(shù)器只有24位跑在32.768kHz外部晶振下每秒計數(shù)32768次那么24位計數(shù)器在約512秒后就會翻轉(zhuǎn)歸零。內(nèi)核需要處理這種翻轉(zhuǎn)驅(qū)動層要判斷“計數(shù)變小是因為翻轉(zhuǎn)還是真的回退”這涉及符號差值運算一旦驅(qū)動沒處理好時間會時不時出現(xiàn)跳變。32位計數(shù)器是最常見的比如以1MHz運行的計數(shù)器約71分鐘后翻轉(zhuǎn)一次。k_cycle_get_32()直接用無符號減法計算時間差因此即使發(fā)生翻轉(zhuǎn)差值依然正確。但如果你把兩次k_cycle_get_32()的結(jié)果直接相減而不轉(zhuǎn)成有符號差超過2的31次方就會出現(xiàn)符號錯誤所以業(yè)務(wù)上測量短間隔時問題不大測量長間隔就得小心。64位計數(shù)器是少數(shù)高端SoC或外擴(kuò)定時器才有的。Zephyr提供k_cycle_get_64()同時配置項CONFIG_TIMER_HAS_64BIT_CYCLE_COUNTER會告知內(nèi)核這個能力。64位計數(shù)器幾乎不可能翻轉(zhuǎn)用于長期性能統(tǒng)計非常友好唯一的缺點是部分場景下讀取高32位和低32位需要額外處理可能引入短暫的讀取不一致硬件級鎖存可以解決但軟件驅(qū)動得正確使用鎖存寄存器。下面是三種情況的對比計數(shù)器寬度典型頻率翻轉(zhuǎn)周期常見問題推薦用法24位32.768kHz約512秒頻繁翻轉(zhuǎn)、驅(qū)動需補(bǔ)償?shù)凸膯拘?、粗略計?shù)32位1MHz約71分鐘差值計算需注意符號常規(guī)性能測量、超時換算64位數(shù)十MHz數(shù)百年讀取一致性長期統(tǒng)計、精確UTC對表2.4 時間戳的實現(xiàn)細(xì)節(jié)實際拿到精確時間戳的方式并不是直接調(diào)用一個現(xiàn)成的“獲取當(dāng)前時間戳”函數(shù)而是利用周期計數(shù)器組合節(jié)拍。常見做法是先用k_uptime_ticks()拿到當(dāng)前節(jié)拍再用k_cycle_get_32()拿到當(dāng)前周期位置兩者結(jié)合得到一個精度遠(yuǎn)高于節(jié)拍的近似時間。Zephyr內(nèi)部某些驅(qū)動就是這么干的比如網(wǎng)絡(luò)子系統(tǒng)打時間戳、協(xié)議棧統(tǒng)計往返延遲。但這里有個坑節(jié)拍和周期計數(shù)不是一個時刻采樣的數(shù)據(jù)它們之間存在微小偏移。普通場景可以忽略但做確定性驗證時需要在同一個臨界區(qū)里讀取這兩個值甚至要在讀取周期計數(shù)前后各讀一次節(jié)拍判斷中間是否發(fā)生了節(jié)拍更新。我自己的做法是用一個短臨界區(qū)先取節(jié)拍再取周期然后看周期讀取后有沒有跨越節(jié)拍邊界若跨越則修正一拍的偏移。3 配置層面怎么展開3.1 關(guān)鍵Kconfig選項內(nèi)核時鐘的配置項看起來不多但每個都對系統(tǒng)行為有很大影響。重點說這么幾個CONFIG_SYS_CLOCK_TICKS_PER_SEC每秒多少個節(jié)拍默認(rèn)通常是100CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC底層硬件計數(shù)器的頻率這個值必須跟硬件匹配不匹配會導(dǎo)致?lián)Q算錯誤CONFIG_SYS_CLOCK_EXISTS指示系統(tǒng)時鐘是否存在一般默認(rèn)yCONFIG_TIMER_HAS_64BIT_CYCLE_COUNTER底層是否支持64位周期計數(shù)CONFIG_TICKLESS_KERNEL啟用tickless模式空閑時停止周期中斷CONFIG_TIMER_NO_WAIT低功耗場景下不等待定時器硬件就緒其中CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC最容易配錯。它不是一個指定“你想要多快”的選項而是一個描述“實際硬件跑多快”的事實選項。如果這個值設(shè)錯所有從周期到毫秒的換算都會偏差而內(nèi)核節(jié)拍卻可能看起來正常——因為節(jié)拍是靠定時器中斷驅(qū)動的跟這個值沒有直接關(guān)系。我踩過一次板子的外部晶振實際是32.768kHz但配置里寫成了32768分頻后內(nèi)核節(jié)拍是100表面上完全正常但周期換算出來的延遲數(shù)據(jù)普遍多了3%左右。排查很久才定位到是晶振實際頻率在溫度和電壓變化下略有偏移而配置寫死導(dǎo)致?lián)Q算比例失真。3.2 節(jié)拍率到底選多少節(jié)拍率直接決定系統(tǒng)的響應(yīng)粒度和開銷。CONFIG_SYS_CLOCK_TICKS_PER_SEC設(shè)為100就是每10毫秒中斷一次設(shè)為1000就是每1毫秒中斷一次。中斷越多處理器越頻繁喚醒功耗越高但調(diào)度響應(yīng)更快。實際項目里怎么選我的經(jīng)驗是分場景低功耗電池設(shè)備選50或100中斷少省電代價是毫秒級任務(wù)響應(yīng)會慢交互式設(shè)備選1000觸摸、按鍵響應(yīng)用戶感知不出來延遲高性能音頻或電機(jī)控制不只靠內(nèi)核節(jié)拍還要用周期計數(shù)的PWM或?qū)Ｓ枚〞r器內(nèi)核節(jié)拍只做輔助調(diào)度特別提醒不要為了“提高精度”而無限提高節(jié)拍率。當(dāng)節(jié)拍率超過某個閾值中斷上下文切換的耗時可能超過有效工作時間況且內(nèi)核節(jié)拍本來有量化誤差——即使節(jié)拍率1000也仍然只能精確到1毫秒的整數(shù)倍真正的亞毫秒精度必須靠周期計數(shù)器。3.3 與底層counter驅(qū)動協(xié)作內(nèi)核時鐘并不直接操作寄存器它調(diào)用一個定時器驅(qū)動接口。這個驅(qū)動通常注冊在drivers/timer/目錄下對應(yīng)SoC的硬件定時器。從接口看驅(qū)動需要提供timer_start、timer_stop、timer_read等函數(shù)并負(fù)責(zé)在硬件中斷里調(diào)用sys_clock_announce()來告知內(nèi)核有多少節(jié)拍經(jīng)過。底層還可以是Zephyr的計數(shù)器Counter設(shè)備通過counter API封裝一層比如counter_start、counter_get_value、counter_set_alarm。定時器驅(qū)動調(diào)用counter API時中斷由counter設(shè)備觸發(fā)counter的回調(diào)再轉(zhuǎn)到內(nèi)核時鐘層。多一層封裝增加靈活性但也意味著要確認(rèn)驅(qū)動和counter中斷優(yōu)先級配合是否恰當(dāng)。如果定時器中斷被更高優(yōu)先級中斷頻繁搶占節(jié)拍延遲會累積導(dǎo)致系統(tǒng)時間越來越偏。我在某塊SoC上遇到過默認(rèn)配置下一個串口DMA中斷優(yōu)先級比系統(tǒng)節(jié)拍高且DMA中斷處理耗時較長導(dǎo)致節(jié)拍中斷被延遲幾個毫秒。表面現(xiàn)象是任務(wù)調(diào)度偶爾抖動深挖發(fā)現(xiàn)是中斷優(yōu)先級沒設(shè)計好。解決方式很簡單將定時器中斷設(shè)成比DMA中斷更高的優(yōu)先級或者將DMA中斷處理拆成短臨界區(qū)加底半部。3.4 設(shè)備樹與時鐘頻率的關(guān)系內(nèi)核時鐘與設(shè)備樹里的時鐘頻率設(shè)置也有關(guān)聯(lián)尤其是在SoC內(nèi)部定時器外設(shè)的時鐘源可能由某個總線時鐘分頻而來。設(shè)備樹里通常只指定時鐘驅(qū)動和時鐘頻率而最終喂給定時器的實際頻率由硬件時鐘控制驅(qū)動計算后配置。如果設(shè)備樹里標(biāo)注的總線頻率和真實PLL配置不一致定時器實際計數(shù)頻率就和你預(yù)想的不同。做硬件抽象時別在應(yīng)用代碼里寫死定時器頻率一定要通過DEVICE_DT_GET和對應(yīng)的clock_control_get_rate或者直接從設(shè)備樹屬性拿頻率值再換算成周期。否則換個板子、換個PLL配置所有時間換算都錯。4 實操驅(qū)動和超時實現(xiàn)4.1 從定時器驅(qū)動到內(nèi)核的對接如果自己寫一個定時器驅(qū)動對接內(nèi)核時鐘的流程可以這樣拆解第一步驅(qū)動初始化時配置硬件計數(shù)器頻率和中斷然后調(diào)用sys_clock_set_phase()建立一個初始相位對齊。第二步硬件中斷觸發(fā)后讀取當(dāng)前計數(shù)器的值計算距離上一次中斷經(jīng)過了多少個計數(shù)再換算成節(jié)拍數(shù)調(diào)用sys_clock_announce(ticks)。如果啟用tickless驅(qū)動還應(yīng)支持動態(tài)設(shè)置下一個報警點而不是固定周期性中斷。第三步驅(qū)動實現(xiàn)k_cycle_get_32()對應(yīng)的周期讀取函數(shù)返回當(dāng)前硬件計數(shù)值。第四步驅(qū)動需要處理暫停、恢復(fù)和低功耗切換保證掛起期間丟失的節(jié)拍在恢復(fù)后補(bǔ)上。核心代碼如下#include zephyr/kernel.h #include zephyr/drivers/timer/system_timer.h #include zephyr/sys_clock.h #define HW_FREQ CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC #define TICK_FREQ CONFIG_SYS_CLOCK_TICKS_PER_SEC static uint32_t last_count; void timer_isr(void *arg) { uint32_t now timer_hw_read_count(); uint32_t elapsed now - last_count; uint64_t ticks (elapsed * TICK_FREQ) / HW_FREQ; last_count now; sys_clock_announce((uint32_t)ticks); } uint32_t z_timer_cycle_get_32(void) { return timer_hw_read_count(); } void z_timer_init(void) { last_count timer_hw_read_count(); timer_hw_set_irq_callback(timer_isr, NULL); timer_hw_start(); sys_clock_set_phase(0); }這個例子里關(guān)鍵的坑是elapsed的計算——直接用無符號減法天然處理了計數(shù)器翻轉(zhuǎn)。但如果計數(shù)器寬度不是32位比如24位就要在每次讀取后做掩碼操作否則差值可能巨大。4.2 tickless模式與單次報警機(jī)制傳統(tǒng)內(nèi)核每節(jié)拍喚醒一次系統(tǒng)空閑時也在白白耗電。tickless內(nèi)核在空閑時關(guān)閉周期性中斷只在下一個已知超時點設(shè)置單次報警。這個機(jī)制能大幅降低功耗但也引入兩個需要注意的問題。第一個問題是“錯過的節(jié)拍”。系統(tǒng)從空閑中醒來時實際經(jīng)過的時間可能比預(yù)定報警點多出幾個節(jié)拍驅(qū)動必須在中斷里算出“實際經(jīng)過了多少節(jié)拍”調(diào)用一次sys_clock_announce()來彌補(bǔ)。第二個問題是“精度漂移”報警點設(shè)定用的是硬件周期換算成節(jié)拍時會有整除余數(shù)這些余數(shù)如果一直忽略長時間跑下來時間會越來越偏。Zephyr底層的sys_clock_set_phase()和剩余周期補(bǔ)償機(jī)制就是為處理這個誤差而存在的。以低功耗系統(tǒng)的實際表現(xiàn)為例某個項目里設(shè)備大部分時間處于睡眠偶爾醒來處理事件。如果報警點補(bǔ)償做得好k_uptime_get()長期誤差能控制在幾十毫秒如果驅(qū)動只是簡單地丟棄余數(shù)跑一天可能偏出一兩分鐘。4.3 應(yīng)用層的超時和定時器在內(nèi)核時鐘之上應(yīng)用最常用的是k_timer。它的接口非常直觀static void my_timeout_handler(struct k_timer *timer) { printk(timer expired, current uptime: %lld ms\n, k_uptime_get_64()); } void app_main(void) { struct k_timer my_timer; k_timer_init(my_timer, my_timeout_handler, NULL); k_timer_start(my_timer, K_MSEC(500), K_SECONDS(1)); }這里K_MSEC(500)是首次超時時間K_SECONDS(1)是后續(xù)周期。重點說一下超時參數(shù)的實際含義K_MSEC(500)在內(nèi)部會換算成節(jié)拍數(shù)由于節(jié)拍率可能是100那么500毫秒正好是50個節(jié)拍沒有量化損失但如果傳K_MSEC(501)換算結(jié)果可能是50或51個節(jié)拍取決于向上還是向下取整。需要精確控制的場景直接傳K_TICKS(50)最穩(wěn)妥。k_timer_start會更新底層報警點。如果你頻繁啟停一個周期很短的定時器注意底層硬件是否支持不斷重新編程下一個報警點。某些計數(shù)器硬件只能在當(dāng)前報警觸發(fā)后設(shè)置新值做不到“無縫更新”。這種情況下Zephyr會在驅(qū)動層做補(bǔ)償——先停掉舊報警再立刻設(shè)置新報警但這之間會損失極短時間窗口。對大多數(shù)業(yè)務(wù)來說無所謂但做精準(zhǔn)PWM或同步采樣就要考慮。4.4 測量內(nèi)核時鐘是否準(zhǔn)確判斷系統(tǒng)時間是否準(zhǔn)確我常用的辦法是在基準(zhǔn)GPIO上輸出秒脈沖用示波器或者外部高精度定時器對比。代碼層面直接讀k_uptime_get_64()的前后差值來驗證節(jié)拍推進(jìn)是否均勻。兩個方法結(jié)合能快速定位是驅(qū)動層計時錯誤還是應(yīng)用層換算錯誤。具體做法是啟動一個高優(yōu)先級線程死循環(huán)記錄k_uptime_get_64()和k_cycle_get_32()打印每次差值。如果節(jié)拍推進(jìn)均勻每次間隔應(yīng)該是嚴(yán)格的節(jié)拍間隔整數(shù)倍如果出現(xiàn)“偶爾多了一拍”或者“漏了一拍”問題基本出在中斷搶占或驅(qū)動補(bǔ)償邏輯。另外還有一個簡單方法利用k_uptime_get_64()和底層RTC時間做對比。睡十分鐘醒來后比較內(nèi)核節(jié)拍和RTC的差值如果偏差超過預(yù)期就去查驅(qū)動。RTC一般有自己的晶振精確度更高可以作為系統(tǒng)時間漂移的參照。這樣做有個前提內(nèi)核時鐘和RTC用的是同一個系統(tǒng)時間基準(zhǔn)Zephyr可能通過外部時間同步服務(wù)校準(zhǔn)需要確認(rèn)是否啟用了自動NTP類的同步機(jī)制。5 常見問題與排查技巧5.1 節(jié)拍精度和漂移最常見的現(xiàn)象是“系統(tǒng)時間比真實時間慢”或“快”排除硬件晶振本身誤差后要檢查幾點第一驅(qū)動里有沒有正確處理計數(shù)器翻轉(zhuǎn)。24位計數(shù)器頻繁翻符號運算稍不留神就會導(dǎo)致時間倒退一大截。第二中斷處理時是否讀取了正確的計數(shù)值。有些硬件定時器讀取會引入額外等待周期要確認(rèn)讀數(shù)沒有因為總線訪問延遲而失真。第三tickless模式下報警補(bǔ)償代碼有沒有真的執(zhí)行。有些驅(qū)動只做了周期性中斷的適配沒做單次報警補(bǔ)償表面能用實際時間越偏越離譜。我習(xí)慣在調(diào)試階段把CONFIG_TICKLESS_KERNEL臨時關(guān)掉用固定節(jié)拍中斷做對照。如果固定中斷模式下時間準(zhǔn)確開tickless后不準(zhǔn)就可以確定是報警補(bǔ)償邏輯問題而不是硬件計數(shù)器本身的問題。5.2 低功耗和暫停時鐘的影響進(jìn)入深度睡眠時很多SoC會直接停掉系統(tǒng)定時器時鐘或CPU時鐘。Zephyr的電源管理模塊會調(diào)用定時器驅(qū)動的暫停/恢復(fù)接口讓驅(qū)動記錄暫停前計數(shù)、暫停后重新對齊。如果驅(qū)動沒有實現(xiàn)這套邏輯睡眠喚醒后節(jié)拍計數(shù)會出現(xiàn)跳變或倒退直接表現(xiàn)為應(yīng)用層定時器全部錯亂。還有一類特殊場景CPU睡眠但定時器仍在跑或者反過來定時器停了但CPU還在跑。兩者都會造成內(nèi)核時間和真實時間的偏差。要確認(rèn)具體行為最直接的辦法是讀芯片手冊中關(guān)于定時器在低功耗模式下是否可用的描述在設(shè)備樹或驅(qū)動里根據(jù)這個行為做對應(yīng)處理。我見過一個板子默認(rèn)配置下CPU睡眠會連帶停掉系統(tǒng)定時器導(dǎo)致每次喚醒后k_uptime_get()像是“凍結(jié)”在睡眠前的時間業(yè)務(wù)上很多程序都受此影響。后來在配置里選了一個獨立的低頻時鐘源作為定時器時鐘問題才解決。5.3 幾個排查手段排查時鐘問題我先說排查順序再用表格整理。排查順序是先確認(rèn)硬件計數(shù)器的頻率讀數(shù)是否正確再確認(rèn)中斷是否按時觸發(fā)再確認(rèn)sys_clock_announce()傳入的節(jié)拍數(shù)是否準(zhǔn)確最后才懷疑應(yīng)用層換算。現(xiàn)象可能原因驗證手段時間均勻偏慢硬件頻率配置偏高對比RTC一段時間誤差時間均勻偏快硬件頻率配置偏低或丟失計數(shù)對比RTC或用秒脈沖抓GPIO偶發(fā)跳變計數(shù)器翻轉(zhuǎn)處理錯誤長時間跑打印每次差值睡眠喚醒后時間異常低功耗時鐘暫停/恢復(fù)未處理開關(guān)睡眠測試對比喚醒后時間中斷頻繁抖動中斷優(yōu)先級搶占定時器中斷優(yōu)先級調(diào)整后對比調(diào)試時最實用的一個手段是啟用內(nèi)核的時鐘統(tǒng)計功能通過查看sys_clock_elapsed()或相關(guān)宏來確認(rèn)當(dāng)前節(jié)拍數(shù)。另外直接閱讀arch/arch/core/下與時鐘相關(guān)的匯編代碼也有幫助不過那是比較內(nèi)核底層的活了一般在查中斷路徑時會用到。5.4 經(jīng)驗中斷上下文的節(jié)拍處理我在寫驅(qū)動時最深刻的經(jīng)驗是不要在高于定時器中斷優(yōu)先級的中斷里調(diào)用任何可能觸發(fā)調(diào)度的API。內(nèi)核時鐘的推進(jìn)依賴定時器中斷里調(diào)用sys_clock_announce()如果這個中斷被更高優(yōu)先級中斷長期擋住調(diào)度器無法及時處理超時系統(tǒng)的實時性指標(biāo)會瞬間崩壞。合理的做法是把高優(yōu)先級中斷里要做的事壓縮到極致只讀取必要寄存器、置標(biāo)志或往一個無鎖隊列里丟數(shù)據(jù)然后立刻退出。真正的時間敏感任務(wù)交給普通優(yōu)先級線程去處理。很多實時性問題的根子就在這里而不是調(diào)度器算法本身。另一個經(jīng)驗是精確測量中斷響應(yīng)時間這類業(yè)務(wù)不要依賴k_uptime_get()更不要依賴k_cycle_get_32()的差值去推算中斷發(fā)生點因為中斷入口本身和調(diào)用讀取API之間也有延遲。精確做法是讓中斷在入口處立即讀周期計數(shù)器并記錄到專用變量之后再在業(yè)務(wù)線程里讀取這個專用變量。這一下差別可能就有幾十到上百個周期在高速系統(tǒng)里已經(jīng)非?？捎^了。6 結(jié)合項目經(jīng)驗談幾個細(xì)節(jié)6.1 一個實際的時基設(shè)計例子我參與過一個某設(shè)備的同步控制項目要求所有節(jié)點基于同一個時間基準(zhǔn)協(xié)同動作。我們沒用內(nèi)核默認(rèn)的節(jié)拍作為控制基準(zhǔn)而是引入了一個獨立的高精度計數(shù)器外設(shè)用它做周期計數(shù)通過周期中斷驅(qū)動控制循環(huán)。內(nèi)核時鐘依然存在但只用來做調(diào)度和管理面的超時。這樣設(shè)計的好處是隔離控制循環(huán)的時間基準(zhǔn)完全不受內(nèi)核調(diào)度延遲影響而管理面的超時又能方便地利用內(nèi)核定時器。壞處是必須自己維護(hù)兩個時間源的同步。我們最后在驅(qū)動里實現(xiàn)了一個校準(zhǔn)函數(shù)每秒鐘讀取內(nèi)核周期計數(shù)和外部計數(shù)器的計數(shù)做一次差值校正。這個方案跑了一段時間時間一致性能控制在微秒級而單靠內(nèi)核節(jié)拍絕對做不到。這種場景也說明Zephyr的“Kernel Clocks”并沒有覆蓋所有時間需求。做高精度控制或測量時你要深入理解它能給什么以及它和底層硬件的邊界在哪里。這不是Zephyr的不足而是嵌入式系統(tǒng)設(shè)計里本來就存在的層次問題。6.2 時間片輪轉(zhuǎn)的時間片與節(jié)拍關(guān)系用時間片輪轉(zhuǎn)調(diào)度時時間片長度通常用CONFIG_TIMESLICE_SIZE_MS或CONFIG_TIMESLICE_PRIORITY配置。這里要注意時間片是用節(jié)拍數(shù)實現(xiàn)的不是用周期計數(shù)實現(xiàn)的。如果你設(shè)置時間片為5毫秒而節(jié)拍率是100那么實際生效的時間片可能是10毫秒或5毫秒取決于內(nèi)核節(jié)拍邊界的對齊。所以讓時間片長度等于節(jié)拍間隔的整數(shù)倍是最穩(wěn)妥的。我曾經(jīng)把時間片設(shè)成7毫秒期望幾種線程均勻輪流執(zhí)行結(jié)果實際表現(xiàn)出現(xiàn)明顯不均。后來查代碼發(fā)現(xiàn)時間片到期判定是基于“節(jié)拍計數(shù)是否跨越了超時點”7毫秒并不是10毫秒整數(shù)倍導(dǎo)致每個線程的時間片長度在一個和兩個節(jié)拍之間來回波動。改成10毫秒后一切正常。6.3 關(guān)于相位校準(zhǔn)和紀(jì)元同步如果系統(tǒng)需要和其他設(shè)備保持時間同步比如通過無線電對時或者分布式節(jié)點同步那么內(nèi)核時鐘需要支持“調(diào)整”而不是“跳變”。Zephyr的sys_clock_set_phase()允許驅(qū)動校準(zhǔn)周期與節(jié)拍之間的比例而k_uptime_get_64()返回的是單調(diào)遞增時間外部同步后可以疊加一個偏移量實現(xiàn)邏輯時間校正避免時間倒退導(dǎo)致各種定時器混亂。工程實現(xiàn)上我一般不會直接修改內(nèi)核節(jié)拍計數(shù)而是把外部同步的時間源封裝成一個獨立模塊內(nèi)部維護(hù)一個偏差值在讀取時加上去。這樣內(nèi)核時鐘仍然保持單調(diào)外部業(yè)務(wù)時間能夠跟隨標(biāo)準(zhǔn)時間源。如果強(qiáng)行改內(nèi)核計數(shù)所有正在等待的超時隊列都可能產(chǎn)生連鎖反應(yīng)輕則跑飛重則死鎖。這是我的血淚教訓(xùn)。6.4 如何閱讀定時器驅(qū)動源碼想深挖某個平臺的時鐘實現(xiàn)閱讀源碼路徑很有講究。定時器驅(qū)動一般在drivers/timer/下面文件名與具體SoC相關(guān)。找到驅(qū)動后優(yōu)先看三個部分初始化函數(shù)如何處理中斷優(yōu)先級和頻率配置周期讀取函數(shù)z_timer_cycle_get_32有沒有做掩碼或鎖存sys_clock_announce()的調(diào)用路徑是否涉及多核上的全局變量同步。讀懂這三個部分基本就能判斷這個平臺補(bǔ)了哪些坑、還有哪些隱患。比如我看到過某個驅(qū)動的sys_clock_announce()是在中斷里加鎖的這在單核沒問題但在SMP下會導(dǎo)致次核在等待鎖的時候錯過后續(xù)中斷。這種隱患通常不會在功能測試?yán)锉┞兜谥刎?fù)載和高頻率下會周期性造成延遲尖刺。7 從實戰(zhàn)角度聊聊我對內(nèi)核時鐘的使用建議7.1 默認(rèn)配置能用但別迷信Zephyr項目用默認(rèn)配置跑起來90%的場景不會出大問題?？烧嬲霎a(chǎn)品默認(rèn)的節(jié)拍率、時鐘源選擇、中斷優(yōu)先級配置往往不是最優(yōu)解。我的建議是產(chǎn)品定義階段就要明確時間精度要求然后倒推需要什么樣的硬件計數(shù)器、多大頻率、是否支持tickless、低功耗模式下時鐘是否保持。如果這個環(huán)節(jié)沒做后面出現(xiàn)時間問題再優(yōu)化往往要動驅(qū)動層或者硬件選型代價比一開始做設(shè)計大得多。7.2 周期計數(shù)是嵌入式時間測量的一等公民內(nèi)核節(jié)拍專注調(diào)度和超時周期計數(shù)則負(fù)責(zé)“真實時間”。一個熟練的嵌入式開發(fā)者應(yīng)該在所有涉及性能測量、精確同步、事件標(biāo)記的場景里習(xí)慣性使用k_cycle_get_32()或者底層周期計數(shù)API而不是毫秒級的k_uptime_get()。周期計數(shù)和節(jié)拍之間的轉(zhuǎn)換用k_ms_to_cyc_floor32()、k_cyc_to_ms_floor64()這類函數(shù)處理不要自己寫除法因為這些函數(shù)會處理溢出和取整規(guī)則。自己寫的換算代碼在邊界條件下很容易因為溢出或舍入方向不符合預(yù)期而出錯。7.3 內(nèi)核時鐘的擴(kuò)展方向后續(xù)做系統(tǒng)時你可以在這個基礎(chǔ)上擴(kuò)展的內(nèi)容包括周期計數(shù)器與外部時間源的對齊校準(zhǔn)、跨核共享時鐘的同步優(yōu)化、基于多個計數(shù)器的無縫切換機(jī)制。這些都是內(nèi)核時鐘概念的延伸Zephyr本身提供了一些基礎(chǔ)設(shè)施但具體策略需要根據(jù)產(chǎn)品需求定制。理解了最底層的節(jié)拍、周期、超時三者如何聯(lián)動這些問題自然就有了入手點。