USB to UART/SPI/I2C

我最近因別人提醒才發現今年有許多USB 控制器IC 廠都有推出所謂的

這一種USB 轉接IC 。

國內的：

盛群半導體 -I/O Type USB MCU with SPI (USB 2.0 Full Speed)

---

國外的：

微芯- 全新的USB与SPI协议转换器| DesignSpark

（這個就是那個 Microchip 的MCU！）

當然還有在USB 轉RS232 很有名的 FTDI :

FT2232H - Hi-Speed Dual USB UART/FIFO IC

----

當然也有一些可能是Design House 拿別人的 USB Controller 所做的產品。

只要您在 Google 輸入 " USB to SPI " 之後就會一大堆了。

---

當然這一種USB 轉接IC 也不是第一天才有，很早以前就有所謂的USB 轉UART。

也是我們俗稱USB 轉RS232 的東西。

我想這當然就是有市場需求才會有一大堆這一種東西。而最常見的應用場合，

就是一些比較沒量但又特別需求：譬如工業控制或是一些簡單的儀器設備之類的。

這些東西您說是標準化的東西，又很難說是標準化，也很難講不是標準化？

那如果要當標準化的IC 賣～那以USB MCU 原廠來說，最為樂見了。

他們只要出了一兩張標準參考電路圖，外加一兩個範例程式...再附給您一個驅動程式

或PC 端標準的 VC 範例程式就好了。人家就可以開門做生意了。

---

也難怪這些原來搞MCU 的IC 原廠也做起這樣子的生意了。

當然之前也有人問過我這一種東西...但深究這樣子的需求與真正在系統解決方案上的

應用狀況，難道真的這麼簡單嗎？！

您還記得我以前寫過一篇：高壓點火～令人困擾的干擾問題  。

我當初用的就是一般市面上常見的 USB 轉RS232 的標準轉接線！

最後結果當然就不能用啊！

那怎麼辦呢？！...最後我也只好用一般的USB MCU Controller 自己寫一個

轉接線，也順便把硬體電路上所碰到的一些電磁干擾的東西給一併解決。

當然啊...我也不用人家的驅動程式...因為萬一碰到問題您也沒得解！

----

所以：針對這一種USB 轉 UART/RS232/SPI/I2C...等等，其實他們的問題都

是一樣的。除了一般標準RS232 /SPI/I2C 的基本規範外...最麻煩的還是在於

您自己本身的 Command protocol 與Handshake 的問題。您說：

SPI/I2C 有標準的Command Sets 嗎？！當然您拿SPI 寫Serial ROM 是有的！

但許多應用是沒有的！萬一您碰到一些檢查或干擾問題時，您要透過額外的

Command Set 來偵測解決問題時，您所採用的USB 轉接控制IC 有提供嗎？

---

我最近碰到一個問題：他就是標準的USB 轉一般SPI 介面，它是使用在

工業儀器設備上...結果常常因為莫名的原因產生當機現象。

後來他們找了軟體工程師們下去看問題點，結果結論就是：USB 介面有問題。

疑似是有電磁干擾問題造成USB 與SPI 端儀器設備的問題。

當然整個USB 轉SPI 標準接法就如同這一些USB 轉SPI 原廠所附的參考電路圖與

相關驅動程式所完成的！---- 也整個打包成一個個模組...

所以碰到問題，搞軟體的大概也只能追到他的上層應用軟體程式大概就卡在

對於原廠所附的驅動程式端吧！...當然當場就沒解了！

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

因為您可以去看這些 原廠所附的驅動程式與他自己本身的所附的參考軟體介面

就簡單的給您幾個簡單Command Set 去定義一些標準的SPI 設定與讀寫動作

指令而已！

----

結果萬一真的碰到問題時，您怎麼辦？！難道真的要靠Close Device 在Open Device 來

Reset 硬體介面嗎？！...

但有時很討厭的是：往往有時當機的時候，是死在底層驅動程式與作業系統端的問題。

類似的問題，我在以前許多 USB DIY 文章中常常提及。結果對硬體與對軟體來說：

都不知如何是好？！--- 當然很多人就會自作聰明：在USB 線上加Core ..Bead ...

或包覆一些防干擾的東西...或這邊接地，那一邊再加一個大大的鐵板當Ground 。

我自己的經驗的是：無啥效果！...今天會干擾～明天還是會...今天不下雨，過兩天

萬一打雷下雨怎麼辦？！...過兩天台電又不爽給您來個"市電閃電"怎麼辦？！

( PS : 我跟高雄的林老師曾經聽過最離奇的問題是：當工廠裡的天車（吊車）

從機器設備上空滑過時，儀器設備就被干擾一次...！.........）

----

結果搞了老半天才發現這樣子的問題還真的不如賣鹽酥雞簡單容易...因為往往發生

這樣子的問題時，通常都已經是在整機組裝完畢後驗證測試或是交機安裝在客戶

廠房內時...這時您說您怎麼重新改硬體？改驅動程式？甚至還要軟體...最痛苦的是：

開始懷疑這樣的USB 轉接方案的USB Controller 真的有問題？！

您想一想：當USB MCU Controller 原廠公司的工程師們搞這些東西時，

哪有想到這麼多鳥事呢？！人家賣您USB MCU 時，也以為這種生意好作啊...

只要給參考電路圖，驅動程式...外加幾個簡單的AP 範例應用程式就想出貨收錢了。

殊不知原來外面的生意環境險惡。工程師搞了老半天還是被客人打槍的說：

您們家的東西有問題...那到底是軟體有問題？還是應用電路圖有問題？！

還是真的USB MCU IC 有問題？！...當然啊，在業務大人備受責難之下，

跑去跟工程部門主管抱怨時，大家皮就得繃緊一點，包您班加不完啦！

----

那您一定想問我結論怎麼辦？！

很簡單：天下沒有白吃的午餐...所以我當初寧願辛苦一點，從最基礎的

系統應用環境考量，重新設計電路版，改寫USB 控制韌體...採用比較穩定可靠的

驅動程式...外加上層比較聰明一點的應用軟體程式...

相信我說的：搞USB 系統應用沒有捷徑，也沒有那一種 Easy Money 的啦！

=====

PS : 文中所提發生干擾當機的USB 轉接IC 還不是國內那一種隨隨便便的USB MCU，

而是國外鼎鼎有名...還是大家公認最佳的 F 牌的 USB IC 。我當初也很納悶訝異的請

對方再一次確認一下問題真的出在USB 端嗎？！答案是肯定的！因為他們的軟體

工程師也是追到底層驅動程式時，就知道了！...而我當場也看到PC 端上的

USB IC 所呈現的USB IC 之PID/VID....您說：您們家的USB IC 就比較厲害？！

這是整個系統應用的問題啊！