發表文章
(補充說明：我在寫系列文章時，我大多著墨於 Bulk Transfer 的傳輸模式，
其實我後來也很少用 Bulk Transfer ，比較常用HID ，是屬於高速的HID，但有些觀念
還是適用的。當然啊~越要求效能，對於規格與基礎理論架構要更清楚，才能展現效能的，
這一點是無庸置疑的!!)
標題：請教移除USB裝置 ? -- 軟體與韌體的互動 !!
Q: 我想在程式上加移除USB裝置，我就不需要去右下角點選移除，
請問哪裡有資料可查?或是有哪位大哥可提供相關的function?
A:其實，我們在視窗的右下角點選移除的動作，就是下了一個 Suspend命令而已罷了
～就是希望您的Device 進入比較弱電狀態～
當然，您也可以用 Vendor Command 下一個 Suspend Command 給您的Device ~
但如何讓OS 收到這個訊息就不知道了。您還有更狠的作法：下一個Vendor Command
給您的Device 叫他拔除！ 怎麼作？！Device 端如何控制？在我的網站說明中有提過：
就是將D+ 那根 Pull-high 放開～再拉一下不就好了嗎？！簡單吧！有時軟體想破頭，
還不如系統作一下更快～哈～哈～ 我們是寫韌體不是寫軟體的！哈～哈～
Q:其實您說的就是斷電的作法，但是視窗會出現拔除的訊息，
我的目的就是不要看到這個訊息，直接跳過去?
A:簡單的回覆如下：
1. 聲明一下：我所說方法不是斷電～只是把D＋放開～就是RESET 狀態！
2. 我當然也知道您是不想看到那個訊息，但是您要如何通知OS呢？！
我也真的不知道，我想，除非您去查微軟公司的相關技術文件吧～但是我的直覺是，
像這種東西是牽涉到他OS底層的東西，微軟不一定會公布，而且我是覺得您也不要
嘗試去『騙』他，否則，後續維護工作包您作不完。
3. 這種問題就譬如好像我開發一個USB DRIVER，但又不想作WHQL ，卻不想看到
微軟那的警告視窗？！您覺得微軟會讓您有機會成功嗎？！那他WHQL 賺什麼？！
4. 您應該回頭想：您為什麼要在AP中去做USB 裝置移除的動作？！原因是什麼？！
只是不想去點選作左下角？既然點選左下角是作業系統直接下命令給底層的
USB 驅動程式（這個也是微軟的），他已經把您作得很好了～
您又何必在程式中多此一舉，卻又想跟作業系統搶這份工作呢？！
或是您只是作一個軟插拔功能來解掉您USB Device 韌體的問題呢？！
那您應該是好好去看看USB DEVICE端的真正的問題。
（我猜的啦：因為以前我們軟體工程師，都很憨直，明明USB DEVICE韌體有問題，
又不敢提～發現每次RESET 好像可以解問題，就自作主張想下RESET ～
結果問題一直沒解～是不是這樣？！
我猜的～真的不要這樣解～對USB的東西不要這樣解！！就好像您說了第一謊之後，
您就要用更多謊來圓這個謊～）
------------------------------------------------------------------------------------------------------------------------------------------------
好啦～這篇Q＆A我要道出以前我們大部分作USB產品場碰到的問題：
韌體與軟體之間的協調問題。說真的，一個真正能拿到台面上的USB產品，
幾乎都需要PC 端軟體工程師，再加USB DEVICE端的韌體工程師，
當然啊～您們若是作USB IC的公司的話，還得再加上IC設計工程師。
有時作技術不難，最難的就是溝通，然溝通最難就是語言不通，很不幸的是：
寫軟體跟寫韌體就是語言不通。尤其是寫軟體DRIVER的，更是難以理解，
連他們自己跟作業系統之間的理解也很難。
USB 傳輸的最大特色是什麼？！說真的，您若是作HID這種低速裝置，
您可能很難理解這個特色，就是主從之間傳輸的協定，因為在低速裝置中，
走的是 Interrupt Token ，他基本上是Polling 方式，而且是以Device 端自己宣告方式
來定義Polling 時間間距及資料長度通常不大的。但對於其他傳輸方式來說，
就未必了，什麼時候HOST要資料？一次又要多少？可能都不一定，
這都得在啟動傳輸協定前就得定義清楚！！
否則，一旦啟動了，在PC端的 Driver 的IRQ 就『不到黃河心不死』！
您的軟體應用程式就當場枯等在哪！！我們當然不能說是當機，
因為底層的DRIVER 真的收不到資料或資料發不出去啊？！
那怕您一次要了 100 MBytes 資料，他卻只收 99.9999% 的資料，
底層的Driver 還是不會把控制權交還給您的應用程式。
好了，這時候，就算這是那麼一個 Bytes ，您就很難捉問題了。
尤其是作BULK傳輸的，資料是完全掉不得的。
此時，看見寫韌體與寫軟體的爭執點了：
寫軟體應用的軟體工程師說：我真的收不到底層DRIVER 的回覆？！
而寫傳資料的韌體工程師卻說：我一切都照暫存器規劃啊～我哪知道？！
資料似乎人間蒸發般～
此時，有一個最大的替死鬼出現了：微軟的作業系統！！大家都開始罵！
罵得很爽，但問題還沒解啊？！（此時，作IC的可能在旁邊偷偷的在笑～～）
因為寫軟體的哪會幫您看USB裝置的暫存器啊？！更不說，寫韌體哪看得懂軟體
那些PC程式啊！
其實，這部分的解法，我本來要在下篇談到有關USB 傳輸的文章中，
以範例教大家如何釐清問題，但在此我先說明一些觀念問題，
這一切首先要講求的是：態度問題。都必須尊重對方的專業知識。
但人非聖賢，人能無過無錯呢？！我在此說我自己的經驗法則：
『雙方都只能描述現象，不可妄下結論！』，因為我們是民主社會，
誰也沒資格給對方安一個怎麼樣的罪名。
所以，以前在還沒確認資料傳輸的路徑已經正確無誤之前，不要劈里啪啦傳
一大堆資料，連要DEBUG都很難，最好是一些固定的資料格式，
譬如說：0x00, 0x01, 0x02 ...依序下去，萬一中間掉了什麼資料，很快的看出問題點。
另外，就是要知道USB Device 一般傳輸的設計機制是：靠硬體幫您擋住所有的
資料傳輸的 Handshake!等一切資料或儲存BUFFER準備就妥，才把傳輸機制啟動。
有點像水庫閘門一樣，一旦閘門一開，其實您的韌體的工作就使不上力了。
皆下來就等另一個硬體的通知（向中斷訊號），相對的，在軟體這邊，
一次要多少資料，一定要透過命令方式事先通知韌體，這一點是很重要的 ！
這是一些傳統的RS232 ，您愛收不收都隨您，USB 可不行，因為USB 是資料串接的，
整個BUS上可不只有您的資料而已（譬如您是透過USB HUB，有些傳輸封包可能
是要傳給USB HUB而不是您USB裝置）。
至於，細節的作法，我會在一篇USB 資料傳輸的文章中，用實際範例來說明。
在此先說明到此。
最後，針對這個問題，我還是強調一點，無論是作工程獲解決問題，
態度真的很重要，我說過：
硬體的問題，韌體解；韌體的問題，軟體解；軟體的問題，業務解；
業務的問題，老闆去解。
但是您若是一位有擔當的工程師，您就不應該把問題留給別人解，否則，
除了工程問題難解外，您的名聲也很難解喔！
您覺得您老闆會用什麼方法解決您的問題啊？！
我舉一個我以前同事講的一句話來送給大家：
只要我XXX出門解決不了的問題，那鐵定是IC有問題！
帥啊～有夠擔當的～也是出了名的機車。
我想這可以列為系統工程師的十大名言之一啊！您有這樣的信心與勇氣嗎？！
沒有留言:
張貼留言