漢亞科技 Han-Ya

2011 March, 開始開發蘋果的認證機制，這套協定稱為 iPod Authentication Protocol (iAP)，藉由蘋果自訂的通訊協定可以認證非蘋果的周邊硬體附件。通過認證的軟硬體才能在蘋果的平台上使用，iOS也才會傳遞一些軟硬體需要的 command & event。有了這個機制，軟體便可取得硬體的訊息，應用面將會更廣，硬體也可取得蘋果平台的服務。
iAP 通訊協定有三種傳遞媒介，其中兩種方式是有線的，必須有蘋果的 30-pin 的傳輸接頭，利用 30-pin 當中的 UART 或者 USB 來傳送協定。另一種方式是無線的藍芽，iAP 由藍芽來傳送。蘋果提供一顆認證處理的晶片(Authentication CoProcessor)，主要是加解密的計算。
2011 April, 已經可以通過 iPhone 認證了，接上一個外部 USB 鍵盤後，可以在 iPhone 備忘錄裡打字。

 
使用 FTDI VNC2 做為 USB host 控制器，一端接著 debugger 給開發平台 IDE 之用。另外，拉出 UART 線路到PC，我們可透過超級終端機看到 trace。雖然 FTDI 提供 function calls，但有幾個怎麼都會出錯呢？特別是 Hub 功能的函式。
2011 Feb, FTDI 發布了 1.4.0 的版本，解決了部分 function call 的問題，但是對於 FTDI 外接一個 hub 卻沒有辦法做到熱插拔的偵測。

2010, July 開始研究 BlueCore5 MM 的使用，包括語音的 PCM 通訊介面與 I2C 控制介面，正在學習在開發板子上面的設定與控制。
2010, August 已經成功控制 PCM 介面中的 I2S 以及 I2C 介面，同時研究 HFP and A2DP profile，還有 PS tool 的使用。CSR 晶片有太多灰色空間，使用者無法 touch 的地方。
這塊開發板幫助我們開發出 iFusion 產品，請看http://thefusionphone.com 可做為音樂播放器,話機,充電器...等多功能的 iPhone 基座。

Mifare 讀寫模組常見於悠遊卡，模組中一顆 8-bit 控制晶片和一顆無線晶片，透過 RS-232 界面傳送資料與控制訊號。搭配 DSP 控制器，系統運用於停車場系統。請參考新詠科技。

eZ430-RF2500 無線傳輸套件包含 MSP430F2274 微控制器與 Chipcon CC2500 無線晶片，除此之外，內附一個 USB 介面的燒錄硬體，可以將程式碼燒到無線模組上，整組套件費用約 50 美金。
CC2500 一顆2.4GHz的傳收器，主要操作在2400-2483.5MHz的頻段。這個頻段提供工業、研究、與醫療之用，或是短通訊設備之用。晶片的參數設定透過 SPI 介面來控制﹙pin-1, 2, 7, 20﹚，晶片有兩個 64-byte FIFO 分別做為傳輸與接收之用。
MSP430F2274 總共有四組數位I/O（Port-1～Port-4），每組數位I/O有8個接腳。這些數位I/O除了當作GPIO使用之外，也可以設置成特殊的周邊控制，如：Timer、ADC（Analog to Digital Conversion）、USCI（Universal Serial Communication Interface）…等。
        學習 IAR IDE 開發環境的使用，如何透過 BootStrap Loader (BSL) or JTAG 將程式碼燒錄到 MSP430 晶片裡，研究開機的過程到載入主程式。在主程式中，設定 clock 以便提供適當的時脈給周邊通訊使用，設定接腳的工作模式。
 
