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