RTOS的發(fā)展之MCU

　　使用過(guò)4 bit,8 bit（尋址能力256）MCU的前輩，應該早已忘了當年所使用的匯編語(yǔ)言（Mnemonics），在那個(gè)批注比程序代碼還多的時(shí)代，別說(shuō)是RTOS，就連用C編譯程序都是奢侈品。時(shí)至今日，32 bit已經(jīng)是主流了，性能上更是今非昔比。

效能的持續性提升

　　觀(guān)察市場(chǎng)的MCU走向，目前跟SOC的明顯分野之一，就在于是否支持MMU，以ARM v7m（Cortex M3/M4）為例，CPU僅支持PA（Physical Address），在鎖定嵌入式市場(chǎng)的策略下，因市面上的RTOS仍以PA為大宗，未來(lái)走向VA(Virtual Address)的機率很低。

　　MCU的效能持續提升，可視為科技領(lǐng)域的常規，除了架構因素外（例如ARMv6->ARMv7->ARMv8），制程的進(jìn)步同樣功不可沒(méi)，以40奈米轉換為28奈米為例，就算芯片的設計沒(méi)變，仍可享受因制程所帶來(lái)的優(yōu)勢，不但可因更高的頻率、獲得實(shí)質(zhì)的效能提升外，還能降低耗電。

　　持續提升的效能，其實(shí)也帶來(lái)另一層的隱憂(yōu)，例如部分效能不彰的RTOS，可受益于硬件的進(jìn)步，來(lái)彌補其本身的不足，使消費者更容易忽略、因RTOS所損失掉的效能。舉例來(lái)說(shuō)，A廠(chǎng)商使用60MHz的硬件，完成了任務(wù)T，但B廠(chǎng)商使用同樣平臺，搭配RTOS，卻需120MHz才能達成，以科學(xué)的角度分析，A的成效明顯優(yōu)于B，但因任務(wù)已達成，B廠(chǎng)商不會(huì )花功夫去檢討軟件上的細節。但事實(shí)就是，RTOS本身需占用運算能力，Context Switch、Critical Section Protection、Scheduling等花費，可全部歸類(lèi)為Overhead（無(wú)關(guān)真正的工作需求、只為了實(shí)現多任務(wù)），至于完整效能被RTOS占用了多少比例，只有很少的廠(chǎng)商會(huì )認真看待。

　　當MCU前進(jìn)到明顯的效能過(guò)剩階段后，理論上已不用在乎RTOS的Overhead損耗，但就算核心再快，延遲的關(guān)鍵仍舊沒(méi)變，就算拉到1GHz仍難以掩飾。

影響延遲反應的因素

　　中斷延遲（Interrupt Latency）的嚴格定義，應該從事件觸發(fā)起算（標記為tA），直到處理程序接手（標記為tB），這段時(shí)間（Latency=tB-tA）自然是越短越好。

　　如果更仔細的分析，Latency是硬件跟軟件的貢獻總和。先談?dòng)布牟糠?，某個(gè)Event觸發(fā)（標記為0ns），CPU雖然收到了訊號，但因執行中的指令、或內部因素，直到100ns后（這段時(shí)間歸算給硬件），才著(zhù)手處理這個(gè)中斷，并執行其內定的硬件程序：諸如Push緩存器、更改執行模式、切換特權、設定狀態(tài)、加載中斷向量等，當CPU執行PC（=Vector）所指向的第一行指令的當下，時(shí)間已推進(jìn)到500ns（使用400ns切換），以這個(gè)例子來(lái)說(shuō)，因硬件造成的Latency為0.5us。

　　大多數CPU的硬件Latency是固定的，以Cortex-M4為例，官方文件提到，在Zero wait state memory的前提下，CPU從中斷發(fā)生、到執行第一行ISR指令，至多（Maximum）為12 cycle（=120ns 100MHz）。這是個(gè)非常優(yōu)秀的數字，除了展現了芯片廠(chǎng)商的努力成果，也預告了造成延遲的主因。

　　接著(zhù)來(lái)分析一般RTOS處理中斷的流程。為了讓ISR能呼叫RTOS的服務(wù)，有一部分的作法，是將ISR分成兩段（Top Half+Bottom Half），只有Bottom段可以使用API；另有一作法則是提供Interrupt Safe API；最極端的則是Hooking所有的ISR。無(wú)論如何，ISR內呼叫API所隱含的意義，就是希望能由對應的Task接手、來(lái)處理原本應在ISR里執行的任務(wù)，換言之，在多數RTOS的運作下，Latency應計算到該Task的第一行指令才對，因為這才是真實(shí)的延遲，至于這個(gè)數字會(huì )是多少，是否終于引起你的關(guān)注呢？在實(shí)務(wù)上，工程師也可選擇在ISR里直接處理，但這顯然會(huì )跟RTOS脫勾，也無(wú)意間說(shuō)明了，刻意繞過(guò)RTOS，只是為了Real Time。

