最近Bee換筆記電腦是具有GeForce GT 420M的顯示卡。
現在都是安裝Windows 7 x64的版本。故Bee下載CUDA 64位元回來安裝。
到這裡都沒有問題。只有CUDA 64部分設定要自己手工調整。
之後有許多工具都很不習慣，花了不少時間去找。整個Windows和XP實在差太多了。
另外有一些其他奇怪的地方有些程式找不到裝置，原來還有UAC的問題。
好吧！看在64位元可以不受4GB限制，還是去適應好了 。
弄了數週，才想到回來看看CUDA程式。
結果，CUDA 64無法和Win32的OpenCV做Link。
而OpenCV沒有64位元的Library。那只好自己編函式庫了。
奇怪的是OpenCV2.1明明就有寫支援64位元，但一直編不出可以用的函式庫。
查過在其他平台都是可以用的。但在VS2008及VS2010就有問題。
沒錯！就是這個問題。但....沒有人解成功。
Bee又安裝了好幾次，沒一次成。查了很久，發現是沒有載入該有的函式庫。
為何！M$的C++老是玩這種，每次編出來的程式都很難搬。
最後沒辦法，回去Win32。安裝CUDA 32然後Link OpenCV，就過了。
再等OpenCV下一版再看看。
不過64位元整合算是失敗了。看來時代還沒有到。
還有很多應用軟體也都是在Win32模式下，沒有幾套是64位元。
要換到64位元，看來還是不容易取得優勢。反而是環境大改，真是不習慣。
2010年12月1日 星期三
2010年9月30日 星期四
YARP介紹
YARP全名Yet Another Robot Platform為人型機器人發展平台。主要目標是降低人型機器人發展的困難度。
機器人現行軟體發展的問題是，在硬體變化快速的狀況下，若是軟體一直要隨硬體而修改，將使機器人軟體發展不易。
但硬體的改變是必定會遭遇到，所以必須使高層軟體可以重覆利用。另外和硬體相關的程式必須模組化，以便於新硬體加入。
其實也有許多機器人發展平台，但都是綁語言或是綁硬體。YARP則是使用C++語言為基礎，並採用Open Source的開放架構。
另外在跨平台部分，採用CMake來達成不同作業系統平台上的移轉，例如使用同一個程式碼可以編譯成Linux,Windows及OS X的執行檔。
YARP設計為一層Middleware，所以可以使用其他語言來觸發。可以用一般Shell上發動的語言例如：Java、Perl、Python及TCL等。Matlab則可以利用Java做為界面觸發。
Bee看了一下YARP是如何達成如此多的語言可以連接，其實很簡單，就是將裝置做成檔案夾的方式。這個是Unix常用的模式，所以可以容易去連接。
而為了將同類裝置使用相同高階程式，則必項將不同啟動程式設定在像.ini檔案中，內容以XML做為描述語言。
對Bee來說有幾個地方是有興趣的。最重要的是在應用上，可以做為分散式嵌入式系統的發展平台，可以讓不同的機器統合而完成一個工作。
而且也有幾個模組也是Bee感興趣的，其中包括有CUDA、OpenCV、MPI及馬達控制。
看來是值得去研究的架構。
機器人現行軟體發展的問題是，在硬體變化快速的狀況下，若是軟體一直要隨硬體而修改，將使機器人軟體發展不易。
但硬體的改變是必定會遭遇到，所以必須使高層軟體可以重覆利用。另外和硬體相關的程式必須模組化，以便於新硬體加入。
其實也有許多機器人發展平台，但都是綁語言或是綁硬體。YARP則是使用C++語言為基礎，並採用Open Source的開放架構。
另外在跨平台部分，採用CMake來達成不同作業系統平台上的移轉，例如使用同一個程式碼可以編譯成Linux,Windows及OS X的執行檔。
YARP設計為一層Middleware，所以可以使用其他語言來觸發。可以用一般Shell上發動的語言例如：Java、Perl、Python及TCL等。Matlab則可以利用Java做為界面觸發。
Bee看了一下YARP是如何達成如此多的語言可以連接，其實很簡單，就是將裝置做成檔案夾的方式。這個是Unix常用的模式，所以可以容易去連接。
而為了將同類裝置使用相同高階程式，則必項將不同啟動程式設定在像.ini檔案中，內容以XML做為描述語言。
對Bee來說有幾個地方是有興趣的。最重要的是在應用上，可以做為分散式嵌入式系統的發展平台，可以讓不同的機器統合而完成一個工作。
而且也有幾個模組也是Bee感興趣的，其中包括有CUDA、OpenCV、MPI及馬達控制。
看來是值得去研究的架構。
2010年8月24日 星期二
最近CUDA程式上的進展
最新主要是改寫別人的CUDA程式。Open Source前幾版真是Bug百出，想找要好改的還要各方比較。
改寫除了解Bug外，也有一些問題要解決。
1.資源調度
最常拿到的是CUDA硬體1.3版的程式，剛好Bee又想用筆電跑，就要改成硬體1.1版。
這種狀況就要會做資源調度的程式改寫了。
2.改C++程式
Bee是C的使用者，C++不熟。不過遇到的算是原本CPU程式轉成CUDA之後造成的問題。
今天抓一個CUDA記憶體取用爆炸問題。追出來問題是長這樣：
原先使用物件只有建構函式，改寫為CUDA時，要在建構函式中取用CUDA記憶體，將資料轉到CUDA去。
後面也有其他函式使用CUDA上的資料運算。
處理單張照片時沒事，放到Webcam執行時，就產生記憶體不足。Bee也感到奇怪，1G的記憶體不夠用。
拿GPU-Z來看，真的用了1G。主要是每次處理照片，就會多出一些記憶體，是累積到爆的。
看程式還看不出問題，後來才發現，原來是建構時取用的CUDA記憶體沒釋放。
因為C++在物件使用完畢後，會自己釋放掉記憶體，所以很多人不寫解構函式。
可是改寫CUDA時，一樣在建構時取用CUDA的記憶體，自動解構時只會釋放CPU側。
而且相關的指標會釋放，在CUDA取用內的記憶體就變成沒人管的記憶體。
Bee加入解構，其內釋放CUDA記憶體，就這樣解決了。
CUDA還是用C的記憶體操作，不會自動回收。直接使用C++程式移植來的，這點還是要注意。
改寫除了解Bug外，也有一些問題要解決。
1.資源調度
最常拿到的是CUDA硬體1.3版的程式，剛好Bee又想用筆電跑，就要改成硬體1.1版。
這種狀況就要會做資源調度的程式改寫了。
2.改C++程式
Bee是C的使用者，C++不熟。不過遇到的算是原本CPU程式轉成CUDA之後造成的問題。
今天抓一個CUDA記憶體取用爆炸問題。追出來問題是長這樣：
原先使用物件只有建構函式，改寫為CUDA時，要在建構函式中取用CUDA記憶體，將資料轉到CUDA去。
後面也有其他函式使用CUDA上的資料運算。
處理單張照片時沒事，放到Webcam執行時，就產生記憶體不足。Bee也感到奇怪，1G的記憶體不夠用。
拿GPU-Z來看，真的用了1G。主要是每次處理照片，就會多出一些記憶體，是累積到爆的。
看程式還看不出問題，後來才發現，原來是建構時取用的CUDA記憶體沒釋放。
因為C++在物件使用完畢後，會自己釋放掉記憶體，所以很多人不寫解構函式。
可是改寫CUDA時，一樣在建構時取用CUDA的記憶體，自動解構時只會釋放CPU側。
而且相關的指標會釋放，在CUDA取用內的記憶體就變成沒人管的記憶體。
Bee加入解構，其內釋放CUDA記憶體，就這樣解決了。
CUDA還是用C的記憶體操作，不會自動回收。直接使用C++程式移植來的，這點還是要注意。
2010年8月17日 星期二
新寵物：蚯蚓
家中的寵物有二隻貓、二隻鳥以及一隻兔子。
最近Bee則買了蚯蚓來養。
一定會有人問，已有這麼多動物，為何要養蚯蚓？
因為Bee的如意算盤是：利用兔子糞養蚯蚓，產生有機土。若是蚯蚓過剩，則變成鳥的點心。
而貓糞則可能含有可傳染人的病源，所以不予利用。
結果進行了一個月，終於進行到投餵兔子糞的階段了。為何搞了一個月，就看以下報告了。
當初要養蚯蚓，也有想要將廚餘轉成堆肥。所以養殖箱和蚯蚓一到，馬上將家中廚餘全倒進養殖箱中裝滿。
這是錯的！後面災難就來了。
晚上蚯蚓大逃亡，結果白天就要揀蚯蚓。這才發現蚯蚓不喜臭味。
解決方法是加入新土，看看是不是增加活動空間可以解。
這招有點用，但箱子八分以上滿。不太能再放東西了。
接下來，另一個災難出現了，長了一堆蛆。
Bee不想養蠅蛆，因為它不會產生土壤。而且搶食能力大於蚯蚓，養料都被蛆吃掉了。
然後每天晚上帶著手電筒及筷子去夾蛆丟棄。
一個月後，找到了飼養箱製造商，買了新箱子，決定分箱養，順便除掉蛆。
滿箱的土，Bee弄了一下午沒弄完，最後變成三箱。
一箱是使用培養土做為基土，一箱是黏土加培養土，原始的箱子還有剩，就成了第三箱。
剛換土又是一次大逃亡，後來就穩定不逃了。
現在則是每天加料再蓋上新培養土，果然不再長蛆，但在分箱時仍有少量蛆。等長大點再除掉。
新箱中基土少多了，所以開始實驗投入不同種類及重量的食物。
果然開始照Bee的預期可以使用兔子糞了。
最近Bee則買了蚯蚓來養。
一定會有人問，已有這麼多動物，為何要養蚯蚓？
因為Bee的如意算盤是：利用兔子糞養蚯蚓，產生有機土。若是蚯蚓過剩，則變成鳥的點心。
而貓糞則可能含有可傳染人的病源，所以不予利用。
結果進行了一個月，終於進行到投餵兔子糞的階段了。為何搞了一個月，就看以下報告了。
當初要養蚯蚓，也有想要將廚餘轉成堆肥。所以養殖箱和蚯蚓一到，馬上將家中廚餘全倒進養殖箱中裝滿。
這是錯的！後面災難就來了。
晚上蚯蚓大逃亡，結果白天就要揀蚯蚓。這才發現蚯蚓不喜臭味。
解決方法是加入新土，看看是不是增加活動空間可以解。
這招有點用，但箱子八分以上滿。不太能再放東西了。
接下來，另一個災難出現了，長了一堆蛆。
Bee不想養蠅蛆，因為它不會產生土壤。而且搶食能力大於蚯蚓，養料都被蛆吃掉了。
然後每天晚上帶著手電筒及筷子去夾蛆丟棄。
一個月後，找到了飼養箱製造商，買了新箱子，決定分箱養，順便除掉蛆。
滿箱的土，Bee弄了一下午沒弄完，最後變成三箱。
一箱是使用培養土做為基土，一箱是黏土加培養土，原始的箱子還有剩，就成了第三箱。
剛換土又是一次大逃亡，後來就穩定不逃了。
現在則是每天加料再蓋上新培養土，果然不再長蛆，但在分箱時仍有少量蛆。等長大點再除掉。
新箱中基土少多了，所以開始實驗投入不同種類及重量的食物。
果然開始照Bee的預期可以使用兔子糞了。
2010年7月15日 星期四
即時作業系統是如何演進的
在小型MCU上面用的工作排程(Task Schedule)Bee整理了一下。
發現從使用硬體中斷，到即時作業系統(RTOS)之間有演進的程序。
1.Round-Robin:不使用中斷，只使用輪詢方式，做為排程。
2.Foreground/Background:只使用中斷，利用硬體排程。
3.Round-Robin with Interrupt:使用中斷及輪詢混合式排程。
4.Coroutine:將輪詢方式的排程改為經由軟體呼叫方式切換。並加入排程工作鏈，管理工作加入及移除。
5.Real-Time Operating System:現代即時作業系統，函式一下子增加了許多。工作切換可以利用設定事件(Event)方式，設定排程的條件。
前三種及RTOS在uCOS的書中有介紹，但Bee認為奇怪的是為何工作排程一下子變的如此複雜。
在使用中斷管理及現代作業系統之間，一定存在軟體可以管理，但又沒有強制切換的管理系統。
不幸的是，中間型式就像物種進化中的失落環節一樣，幾乎找不到資料。
後來才從Forth語言及Lua語言上找到Coroutine，Bee才確定有Coroutine這型排程管理系統存在。
以下就功能特性做一個比較：
1.Round-Robin:
特性：這是最簡單的排程系統，但時間控制不精準。
Task Control : Pulling
Time Function : Depend on assemble code or instruction delay
Data Exchange : Global variable
State Machine : Run on open loop，state control by data
2.Foreground/Background:
特性：將需要精準時間控制的工作放入中斷。
Task Control : Interrupt
Time Function : In interrupt using counter control function call
Data Exchange : User control with protected global variable
State Machine : Run on open loop，state control by data
要解決問題：變數保護問題，假設有一個函式如下。
int temp;
void swap( int *x, int *y)
{
temp = *x;
*x = *y;
*y = temp;
}
這個函式若由main()及中斷中都有使用到，則會發生變數衝突問題。這個問題則要由工程師自己注意。
3.Round-Robin with Interrupt:
特性：加入多種工作時，要改成這個結構。
Task Control : Interrupt/Pulling
Time Function : Interrupt Function/Interrupt Flag to Round-Robin Function
Data Exchange : User control with protected global variable/Global Variable
State Machine : Run on open loop，state control by data
4.Coroutine:
特性：加入工作管理，可以加入及移除工作項目
Task Control : O.S. Function/Interrupt
Time Function : Interrupt Function / O.S. Function
Data Exchange : Global Variable
State Machine : Program Structure Control
5.Real-Time Operating System:
特性：現在作業系統功能
Task Control : O.S. Function
Time Function : O.S. Function
Data Exchange : O.S. Function
State Machine : Program Structure Control
發現從使用硬體中斷，到即時作業系統(RTOS)之間有演進的程序。
1.Round-Robin:不使用中斷，只使用輪詢方式，做為排程。
2.Foreground/Background:只使用中斷，利用硬體排程。
3.Round-Robin with Interrupt:使用中斷及輪詢混合式排程。
4.Coroutine:將輪詢方式的排程改為經由軟體呼叫方式切換。並加入排程工作鏈，管理工作加入及移除。
5.Real-Time Operating System:現代即時作業系統，函式一下子增加了許多。工作切換可以利用設定事件(Event)方式，設定排程的條件。
前三種及RTOS在uCOS的書中有介紹，但Bee認為奇怪的是為何工作排程一下子變的如此複雜。
在使用中斷管理及現代作業系統之間，一定存在軟體可以管理，但又沒有強制切換的管理系統。
不幸的是，中間型式就像物種進化中的失落環節一樣，幾乎找不到資料。
後來才從Forth語言及Lua語言上找到Coroutine，Bee才確定有Coroutine這型排程管理系統存在。
以下就功能特性做一個比較：
1.Round-Robin:
特性：這是最簡單的排程系統，但時間控制不精準。
Task Control : Pulling
Time Function : Depend on assemble code or instruction delay
Data Exchange : Global variable
State Machine : Run on open loop，state control by data
2.Foreground/Background:
特性：將需要精準時間控制的工作放入中斷。
Task Control : Interrupt
Time Function : In interrupt using counter control function call
Data Exchange : User control with protected global variable
State Machine : Run on open loop，state control by data
int temp;
void swap( int *x, int *y)
{
temp = *x;
*x = *y;
*y = temp;
}
這個函式若由main()及中斷中都有使用到，則會發生變數衝突問題。這個問題則要由工程師自己注意。
3.Round-Robin with Interrupt:
特性：加入多種工作時，要改成這個結構。
Task Control : Interrupt/Pulling
Time Function : Interrupt Function/Interrupt Flag to Round-Robin Function
Data Exchange : User control with protected global variable/Global Variable
State Machine : Run on open loop，state control by data
4.Coroutine:
特性：加入工作管理，可以加入及移除工作項目
Task Control : O.S. Function/Interrupt
Time Function : Interrupt Function / O.S. Function
Data Exchange : Global Variable
State Machine : Program Structure Control
5.Real-Time Operating System:
特性：現在作業系統功能
Task Control : O.S. Function
Time Function : O.S. Function
Data Exchange : O.S. Function
State Machine : Program Structure Control
2010年7月11日 星期日
過時的工程師
前些時候Bee遇到了一位自製CPU的工程師，今年則是遇到開CPU的工程師。
Bee是曾經想自製CPU，所以要聊CPU可能可以找的人也不多，所以會談到一些市場的問題。
對他們來說，Bee算是自製CPU的逃兵。可是Bee早在數年前就覺得這個領域是不能再待的。因為市場快要過時了。
只是不到十年，就已成真。未來可以遇到的CPU可能不多了。
二個人我都問過一樣的問題：為何不改走別條路。回答的原因很多，但有一個共同的是，已投入十年以上的技術，不能放棄。
不過技術本來就會過時，科技業本就是如此！即使學有專精，還是有過時的一天。
但舊技術是不會消失，只是看人如何去用，如何加入新元素，找到新市場。
不過可以肯定的是，硬體為主的時代已過，現在走的是軟體服務時代。
現代軟體工程師也和以前不同，以前的軟體工程師會熟讀原始碼才使用，甚至改寫。現代的則是找Open Source直接用。
有些軟體開發環境已經和以前不同了。網路發達是主因，但軟體環境也變了許多。
除錯工具的精進，也改變了寫程式的生態。
有許多的函式庫可以用，不用再去做非常深入的了解。
不同時代，環境不同，所以生存機制不同。藉由以往成功的經驗是不一定能在新的環境下成功。
而且使用不對，反而會走向失敗。
人生沒有幾個十年，要如何走才是要好好考量的。
Bee是曾經想自製CPU，所以要聊CPU可能可以找的人也不多，所以會談到一些市場的問題。
對他們來說，Bee算是自製CPU的逃兵。可是Bee早在數年前就覺得這個領域是不能再待的。因為市場快要過時了。
只是不到十年，就已成真。未來可以遇到的CPU可能不多了。
二個人我都問過一樣的問題：為何不改走別條路。回答的原因很多，但有一個共同的是，已投入十年以上的技術，不能放棄。
不過技術本來就會過時，科技業本就是如此！即使學有專精，還是有過時的一天。
但舊技術是不會消失，只是看人如何去用，如何加入新元素，找到新市場。
不過可以肯定的是，硬體為主的時代已過，現在走的是軟體服務時代。
現代軟體工程師也和以前不同，以前的軟體工程師會熟讀原始碼才使用，甚至改寫。現代的則是找Open Source直接用。
有些軟體開發環境已經和以前不同了。網路發達是主因，但軟體環境也變了許多。
除錯工具的精進，也改變了寫程式的生態。
有許多的函式庫可以用，不用再去做非常深入的了解。
不同時代，環境不同，所以生存機制不同。藉由以往成功的經驗是不一定能在新的環境下成功。
而且使用不對，反而會走向失敗。
人生沒有幾個十年，要如何走才是要好好考量的。
2010年6月25日 星期五
用PC控制史賓機器人
這是Bee讀研究所科目之大作。因為做起來要打通的東西還真不少。
其實也是Bee當時重要研究所的夢想實現。
就概念上很簡單，就是希望可以寫程式遙控機器人動作。
機器人要重做很麻煩且沒有時間，因為這只是單一科目之專題。
所以找到"史賓機器人"。
這是它的遙控器
剛好又找到遙控器相關資料。很多已經失去連接了，目前可以找到的為
史賓機器人紅外線碼
實際量測結果無誤，所以我便規劃重製遙控器來做到遙控。
不過實現上最關鍵的是USB遙控器，主因是現行筆電已經沒有RS232可以用了。
在這方面則是採用Silicon Lab的C8051F340這個單晶片來解決。
所以整個系統架構為
使用單晶片不是問題，但Bee使用過各式怪單晶片，這次終於用到8051了，不過這是不是值得高興的事。
單晶片上手對Bee來說容易，倒是去除錯別人的系統，要花功夫了。
另外這也是第一次開發DLL給PC應用端程式。
之所以不使用單一應用程式，主要是測試靈活度，故採用Win32Forth做為PC端測試界面，另一方面寫出來的是中文的程式哦！
Bee記得一星期就做完了，其中確認推動信號強度不足就花了一天。
第一階段，將硬體及8051程式建造完畢。
第二階段，做DLL程式，因為這是第一次做，所以花的比較久。BCB 6和VC參數傳遞上有些定義差異花了許多時間。
第三階段，做系統串連測試，確認是無法動作。後來才查出是推動信號強度不足。所以又改了一下電路。
一做完，就先去FIG去展示，那時報告都還沒有寫。所以寫了點草稿就去報告了。
後來開學後修了uCOS-II的課，就把整個系統拿來做專題，重新改寫8051的部分，將uCOS-II放進去。
之所以是大作，其實是先在暑假就做完，上課才硬是把它轉成專題拿去交。比起上課後才想專題，自然做得更完備。
其實也是Bee當時重要研究所的夢想實現。
就概念上很簡單，就是希望可以寫程式遙控機器人動作。
機器人要重做很麻煩且沒有時間，因為這只是單一科目之專題。
所以找到"史賓機器人"。
這是它的遙控器
剛好又找到遙控器相關資料。很多已經失去連接了，目前可以找到的為
史賓機器人紅外線碼
實際量測結果無誤，所以我便規劃重製遙控器來做到遙控。
不過實現上最關鍵的是USB遙控器，主因是現行筆電已經沒有RS232可以用了。
在這方面則是採用Silicon Lab的C8051F340這個單晶片來解決。
所以整個系統架構為
使用單晶片不是問題，但Bee使用過各式怪單晶片，這次終於用到8051了，不過這是不是值得高興的事。
單晶片上手對Bee來說容易，倒是去除錯別人的系統，要花功夫了。
另外這也是第一次開發DLL給PC應用端程式。
之所以不使用單一應用程式，主要是測試靈活度，故採用Win32Forth做為PC端測試界面，另一方面寫出來的是中文的程式哦！
Bee記得一星期就做完了，其中確認推動信號強度不足就花了一天。
第一階段，將硬體及8051程式建造完畢。
第二階段，做DLL程式，因為這是第一次做，所以花的比較久。BCB 6和VC參數傳遞上有些定義差異花了許多時間。
第三階段，做系統串連測試，確認是無法動作。後來才查出是推動信號強度不足。所以又改了一下電路。
一做完，就先去FIG去展示，那時報告都還沒有寫。所以寫了點草稿就去報告了。
後來開學後修了uCOS-II的課，就把整個系統拿來做專題，重新改寫8051的部分，將uCOS-II放進去。
之所以是大作，其實是先在暑假就做完，上課才硬是把它轉成專題拿去交。比起上課後才想專題，自然做得更完備。
訂閱：
文章 (Atom)