1.在uC/OS-II的幫助手冊內，作者特地強調絕對不能在OSInit（）或者OSStart（）內
調用Timer初始化程序，那會破壞系統(tǒng)的可移植性同時帶來性能上的損失。
所以，一個折中的辦法就是：
在優(yōu)先級最高的程序內調用，這樣可以保證當OSStart（）調用系統(tǒng)內部函數(shù)
OSStartHighRdy（）開始多任務后，首先執(zhí)行的就是Timer初始化程序。或者
專門開一個優(yōu)先級最高的任務，只做一件事情，那就是執(zhí)行 Timer初始化，
之后通過調用OSTaskSuspend（）將自己掛起來，永遠不再執(zhí)行。不過這樣會
浪費一個TCB空間。對于那些RAM吃緊的系統(tǒng)來說，還是不用為好。
2.（三） 一些重要的uC/OS-II API介紹
任何一個操作系統(tǒng)都會提供大量的API供程序員使用，uC/OS-II也不例外。由于uC/OS-II面向
的是嵌入式開發(fā)，并不要求大而全，所以內核提供的API也就大多和多任務息息相關。
主要的有以下幾類：
１）任務類
２）消息類
３）同步類
４）時間類
５）臨界區(qū)與事件類
我個人認為對于初級程序員而言，任務類和時間類是必須要首先掌握的兩種類型的API.
下面我就來介紹比較重要的：
１）OSTaskCreate函數(shù)
這個函數(shù)應該至少再main函數(shù)內調用一次，在OSInit函數(shù)調用之后調用。作用就是創(chuàng)建
一個任務。目前有四個參數(shù)，分別是任務的入口地址，任務的參數(shù)， 任務堆棧的首地址和
任務的優(yōu)先級。調用本函數(shù)后，系統(tǒng)會首先從TCB空閑列表內申請一個空的TCB指針，然后
將會根據(jù)用戶給出參數(shù)初始化任務堆棧，并在內部的任務就緒表內標記該任務為就緒狀態(tài)。
最后返回，這樣一個任務就創(chuàng)建成功了。
２）OSTaskSuspend函數(shù)
這個函數(shù)很簡單，一看名字就該明白它的作用，它可以將指定的任務掛起。如果掛起的是
當前任務的話，那么還會引發(fā)系統(tǒng)執(zhí)行任務切換先導函數(shù)OSShed來進行一次任務切換。
這個函數(shù)只有一個參數(shù)，那就是指定任務的優(yōu)先級。那為什么是優(yōu)先級呢？事實上在系統(tǒng)
內部，優(yōu)先級除了表示一個任務執(zhí)行的先后次序外，還起著分別每一個任務的作用，換句話
說，優(yōu)先級也就是任務的ID.所以uC/OS-II不允許出現(xiàn)相同優(yōu)先級的任務。
３）OSTaskResume函數(shù)
這個函數(shù)和上面的函數(shù)正好相反，它用于將指定的已經(jīng)掛起的函數(shù)恢復成就緒狀態(tài)。如果
恢復任務的優(yōu)先級高于當前任務，那么還為引發(fā)一次任務切換。其參數(shù)類似 OSTaskSuspend
函數(shù)，為指定任務的優(yōu)先級。需要特別說明是，本函數(shù)并不要求和OSTaskSuspend函數(shù)成對使
用。
４）OS_ENTER_CRITICAL宏
很多人都以為它是個函數(shù)，其實不然，仔細分析一下OS_CPU.H文件，它和下面馬上要談到的
OS_EXIT_CRITICAL都是宏。他們都是涉及特定 CPU的實現(xiàn)。一般都被替換為一條或者幾條
嵌入式匯編代碼。由于系統(tǒng)希望向上層程序員隱藏內部實現(xiàn)，故而一般都宣稱執(zhí)行此條指
令后系統(tǒng)進入臨界區(qū)。其實， 它就是關個中斷而已。這樣，只要任務不主動放棄CPU使用權，
別的任務就沒有占用CPU的機會了，相對這個任務而言，它就是獨占了。所以說進入臨界區(qū)了。
這個宏能少用還是少用，因為它會破壞系統(tǒng)的一些服務，尤其是時間服務。并使系統(tǒng)對外界響
應性能降低。
５）OS_EXIT_CRITICAL宏
這個是和上面介紹的宏配套使用另一個宏，它在系統(tǒng)手冊里的說明是退出臨界區(qū)。其實它就
是重新開中斷。需要注意的是，它必須和上面的宏成對出現(xiàn)，否則會帶來意想不到的后果。
最壞的情況下，系統(tǒng)會崩潰。我們推薦程序員們盡量少使用這兩個宏調用，因為他們的確會
破壞系統(tǒng)的多任務性能。
６）OSTimeDly函數(shù)
這應該程序員們調用最多的一個函數(shù)了，這個函數(shù)完成功能很簡單，就是先掛起當起當前任務，
然后進行任務切換，在指定的時間到來之后，將當前任務恢復為就緒狀態(tài)，但是并不一定運行，
如果恢復后是優(yōu)先級最高就緒任務的話，那么運行之。簡單點說，就是可以任務延時一定時間
后再次執(zhí)行它，或者說，暫時放棄CPU的使用權。一個任務可以不顯式的調用這些可以導致放棄CPU使用權的API，但那樣多任務性能會大大降低，因為此時僅僅依靠時鐘機制在進行任務切換。一個好的任務應該在完成一些操作主動放棄使用權，好東西要大家分享嘛！
3.我們推薦程序員們盡量少使用OS_ENTER_CRITICAL宏和 OS_EXIT_CRITICAL宏兩個宏調用，
因為他們的確會破壞系統(tǒng)的多任務性能。why？？
4.在以uC/OS為操作系統(tǒng)的項目中，系統(tǒng)可能要處理各種不同的中斷請求，如果某個中斷處理
程序需要調用uC/OS的各種Post函數(shù)向任務發(fā)出消息，那么uC/OS建議中斷服務程序的寫法是：
1、保存全部CPU寄存器
2、調用OSIntEnter或OSIntNesting直接加1
3、執(zhí)行用戶代碼做中斷服務
4、調用OSIntExit
5、恢復所有CPU寄存器
6、執(zhí)行中斷返回指令
暫且稱為“標準中斷”方式，這種方式實際上是將這個中斷處理加入了任務調度系統(tǒng)，也就是
說這個中斷可以引起任務的切換。
如果在中斷處理中沒有調用各種Post函數(shù)的話，則可以用一般的、象原來沒有操作系統(tǒng)時的
寫法：
1、保存中斷處理程序需要用到的CPU寄存器
2、執(zhí)行中斷處理
3、恢復保存了的CPU寄存器
4、執(zhí)行中斷返回指令
暫且稱為“快中斷”方式，按照這種方法定義的中斷永遠不會引起任務切換。
在uC/OS系統(tǒng)中，每個任務都要定義獨立的棧空間，一個棧空間的使用包括5個部分：
1、任務包括的各個函數(shù)的調用返回地址
2、任務包括的各個函數(shù)中可能在棧上分配的局部變量
3、發(fā)生了“標準中斷”方式定義的中斷或任務被掛起時，所要保存的任務上下文
4、發(fā)生了“快中斷”方式定義的中斷時，中斷處理程序所需要的棧空間
5、中斷嵌套時，所要保存的中斷嵌套上下文
在這些使用的部分中，1，2，3，4的內存占用量是比較容易估算的，最精確和保險的確定
方法是：查看由C生成的asm文件，并計算各個函數(shù)的棧使用量。但是第5部分的棧空間使用
量是隨中斷嵌套的深度而不斷增加的，是不確定的，一般的方法只能定義一個充分大的棧
空間，使之不會溢出。
為每個任務都定義一個充分大的棧空間，這在某些內存稀缺的小項目中是非常痛苦的，
有時不得不增擴內存，這就會使成本增加。
我深入研究了uC/OS后，認為，可以將所有任務棧空間使用的第5部分合并，這樣將會大大的
降低整個系統(tǒng)對內存的需求。
uC/OS的任務調度是靠OS_Sched和 OSIntExit來完成的，這兩個函數(shù)中都要先判斷一個叫
OSIntNesting的系統(tǒng)變量，如果OSIntNesting不為0，則不進行任務切換。也就是說：
在OSIntNesting為1（當前只有一個中斷在處理中，并且沒有嵌套的中斷）時起，
如果發(fā)生了嵌套的中斷（不管嵌套的層數(shù)有深），那么在所有嵌套的中斷一層一層地都返回
直到 OSIntNesting再次為1時止，任務棧是不會切換的（棧指針都在一個任務的棧空間中變
化）。
據(jù)此，我們可以這樣改動：設置一個緩沖區(qū)OSInterruptStk，作為嵌套中斷的棧空間
由所有任務共享，中斷服務程序改為：
1、保存全部CPU寄存器
2、調用OSIntEnter或OSIntNesting直接加1
增加：2.1、判斷OSIntNesting是否等于1，如果不是則轉到3
增加：2.2、將棧指針SP保存到OSTCBCur->OSTCBStkPtr
增加：2.3、將SP指向OSInterruptStk的棧頂（注意棧增長的方向）。
3、執(zhí)行用戶代碼做中斷服務
4、調用OSIntExit
增加：4.1、判斷OSIntNesting是否等于0，如果不是則轉到5
增加：4.2、從OSTCBCur->OSTCBStkPtr中恢復棧指針SP
5、恢復所有CPU寄存器
6、執(zhí)行中斷返回指令
并且要修改OSIntCtxSw函數(shù)，原始的OSIntCtxSw函數(shù)的寫法是：
1、調整棧指針來去掉在調用：OSIntExit，OSIntCtxSw過程中入棧的多余內容
2、將當前任務棧指針保存到OSTCBCur中（OSTCBCur->OSTCBStkPtr = __SP__）
3、如果需要則調用OSTaskSwHook
4、OSTCBCur = OSTCBHighRdy
5、OSPrio = OSPrioHighRdy
6、從OSTCBCur中恢復棧指針（__SP__ = OSTCBCur->OSTCBStkPtr）
7、恢復保存了的CPU寄存器
8、執(zhí)行中斷返回指令
新的寫法只需將原寫法中的1，2去掉即可，因為1，2步只是保存舊任務的棧指針，而新的寫
法中，這些步被移到了“中斷服務程序”中的2.2.
5.注意arm Image for uCOSII for lpc213x 模板中的TargetInit（）
對于很多使用ZLG arm Image for uCOSII for lpc213x 模板的初學者，常常會置疑使用該模板
后自動生成的target.c文件，和在程序中調用的TargetInit（）函數(shù)，我和 Zgpswh都是如此，這
個問題當初困擾了很久：當用戶程序中不調用TargetInit（）時，發(fā)現(xiàn)內核能運行，但是等待機制
失靈，調用 TargetInit（），很多硬件中斷打不開，后來，在很多熱心人的指點下解決了，現(xiàn)重新
總結如下：
請仔細察看ZLG模板里的target.c文件，這里的TargetInit（）如下：
void TargetInit（void）
{
OS_ENTER_CRITICAL（）；
srand（（uint32）TargetInit）；
VICInit（）；
Timer0Init（）；
OS_EXIT_CRITICAL（）；
}
其中的Timer0Init（）；用于硬件定時器0的初始化，事實上，ZLG的移植代碼的μC/OS-Ⅱ的時鐘節(jié)拍是
通過定時器0提供的，不在主程序里調用這個函數(shù)，μC/OS-Ⅱ的時鐘源就無法打開；但是，沒有開啟
時鐘源的μC/OS-Ⅱ是同樣能運行的，只是內核提供的延時和等待時限機制都不起作用，系統(tǒng)雖能將
就運行，但因沒調用TargetInit（）而使內核功能不健全。
請注意，TargetInit（）中的另一個函數(shù)VICInit （）是用來中斷的初始化，它其中含有對UART0中斷的
分配，在用戶程序里需要根據(jù)使用的硬件中斷修改這部分代碼，否則，這些硬件中斷無法開啟；
再者，在不調用TargetInit（）的時候，硬件的中斷初始化是在硬件初始化函數(shù)中完成，
這也就是Zgpswh提到的現(xiàn)象：不調用TargetInit（）內核運行異常，調用了卻開不了UART0的中斷。
解決的方法如下：
這在《arm嵌入式系統(tǒng)基礎教程》的430頁7.4.3節(jié)中論述的很清楚：
……關鍵在于把程序與芯片相關中斷源掛接，使芯片在產(chǎn)生相應的中斷后會調用相應的處理程序。
這需要做兩方面事情：
1. 增加匯編接口的支持。……
2. 初始化向量中斷控制器。……
按照一下方法完成中斷源的的掛接：
1、增加匯編接口的支持。方法是修改IRQ.s文件，在末尾添加本句代碼：
UART0_Handler HANDLER UART0_Exception
追加定義了通用串口0 中斷句柄。
2、初始化向量中斷控制器。將target.c文件中的VICInit（）修改如下：
void VICInit（void）
{ extern void IRQ_Handler（void）；
extern void Timer0_Handler（void）；
extern void UART0_Handler（void）；
VICIntEnClr = 0xffffffff；
VICDefVectAddr =（uint32）IRQ_Handler；
VICVectAddr0 =（uint32）Timer0_Handler；
VICVectCntl0 =（0x20 | 0x04）；
VICIntEnable = 1<<4；
VICVectAddr14 =（uint32）UART0_Handler；
VICVectCntl14 =（0x20 | 0x06）；
VICIntEnable = 1<<6；
}
此為初始化向量中斷控制器。包括定時器0和串口0，特別要注意的是，一定不可以省略對定
時器0的初始化
中斷里，不可以調用延時
請注意，中斷里面是不支持等待機制的。請用自己編的一個軟件延時，問題就可以解決了。
中斷源掛接正確是沒問題的。
6.問
void TargetInit（void）
{
OS_ENTER_CRITICAL（）；
srand（（uint32）TargetInit）；
VICInit（）；
Timer0Init（）；
OS_EXIT_CRITICAL（）；
}
在此單獨用srand（）函數(shù)有什么作用（用了有什么好處，不用又會怎樣），一般srand（）用于
給rand（）設定種子（即srand給定rand運算式子的第一個值）。查了FAQ（P22）僅僅說明了
seed的譯文。
答2
你說的沒有錯，他就是用來設置隨機數(shù)的種子。
每次編譯一次，void TargetInit（void）函數(shù)在Ram或者Flash中的地址都不一樣
（即種子也不一樣）。如果你在程序中不用隨機函數(shù)rand（），那么srand（）
在這里對你來說是沒有意義的，如果你要用rand（），那么每次編譯程序后你的rand（）
產(chǎn)生的隨機數(shù)就不一樣。當然，你也可以自己種種子咯。
答3
srand（（uint32） TargetInit）；是初始化uc/os－ii隨機數(shù)函數(shù)rand（）；也就是說給隨機數(shù)一個基值，以后調用相關隨機數(shù)函數(shù)時，隨機數(shù)就在此基值的基礎上改變。
只要不調用rand（）函數(shù)，就可以去掉這句。
7.
在arm上移植操作系統(tǒng)有一點需要注意：建立任務的任務，最好不要做復雜的工作。
頻繁的訪問其他硬件或者做時序要求比較嚴的工作容易造成系統(tǒng)死機，希望大家多
多注意。我的做法是：將建立任務的任務，閑置起來，但是不能進入死循環(huán)。方法
是：利用一個空郵箱，讓任務無限期的等待，這樣可以實現(xiàn)與其他任務的切換。
8.//定義與編譯器無關的數(shù)據(jù)類型
typedef unsigned char BOOLEAN；//布爾變量
typedef unsigned char INT8U；//無符號8位整型變量
typedef signed char INT8S；//有符號8位整型變量
typedef unsigned short INT16U；//無符號16位整型變量
typedef signed 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位寬度
注：這里為什么用typedef，因為如果用#define，那么代碼中的每一個相應的類型都會被替代，
很有可能會出現(xiàn)問題，畢竟他只是一個替代的關系，且編譯時間會增加，而用typedef則不會，
它就相當于我們C++里面的引用，一樣的思維，在這里面就是說多了一個名稱。還有要注意的是
我們怎么知道unsigned char 就是無符號8位整型變量，可以arm公司里面下載ADS_CompilerGuide_D.PDF
文件，或者在你所裝的ADS1.2目錄里面有一個文件夾叫PDF，打開它就可