MSP430 控制晶片, RF 晶片(Chipcon 2500), 天線晶片 (前端白色方塊體)

        美商英特爾–Intel^TM提供了『Intel Integrated Performance Primitives』（簡稱︰Intel IPP），這是一套跨平臺的軟體元件庫。這套函式庫提供了廣泛的多媒體功能：音頻解碼器（例如：H.263、MPEG-4）、圖像處理（JPEG）、信號處理、語音壓縮（例如：G.723、GSM、AMR）和加密機制。「Intel IPP」包含各種的函數，用於進行向量與圖像處理、顏色轉換、過濾、分屏、變換，以及算術、統計、幾何與形態運算。對於每個函數，「Intel IPP」均支持多種資料類型和佈局，同時保持了資料結構的最小化，它提供了豐富的選項供用戶在設計與最佳化應用程式時選用，不必再去編寫特定代碼。Intel IPP針對多數的 Intel Microprocessor（微處理器）進行最佳化，包括︰Intel Pentium 4處理器、採用 Intel Centrino 移動運算技術的 Intel Pentium M處理器組件，Intel Itanium 2處理器、Intel Xeon處理器、以及採用 Intel XScale 技術的 Intel PCA應用處理器。採用一套跨平台結構的通用API，使用者除了不需要擔心平台相容性的問題，更節省了開發成本以及研發時間，使用者可以輕輕鬆鬆移植原有應用程式。
        隨著伺服器上的 CPU 運算速度越來越快，價格比起DSP晶片便宜許多，因此在 DSP 伺服器的設計上採用 CPU 當作數位信號運算的核心，這種設計方式稱為 HMP（Host Media Processing），取代過去以 DSP 晶片作為加速器的設計方法。這種以 HMP 為主的模式已經常見於VoIP（Voice Over IP）或者 video-over-IP 的設備，主因是 Intel 英特爾和 AMD 超微的 x86 CPU具備快速的運算能力，足以應付語音或影像訊號的處理，並且不需要額外 DSP 晶片的協助了。
         以VoIP或video-over-IP系統為例，採用 HMP 模式的設計再搭配一些通訊協定的軟體，而這些通訊協定的來源多數取自於開放的原始碼（open source），因此設備廠商可以很快地實現出VoIP或video-over-IP系統。目前像是Dialogic或NMS電信設備公司已經提供 HMP 為基礎的通訊系統，甚至這種HMP的設計模式有助於一些通訊設備的小廠只需雇用數十位軟體工程師便能設計出多媒體通訊系統，像︰SS7、SIP、H.323、H.248、和H.264…等，對於這些設備小廠有助於降低設計的成本。雖然上面說明了HMP設計概念的優點，不過也有其缺點，說明如下。
晶片市場的競爭
        過去十多年來，CPU製造大廠–英特爾–努力打造一個“沒有DSP的世界”，其中 HMP 設計概念只是英特爾最新的命名而已，其實最早概念來自於90年代中期的NSP（Native Signal Processing）雛型。儘管英特爾有此雄心壯志，但是在90年代中期DSP晶片製造商與FPGA廠商如雨後春筍般的崛起，像︰德州儀器（Texas Instruments）、飛思卡爾（Freescale）、Mindspeed、智霖（Xilinx）、Altera…等科技公司，在DSP晶片銷售方面比過去幾年更好。因為這些DSP晶片製造商利用x86架構在運算效率不彰的缺點大肆擴大市佔率，不過同時英特爾也致力於改善x86架構的效率問題。
        前述的競爭都是以每顆晶片核心能處理多少MIPS做比較，對於英特爾而言，這僅是從晶片等級的角度切入DSP市場。然而，為了更準確地評估晶片價格所能帶來的效能，必須在價格與效能之間取得一個平衡點，因此以全系統的角度切入DSP市場更是必然的趨勢。例如︰以目前CPU的效能而言，在Intel雙核心伺服器上可以處理250個G.729語音通道，但是考慮到消耗的功率、產生的熱氣、I/O的限制、需要多少DRAM…等系統方面的問題，加上風扇排熱之後整個系統體積將變大，是否要使用以CPU處理數位信號呢？值得從全系統的角度思考。
        同樣地，若採用德州儀器的DSP晶片，以12張DSP加速板卡，每張卡具備6個DSP核心為例（總共72個核心），再加上Gigabit的網路處理器，這樣設備並不需要風扇排熱卻可以處理1150個G.729語音通道。此外，利用網路介面作為資料匯流，也無需考慮因作業系統所造成的I/O限制。想想看，如果架設五部Intel雙核心伺服器，我們能夠在相同的系統體積以及相同的功耗情況下而做到上述DSP晶片的功效。這就是使用HMP設計概念或者採用DSP晶片的問題。
       以HMP為基礎的設計概念來看，其優點在於便利的開發環境、快速實現DSP系統、價格比DSP晶片低廉，但是其缺點是無法有效地運作於高容量的DSP系統。因此，在低容量的系統，HMP的架構是很有競爭力的。不過，當系統的通道數目增加時，為了改善系統效能，有時我們需要考慮加上一個DSP晶片當作加速器（DSP accelerator），這個外加的硬體卻增加了每個通道的成本。HMP架構在不使用DSP加速器的情況下， 每個通道的成本隨著通道數目的增加而下降，但是當通道數增加到需要DSP加速器的協助時，每個通道成本就不再下降了。在設計HMP系統時有幾項指標需要留意︰
