什么是uT/OS介绍

µT/OS是面向小规模嵌入式系统的实时操作系统内核，它的目标系统是假设为32位单芯片的微控制器，带有有限的ROM/RAM，没有MMU的系统等。因此，这个规范允许开发人员在小规模嵌入式系统上容易的进行优化和裁减。

大连悠龙软件科技有限公司从2008年开始借鉴谷歌在Android上的成功商业模式，以μT-Kernel规范为基础，2009年底在世界上第一个研发出支持Cortex M3和μT-Kernel规范的实时操作系统内核，后来逐渐加上Linux上的成熟轻量级开源中间件，推出了中国人自己的物联网开源实时操作系统-μTenux，在μTenux中遵循μT-Kernel规范的内核被命名为μT/OS。μTenux支持CortexM0/3/4、ARMV4T、ARMV5E等多种32位内核微控制器，在2010年和2011年陆续成为ATMEL和ARM公司全球操作系统战略合作伙伴。

支持T-Kernel规范的RTOS厂商主要是日本厂商，而且还是支持日本应用较多的微控制器和微处理器，包括瑞萨公司的产品在内。然而国内大多应用以ARM内核芯片为主，尤其是国内日益普及的Cortex M内核芯片，而且国内大部分电子产品公司使用未经授权的欧美商业RTOS开发产品，隐藏了很大的风险。如果在使用T-Kernel规范的基础上，研发中国人自己的嵌入式操作系统，相信对于促进中国国内物联网等电子产业发展会有非常大的促进作用，同时除了嵌入式操作系统内核外，操作系统厂商还需要在开发环境、中间件移植、典型应用等方面作大量的工作，才能形成自己自主知识产权的产品。

uT/OS定义

uT/OS是微控制器实时操作系统内核。

uT/OS1.1.定位

µT/OS是面向小规模嵌入式系统的实时操作系统内核，它的目标系统是假设为32位单芯片的微控制器，带有有限的ROM/RAM，没有MMU的系统等。因此，这个规范允许开发人员在小规模嵌入式系统上容易的进行优化和裁减。

uT/OS1.2.背景

Tron/T-Kernel创始人坂村健教授是世界上研究计算机结构的知名学者、工学博士，现任日本东京大学信息学研究生院副院长、教授、博导，也是日本政府研究开发/标准化战略委员会委员等。

坂村健教授在1984年领导TRON项目，采用结构自由开源、“弱标准化”的方针，对推动日本电子产品发展起了决定性作用；为了实现更理想的实时嵌入式计算结构，2002年启动了T-Engine项目，成立了T-Engine论坛，TRON的新一代-T-Kernel规范由此而来；

2007年随着ARM发布CortexM后，微控制器已经进入了32位的时代，为了支持32位的微控制器，坂村健教授对T-Kernel规范进行了裁剪，发布了μT-Kernel规范。

遵循TRON和新一代的T-Kernel规范的嵌入式实时操作系统广泛应用于汽车、移动电话、传真机、电视机、录像机和家电等各种电子产品领域，主要的用户有NTTDoCoMo、丰田、佳能、理光、松下、索尼、NEC、东芝、日立、富士通、阿尔派等全球知名汽车和电子产品厂商。在日本市场上，TRON和T-Kernel规范为基础的RTOS占有60%的份额。

不论是物联网、汽车电子、家用电器、医疗仪器、工业控制、机器人、仪表等，遵循T-Kernel规范的RTOS都是很适合的开源实时嵌入式操作系统。

支持T-Kernel规范的RTOS厂商主要是日本厂商，而且还是支持日本应用较多的微控制器和微处理器，包括瑞萨公司的产品在内。然而国内大多应用以ARM内核芯片为主，尤其是国内日益普及的CortexM内核芯片，而且国内大部分电子产品公司使用未经授权的欧美商业RTOS开发产品，隐藏了很大的风险。如果在使用T-Kernel规范的基础上，研发中国人自己的嵌入式操作系统，相信对于促进中国国内物联网等电子产业发展会有非常大的促进作用，同时除了嵌入式操作系统内核外，操作系统厂商还需要在开发环境、中间件移植、典型应用等方面作大量的工作，才能形成自己自主知识产权的产品。Google开发的Andorid智能手机操作系统就是非常成功的开源案例。