　　幾乎所有的CPU都支持中斷。當中斷發(fā)生時(shí)，CPU進(jìn)入中斷模式、并執行ISR，當ISR結束、CPU重回正常模式。這個(gè)中斷的規則，幾乎可以套用在過(guò)去數十年間、所有出現過(guò)的MCU/CPU身上，雖然大方向一致，但各有各的處理細節與特色。也許是長(cháng)久以來(lái)的歷史包袱，多數CPU的中斷是共享（或有限制）的，所以當中斷發(fā)生后，如果ISR執行太久，就會(huì )影響下一個(gè)（也可說(shuō)是所有的）中斷事件。在這樣的前提下，RTOS要求使用者縮短ISR的運行時(shí)間，并使用其API，將工作轉給Task來(lái)執行，又因為T(mén)ask的優(yōu)先權機制，RTOS保證，重要的工作會(huì )被優(yōu)先執行，且不影響下一個(gè)ISR的觸發(fā)。這段的描述，其實(shí)可用來(lái)平反前一段、對于RTOS處理不力的質(zhì)疑。顯然，RTOS采用這樣的作法是有原因的，其較長(cháng)的延遲、是用來(lái)?yè)Q取中斷暢通的代價(jià)。

　　時(shí)至今日，對于ISR不應該占用太長(cháng)時(shí)間的說(shuō)法，其實(shí)是飽受挑戰的。以Cortex-M為例，在整合NVIC后，ISR本身已具備優(yōu)先權，而這只是新一代架構的其中一項特色而已。軟件業(yè)應以新的思維，來(lái)因應這些新的硬件技術(shù)。

Hard Real Time的挑戰

　　多數RTOS對于Real Time的定義為：「當事件發(fā)生后，保證在可預期的時(shí)間內處理之」，至于可預期的具體時(shí)間，則是一個(gè)復雜的問(wèn)題。以RTOS廠(chǎng)商來(lái)說(shuō)，其內部應有明確的數據，但礙于客戶(hù)使用的MCU種類(lèi)、時(shí)眽、編譯程序、參數、甚至程序的寫(xiě)法等差異，確實(shí)很難給出明確的數據，但只要廠(chǎng)商有心，愿意提出基于某個(gè)平臺的數據，就會(huì )很有參考價(jià)值。

　　Hard Real Time的一般定義，就是當系統的反應、超出了上述的「可預期時(shí)間」，就判定為錯誤。多數標榜Hard Real Time OS的產(chǎn)品，在體質(zhì)上必定符合Constant Overhead的要求，至于因中斷屏蔽，所造成的Interrupt Latency浮動(dòng)問(wèn)題，若對比數十倍以上的Overhead、則可完全忽略。綜合后的結果，就是一個(gè)保證能達成的「寬松時(shí)間」。

　　Cortex-M4所保證的硬件延遲是12 cycle，如果工程師直接在ISR內處理任務(wù)，依照RTOS的前述定義，則：可預期的時(shí)間＝12 cycle。再回前述討論，標榜Hard Real Time的「可預期時(shí)間」會(huì )是多少呢？這個(gè)數值估計將超過(guò)1000+cycle，不過(guò)，無(wú)論最終算出來(lái)的是1500、或是3000，其實(shí)都不打緊，只要將這個(gè)數值、填入「可預期時(shí)間」字段即可，系統「保證」在這個(gè)時(shí)間內有所反應。平心而論，以100MHz為基準，3000 cycle約為30us，這個(gè)數值就算寬松（對比12 cycle），但多數應用已夠用，足已。

　　IEEE組織，在多年前成立了Time-Sensitive Networking(TSN)Task Group，希望藉由標準的制定，來(lái)帶動(dòng)產(chǎn)業(yè)的發(fā)展。這些(802.1x)標準所設定的時(shí)間單位是ns（＝10∧-9秒），這個(gè)極小的數值，凸顯了產(chǎn)學(xué)界對于「Time-Sensitive」的期待及想象。簡(jiǎn)單來(lái)說(shuō)，TSN就是一個(gè)要求Real Time的規范，而且精度是以奈秒來(lái)計算的，當廠(chǎng)商使用MCU來(lái)制作TSN的設備時(shí)，RTOS是否能勝任，這將是標榜Real Time的嚴苛考驗。

作者：科技下午茶啃泥https://www.bilibili.com/read/cv15838523