(1) 系統的通道數目
(2) 平均花費在每個通道的費用
(3) 演算法的智慧財產權
(4) 系統所消耗的功率
       系統的通道數在何種情況下採用DSP加速器較為適合呢？從通道數和codec的複雜度來觀察，圖中說明HMP與DSP加速器之間的關係（以3 GHz雙核心的 Xeon 伺服器為例），x軸表示系統的通道數目，y軸表示codec的複雜度，包括︰G.711、G.729、GSM-AMR和EVRC。其中以G.711為例，當通道數目低於1000個的時候，採用HMP的架構較為合適，通道數高於1000個時，最好是HMP架構加上DSP晶片加速器。就G.729而言，通道數120就是個門檻，隨著處理的複雜度增高，HMP架構便無法滿足太多的通道同時進行運算。所以通道數與複雜度是以HMP為基礎的伺服器需要考量的設計參數之一。
        在低容量的系統，HMP架構在價格性能比方面遠高於DSP，價格性能比主要針對每個通道所花費的成本。對於G.711 VoIP的系統而言，DSP加速器根本不需要，只需要HMP架構就能達成，除非系統的通道數達到500以上。圖中說明平均每個通道所花的費用與系統容量的關係，x軸表示系統的通道數目，y軸表示平均每個通道的花費，圖中的曲線代表多了DSP加速器之後平均的費用。
        以G.711語音編碼為例，當系統通道數超過500以上，若採用DSP晶片協助HMP架構的話，平均每個通道的價格會下降；當系統通道數低於500個，通道所花費的價格就是整個HMP系統的價格。其他的codec處理也呈現相同的價格趨勢︰通道數越多採用DSP加速器越顯經濟效益。如果沒有外加使用DSP加速器的話，整個HMP系統將會因為通道數目增加而消耗功率也增加，CPU熱能增加，這時候反而要添加散熱的硬體設備，還要擔心系統的功耗過大而造成的不穩定，這些反而增加了通道的平均花費。
        另外，設計HMP系統時所要考慮的問題還有智慧財產權的費用，以及系統功率的消耗。例如︰在HMP平台中，當一個VoIP的系統中需要超過100個G.729通道時，誰要付每個系統中G.729的權利金呢？通常DSP晶片製造商已經將這部份的權利金分攤到每顆晶片上了，像德州儀器因為手中握有一些關鍵專利，所以權利金的談判中可以取得較優惠的價格，但是英特爾擁有很多像德州儀器在語音和影像方面的專利嗎？
        如果不使用DSP加速器，但是增加HMP伺服器的個數，從系統功率消耗的角度來看其實並不經濟。因為每部伺服器都需要人力的維護，而且越多伺服器組成的群組更需要額外的硬體設備來維護與連結，像︰排線、風扇、電源線…等。因此，當設計DSP系統時，以上的說明提供我們很多設計的概念，採用HMP的架構或DSP晶片加速器，以及兩者的優缺點。可預測的未來中，DSP晶片製造商或FPGA廠商還是持續改善數位信號處理的效能上，DSP加速器在HMP平台上還是佔有一席之地。

      程曦資訊整合股份有限公司採用AltiGen Communications (奧迪堅通訊系統)系統整合方案以優異的口碑和亮眼的實績，在繼勞委會就業服務科技客服中心、臺灣中油客服中心、高雄捷運客服中心及法律扶助基金會客服中心、職災諮詢專線等政府及國營事業客服營運的成功案例後，再度榮獲臺北市政府的青睞，成為「1999臺北市民當家熱線」的最新委外團隊，為程曦在政府客服領域再下一城！
       在全球企業仍壟罩在金融風暴陰霾之際，客戶服務領域卻是逆勢成長！繼1999臺北市民當家熱線、勞委會職災諮詢專線、1999苗栗縣熱線後，程曦今年再度榮獲政府單位青睞，於2009年4月中順利承接青輔會「98年度青年創業資訊服務話務中心」專案，在政府客服領域成功再下一城！
       2009年可說是程曦資訊在公部門客服中心委外案中大有斬獲的一年，繼「1999台北市民當家熱線」、「青輔會青年創業諮詢專線」、「苗栗縣政府1999」、「1955外勞諮詢保護專線」後，程曦資訊與國內電信業龍頭- 中華電信合作，再度憑藉著豐富的客服系統建置及營運經驗，贏得「台中市政府1999」話務中心建置暨營運專案，為程曦在政府客服領域的輝煌紀錄再添一樁！「台中市政府1999」話務中心預計於98年6月20日前完成建置，7月1日正式開始營運。本專案的系統軟硬體建置部分由程曦負責規劃執行，採用國內公民營客服中心使用率最高的整合性IP CTI設備：美國知名公司AltiGen CTI交換機平台，並結合程曦的 e-Center 客服產品，提供台中市政府1999話務中心最佳的 CTI 整合品質與管理功能。此套系統設備目前在高雄市政府話務中心、行政院勞委會、警政署、臺灣中油、兩廳院等公部門 Call Center 中均有使用，而民營企業則有中華電信、台積電、高雄捷運、兆豐銀行、明台產險、華南產險、寶來證券…等十餘家採用，其優異的效能深獲各界好評。
        經過美國納斯達克上市的高科技公司－AltiGen 的多年研發，推出建置靈活、讓規模隨需求而變的IP分散式客服中心產品－ACM 6.0 / MAX Communication Server 6.0！台灣將於近期推出中文化的正體版本，敬請期待。這項產品是基於AltiGen獨有的 CTX（Computer Telephony eXchange）技術而研發的 CTOP（Computer Telephony Operating Platform）系統，在CTOP系統設計中引入了核心交換、媒體處理與智慧接入三層應用架構，統稱 SMG、而同時又相容多層合一的 All-In-One 架構，CTOP即可多層合一、又可分層協作的架構，適用於從小到大各種規模的客服中心！此外，新新產品更加強第四代IP融合型及分散式客服中心技術的元素，搭配全新的功能介面以及靈活的系統佈署方案，無論從技術上還是應用上，都擁有革新性的突破！
        在台灣微軟公司的新聞報導中提到，程曦提供 AltiGen 通訊系統，完全針對企業顧客關係管理需求設計，在電話進線後，結合了 Microsoft CRM 系統，電腦螢幕馬上顯示來電者的身分，使用者可親切問候客戶，同時對於客戶的需求可立即進行工作分派或追蹤管理。貼心之外服務更具效率，客戶關係更加緊密。如果一線接線人員無法立即滿足客戶需求，可以將電話及客戶資料同步轉接二線接線人員，甚至開啟多方會議、隨身碼的功能找到負責人員，同時直接在線上解決客戶問題。效率之外更具信任，爭取客戶也將無往不利。此外系統也整合了電話通聯記錄、電話錄音、知識庫等多項 Call Center 完整的機制，並提供中小企業的版本與租賃方案，給更多想要改善服務品質，創造客戶關係管理環境的企業，一個更好的選擇。
 
