A first hand look at building an Android application

##CONTINUE##
Androidology - Part 1 of 3 - Architecture Overview


Androidology - Part 2 of 3 - Architecture Overview


Androidology - Part 3 of 3 - Architecture Overview

Display PNG file in WinCE 5.0

PNG圖檔支援背景透明的效果，不過一開始使用時，卻發現原本應該是要透明的背景，卻仍然顯示出來，這樣在將來若做UI介面時會使的美觀上大打折扣

##CONTINUE##
後來在書上發現，可以利用程式來自行處理，不過，處理時必須要指定要變為透明的顏色，也就是說，每載入一張PNG圖都必須去取得透明色的RGB值，才能將它變為透明，這樣會使得設計上非常不方便，同時，在處理後的圖示上，由於只譨指定一種顏色為透明，因此，若圖示上有陰影的效果，會使得圖示的邊緣處理的不漂亮！

後來，發現在WinCE 5.0上其實有提供透明背景顯示，不過需要加入Component後才行，可以在platform builder上搜尋SYSGEN_GDI_ALPHABLEND，加入"Alphablend API"，重新Build image後即可！







至於顯示PNG的方便，有很多library可以使用，不過還需要時間比較一下，微軟也有提供IImage class可以使用。


CoInitializeEx(NULL, 0);
IImagingFactory* pImageFactory;
IImage *pImage = NULL;


HRESULT hr = CoCreateInstance(CLSID_ImagingFactory, NULL,
CLSCTX_INPROC_SERVER,
__uuidof(IImagingFactory),
(LPVOID *)&pImageFactory);

// Load image from file
pImageFactory->CreateImageFromFile(L"info.png", &pImage);

// Get image information
ImageInfo info;
pImage->GetImageInfo(&info);

RECT rc={0,0,info.Width, info.Height};

pImage->Draw(dc, &rc, NULL);

// Clean up
pImage->Release();
pImageFactory->Release();

CoUninitialize();


修正Reset Registry to default問題

藉由更動TOC中變數來判斷是否要將系統回復為預設值

AP部分：將TOC中bReserved[3]的值設為0X45

TOC *p;
BYTE InBuf[2048];
DWORD psize,val=0;
if(::KernelIoControl(IOCTL_READ_TOC, NULL,0,&InBuf, 2048,&psize))
{
p = (TOC *)InBuf;
p->bReserved[3] =0x45;
::KernelIoControl(IOCTL_WRITE_TOC, &InBuf, 2048,NULL,0,&psize);
KernelIoControl(IOCTL_HAL_REBOOT, NULL, 0, NULL, 0, NULL); //reboot device
}

##CONTINUE##
Driver部分：

• 在IsAnyKeyDown()加入判斷：若值為0x45則將系統回復為預設值


if(toc->bReserved[3] == 0x45)
{
RETAILMSG(1, (TEXT("#####toc->bReserved[3]=%d \r\n"),toc->bReserved[3]));
return TRUE;
}
.........


• 在XXXDaemon中加入判斷：若值為0x45，則將PETestFolder刪除，並將值設為0避免重複作回復預設值的動作！


if(toc->bReserved[3] == 0x45)
{
if(::KernelIoControl(IOCTL_READ_TOC, NULL,0,&InBuf, 2048,&psize))
{
p = (TOC *)InBuf;
p->bReserved[3] =0;
::KernelIoControl(IOCTL_WRITE_TOC, &InBuf, 2048,NULL,0,&psize);
}
hFind = FindFirstFile (L"\\My Flash Disk\\PETestFolder", &FindFileData);
if(hFind != INVALID_HANDLE_VALUE)
{
FindClose(hFind);
if(EmptyDirectory(_T("\\My Flash Disk\\PETestFolder"),TRUE))
{
RemoveDirectory(_T("\\My Flash Disk\\PETestFolder"));
}
}


[轉貼]滿街都是iPod跟iPhone‧漫談UI界的逆向工程

出處：HandyUI.com
作者：陳文剛

逆向工程(Reversed Engineering)普遍存在於各個領域，尤其在台灣，各行各業的高手們，更是樂此不疲。大廚師喜歡到處吃吃喝喝，用舌頭跟鼻子去破解各地美食的料理秘方；電影工作者喜歡把經典橋段拿來重複播放、快轉倒轉、慢動作格放，反覆地推敲每一個走位跟運鏡。就連裕隆老總嚴凱泰都曾發生過類似的趣事，他在正式代理Armani前，就曾經把Armani西裝丟給港台一流的打版師傅拆解研究，直到怎麼組都組不回原樣時，他才心甘情願地放棄自行生產，專心做代理銷售。

每個人看到好東西時，心裡自然都會想著：「媽阿，這是怎麼辦到的？」也因此，人們都會渴望把美好的東西拆解，把它的外表一層一層地撥開，直到搞清楚這是怎麼一回事為止。這個過程就像拆禮物一樣，一層一層的包裝被打開，外觀越來越接近物品本身應有的大小跟重量，最後露出禮物的一瞬間，謎底終於揭曉，這可是相當迷人的經驗。「喔，原來是這樣做的阿！」這樣的讚嘆聲，就在最終破解的那一刻，發自內心地冒了出來。人類最原始，那種窺探、追根究底、搞懂怎麼做的本能渴望，就在這樣的過程中，一次又一次地被徹底滿足。

##CONTINUE##
就像上面所提到的，逆向工程的過程裡，充滿了驚喜與刺激，既知性，又充滿挑戰性。不過，從 UI Design的角度來看，搞懂怎麼做(know-how)，跟知道為什麼要這樣做(know-why)，其實是天差地遠的兩件事。

在UI界，逆向工程這檔子事也是常常在發生，每天都在做，只是抄得多抄得少，或是依賴程度高低的差別而已。設計手機介面的時候，拿起Nokia或是Sony Ericsson玩看看，參考一下人家輸入法是怎樣做的；或是設計相機時，拿起 Canon或Nikon，看看人家的人臉對焦框是方的還是圓的，合焦時會不會變色？久而久之，所有類似產品的介面都長得很像，用起來都一樣，沒有特別好，也不會特別差。由於這種狀況每天都在發生，所以部分的介面設計師，很可能已經習慣於大量地參考別人，然後小幅地改善自己。

從模仿中學習，其實是個必經的歷程

從現有案例中學習，其實是件好事，也或許可以當作是蹲馬步般的基本功。舉個例來說，要一個沒吃過義大利菜的人，做出好吃的義大利式燉飯 (Risotto)，或是要一個沒玩過遊戲軟體的人，憑空設計出一款多人線上角色扮演遊戲 (MMORPG)，那都是相當困難，甚至天方夜譚的事。

介面設計師在開始著手設計前，當然要對該產品，或是同一領域的其他產品，有清楚的認識。在介面設計流程裡，這個知己知彼的過程與方法，就叫做競爭者分析 (Competitor Study)。通常在做產品定位，或是進行設計前，都會先跑過一次分析，搞清楚現有產品的優勢劣勢，以及自家產品的機會點。

在做介面設計的競爭者分析時，最簡單的方法是，找來各家產品，快速比較一下設計風格、資訊架構、互動效果等，一個表格或是幾張slide大概就可以搞定。另一種比較嚴謹的做法則是，把整個介面設計的元素全部拆解開來，重製出一份UI flow，並且將layout跟icon全部攤開，把各種互動設計都分門別類，一個一個做比較分析。後者的做法，跟所謂的逆向工程，其實沒什麼兩樣。

經過上述的拆解與分析之後，簡單如iPod，複雜如iPhone，內部的操作流程跟介面設計元素，都可以攤開來一覽無遺。這時候要抄要改，幾乎都像扒滷肉飯一樣輕鬆 (其實也沒這樣輕鬆，苦工夫一堆，又會被告，千萬別傻傻地去做)。至於要參考哪個部分，如何轉化成自己的設計，則完全看設計師自己的功力與經驗。

就像前面舉做燉飯，或是研發線上遊戲的例子一樣，做介面設計時，要是不做點競爭者分析的功課，就很可能會閉門造車，搞出類似重新發明輪胎的糗事 (歷史上，輪胎的外型曾經被重新發明很多次，方型的，雪橇型的都有，但是弄到最後，事實證明還是圓的最有效率)。透過逆向工程的手段，去快速學習、了解競爭者特性，是非常有效率且必要的做法。莫內、梵谷、畢卡索，哪一個沒有畫過靜物素描，沒有揣摩過大批翻製的石膏像？從模仿中學習，是人類進步的重要技能，在科技快速發展的今天，更是得不停地模仿，不停地踩在別人既有的基礎上，追求實質的進步。



掌握關鍵本質，才能夠舉一反三

只不過，模仿應該只是手段，而不是最終目的；知道如何做得一模一樣，跟了解背後的原理原則，真的是天差地遠的兩件事。

舉個實際的例子來說，有時候我們常會看到許多四不像的產品規格，去找PM討論時，總會聽到：「XX大廠就是這樣設計的，我想他們這樣做，一定有他的原因跟道理，我們照著這樣做比較安全。」 更厲害的PM則會融會貫通、旁徵援引，說出一套道理來：「我會想拿掉電源開關，是因為iPod也沒有電源開關；至於這裡要長按兩秒鐘，是因為PDA也都是長按兩秒鐘；而且我還加了閃七下的燈號提示，這是我們自己發明的，非常friendly，跟Canon的印表機有異曲同工之妙。」

這樣噴飯的對話常常出現，每回聽到這些謬論，除了心裡苦笑之外，也很懶得去反駁。老實說，我不太能夠接受「XX大廠這樣設計，一定有他的原因跟道理」這種說法，太籠統，而且也太馬虎行事。在搞不清楚別人為什麼這樣設計之前，就一股腦地抄，抄到最後就像拼裝車一樣，東拼西湊，重看不重用。

好的介面設計師不只懂得欣賞好產品，具有一眼就看出關鍵概念的鑑賞力，而且更懂得將這些精采地設計概念消化吸收，重新轉化成新的設計，比過去看過的更精練，更貼近使用者需求。夠水準的介面設計師，絕對不會只從Apple, Nokia等公司產品找靈感，更大一部分的啟發來自於日常生活，來自於人類歷史當中所有的經典設計。

舉個例來說，在思考手寫輸入介面的可能性時，我們會去參考Windows Mobile、漢王、蒙恬，或是甚至是iPhone的觸控螢幕鍵盤。但是在此同時，我們更關注的是，手、筆跟紙的關係。我們觀察人們長久以來怎麼樣用筆紀錄，如何在紙張上頭註記，如何塗改，如何銷毀。漸漸地會發現到，現有的手寫輸入介面都不夠好，連市面上最棒的產品也頂多在及格邊緣，離感動人心還差的遠。這時候，精采的就來了。從競爭者分析中看到現況，找到機會，然後透過設計師的經驗與巧思，就有可能設計出一套全新的手寫輸入介面，一舉超越現下的所有產品，或者你要說是，有史以來的所有產品也可以。

這就是具備鑑賞力、觀察力，並且掌握關鍵本質的奇妙功效。同樣是做競爭者分析，同樣是逆向工程，不明就裡地抄，跟了解原理原則後的全新設計，很可能就是地獄與天堂的差別。在這一點上，台灣廠商的逆向工程技術確實很先進，但是少了創意，少了理想與堅持，最後很可能開發出的全是一堆me too，或甚至比me too還差的產品，真的是很可惜。

XXX7600 : Fix Calibration

• 讀取Registry儲存值：
  

if (RegOpenKeyEx(HKEY_LOCAL_MACHINE, _T("HARDWARE\\DEVICEMAP\\TOUCH"), 0, KEY_QUERY_VALUE, &hkey) != ERROR_SUCCESS)
return 0;

dwSize = sizeof(str);
lResult = RegQueryValueEx(hkey, _T("CalibrationData"), NULL, &dwType, (LPBYTE)str, &dwSize); //query registry value

##CONTINUE##

• 分割字串，並計算與預設值的差值總和(每一點座標相減)

pStr = wcstok(str, seps);

for (i=0; pStr != NULL; i++)
{
wcscpy(token[i], pStr);
tokennum[i]=_wtoi(token[i]);
pStr = wcstok(NULL, seps);
}

for(i=0;i<10;i++) sum =" sum"> 50)
bMAXVal = true;
}
if(sum > 400)
{
lResult = RegSetValueEx(hkey, _T("CalibrationData"), NULL, REG_SZ, (LPBYTE)defaultval, dwSize);
RegCloseKey(hkey);
bMAXVal = true;
}
else
RegCloseKey(hkey);