大连悠龙软件科技有限公司从2008年开始借鉴谷歌在Android上的成功商业模式，以μT-Kernel规范为基础，2009年底在世界上第一个研发出支持CortexM3和μT-Kernel规范的实时操作系统内核，后来逐渐加上Linux上的成熟轻量级开源中间件，推出了中国人自己的物联网开源实时操作系统-μTenux，在μTenux中遵循μT-Kernel规范的内核被命名为μT/OS。μTenux支持CortexM0/3/4、ARMV4T、ARMV5E等多种32位内核微控制器，在2010年和2011年陆续成为ATMEL和ARM公司全球操作系统战略合作伙伴。

uT/OS1.3.设计方针

µT/OS内核设计方针是基于容易优化、容易学习、容易移植、容易测试以及容易为小规模嵌入式系统裁减。

和用于微处理器的T/OS不同的是，为了容易优化和裁减，在小系统中不使用的功能和加重系统负担的功能都被省略了，增加了有效使用资源的功能。

为了改善分发和移植，µT/OS的强标准化保证了不同µT/OS之间的移植性，同时，µT/OS接口的统一也保持了和T/OS的高度兼容性。特别的是，为µT/OS和T/OS都存在的功能定义了一致的接口，µT/OS中的数据类型也和T/OS一致。因此，使用µT/OS和T/OS都有的函数，按照移植准则编写程序，保证可以通过重编译就能够移植程序。一个仅仅在µT/OS出现的功能可能是对T/OSl的增强，但也是对T/OS格式的自然增强。所以，当使用T/OS的功能移植时，程序几乎不需要修改。

µT/OS合并了任务管理和任务相关的同步函数，合并后类别为任务管理函数。

µT/OS删除了在µT-Kernel中的子系统定义和外设流设备驱动相关的所有功能。

µT/OS增加了启动内核和退出内核的系统管理函数。

uT/OS1.4.调整

µT/OS规范设计时考虑了和T/OS的兼容性。就是说，当在µT/OS和T/OS间移植程序时，规范要求仅仅使用通用函数，允许仅通过重新编译和最小修改来移植程序，即使修改是必然的。所以，µT/OSl包含了一些对于一般系统不必要的功能。不管怎样，如果定义了这个系统的子集，设备驱动程序和中间件等的分发和移植将被消弱。此外，如果按照目标系统不同必要的功能也不同的话，定义子集规范将是非常困难的。

在µT/OS中，产生子集的规范，比如基本分类等，没有被定义。所有兼容µT/OS规范的OS必须实现所有的功能。然而，当合并µT/OS到目标系统时，可以删除不必要的功能。就是说，OS供货商应该支持规范中的所有功能，但用户能够选择和使用仅仅必要的功能。

1、µT/OS基本概念

uT/OS性质

uT/OS的特性描述。

uT/OS2.1.基本术语的含义

uT/OS2.1.1.关于实现的术语

1、实现定义(Implementation-defined)

这个词条不是µT/OS规范中的标准，而是应该在每个具体的实现中定义。实现的细节应该在实现规范中详细说明。在应用程序中，对于依赖实现定义条目的部分的移植性不能保证。

2、实现依赖(Implementation-dependent)

这个词条说明在µT/OS规范中，随着目标系统和操作条件的不同，行为也有差异。行为可能被具体的实现定义。实现的细节应该在实现规范中详细说明。在应用程序中，对于依赖实现依赖条目的部分，基本上需要随着移植而进行修改。

3、实现规范(ImplementationSpecifications)

这个文档解释了µT/OS在支持目标系统时，实现的细节等。当µT/OS为一个目标系统而被实现、调整、优化时，建议创建相应的实现规范。

uT/OS2.1.2.其他基本术语的含义

1、任务（task）和调用任务（invokingtask）

并行程序执行的基本逻辑单元称为“任务”。一个任务的程序是顺序执行的；而不同任务的程序却是并行执行的。从应用程序的观点来看，此处的并行处理只是一个概念上的现象。实际上，它是通过内核控制任务间的时间共享来实现的。

进行系统调用的任务被称为“调用任务”。

2、分派（dispatch）和分派器（dispatcher）

处理器执行的任务间的切换称为“分派”（或任务分派）。用来实现分派的内核机制叫做“分派器”（或任务分派器）。

3、调度（Scheduling）和调度器（scheduler）

决定要执行的下一个任务的处理过程称为“调度”（或任务调度）。用来实现调度的内核机制叫做“调度器”（或任务调度器）。通常，调度器的功能在系统调用处理过程中或分派器内实现。

4、上下文（context）