相關新聞的聯結
www.chainsea.com.tw/news17.html
www.chainsea.com.tw/news19.html
www.chainsea.com.tw/news21.html
www.chainsea.com.tw/news24.html
www.chainsea.com.tw/news25.html
www.microsoft.com/taiwan/dynamics/crm/partners/Chainsea.aspx
www.altigen.com，www.altigen.com.cn

開發 C2000 數位控制晶片多年，寫下使用心得。
   在設計一個硬體平台的時候，晶片的選用很重要，通常選用同系列的晶片來開發最好。例如：當選用德州儀器F2812晶片作為開發平台時，與這顆同系列的晶片就是F28xx。F代表晶片內建flash，C則代表無內建flash。通常，選用同系列的好處很多，
第一：開發套件可以重複使用，通常開發套件也要幾萬元左右。採用不同系列或者不同公司的晶片，開發套件就不一樣。
第二：編譯軟體可以共用，每家的編譯軟體都不一樣，不像PC端通常都是用微軟的編譯軟體Visual Studio。
第三：程式碼比較容易互相移植，因為同系列晶片的核心都相同，所以程式碼容易porting。
第四：省時又省錢，如果使用不同公司的晶片，要花很多時間研究datasheet，以及軟硬體套件。
   目前F2812晶片只是控制晶片中的一款而已，我從TI網站上將這系列的晶片做些整理，大致可分成三類：低階 (F280x)，中階 (F281x)，高階 (F282x or F283x)。這些晶片都內建ADC，不過 analog input 的範圍只有0~3V；也都內建PWM (Pulase Width Modulation)，可以控制LED亮度或者馬達的轉速...等用途。

