第3章 ThreadX操作系统介绍
本章节介绍 ThreadX 操作系统，让大家对 ThreadX 有一个整体的了解。
(资料图片仅供参考)
目录
第3章 ThreadX操作系统介绍
3.1 初学者重要提示
3.2 Express Logic公司介绍
3.2.1 FileX文件系统
3.2.2 NetX网络协议栈
3.2.3 USBX协议栈
3.2.4 GUIX图形界面
3.2.5 LevelX擦写均衡保护层
3.3 ThreadX简介
3.3.1 内存需求
3.3.2 API命名规则
3.3.3 实时性
3.3.4 安全认证
3.3.5 高级特性
3.3.6 简单易用
3.3.7 多核支持（AMP&SMP）
3.3.8 应用程序动态加载，类似安卓APP
3.3.9 快速推向市场
3.3.10 高质量源代码
3.3.11 MISRA兼容
3.3.12 支持的硬件平台
3.4 ThreadX各行各业应用案例
3.5 ThreadX论坛
3.6 总结
3.1 初学者重要提示
ThreadX是小型RTOS的巅峰之作，通过了各行各业的安全认证，并且大部分都是最高安全标准。 ThreadX为其微内核架构（picokernel™ architecture）,抢占阀值调度（preemption-threshold™ scheduling）, 事件链（event-chaining™）注册了商标。
3.2 Express Logic公司介绍
ThreadX的作者是William lamie（同样是Nucleus RTOS的原始作者，于1990年发布）。1996的时候成立了Express Logic，并于1997发布首版ThreadX RTOS。
ThreadX4发布于2001年，ThreadX5发布于2005年，ThreadX6发布于2020年。 FileX – ThreadX的嵌入式文件系统于1999年发布首版。 NetX – ThreadX的嵌入式TCP / IP网络协议栈于2002年发布首版。 USBX – ThreadX的嵌入式USB协议栈于2004年发布首版。 2009年推出了适用于SMP多核环境的ThreadX。 2011年发布支持动态应用加载的ThreadX Modules。 GUIX – ThreadX的嵌入式UI于2014年发布首版。 Microsoft在2019年4月18日以未公开的价格购买了Express Logic。
3.2.1 FileX文件系统
ThreadX的文件系统非常强劲，通过了各行各业的高等级安全认证。其它文件系统别说安全认证了，安全措施都不多，甚至没有。
规格如下：
再看API，一个文件系统竟然提供了230多个，仅异常处理的API就有20个（一个文件一个API）
3.2.2 NetX网络协议栈
ThreadX的网络协议栈对其它网络协议栈几乎是碾压性优势。一张图，几乎涵盖了我们日常项目大部分应用：
各个行业的安全认证：
物联网协议方向安全认证：
加密库也做了认证：
3.2.3 USBX协议栈
USB协议栈也不错，日常用的功能也齐全
规格如下：
3.2.4 GUIX图形界面
GUIX用于图形界面设计，功能强劲，特别是配套的图形界面开发软件GUIX Studio，可以添加设置各种主题，各种界面效果，各种字体展示，各种图片格式设置，真的是一条龙，非常方便。而且GUIX有各种安全认证。
GUIX通过了医疗认证IEC-62304 Class C，汽车认证IEC-61508 ASIL D，工业认证IEC-61508 SIL 4和运输/铁路认证EN50128，表明GUIX可用于安全关键型系统。
规格如下:
3.2.5 LevelX擦写均衡保护层
LevelX为NAND和NOR型Flash提供擦写均衡支持，并且对于NAND型，还支持ECC校验和坏块管理。
由于NAND和NOR型Flash擦除次数是有限的，因此均匀分配闪存使用至关重要。这通常称为擦写均衡，LevelX为此而生。LevelX向用户提供一个逻辑扇区阵列，这些逻辑扇区映射到LevelX内部的物理闪存。应用程序可以将LevelX与FileX结合使用，也可以直接读取/写入逻辑扇区。LevelX专为容错而设计。Flash更新是分多个步骤进行的，每个步骤都可以中断。在下一次操作期间，LevelX自动恢复到最佳状态。
3.3 ThreadX简介
ThreadX是先进的工业级实时操作系统，专为深度嵌入式，实时应用和IoT应用而设计。ThreadX提供了高级调度，通信，同步，计时器，内存管理和中断管理功能。此外，ThreadX具有许多高级功能，包括微内核架构（picokernel™ architecture）,抢占阀值调度（preemption-threshold™ scheduling）, 事件链（event-chaining™），执行时性能分析，性能指标以及系统事件跟踪。结合其易用性，ThreadX是苛刻的嵌入式应用理想选择。
62亿电子设备采用，是其它RTOS无法逾越的高山。ThreadX的产品涵盖了各种领域，包括NASA的多个太空探测项目，飞机自动驾驶仪系统，火星侦察轨道器等。
注：内核技术picokernel™ architecture，preemption-threshold™ scheduling和event-chaining™已经被ThreadX注册了商标。
3.3.1 内存需求
ThreadX最小空间需要2KB Flash空间和1KB RAM空间。这主要得益于ThreadX内核非分层的Picokernel™微内核架构和可裁剪性。
ThreadX内核各个组件需要的Flash空间如下：
3.3.2 API命名规则
ThreadX的函数命名规则是：Noun-verb naming convention （名词动词命名约定）。根据这个命名规格，我们实际看下个API，比如：tx_thread_create ，前缀tx，名词thread_，动词create。再看下面API截图（部分函数截图）：
基本也都符合这个命名规则。
3.3.3 实时性
ThreadX在大多数流行的处理器上实现了亚微秒的上下文切换时间。除了速度快之外，ThreadX还具有高度确定性。无论准备好200个线程还是仅准备一个线程，它都能实现相同的快速性能。
以下是ThreadX的一些典型性能特征：
快速启动：
ThreadX的启动时间少于120个周期。
可选的错误检查机制：
当验证了应用程序代码并且不再需要对每个参数进行错误检查时，可以在编译时跳过ThreadX错误检查，优化性能。
Picokernel™ Design（微内核设计）：
服务不会彼此套用，从而消除了不必要的函数调用开销。
优化的中断处理：
除非需要抢占，否则仅在ISR进入/退出时才保存/恢复暂存寄存器。
优化的API处理：
测试平台：200MHz处理器。
3.3.4 安全认证
ThreadX及其所有中间件的安全认证等级，至今没有一款小型RTOS可以与其匹敌。这么多安全认证，公司要入大量财力，人力和物力才可以完成，早前Micrium的一篇文章还谈过这个问题，投入了太多资金和人力了，还与风河的VxWorks做了简单对比。
（1）医疗 - FDA510（k），IEC-62304 Class C，IEC-60601，ISO-14971
（2）工业 - UL-1998，IEC-61508 SIL 4
（3）运输/铁路 - EN50128 SIL 4，BS50128, 49CFR236，IEC-61508
（4）航空航天设备 - DO-178B，ED-12B，DO-278
（5）汽车 - IEC-61508 ASIL D
（6）核应用 - IEC-61508
（7）家电 - UL/IEC 60730/60335
ThreadX的安全认证基本都达到了最高等级，像工业级认证IEC-61508达到了最高等级的SIL4，而uCOS，RTX5，embOS都是SIL3。
除了ThreadX内核有安全认证，中间件GUIX，FileX，NetX，甚至是加密库都有安全认证。在安全领域，ThreadX基本已经做到了登峰造极。
3.3.5 高级特性
ThreadX高级特性里面最具代表性的是抢占式阀值调度Preemption-Threshold™，此功能是ThreadX独有的功能，并且已成为广泛学术研究的主题。比如此贴的介绍：
具体如下：
完善的多任务机制：
线程，定时器组，消息队列，计数信号量，互斥信号量，事件标志组，块型内存池和字节型内存池。
支持基于优先级的抢占式调度。 支持1024个优先级设置。 支持合作调度。 Preemption-Threshold™抢占式阀值调度，ThreadX独有的功能，有助于确保可调度性并减少上下文切换。 内存保护。 完全确定性，确定性是指在在定义的时间内处理事件和中断，ThreadX提供完全确定性的行为，这意味着在预定义时间内（期限）处理事件和中断。 事件跟踪，记录最近的n个系统/应用程序事件。 Event Chaining™事件链，为每个ThreadX通信或同步对象注册一个专用的应用程序回调函数。 动态应用加载。 运行时性能指标展示： 恢复的任务个数。 挂起的任务个数。 请求的线程抢占次数。 异步线程中断抢占次数。 线程优先级反转次数。 线程释放CPU权次数。 执行配置文件套件（EPK）。 独立的中断栈。 运行时堆栈分析。 优化的定时器中断处理。
3.3.6 简单易用
ThreadX简单易用，API既直观又功能强大，并且所有API都遵循名词-动词命名约定。此外，整个API都具有功能一致性。例如，所有挂起的API都有一个可选的超时时间配置，对于API而言，超时的功能相同。
构建ThreadX应用程序也比较简单。教程的后面章节中，大家会体会到。ThreadX也有官方为其配套的用户手册。
3.3.7 多核支持（AMP&SMP）
ThreadX通常以非对称多处理（Asymmetric Multiprocessing, AMP）方式使用，其中ThreadX和应用程序（或其它系统）的单独在每个内核上执行，并通过共享内存或处理器间通信机制来相互通信，比如OpenAMP（ThreadX支持OpenAMP）。这是使用ThreadX的最典型多核配置，如果应用程序能够有效地加载处理器，则它可能是最高效的。
对于处理器高度动态加载的环境，ThreadX对称多处理（Symetric Multiprocessing，SMP）可用于以下内核：
ARM Cortex-Ax ARM Cortex-Rx ARM Cortex-A5x 64位 MIPS 34K，1004K和interAptiv PowerPC Synopsys ARC HS x86
ThreadX SMP在n个处理器之间执行动态负载平衡，并允许任何Core上的任何线程访问所有ThreadX资源（队列，信号量，事件标志，内存池等）。ThreadX SMP在所有内核上启用完整的API，并引入了适用于SMP操作的以下新API：
UINT tx_thread_smp_core_exclude(TX_THREAD *thread_ptr, ULONG exclusion_map);UINT tx_thread_smp_core_exclude_get(TX_THREAD *thread_ptr, ULONG *exclusion_map_ptr);UINT tx_thread_smp_core_get(void);UINT tx_timer_smp_core_exclude(TX_TIMER *timer_ptr, ULONG exclusion_map);UINT tx_timer_smp_core_exclude_get(TX_TIMER *timer_ptr, ULONG *exclusion_map_ptr);
3.3.8 应用程序动态加载，类似安卓APP
ThreadX MODULES可以使一个或多个应用程序线程可以捆绑到一个“模块（MODULES）”中，该模块可以在目标上动态加载和运行（或就地执行）。
ThreadX MODULES启用现场升级（field upgrade），错误修复和程序分区，以允许大型应用程序仅占用活动线程所需的内存。
ThreadX MODULES还具有与ThreadX本身完全独立的地址空间。这使ThreadX可以在MODULES周围放置内存保护（通过MPU或MMU），这样模块外部的意外访问将无法破坏任何其他软件组件。
3.3.9 快速推向市场
ThreadX易于安装，学习，使用，调试，验证，认证和维护。因此，根据嵌入式市场预测专家（EMF）的调查， ThreadX在过去七年中一直是领先的上市时间RTOS。调查一致显示，使用ThreadX的设计中有70％可以按时投放市场-超过了所有其他RTOS。
可以快速推向市场的原因：
高质量文档。 完整的源代码。 易于使用的API。 高级特性。 广泛的第三方工具集成–特别是IAR。
3.3.10 高质量源代码
从一开始，ThreadX就被设计为工业级RTOS，并附带完整的C源代码。ThreadX源代码在质量和易于理解方面树立了标杆。此外，一个函数一个源文件的方式，大大方便用户查阅浏览。
ThreadX遵守严格的编码规范，包括要求每行C代码都必须有有意义的注释。此外，ThreadX源码已通过最高标准的认证。
3.3.11 MISRA兼容
ThreadX和ThreadX SMP源代码符合MISRA-C：2004和MISRA C：2012。MISRA C是C语言编程规范，最初的MISRA C指南主要针对汽车应用。但是，MISRA C现在被广泛认为适用于任何对安全性要求很高的应用。ThreadX符合MISRA-C：2004和MISRA C：2012的所有必需和强制性规则。
3.3.12 支持的硬件平台
ThreadX在开箱即用，可以在各种主流的32/64位处理器上运行。经过全面测试和完全支持的平台如下：
3.4 ThreadX各行各业应用案例
ThreadX官网给出了航空航天，工业，汽车，医疗，消费电子，物联网，片上系统等方向的具体案例 ： https://rtos.com/x-ware-showcase/
以消费电子方向为例，三星，NEST，HTC等都是其客户，对应的产品也非常多。并且这些产品的直接使用ThreadX全套，基本ThreadX有的，就不再使用第三方组件：
3.5 ThreadX论坛
针对ThreadX，专门建立了论坛版块
当然，大家也可以上GUIX的官方Github开源地址提交问题：
3.6 总结
关于ThreadX就跟大家介绍这么多，更详细的可以上我们的论坛进一步讨论。
