因為使用到PIC，於是看看有無Forth可用，於是找到Flash Forth。
另一個目標是找Cortex M3上的Forth，結果找到一個分散式的Forth，PC端是用TCL寫的，TCL很不熟，就先放著。
比較令我感興趣的是PIC18上的Flash Forth。
雖然丁陳老師的eForth有做在PIC17上。但無法做新加程式，因為無法將程式寫回Flash。
但Flash Forth在PIC18上可以將程式寫回Flash。
因為MCU上我比較少做這個動作，所以沒有想到其實可以寫回Flash，就可以Run完整的Forth。
看了一下，就把回寫的地方改為燒回Flash的函式。
雖然寫回Flash是很慢，但人的反應也不快，所以不會感覺到。
只要Run的夠快就好了。
有去比對其他Forth，MSP430上的CamelForth也有這樣的能力。
不過作者有發現一個問題，就是CREATE> 指令受到影響。
而改以另一個指令去取代。
還是比較希望有Flash Forth在Cortex M3上面。目前還沒有看到。
Bee是知道FIG Taiwan的Holi有ARM7 Forth。不過他的堆疊成長方向和Cortex M3相反，要移反而麻煩。
只能說是Holi選錯了方向，因為ARM7確實二個方向都可以。
不過Cortex M3因為要精簡，就變成單向。而且組合語言指令有16 bit及32 bit混合，不像ARM7固定在32 bit上。
這些改變都要去動Forth核心動作。重寫可能還比改寫快。
2011年8月20日 星期六
五週五顆MCU
新工作上先做一些支援性任務，結果上班五週，就遇到五顆MCU。
分別是PIC18、PIC33、STM32F103、STM32F207以及待寫的STM32F100。
後三個是ARM Cortex M3，理論上會比較好適應，不幸的是這三個是分開的在二個任務上。
現代MCU和以前的不同，I/O型態多，不好設定，花最多時間在讀規格及設定成需要的I/O。
以前是很喜歡去看不同的MCU及CPU資料，不過這五週還真的有點吃不消。
不過可以看到一個趨勢，Cortex M3真的很便宜，PIC完全不是對手。
所以新設計會採用ARM是無法避免的。
本來還想說不是還有Cortex M0，問題是M3不到1美元。那還用M0做什麼?
其實還有遇到第六個MCU，因為是全組合語言寫的，且是已停產的日系MCU。就說要適應要一個月。
所以就沒再去碰了。
在這裡可以見到使用C語言是必然的。
現在MCU便宜到不行，用組合語言會被特定MCU綁住，就無法升級。
程式也是一種資產，但沒有製造成本。
全組合語言的程式很難移植，最後只好用新產品去頂掉，程式就只好用C重寫一次。
變成不做也不行的事了。
另外還有一些PC上做出來的人工智慧的程式要移進MCU中。
在沒有作業系統的幫助下，在PC上開發程式的人吃了不少苦頭。
所以我又架了RTOS做為準備工作。
這次選了FreeRTOS。有去追一下核心，設計方式和uCOS-II並不同。
不過國內沒有什麼人在用FreeRTOS，所以也没有什麼中文資料。
充實的五週，不過還沒有結束。只能一件一件事解開來。
分別是PIC18、PIC33、STM32F103、STM32F207以及待寫的STM32F100。
後三個是ARM Cortex M3，理論上會比較好適應，不幸的是這三個是分開的在二個任務上。
現代MCU和以前的不同，I/O型態多，不好設定，花最多時間在讀規格及設定成需要的I/O。
以前是很喜歡去看不同的MCU及CPU資料，不過這五週還真的有點吃不消。
不過可以看到一個趨勢，Cortex M3真的很便宜，PIC完全不是對手。
所以新設計會採用ARM是無法避免的。
本來還想說不是還有Cortex M0，問題是M3不到1美元。那還用M0做什麼?
其實還有遇到第六個MCU，因為是全組合語言寫的，且是已停產的日系MCU。就說要適應要一個月。
所以就沒再去碰了。
在這裡可以見到使用C語言是必然的。
現在MCU便宜到不行，用組合語言會被特定MCU綁住，就無法升級。
程式也是一種資產，但沒有製造成本。
全組合語言的程式很難移植，最後只好用新產品去頂掉，程式就只好用C重寫一次。
變成不做也不行的事了。
另外還有一些PC上做出來的人工智慧的程式要移進MCU中。
在沒有作業系統的幫助下，在PC上開發程式的人吃了不少苦頭。
所以我又架了RTOS做為準備工作。
這次選了FreeRTOS。有去追一下核心，設計方式和uCOS-II並不同。
不過國內沒有什麼人在用FreeRTOS，所以也没有什麼中文資料。
充實的五週，不過還沒有結束。只能一件一件事解開來。
2011年7月24日 星期日
VS2010追蹤MCU的C程式
換公司後都是用未曾用過的MCU。
這時追程式能力很重要。
除了前公司用過Source Insight外。
Bee更喜歡用Visual Studio 2010。
追MCU程式碼只要用到Express版本就剛好，是免費的。
因為不只能靜態追碼，還可以做以下動作：
1. 使用X86的除錯器，可以做到動態追碼，就是模擬執行。
2. 在執行中，可以修改程式碼。
不過要使用，有二個問題要解決。
1. 組合語言對應程式碼。
大部分是設定MCU，對X86沒有用。
只是去補欠缺的函式。
2. 標頭檔不同
函式庫位置。以及二個編譯器之間的不同。
都搞定後，就可以在VS2010上面編出exe檔。
這是在X86下可以執行的。
用Debuger去追，只要遇IO就會產生記憶體存取錯誤。
沒關係，直接修改。導向一個記憶體區。
然後就繼續執行。
都改好了，就可以發現while跑完了一圈。
去修改假IO用的記憶體區，就可以進入程式內部再追下去。
這是Bee面對大型Firmware程式用的方法。
這時追程式能力很重要。
除了前公司用過Source Insight外。
Bee更喜歡用Visual Studio 2010。
追MCU程式碼只要用到Express版本就剛好，是免費的。
因為不只能靜態追碼，還可以做以下動作：
1. 使用X86的除錯器，可以做到動態追碼，就是模擬執行。
2. 在執行中，可以修改程式碼。
不過要使用，有二個問題要解決。
1. 組合語言對應程式碼。
大部分是設定MCU，對X86沒有用。
只是去補欠缺的函式。
2. 標頭檔不同
函式庫位置。以及二個編譯器之間的不同。
都搞定後，就可以在VS2010上面編出exe檔。
這是在X86下可以執行的。
用Debuger去追，只要遇IO就會產生記憶體存取錯誤。
沒關係，直接修改。導向一個記憶體區。
然後就繼續執行。
都改好了，就可以發現while跑完了一圈。
去修改假IO用的記憶體區，就可以進入程式內部再追下去。
這是Bee面對大型Firmware程式用的方法。
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.為何不能移到正常的作業上執行的原因。
程式根本會死當，再利用怪怪的作業系統回復其工作，正常作業系統那裏有這招的。
訂閱：
文章 (Atom)