低階的 F280x，價位低於美金5元，介於2~4元左右。運算速度：最高 40~60 Mhz。
提供的介面有GPIO, UART, SPI, I2C, PWM。晶片大小：9mm x 9mm，12mm x 12mm。
中階的 F281x (F2810, F2811, FF2812)，價位介於12~15元左右。運算速度：最高 150 Mhz。
比起低階晶片，GPIO的數量更多了，還有CAN介面(Enhanced Controller Area Network)，一種控制用的通訊協定。
F2812 是裡面最高檔的，因為多了一種介面 EMIF，支援16-bit匯流排，可以用來擴充外部記憶體與 flash...等。
高階的 F282x, F283x，價位介於12~15元左右。運算速度：最高 150 Mhz。
比起中階晶片，GPIO的數量更多了，還多了DMA搬運，EMIF介面可支援32-bit匯流排。當然此類晶片的面積較大。
應用面：停車場管理系統 (管控進出口的車輛)

 

內建DSP F2812 (150 MHz), SRAM, Flash, Network, RTC, UART (共4組 RS-232), 外接GPIO, 預留擴充槽。

外接 ADC/DAC 擴充板，如下所示。ADC 14-bit x 16 ch 以及 DAC 12-bit x 4 ch，由DSP F2812 控制。

 

最近開始開發TMS320DM6437 EVM平台, 寫下心得。
德州儀器提供的多款達文西平台，主要分成單核心CPU（如︰DM64x與DM643x）與雙核心CPU（如︰DM644x與DM646x）兩大類。單核心晶片提供高效能的影像處理，而且能同時處理多個影像通道，所以運算時脈比較高，內部記憶體容量也比較多。雙核心晶片偏重於多媒體應用為主，例如網路影像監控、影像電話…等應用。因此運算時脈較低以便節省耗電量，內部記憶體容量也比較少。
TMS320DM64x系列–從DM641、DM642、DM647到DM648，核心CPU是一顆單核心由C64或C64+所組成，時脈大約500MHz~900MHz之間，L2 SRAM大小至少為128Kb，最大為512Kb。
TMS320DM643x系列–從DM6433、DM6435、到DM6437，核心CPU也是一顆單核心由C64+所組成，時脈大約400MHz~700MHz之間，L2 SRAM大小為128Kb。
TMS320DM644x系列–從DM6441、DM6443到DM6446，核心CPU是一顆雙核心，由C64+與ARM9所組成。DSP C64+時脈大約400MHz~600MHz之間，ARM9運算時脈大約200MHz~300MHz之間。L2 SRAM大小只有64Kb。
TMS320DM646x系列–目前只有DM6467一款，核心CPU也是一顆雙核心，由C64+與ARM9所組成。DSP C64+時脈大約594MHz與729MHz兩種，ARM9運算時脈大約297MHz與364.5MHz。L2 SRAM大小為128Kb。
在開發系統方面，達文西平台相對於過去的DSP晶片來的複雜，特別是雙核心的平台開發。對於DM641與DM642晶片而言，德州儀器提供晶片使用的CSL（Chip Support Library）函式庫；對於較為複雜的晶片來說，德州儀器提供 PSP（Platform Support Package）函式庫給DM648或DM6437等晶片使用者，其中包含了CSL與DSP/BIOS驅動程式。對於雙核心的開發過程則比起只載入CSL或PSP函式庫還要複雜，因為除了要開發DSP的程式之外，還要開發ARM9的應用程式。
編譯DM6437平台的範例程式所需的軟體，包括開發環境CCS 3.3.38以上的版本、編譯工具Code Generation Tools 6.0.8以上的版本、作業系統DSP/BIOS 5.31.06以上的版本。此外，我們安裝DM6437提供的光碟片之後，還有需要安裝DSP/BIOS，安裝後的目錄如下圖所示。最重要的是PSP（Platform Support Package）套件，因為提供很多DM6437的驅動程式。
德州儀器提供數個DM6437平台的範例程式，範例放在\dvsdk_1_01_00_15\ psp_1_00_02_00\pspdrivers\system\dm6437\bios\dm6437_evm\src\video\sample目錄下。每個範例中有兩個檔案與編譯project有關，一個是*.pjt檔，另一個是*.tcf檔。首先要編譯tcf檔案，然後產生DSP/BIOS相關的程式碼，最後才利用CCS開啟pjt檔案進行範例程式的編譯。
 
