2010年4月28日 星期三

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




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

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




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



1.    WindowsLinux皆可以使用,具有平台轉移性。



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不同是共用,所以不用保護也可以正常使用。但各Taskrandom()產出的數列完全相同,在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[]Win32APIThread Handle。此二個變數要改用Stack做為存放的地方,故資料結構要做變動。



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



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



實作驗證是成功的。









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

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

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

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

沒有留言:

張貼留言