在尋求獲得來自處理系統內的賽靈思Zynq?-7000全可編程SoC的最大利益，操作系統將讓你更不是一個簡單的裸機解決方案。任何開發ZYNQ SoC設計有大量的操作系統可供選擇，并根據最終應用程序，你可以選擇一個實時版本。一個RTOS是您最好的選擇，如果你是在工業，軍事，航空航天或在響應時間和可靠的性能要求，以防止生命或傷亡的，或者實現嚴格的績效目標等具有挑戰性的環境中使用的SoC ZYNQ。

為了得到一個感覺如何最好地實時操作系統添加到我們的ZYNQ SoC系統中，我們將使用最流行的實時操作系統之一左右，在μC/ OS-III Micrium的。這RTOS或更早的版本中它已經用在了一些非常令人興奮的系統，包括火星的好奇心流動站。目前最新的版本是在被認證為MISRA-C，DO178B A級，SIL3 / 4和IEC61508標準，這意味著它應該有一個廣泛的吸引力許多ZYNQ SoC的用戶的過程。但在此之前進入的實施細則，這是有幫助的審查實時操作系統的基礎知識。

什么是實時操作系統？

是什么讓一個實時操作系統與標準操作系統有何不同？井，一個實時操作系統是確定性的，這意味著該系統限定的期限內進行響應。這個決定可以是一個重要的原因，例如，如果最終應用正在監控工業過程，并具有以響應事件在指定的時間周期內，如將是一種用于工業控制系統中的情況。

RTOS進一步細分基于它們來滿足這些最后期限的能力。這種分類產生了三種不同類型的RTOS，其中每一個不同的地址的最后期限的概念。在硬的RTOS，缺少一個期限被看作是一個系統故障。這不是為公司RTOS，其中偶爾錯過截止時間是可以接受的情況。在軟的RTOS，同時，缺少一個期限減少的結果的有效性，但該系統作為一個整體能容忍此。

實時操作系統圍繞運行的任務（有時稱為工藝），其每一個執行所需功能的概念。例如，一個任務可能讀取數據通過接口或對這些數據進行操作。一個簡單的系統可以采用只有一個任務，但它更可能為多個任務，以在處理器上在任一時刻運行。這些任務之間的切換被稱為“上下文切換”，它要求與每個任務相關聯的處理器的狀態被存儲和添加到任務堆棧中。

確定的方法，其任務是下一個要運行是由內核（管理從軟件輸入/輸出請求，并將它們轉換成用于所述中央處理單元的數據處理的指令和在所述處理器的功能元件的RTOS的核心）來控制。任務調度可以是復雜的，特別是如果我們希望避免死鎖的狀態，其中兩個或多個任務鎖定彼此出來。的兩個基本方法是時間共享和事件驅動的。分時，每個任務獲取處理器上的專用時隙。更高優先級的任務可以被分配多個時隙。此時間片是通過常規的中斷或定時器控制，并且通常被稱為“round-robin調度”。隨著一個事件驅動的溶液，任務只切換，當一個具有較高優先級的運行必需的。這通常被稱為“搶占式調度”。

死鎖，資源共享和饑餓

當兩個或多個進程需要使用相同的資源，如UART，ADC或DAC-它有可能為他們的同時請求該資源。在這種情況下，訪問需要為了防止爭用被控制。這是如何管理是很重要的。如果沒有正確的管理，問題，如“死鎖”或“饑餓”可能發生，從而導致系統故障。

死鎖當一個進程持有一個資源而無法釋放它發生，因為它是無法完成的任務。它要求當前正由另一個過程中的另一個的資源。由于該系統將保持在該狀態下無限期地，該應用程序被認為是僵持。你可以想像，僵局是一個實時操作系統發現自己在一個糟糕的情況。

發生饑荒時，一個進程無法運行，因為它需要的資源總是分配給另一個進程。

這可能不會令你感到驚訝地聽到，已經出現了很多東西寫就這些問題，多年來，有很多提出的解決方案，如德克爾的算法，一個經典的修復程序并發編程的互斥問題。最常用的方法來處理這些情況下是信號量，這通常是兩種類型的二進制信號和計數信號量的。

一般地，每個資源有分配給它的一個二進制信號。一個請求進程將等待資源執行之前變得可用。一旦任務完成，請求進程將釋放資源。這些信號量通常被稱為WAIT和SIGNAL操作。一個進程將等待一個信號量。如果資源是自由的，該過程將被考慮到資源的控制，它會運行，直到完成，此時它會SIGNAL完成。然而，如果當處理等待對信號執行的資源已被占用，則該過程將被掛起，直到資源變得自由。這可以盡快當前正在執行的處理結束發生，但有可能是一個較長的等待，如果這個過程是由較高優先級的一個進程搶占。一類特殊的名為互斥體（從術語“互斥”派生）二進制信號量經常被用來防止優先級反轉。

