2013年6月5日 星期三

USB HID 與UART (RS232)系列之一

最近搞了一個案子是幫朋友解決USB Dongle ,應該算是USB Tools 的東西...
雖然這樣子的東西我也算作了不少東西了...對我來說:也只不過就是Copy & Paste ...
然後再改改一些UI 人機介面而已,您說有沒有比較特別的地方?!不知道!
對我來說一點也沒感覺。...

但後來想一想,這樣子的東西應該也是許多人常會碰到的問題吧:
譬如在USB 應用上常見到的 USB 轉RS232 或是USB 轉I2C 或SPI 等等吧!
所以我就以USB 轉RS232C (UART )大家常會碰到或想問的技術問題,我就稍微交代
一下吧!如果寫得不是很清楚的話...大家就用力的留言吐嘈吧!
---------------------
基本上,以前我都很懶得教大家搞那個USB 轉RS232C 的東西,因為呢?市面上已經有
一大堆這一種專用IC 了,我也不想斷人家的財路,所以,我也就順水推舟的請大家
自個兒想辦法了!
但我發現:有很多人用了這一種IC 之後,他們還是用那個VB 來寫PC AP 端的應用程式...
當然您不能要求每一個又搞USB (或MCU 韌體)的工程師們又要搞好PC AP 程式,
所以大家就利用簡單的VB 程式裡的COMM.H 加減寫寫程式了囉!
但是卻又常碰到資料三不五時會掉...老是搞不清楚問題出在哪?!功力好一點的或許還
可以從DEVICE端的韌體或AP 端作業系統底層追追看...但實在很辛苦,又求救無門!
其實,以前我在USB 文章內就有提過:您不要看USB 轉RS232 ,就哪兩支 RX/TX PIN嘛!
很簡單...這一種USB 轉RS232C 的IC 要搞好也不容易...
您光看以下這一家專用IC 所出的IC 編號...您就知道:人家搞了好幾個版本,還不一定搞定:
    說真的啦...出這麼多版本,又是一大堆技術文件資料...我自己也實在很懶得想看...
那您說:我自己本身在系統應用上會不會常遇到這一種東西?!Of course...
沒有的話,那就根本不是在搞研究,在系統開發上有多少實驗數據要量,有這麼多需要
調整的參數...您沒有PC 端的AP 協助?!搞屁啊?!瞎子摸象...在做什麼研究啊?
那您一定會問我說:那我怎麼處理這個問題?!那就是我這一系列文章要講的事!
------------------
首先我們先來講為什麼大家喜歡用UART ?!因為很簡單,現在MCU 幾乎都有支持,
甚至現在新一代的32 bits ARM 都還不只只有一組UART...
而且UART 在使用上很簡單:就只有TX/RX 兩條線就可以提供雙向通訊,
而且在PC AP 還有一大堆標準應用程式可以直接套用:像是超級終端機等。
大家只要笨笨的寫MCU 韌體程式就可以了。就可以透過PC 端Debug了!
但實際上,有時問題就沒那麼簡單...
-------
那我們就應該不要忘記這個RS232 為什麼會成為電腦應用上的一個重要規範?!
他原本的用意是啥?!....其實,最早的UART(RS 232) 是拿來外接數據機(Modem)
的介面...所以在RS232規範尚有很多還留著這一種產品的"餘毒"...您無法擺脫,但微軟的
作業系統就非常討厭他...那您還幹嘛跟微軟對幹呢?!更何況現在微軟也不行了。
----
當然現在已經沒有人用RS232 來連接Modem 了,但我們還是喜歡用他原本的那一套
通訊介面來玩周邊,尤其是作資料傳輸的這一件事。
那如果要提到拿Modem 精神來作電腦周邊傳輸的話,那您就不得不提到Null Modem
這個東西了!因為我們現在用UART 來作為系統傳輸介面的,都是利用Null Modem 的方法:
他最基本的就是 TX/RX (pin 2 & 3 ) 對調,就可以達到雙向通訊的功能了!
但很不幸的是:現在大家就只看到 RD/TD 這兩支pin 而已,都忘記了其實還有其他
I/O 的定義的重要性,這個就是造成您通訊系統掉資料的問題了
-------------------
以下是兩家算是這個領域都很有名的 專用IC 廠所提供標準EV Borad :
一家就是Silabs 的CP210x : 
---
另一家就是FTDI 的專用IC...
----------------
大家都應該發現:其實人家的USB 轉UART 的IC 是提供標準的Null Modem 的標準接口。
除了常用的TD/RD 兩支I/O 之外,人家還是把所有的Null Modem 會用的I/O 腳都提供了!
只是大家不喜歡這麼用...因為我們就是要省 I/O 啊...除了TD/RD 之外,我們幾乎不管
其他I/O 的定義了。但如果大家若有心的話,那您就應該去看一下其他I/O 腳在
RS232 的通訊協定上扮演什麼硬體功能定義...如果您搞不懂這些的話,
那您也不能怪人家IC 有問題或為什麼會掉資料?!
-----
那我自己呢?!我當然也不喜歡這麼用啊!搞死自己喔!因為您還要兼顧到您PC AP 端的
程式問題...因為如果您要真正的完全掌握與控制這些除了RD/TD 以外的PIN 的話...
您就得要瞭解作業系統底層的東西。
最早您要透過作業系統來控制PC 硬體周邊時,您必須利用 電腦硬體上的BIOS 來玩!
那作業系統就得要提供這一條路徑:以前控制RS232 是透過BIOS 的中斷向量:0x14H...
我想現在人家微軟的作業系統不讓您這麼搞了吧!...您就別再想那個
COM1 : 0x03F8, COM2 :0x02F8.....。不要說您看了就討厭,連微軟自己也很討厭!
那您說:您的USB 轉RS232 的IC 又要有這一種I/O 腳的控制....那怎麼辦?!
微軟才懶得理您。那就只好要賣IC 的人。自己想辦法在底層的驅動程式裡作掉了啊!
搞得讓您的AP 能看得懂這些東西,然後又要避開微軟的底層...那您就知道怎麼會有那麼
多一大堆的VCP 或其他奇奇怪怪的驅動程式,然後每一家的還不一定相容呢! 
---
您就想一想:您偏偏要用微軟的的軟體開發平台,但人家就不喜歡您還在用這些東西...
您還在Open COMM ...又要comm_puts/comm_gets...微軟為什麼還要理您?!
這樣子的搞法,不就是拿石頭一直在砸自己的腳嗎?人家微軟也不一定會可憐您...
搞不好還在背後詛咒您說:死好!(台語!)....微軟的作業系統現在已經慢慢
失勢了...他們一定更不爽:就是您們這些人搞得讓他們一直擺脫不了包袱!
所以啦...看過我這一系列文章之後,您們真的要好好想想:我還要這麼搞法嗎?!
----
我們先在這一篇前言文章先下一個簡單結論註腳:
第一:我們利用RS232 的通訊協定,硬體上用的就是早期Null Modem 的基本作法。
            而Null Modem 在硬體定義上,除了TD/RD pin以外,其實還有其他I/O的
            定義。但我們往往常忽略這些I/O 在通訊協定上的意義!
