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
• 實質：微控制器實時作業系統核心
• 目標系統：假設為32位單晶片的微控制器
• 設計方針：容易最佳化、容易學習、容易移植等

定義

uT/OS是微控制器實時作業系統核心。

1.1.定位

µT/OS是面向小規模嵌入式系統的實時作業系統核心，它的目標系統是假設為32位單晶片的微控制器，帶有有限的ROM/RAM，沒有MMU的系統等。因此，這個規範允許開發人員在小規模嵌入式系統上容易的進行最佳化和裁減。

1.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公司全球作業系統戰略合作夥伴。

1.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-Engine論壇的µT-Kernel的不同]

µT/OS合併了任務管理和任務相關的同步函式，合併後類別為任務管理函式。

µT/OS刪除了在µT-Kernel中的子系統定義和外設流設備驅動相關的所有功能。

µT/OS增加了啟動核心和退出核心的系統管理函式。

1.4.調整

µT/OS規範設計時考慮了和T/OS的兼容性。就是說，當在µT/OS和T/OS間移植程式時，規範要求僅僅使用通用函式，允許僅通過重新編譯和最小修改來移植程式，即使修改是必然的。所以，µT/OSl包含了一些對於一般系統不必要的功能。不管怎樣，如果定義了這個系統的子集，設備驅動程式和中間件等的分發和移植將被消弱。此外，如果按照目標系統不同必要的功能也不同的話，定義子集規範將是非常困難的。

在µT/OS中，產生子集的規範，比如基本分類等，沒有被定義。所有兼容µT/OS規範的OS必須實現所有的功能。然而，當合併µT/OS到目標系統時，可以刪除不必要的功能。就是說，OS供貨商應該支持規範中的所有功能，但用戶能夠選擇和使用僅僅必要的功能。

1.µT/OS基本概念

性質

uT/OS的特性描述。

2.1.基本術語的含義

2.1.1.關於實現的術語

1.實現定義(Implementation-defined)

這個詞條不是µT/OS規範中的標準，而是應該在每個具體的實現中定義。實現的細節應該在實現規範中詳細說明。在應用程式中，對於依賴實現定義條目的部分的移植性不能保證。

2.實現依賴(Implementation-dependent)

這個詞條說明在µT/OS規範中，隨著目標系統和操作條件的不同，行為也有差異。行為可能被具體的實現定義。實現的細節應該在實現規範中詳細說明。在應用程式中，對於依賴實現依賴條目的部分，基本上需要隨著移植而進行修改。

3.實現規範(ImplementationSpecifications)

這個文檔解釋了µT/OS在支持目標系統時，實現的細節等。當µT/OS為一個目標系統而被實現、調整、最佳化時，建議創建相應的實現規範。

2.1.2.其他基本術語的含義

1.任務（task）和調用任務（invokingtask）

並行程式執行的基本邏輯單元稱為“任務”。一個任務的程式是順序執行的；而不同任務的程式卻是並行執行的。從應用程式的觀點來看，此處的並行處理只是一個概念上的現象。實際上，它是通過核心控制任務間的時間共享來實現的。

進行系統調用的任務被稱為“調用任務”。

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

處理器執行的任務間的切換稱為“分派”（或任務分派）。用來實現分派的核心機制叫做“分派器”（或任務分派器）。

3.調度（Scheduling）和調度器（scheduler）

決定要執行的下一個任務的處理過程稱為“調度”（或任務調度）。用來實現調度的核心機制叫做“調度器”（或任務調度器）。通常，調度器的功能在系統調用處理過程中或分派器內實現。

4.上下文（context）

一個程式運行的環境通常被稱為“上下文”。若要說上下文完全一致，最起碼的條件是處理器的運行模式必須相同，並且堆疊空間（相同連續區域的一部分）必須一致。

請注意，上下文是一個應用程式立場上的概念。即便處理過程並不在同一個上下文中執行，而在實際執行中，這些上下文有時也會使用相同的處理器模式以及相同的堆疊空間。

5.優先權（precedence）

不同處理請求之間的、決定處理的先後次序的關係稱為“優先權”。在處理較低優先權任務的過程中，如有一個擁有更高優先權的處理請求發生，通常，擁有較高優先權的處理將先於其他處理執行。

[附加說明]

優先權（Priority）是應用程式分配的一個參數，用來控制任務或訊息處理的順序。而優先權（precedence）在這份規範中是用來明確處理執行的先後次序。任務間的優先權是由優先權來決定的。

