【文章內(nèi)容簡介】 。在本課題中，使用 ADS 進行編 寫、編譯和初步調(diào)試程序。 串口調(diào)試工具在本課題后期的調(diào)試中，用串口線連接 PC 機和音頻系統(tǒng)，在程序中設(shè)置調(diào)試信息，使用串口調(diào)試工具，可以在 PC 機上看到相應(yīng)的調(diào)試信息。在調(diào)試過程開始之前，必須設(shè)置串口工作在 8 位，無奇偶校驗， 1 停止位，115200 波特率下（與軟件中串口模塊的波特率一致，否則，不能得到調(diào)試信息）。 小結(jié)本章首先簡要的介紹了本項目中給出本課題的總體設(shè)計目標，在對總體目標及系統(tǒng)功能進行需求分析的基礎(chǔ)上，提出了系統(tǒng)總體設(shè)計方案，并分析了系統(tǒng)軟件工作流程，最后簡要的介紹了系統(tǒng)開發(fā)的硬件環(huán)境及其軟件開發(fā)平臺。 第三章 uC/OSII 操作系統(tǒng)移植ARM 芯片獲得了許多實時操作系統(tǒng)(Real Time Operating System)供應(yīng)商的支持，比較知名的有：Windows CE、Linux、pSOS、VxWorks、Nucleus、ECOS、uC/OS 等。uC/OSII是著名的、源碼公開的實時 內(nèi)核，是 專為嵌入式系統(tǒng)應(yīng)用設(shè)計的，可用于各 類 8 位、16 位和 32 位單片機或 DSP。從 uC/OS 算起，該內(nèi)核己有 10 余年應(yīng)用史，在諸多領(lǐng)域得到了廣泛應(yīng)用。在本項目中，采用了 uC/OSII 實時操作系統(tǒng)[17][18][19]。 uC/OSII 簡介uC/OS 最早的版本叫做 COS，關(guān)于 uC/OS 的論文，分兩期連載在美國的“嵌入式系統(tǒng)編程”(Embedded System Programming)雜志的 1992 年第 5 期和第 6 期上，COS 的源碼放在該雜志網(wǎng)頁的留言版(BBS)上供用戶下載 。1992 年末，美國的 Ramp。D 出版社出版了， “Micro uC/OS The RealTime Kernel”一書， 書 中附有一張軟盤，是 uC/OS 的源代碼。該書后來成為一本暢銷書， 發(fā)行量突破了 15000 本。uC/OS 是基于優(yōu)先級的可剝奪型(Preemptive)實時 內(nèi)核，可裁剪、可固化。由于與硬件相關(guān)的代碼僅 200 行左右，并寫在兩個單獨的文件中，且注解很清楚，故很容易將 uC/OS 移植到其它類型的 CPU 上。在后來的幾年中，用戶紛紛將 uC/OS 移植到了各種 CPU 上，應(yīng)用領(lǐng)域涵蓋了如照相機、醫(yī)療器械、音響設(shè)施、發(fā)動機控制、網(wǎng)絡(luò)設(shè)備、高速公路電話、自動柜員機、工業(yè)機器人等行業(yè)和設(shè)備。到 1998 年，作者出了他的第二本書“uC/OSII The RealTime Kernel”，給 uC/OS 增加了一些新功能，對源碼進行了整理，說明得更詳盡，書的厚度也增加了 200 頁，Jean J. Labrosse 先生開通了 uC/OS 的商業(yè)網(wǎng)站，并不斷推出新版本。自此，uC/OSII 開始在各個 領(lǐng)域重裝上陣，大 顯身手。uC/OSII 產(chǎn)品在現(xiàn)代商業(yè)應(yīng)用非常廣泛，已被相關(guān)機構(gòu)證實 具有非常穩(wěn)定、可靠的性能，并成功 應(yīng)用于生命科學(xué)、航天工程等重大科研項目中。并且由于其極小的內(nèi)核，特別 適用于對程序代碼存儲空間要求極其敏感的嵌入式系統(tǒng)開發(fā)。 uC/OSII 是一款源碼公開的實時操作系統(tǒng)[20][21] ，真正支持多個任務(wù)同時運行，各個任 務(wù)有獨立的棧空間，并提供系統(tǒng)服務(wù)、中斷管理等功能。作 為一個實用的實時操作系統(tǒng)， uC/OSII 還具有以下特點：可移植性（Portable）、可固化（ROMable）、可裁剪（Scalable）、 搶占式（Preemptive）。教學(xué)系統(tǒng)已成功運行的 uC/OSII 系統(tǒng)是 Embest IDE for ARM 工具編譯調(diào)試通過的簡單內(nèi)核和用戶程序，使用 Embest IDE for ARM 可以 查看內(nèi)核的各種狀態(tài)，包括任務(wù)（Task）、隊列（Queue)、信號量（Semaphore）、郵箱（Mailbox ）、事件（ Event）、互斥量（Mutex）等；同時提供時間相關(guān)函數(shù)、?？臻g、內(nèi)存（Memory）申請和釋放等操作。在當(dāng)前各種嵌入式操作系統(tǒng)之中，uC/OSII 以其優(yōu)異的性能，在各大領(lǐng)域中得到了廣泛的應(yīng)用。uC/OS 和 uC/OSII 是專門為嵌入式應(yīng)用設(shè)計的實時操作系統(tǒng)內(nèi)核。注解得很詳細的源代碼有 200 頁，其中 95%左右是用 C 語言寫的，與 CPU 類型相關(guān)的代碼用 8088 的匯編語言寫成，不超過 200 行。 移植要求所謂移植，就是使一個實時內(nèi)核能在某個微處理器或微控制器上運行。為了方便移植，大部分的 uC/OSII 代碼 是用 C 語言寫的；但仍需要用 C 和匯編語言寫一些與處理器相關(guān)的代碼，這是因為 uC/OSII 在讀寫處理器寄存器時只能通過匯編語言來實現(xiàn)。由于 uC/OSII 在設(shè)計時就己 經(jīng)充分考慮了可移植性，所以 uC/OSII 的移植相對來說是比較容易的。要使 uC/OSII 正常運行，處理器必須滿足以下要求[22]：●處 理器的 C 編譯器能產(chǎn)生可重入代碼?？芍厝氲拇a指的是一段代碼可以被多個任務(wù)同時調(diào)用，而不必擔(dān)心會破壞數(shù)據(jù)。也就是說，可重入型函數(shù)在任何時候都可以被中斷執(zhí)行，過一段時間以后又可以繼續(xù)運行，而不會因為在函數(shù)中斷的時候被其他的任務(wù)重新調(diào)用，影響函數(shù)中的數(shù)據(jù)?！裨? 程 序 中 可 以 打 開 和 關(guān) 閉 中 斷 。 在 uC/OSII 中 ， 可 以 通 過OS_ENTER_CRITICAL()或者 OS_EXIT_CRITICAL()宏來控制系統(tǒng)關(guān)閉或者打開中斷，這需要處理器的支持。在 ARM7TDMI 的處理器上，可以設(shè)置相應(yīng)的寄存器來關(guān)閉或者打開系統(tǒng)的所有中斷?！裉?理器支持中斷，并且能產(chǎn)生定時中斷(通常在 10 至 100Hz 之間)。uC/OSII 是通過處理器產(chǎn)生的定時器中斷來實現(xiàn)多任務(wù)之間的調(diào)度的， ARM7TDMI 的處理器上可以產(chǎn)生定時器中斷?！?處理器支持能夠容納一定量數(shù)據(jù)(可能是幾千字節(jié))的硬件堆棧?！?處理器有將堆棧指針和其它 CPU 寄存器讀出和存儲到堆?；騼?nèi)存中的指令。uC/OSII 進行任務(wù)調(diào)度的時候，會把當(dāng)前任 務(wù)的 CPU 寄存器存放到此任務(wù)的堆棧中，然后，再從另一個任務(wù)的堆棧中恢復(fù)原來的工作寄存器， 繼續(xù)運行另一個任務(wù)。所以，寄存器的入棧和出棧是 uC/OSII 多任務(wù)調(diào)度的基礎(chǔ)。在本項目中，SG850 微處 理器完全符合上面要求，所以可以移植 uC/OSII。 uC/OS II 任務(wù)調(diào)度機制uC/OS II 總 是運行進入就 緒態(tài)任務(wù)中優(yōu)先級最高的那一個。確定任務(wù)優(yōu)先級的高低，下面該哪個任務(wù)運行的工作是由調(diào)度器（Scheduler）完成的。任 務(wù)級的調(diào)度是由函數(shù) OSSched()完成的，中斷級的調(diào)度是由另一個函數(shù) OSIntExt()完成的。 uC/OS II 任務(wù)管理機制任務(wù)可以是一個無限的循環(huán)，也可以在一次執(zhí)行完畢后被刪除掉。這里要注意的是，任務(wù)代碼并不是被真正的刪除了，而只是 uC/OSII 不再理會該任務(wù)代碼，所以 該任務(wù)代碼不會再運行。任務(wù)看起來與任何 C 函數(shù)一 樣，具有一個返回 類型和一個參數(shù)，只是它從不返回。任務(wù)的返回類型必須被定義成 void 型。在本 節(jié)中所提到的函數(shù)可以在 文件中找到。uC/OSII 可以管理多達 64 個任務(wù)，并從中保留了四個最高優(yōu)先級和四個最低優(yōu)先級的任務(wù)供自己使用，所以用戶可以使用的只有 56 個任務(wù)。任 務(wù)的優(yōu)先級越高，反映優(yōu)先級的值則越低。在最新的 uC/OSII 版本中，任務(wù)的優(yōu)先級數(shù)也可作為任務(wù)的標識符使用。 uC/OS II 的內(nèi)存管理機制在 ANSI C 中可以用 malloc()和 free()兩個函數(shù)動態(tài)地分配內(nèi)存和釋放內(nèi)存。但是，在嵌入式實時操作系統(tǒng)中，多次這樣做會把原來很大的一塊連續(xù)內(nèi)存區(qū)域，逐漸地分割成許多非常小而且彼此又不相鄰的內(nèi)存區(qū)域，也就是內(nèi)存碎片。由于這些碎片的大量存在，使得程序到后來連 非常小的內(nèi)存也分配不到。另外，由于內(nèi)存管理算法的原因，malloc ()和 free()函數(shù)執(zhí)行時間是不確定的。在 uC/OSII 中，操作系統(tǒng)把連續(xù)的大塊內(nèi)存按分區(qū)來管理。每個分區(qū)中包含有整數(shù)個大小相同的內(nèi)存塊，如圖 3. 1 ( a)所示。利用 這種機制，uC/OSII 對 malloc()和 free()函數(shù)進行了改進，使得它 們可以分配和釋 放固定大小的內(nèi)存塊。 這樣一來，malloc()和 free()函數(shù)的執(zhí) 行時間也就固定了。如圖 3. 1 (b)，在一個系統(tǒng)中可以有多個內(nèi)存分區(qū)。這樣，用戶的應(yīng)用程序就可以從不同的內(nèi)存分區(qū)中得到大小不同的內(nèi)存塊。但是，特定的內(nèi)存塊在釋放時必須重新放回它以前所屬的內(nèi)存分區(qū)。 顯然，采用這樣的內(nèi)存管理算法，上面的內(nèi)存碎片問題就得到了解決。圖 內(nèi)存分區(qū)示意圖 uC/OS II 的通信與同步機制任務(wù)之間共享數(shù)據(jù)和提供任務(wù)之間的通信，除了利用宏 OS_ENTER_ CRITICAL()和 OS_EXIT_CEITICAL() 來 關(guān) 、 開 中 斷 以 及 利 用 函 數(shù) OSSchedLock() 和OSSchedUnlock()對任務(wù)調(diào) 度函數(shù)上鎖和開鎖等方法外，還可以通過信號量、郵箱和信息隊列來完成通信。一個任務(wù)或者中斷服務(wù)子程序可以通過事件控制塊 ECB ( Event Control Blocks)來向另外的任務(wù)發(fā)信號。這 里，所有的信號都被看成是事件(Event) 。一個任務(wù)還可以等待另一個任務(wù)或中斷服務(wù)子程序給它發(fā)送信號。只有任務(wù)可以等待事件發(fā)生，中斷服務(wù)子程序是不能這樣做的。對于處于等待狀態(tài)的任務(wù)，可以給它指定一個最長等待時間，以此來防止因為等待的事件沒有發(fā)生而無限期的等下去。多個任務(wù)可以同時等待同一個事件的發(fā)生。在這種情況下，當(dāng) 該事件發(fā)生后，所有等待 該事件的任務(wù)中，優(yōu)先級最高的任務(wù)得到了該事件并進入就緒狀態(tài)，準備執(zhí)行。這里的事件，可以是信號量、郵箱或者消息隊列等。 uC/OSII 的移植步驟uC/OSII 的體系結(jié)構(gòu)[23][24]如圖 所示。在移植過程中，與 處理器相關(guān)的的代碼主要集中在 、 和 這三個文件中。 uC/OS中的任務(wù)總是處于睡眠態(tài)、就緒態(tài)、運行 態(tài)、等待狀態(tài)和中斷服務(wù)態(tài) 5 種狀態(tài)之一。任何任務(wù)必須首先創(chuàng)建處于就緒態(tài)之后才有可能運行，任務(wù)創(chuàng)建函數(shù) OSTaskCreate()和 OSTaskCreateExt()會初始化任 務(wù)的棧結(jié)構(gòu)，使堆?？雌饋砭拖駝倓偘l(fā)生過中斷一樣，所有寄存器保存在任務(wù)的堆棧之中。若要任 務(wù)恢復(fù)執(zhí)行，只需在最后 執(zhí)行一條中斷返回指令即可。在 uC/OSII 的移植文件 中，唯一必要的函數(shù)就是OSTaskStkinit()。該函數(shù)會在任務(wù)創(chuàng)建時被調(diào)用，用來初始化任務(wù)的堆棧結(jié)構(gòu)。在uC/OSII 的另一個移植文件 中，需要改寫 OSSstartHighRdy() 、OSCtxSW()、OSIntCtxSW()和 OSTickISR()4 個函數(shù)。圖 uC/OSII 體系結(jié)構(gòu)圖 文件相關(guān)配置這個文件中包含了一些需要根據(jù) CPU 的指令字長和硬件更改的定義。1． 定義與編譯器無關(guān)的數(shù)據(jù)類型typedef unsigned char BOOLEAN。 /*布爾變量*/typedef unsigned char INTBU。 /*無符號 8 位整型變 量*/typedef signed char INTBS。 /*有符號 8 位整型變量*/typedef unsigned short INT16U。 /*無符號 16 位整型變量*/typedefsigned short INT16S。 /*有符號 16 位整型變量*/typedef unsigned int INT32U。 /*無符號 32 位整型變量*/typedef signed int INT32S。 /*有符號 32 位整型變量*/typedef float FP32。 /*單精度浮點數(shù)(32 位長度) */typedef double FP64。 /*雙精度浮點數(shù) (64 位長度) */typedef INT32U OS_STK。 /*堆棧是 32 位寬度*/2． 堆棧單位因為處理器現(xiàn)場的寄存器在任務(wù)切換時都將會保存在當(dāng)前運行任務(wù)的堆棧中，所以 OS_STK 數(shù)據(jù)類型應(yīng)該是和處理器的寄存器長度一致的。typedef INT32U OS_STK。 /*堆棧是 32 位寬度*/3． 堆棧增長方向堆棧由高地址向低地址增長，這也是和編譯器有關(guān)的。當(dāng)進行函數(shù)調(diào)用時，入口參數(shù)和返回地址一般都會保存在當(dāng)前任務(wù)的堆棧中，編譯器的編譯選項和由此生成的堆棧指令就會決定堆棧的增長方向。define OS_STK_GROWTH 1 /*堆棧是從上往下長的*/4． 關(guān)閉中斷和打開中斷OS_ENTER_CRITICAL()宏被定義為 中的 ARMDisableInt()——關(guān)閉中斷；OS_EXIT_CRITICAL()宏被定 義為 中的 ARMEnableInt()——打開中斷。 文件相關(guān)配置這個文件包含一個和 CPU 結(jié)構(gòu)相關(guān)的任務(wù)堆棧初始化函數(shù)，以及用戶可以利用的一系列鉤子函數(shù)，可以處理特殊硬件擴展、 MMU、調(diào)試等之用。1． 任務(wù)堆棧的初始化每個任務(wù)都需要有自己的堆?？臻g，以便進行任務(wù)切換的時候能夠?qū)?dāng)時的處理器現(xiàn)場保存到任務(wù)的堆棧中去，在下一次執(zhí)行的時候能夠恢復(fù)出來。在每次進行處理器現(xiàn)場保存的時候，需要按照一定的順序進行堆棧操作，這個順序就是任務(wù)堆棧設(shè)計。任 務(wù)堆棧的設(shè)計是在任務(wù)初始化時進行的，主要是在堆棧增長方向上如何定義每個需要保存的寄存器位置。在 ARM 體系結(jié)構(gòu)中，處理器的現(xiàn)場通常是指{P