五週五顆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，所以也没有什麼中文資料。

充實的五週，不過還沒有結束。只能一件一件事解開來。

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程式用的方法。

十年，終究還是離開

一家公司待了十年。要離開還是有一點點不捨。
但，為了走更好的路，只能選擇離開。

朝下一個目標前進！

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總算全部搞定。

OpenCV2.2+CUDA x64模式編譯成功

使用OpenCV2.2版，用CUDA 3.2版。

因為改用CMake所以很不習慣。

裝了半天，才發現需要NPP函式庫。
NPP函式庫也要用64位元。

用VS2010編也不行，還退回去VS2008。

總算把hog_gpu給編出來了。


再來，要經由CMake重做。變得太快，不知要弄多久。

程式雙跨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.為何不能移到正常的作業上執行的原因。
  程式根本會死當，再利用怪怪的作業系統回復其工作，正常作業系統那裏有這招的。

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沒錢，一切仍在紙上作業。