發表文章
前兩篇關於USB DIY--自學計畫_USB新平台(二)，我講的是走一遍原廠所提供的範例程式
說起弄這些原廠程式難不難？說起來不難，在原廠搞這些範例程式我以前也搞過，
講難聽一點：簡單到有點不是很負責啦。為什麼？反正一般 MCU 驗證之後，對許多
原廠工程師來說如釋重負，其他的就是寫寫一些技術文章之類的。交代一下這MCU 的
一些功能。頂多呢，就是寫寫我們所看到的這些範例程式了囉。告訴你：這些MCU 的
基本功能。那你覺得這些東西對你拿來開發系統產品就可以了嗎？
簡單來說：一般MCU 都帶有一些周邊應用硬體電路，譬如 ADC、I2C或 SPI 等等。
要驗證這些功能，再寫一些範例程式，真的不難，但重點是：當這些周邊要搞在一起應用
時，大家就頭大了。這也是大家所常說的系統應用整合。對於這些基本周邊功能如何協調
地完成產品系統功能，還要包括一些系統設計本身所需要的檢測功能，就考驗著系統
工程師的功力了。尤其是像 USB 這一種架構在基本規格上，如何變化使用，就顯得格外
考驗著系統工程師的功力了。就以前兩個範例文章來說：USB 基本功能那就不用說了，
但對於系統產品在量產銷售與服務方面，你就得考慮著系統更新與維護問題。
所以在系統應用端就肯定要把這兩篇文章做一個結合了。那原廠會不會幫你做？
那肯定不會的。
那你會覺得說：既然現在網路這麼發達了，我上網 Google 一下不就好了嗎？
網路的資源是有，但茫茫網海，你要去哪裡找？我想你一定會馬上想到對岸了。
沒關係，我就幫你整理了。
這就是在大陸百度雲端裡幫你打包好的一些關於USB 的技術相關文章或原始碼了。
你也就不用再花心思去翻找了，我直接幫你轉成繁體字，也以我稍微"專業一點"的觀點
幫你加了註記。那到底還具有多少參考價值，就不用我多說了。(如果覺得字體太小可以
另外下載另存圖片之後，放大查看，我原始圖檔都可以清晰地看到註解說明文字的啦)
其實大部分的還都是遵循著原廠相關文章或範例程式碼跟你解說一下而已。對你來說：
你也是要自己進入這樣的環境條件哩，你也才有能力維護，你也總不能跟著原廠工程師
一樣的打混吧。那話又說回來：如果甚麼都依據原廠所給的東西，那我們幹系統工程師的
哪有甚麼價值，那就像大陸百度裡東西一樣，隨時可以下載套用。
我們搞系統應用的不只只是要做到而已，還要做得更好。這過程才是真正考驗著你的創造
能力，尤其是USB 這樣子的系統設計，也都必須透過這樣子的過程，你也才能真正的
了解掌握USB 關鍵技術，進而拓展USB 系統應用的領域。
我在上一篇文章中也有提到 USB 介面往往會被拿來作為系統輔助工具，所以在某些應用
場合就會很斤斤計較效能問題。這一點原廠也就不會管你了。而且USB 的系統應用也是
千變萬化，也不太可能就如同原廠範例程式那麼呆版死死的使用。以下我就用一些比較
範例來說明：(這就代表著我已經完全修改原廠的範例程式，並同時也完成系統驗證了。)
---
首先，像藉由 Bootloader 來更新系統程式，他講求的就是效能，一來為了表面不讓客人
覺得好像東西很爛，(更新太久，客人會怕怕的!)，二來程式更新本來就有一定的風險，
萬一更新過程中斷電或是不小心斷線，都有可能造成更新失敗，甚至造成死機。
這是原廠程式中用 SetReport 來完成一般客製化命令的下達，然後用 Endpoint 1 的
Interrupt IN Token 來回應命令執行結果。看起來沒有不對的地方。
以下是我略做修改之後的結果：
其實，基本上命令所帶的指令長度都不用太長，但原廠為了簡化範例程式的複雜度，
他就乾脆一路全部用 Setup 帶 64 Bytes 一路搞定，這樣子就無形中會占用USB 傳輸的
頻寬了。但也同時凸顯著原廠 Bootloader 這個範例程式缺乏一定系統發展彈性，
這也是USB HID 系統規範中，為什麼還要定義一個所謂的 Report ID 的原因，因為
如果你的USB HID 系統中沒有額外宣告 Report ID 的話，你的USB 傳輸就只有唯一一種
傳輸長度。然後你的系統發展就顯得到處受限，有些資料又嫌太多，但有些就又嫌太少。
最後把自己給玩死了，更不用說還要配合PC 端的系統軟體工程師。所以玩系統的人一定
就得懂得調整規劃與定義系統規格。
以下這一台就是原廠的MCU 開發工具，他也是用 USB Vendor HID 定義出來的介面：
很誇張吧，他的 Vendor HID Report Descriptor 長度有 855 Bytes 。 所以你就不要太相信
原廠所提供的範例程式，真的只是簡單的交差了事，沒有任何修改是絕對無法拿到系統
上來用的啦。
以上是原廠提供的在命令端的資料長度，看起來真的顯得太長，有點浪費了，那接來我們
在來看程式更新過程中的傳輸情形：
以上這兩張圖是要連著看的。
我們可以看到如我之前所說的：因為他的 SetReport 只有一種長度，所以他也只能每
64 Bytes 就得再下一次 SetReport 。然後每傳完 128 Bytes 之後，再以一個 Endpoint 1 來
回應傳輸結果：
這樣子一來，就顯得很沒有效率，而且你也看到最後一筆也只傳了 5 Bytes ，卻還要用一個
完整的 Setup Out 64 Bytes 來完成。是不是有點荒謬？我跟你說：這樣子 PC 端的軟體真的
比較複雜討厭。你韌體覺得簡單，但搞軟體的一定在背後公幹你的。
但如果我們把它改寫後就成了如此：
看到沒有？反正就是 128 bytes 嘛 ! 你乾脆就一次 Setup Out 128 Bytes 就好了。
一次搞定，PC 端程式又簡單，傳輸效率又好。如果你還嫌速度不夠快的話，
只要你韌體端的記憶體空間夠的話，你也可以繼續增加，我記得沒錯的話，USB
的 Setup Out 一次好像可以 4096 (4K) Bytes (USB 1.1 規格)。這樣子夠快了吧。
所以我才說：有些人在搞燒錄器或搞系統工具傳輸，都沒有真正的掌握規格的小細節。
然後兩手一攤的跟老闆說：就覺得反正速度就是這樣子。結果產品一出去，不比沒關係，
一比就見真章了。你還敢說人家USB 規格問題？所以我才一直強調：搞USB 規格不能
囫圇吞棗。規格是死的，但系統應用是活的。就看你如何變化使用。
所以經由這一次簡單的實驗，其實背後也不簡單啦。因為這樣子的改寫不只只是改寫
韌體端的傳輸介面，而且還要同時修改 PC端的應用程式才能有辦法檢視程式修改的想法
對不對？最重要的還是程式除錯過程中，對於問題發生的研判與找出方法，才是最難的
部分。因為畢竟這些介面還是有一部分是我們所看不到的在PC 端底層的作業系統內。
更令人討厭的地方是：USB 規範真的很嚴謹，不管是 USB Descriptor 或程式命令的
內容有稍微不對的話，不管是作業系統的底層或是韌體搭配的USB 硬體控制器就發生
讓你意想不到的結果。幸好的是：我自己本身對於問題的發生點與USB 控制韌體的掌握
還算蠻有 Sense 的。往往碰到問題，只要站起來，出去外面走走繞個兩圈回來，問題就
迎刃而解了。或許這也是經年累月所累積下來的系統開發經驗吧。
所以有時候，看著科技產品日新月異，天天總有人炒作新技術新產品，與其去追求那些
華麗的外表，倒也真得不如好好的掌握一兩項關鍵系統開發技術，尤其時所培養出來
那一份系統開發與整合測試的經驗法則。還真的比較好用。一個小小的經驗分享也供各位
參考。
(待續)
沒有留言:
張貼留言