計數信號以同樣的方式作為二進制信號量的工作，但它們被使用時，一個特定類型的資源的一個以上的實例是可用的（例如，數據存儲）。由于每個資源被分配給一個過程，計數被減小，以顯示剩余的可用資源的數量。當計數到達零，有沒有更多的可用資源，并且請求進程將被掛起，直到資源之一被釋放。

它往往是必要的過程來與彼此通信。有多種方法可以采用，這是最簡單的是，如上所述，以使用一個數據存儲和信號。更復雜的技術包括消息隊列。有了消息隊列，當一個進程希望將信息發送到另一個進程，它發布消息隊列。當一個進程希望從一個隊列中接收消息時，它會掛起隊列。因此，消息隊列工作就像一個FIFO（先入先出）存儲器。

在μC/ OS-III操作系統

Micrium的μC/ OS-III是一個搶占式RTOS，這意味著它會一直運行具有最高優先級的準備執行任務。在將其加入ZYNQ SoC系統設計的第一步是從Micrium的網站下載了μC/ OS-III的RTOS。一旦你這樣做，安裝非常簡單。你只需要你安裝的Xilinx提取下您的計算機上的幾個ZIP文件到正確的文件夾（目錄）。

請確保您提取名為Zynq-7000-ucosiii-bsp.zip ZIP文件到您的 ISE_DS EDK 軟件 lib目錄 BSP 文件夾中。你會看到一些其他的操作系統這個文件夾下，包括獨立和xilkernel的。接下來，提取名為Zynq-7000-ucosiii-demo.zip ZIP文件到您的 ISE_DS EDK 軟件 lib目錄 sw_apps 文件夾，如圖1。再次，你會看到一些其他的應用演示中此文件夾。

圖1：顯示演示文件的位置的目錄結構

無需安裝這兩套文件，我們準備開始軟件開發工具包（SDK）中創建我們的項目。我們將使用之前創建相同的基本硬件，但我們需要一個新的應用程序和板級支持包（BSP），因為我們希望包括操作系統。

在SDK中，關閉所有打開的項目，除了基本硬件設計。接下來，選擇文件>新建>應用程序項目的選擇，給新的項目名稱并選擇操作系統μC/ OS-III（見圖2）。然后選擇μC/ OS-III的演示應用程序（見圖3）

圖2：選擇操作系統

圖3：選擇μCOS-III演示

當你快樂時，單擊Finish按鈕。應用程序和板級支持包（如果你選擇該選項）將在SDK中創建。如果您選擇了自動生成選項，你可能會發現一些錯誤的報道。這是因為不是所有的項目引用是正確的呢。要設置這些項目引用，您需要導入的演示設置，你會發現項目>來源>設置選項下。在這個XML文件右鍵單擊并查看屬性。這將允許您選擇和復制該文件的位置，如圖4所示。

圖4：獲取正確的設置

一旦你復制這個位置，在項目右鍵單擊并選擇屬性。在標題C / C ++一般，選擇路徑和符號的選擇。然后選擇導入設置和設置文件的位置粘貼。

同樣重要的是，以確保存儲庫正確指向前面添加的庫。您可以通過設置賽靈思工具>存儲庫，它應該顯示在您的μC/ OS-III BSP以前安裝的位置檢查這些。

因為我們希望使用的UART輸出的狀態演示，正在顯示出完成初始化和運行任務，則可能需要設置標準輸入和標準輸出到UART下的BSP設置。

經執行這些操作，你會看到，現在可以建項目。但是，仍然會有一些警告，如果你想在你的硬件上運行這個項目，將無法達到演示指出它應該。這是因為警告了未申報的功能。包括bsp.c文件中下面的語句應該糾正這個問題。

有一次，我添加了這個“有”頭文件，該項目建成并運行按預期在我的ZedBoard（見我的YouTube視頻）。#include“xil_cache.h”

啟動和運行

在拿到例如啟動和運行，你現在有信心，RTOS已經在系統上正確實施。現在，您可以繼續正確地執行對ZYNQ SoC的軟件設計。一旦你創建了軟件應用和工程團隊已經準備好嘗試一下硬件，可以在完全相同的方式創建一個編程文件，你會為裸機系統（參見Xcell雜志問題83，“如何配置您的SoC ZYNQ裸機解決方案“），能夠與RTOS的應用程序啟動和配置存儲器執行。