• 若差值總和過大或其中一點差值大於40則在進入系統後重新做校正。
  

時間管理軟體試用：iGTD

iGTD是由bartek bargiel發展出來的mac上時間管理軟體，GTD(Getting Things Done)則是由David Allen發展出來的時間管理系統，主張事情應該利用工具來紀錄，而不應該記在腦中！


##CONTINUE##
有關GTD可參考：



Getting Things Done

作者︰David Allen






搞定! 2分鐘輕鬆管理工作與生活




相關網站：

• 開始你的GTD
• twhsi的時間管理網站

GTD的概念在於把可以同時處理的事情集合在一起，可以利用場合的概念，把我們有的雜事加以分類，例如電話、電腦前處理、Mail等，這樣就可以批次來處理！

在twhsi的網站上提供了幾個實用場合參考：

• 電話聯絡
• 電腦相關
• 閱讀及寫作
• 規劃思考
• 當面聯絡
• 自己動手
• waitting
• someday/maybe

iGTD也是以此概念來處理，在iGTD中Context可以視為各種的場合，而每個待辦的事項則稱為task！每個task都可以設定其輕重等級！

iGTD也提供了同步的功能，可以與iCal同步，若再搭配iCalViewer，則可以將事情列在桌面上，隨著事情的輕重等級，會以不同顏色區分！

另外，iGTD也提供了tag的功能，可以為task加上tag，再透過smart folder的功能，就可以將所有與此tag有關的task列出，這項功能就可以用在案子的管理上，看看目前還有那些task尚未解決！

Provia A1 GPS

##CONTINUE##

• Samsung 800 x 480 resolution widescreen touchscreen 7-inch display
• Navigation uses super-detailed, razor-sharp 3D maps, complete with models of buildings and other landmarks.
• It has a "picture-in-picture" (PIP) mode, so you can simultaneously watch a movie and get directions.
• a DMB receiver so you can receive over-the-air (OTA) digital television broadcasts.
  
• DivX, XviD, H.264, WMA, WMV, OGG, mp3, MPEG-4, and a bunch of other formats.

心智圖軟體

##CONTINUE##
免費跨平台 : FreeMind

• 新版本0.9.0Beta2 Release！
• 使用上蠻直覺好用，Tab鍵新增子結點，Enter鍵新增平行結點。
• 跨平台，PC或Mac上皆可使用。

免費線上版：Mindomo

• 介面較美觀，免費版已提供Map style以及加入圖式、圖片功能。
• 有提供類似標籤雲功能：Boundary Shape
• Flash 介面
• 連線速度滿意。
• 提供分享功能。
• 可輸入FreeMind檔案。
• 免費版僅提供三個私人檔案！
  

Mac版：NovaMind

• 介面華麗，並提供許多免費的圖示。
• 無免費版，最便宜的需要49 USD。
• 目前試用中，輸入介面還是覺得FreeMind好用。
  

Something about including managed code to OS Image

在MSDN上提到：
The MODULES section specifies which Windows Embedded CE-based modules are included in the run-time image, and how they are loaded into the memory table as established in the MEMORY section of the Config.bib file.

This section can contain up to 2,000 modules, which consist of a two-part combination of source code and data.

Note:

Do not include managed code in the MODULES section. This is because the kernel does not load managed code. Instead, managed code is opened as a memory-mapped file by the .NET Compact Framework. Managed code must be included in the FILES section.

##CONTINUE##
至於甚麼是Managed Code? Unmanaged Code? Native Code?可以參考這篇文章！Managed, Unmanaged, Native: What Kind of Code Is This?

因此，在platform.bib中，必須將要加入的Managed Code加在Files Section而不是在Modules Section！

增加MFC component到Wince 6.0 Image

##CONTINUE##
在Visual Studio 2005中建立Wince 6.0 OS時，似乎找不到MFC的Component，在Google上搜尋了一下，看起來是要自己將需要的檔案加到OS的Image中！

1.首先，若不知道程式需要用到哪些DLL檔，可以使用 Dependency Walker 確認：

2.利用 CEFileWiz將所需的DLL檔案產生CE 的Component，MFC相關的DLL在安裝Visual Studio2005完後，會放置在C:\Program Files\Microsoft Visual Studio 8\VC\ce\Dll\上！

