RTOS的发展之MCU

　　使用过4 bit,8 bit（寻址能力256）MCU的前辈，应该早已忘了当年所使用的汇编语言（Mnemonics），在那个批注比程序代码还多的时代，别说是RTOS，就连用C编译程序都是奢侈品。时至今日，32 bit已经是主流了，性能上更是今非昔比。

效能的持续性提升

　　观察市场的MCU走向，目前跟SOC的明显分野之一，就在于是否支持MMU，以ARM v7m（Cortex M3/M4）为例，CPU仅支持PA（Physical Address），在锁定嵌入式市场的策略下，因市面上的RTOS仍以PA为大宗，未来走向VA(Virtual Address)的机率很低。

　　MCU的效能持续提升，可视为科技领域的常规，除了架构因素外（例如ARMv6->ARMv7->ARMv8），制程的进步同样功不可没，以40奈米转换为28奈米为例，就算芯片的设计没变，仍可享受因制程所带来的优势，不但可因更高的频率、获得实质的效能提升外，还能降低耗电。

　　持续提升的效能，其实也带来另一层的隐忧，例如部分效能不彰的RTOS，可受益于硬件的进步，来弥补其本身的不足，使消费者更容易忽略、因RTOS所损失掉的效能。举例来说，A厂商使用60MHz的硬件，完成了任务T，但B厂商使用同样平台，搭配RTOS，却需120MHz才能达成，以科学的角度分析，A的成效明显优于B，但因任务已达成，B厂商不会花功夫去检讨软件上的细节。但事实就是，RTOS本身需占用运算能力，Context Switch、Critical Section Protection、Scheduling等花费，可全部归类为Overhead（无关真正的工作需求、只为了实现多任务），至于完整效能被RTOS占用了多少比例，只有很少的厂商会认真看待。

　　当MCU前进到明显的效能过剩阶段后，理论上已不用在乎RTOS的Overhead损耗，但就算核心再快，延迟的关键仍旧没变，就算拉到1GHz仍难以掩饰。

影响延迟反应的因素

　　中断延迟（Interrupt Latency）的严格定义，应该从事件触发起算（标记为tA），直到处理程序接手（标记为tB），这段时间（Latency=tB-tA）自然是越短越好。

　　如果更仔细的分析，Latency是硬件跟软件的贡献总和。先谈硬件的部份，某个Event触发（标记为0ns），CPU虽然收到了讯号，但因执行中的指令、或内部因素，直到100ns后（这段时间归算给硬件），才着手处理这个中断，并执行其内定的硬件程序：诸如Push缓存器、更改执行模式、切换特权、设定状态、加载中断向量等，当CPU执行PC（=Vector）所指向的第一行指令的当下，时间已推进到500ns（使用400ns切换），以这个例子来说，因硬件造成的Latency为0.5us。

　　大多数CPU的硬件Latency是固定的，以Cortex-M4为例，官方文件提到，在Zero wait state memory的前提下，CPU从中断发生、到执行第一行ISR指令，至多（Maximum）为12 cycle（=120ns 100MHz）。这是个非常优秀的数字，除了展现了芯片厂商的努力成果，也预告了造成延迟的主因。

　　接着来分析一般RTOS处理中断的流程。为了让ISR能呼叫RTOS的服务，有一部分的作法，是将ISR分成两段（Top Half+Bottom Half），只有Bottom段可以使用API；另有一作法则是提供Interrupt Safe API；最极端的则是Hooking所有的ISR。无论如何，ISR内呼叫API所隐含的意义，就是希望能由对应的Task接手、来处理原本应在ISR里执行的任务，换言之，在多数RTOS的运作下，Latency应计算到该Task的第一行指令才对，因为这才是真实的延迟，至于这个数字会是多少，是否终于引起你的关注呢？在实务上，工程师也可选择在ISR里直接处理，但这显然会跟RTOS脱勾，也无意间说明了，刻意绕过RTOS，只是为了Real Time。

　　几乎所有的CPU都支持中断。当中断发生时，CPU进入中断模式、并执行ISR，当ISR结束、CPU重回正常模式。这个中断的规则，几乎可以套用在过去数十年间、所有出现过的MCU/CPU身上，虽然大方向一致，但各有各的处理细节与特色。也许是长久以来的历史包袱，多数CPU的中断是共享（或有限制）的，所以当中断发生后，如果ISR执行太久，就会影响下一个（也可说是所有的）中断事件。在这样的前提下，RTOS要求使用者缩短ISR的运行时间，并使用其API，将工作转给Task来执行，又因为Task的优先权机制，RTOS保证，重要的工作会被优先执行，且不影响下一个ISR的触发。这段的描述，其实可用来平反前一段、对于RTOS处理不力的质疑。显然，RTOS采用这样的作法是有原因的，其较长的延迟、是用来换取中断畅通的代价。

　　时至今日，对于ISR不应该占用太长时间的说法，其实是饱受挑战的。以Cortex-M为例，在整合NVIC后，ISR本身已具备优先权，而这只是新一代架构的其中一项特色而已。软件业应以新的思维，来因应这些新的硬件技术。

Hard Real Time的挑战

　　多数RTOS对于Real Time的定义为：「当事件发生后，保证在可预期的时间内处理之」，至于可预期的具体时间，则是一个复杂的问题。以RTOS厂商来说，其内部应有明确的数据，但碍于客户使用的MCU种类、时眽、编译程序、参数、甚至程序的写法等差异，确实很难给出明确的数据，但只要厂商有心，愿意提出基于某个平台的数据，就会很有参考价值。

　　Hard Real Time的一般定义，就是当系统的反应、超出了上述的「可预期时间」，就判定为错误。多数标榜Hard Real Time OS的产品，在体质上必定符合Constant Overhead的要求，至于因中断屏蔽，所造成的Interrupt Latency浮动问题，若对比数十倍以上的Overhead、则可完全忽略。综合后的结果，就是一个保证能达成的「宽松时间」。

　　Cortex-M4所保证的硬件延迟是12 cycle，如果工程师直接在ISR内处理任务，依照RTOS的前述定义，则：可预期的时间＝12 cycle。再回前述讨论，标榜Hard Real Time的「可预期时间」会是多少呢？这个数值估计将超过1000+cycle，不过，无论最终算出来的是1500、或是3000，其实都不打紧，只要将这个数值、填入「可预期时间」字段即可，系统「保证」在这个时间内有所反应。平心而论，以100MHz为基准，3000 cycle约为30us，这个数值就算宽松（对比12 cycle），但多数应用已够用，足已。

　　IEEE组织，在多年前成立了Time-Sensitive Networking(TSN)Task Group，希望藉由标准的制定，来带动产业的发展。这些(802.1x)标准所设定的时间单位是ns（＝10∧-9秒），这个极小的数值，凸显了产学界对于「Time-Sensitive」的期待及想象。简单来说，TSN就是一个要求Real Time的规范，而且精度是以奈秒来计算的，当厂商使用MCU来制作TSN的设备时，RTOS是否能胜任，这将是标榜Real Time的严苛考验。

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