DM6437範例的編譯流程
前置作業
   1. 安裝開發軟體與DM6437平台的驅動程式
   2. 安裝範例程式碼與PSP（Platform Support Package）函式庫
   3. 重新編譯函式庫
   4. 編譯TI提供的範例程式
   5. 將範例程式載入DM6437平台中
   TI在DM6437平台提供三套光碟，分別是Code Composer Studio 3.3 IDE、DVSDK（Digital Video Software Development Kit）、SoC Analyzer。前兩套是開發所必須安裝的軟體，SoC分析軟體則不一定需要安裝。
   學會編譯範例程式之後，我們可以試著將執行檔（out檔）載入開發平台上，看看有何結果。首先DM6437 EVM板子接上電源，使用USB線連結到EVM板子，編譯後的執行檔可以透過USB載入到板子上面。CCD camera的輸出要連接到EVM板子的video input埠，然後EVM板子的DAC-3埠連接到LCD螢幕。建議從下列兩個範例開始學習。
範例一. $DVSDK_DIR\pspdrivers\system\dm6437\bios\dm6437_evm\src\video\sample\vpbe的目錄下，是一個學習影像輸出的範例。在vpbe範例中，載入執行檔之後，一張史瑞克的彩色圖片將出現在LCD螢幕上，同時有一條掃描線從上到下掃瞄。
範例二. $DVSDK_DIR\pspdrivers\system\dm6437\bios\dm6437_evm\src\video\sample\loopback的目錄下，是結合影像輸入出的範例。在loopback範例中，載入執行檔之後，CCD camera擷取的影像將出現在LCD螢幕上。
有關EDMA, McBSP, SPI, HPI, 中斷…等介面的使用，請參考拙著的”數位信號處理平台””單晶片於數位信號處理”等書。(書籍提供教學投影片，歡迎到出版社網站上下載使用)