選好要加入的檔案，並在Component Name填入名稱後，按下Built後就會在WINCE600\PUBLIC下加入新的Component，之後在Catalog Item Window內的Third Party內就可以看見新加入的Component了:)

在WinCE桌面上加個程式捷徑

##CONTINUE##
1.產生一個.lnk檔案

產生一個.lnk檔案，例如：MyApp.lnk，檔案內容為

20#"\Windows\MyApp.exe"

其中，20代表#後的字串個數，包含""！

並將.lnk檔放到%_PROJECTOAKROOT%\Files目錄下！

2.在.dat內加入捷徑宣告

在project.dat內加入下面宣告：

Directory("\Windows\Desktop"):-File("DebugZoneAp.lnk", "\Windows\DebugZoneAp.lnk")

3.將.lnk檔增加到ROM Image內

在project.bib之FILE區內加入：

DebugZoneAp.lnk $(_FLATRELEASEDIR)\DebugZoneAp.LNK NK S

Something about taskbar and desktop

有關Taskbar設定：
設定Taskbar自動隱藏：在platform.reg中加入
[HKEY_LOCAL_MACHINE\Software\Microsoft\Shell\AutoHide]
"Default"=dword:1

將Taskbar "Always on top"屬性取消：
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shell\OnTop]
"Default"=dword:0
##CONTINUE##
若要將taskbar完全隱藏，可以在程式中加入：
HWND hWnd = NULL;
hWnd = ::FindWindow(_T("HHTaskBar"),NULL);
if(hWnd)
{
::ShowWindow(hWnd,SW_HIDE);
}


有關桌面設定：
設定預設桌布：在platform.reg中加入
[HKEY_CURRENT_USER\ControlPanel\Desktop]
"wallpaper"="\\Windows\\Orangebk.jpg"
記得要將圖片檔在platform.bib中加入

取消我的電腦與垃圾桶圖示：在platform.reg中加入
[HKEY_LOCAL_MACHINE\Explorer\Desktop]
"{000214A0-0000-0000-C000-000000000046}"=-
"{000214A1-0000-0000-C000-000000000046}"=-

Dragon Quest Sword

Windows CE vs. Windows Mobile

簡單來說，基本上兩者所採用的系統核心是一樣的，不過Windows Mobile是Microsoft公司專門為了市面上常見到的PocketPC或是Smartphone所打造的一套開發環境與授權方式，一般OEM公司如果想要加入生產PocketPC或是Smartphone的行列，就必須與Microsoft特別簽訂相關授權，至於產品的外觀與內含的軟體核心，都是由Microsoft建議，量產之前也必須通過Microsoft的認證，方能掛上Microsoft標籤出售。
##CONTINUE##
至於Windows CE則不限定於PocketPC或是Smartphone的產品，一般公司可以自由運用在許多方面。以這一次Microsoft所展示的相關產品來說，就可以運用在VoIP電話或是網路IP機上盒等多樣產品，一般公司可以自由選擇Windows CE中的套件組合，如果單單選擇只要核心的套件組合，最便宜的核心授權費是3元美金，量產出貨也不一定要通過Microsoft的認證，當然也省了一筆認證所需的費用。如此的彈性組合，已經逐漸讓許多專門做嵌入式系統產品的廠商心動，並且逐漸積極佈局研發。
這兩者的軟體開發環境取得也不一樣，Windows Mobile是在取得Microsoft授權之後，由Microsoft以特別的方式授予。但是Windows CE則是以幾乎免費的方式散佈。因此對於一般公司或是個人工作室來說，取得Windows CE的開發環境與相關技術文件的門檻相對來說是非常低的。
[節錄]"WinCE降低授權門檻 微軟新版OS大舉進攻嵌入式市場"

Block Device Driver vs. Character Device Driver

Device Driver大 致 分 為 Block Device Driver和 Character Device Driver兩 類 。
而 Block Device Driver是 以 固 定 大 小 長 度 來 傳 送 轉 移 資 料 ； Character Device Driver是 以 不 定 長 度 的 字 元 傳 送 資 料 。
##CONTINUE##
且 所 連 接 的 Devices也 有 所 不 同 ， Block Device大 致 是 可 以 隨 機 存 取 (Random Access)資 料 的 設 備 ， 如 硬 碟 機 或 光 碟 機 ； 而 Character Device剛 好 相 反 ， 依 循 先 後 順 序 存 取 資 料 的 設 備 ， 如 印 表 機 、 終 端 機 等 皆 是 。

HOW TO：進行對 Windows Form 控制項的安全執行緒呼叫

Windows Form 控制項的存取並非原本就採用安全執行緒的方式。如果您有兩個或多個執行緒管理控制項的狀態，就有可能強制控制項進入不一致的狀態。其他與執行緒有關的錯誤 也有可能如此，包括競爭情形和死結。確定存取控制項是以安全執行緒的方式來進行，是很重要的。
##CONTINUE##
對 Windows Form 控制項進行安全執行緒呼叫
若要對 Windows Form 控制項進行安全執行緒呼叫

1.查詢控制項的 InvokeRequired 屬性。
2.如果 InvokeRequired 傳回 true，就使用對控制項進行實際呼叫的委派 (Delegate) 呼叫 Invoke。
3.如果 InvokeRequired 傳回 false，便直接呼叫控制項。

private void setTextSafeBtn_Click(
object sender,
EventArgs e)
{
this.demoThread =
   new Thread(new ThreadStart(this.ThreadProcSafe));

this.demoThread.Start();
}

// This method is executed on the worker thread and makes
// a thread-safe call on the TextBox control.
private void ThreadProcSafe()
{
this.SetText("This text was set safely.");
}
private void SetText(string text)
{
// InvokeRequired required compares the thread ID of the
// calling thread to the thread ID of the creating thread.
// If these threads are different, it returns true.
if (this.textBox1.InvokeRequired)
{
   SetTextCallback d = new SetTextCallback(SetText);
   this.Invoke(d, new object[] { text });
}
else
{
   this.textBox1.Text = text;
}
}
}

資料來源：MSDN

Windows Form vs Multithread

最近試著用C#練習寫BT(bluetooth)搜尋程式，為了讓搜尋時視窗不要因為搜尋時而導致視窗無法移動，因此，最簡單的方式，就是在增加一個thread來處理搜尋的動作，等處理完後再將結果顯示在ListBox上：

##CONTINUE##

public void Search_Click(object sender, EventArgs e)

{
this.listBox_devices.Items.Clear();
this.Text = "Search Bluetooth Device...";
this.search_thread = new Thread(new ThreadStart(search));
search_thread.Start();
}

private void search()
{
this.listBox_devices.Items.Clear();

InTheHand.Net.Sockets.BluetoothClient bc = new InTheHand.Net.Sockets.BluetoothClient();

InTheHand.Net.Sockets.BluetoothDeviceInfo[] array = bc.DiscoverDevices();

for (int i = 0; i <>

this.address_array[i] = array[i].DeviceAddress;
this.listBox_devices.Items.Add(array[i].DeviceName);

}

}

上面程式在按下Search按鈕後將會啟動Search thread處理搜尋的功能，搜尋完後會將蒐尋到的BT Devices的名稱儲存下來並顯示在ListBox中，看起來似乎沒甚麼問題，但程式在按下Search按鈕後程式就當掉了！

原來問題在於，只有建立Windows Form的thread才能存取、修改Form或控制項的內容，因為.NET的控制項在設計時是執行緒相依(thread affnity)，只有在建立該Form或控制項的執行緒才能安全地存取其屬性。

當控制項的狀態改變時，系統會把它轉換成視窗訊息，放到訊息佇列中(Message Queue)，再由程式處理！

不過，將訊息放入訊息佇列(Message Queue)的方式分為兩種，一種為SendMessage()，一個則為PostMessage()。前者為呼叫者會停住直到訊息被處理為止；而後者呼叫端則是將訊息放置訊息佇列後即立刻返回。

而在.NET裡，所有Form或是控制項的屬性變更，皆由SendMessage()送出訊息！

因此，在上面的程式中，當主執行緒等待搜尋執行緒完成，而搜尋執行緒因為嚐試更新控制項，因此呼叫了SendMessage()，而SendMessage()會因此使搜尋執行緒停住，因為它必須停主執行緒將SendMessage()送出的訊息處理，而主執行緒也在等待搜尋執行緒執行完畢，因此變成互相等待的情形，程式因此當掉了！

iPhone is coming~~

C# : Delegate(委派)

