ChamberPlus System Level Studio

  首頁 | Contact to us

 

News
Products
FAQ
Technicality
Links
OldNews

互動區:

留下您的足跡

想討論嗎?

 

USB 轉 I2C DIY (一)

        已經很久沒有在此網站發表文章了,不知道大家有沒有忘了這個網站了?!其實,關於要做一個USB 轉I2C 的應用介面,是版主完成USB DIY初級入門之後,一直很想整理的一系列的應用文章。 一方面,在許多電子討論區或一些論壇上,很多人都在討論或詢問這種USB 轉I2C東西。這種東西,說簡單也是簡單。但嚴格說起來:這整個系統要做到很好,很漂亮,版主一開始心中就覺得:這得用一系列的實驗或許多值得探討的技術議題。


    所以,這個想法就一直沒有機會好好的整理與作實驗。但實在是許多人或太多人在問這個東西,當然,這個問題所牽涉的也絕對不是單純的一個USB 轉 I2C 的問題而已...因為也有可能是USB 轉多組的UART 或是USB轉SPI 等等...許多我們在微控器上常見的一些業界標準介面,所以,我才說這將是一系列的系統應用問題。
   
        如果是單純的USB 轉UART 那種標準的 USB 轉RS232線,市面上是一大堆,而且都有標準SOC 可以自己搞。但您說這種很特殊的 USB 轉I2C 或是USB 轉SPI等...您要如何說呢?!這種在微控器應用上,舉目皆然的業界標準界面,您要人家USB Controller 做到全包的話?那也未免太強人所難了。另外一點是:這些業界標準界面又是往往常常接在一些奇奇怪怪的Device 之上:譬如:他可能是一個I2C 的EEPROM ,或是一個SPI 無線傳輸模組...等等 !您又總不能要人家老是搞個USB 介面...但卻又往往想把這些奇奇怪怪的Device 接在PC 周邊上,讓我們可以在一個開放的作業系統上去存取這些Device 。

        而且,這些奇奇怪怪的DEVICE 人家也可能沒想到您要這樣玩的吧?!所以,這種很特殊的USB 轉I2C 或是USB 轉SPI 介面...就可能要依賴一些USB Controller 本身韌體支援能力了。當然,又如果很單純的單晶片微控器去寫這種介面也不難。有支援I2C 硬體介面的理所當然要值得高興...但如果沒有的話?
那得可能要單晶片微控器"撩"下去用GPIO 腳去造出這些介面程式啊...那也還好....但如果也要把USB 傳輸問題給加進來的話...哈∼哈∼...這可能已經不好玩了。更何況要把這些傳輸介面要做到一進一出的資料傳輸... 不要說要做到即時傳輸(Real-Time),如果在能在一些限制條件下,可以做到不掉資料...也算是功德圓滿了 !!所以,經由這樣簡單的前面引言,想必各位看官就應該瞭解到版主提到這個議題好玩之處吧。

....

           首先,我們要先做一個簡單USB 轉I2C 的實驗,讓我們往後的實驗都可以順利進行的...當然我用的USB Controller 仍然是版主常用的 GT USB Controller ...您可別小看這顆USB Controller 呢...他還算是業界的長青樹...最近還有人請版主幫這顆USB Controller 找一些特殊應用市場呢!!

            當然,不要說什麼I2C 的硬體介面啊?!或是什麼奇奇怪怪的介面...不好意思。這顆GT USB Controller 都沒有...這不就是我們在前言所述的:要如何從USB Controller 本身韌體能力來完成這樣子的工作呢?!就是有挑戰才有技術層次的提升啊...版主是比較喜歡做一些新奇的東西...但也不是完全外行的東西...正確的說法應該是:作東西或開發產品應該是:利用自己本身學識涵養 約90 % 的功力(若差太遠...做起來太累了!);當然也不要完全是100 % 的?!為什麼?!那就是完全全心全力的付出了,本身就沒什麼成長性與挑戰性...作久了也會疲乏...所以啊,才說留個 10~15 % 的成長空間。讓自己也有機會隨著不同產品開發而有不同的成長空間...不是嗎?!---版主座右銘:溫故知新,精益求精

