想瞭解之前的...可以點選以下連結:
---
之前寫了有關USB 自學計畫...完成USB Bulk 傳輸之後,原本要進入HID 應用,
後來就停了一陣子,最主要的原因,還是我一直強調的:學USB 不難,
最主要的還是要有明確的應用市場或是產品,否則,真的很難督促自己一棵向學的心。
也不能講說:向學的心啦...因為對於USB DIY來說,我應該是不用向學了,
應該還是拿來作系統應用開發才對。所以啦,不管您要學什麼USB 、MCU 或是Andriod,
主要還是要有一個明確的目標,總不能說:我只是為了比較好找工作,
如果是如此的話,那找到工作之後,那您是不是又陷入另一個迷失?那豈不永遠學不完?
我來講一個同樣的道理:有許多老闆是搞技術出身,公司一開始也是滿腔熱血,常常是自己
突發奇想,總覺得哪些東西、產品好像很前景似的,就一頭栽進去搞,這樣子搞也沒錯,
人總是因為夢想而偉大的嘛!...好了,在搞的過程中,就開始找一些業務進來幫忙看市場,
結果,業務跑了兩圈,才發現這個東西好像沒老闆想像的那般市場榮景?
好一點的業務,很誠摯的跟老闆反映說:可不可以依據客人或市場需求調整?
一般這種所謂的『調整』,往往又有點偏離老闆原始的初衷,老闆不一定聽得進去,
久了,這業務也懶得再跟老闆反映了...結果,整個公司開始打混戰了。老闆自我安慰的
"很東西的研發是需要時間的啦!"也勸勸業務不要急啦。一股研發本質精神的自我感覺很好。
結果...一年,兩年...時間慢慢的流失,後來才發現:整個市場趨勢翻盤了,原來,
現在世界已經在流行 iPad、雲端等等....老闆才發現帶一群迷途的羔羊(青澀工程師們),
誤入歧途的不知所云的埋頭苦幹,然後才發現業務早就安排退路腳底抹油了。
所以您跟我說:您在這一種環境中,您學到什麼?!您學會了又代表什麼?!
那您的自我感覺是不也很好啊?!那您是不是該又要準備再學點別的?
這幾年,我看過太多公司、太多工程師都面臨這一種問題,老闆還是浸淫在那個自我感覺
很好的幻想裡...所以,有很多朋友都跟我說:在高科技界裡,他的結論:很有把握的說,
有超百分之九十的公司,只要老闆是搞技術出身的,然後又很容易陷入一種工程開發或
研究工作之後自我感覺很好的...大概公司下場都很慘的。
是不是這樣子的?或許您也可以參考看看吧。
----
好吧,我們就來講一點USB HID 的東西吧。大家就不用這麼辛苦的搞得要死的~
有些東西或技術,大家都可以拿出來討論的,可以早一點讓大家有點覺悟吧。
不要上班搞這些之後,還是那一副自我感覺很好,甚至還是公司花錢請您出去外面上課,
更是師出有名,振振有詞的...您也只不過慢慢的要步入另一個宅男工程師的樣子而已。
首先,我們採用的是Silabs 的C8051F320 的開發平台,什麼平台不重要,
我看過那麼多家,USB 控制器裡的Register 的定義與用法幾乎差不多,我都有點懷疑,
這些USB 中的SIE 應該都是師出同門的吧?改天我會針對這些 Registers 說明的。
SiLabs 在USB HID 中有提供相關的PC 端HOST 軟體供您參考,但是我敢跟您拍胸脯
保證,如果您是公司要搞USB 控制器韌體的工程師的話,您一定看不懂這一隻軟體。
那更不說:Silabs 這一隻範例程式的說明根本語焉不詳,一開始您根本看不懂這個範例
想表達什麼?! 他的韌體與上層PC HOST 軟體在幹什麼?!尤其您還是USB 新手。
很簡單:您不要以為用Microsoft 的 HID 驅動程式很爽,不用寫驅動程式,不好意思,
您要用人家的驅動程式您就得乖乖的用別人的方法或是思維模式...這一點才辛苦呢。
其實坦白講:這一隻範例程式真的寫得很好...他已經把USB HID 的精髓都全包進去了,
只是我是覺得:真的一下子太快了,對於USB 新手來說,有點給他複雜一點。
以USB 傳輸來說:HID 中的interrupt pipe 傳輸是跟Bulk pipe 是一樣的啦,至少您從
USB 的分析儀看起來也是如此,甚至在USB 控制器裡的Registers 定義也是一樣的。
但很不幸的是:作業系統端與應用軟體端是不同,您要用人家的驅動程式就要用人家的
作法...簡單來說好了,USB HID 中有一個基本規格:就是Interrupt In Pipe。(人家USB
有跟您說:您的Interrupt Out pipe 是可以用Control pipe 來做的...如果是我,我當然要選
Control pipe 來作啊,PC HOST 端的軟體多簡單啊 ...)他是USB Device 端,主動的在
每一個時間內都會送出資料給PC 端的,您不要以為您的應用程式只要開在視窗上,
他就是一直在執行...對於作業系統來說:您要搶周邊資源,您也得要聽作業系統的啦。
像一般我們USB Control Pipe 來說:他是每按一下,系統就幫您執行一次,簡單又明確。
以現在這麼強的作業系統幫您執行這樣的工作,不難。但是您要他隨時幫您留意周邊資源?!
不好意思,這下子是換您要聽他的...可不能隨時讓您隨心所欲的。所以,他的這一隻範例
程式在處理這一部份是用所謂的 Multi-thread(多緒)的作法...我是不知道VB的程式語法啦。
在VC 要處理這一種東西就讓人很討厭...他是不同與一般簡單的程式方式,
更不用說:您只是寫寫USB 控制器的韌體工程師了...所以,我才說:對於USB 新手來說,
有點給他難一點。
----
好吧,先不管他,我們還是照往例先利用他所附的先跑一遍,以確定功能。
還是按照往例,我們還是先動手稍微改一下PC HOST 端的應用軟體,看到右下角那個
LOGO沒 ?代表我們真的有給他改他原來的MFC 程式的啦。
我們也照往例從USB 分析儀看一下資料傳輸的內容....很快的,我就發現一個怪怪數據?
只要您是寫MFC 的,您就知道這個 0xCC的意思了...(未定義的陣列啦!)
查一下PC HOST 的程式碼...果然是錯的啦...
他沒有定義到 Pattern[0][1] 啦。...難怪會出錯。人家USB 傳輸是不可能出錯的啦。
幸好,這一個參數影響USB 韌體不多(當然不多,他們原廠才沒有發現的啦。)
我們在看這些程式與資料流時,一定要盯緊每一筆資料的流向的。
這一個數據指示拿來設定USB 控制器裡Timer 中斷中的LED時序的。
--------------------------
這一隻範例程式是從Interrupt In pipe 端(就是那一隻Thread 程式一直在抓USB 資料),
抓從USB 控制器上那一個ADC 值(可變電阻的輸入電壓)...
他在HID 的Report Descriptor 中Report ID 是0x04 ...長度只有1 個Byte(8 bits)。
所以,在分析儀上看到的就是那一個 0x04 0x32...那個0x32(0x2F, 0x34...) 就是ADC 值。
很簡單吧...
其實還不簡單啦,要能真正拿來作應用,還是需要一番修改與努力的。
您不以為您的USB 韌體只要固定時間一直往PC HOST 丟資料就可以了...
我們講過:USB 是主從架構,沒有這一隻Thread 程式一直從您的Interrupt In pipe
中要資料的話,您的USB 韌體中...Interrupt In Pipe (ADC 資料)一筆也傳不出去。
(然後您會發現:很難掌握Microsoft 底層的這一隻thread 程式何時出手抓資料?!
一般Thread 程式是比一般程式難Debug的啦...)
只是我說了:您光會寫USB 韌體還不夠,還是要能自己修改PC Host 端程式,
這樣子Debug 或是開發定義彼此之間的通訊協定是比較快的啦。
就像我們一開始就可以發現原廠的錯誤範例,是對我們熟悉開發平台是比較好的啦。
(待續)
---------------------
PS : 您不以為用了 USB HID Class 這一種介面,您就可以完全解脫了,簡單來說:
若是現成的 USB Class 介面,您還是得遵循USB Class 規範來走,甚至每一條命令
或是每一個指令都要遵循Class Command ,這不止HID 而已,連一般隨身碟的MSDC也是。
所以,若您是用HID Class 已經有的 Usage Page,不好意思,您自己也要用功一點,
把規格每一條都要K 清楚,就是您K 清楚了,您也得要慢慢的跟Microsoft 的作業系統
慢慢磨合一點(誰叫我們要用人家現成的驅動程式)。
但是若是一般HID 的Usage Page 有定義的,對我們搞USB DIY 或是真的要拿USB 作一些
特殊應用的...好像也啥好鑽研的,我們USB DIY 最主要的就是要拿來像一般傳統RS232 的用法,
讓我們可以隨心所欲。所以呢?這樣子的系統應用問題還是得回到我們自己本身對系統應用的
通訊協定的架構的定義了,這還是得考我們自己本身能否在我們自己的系統應用條件中,
再配合USB HID 的基本精神,創造屬於自己的應用介面。這代表的意思是說:
我們自己在系統應用中,到底有沒有能力去創造屬於我們自己的Application Command 了。
舉個例子來說:您要做一台簡單的MCU 燒錄器,您要怎麼定義屬於您MCU 燒錄器命令介面?
您要準備哪些命令介面?要如何定義一台USB 燒錄器介面?這才是重點。瞭解嗎?!
1. 難怪我一直覺的這程式怪怪的~但是因為HID的應用 ~我都直接給客戶64 byte IN/OUT的 FW +APP了(這算是將客戶養壞嗎?直接給程式~然後跟客戶說直接填入buffer就好了~其餘都不用管XD ~歧視是客戶也懶的看~懶的學啦),所以我也根本沒再去看這個HID的FW +APP 不順的地方在哪. 倒是其他的範例程式(例如bulk, 我就會仔細去看整個FW + APP了)
回覆刪除2.我還有疑問的就是範例程式中有一個interrupt device的範例程式(需要裝驅動程式的那個), 請問這樣客製化的interrupt device, 與HID 的比較? 個人覺得因為都是使用中斷傳輸, 應該使用的傳輸頻寬都是一樣的, 所以二者之間的傳輸效能應該是差不多的??
3.HID的IN~如果沒有開啟APP,只要MCU傳送IN給PC, Windows也一樣會收走,那是否也代表著HID的APP不能連續IN (可能會有當機的風險?)? 一定要PC先OUT~之後PC再IN(FW也需要相對的配合),才可以得到正確的資料? 有做過實驗~就是MCU一直傳送0x00~0xff~PC端的APP一直IN~結果會掉資料~是我程式沒寫好嗎?
1. 原廠這一支範例程式怪怪的地方還有很多,改天我會一一點出的。
刪除2.我是覺得用通俗型USB MCU 的效能都不會好到哪裡去,所以,我是覺得沒差啦。只不過的是:既然都要用interrupt 了...就直接用HID 就好了,反正HID 也可以利用Get Report/Set Report 自行定義應用介面與參數傳輸。
3. 我說了:您要用人家的驅動程式就有一些潛在的風險。這些問題可能要問Microsoft 才知道答案吧。...至於In/Out 之間,因為USB 是主從架構,PC Host 沒來要資料,您In 資料準備在那也傳不出去,有沒有Out 在先也沒差!...
當然同理來說:PC Host 來要資料,您一直回NAK 也沒有人說您不對,.,,只不過,microSoft 那一支HID驅動程式會不會設Time-out 機制?!還有他 Time-out 多久?我們還是不知道。所以,還是得看Microsoft 的臉色。...至於,會掉資料?這一點我就懷疑,應該不可能...那就要查說:資料是掉在哪一層?底層驅動程式?還是上層APP?(如果底層有Time-Out 機制,那他會不會掉資料?也不知道?也是要問Microsoft!)...不過,如果真的會掉,應該也沒關係,我個人覺得HID 中的Interrupt 有點類似ISO 作法或理念吧。...反正您的資料會再送的。...如果真的很在意資料準確性的話,那還是用Setup做吧。