發表文章
還會碰到還需要再加掛系統的USB 驅動程式，後來再來就是 Win2000 /NT 版本。當我自己
在搞USB DIY 時，就是WIN XP 了。那一陣子作業系統的確是比較複雜，但到了後來，
MiscroSoft 也就慢慢地穩定的開發出比較一致性的作業系統，當然整個作業系統也慢慢的
不再是市場主力了，否則以前在搞這些軟體工作的人員都很吃香，當時我們的軟體工程師還是
數學系畢業的，只要你肯幹，大致上都有一些機會的。不過，現在這種工作可能已經不太需要
了，一來USB 的東西已經很穩定了，就連我現在用的作業系統裡USB的東西，只要是 2007 年
以後，都還可以在 Win 10 底下運行的很穩定。況且現在USB Class Driver 也很完善了。
大概也不太需要客戶自己還要搞一些很奇怪的驅動程式來玩死自己了。
剩下的大概就是如何在不同的應用系統哩，定義自己的通訊協定或命令組，這一點就有點又
回到那個 UART的時代了，只是差別的是 USB 已經把過去跟硬體有關的東西幫你處理完了，
雖然你還是要找一顆支援 USB 介面的MCU ，但這個也不是難事了。
所以這些文章，也只能當作一種歷史軌跡來供人"瞻仰"而已。也讓以前沒有參與過那一段資訊
產業革命的新一代工程師們，從文章中去找尋一些歷史的蛛絲馬跡吧。)
>>>++++++++++++++++++++++++++++++++++++++++
看了標題，以為我又要講一些基礎的東西了，不，接下來都是我們要用USB 作一些實際
又好用的東西，不過，我過去一直沒提軟體的觀念，害得大家都懶得理軟體的問題，
自然而然，就隨便用別人的東西。但說真的，這可不是電子零件，找一棵功能相仿的，
放上去就可以了。對不起，如果是這樣的話，今天比爾蓋茲就不會連續十三年蟬聯世界
首富的的榜首了。
首先，我先用我USB Controller 的軟體架構來說明，我是認為大致上，USB 在PC端軟體的
架構都是大同小異的。因為，USB 出現的時候，微軟已經在推視窗環境的作業系統，
他就不會像以前IBM AT/XT 那個時代，留下這麼多硬體上的罩門可以讓一般使用者隨便
使用的東西了。人家（我指的是台灣的廠商啊！）都是買硬體免費送您軟體。
但是人家微軟可厲害了囉～是用軟體來綁您的硬體呢！
或許，微軟品牌的硬體賣得不怎麼樣，但是，台灣作硬體的，誰敢不賣他的帳。
好，首先先看一般PC上利用 USB控制周邊的基本概念：
這張只是基本觀念，我想所有會寫點軟體，甚至寫韌體的，也會有這樣的觀念。
其中中間那些都是可以以副程式或程式庫的方式來呼叫的。但是，學問就在底下那的
Transmission Interface ，那才是難的地方。如果您對上面那張圖，不是很清楚的話，
那就看他另一種面貌：
所以，當我們在最上層應用程式要下的簡單的 Command 給我們USB Controller 中的8051
(firmware)時，要經過哪些東西？看到沒？在韌體的上一層，不好意思，不是您寫的驅動
程式，而都是歸作業系統管。尤其是在視窗系統中，全部都歸作業系統管～
那怕是最左邊，那個很傳統的EPP介面，也是的啦。這下您就相信我這個 USB Controller
不只有USB而已吧！
所以，當您自己寫驅動程式時，您就得跟下層的作業系統作相容性測試，而且很不幸的，
若有相容性的問題發生時，如同USBLAB 網站中有人所發表的：千錯萬錯都是您的錯～
不是微軟的錯。至於，我們常聽到的所謂MSDC 或HID 等視窗環境所內附的驅動程式，
指的也是上圖中 GT68XX.SYS 那一層的東西。我在想：大家都有那麼懶嗎？或是開公司
作東西，需要省到連個軟體工程師都請不起嗎？為什麼？動不動想偷雞的偷微軟的東西？
（藉微軟的上層的驅動程式來騙微軟下層的驅動程式呢？）抓一個看不到問題的，
已經夠辛苦了，您還要矇著眼睛（微軟是不會跟您說他的驅動程式的東西的！！）
來抓兩層的東西，更何況是對PC軟體一竅不通的韌體工程師去抓問題呢？！
說到這，我相信很多軟體或韌體工程師都會有所體認吧！
如果，您對我所說的東西，還是搞不懂，那您就在看一下下面的圖吧～其中，
所謂GT68xx USB kernal Library 可能是您買了別人的 USB Controller 來寫程式時，
常看到的東西吧。但我們在USB DIY 過程中，常常是需要再增加一些屬於我們自己的命令，
就是左邊的那一條路徑，我是覺得，您如果還在學USB的東西的話，最好還是掌握一下
左邊的那一條路徑，因為上述的兩層都夠辛苦了，不用再加一層吧～否則，您真的只是
拿一棵USB Controller 在寫一般 8051 的程式了。從這張圖您也很清楚看到，
所有發USB Control pipe 或 Bulk pipe 的都是微軟的那支底層的驅動程式。所以，
當您下完命令或要存取USB資料時，連您的驅動程式也只能在那等作業系統的差遣了。
不過，在這也有一個好處就是：當您的USB驅動程式歷經千錘百鍊後，您就可以不用擔心
我上述的問題了吧！這就是我用我的USB驅動程式這麼有把握的原因。因為，當初我們的
軟體工程師是花了很多精神去抓跟下層驅動程式的相容性問題～當然，當初USB剛出來，
微軟的作業系統也是初期嘗試跟一般硬體Provider 合作，所以他們的態度是比較謙虛一點！
哈～哈～ 所以，作東西還是我說的：還是得趁早啊！
從上圖，我就很容易看到我們 USB Controller 就可以很獨立的依據所附與的 Firmware 來寫
應用程式了，那真的就是一般寫 8051的程式了。至於，當您要更新韌體時，作業系統也
不知道，他只是忠實把上層應用程式所交附的資料（韌體程式也是資料的一種）傳給您的
USB Controller 了！
好了。我講完基本PC端的控制流程後，我就以一個實際的應用案例來說明整個USB DIY
系統的軟體～韌體與硬體之間的操作：譬如，我要作一個USB 介面的 Atmel ISP 燒錄器，
在架構上我就定義誠如下圖：（還是看圖比較清楚）
會不會很複雜？！不會啊～還好，您只要把上圖從中心線一分為二，看左右兩邊就可以
知道了，右邊的就是一般 Control pipe 要做的事；而左邊就是一般 Bulk pipe 作的事。
在這個應用中有一個很簡單的作法就是，因為目前 Atmel ISP 所支援的 Code Size 都小於
16KBytes ，所以，我都可以一次完全的透過 Bulk 傳進傳出我 USB Controller 之中，再讓我
右邊綠色虛線中的韌體（8051 程式）慢慢的處理這些資料。比較難的會是，未來您若要
作一些BULK Transfer 資料是超過我內部 Data Buffer 容量的時，那時，下面那左右兩邊是
混在一起的。既然要循序漸進的講USB DIY當然就是從簡單說起。
那要不要繼續講？不好意思，就先保留一下，讓我的網站的人氣指數可以一路往上飆高。
奇怪，我講了這麼多東西，為什麼大家似乎都無動於衷呢？還是我講得太簡單了？
沒深度？沒水準？ ！
所以，在這也奉勸一些想寫書的朋友，您若是專職寫技術書的作者，您可能真的會餓死喔～
也難怪寫這種書的都是學校老師。咦？對喔～也沒有人請我去開課？！真的要檢討自己了～
也真的要潛水一陣子來檢討自己了。
謝謝各位囉！還是自言自語一般....＠＃＆...
---------------------------------------------------------------------------------------------------------------------
後記：關於這個議題，在完稿的隔天剛好有位交大電控所博士班的吳小姐
（人家吳小姐做USB的東西，一付巾幗不讓鬚眉的氣勢，令人感動），最近有寫個用視窗
內定 HID驅動程式來做簡單的USB I/O 的東西，碰到了一些問題，請我幫他看看問題點～
剛好因為也就在新竹市區，我就就近幫他看了一下，當然啊～剛好我也沒碰過USB HID的
東西，也可以藉由此次教學相長一下。其實，吳小姐做的USB 控制的東西已經做得不錯了，
結果卻在最後關頭碰到相容性問題！剛好藉此提出討論：
果然是，大家都是為了省掉寫PC端驅動程式的撰寫與維護，就跑出一些連自己都意想不到
的問題。吳小姐的應用也是簡單的USB I/O : 藉由 USB 下一些 Vendor Command 及傳輸一些
簡單的數據（雙向數據）。認為只要寫一個簡單的應用程式： Visual C++ 及在USB Controller
這邊回個簡單HID Class 的裝置，自然PC 端視窗作業系統的HID驅動程式自然就會接手一切
驅動程式的工作，相信這樣的東西，大家都不陌生。但是這樣會延伸出什麼問題呢？
（說真的，我自己以前也沒碰過～）
因為HID CLASS的東西會有一個 Interrupt pipe 。所以Host 的 HID Class驅動程式會在一固定
的時間來跟您要資料，不管這個時間的長短（多長多短都不是問題，因為他跟您內部的韌體
就不會是同步信號的～這個問題待會解釋！），要嘛您的韌體不要理他，用硬體回一些奇奇
怪怪的資料給他～但是，您會知道HID Class 這支驅動程式要了這些資料要做什麼？！
資料內容要如何定義？！您還是得去K規格但是 HID Class 會有多少規格？未來會再加多少
您可能想都很難想得到東西？！然後，您知道HID CLASS的上一層的應用程式，除了您寫的
應用程式外，還有多少支微軟應用程式也是透過這支HID Class 驅動程式抓周邊硬體嗎？！
今天只有您的應用程式跑或許沒問題，但是明天您加個KeyBoard、Mouse 外加遊戲的回饋
動力方向盤再加個搖桿....您有把握客戶使用時，會不會再跑出另外的問題呢？！
那又有問題時，您覺得是您的錯呢？還是微軟的錯呢？！
工程的不確定性，對老闆來說都是最大的風險：不是要付出慘痛的代價外，
還會賠上商業信譽的。
資料傳輸跟韌體不同步會有什麼問題？！
第一、您就非得靠韌體的中斷處理能力不可。否則，他有可能會打亂您程式內部控制流程
的旗標或記憶體內的資料內容，甚至造成程式不穩定！
第二、那一旦啟動這一項中斷機制的話，那您的程式會常常被此中斷叫去服務這段
中斷服務程式，這會造成您韌體程式的執行效能，甚至，您一般資料處理控管複雜度！
（每次都還得 Push & Pop ，還得留意Stack 空間問題，我想他的風險也不會比不同步的
問題來的單純！）
當然，吳小姐的問題可不可以解？我不知道，因為就算今天可以解掉這個問題，
很難擔保明天會不會跑出另一個更奇怪的問題？！她當初很快的省掉驅動程式的撰寫與
維護，以一個簡單的應用程式就完成老闆交付的任務，卻只在不同硬體的主機板跑同樣的
作業系統就出現資料傳輸錯誤的相容性問題？！反而，被這個問題卡了後面一大段時間，
卻也束手無策。（可想老闆的心情一定從雲端跌到谷底吧～）而且，越到計畫後期，
要更改系統規格那怕解決方案是越難下決定的啊，您會牽扯更多工程人員(硬體設計、
PCB等）及採購！那這時要不要壯士斷腕更改解決方案？！
您敢不敢跟老闆拍胸脯打包票？！您覺得痛苦？老闆也很痛苦！！
就考驗著每一位主其事者的英名睿智了~我想最後這個問題會延伸出非工程的政治問題了
～哈～哈～
簡單的結論說明：從這個案例，我想大家就可以體會到我這篇文章的用心良苦了。
說真的，因為現在的視窗環境已經做得很不錯了～一般使用者都可以簡單的操作
應用軟體，所以，您與其只有寫一支簡單的應用程式，人家一般客戶還是希望有所謂
自動安裝軟體(Autorun 的Installer)～幫人家安裝卸載應用軟體，既然要自動安裝了～
您就順便把您的驅動程式也一併安裝了～客戶根本不知道。您覺得您跟您老闆說：
我有一套『穩定』的驅動程式也可以自動完整的安裝軟體提供給客戶！還是我可以讓
客戶不用安裝任何驅動程式，卻不敢保證會不會出問題的應用程式時，您老闆會接受
哪一個方案？！
至於，您的驅動程式只是服務您的應用程式及您USB 裝置的韌體而已，根本不用擔心
會有其他奇奇怪怪的應用程式或別人的硬體裝置的東西會干擾您們
（當然，我們擅長是做硬體的話，我們更應該透過軟體來幫我們硬體創造更多價值啊！
）～那您就可以從此體會到為什麼：所有的作業系統（包括微軟或iMac ）會把一些
就算常用的周邊硬體的東西，還是拆成兩部分驅動程式（參考上面的圖示），
您就懂了我的意思吧！
微軟的作業系統雖然把一些工作都包起來做掉了～但不代表所有使用客戶就不必
再養寫驅動程式的軟體工程師了。如果這樣的話～那微軟也不必提供WHQL
測試平台了～那也不會有更多硬體搭配他的軟體出現了，他未來也不必想用他的
軟體綁人家的硬體了，人家做硬體也不必理會他的作業系統的更新問題～
不用幾年比爾蓋茲就不會是世界首富了！！這樣的比喻您懂了嗎？！
哈～哈～祝福各位，有朝一日也可以成為獨霸一方的首富吧！（世界首富比較難吧！）
沒有留言:
張貼留言