第二:除了硬體的考量之外,我們還是得必須瞭解新一代的作業系統,尤其是微軟的
           作業系統對於基本Null Modem 的控制方式的支持。如果我們沒有對些基本的
           RS232 通訊協定的充分掌握的話,那就很難擔保過渡簡化的Null Modem 的
           資料傳輸方式(就只用TD/RD) ,會不會產生資料傳輸Loss 的現象?!
-----
先暫時歇筆一下...等到下一篇文章時,我再來解說:該如何解決這樣子類似的問題,
可以讓您跟著PC AP 端的軟體開發一路順遂!
(待續)....

10 則留言:

  1. MCU遇到像PC這種比較快裝置,兩都之間的Handshake就很重要。

    如果加上軟體或是硬體Busy Flag判斷的機制,那會不會就不容易掉資料?

    當Busy Flag 被MCU設定,表示MCU還在存取資料,

    Host端就必需等待Busy Flag被清除,才能向MCU拿資料(也確保拿到的資料無誤)。

    個人一點淺見,提供參考。

    回覆刪除
    回覆
    1. 嗯...基本上,說得沒錯!
      當您互傳資料的速度越來越快時,Handshake 就變得很重要。
      因為RS232 這一種非同步的傳輸方式(就是沒有帶Clock同步訊號!)
      純粹只靠Baudrate...本來就有風險。更何況若也沒有硬體檢查機制。
      人家I2C 至少還有Start/Stop Bit,SPI 也有一根Enable Pin...
      RS232 是完全看不到有另外的同步或檢查機制I/O ...其實,
      原來的Null Modem 是有的啦!---- 所以這樣脆弱的資料傳輸機制
      就有很大的風險。
      另外在軟體溝通上,又缺乏一定的檢查機制...(其實原來要搭配
      CTS/RTS 等I/O 腳的控制信號的啦!)....只是更增加風險,
      這一部份往後文章會繼續探討!
      也非常謝謝您的回應。也非常謝謝您的補充! =D>

      刪除
  2. 板主您太客氣了,如果沒遇過也不知道有這回事啊。

    當時在做案子的時候,初期也沒有加上Handshake的機制,

    遇到掉資料的問題也不好抓,是底層F/W的問題呢?還是上層AP/Driver的問題呢?

    搞到後來雙方人馬在那邊吵來吵去。

    回覆刪除
    回覆
    1. 這是我以前文章常提到的辦公室的"鳥事"!
      每一個搞工程的都難免會自以為是...
      所以我的至理名言:
      討論問題,只能點出問題現象,而不能輕易下結論指責對方!
      尤其,您根本沒有在做對方在做的事!
      (當然啊~如果您是老闆的話,那就另當別論! :)) ... :)) ... :)) ...)

      刪除
  3. 看了內文 我的觀點是這些都不是RS-232 or null modem 的問題, 是用的人沒有通訊系統的概念,
    通訊必然是不可靠的, 不管那種系統 USB 本身packet也有CRC/ACK/NACK

    RS-232 就是一個很legacy/free 的設計 要避免的不是掉資料, 掉資料是正常的 連Ethernet 因為線材干擾都會掉資料了 只不過大家用TCP 中間會有driver/MAC/datalink 去確保資料的傳送可靠性

    而是怎樣知道掉資料怎樣重傳 這不是 Physical layer 的事情 RS-232 只定義了 Physical layer
    CTS/RTS 那些功能 基本上可以透過 Data-link layer去做,
    傳輸資料本身要有適當packet 看USB 本身的 packet 設計

    當然 USB to RS232 的相容性主要問題我知道的事那些CTS/RTS/RI接腳的timiing 跟本來的ISA/PCI 介面不太一樣 因為是經過USB 傳送在轉換 有些軟體寫的不好會受這些timing 影響吧!

    回覆刪除
    回覆
    1. 通訊介面一般來說都是要搭配軟硬體,才可以達到迅速,確實的要求。
      我說了:非同步的UART 本來就比較缺乏同步機制,軟體上面又很難做
      到確實檢查機制,(一般人寫RS232 的軟體應該也沒有想過這麼多吧!)
      大家又喜歡用最簡單的方式來處理,本來風險就會增加。能怪誰?
      --- 個人造業,個人擔!
      -----------------------
      不管是RS232 或Null Modem 等等...這些本來就是某一世代需求下的產物,
      他有他時代定位,當然也有其時代共業,而這些都使得他難以再往下發展。
      所以當初這些PC 大廠們(M$, Intel ...)才會想出新一代的USB 來取代他。
      大家之所以會用USB 轉RS232 那是時空轉換的灰色時代的歲月...
      應該不可能一直持續下去吧,就以大廠來說:都已經給您們這麼多年了,
      怎麼還搞不定?!...人家也不一定會有耐心陪您們一直耗著吧!
      ----
      最後,不錯的是,您點出了一個重點:RS232 只有定義到Physical Layer,
      而USB 是定義到更高層次...這在兩者之間要做轉換,如果站在RS232
      使用者端,沒有利用更高層次的通訊協定方式的話...
      出了問題真的就不要怪人家了!  [-( ....
       

      刪除
  4. 另外傳統上 RS-232 應該會定義一個固定的傳送距離 15m 然後對傳 可能用上百MB bytes 然後去統計 然後每個可傳字元 (RS-232 有 5,6,7,8 data bits) 都會測過 也有start/stop 所以 還有parity bits 所以PC上會有 9600:N,8,1 (Baudrate, parity, 8 bits data, 1 bit stop), 另外也有簡單的 frame error detect 設計

    回覆刪除
    回覆
    1. 以下已經有所說明了, RS232 這一種東西有其歷史共業...
      這些9600 N 8 1 的東西...對於日益複雜的網路通訊來說:
      真的過簡化到難以因應日益複雜電腦通訊與資料傳輸的需求了。
      講難聽一點:就算用硬體來作一些補救(Error Correction)都還嫌
      在使用上諸多不方便之處...所以啦...人還是往前看吧!  

      刪除
  5. 我同意人要向前看, 但是如果使用者自己基礎打不好, 遇到問題就怪東怪西! 那說實在的 在好的東西 能發揮出怎樣的效能 還是看使用者本身的能力
    RS-232/RS-485/RS-422 應該還會再某些利基市場有一席之地

    回覆刪除
    回覆
    1. 如果撇開  UART 與RS232/RS485/RS422 來看的話:
      我也會認為RS232/RS485/RS422 還會維持一段利基市場。
      但若以我來做的話:
      我就不會用PC 直接用 USB 直接轉RS232/RS485/RS422。
      我還是寧願用USB HID to MCU 然後MCU UART to RS232/RS485/RS422。
      反正現在隨便一棵帶USB 的MCU 用他的UART來寫 真正的
      RS232/RS485/RS422 的Protocol 應該都綽綽有餘了吧!
      ---
      所以這是兩件事...我在許多應用還是會用RS232/RS485/RS422 ...
      我自己也不會淘汰這些東西。 :))  ...

      刪除