硬體與驅動程式的安裝過程
1. 假設新加入一塊PCI網路卡之後，重新開機。
2. Bus Driver（PCI.sys）最先偵測到硬體存在，由PCI.sys通知PnP Manager準備啟動這個裝置。
3. 如果kernel mode PnP Manager找不到適當的驅動程式載入，則進一步要求user mode PnP Manager準備安裝驅動程式。
4. 如果user mode PnP Manager無法在系統中找到適當的驅動程式，則啟動client installation，由使用者自行安裝。如果user mode PnP Manager能從系統中找到驅動程式，則啟動server installation安裝驅動程式。
5. 以上兩者安裝模式都需要Setup API和CfgMgr API的協助，透過INF檔案的安裝指示，以及Cat檔案的數位簽名，將合法的驅動程式安裝到OS中。
6. 在安裝過程，透過Co-Installer、Class Installer與Device Installation API將執行的設定與資訊寫入登錄資料庫（Registry）。
7. 最後，PnP Manager會載入驅動程式（Function Driver），對它送出IRP_MN_START_DEVICE。
驅動程式用到的登錄資料庫
1. HKEY_LOCAL_MACHINE\System\CurrentControlSet\路徑下有Control、Enum、Services目錄
2. HKEY_LOCAL_MACHINE\Hardware
在Control目錄下有Class子目錄，針對不同類型的硬體裝置分類，給予不同的CLSID值。硬體裝置的規格資料都被存放在每個CLSID目錄底下。
在Enum目錄下是根據硬體裝置的已知名稱來分類，如︰PCI、IDE、USB等，屬於USB型別的裝置就被歸類在USB目錄底下。另外，當OS開機後，底層的bus driver會進行硬體裝置掃描，硬體裝置也會回應特定裝置識別碼，然後bus driver再比對Enum目錄下的註冊碼，以判斷系統是否支援該裝置。
Services目錄下的資料有某些目的，例如希望在OS開機之後某些應用程式能在背景執行，類似常駐程式。目錄下也會提供驅動程式的路經，通常系統根目錄底下有個子目錄System\Drivers，存放驅動程式（*.sys），可以根據Start機碼值決定是否要Auto、Manual、Disable…執行驅動程式。
驅動程式的類型
1. Bus Driver︰最底層的驅動程式，包含各種匯流排（IDE、PCI、USB、IEEE1394…），是必備的驅動程式。Windows隨機就附贈相關的bus driver。
2. Function Driver︰通常由硬體廠商所開發，定義硬體能提供哪些功能。它能支援多個同類型的硬體裝置運作，假設有三張同樣功能的PCI卡，所有的功能運作都由這個function driver負責提供驅動。
3. Filter Driver︰屬於可有可無的驅動程式。分為兩種filter driver，一種介於bus driver與function driver之間，稱為下層過濾式驅動程式。另一種在function driver之上，稱為上層過濾式驅動程式。這類驅動程式也像其他驅動程式一樣，具備DeviceEntry、AddDevice、Dispatch…等函式。
上層過濾式驅動程式通常用於篩選IRP封包流向。假設原本的function driver僅提供基本功能，針對一些附加功能需要處理的話，在不修改原本驅動程式情況下，只要寫個上層過濾式驅動程式處理IRP封包。另外，還有個用途就是修正硬體或者function driver的臭蟲。
下層過濾式驅動程式用於協助我們寫個無關匯流排的function driver。假設有個設備可支援三種不同匯流排，但因為功能都相同，function driver應該一致才對。因此利用下層過濾式驅動程式將bus driver與function driver切開，我們僅需要寫三個filter driver對應到不同的bus，而function driver發送IRP封包給對應的filter driver即可。
Q︰應用程式如何呼叫硬體裝置呢？
一旦作業系統開機成功之後，硬體裝置建立好Device Object，我們可以用工具看到所有裝置的資訊。這類工具像Object Viewer（WinObj.exe）或DevView公用程式，可以從網路下載得到。用WinObj工具打開後，所看到的裝置如下
當應用程式呼叫CreateFile函式以便開啟某一裝置時，這個函式需要輸入裝置名稱，例如\\.\TritonGenericDevice。I/O Manager看到“\\.\”這個符號會改成“\??\”，對應到上圖所示，就是\GLOBAL??\目錄下找一個名稱為TritonGenericDevice的裝置，然後開啟它，以便user mode的應用程式可以操控。
Driver的中斷處理
中斷的等級分為軟體中斷與硬體中斷，而軟體中斷的優先權低於硬體中斷。軟體中斷又分三種︰依優先權高低為Dispatch level、APC（Async Procedure Call）level、Passive level。硬體中斷有很多種類，不過優先權都高於軟體。
當偵測到硬體發出中斷之後，I/O Manager將中斷封裝成特定的資料結構，傳給該硬體裝置的驅動程式，由這個驅動程式的ISR服務常式決定是否要處理這個中斷。如果需要處理，I/O Manager會再呼叫驅動程式的DPC（Deferred Procedure Call）函式，這個函式才真正處理中斷。
Passive level︰thread執行的等級，執行於這個等級的函式有DriverEntry、AddDevice、ReInitialize、Unload、Dispatch、user mode的程式也在這個等級執行。
APC level︰是作業系統核心所使用的，用於喚醒thread或者執行某些特定函式。
Dispatch level︰在作業系統核心有一個主要thread負責分配其他threads執行的順序。取得這個等級的thread將有優先權執行本身的工作，其他的thread則處於passive等級等待執行。常見的函式有StartIo、Cancel、IoTimer、DPC…，因為這些函式必須存取DeviceObject或其他欄位，在這個等級執行確保不會被其他驅動程式所干擾。
Q︰如何建立ISR服務常式與DPC函式呢？
驅動程式的DriverEntry之後，必須先註冊一個ISR，以便支援硬體發出的中斷處理。所以要呼叫IoConnectInterrupt函式註冊驅動程式的ISR，這是I/O Manager內建用來支援中斷處理的函式之一。因為硬體中斷的等級高於軟體執行的等級，所以ISR服務常式執行的工作要越少越好，以免佔用CPU太久的資源。ISR的工作有幾個要點，如下︰
1. 檢查收到的中斷是不是我們的硬體所發出的，如果不是則返回FALSE，如果是則繼續下列步驟。
2. 設定硬體停止發出中斷。
3. 如果需要與驅動程式的其他成員存取shared data，則需要執行Critical Section。
4. 呼叫IoRequestDpc，等到ISR完成工作後，I/O Manager將會呼叫DPC函式。
前面提到DriverEntry要註冊ISR，還要在AddDevice建立一個DPC函式以便ISR之後呼叫。在AddDevice函式中，呼叫IoInitializeDpcRequest函式來建立DPC函式。底下的範例是以DriverWorks開發的驅動程式，