用來宣告委派 (Delegate)。委派是一種參考型別，它參考型別的 Shared 方法或物件的執行個體方法 (Instance Method)。任何具有相符參數型別和傳回型別的程序都可用來建立這個委派類別的執行個體。接著可透過委派執行個體來叫用程序。
##CONTINUE##
Delegate 陳述式定義委派類別的參數型別和傳回型別。任何具有相符參數型別和傳回型別的程序都可用來建立這個委派類別的執行個體。接著可透過委派執行個體來叫用程序，方式是呼叫委派的 Invoke 方法。

~MSDN

Delegate(委派)大致類似 C++ 的函式指標(Function Pointer)，函數指標的致命缺點是：無法對參數 (parameter) 和返回值 (return value) 的型態進行檢查，因為函數已經退化成指標，指標是不帶有這些型態資訊的。少了型態檢查，當參數或返回值不一致時，會造成嚴重的錯誤。編譯器和虛擬機器 (VM) 並不會幫我們找出函數指標這樣的致命錯誤。所以，許多新的程式語言不支援函數指標，而改用其他方式。

至於為什麼會需要function pointer、delegate機制呢？簡單的想法：『為什麼我們不能將function也如同變數一樣傳進另外一個function呢?』，C語言的解決方式是，利用pointer指向該function，將該pointer傳入另外一個function，只要將該pointer dereference後，就如同存取原function一樣。C#解決的方式是，將function包成delegate object，傳入另外一個function。

參考" Function Pointer、Delegate和Function Object (初級) (C/C++) (OO C++) (Template C++) (C#)"

Visual Studio 2005試用

##CONTINUE##
最近重新安裝Visual Studio 2005再試用一下，之前使用的時候，總是無法順利的部署到機器上，這次到網路論壇上找了一下，發現原來之前安裝的順序錯了，正確的安裝順序應該是：
1. 安裝Visual Studio 2005
2. 安裝裝置的SDK
3. 在Visual studio 2005的選單上，選取"工具\連接到裝置"，選取要連結的裝置即可，例如SNAXXXX

接下來就可以開啟新的專案來開發新的Ap了，試用C#寫了一個簡單的Ap確實可以在760上Run，不過第一次部署時，花了不少的時間安裝檔案，還目前還不清楚需要哪些檔案才能執行？

Mac上錄音軟體 : WireTap pro

##CONTINUE##
最近需要錄製ICRT的BBC News，不過之前買的手提音響被賣掉了，只好找看看在電腦上錄製的可能性，首先當然是找網路廣播軟體，這個已經有人寫好了 : Hinet Sucks! Radio widget，內建台灣大部分的廣播了！
接下來就是如何去錄製了，這部份在PC上應該找到不少軟體，不過，PC實在太吵了，不想一大早就被吵醒，所以只好往Mac上找看看，其實也不少軟體，不過大部分都是要錢的，既然要錢就要好好比較一下，最後決定買了WireTap pro，價錢19塊美金，還能接受！
看一下它的功能圖

除了一般從麥克風錄製外，也可以錄製電腦上播放的聲音，因此要錄製廣播的話，只要打開廣播，接著選擇錄製電腦上聲音即可！
另外也跟iCal與iTunes整合，可以以iCal設定要錄製的時程與錄製時間，時間到了就會自動開啟錄製，目前是希望能讓電腦每天自動開啟後錄製，錄製完後在自動關機，不過目前還沒找到可以讓Hinet Sucks! Radio widget在開機後自動播放廣播的方法，難不成真的要自己寫各程式去控制嗎？

BlueTooth Profiles Overview

Advanced Audio Distribution Profile (A2DP)
A2DP describes how stereo quality audio can be streamed from a media source to a sink. The profile defines two roles of an audio source and sink. A typical usage scenario can be considered as the 「walkman」 class of media player. The audio source would be the music player and the audio sink is the wireless headset. A2DP defines the protocols and procedures that realize distribution of audio content of high-quality in mono or stereo on ACL channels. The term 「advanced audio」, therefore, should be distinguished from 「Bluetooth audio」, which indicates distribution of narrow band voice on SCO channels as defined in the baseband specification.
##CONTINUE##
This profile relies on GAVDP. It includes mandatory support for low complexity subband codec (SBC) and supports optionally MPEG-1,2 Audio, MPEG-2,4 AAC and ATRAC.

The audio data is compressed in a proper format for efficient use of the limited bandwidth. Surround sound distribution is not included in the scope of this profile.

Audio / Video Control Transport Protocol (AVCTP)
AVCTP describes the transport mechanisms to exchange messages for controlling A/V devices.

Audio / Video Distribution Transport Protocol (AVDTP)
AVDTP defines A/V stream negotiation, establishment and transmission procedures.

Audio/Video Remote Control Profile (AVRCP)
AVRCP is designed to provide a standard interface to control TVs, hi-fi equipment, or other to allow a single remote control (or other device) to control all the A/V equipment that a user has access to. It may be used in concert with A2DP or VDP.

AVRCP defines how to control characteristics of streaming media. This includes pausing, stopping and starting playback and volume control as well as other types of remote control operations. The AVRCP defines two roles, that of a controller and target device. The controller is typically considered the remote control device while the target device is the one whose characteristics are being altered. In a 「walkman」 type media player scenario, the control device may be a headset that allows tracks to be skipped and the target device would be the actual medial player.

This protocol specifies the scope of the AV/C Digital Interface Command Set (AV/C command set, defined by the 1394 trade association) to be applied, realizing simple implementation and easy operability. This protocol adopts the AV/C device model and command format for control messages and those messages are transported by the Audio/Video Control Transport Protocol (AVCTP).

In AVRCP, the controller translates the detected user action to the A/V control signal, and then transmits it to a remote Bluetooth enabled device. The functions available for a conventional infrared remote controller can be realized in this protocol. The remote control described in this protocol is designed specifically for A/V control only.

Basic Imaging Profile (BIP)
BIP defines how an imaging device can be remotely controlled, how an imaging device may print, as well as how an imaging device can transfer images to a storage device. BIP also includes the ability to resize and convert images to make them suitable for the receiving device. A typical scenario involves a mobile phone being used to control the shutter operation of a digital camera.

BIP may be broken down as follows:

* Image Push: Allows the sending of images from a device the user controls
* Image Pull: Allows the browsing and retrieval of images from a remote device
* Advanced Image Printing: Print images with advanced options using the DPOF format
* Automatic Archive: Allows the automatic backup of all the new images from a target device
* Remote Camera: Allows the initiator to remotely use a digital camera
* Remote Display: Allows the initiator to push images to be displayed on another device

Basic Printing Profile (BPP)
BPP allows devices to send text, e-mails, vCards, images or other items to printers based on print jobs. It differs from HCRP in that it needs no printer-specific drivers. This makes it more suitable for embedded devices such as mobile phones and digital cameras which cannot easily be updated with drivers dependent upon printer vendors.

BPP defines two roles, a sender and a printer. The sender is typically the mobile device such as a mobile phone or PDA which desires to print without the overhead of a driver. The printer is the device which renders the information to be printed. This is typically a physical printer or PC acting as a proxy for a printer connected via another physical transport such as USB.

BNEP
BNEP is used to transport common networking protocols over the Bluetooth media such as IPv4 and IPv6. The packet format is based on EthernetII/DIX Framing as defined by IEEE 802.3 (runs directly over L2CAP). BNEP is used by the Personal Area Networking Profile (PAN).

Common ISDN Access Profile (CIP)
CIP defines how ISDN signaling can be transferred via a Bluetooth wireless connection. CIP provides unrestricted access to the services, data and signaling that ISDN offers.

The purpose of the Common ISDN Access Profile (CIP) is as follows:

* To define how applications shall access ISDN over Bluetooth technology
* To allow wherever possible unrestricted access to services, data or signaling provided by ISDN
* To ensure that legacy ISDN applications do continue to work without any modification inside that application itself
* To define how the ISDN access co-exists with Bluetooth specifications that possibly access ISDN in one way or another
* To show how ISDN over Bluetooth technology can co-exist with existing ISDN in one application

Cordless Telephony Profile (CTP)
CTP defines how a cordless phone can be implemented over a Bluetooth wireless link. This profile can be used for either a dedicated cordless phone or a mobile phone that acts as a cordless phone when in proximity to a base station implementing the CTP. It is anticipated that mobile phones could use a Bluetooth CTP gateway connected to a landline when within the home, and the mobile phone network when out of range. CTP is central to the Bluetooth technology '3-in-1 phone' use case.