----
            作這種USB 轉 XX咚咚的東西...一定要有一個簡單的系統觀念:就是USB Controller 本身角色要同時扮演著"主"(Master)與"從"(Slave)雙重角色,比較有機會...您可別說:您要兩者都是"主" ?或是"從" ?!當然要兩者都是"主"已經是不可能了...因為您的頂頭上司就是PC 端...您已經先天上:成為人家的一個"從"了。但是若單純一棵USB Controller 要同時當作兩個"從"而要完成資料傳輸工作...我是覺得蠻難的...但是:若再外加一些零組件,有沒有機會做到呢?!...我是覺得在某些條件下是有機會的...這在未來這一系列文章與DIY實驗中...希望有機會挑戰一下這樣子的應用...所以,如果,各位看官如果您看完這篇文章後,要找人家要這種東西之前,您可能要先搞清楚一下:您的系統應用中:您希望人家的USB Controller 是扮演什麼角色?!自己要先推演一下吧!!

---------------
            好吧...我們先做一個簡單的USB 轉I2C 的小實驗,來驗證這些標準界面的基本架構。要找到支援I2C 介面,又要是"從"(Slave)的...當然就是I2C 的EEPROM (24CXX系列)

        版主所用的還是標準的 GT USB  Controller 的實驗平台,我們利用兩根很普通的GPIO 來當一般I2C 的兩根訊號線(為什麼不用一般 8051 的P1 ?!不是更方便嗎?...待會看完實驗您就會知道了!),當然我們直接用USB Power 就可以了。而我們所使用的 EEPROM 為24C64 ...有8K Bytes...對USB Bus來說:是很小...但如果您要做到一進一出資料傳輸來說:若是您的觀念不清楚,程式沒寫好...不要多,連1~2K Bytes 的資料量就會讓您的USB BUS 給Choke了...(噎住了...會不會噎死?!您說呢?!)..

        我們先把這顆24C64 拿到一般的燒錄器,把一些資料給寫進入,來確保資料正確性...也可以拿來檢查驗證結果:

    上圖所示的是8 KBytes 前段一部份的資料....

 

        我們也可看到整個資料內容 的Checksum為 0x0011AD28h....

------------------------------------------------------------

        接下來我們就要做一支美美的PC 應用程式,來檢視我們傳輸的結果 :

    ...其實,您只要常寫這種程式...您的程式就越寫越快,而且也會越寫越精簡有力...至於,圖中那些什麼M1 Buffer 或是M2 Buffer ...您就參考我之前USB DIY 中介紹的GT USB Controller 內容。當然我們也可以預留一些像是I2C Read 或是 I2C Write ...功能,來命令USB Controller 幫我們執行 一些相關的 I2C 動作。

    好吧,我們就把整個24C64 的資料內容給讀到PC 端看結果吧:

    我們就很快的看到:一樣前段部分,紅色框框所示的資料內容是一樣的...而整個資料內容的Checksum 也是 0x11AD28h 這部分也是跟市售燒錄器的內容相同的。(好像我要做一台USB Bus 的I2C EEPROM 燒錄器,好像也不難喔....)

-----------------------

            所以,從以上的實驗,我們可以很快的完成了一個USB 轉I2C 的基本介面轉換功能了。但如果光講這個東西,多沒意思?!還不如去買一本USB 參考書還比較快...再附個簡單程式範例之後,就您家的事了。而您也以為您會了....下回您遇到同樣應用時,咦?!怎麼又不一樣了?!就會開始"幹譙"那本書...寫的這麼爛...還賣這麼貴 ....反正都是別人的錯...最好書商也一起"幹譙"進去好了...

---------------------

        這種USB 轉I2C 的傳輸介面會有什麼隱藏的問題呢?!...第一個當然就是您 I2C 介面符不符合 I2C 的標準?!啊?! I2C Bus 有標準?!...您又不夠用功了...我們在這裡用韌體自行建立的 I2C 介面,當然要參考標準規格啊....只是您常用別人用硬體做好的...您當然就不知道了...I2C Bus 其實,他的Clock rate 是有規定的...最常見的規格是 400Kbps 的....就是他的Clock rate 為 400 KHz 的...當然這幾年已經向上推升到MHz 等級了...不過,都是一些特殊應用的....您看24Cxx 的Datasheet 大部分還都是 400KHz 的。

        好吧,我們就來看我們的I2C 的訊號:

        我們可以看到示波器所示的是 I2C Read 訊號...有興趣的要一手拿24Cxx DataSheet對照一下...,我們可也可以看到我們在Read data 時,我們用8051 韌體造出來的 I2C 的Clock rate 是 357 KHz...再看整個資料讀取中的Clock Rate:

也是在 333 KHz 左右....剛好都小於I2C 規格的 400Khz 以下....說到這裡:大家有沒有發現一個很重要的技術問題了?!啊?!什麼事?!發生什麼事....您先不要往下讀...閉起眼睛回想一下...您要不要讓您的腦筋跟著版主思考?!.....

----------------------

            剛剛版主不是提到說:為何不要用 8051 的P1?!而要用GPIO 呢?!因為...一般特殊MCU的GPIO 是透過 Registers 定義來控制IO的...而8051 對 Registers 都是透過 Movx 指令出去的...而這個Movx 指令都是比較長指令週期的指令集...所以啊...如果您是用 8051 的P1 的話...包您所產生的Clock rate 超過 400KHz....好了...看到這裡您只是看到一個答案而已...??!!....您不要真的把這個範例拿去到 Cypress 的USB Controller 去應用喔...為什麼?!因為人家我的USB controller 內的8051 是跑 48Mhz 2T 的喔...所以,我們當然可以造出這麼好與速度佳的 I2C 控制訊號。

            但您也不認為人家 Cypress USB Controller 有支援硬體的 I2C 介面啊...那個介面是讓控制一些簡單的 I/O device 的...我要提的是:如果我們要作USB 轉 I2C 等類似介面時,我們要挑戰的是那些龐大資料一進一出的USB 轉I2C bus 的資料傳輸...我們要精準每一筆從 I2C device 讀到 USB Controller 的 USB Buffer 之後,又要讓USB Bus 可以很快速的將資料讀到 PC 端...所以,您要嘛..讓每一個 I2C 的傳輸都有DMA 中斷產生,(但好像有些USB Controller 都沒有支援這種功能的...);但這種 I2C 中斷產生,無形中會是造成USB Controller 成為另一個"從"的架構...這是很辛苦的...因為您另一端也是USB 傳輸的 "從"...您都不知道這兩個不同方向來中斷要求會不會撞在一起?!...

        所以,如果我們能夠先讓一邊傳輸先停下來:讓另一邊Ready 好之後,再傳輸的話,我們就可確保資料無誤...所以我之前才提到說:USB  Controller 最好是一主一從的架構...

        所以,對於I 2C 這邊的資料傳輸來說:最好就是由USB  Controller 韌體主控...所以,這種讓USB Controller 中的MCU來造I2C 傳輸介面訊號,沒有說比較不好...反而還可以讓USB Controller 6取得主控權....只不過:您用的USB Controller 中的 8051  效能又這麼好嗎?!他會不會造成您另一邊USB 介面的瓶頸?!....

        這個就是我要說的:作這種 USB 轉 I2C或是 USB 轉SPI 等等介面時,有些您必須小心謹慎的地方...所以,原本您看來簡單容易的傳輸介面轉換的問題,經版主這樣子的實驗與解說,您是不是有另類的思考方式?!您去市面上去買一本USB 的書,看一看,您覺得您就可作這種傳輸介面的轉換了嗎?!或是,反過來:您是為了要做一條 USB 轉 XX 的DIY傳輸線...您就跑遍各大書局翻USB 的書?!或是在茫茫網路世界裡搜尋?!...甚至去人家電子網站論壇,跟人家一樣的到處跟人家要程式或要範例?!...那您真正懂了箇中的道理了嗎?!或是您真正找到您要的東西了嗎?!....

        如果,您是因為在網路搜尋相關訊息而來到這個網站...那就是您我有緣了...那應該要常常來這個網站看一下...因為接下來就要看續集篇了...

        謝謝您耐心的瀏覽...敬請期待下回分曉!

(可不可以稍微留言一下,...作個調查說:您們是如何找到這個網站的?!要在留言版留言也可以...也可以去部落格留言版...留言也是歡迎的...)


 

首頁 | News | Products | FAQ | Technicality | Links | OldNews

Telephone : 886-3-5439918    FAX : 886-3-5437632

Copyright(C) 2005 . ChamberPlus System Level Studio All rights reserved.  Last Update: 2008年01月18日。