一家公司待了十年。要離開還是有一點點不捨。
但,為了走更好的路,只能選擇離開。
朝下一個目標前進!
2011年7月19日 星期二
2011年7月6日 星期三
x64下安裝OpenCV2.3+CUDA
災難!
一定有人問,Bee為何裝完馬上升級。
因為,Bee要的功能是壞的啊!查了一下,發現OpenCV2.2滿是Bug。
Bee想主因是一口氣加入太多東西,GPU和X64一次加入的結果。
然後在一連串找尋中,Bee發現了OpenCV2.3可以解決問題,然後一看,11小時前更新,還是熱的啊!
OpenCV2.3需要CUDA4.0及VS2010,天啊!一切要重裝。
好! 就重裝。那就先移除CUDA3.2及VS2008。
接下來安裝顯示卡Driver,然後重開機。
再來是裝VS2010、SP1及Nsight2.0。
然後是CUDA SDK4.0,接下來就有問題了。
竟然無法編譯!少了cutil64D.lib。查了一下,好像要自己編出來。Bee邊查邊找就半小時過去了。
去\NVIDIA GPU Computing SDK 4.0\CUDALibraries下打開CUDALibrariesSDK_vs2010.sln編一次。
總算得到cutil64D.lib,然後移去要用的地方。
再來又少了shrUtils64D.lib,而且缺檔案stopwatch.cpp及stopwatch_win.cpp。
這二個檔在\NVIDIA GPU Computing SDK 4.0\C\common\src。
先從專案中移除錯的連接,再加入正確的。
總算可以用了。
最後把x64、W32、Debug及Release全部各編一次,放好備用。
可以裝OpenCV2.3了。
使用OpenCV-2.3.0-win-superpack.exe解開來。
用CMake重做一次,這次就沒有問題了。
沒想到這次是CUDA比較難裝。
不過x64模式OpenCV+CUDA總算全部搞定。
一定有人問,Bee為何裝完馬上升級。
因為,Bee要的功能是壞的啊!查了一下,發現OpenCV2.2滿是Bug。
Bee想主因是一口氣加入太多東西,GPU和X64一次加入的結果。
然後在一連串找尋中,Bee發現了OpenCV2.3可以解決問題,然後一看,11小時前更新,還是熱的啊!
OpenCV2.3需要CUDA4.0及VS2010,天啊!一切要重裝。
好! 就重裝。那就先移除CUDA3.2及VS2008。
接下來安裝顯示卡Driver,然後重開機。
再來是裝VS2010、SP1及Nsight2.0。
然後是CUDA SDK4.0,接下來就有問題了。
竟然無法編譯!少了cutil64D.lib。查了一下,好像要自己編出來。Bee邊查邊找就半小時過去了。
去\NVIDIA GPU Computing SDK 4.0\CUDALibraries下打開CUDALibrariesSDK_vs2010.sln編一次。
總算得到cutil64D.lib,然後移去要用的地方。
再來又少了shrUtils64D.lib,而且缺檔案stopwatch.cpp及stopwatch_win.cpp。
這二個檔在\NVIDIA GPU Computing SDK 4.0\C\common\src。
先從專案中移除錯的連接,再加入正確的。
總算可以用了。
最後把x64、W32、Debug及Release全部各編一次,放好備用。
可以裝OpenCV2.3了。
使用OpenCV-2.3.0-win-superpack.exe解開來。
用CMake重做一次,這次就沒有問題了。
沒想到這次是CUDA比較難裝。
不過x64模式OpenCV+CUDA總算全部搞定。
2011年7月3日 星期日
OpenCV2.2+CUDA x64模式編譯成功
使用OpenCV2.2版,用CUDA 3.2版。
因為改用CMake所以很不習慣。
裝了半天,才發現需要NPP函式庫。
NPP函式庫也要用64位元。
用VS2010編也不行,還退回去VS2008。
總算把hog_gpu給編出來了。
再來,要經由CMake重做。變得太快,不知要弄多久。
因為改用CMake所以很不習慣。
裝了半天,才發現需要NPP函式庫。
NPP函式庫也要用64位元。
用VS2010編也不行,還退回去VS2008。
總算把hog_gpu給編出來了。
再來,要經由CMake重做。變得太快,不知要弄多久。
2011年6月3日 星期五
程式雙跨X86及MCU
主要是要讓MCU程式可以在Windows環境下可以編譯,或是簡單執行。
因為Bee成功將68K的程式移轉到Windows下成功。
這才了解在Windows下除錯是多麼幸福的事。
尤其在有作業系統的環境中,一般Debuger無法作用的環境中寫了數年的程式。
可以單步中斷、追蹤,是很幸福的。
在Visual Studio下,在執行時仍可以修改程式碼,立刻修改錯誤,這是不可能在MCU中可以做到的。
另外可以看呼叫來源,可以知道是如何進入函式,可以省去追各路分支。
MCU可以用Visual Studio去寫及模擬,我就不可能回到過去那種人工看Code的日子。
可以操作的等級差太多了。
以前面對10MB的原始碼,根本不知如何追起。
現在就覺得10MB不是那樣可怕,很輕鬆就可以設定及追蹤。
以下為需要修改的。
1.I/O
使用巨集,函式外型。
因為在沒有實體硬體時,需要另一組軟體函式來模擬。
要是做成記憶體存取,就會變成無法模擬。
2.組合語言
跳過
以C重寫
組合語言轉C
3.MCU內部設定
幾乎都是跳過
4.中斷
使用Windows Thread,另外開獨立高權限Thread來模擬中斷。
5.RTOS系統呼叫
找出對應的地方,套入Windows系統呼叫。
但仍有一些操作上和實體不同
1.堆疊
不會用配置記憶體做為堆疊,Windows有自己的。
2.當機的回復
這個不是硬體當掉,而是將堆疊設置錯誤產生的。
MCU有時會重啟RTOS,然後因全域變數留有工作,會連下去做。
但Windows可不會。
老實說,發現這個動作Bee很驚訝,這個明顯是程式設計錯誤。
也終於了解公司的怪O.S.為何不能移到正常的作業上執行的原因。
程式根本會死當,再利用怪怪的作業系統回復其工作,正常作業系統那裏有這招的。
因為Bee成功將68K的程式移轉到Windows下成功。
這才了解在Windows下除錯是多麼幸福的事。
尤其在有作業系統的環境中,一般Debuger無法作用的環境中寫了數年的程式。
可以單步中斷、追蹤,是很幸福的。
在Visual Studio下,在執行時仍可以修改程式碼,立刻修改錯誤,這是不可能在MCU中可以做到的。
另外可以看呼叫來源,可以知道是如何進入函式,可以省去追各路分支。
MCU可以用Visual Studio去寫及模擬,我就不可能回到過去那種人工看Code的日子。
可以操作的等級差太多了。
以前面對10MB的原始碼,根本不知如何追起。
現在就覺得10MB不是那樣可怕,很輕鬆就可以設定及追蹤。
以下為需要修改的。
1.I/O
使用巨集,函式外型。
因為在沒有實體硬體時,需要另一組軟體函式來模擬。
要是做成記憶體存取,就會變成無法模擬。
2.組合語言
跳過
以C重寫
組合語言轉C
3.MCU內部設定
幾乎都是跳過
4.中斷
使用Windows Thread,另外開獨立高權限Thread來模擬中斷。
5.RTOS系統呼叫
找出對應的地方,套入Windows系統呼叫。
但仍有一些操作上和實體不同
1.堆疊
不會用配置記憶體做為堆疊,Windows有自己的。
2.當機的回復
這個不是硬體當掉,而是將堆疊設置錯誤產生的。
MCU有時會重啟RTOS,然後因全域變數留有工作,會連下去做。
但Windows可不會。
老實說,發現這個動作Bee很驚訝,這個明顯是程式設計錯誤。
也終於了解公司的怪O.S.為何不能移到正常的作業上執行的原因。
程式根本會死當,再利用怪怪的作業系統回復其工作,正常作業系統那裏有這招的。
2011年5月12日 星期四
NAS+Smart Phone應用方法評估
最近Bee在評估Smart Phone並利用它和家中的動物機架互連的方法。
先實驗在動物機上架FTP Server。這個不難,只是要去設防火牆這裏不熟。
至於要架那些Server,想說先參照NAS上的功能。
因為Bee認為NAS上的功能,在動物機上應該都可以架設。
目前是用另一台筆電試連,未來買進Smart Phone,就可以直接使用。
這樣的組合,就可以用手機去遙控動物機,或是監看。
但下載的節目,還是要有可以播放的地方,用手機看實在是太小了。
剛好最近平板電腦開始流行,最新的已經進展到雙核心,可以順暢播放影片。
看來新的應用組合已經到位,且價格也可以接受了。
看來新的組合運行狀況是這樣的:
1.架設家用Server,可以是NAS或是動物機,主要是節目下載。
2.利用Smart Phone可以新增下載節目,或是監看下載狀況。
3.回家看節目,或是下載到平板電腦帶出門看。
平板電腦等於是行動播放器。
不過看來不只可以做這些事。
家用Server可以是數位家電的控制中心,這個概念Intel已經推很久了。只是一直流行不起來。
所以未來家用Server可以連接家電並做控制,只要使用手機就可以開啟或是監控。
所以生活就會變成這樣:
上班時,可以利用手機指定好下載的節目。
然後下班時,用手機遙控家中冷氣開始運轉。
再打電話訂便當,下班開車去拿便當回家。
一回家就有冷氣吹,就可以直接吃飯看節目了。
看不完的節目就轉存到平板電腦去。隔天出差坐高鐵時還可以繼續看。
Smart Phone只是開端,再來就是家用server及數位家電了。
可惜Bee沒錢,一切仍在紙上作業。
先實驗在動物機上架FTP Server。這個不難,只是要去設防火牆這裏不熟。
至於要架那些Server,想說先參照NAS上的功能。
因為Bee認為NAS上的功能,在動物機上應該都可以架設。
目前是用另一台筆電試連,未來買進Smart Phone,就可以直接使用。
這樣的組合,就可以用手機去遙控動物機,或是監看。
但下載的節目,還是要有可以播放的地方,用手機看實在是太小了。
剛好最近平板電腦開始流行,最新的已經進展到雙核心,可以順暢播放影片。
看來新的應用組合已經到位,且價格也可以接受了。
看來新的組合運行狀況是這樣的:
1.架設家用Server,可以是NAS或是動物機,主要是節目下載。
2.利用Smart Phone可以新增下載節目,或是監看下載狀況。
3.回家看節目,或是下載到平板電腦帶出門看。
平板電腦等於是行動播放器。
不過看來不只可以做這些事。
家用Server可以是數位家電的控制中心,這個概念Intel已經推很久了。只是一直流行不起來。
所以未來家用Server可以連接家電並做控制,只要使用手機就可以開啟或是監控。
所以生活就會變成這樣:
上班時,可以利用手機指定好下載的節目。
然後下班時,用手機遙控家中冷氣開始運轉。
再打電話訂便當,下班開車去拿便當回家。
一回家就有冷氣吹,就可以直接吃飯看節目了。
看不完的節目就轉存到平板電腦去。隔天出差坐高鐵時還可以繼續看。
Smart Phone只是開端,再來就是家用server及數位家電了。
可惜Bee沒錢,一切仍在紙上作業。
2011年4月13日 星期三
Lua排名急升
在這個月Lua成長到歷史新高,突破1%的佔有率,而且是"急升"。
一切都要感謝Apple。因為Lua已是iPhone上開發的語言。
另一個受惠於Apple的是Objective-C,可見Apple媚力很大。
以Bee猜想,Apple選用Lua是有原因的,其中之一是因為有coroutine。
因為iOS好像是單工(這個是聽來的),所以需要使用者管理多工問題。
而Lua的Coroutine可以在單工下解決多工問題,讓管理變簡單。
再來,可以預測Lua會進前十名。
一切都要感謝Apple。因為Lua已是iPhone上開發的語言。
另一個受惠於Apple的是Objective-C,可見Apple媚力很大。
以Bee猜想,Apple選用Lua是有原因的,其中之一是因為有coroutine。
因為iOS好像是單工(這個是聽來的),所以需要使用者管理多工問題。
而Lua的Coroutine可以在單工下解決多工問題,讓管理變簡單。
再來,可以預測Lua會進前十名。
2011年4月8日 星期五
虛擬機器啟動了
最近將I/O模擬做好了。
可以看到機器的輸出,再將輸出資料組合回去變成物理量。
可以大概看到機器動作起來。
先用開檔的方式,一個字一個字餵給RS232的取代函式,可以看到機器啟動去工作了。
公司的RTOS很怪,有一些不太好的行為,才會導致近十年來無法搬去PC上模擬。
有包含忙碌等待這種8051才看得到的delay方法。以及奇怪的多工系統。
現在於Windows上可以用multi-threads去模擬及觀察。
剛好最近有比較大的修改,就可以用這個虛擬機器去看一下動態行為。
一個以全域變數為主的管理系統,沒有這個虛擬機器去觀察的話,花在解析的時間會很可觀。
可以看到機器的輸出,再將輸出資料組合回去變成物理量。
可以大概看到機器動作起來。
先用開檔的方式,一個字一個字餵給RS232的取代函式,可以看到機器啟動去工作了。
公司的RTOS很怪,有一些不太好的行為,才會導致近十年來無法搬去PC上模擬。
有包含忙碌等待這種8051才看得到的delay方法。以及奇怪的多工系統。
現在於Windows上可以用multi-threads去模擬及觀察。
剛好最近有比較大的修改,就可以用這個虛擬機器去看一下動態行為。
一個以全域變數為主的管理系統,沒有這個虛擬機器去觀察的話,花在解析的時間會很可觀。
訂閱:
文章 (Atom)