Dial-up Networking Profile (DUN)
DUN provides a standard to access the Internet and other dial-up services over Bluetooth technology. The most common scenario is accessing the Internet from a laptop by dialing up on a mobile phone wirelessly. It is based on SPP and provides for relatively easy conversion of existing products, through the many features that it has in common with the existing wired serial protocols for the same task. These include the AT command set specified in ETSI 07.07 and PPP.

Like other profiles built on top of SPP, the virtual serial link created by the lower layers of the Bluetooth protocol stack is transparent to applications using the DUN profile. Thus, the modem driver on the data-terminal device is unaware that it is communicating over Bluetooth technology. The application on the data-terminal device is similarly unaware that it is not connected to the gateway device by a cable.

DUN describes two roles, the gateway and terminal devices. The gateway device provides network access for the terminal device. A typical configuration consists of a mobile phone acting as the gateway device for a personal computer acting as the terminal role.

Extended Service Discovery Profile (ESDP)
ESDP defines how universal plug and play runs over a Bluetooth wireless technology connection.

Fax Profile (FAX)
The FAX profile defines how a FAX gateway device can be used by a terminal device. FAX is intended to provide a well defined interface between a mobile phone or fixed-line phone and a PC with FAX software installed. Support must be provided for ITU T.31 and / or ITU T.32 AT command sets as defined by ITU-T. A typical configuration is a personal computer using a mobile phone as a FAX gateway to send a FAX transmission to an arbitrary recipient.

File Transfer Profile (FTP)
FTP defines how folders and files on a server device can be browsed by a client device. Once a file or location is found by the client, a file can be pulled from the server to the client, or pushed from the client to the server using GOEP. The FTP profile includes support for getting folder listings, changing to different folders, getting files, putting files and deleting files. FTP uses OBEX as a transport and is based on GOEP.

FTP also defines client and server device roles and describes the range of their responsibilities in various scenarios. For example, if a client wishes to browse the available objects on the server, it is required to support the ability to pull from the server a folder-listing object. Likewise, the server is required to respond to this request by providing the folder-listing object.

Generic Access Profile (GAP)
GAP provides the basis for all other profiles and defines a consistent means to establish a baseband link between Bluetooth enabled devices. In addition to this, GAP defines the following:

* The features must be implemented in all Bluetooth devices
* Generic procedures for discovering and linking to devices
* Basic user-interface terminology

GAP ensures a high degree of interoperability between applications and devices. It also makes it easier for developers to define new profiles by leveraging existing definitions.

GAP handles discovery and establishment between devices that are unconnected. The profile defines operations that are generic and can be used by profiles referring to GAP and by devices implementing multiple profiles. GAP ensures that any two Bluetooth enabled devices, regardless of manufacturer and application, can exchange information via Bluetooth technology in order to discover what type of applications the devices support. Bluetooth enabled devices not conforming to any other Bluetooth profile must conform to GAP to ensure basic interoperability and co-existence.

General Audio/Video Distribution Profile (GAVDP)
GAVDP provides the basis for A2DP and VDP, the basis of the systems designed for distributing video and audio streams using Bluetooth technology. GAVDP defines two roles, an initiator and an acceptor. In a typical usage scenario, a device such as a 「walkman」 is used as the initiator and a headset is used as the acceptor.

GAVDP specifies signaling transaction procedures between two devices to set up, terminate and reconfigure streaming channels. The streaming parameters and encode/decode features are included in A2DP and VDP which depend on this profile.

Generic Object Exchange Profile (GOEP)
GOEP is used to transfer an object from one device to another. The object may be any object such as a picture, document, business card, etc. The profile defines two roles, a server that provides the location form which an object is pulled or pushed, as well as a client that initiates the action. Applications using GOEP assume that links and channels are established as defined by the GAP. The GOEP is dependent on the Serial Port Profile.

GOEP provides a generic blueprint for other profiles using the OBEX protocol and defines the client and server roles for devices. As with all OBEX transactions, GOEP stipulates that the client shall initiate all transactions. The profile does not, however, describe how applications should define the objects to exchange or exactly how the applications should implement the exchange. These details are left to the profiles that depend on GOEP, namely OPP, FTP and SYNC. Typical Bluetooth enabled devices using this profile are notebook PCs, PDAs, mobile phones and smart phones.

Hands-Free Profile (HFP)
HFP describes how a gateway device can be used to place and receive calls for a hand-free device. A typical configuration is an automobile using a mobile phone for a gateway device. In the car, the stereo is used for the phone audio and a microphone is installed in the car for sending outgoing audio. HFP is also used for a personal computer to act as a speaker phone for a mobile phone in a home or office environment. HFP uses SCO to carry a mono, PCM audio channel.

Hard Copy Cable Replacement Profile (HCRP)
HCRP defines how driver-based printing is accomplished over a Bluetooth wireless link. The profile defines a client and a server role. The client is a device containing a print driver for the server on which the client wishes to print. A common configuration is a client personal computer printing using a driver to a printer acting as a server. This provides a simple wireless alternative to a cable connection between a device and a printer. HCRP does not set a standard regarding the actual communications to the printer, so drivers are required specific to the printer model or range. This makes this profile more problematic for embedded devices which must update drivers. HCRP runs directly over L2CAP to avoid the overhead of RFCOMM / OBEX.

Headset Profile (HSP)
The HSP describes how a Bluetooth enabled headset should communicate with a computer or other Bluetooth enabled device such as a mobile phone. When connected and configured, the headset can act as the remote device's audio input and output interface. The HSP relies on SCO for audio and a subset of AT commands from GSM 07.07 for minimal controls including the ability to ring, answer a call, hang up and adjust the volume.

Human Interface Device Profile (HID)
The HID profile defines the protocols, procedures and features to be used by Bluetooth HID such as keyboards, pointing devices, gaming devices and remote monitoring devices. The HID profile uses the universal serial bus (USB) definition of a HID device in order to leverage the existing class drivers for USB HID devices. The HID profile describes how to use the USB HID protocol to discover a HID class device's feature set and how a Bluetooth enabled device can support HID services using the L2CAP layer. The HID profile is designed to enable initialization and control self-describing devices as well as provide a low latency link with low power requirements.

Intercom Profile (ICP)
ICP defines how two Bluetooth enabled mobile phones in the same network can communicate directly with each other without using the public telephone network. This function enables for example, the interconnecting of phones within an office. This profile has also been referred to as the walkie-talkie profile. It is a TCS based profile, relying on SCO to carry the audio.

Object Exchange (OBEX)
OBEX is a transfer protocol that defines data objects and a communication protocol two devices can use to exchange those objects. OBEX is designed to enable devices supporting infrared communication to exchange a wide variety of data and commands in a resource-sensitive standardized fashion. OBEX uses a client-server model and is independent of the transport mechanism and transport API. A Bluetooth enabled device wanting to set up an OBEX communication session with another device is considered to be the client device. The OBEX protocol also defines a folder-listing object, which is used to browse the contents of folders on remote device. RFCOMM is used as the main transport layer for OBEX.

OBEX enables applications to work over the Bluetooth technology protocol stack as well as the IrDA stack. For Bluetooth enabled devices, only connection-oriented OBEX is supported. Three application profiles have been developed using OBEX which include SYNC, FTP and OPP.

Object Push Profile (OPP)
OPP defines the roles of push server and push client. These roles are analogous to and must interoperate with the server and client device roles that GOEP defines. It is called push because the transfers are always instigated by the sender (client), not the receiver (server). OPP focuses on a narrow range of object formats to maximize interoperability. The most common acceptable format is the vCard. OPP may also be used for sending objects such as pictures or appointment details.

Personal Area Networking Profile (PAN)
PAN describes how two or more Bluetooth enabled devices can form an ad-hoc network and how the same mechanism can be used to access a remote network through a network access point. The profile roles include the network access point, group ad-hoc network, and PAN user. Network access points can be a traditional LAN data access point while group ad-hoc networks represent a set of devices that are only attached to one another. PAN is intended to allow the use of BNEP on Layer 3 protocols for transport over a Bluetooth wireless technology link.

RFCOMM
The RFCOMM protocol emulates the serial cable line settings and status of an RS-232 serial port and is used for providing serial data transfer. RFCOMM connects to the lower layers of the Bluetooth protocol stack through the L2CAP layer. By providing serial-port emulation, RFCOMM supports legacy serial-port applications while also supporting the OBEX protocol among others. RFCOMM is a subset of the ETSI TS 07.10 standard, along with some Bluetooth-specific adaptations.

