前段時間在ARM9 平臺上作基於 UC/OS-II的應用開發，遇到一個比較重要的問題，現在總結一下，便於日後回顧
關注點 ： 多任務調度的方式區別 （查詢+OSTimeDly 還是 基於事件驅動的方式，比如smei，flag等）
平臺設施： ARM9 + UC/OS-II
背景介紹： 首先有個引擎需要移植到我的系統中，下面簡稱該引擎爲emo，
emo需要有2個任務支持，簡稱任務T2，任務T2。 T1負責從一個buffer中獲取數據，
當獲取到的數據達到一定閾值m時，把獲取到的數據一下全部塞進emo中，
同時T2任務負責運算處理emo中的數據。但是T2該任務運行要求實時性比較高，
運算比較複雜，所以在應用設計的時候儘量不要去經常打斷 T2任務。
出題發生： 一開始T1任務設計方式是 採用查詢+OSTimeDly，結構如下
//T1 task ......
while(1)
{
while(1)
{
if 獲取數據達到閾值m
break
else
OSTimeDly(10)
}
append_data() //把數據塞進emo中
if 有其他任務需要刪除T1
刪除自己
else OSTimeDly(10)
}
解釋---整個task結構是通過不斷查詢+dly方式，這就存在一個問題，T1在沒有獲取到足夠的數據時
會不斷的Dly，在獲取到一定數據後，還是要不斷的Dly（除非要刪除自己了），但是在這過程中，
T2一直要跑的，而且需要實時性很高，那麼頻繁的Dly操作導致UC/OS調度很多次，這多少會影響到T2的執行，
同是當前系統做了一個頻率自動調節技術PM，即根據Dly的次數（大概是這樣）通過某算法可以得知當前需要
多大的頻率可以滿足應用程序。因爲頻繁的Dly造成PM上計算結果和實際情況相差較大，導致分配給應用的
頻率不夠，這2種情況共同導致了T2運行很不順暢，因爲T2運行受到阻礙，導致T1中取到的很多數據被丟失，
而T1數據的丟失更導致T2運算得到的結果錯誤，惡性循環了
現在換了寫法，採取事件方式，設置了一個Flag，
當buffer中數據達到m時，通過一個回調函數post該flag，T1中首先是pend該Flag如果err，則無限等待知道該flag被post，
什麼時候能等到從而使T1繼續往下運行呢，只能是buffer中數據達到m。當pend到有效的flag之後，T1再把獲取到的數據塞到emo中，
T2則計算處理emo中的數據，這樣寫不需要頻繁的查詢頻繁的Dly。T2的實時性也可以很好的保證，塞到emo中的數據也可以及時處理完，
不至於丟失有效數據。
... post flag //第一次時flag是有效的
while(1)
{
pend the flag //等待該flag，如果無效則一直等待下去
while(get_data(閾值，回調))
{
append_data //向emo中塞數據，供T2處理
}
if 有其他任務要刪除T1
刪除自己
else
OSTimeDly(10)
}