2.2.任務狀態和調度規則

2.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：任務狀態轉換

2.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等待狀態釋放後任務執行的優先權

2.3.中斷處理

µT/OS規範中的中斷包括由設備引發的外部中斷和CPU異常產生的中斷。每箇中斷號都可定義一段中斷處理程式。中斷處理程式可設計成直接啟動，基本上無須作業系統的干預，或者通過一個高級語言的支持函式來啟動。

2.4.系統狀態

2.4.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：系統狀態的劃分

2.4.2.任務無關部分（Task-IndependentPortion）與準任務部分（Quasi-TaskPortion）

任務無關部分（中斷處理程式、時間事件處理程式等）的特點是，在即將進入任務無關部分（運行狀態）前鑑別正在運行的任務是無意義的，在此並不存在“調用任務”的概念。因此，一個進入等待狀態的系統調用（函式），或者是發布時隱含地指明調用任務的系統調用（函式）都不能在任務無關部分（運行狀態）中調用。而且，由於在任務無關部分（運行狀態）中不能鑑別當前運行的任務，所以將不會有任務切換（分派）發生。

如果有必要產生（任務）分派，那么它將被延遲，直至任務退出任務無關部分（運行狀態）。這種情形被稱為延遲分派（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：中斷嵌套與延遲分派

2.5.對象

“對象”是對µT/OS所處理的資源的一個統稱。除了任務之外，對象還包含了記憶體池、信號量、事件標誌、信箱以及其他同步和通信機制，如時間事件處理程式（周期處理程式和報警處理程式）等。

對象的屬性通常在它建立時設定。屬性決定了對象行為和對象初始狀態等細節上的差別。當某對象的TA_XXXXX（屬性）被設定時，該對象將被稱為“帶TA_XXXXX屬性的對象”。如果沒有特別需要定義的屬性，那么將設定為TA_NULL（=0）。一般情況下，對象在註冊後都不會提供讀取其屬性的接口。在對象或者處理程式屬性的值中，低位用來指定系統的屬性，高位用來指定與具體實現方案相關的屬性。µT/OS規範並未指定區分高位和低位的位所在的位置。原則上，系統的屬性都從最低位（LSB）向最高位（MSB）來放置，而具體實現方案相關的屬性從最高位向最低位來放置。而未被用於定義屬性的位將被清0。

某些情況中，一個對象可以包含擴展信息。擴展信息在對象註冊的時候指定。對象開始執行時，擴展信息對µT/OS的操作無影響；擴展信息可通過調用一個對象狀態查詢系統調用（函式）來讀取。

每個對象都由一個數字ID來標識。在µT/OS中，數字ID不能被用戶指定，而是在對象建立時自動分配的。因此，對於調試來說，會有些困難。因為這個原因，在建立對象時，用戶可以指定對象的名稱用於調試。這個名稱僅僅用於調試，也僅僅能夠被調試支持函式訪問。µT/OS並不會檢查對象的名稱。

2.6.記憶體

2.6.1.地址空間（AddressSpace）

µT/OS僅僅有單一的地址空間。就是說，所有的任務和任務無關部分總是訪問同樣的地址空間。

[和T/OS的不同]

T/OS的地址空間被劃分為共享空間和用戶空間。共享空間，可被所有的任務同等訪問，而用戶空間只能被屬於它的任務訪問。

µT/OS不存在用戶空間，只存在相當於T/OS的共享空間。

2.6.2.非駐留記憶體（NonresidentMemory）

µT/OS不支持虛擬記憶體。因此，就不存在駐留記憶體和非駐留記憶體的概念。

[和T/OS的不同]

T/OS記憶體分為駐留記憶體和非駐留記憶體，駐留記憶體通常在物理記憶體中，然而非駐留記憶體是基於虛擬記憶體基礎上，被放置在磁碟等。

µT/OS只存在相當於T/OS的駐留記憶體。

2.6.3.保護級別（ProtectionLevels）

T/OS中可以設定0～3四個記憶體保護級別。然而，在µT/OS中，假定沒有MMU的，因此所有需要指定保護級別的地方都作為保護級別0處理。

[和T/OS的不同]

T/OS中保護級別的處理規範中，保護級別0用於作業系統、子系統，保護級別1用於系統應用程式，保護級別2暫時保留，保護級別3用於用戶應用程式。