一个程序运行的环境通常被称为“上下文”。若要说上下文完全一致，最起码的条件是处理器的运行模式必须相同，并且堆栈空间（相同连续区域的一部分）必须一致。

请注意，上下文是一个应用程序立场上的概念。即便处理过程并不在同一个上下文中执行，而在实际执行中，这些上下文有时也会使用相同的处理器模式以及相同的堆栈空间。

5、优先权（precedence）

不同处理请求之间的、决定处理的先后次序的关系称为“优先权”。在处理较低优先权任务的过程中，如有一个拥有更高优先权的处理请求发生，通常，拥有较高优先权的处理将先于其他处理执行。

优先级（Priority）是应用程序分配的一个参数，用来控制任务或消息处理的顺序。而优先权（precedence）在这份规范中是用来明确处理执行的先后次序。任务间的优先权是由优先级来决定的。

uT/OS2.2.任务状态和调度规则

uT/OS2.2.1.任务状态

任务的状态可分成下面5种。其中，广义的等待状态被进一步划分为3种情况。而所说的任务处于运行状态是指任务处于运行状态或者就绪状态。

(a)运行状态（RUNstate）

当前任务正在运行。除非另外指明，否则当任务无关部分执行时，先于任务无关部分执行的任务被认为处于运行状态。

(b)就绪状态（READYstate）

任务已经完成运行前的准备，但由于有更高优先权的任务正在运行，使得它不能运行。处于这个状态的任务，只有优先权比其他处于就绪状态或者运行状态的任务高时方可运行。

(c)广义的等待状态

由于运行的条件未达到而导致任务不能运行。换言之，任务正在等待执行条件被满足。当任务处于任何一种等待状态时，程序计数器和寄存器的值，以及其他代表程序执行状况的信息都将被保存起来。当任务从这个状态返回而被执行时，程序计数器和寄存器的值，以及其他的值都将立即被恢复为它们进入等待状态前的值。这个状态被细分为下述3种状态。

(c.1)等待状态（WAITstate）

由于有系统调用函数被调用而中断了调用任务的执行时，执行将被停止，直到某些条件满足。

(c.2)挂起状态（SUSPENDstate）

执行被其他任务强行中断。

(c.3)等待挂起状态（WAIT-SUSPENDstate）

任务在同一时间内既在等待状态，也在挂起状态。对于处于等待状态的任务，一旦强制变为挂起状态，它将处于等待挂起状态。µT/OS明确区分“等待状态”和“挂起状态”。一个任务本身不能将自己变为“挂起状态”。

(d)静止状态（DORMANTstate）

任务还未启动或者已经完成执行的状态。当任务处于静止状态时，代表它的执行信息将不被保存。当一个任务从静止状态开始启动时，执行将从任务的起始地址开始。除非另外声明，否则寄存器的值将不被保存。

(e)不存在状态（NON-EXISTENTstate）

任务建立前或者删除后的一种虚拟状态，任务此时并未在系统中注册。

根据实现的方法，任务可能会处于一些暂时的状态，而这些状态并不属于上述的任何一种（请参阅2.4部分）。

当转到就绪状态的任务的优先权高于当前正在运行的任务时，在任务进入就绪状态的同时会产生（任务的）分派，使得该任务立刻转为运行状态。在这种情况下，就称之前处于运行状态的任务被刚转入到运行状态的任务抢占了。请注意，在系统调用函数的说明中，即使在说明一个任务进入就绪状态时，该任务也可能立刻进入运行状态，这是由它的优先权所决定的。

任务启动是指把它的状态从静止状态转为就绪状态。因此，如果说一个任务并不处于静止或者不存在状态，那么它被称为处于“已经启动”的状态。任务退出是指把一个处于启动状态的任务转到静止状态。

任务的等待释放是指使一个任务从等待状态转为就绪状态，或者是使一个处于等待-挂起状态的任务转为挂起状态。挂起任务的恢复是指使一个处于挂起状态的任务转为就绪状态，或者是使一个处于等待-挂起状态的任务转为等待状态。

图2.1所示为任务状态转换的一种典型的实现方法。依赖具体的实现方法，除了上面列出的状态之外，还可能会有其他状态。µT/OS的一个特征是可将操作会影响调用任务的系统调用（函数）与操作会影响其他任务的系统调用（函数）清楚地区分开来（参阅表2.1）。这样做的原因是使任务的状态转换更加清晰，并使系统调用更加易于理解。将调用任务中的系统调用操作和影响其他任务的操作区别开来，也可以看成是把运行状态的状态转换与其他状态的状态转换区别开来。

