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

效能的持續(xù)性提升

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

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

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

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

影響延遲反應的因素

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

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

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

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

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

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

Hard Real Time的挑戰(zhàn)

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

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

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

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

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