Service Discovery Protocol (SDP)
SDP defines how a Bluetooth client application acts to discover an available Bluetooth enabled server services and characteristics. SDP provides means for the discovery of new services becoming available when the client enters an area where a Bluetooth enabled server is operating. SDP also provides functionality for detecting when a service is no longer available. SDP defines a service as any feature that is usable by another Bluetooth device. A single Bluetooth enabled device can be both a server and a client of services. An SDP client communicates with an SDP server using a reserved channel on an L2CAP link to find out what services are available. When the client finds the desired service, it requests a separate connection to use the service. The reserved channel is dedicated to SDP communication so that a device always knows how to connect to the SDP service on any other device. An SDP server maintains its own SDP database, which is a set of service records that describe the services the server offers. Along with information describing how a client can connect to the service, the service record contains the service's UUID, or universally unique identifier.

Service Discovery Application Profile (SDAP)
SDAP describes how an application should use SDP to discover services on a remote device. As required by the GAP, any Bluetooth enabled device should be able to connect to any other Bluetooth enabled device. Based on this, SDAP requires that any application be able to find out what services are available on any Bluetooth enabled device it connects to. The profile handles the search for known and specific services as well as searches for general services. SDAP involves an application, the service discovery user application, which is required in a Bluetooth device for locating services. This application interfaces with the SDP that sends and receives service inquiries to and from other Bluetooth enabled devices. SDAP is dependent on and re-uses parts of the GAP.

SIM Access Profile (SAP)
SAP allows devices such as car phones with built in GSM transceivers to connect to a SIM card in a Bluetooth enabled phone. Therefore the car phone itself does not require a separate SIM card.

Serial Port Profile (SPP)
SPP defines how to set-up virtual serial ports and connect two Bluetooth enabled devices. SPP is based on the ETSI TS07.10 specification and uses the RFCOMM protocol to provide serial-port emulation. SPP provides a wireless replacement for existing RS-232 based serial communications applications and control signals. SPP provides the basis for the DUN, FAX, HSP and LAN profiles. This profile supports a data rate of up to 128 kbit/sec. SPP is dependent on GAP.

Synchronization Profile (SYNC)
The SYNC profile is used in conjunction with GOEP to enable synchronization of calendar and address information (personal information manager (PIM) items) between Bluetooth enabled devices. The profile also describes how an application can support automated synchronization. A common application of this profile is the exchange of data between a PDA and computer. SYNC defines client and server device roles. The profile is also commonly referred to as IrMC synchronization.

Telephony Control Specification (TCS-Binary or TCP)
TCP defines how a Bluetooth enabled device can be used as wireless phone and how a Bluetooth enabled mobile phone should switch to Bluetooth enabled wireless phone-function when it comes within reach of a Bluetooth enabled base station. TCP is a bit oriented protocol that defines the call control signaling for the establishment of speech and data calls between Bluetooth enabled devices. It also defines the signaling for the handling of groups of Bluetooth enabled devices. TCP also supports the establishment of a voice or data call in a point-to-point configuration or point-to-multipoint configuration. This protocol is based on the ITU-T recommendation Q.931 and runs directly over L2CAP.

Video Distribution Profile (VDP)
VDP defines how a Bluetooth enabled device streams video over Bluetooth wireless technology. Sample use cases include the streaming of a stored video from a PC media center to a portable player or streaming from a digital video camera to a TV. The profile mandates support for H.263 baseline. The support for MPEG-4 visual simple profile and H.263 profiles 3 and 8 are optional and covered in the specification.

WAP Over Bluetooth Profile (WAP)
WAP defines how the wireless application protocol suite can run over a Bluetooth wireless technology link. A typical configuration is a mobile phone connecting to a public kiosk over a Bluetooth technology link and using WAP to browse for information. WAP works across a variety of WAN technologies bringing the Internet to mobile devices. Bluetooth technology can be used to provide a bearer for transporting data between the WAP client and an adjacent WAP server. The ad hoc networking capabilities offered by Bluetooth technology gives a WAP client unique possibilities regarding mobility compared with other WAP bearers. The traditional form of WAP communications involves a client device that communicates with a server/proxy device using the WAP protocols. WAP technology supports server push. Used over Bluetooth technology, this protocol offers many possibilities for distributing information to handheld devices on location basis.

PS : 轉貼BlueTooth.com

Echo Cancellation

當來源端所發出的聲音，經過一段時間的延遲後，反射回來源端，且其能量大到足夠讓使用者察覺，就會產生回音 (echo)；會產生回音的環境很多，例如，當使用者使用免持模式時，由喇叭放出的聲音及其反射之後的訊號，會被麥克風所捕捉，形成回音。
##CONTINUE##


解決回音問題的方式有好幾種，例如：適當擺放麥克風與喇叭之間的位置，使得喇叭所發出的聲音不會進到麥克風，或進到麥克風後能量小到讓使用者無法察覺；使用回音抑制器（Echo Suppressor），在傳送訊號時，關閉接收路徑，換言之，即是以半雙工傳送；使用回音消除器（Echo Canceller），在傳送訊號時，先將麥克風所接收到的訊號減去系統所估計出來的回音後，再將訊號發送出去。

在一般的電信系統中，存在著兩種種類的回音：線回音 (line echo) 及聲學回音(acoustic echo)。線回音是由於存在交換線路中的hybrid 的阻抗不匹配所產生的；聲學回音則
是由喇叭放出聲音後，再進入麥克風所產生的。回音對使用者造成的影響取決於回音的強度及延遲；當回音的強度太小，使用者無法察覺；當回音的延遲太短，使用者亦無法分辨出來。故強度和延遲，是回音可否被使用者察覺的兩個主要因素。

回音消除器的精神在於模擬出回音路徑(Echo Path) 的空間模型 (impulse response)，依據此模型，計算出遠端訊號 (Far-End Signal)透過喇叭放出，經過空間，由麥克風捕捉後，所會產生的回音，並將麥克風實際所收到的聲音減去此計算出來的回音；如果模擬的模型夠精準，使得計算出來的回音與實際的回音一樣的話，最後送出的聲音即可將回音消除，但不影響近端使用者所發出的聲音。


PS : 來源轉貼於鍾國煌之“回音消除器在嵌入式系統上之設計與分析（Design and Analysis of Echo Canceller on Embedded System）“

[XXX661]為Driver加入global變數

當driver間想使用共同變數時，可以於drvglob.h(...\PUBLIC\COMMON\OAK\CSP\ARM\CXXX..Y\AT4X0A\SRC\INC)中加入變數：
##CONTINUE##
typedef struct _MISC_GLOBALS
{
UCHAR offButton; // Indicate to keyboard driver when OFF button pressed
UCHAR bSysGoingSleep;
...........
DWORD iPCMStatus; //0:PCM Mode 1:Normal Mode
DWORD iRotate;
} MISC_GLOBALS, *PMISC_GLOBALS;

一般只要在MISC_GLOBALS內加入即可，在這宣告的變數皆會屬於DRIVER_GLOBALS 這個Structure，由於在drvlib.h中已經宣告了一個DRIVER_GLOBALS的變數：

volatile DRIVER_GLOBALS *m_pDriverGlobals;
.....

#define v_pDriverGlobals (g_cspRegs.m_pDriverGlobals)

因此，當我們加入自己的變數之後，使用時僅需在driver中include drvlib.h這個檔，就可以開始使用了：
例如：
v_pDriverGlobals->misc.iEchoStatus = 3;


PS：感謝Jimmy學長的提示！

讓通話中能調整聲音與麥克風的音量

調整通話中的音量可以從XX9712與XX1182來調整，由於在XX9712中更改有可能會更動到其他狀態下的設定值，且XX1182原本就可以在Runtime模式下，藉由UART傳送AT Command來達到動態調整的功能，因此由XX1182來調整，在實踐上應該會比較簡單！
##CONTINUE##
首先，必須先知道在通話模式時，調整聲音的音量是由哪個driver所控制，根據Roland的說法，通話時音量的控制是由audio_api.dll所控制，即platform\bluetooth\PCM_Audio_Control.cpp，在此程式中有四個function：SetAudioVolume、GetAudioVolume、SetAudioMicVolume及GetAudioMicVolume分別對應到speaker與microphone的音量大小，因此只要在此加入控制程式即可！

為了要能控制XX1182，所以必須在XX1182的IOControl中加入相對應的程式：

