uCOS-II Win32 Port解析及改善 -- 4

將中斷改為其他程式觸發：

將中斷改由外部程式控制，其中Timer改為外部程式觸發可以改為可以”停格”的作業系統模擬，可以觀察各中斷程式是否有執行異常，或是驗證程式。結果如下：

改進資料傳輸：

資料傳輸功能主要是可以使uCOS-II可以模擬在大量資料輸入狀況下，測試程式是否正常，可以應用在有通信的狀況下，或有輸出入資料的狀況下，看程式對於資料處理的情況。也可以增加除錯的報告，將程式運作的各種狀況報告，增加對程式的除錯。實行則以選擇跨行程通信的方式來做，選擇使用Pipe。因為Pipe具有以下特性：

1.    在Windows及Linux皆可以使用，具有平台轉移性。

2.    以檔案呼叫方式做為資料傳輸的方式，容易理解函式的用法。

因為檔案呼叫也會停止Thread，故Pipe實現在uC/OS-II中亦要一個獨立Task才不會干擾到其他的Task。結果如下：

可以發現兩支應用程式的資料為完全一樣，證明有寫到uC/OS Win32 Port。而且可以設定在Server程式關閉時，Client端亦可同時關閉。

加入此功能可以實現以軟體模擬外部環境對uC/OS-II做輸出入測試。

其他問題及改善提議：

在Windows上模擬uC/OS仍和DOS上執行的uC/OS有些行為不同。

1.    random()行為不一樣：每一個Thread都有自己的random()的變數，和DOS不同是共用，所以不用保護也可以正常使用。但各Task的random()產出的數列完全相同，在DOS則完全不同。使得Win32 port模擬結果和DOS不同。

2.    Mutex功能使用後當機，經查原始碼，發現也是因為hTaskThread[]沒有同步更新造成。

若是將Win 32A PI Thread Handle放在TCB中管理也許可以解決，但要重新做核心除錯。其主要構想為：

1.        利用沒有用到的Stack做為Thread Handle存放地方，就可以經由TCB管理。而Stack在實體CPU會用到，但也不會亂改，所以是安全的。

2.        影響到函式有OSSchedulThread()及OSTCBInitHook()。

3.        需要修改的變數有二個hTaskThread[]及taskSuspended[]。

4.        taskSuspended[]是管理task是可以執行或是不可執行flag。

hTaskThread[]是Win32API的Thread Handle。此二個變數要改用Stack做為存放的地方，故資料結構要做變動。

5.        OSTCBInitHook()是向Win32API申請Thread Handle的函式，要改成Handle改存到pTcb->OSTCBStkPtr，taskSuspended[]標記亦一併存入。

6.        OSSchedulThread()則要改成取用Handle時改由OSTCBCur->OSTCBStkPtr中取出Win32API Thread Handle，taskSuspended[]標記亦一併取出。

實作驗證是成功的。

後記：在要發表這篇時，將舊程式拿出來Run時，結果是當機的。原因在於Bee換了一台雙核電腦。也就是原先在單核心上是可以正常執行。

也因這個原因，改善的部分延至今日發表。

因為已經找到當機原因，且有在研究解決方法了。

所以就再次發表。後面會加上新的版本。