表2.1：区分调用任务和其他任务的状态转换

等待状态和挂起状态的关系是互相垂直的；也就是说，请求转换到挂起状态并不会影响到释放任务等待状态的条件。这就表明，不管任务处于等待状态，还是等待-挂起状态，释放任务等待状态的条件都是相同的。因此，即使一个正处于等待获得某些资源（信号资源和内存块等）的任务请求转变为挂起状态且任务因此而进入等待-挂起状态时，分配资源的条件也不会改变，还是与请求进入挂起状态前一样。

µT/OS把等待状态（由调用任务所导致的等待）和挂起状态（由其他任务所导致的等待）区分开来的原因在于，这些状态有时候会互相叠加。而通过把叠加的状态区别为等待-挂起状态，任务的状态转换将变得更加清晰，而且系统调用（函数）也将变得更加容易理解。另一方面，由于处于等待状态中的任务无法调用系统调用（函数），所以不同类型的等待状态(例如，唤醒的等待状态和获得信号量资源的等待状态等）将永远不会互相叠加。由于只有一种等待状态是由其他任务引起的（挂起状态），所以，µT/OS规范可把挂起状态的叠加视为一种嵌套的过程，从而实现了任务状态转换的明朗化。

图2.1：任务状态转换

uT/OS2.2.2.任务调度规则

基于分配给每个任务的优先级级别，µT/OS规范采用抢占式的基于优先级的调度方法。拥有相同优先级的任务的调度按照FCFS（FirstComeFirstServe先来先服务）的原则进行。特定情况下，任务的优先权作为任务的调度规则，而任务间的优先权则将根据任务的优先级按照下述方法来确定：如果有多个任务可以运行，那么拥有最高优先权的那个任务转为运行状态，其他的则转为就绪状态；在决定任务的优先权时，对于不同优先级的任务，拥有最高优先级的任务最先执行；而对于优先级相同的任务，首先进入运行状态（运行状态和就绪状态）的任务最先执行。尽管如此，也可以使用一个系统调用（函数）来修改优先级相同的任务的先后执行顺序（precedence）。当最高优先权从一个任务转到另外一个任务时，立即产生一次分派（操作），处于运行状态的任务被切换。但是，如果分派并未发生，那么处于运行状态的任务的切换将被延迟，直到分派（操作）产生。

根据µT/OS规范所采用的调度规则，只要有一个高优先权的任务处于运行状态，低优先权的任务就不会运行。也就是说，除非高优先权的任务处于等待状态或者由于某些原因而不能运行，否则其他任务是不能运行的。这是与时间共享系统TSS（TimeSharingSystem）的调度的根本不同之处。在时间共享系统中，多个任务被看作是平等的。尽管如此，还是允许通过发出一个系统调用（函数）来改变优先级相同的任务的优先权。应用程序可以通过使用这样的系统调用（函数）来实现轮番调度（round-robinscheduling）。它是一种典型的TSS调度。

图2.2：初始状态时任务执行的优先权

图2.2和下面的说明描述了首先进入运行状态（运行状态或者就绪状态）的任务是如何在拥有相同优先级的任务中获得优先执行权的。图2.2所示为优先级1的任务A、优先级3的任务E，以及优先级2的任务B、任务C和任务D以这个顺序启动后的先后执行次序。优先权最高的任务A进入运行状态。

当任务A退出后，下一个拥有最高优先权的任务B将进入运行状态（见图2.3）。当任务A重新启动时，任务B被抢占而返回到就绪状态；但由于任务B比任务C和任务D早进入运行状态，所以，它在相同优先级的任务中仍然拥有最高的优先权，所以，任务的优先权恢复到如图2.2所示。

接下来要考虑的是图2.3中的任务B转入等待状态后将发生什么。由于任务的优先权是定义在可运行的任务中的，所以任务的先后执行顺序将如图2.4所示的那样。然而，当任务B的等待状态释放时，任务B在任务C和任务D之后进入运行状态，成为同等优先级的任务中优先权最低的一个（见图2.5）。综上所述，一旦一个从就绪状态转变为运行状态的任务返回到就绪状态，其优先权就是具有相同优先级的任务中最高的；但是，如果一个任务先从运行状态转变为等待状态，然后其等待再被释放，则其优先权是具有相同优先级的任务中最低的。

图2.3：任务B进入运行状态后任务执行的优先权

图2.4：任务B进入等待状态后任务执行的优先权

如果一个任务从挂起状态返回到运行状态后，它是优先级相同的任务中优先权最低的一个。

图2.5：任务B等待状态释放后任务执行的优先权

uT/OS2.3.中断处理

µT/OS规范中的中断包括由设备引发的外部中断和CPU异常产生的中断。每个中断号都可定义一段中断处理程序。中断处理程序可设计成直接启动，基本上无须操作系统的干预，或者通过一个高级语言的支持函数来启动。

uT/OS2.4.系统状态

24.1.非任务部分（Non-taskPortion）执行时的系统状态

当编程任务在µT/OS中运行时，任务状态的改变可通过查看任务状态转换图来跟踪。然而，在中断处理程序或者扩展SVC处理程序中，用户的编写应当站在内核而不是任务的层面上来考虑。在这种情况下，必须考虑到非任务部分执行时的系统状态；否则所编写的任务将不能正确执行。因此，下面对这种情况下的µT/OS系统状态进行说明。系统状态的分类如图2.6所示。其中的“瞬时状态（transient）”等同于系统的(系统调用函数执行时的）运行状态。从用户的角度来看，比较重要的是，由用户发布的每个系统调用都能完整地执行，而系统调用（函数）执行时的内部状态是不能被用户看见的。因此，系统运行中的状态被看作是一种“瞬时状态”，而其内部则被作为一个黑盒子来看待。然而，在下述的情况中，瞬时状态并不能被完整地执行。

l在系统调用（函数）正分配或释放内存的情况下，内存被获取或释放的时候

当任务处于这些瞬时状态时，无法保证终止任务的系统调用（函数）（tk_ter_tsk函数）的操作。此外，如果任务挂起（tk_sus_tsk函数）停止时未清除瞬时状态，那么将导致死锁或其他问题。因此，通常tk_ter_tsk（函数）和tk_sus_tsk（函数）不能在用户程序中使用。这些系统调用（函数）应当只用于诸如子系统或者调试器等与OS非常接近并可被视为OS一部分的子系统中。任务无关的部分(状态）和准任务部分(状态)也是处理程序执行中的状态。在任务上下文中运行的那一部分（运行状态）被称为准任务部分（运行状态），而在与任务无关的上下文中运行的那一部分（运行状态）被称为任务无关部分（运行状态）。处理由用户定义的扩展系统调用（函数）的扩展SVC处理程序属于准任务部分，而通过外部中断触发的中断处理程序或者时间事件处理程序则属于任务无关部分。在准任务部分（运行状态）中，任务拥有与普通任务一样的瞬时状态，并且在等待状态中也可以发布系统调用（函数）。瞬时状态、任务无关部分（运行状态）和准任务部分（运行状态)合称为非任务部分（运行状态）。当除这些状态之外的普通任务程序运行时，对应的状态都被称为“任务部分运行”状态。

图2.6：系统状态的划分

24.2.任务无关部分与准任务部分

任务无关部分（中断处理程序、时间事件处理程序等）的特点是，在即将进入任务无关部分（运行状态）前鉴别正在运行的任务是无意义的，在此并不存在“调用任务”的概念。因此，一个进入等待状态的系统调用（函数），或者是发布时隐含地指明调用任务的系统调用（函数）都不能在任务无关部分（运行状态）中调用。而且，由于在任务无关部分（运行状态）中不能鉴别当前运行的任务，所以将不会有任务切换（分派）发生。

如果有必要产生（任务）分派，那么它将被延迟，直至任务退出任务无关部分（运行状态）。这种情形被称为延迟分派（delayeddispatching）。如果分派发生在属于任务无关部分的中断处理程序中，那么所剩的中断处理程序将在分派的任务启动后才继续执行。这在中断嵌套中会造成一些问题，如图2.7所示。

如例中所示，中断X在任务A执行的时候被触发，但在执行X的中断处理程序过程中一个有更高优先级的中断Y被触发。在这种情况中，如果任务B的分派在中断Y返回

（1）时立即发生，就启动任务B，属于A的中断处理

（2）和

（3）的执行将被闲置，直到任务B执行完，任务A返回到运行状态为止。可见，危险的是，低优先级的中断X的处理程序不仅会被高优先级的中断Y抢占，甚至还会被这个中断（Y）启动的任务B抢占。这使得无法再保证中断处理程序的优先级一定高于任务处理，从而可能造成中断程序的无法编写。这也是为何要引入延迟分派的原因。

而准任务部分的特点是，进入准任务部分（运行状态）前可以鉴别所执行的任务（请求的任务），这就使得它可与任务部分（运行状态）一样来定义任务的状态；而且，在准任务部分（运行状态）中也可以进入等待状态。因此，准任务部分（运行状态）中分派出现的方式与正常任务执行中的相同。

这样，尽管OS扩展部分和其他准任务部分（运行状态）都是属于非任务部分（运行状态），但是无须使其在执行时的优先级总是高于任务部分。这恰好与中断处理程序的执行相对应，中断处理程序的执行优先权总是高于任务。

下面两个例子描述了任务无关部分和准任务部分之间的区别。

l一个中断在任务A（优先级8=低）正在运行时被触发，并且，在这个中断处理程序中（任务无关部分）调用了tk_wup_tsk函数来唤醒任务B（优先级2=高）。但是，根据延迟分派的原则，分派并不会在此时发生，而是在tk_wup_tsk执行后，先执行中断处理程序的剩余部分。只有tk_ret_int在中断处理程序结束处被执行后，分派操作才会发生并导致任务B的运行。

l一个扩展系统调用（函数）在任务A（优先级8=低）中被执行，并且在它的扩展SVC处理程序中调用了tk_wup_tsk函数来唤醒任务B（优先级2=高）。在这种情况下，延迟分派的原则并不适用，所以，在处理tk_wup_tsk时分派就会发生。处于准任务部分中的任务A进入就绪状态，而任务B进入运行状态。因此，任务B将在SVC处理程序的剩余部分执行之前执行，而扩展SVC处理程序的剩余部分将在分派再次发生后执行，任务A转入运行状态。

图2.7：中断嵌套与延迟分派

uT/OS2.5.对象

“对象”是对µT/OS所处理的资源的一个统称。除了任务之外，对象还包含了内存池、信号量、事件标志、邮箱以及其他同步和通信机制，如时间事件处理程序（周期处理程序和报警处理程序）等。

对象的属性通常在它建立时设置。属性决定了对象行为和对象初始状态等细节上的差别。当某对象的TA_XXXXX（属性）被设定时，该对象将被称为“带TA_XXXXX属性的对象”。如果没有特别需要定义的属性，那么将设定为TA_NULL（=0）。一般情况下，对象在注册后都不会提供读取其属性的接口。在对象或者处理程序属性的值中，低位用来指定系统的属性，高位用来指定与具体实现方案相关的属性。µT/OS规范并未指定区分高位和低位的位所在的位置。原则上，系统的属性都从最低位（LSB）向最高位（MSB）来放置，而具体实现方案相关的属性从最高位向最低位来放置。而未被用于定义属性的位将被清0。

某些情况中，一个对象可以包含扩展信息。扩展信息在对象注册的时候指定。对象开始执行时，扩展信息对µT/OS的操作无影响；扩展信息可通过调用一个对象状态查询系统调用（函数）来读取。

每个对象都由一个数字ID来标识。在µT/OS中，数字ID不能被用户指定，而是在对象建立时自动分配的。因此，对于调试来说，会有些困难。因为这个原因，在建立对象时，用户可以指定对象的名称用于调试。这个名称仅仅用于调试，也仅仅能够被调试支持函数访问。µT/OS并不会检查对象的名称。

uT/OS2.6.内存

uT/OS2.6.1.地址空间

µT/OS仅仅有单一的地址空间。就是说，所有的任务和任务无关部分总是访问同样的地址空间。

T/OS的地址空间被划分为共享空间和用户空间。共享空间，可被所有的任务同等访问，而用户空间只能被属于它的任务访问。

µT/OS不存在用户空间，只存在相当于T/OS的共享空间。

uT/OS2.6.2.非驻留内存

µT/OS不支持虚拟内存。因此，就不存在驻留内存和非驻留内存的概念。

T/OS内存分为驻留内存和非驻留内存，驻留内存通常在物理内存中，然而非驻留内存是基于虚拟内存基础上，被放置在磁盘等。

µT/OS只存在相当于T/OS的驻留内存。

uT/OS2.6.3.保护级别

T/OS中可以设置0～3四个内存保护级别。然而，在µT/OS中，假定没有MMU的，因此所有需要指定保护级别的地方都作为保护级别0处理。

T/OS中保护级别的处理规范中，保护级别0用于操作系统、子系统，保护级别1用于系统应用程序，保护级别2暂时保留，保护级别3用于用户应用程序。