case IOCTL_FME_PCM_VOLLEVEL:
{
unsigned char FmInitStr[][7] ={
{0xFC, 0xF3, 0x3B, 0x1E,0x3D,dwLenOut,0x00},
{0xFC, 0xF3, 0x3B, 0x1E,0x3A,0x00,0x00}
};
for(i=0;i<2;i++) bresult =" WriteFile" val =" dwLenOut;" i="0;i<2;i++)" bresult =" WriteFile" val =" dwLenOut;" style="color: rgb(255, 255, 51);">PCM1SpkVol、PCM2SpkVol、PCM1MicVolPCM2MicVol用來儲存兩中模式下speaker與microphone的音量大小。

增加好控制碼後，在PCM_Audio_Control.cpp中就可以控制XX1182的輸出音量了：

DllExport void SetAudioVolume(AudioLevel audioLevel)
{
HANDLE g_hFM1182=NULL;
USHORT parm01=0;
DWORD dwRet;
g_hFM1182 = CreateFile(L"FME1:",0,0,NULL,OPEN_EXISTING,0,NULL);
if (INVALID_HANDLE_VALUE == g_hFM1182)
{
RETAILMSG(0, (TEXT("=====Error calling CreateFile on g_hFM1182\r\n")));
}
else
{
RETAILMSG(0, (TEXT("=====Calling CreateFile on g_hFM1182 Success!!\r\n")));
dwRet = DeviceIoControl(g_hFM1182,IOCTL_FME_PCM_SPKVOLLEVEL,
&parm01,sizeof(USHORT),NULL,(DWORD)audioLevel,NULL,NULL);
}
CloseHandle(g_hFM1182);
}

DllExport AudioLevel GetAudioVolume(void)
{
HKEY hkey;
LONG lResult;
DWORD dwType, dwSize;
unsigned short dvalue;
dwSize = 4;

if (RegOpenKeyEx(HKEY_LOCAL_MACHINE, _T("SOFTWARE"), 0, KEY_QUERY_VALUE, &hkey) != ERROR_SUCCESS)
return 0;

if(PIO_READ_INPUT(GPIO, GPIO_GROUP(3),GPIO_INDEX(20)))
{
lResult = RegQueryValueEx(hkey, _T("PCM2SpkVol"), NULL, &dwType, (LPBYTE)&dvalue, &dwSize); //query registry value
}
else
{
lResult = RegQueryValueEx(hkey, _T("PCM1SpkVol"), NULL, &dwType, (LPBYTE)&dvalue, &dwSize); //query registry value
}

RegCloseKey(hkey);
return dvalue;

}

DllExport void SetAudioMicVolume(AudioLevel audioLevel)
{
HANDLE g_hFM1182=NULL;
USHORT parm01=0;
DWORD dwRet;
g_hFM1182 = CreateFile(L"FME1:",0,0,NULL,OPEN_EXISTING,0,NULL);


if (INVALID_HANDLE_VALUE == g_hFM1182)
{
RETAILMSG(0, (TEXT("=====Error calling CreateFile on g_hFM1182\r\n")));
}
else
{
RETAILMSG(0, (TEXT("=====Calling CreateFile on g_hFM1182 Success!!\r\n")));
dwRet = DeviceIoControl(g_hFM1182,IOCTL_FME_PCM_VOLLEVEL,
&parm01,sizeof(USHORT),NULL,(DWORD)audioLevel,NULL,NULL);
}
CloseHandle(g_hFM1182);
}

DllExport AudioLevel GetAudioMicVolume(void)
{
HKEY hkey;
LONG lResult;
DWORD dwType, dwSize;
unsigned short dvalue;
dwSize = 4;

if (RegOpenKeyEx(HKEY_LOCAL_MACHINE, _T("SOFTWARE"), 0, KEY_QUERY_VALUE, &hkey) != ERROR_SUCCESS)
return 0;

if(PIO_READ_INPUT(GPIO, GPIO_GROUP(3),GPIO_INDEX(20)))
{
lResult = RegQueryValueEx(hkey, _T("PCM2MicVol"), NULL, &dwType, (LPBYTE)&dvalue, &dwSize); //query registry value
}
else
{
lResult = RegQueryValueEx(hkey, _T("PCM1MicVol"), NULL, &dwType, (LPBYTE)&dvalue, &dwSize); //query registry value
}

RegCloseKey(hkey);
return dvalue;
}

目前，通話中的音量可以動態的控制(若想讓聲音靜音，只需將gain值設為即可)，不過當通話結束後，gain值的大小會再回復為預設值，不會儲存通話時的調整值！

讓調整參數更方便

由於聲音的調整經常需要不斷的調整與測試，如果在整機的狀態下，又不能跳線，那從修改參數，compile code，build image以及download image，光是修改一次參數的時間可能就要光掉5分鐘的時間了，效率上蠻差的！
##CONTINUE##
在Roland的建議以及幫助下，為了改參數能更快更方便，同時，希望能在讓客戶自行調整參數又不需要更動到driver的情形下，把參數的設定值儲存到一個文字檔上，再由driver來讀檔以及設定值！

1.
因為在此案中，Audio Path共有6種，所以必須準備6個檔分別對應至這6種情形，然後在Windows CE的 Registry下加入6個參數，儲存這四個檔的放置位置與檔名 :在Platform.reg中加入6個參數

[HKEY_LOCAL_MACHINE\SOFTWARE]
"File1"="\\Windows\\Bypass1.txt"
"File2"="\\Windows\\Bypass2.txt"
"File3"="\\Windows\\Bypass3.txt"
"File4"="\\Windows\\Bypass4.txt"
"File5"="\\Windows\\pcm01.txt"
"File6"="\\Windows\\pcm02.txt"

2.
在driver裡加入讀取Registry值與讀取檔案內值的function：傳入要讀取Registry的值並讀取相對應的檔案，再透過UART將值傳送至XX1182中。

int XX1182Write(HKEY key, TCHAR *subkey, TCHAR *name, HANDLE hComPort)
{
HKEY hkey;
LONG lResult;
TCHAR str[MAX_PATH], *pStr;
DWORD dwType, dwSize;
FILE *file;
unsigned char pData[7];
int i, nResult;

if (RegOpenKeyEx(key, subkey, 0, KEY_QUERY_VALUE, &hkey) != ERROR_SUCCESS)
return 0;

dwSize = sizeof(str);
lResult = RegQueryValueEx(hkey, name, NULL, &dwType, (LPBYTE)str, &dwSize); //query registry value
RegCloseKey(hkey);
if (lResult != ERROR_SUCCESS || dwType != REG_SZ)
return 0;

file = _tfopen(str, _T("rt"));
if (file == NULL) //open file failed
return 0;

nResult = 0;
while (_fgetts(str, MAX_PATH, file))
{
pStr = _tcsstr(str, _T("//"));
if (pStr) //there is comment
*pStr = _T('\0'); //remove comment

pStr = str;
for (i = 0; i < pstr =" _tcsstr(pStr,">= _T('0') && *pStr <= _T('9')) pData[i] = (pData[i] <<>= _T('A') && *pStr <= _T('F')) pData[i] = (pData[i] <<>= _T('a') && *pStr <= _T('f')) pData[i] = (pData[i] << i ="="">misc.iEchoStatus == 0)
{
nLine = XX1182Write(HKEY_LOCAL_MACHINE, _T("SOFTWARE"), _T("File1"), hFile);
CloseHandle(hFile);
}
else if(v_pDriverGlobals->misc.iEchoStatus == 1)
{
nLine = XX1182Write(HKEY_LOCAL_MACHINE, _T("SOFTWARE"), _T("File2"), hFile);
CloseHandle(hFile);
}
else if(v_pDriverGlobals->misc.iEchoStatus == 2)
{
nLine = XX1182Write(HKEY_LOCAL_MACHINE, _T("SOFTWARE"), _T("File3"), hFile);
CloseHandle(hFile);
}
else
{
nLine = XX1182Write(HKEY_LOCAL_MACHINE, _T("SOFTWARE"), _T("File4"), hFile);
CloseHandle(hFile);
}
break;

case IOCTL_FME_PCM_MESSAGE:
//PCM spk -> out2 echo cancellation on
nLine = XX1182Write(HKEY_LOCAL_MACHINE, _T("SOFTWARE"), _T("File6"), hFile);
CloseHandle(hFile);
break;

case IOCTL_FME_PCM_MESSAGE2:
//PCM spk -> out2 echo cancellation on
nLine = XX1182Write(HKEY_LOCAL_MACHINE, _T("SOFTWARE"), _T("File5"), hFile);
CloseHandle(hFile);
break;


藉由此方式，確實可讓調整參數更快也更方便，可直接在Windows CE直接更改相對應的文字檔來調整，driver的不份則不需再更動，不過，缺點則是執行時間會變長。

XX1182設定方式

XX1182在此案子主要用來echo cancellation and noise suppression，包括錄音與與藍芽連接時PCM的聲音處理。
此Chip的參數設定方式透過UART傳入Commond的方式來更改，透過修改不同Memory Address位址，可以設定聲音傳送的路徑、設定microphone與speaker的pgagain值大小等。
##CONTINUE##
Command的格式是以FCF3為開頭作為sync word，例如：

寫值：
FC F3 3B 1E 34 00 55 代表 write memory 1E34 with 0055

讀值：
FC F3 37 1E 34 代表 read memory contents of 1E34

因此，在driver中，我們可以利用一個Array來儲存要修改的參數：
unsigned char FmInitStr[][7] ={
{0xFC, 0xF3, 0x3B, 0x1E, 0x30, 0x02, 0x21},
{0xFC, 0xF3, 0x3B, 0x1E, 0x34, 0x00, 0x0F},
{0xFC, 0xF3, 0x3B, 0x1E, 0x3D, 0x0A, 0x00},
{0xFC, 0xF3, 0x3B, 0x1E, 0x41, 0x00, 0x01},
{0xFC, 0xF3, 0x3B, 0x1E, 0x44, 0x00, 0x01},
{0xFC, 0xF3, 0x3B, 0x1E, 0x45, 0x00, 0xDE},
{0xFC, 0xF3, 0x3B, 0x1E, 0x46, 0x00, 0x10},
{0xFC, 0xF3, 0x3B, 0x1E, 0x36, 0x00, 0x1F},
{0xFC, 0xF3, 0x3B, 0x0F, 0xA9, 0x00, 0x80},
{0xFC, 0xF3, 0x3B, 0x1E, 0x70, 0x07, 0xC0},
{0xFC, 0xF3, 0x3B, 0x1E, 0x52, 0x00, 0x07},
{0xFC, 0xF3, 0x3B, 0x1E, 0x51, 0xC0, 0x00},
{0xFC, 0xF3, 0x3B, 0x1E, 0x3A, 0x00, 0x00}
};

然後再利用一個迴圈依序將Commond透過UART傳入即可！
for(i=0;i<13;i++) bresult =" WriteFile" style="color: rgb(255, 255, 51);">IE65的值，若是正常狀況下，讀取的值會不斷的增加，反之，則為0。

讓Source Insight顯示完整路徑名稱

##CONTINUE##
Source Insight預設顯示路徑會簡化，常常會無法得知更改的檔案是否我們想要更改的！
所以如果想要顯示完整的路徑，需要到Options\Preferences\Display裡更改一下設定，如下圖：


將Trim long path names with ellipses選項取消，如此就會顯示完整的名稱了！
紀錄一下，免得下次重灌電腦時又忘了！

Jackie婚禮於豪園飯店

SyncBack 免費好用的資料備份及同步軟體

##CONTINUE##


目的：同步Server與桌機上Project的資料！


商業軟體有 SyncBackSE 與 SyncBackPro。
免費的版本則是 SyncBack。
http://www.2brightsparks.com/

使用上蠻簡單的，如圖，選擇來源與目的資料夾，來源的話可以選擇Server上的Project的資料夾，目的的話就選擇本機的資料夾就可以了！
至於運作方式，我是選擇備份來源資料夾資料，避免更改Server上的資料。
接著執行就可以了！

wince下加載驅動程式

加載流驅動程序有三種方法：

第一種加載類型是在系統啟動的時候進行的。當Winows CE的平台啟動的時候，設備管理器(Device.exe)從註冊表的HKEY_LOCAL_MACHINE\Drivers\RootKey下面加載入口點，通常RootKey的值都被設置為Drivers\BuiltIn。然後設備管理器(Device.exe)通過\RootKey提供的入口點開始讀取 HKEY_LOCAL_MACHINE \Drivers\Builtin的內容，並加載已列出的驅動程式。
##CONTINUE##
第二種加載的類型是在設備管理程式自動檢測外圍設備設備與基於Windows CE平台的連接時進行的。

第三種加載類型是當設備管理器程序不能夠自動檢測或加載某一種驅動程式的時候，這個時候的可以使用系統提供的函數ActivateDeviceEx函數來加載驅動程序。

HANDLE ActivateDeviceEx(
LPCWSTR lpszDevKey,
LPCVOID lpRegEnts,
DWORD cRegEnts,
LPVOID lpvParam
);
lpszDevKey ：[HKEY_LOCAL_MACHINE]下的登錄機碼名稱
lpvParam：傳送至驅動程式的Init函式中的指標。
傳回值：裝置的控制碼，可用來卸載Driver時傳送之參數！

以PCT661的PowerButton Driver為例：

方法一：
若在Platform.reg中已經有定義相關資訊，則必須在相關設定中加入"Flags"的參數，並將值定為4

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\PWRBUTTON]
"Prefix"="PWR"
"Dll"="PwrButton.Dll"
"Order"=dword:2
"Ioctl"=dword:4
"KeyMuxTime"=dword:64 ; 100 ms
IF BSP_ATLAS_KEYPANEL_V3
"KeyMuxValue"=dword:C3 ; VK_APP3
ELSE
"KeyMuxValue"=dword:d ; VK_RETURN
"Flags"=dword:4


Flags設定為4表示系統開機時不去載入此driver！
有關Flags參數設定，可參考MSDN裡ActivateDeviceEx()說明！

接著就可以在AP中呼叫ActivateDeviceEx()
Step1 :
呼叫前須先將"Flags"的值設為0，Driver才能成功被載入：
if(RegCreateKeyEx( HKEY_LOCAL_MACHINE,szPWRBTNDevKey,0,_T("PWRBUTTON"),REG_OPTION_VOLATILE,0,NULL,&hKey,&dwDisposition) == ERROR_SUCCESS)
{
DisplayData(TEXT("RegCreateKeyEx Success"));

val = 0; RegSetValueEx(hKey,_T("Flags"),0,REG_DWORD,(PBYTE)&val,sizeof(DWORD));
RegCloseKey(hKey);
}
Step2 :
呼叫ActivateDeviceEx()：
TCHAR szPWRBTNDevKey[] = _T("Drivers\\BuiltIn\\PWRBUTTON");
hDev = ActivateDeviceEx( szPWRBTNDevKey, NULL, 0, NULL );


方法二：
若沒有在Platfom.reg中設定Registry相關資料，則必須在載入前於Registry自行加入相關設定：

if(RegCreateKeyEx( HKEY_LOCAL_MACHINE,szKeyPADDevKey,0,
_T("KEYPAD"),REG_OPTION_VOLATILE,0,NULL,&hKey,&dwDisposition) == ERROR_SUCCESS)
{
RegSetValueEx(hKey,_T("Prefix"),0,REG_SZ,(const BYTE*)TEXT("PWR"),sizeof(TEXT("PWR")));
RegSetValueEx(hKey,_T("Dll"),0,REG_SZ,(const BYTE*)TEXT("touchpad.dll"),sizeof(TEXT("PwrButton.dll")));
val = 4;
RegSetValueEx(hKey,_T("Ioctl"),0,REG_DWORD,(PBYTE)&val,sizeof(DWORD));
val = 100;
RegSetValueEx(hKey,_T("KeyMuxTime"),0,REG_DWORD,(PBYTE)&val,sizeof(DWORD));
...............
RegCloseKey(hKey);
}
接著一樣再呼叫ActivateDeviceEx()

若想卸載Driver，則可以呼叫DeactivateDevice()

DeactivateDevice(hDev);
hDev為ActivateDeviceEx()之傳回值

問題：

* 有些Driver無法成功載入，如Bluetooth
* 有些Driver只能載入一次，卸載後無法再載入第二次，例如KEYPAD

2007高中同學會

算一算，離高中畢業也有16年了，看看大家似乎都找到自己的生活方式，有人已經做到經理了，也有人放棄工程師的生活，從頭學習調音的技術，目前已經是台灣最年輕的管風琴調音師了！當然也有人和我一樣還在找尋目標，希望明年的同學會還有更多人參加，也祝等綠卡的人今年能成功拿到，明年見了！