USB傳輸協議。——Arvin

来源:http://www.cnblogs.com/zhsh641/archive/2016/10/14/Basic_XY.html
-Advertisement-
Play Games

問題一:USB的傳輸線結構是如何的呢? 答案一:一條USB的傳輸線分別由地線、電源線、D+、D-四條線構成,D+和D-是差分輸入線,它使用的是3.3V的電壓(註意哦,與CMOS的5V電平不同),而電源線和地線可向設備提供5V電壓,最大電流為500MA(可以在編程中設置的,至於硬體的實現機制,就不要管 ...


問題一:USB的傳輸線結構是如何的呢? 答案一:一條USB的傳輸線分別由地線、電源線、D+、D-四條線構成,D+和D-是差分輸入線,它使用的是3.3V的電壓(註意哦,與CMOS的5V電平不同),而電源線和地線可向設備提供5V電壓,最大電流為500MA(可以在編程中設置的,至於硬體的實現機制,就不要管它了)。 問題二:數據是如何在USB傳輸線裡面傳送的? 答案二:數據在USB線里傳送是由低位到高位發送的。 問題三:USB的編碼方案? 答案三:USB採用不歸零取反來傳輸數據,當傳輸線上的差分數據輸入0時就取反,輸入1時就保持原值,為了確保信號發送的準確性,當在USB匯流排上發送一個包時,傳輸設備就要進行位插入***作(即在數據流中每連續6個1後就插入一個0),從而強迫NRZI碼發生變化。這個瞭解就行了,這些是由專門硬體處理的。 問題四:USB的數據格式是怎麼樣的呢? 答案四:和其他的一樣,USB數據是由二進位數字串構成的,首先數字串構成域(有七種),域再構成包,包再構成事務(IN、OUT、SETUP),事務最後構成傳輸(中斷傳輸、並行傳輸、批量傳輸和控制傳輸)。  ---------------------- 下麵簡單介紹一下域、包、事務、傳輸,請註意他們之間的關係。 (一)域:是USB數據最小的單位,由若幹位組成(至於是多少位由具體的域決定),域可分為七個類型: 1、同步域(SYNC),八位,值固定為0000 0001,用於本地時鐘與輸入同步 2、標識域(PID),由四位標識符+四位標識符反碼構成,表明包的類型和格式,這是一個很重要的部分,這裡可以計算出,USB的標識碼有16種,具體分類請看問題五。 3、地址域(ADDR):七位地址,代表了設備在主機上的地址,地址000 0000被命名為零地址,是任何一個設備第一次連接到主機時,在被主機配置、枚舉前的預設地址,由此可以知道為什麼一個USB主機只能接127個設備的原因。 4、端點域(ENDP),四位,由此可知一個USB設備有的端點數量最大為16個。 5、幀號域(FRAM),11位,每一個幀都有一個特定的幀號,幀號域最大容量0x800,對於同步傳輸有重要意義(同步傳輸為四種傳輸類型之一,請看下麵)。 6、數據域(DATA):長度為0~1023位元組,在不同的傳輸類型中,數據域的長度各不相同,但必須為整數個位元組的長度。 7、校驗域(CRC):對令牌包和數據包(對於包的分類請看下麵)中非PID域進行校驗的一種方法,CRC校驗在通訊中應用很泛,是一種很好的校驗方法,至於具體的校驗方法這裡就不多說,請查閱相關資料,只須註意CRC碼的除法是模2運算,不同於10進位中的除法。 (二)包:由域構成的包有四種類型,分別是令牌包、數據包、握手包和特殊包,前面三種是重要的包,不同的包的域結構不同,介紹如下 1、令牌包:可分為輸入包、輸出包、設置包和幀起始包(註意這裡的輸入包是用於設置輸入命令的,輸出包是用來設置輸出命令的,而不是放據數的) 其中輸入包、輸出包和設置包的格式都是一樣的: SYNC+PID+ADDR+ENDP+CRC5(五位的校驗碼)   (上面的縮寫解釋請看上面域的介紹,PID碼的具體定義請看問題五) 幀起始包的格式: SYNC+PID+11位FRAM+CRC5(五位的校驗碼) 2、數據包:分為DATA0包和DATA1包,當USB發送數據的時候,當一次發送的數據長度大於相應端點的容量時,就需要把數據包分為好幾個包,分批發送,DATA0包和DATA1包交替發送,即如果第一個數據包是DATA0,那第二個數據包就是DATA1。但也有例外情況,在同步傳輸中(四類傳輸類型中之一),所有的數據包都是為DATA0,格式如下: SYNC+PID+0~1023位元組+CRC16 3、握手包:結構最為簡單的包,格式如下 SYNC+PID (註上面每種包都有不同類型的,USB1.1共定義了十種包,具體請見問題五) (三)事務:分別有IN事務、OUT事務和SETUP事務三大事務,每一種事務都由令牌包、數據包、握手包三個階段構成,這裡用階段的意思是因為這些包的發送是有一定的時間先後順序的,事務的三個階段如下: 1、令牌包階段:啟動一個輸入、輸出或設置的事務 2、數據包階段:按輸入、輸出發送相應的數據 3、握手包階段:返回數據接收情況,在同步傳輸的IN和OUT事務中沒有這個階段,這是比較特殊的。 事務的三種類型如下(以下按三個階段來說明一個事務): 1、 IN事務: 令牌包階段——主機發送一個PID為IN的輸入包給設備,通知設備要往主機發送數據; 數據包階段——設備根據情況會作出三種反應(要註意:數據包階段也不總是傳送數據的,根據傳輸情況還會提前進入握手包階段) 1) 設備端點正常,設備往入主機裡面發出數據包(DATA0與DATA1交替); 2)設備正在忙,無法往主機發出數據包就發送NAK無效包,IN事務提前結束,到了下一個IN事務才繼續; 3) 相應設備端點被禁止,發送錯誤包STALL包,事務也就提前結束了,匯流排進入空閑狀態。 握手包階段——主機正確接收到數據之後就會向設備發送ACK包。 2、 OUT事務: 令牌包階段——主機發送一個PID為OUT的輸出包給設備,通知設備要接收數據; 數據包階段——比較簡單,就是主機會設備送數據,DATA0與DATA1交替 握手包階段——設備根據情況會作出三種反應 1)設備端點接收正確,設備往入主機返回ACK,通知主機可以發送新的數據,如果數據包發生了CRC校驗錯誤,將不返回任何握手信息; 2) 設備正在忙,無法往主機發出數據包就發送NAK無效包,通知主機再次發送數據; 3) 相應設備端點被禁止,發送錯誤包STALL包,事務提前結束,匯流排直接進入空閑狀態。 3、SETUT事務: 令牌包階段——主機發送一個PID為SETUP的輸出包給設備,通知設備要接收數據; 數據包階段——比較簡單,就是主機會設備送數據,註意,這裡只有一個固定為8個位元組的DATA0包,這8個位元組的內容就是標準的USB設備請求命令(共有11條,具體請看問題七) 握手包階段——設備接收到主機的命令信息後,返回ACK,此後匯流排進入空閑狀態,並準備下一個傳輸(在SETUP事務後通常是一個IN或OUT事務構成的傳輸) (四)傳輸:傳輸由OUT、IN、SETUP事務其中的事務構成,傳輸有四種類型,中斷傳輸、批量傳輸、同步傳輸、控制傳輸,其中中斷傳輸和批量轉輸的結構一樣,同步傳輸有最簡單的結構,而控制傳輸是最重要的也是最複雜的傳輸。 1、中斷傳輸:由OUT事務和IN事務構成,用於鍵盤、滑鼠等HID設備的數據傳輸中 2、批量傳輸:由OUT事務和IN事務構成,用於大容量數據傳輸,沒有固定的傳輸速率,也不占用帶寬,當匯流排忙時,USB會優先進行其他類型的數據傳輸,而暫時停止批量轉輸。 3、同步傳輸:由OUT事務和IN事務構成,有兩個特殊地方,第一,在同步傳輸的IN和OUT事務中是沒有返回包階段的;第二,在數據包階段所有的數據包都為DATA0 4、控制傳輸:最重要的也是最複雜的傳輸,控制傳輸由三個階段構成(初始設置階段、可選數據階段、狀態信息步驟),每一個階段可以看成一個的傳輸,也就是說控制傳輸其實是由三個傳輸構成的,用來於USB設備初次加接到主機之後,主機通過控制傳輸來交換信息,設備地址和讀取設備的描述符,使得主機識別設備,並安裝相應的驅動程式,這是每一個USB開發者都要關心的問題。  1、初始設置步驟:就是一個由SET事務構成的傳輸 2、可選數據步驟:就是一個由IN或OUT事務構成的傳輸,這個步驟是可選的,要看初始設置步驟有沒有要求讀/寫數據(由SET事務的數據包階段發送的標準請求命令決定) 3、 狀態信息步驟:顧名思義,這個步驟就是要獲取狀態信息,由IN或OUT事務構成構成的傳輸,但是要註意這裡的IN和OUT事務和之前的INT和OUT事務有兩點不同: 1) 傳輸方向相反,通常IN表示設備往主機送數據,OUT表示主機往設備送數據;在這裡,IN表示主機往設備送數據,而OUT表示設備往主機送數據,這是為了和可選數據步驟相結合; 2) 在這個步驟里,數據包階段的數據包都是0長度的,即SYNC+PID+CRC16  除了以上兩點有區別外,其他的一樣,這裡就不多說 (思考:這些傳輸模式在實際***作中應如何通過什麼方式去設置?) 問題五:標識碼有哪些? 答案五:如同前面所說的標識碼由四位數據組成,因此可以表示十六種標識碼,在USB1.1規範裡面,只用了十種標識碼,USB2.0使用了十六種標識碼,標識碼的作用是用來說明包的屬性的,標識碼是和包聯繫在一起的,首先簡單介紹一下數據包的類型,數據包分為令牌包、數據、握手包和特殊包四種(具體分類請看問題七),標識碼分別有以下十六種: 令牌包 : 0x01  輸出(OUT)啟動一個方向為主機到設備的傳輸,並包含了設備地址和標號 0x09  輸入 (IN) 啟動一個方向為設備到主機的傳輸,並包含了設備地址和標號 0x05  幀起始(SOF)表示一個幀的開始,並且包含了相應的幀號 0x0d  設置(SETUP)啟動一個控制傳輸,用於主機對設備的初始化 數據包 : 0x03  偶數據包(DATA0), 0x0b  奇數據包(DATA1) 握手包: 0x02  確認接收到無誤的數據包(ACK) 0x0a  無效,接收(發送)端正在忙而無法接收(發送)信息 0x0e  錯誤,端點被禁止或不支持控制管道請求 特殊包 0x0C  前導,用於啟動下行埠的低速設備的數據傳輸 問題六:USB主機是如何識別USB設備的? 答案六:當USB設備插上主機時,主機就通過一系列的動作來對設備進行枚舉配置(配置是屬於枚舉的一個態,態表示暫時的狀態),這這些態如下:         1、接入態(Attached):設備接入主機後,主機通過檢測信號線上的電平變化來發現設備的接入;         2、供電態(Powered):就是給設備供電,分為設備接入時的預設供電值,配置階段後的供電值(按數據中要求的最大值,可通過編程設置)         3、預設態(Default):USB在被配置之前,通過預設地址0與主機進行通信;         4、地址態(Address):經過了配置,USB設備被覆位後,就可以按主機分配給它的唯一地址來與主機通信,這種狀態就是地址態;         5、配置態(Configured):通過各種標準的USB請求命令來獲取設備的各種信息,並對設備的某此信息進行改變或設置。         6、掛起態(Suspended):匯流排供電設備在3ms內沒有匯流排***作,即USB匯流排處於空閑狀態的話,該設備就要自動進入掛起狀態,在進入掛起狀態後,總的電流功耗不超過280UA。 問題七:剛纔在答案四提到的標準的USB設備請求命令究竟是什麼? 答案七:標準的USB設備請求命令是用在控制傳輸中的“初始設置步驟”里的數據包階段(即DATA0,由八個位元組構成),請看回問答四的內容。標準USB設備請求命令共有11個,大小都是8個位元組,具有相同的結構,由5個欄位構成(欄位是標準請求命令的數據部分),結構如下(括弧中的數字表示位元組數,首字母bm,b,w分別表示點陣圖、位元組,雙位元組): bmRequestType(1)+bRequest(1)+wvalue(2)+wIndex(2)+wLength(2) 各欄位的意義如下: 1、bmRequestType:D7D6D5D4D3D2D1D0 D7=0主機到設備 =1設備到主機; D6D5=00標準請求命令      =01 類請求命令      =10用戶定義的命令     =11保留值 D4D3D2D1D0=00000 接收者為設備             =00001 接收者為設備             =00010 接收者為端點             =00011 接收者為其他接收者             =其他  其他值保留 2、bRequest:請求命令代碼,在標準的USB命令中,每一個命令都定義了編號,編號的值就為欄位的值,編號與命令名稱如下(要註意這裡的命令代碼要與其他欄位結合使用,可以說命令代碼是標準請求命令代碼的核心,正是因為這些命令代碼而決定了11個USB標準請求命令): 0) 0  GET_STATUS:用來返回特定接收者的狀態 1) 1  CLEAR_FEATURE:用來清除或禁止接收者的某些特性 2) 3  SET_FEATURE:用來啟用或激活命令接收者的某些特性 3) 5  SET_ADDRESS:用來給設備分配地址 4) 6  GET_DEscriptOR:用於主機獲取設備的特定描述符 5) 7  SET_DEscriptOR:修改設備中有關的描述符,或者增加新的描述符 6) 8  GET_CONFIGURATION:用於主機獲取設備當前設備的配置值(註同上面的不同)  7) 9  SET_CONFIGURATION:用於主機指示設備採用的要求的配置 8) 10  GET_INTERFACE:用於獲取當前某個介面描述符編號 9) 11  SET_INTERFACE:用於主機要求設備用某個描述符來描述介面 10) 12 SYNCH_FRAME:用於設備設置和報告一個端點的同步幀 以上的11個命令要說得明白真的有一匹布那麼長,請各位去看書吧,這裡就不多說了,控制傳輸是USB的重心,而這11個命令是控制傳輸的重心,所以這11個命令是重中之重,這個搞明白了,USB就算是入門了。 問題八:在標準的USB請求命令中,經常會看到Descriptor,這是什麼來的呢? 回答八:Descriptor即描述符,是一個完整的數據結構,可以通過C語言等編程實現,並存儲在USB設備中,用於描述一個USB設備的所有屬性,USB主機是通過一系列命令來要求設備發送這些信息的。它的作用就是通過如問答節中的命令***作來給主機傳遞信息,從而讓主機知道設備具有什麼功能、屬於哪一類設備、要占用多少帶寬、使用哪類傳輸方式及數據量的大小,只有主機確定了這些信息之後,設備才能真正開始工作,所以描述符也是十分重要的部分,要好好掌握。標準的描述符有5種,USB為這些描述符定義了編號: 1——設備描述符 2——配置描述符 3——字元描述符 4——介面描述符 5——端點描述符 上面的描述符之間有一定的關係,一個設備只有一個設備描述符,而一個設備描述符可以包含多個配置描述符,而一個配置描述符可以包含多個介面描述符,一個介面使用了幾個端點,就有幾個端點描述符。這間描述符是用一定的欄位構成的,分別如下說明: 1、設備描述符
struct _DEVICE_DEscriptOR_STRUCT
{
BYTE bLength;          //設備描述符的位元組數大小,為0x12
BYTE bDescriptorType;  //描述符類型編號,為0x01
WORD bcdUSB;           //USB版本號
BYTE bDeviceClass;  //USB分配的設備類代碼,0x01~0xfe為標準設備類,0xff為廠商自定義類型
                        //0x00不是在設備描述符中定義的,如HID
    BYTE bDeviceSubClass;   //usb分配的子類代碼,同上,值由USB規定和分配的
    BYTE bDeviceProtocl;    //USB分配的設備協議代碼,同上
    BYTE bMaxPacketSize0;   //端點0的最大包的大小
    WORD idVendor;          //廠商編號
    WORD idProduct;         //產品編號
    WORD bcdDevice;         //設備出廠編號
    BYTE iManufacturer;     //描述廠商字元串的索引
    BYTE iProduct;          //描述產品字元串的索引
    BYTE iSerialNumber;     //描述設備序列號字元串的索引
    BYTE bNumConfiguration; //可能的配置數量
}
2、配置描述符
struct _CONFIGURATION_DEscriptOR_STRUCT
{
BYTE bLength;          //設備描述符的位元組數大小,為0x12
BYTE bDescriptorType;  //描述符類型編號,為0x01
WORD wTotalLength;     //配置所返回的所有數量的大小
BYTE bNumInterface;    //此配置所支持的介面數量
BYTE bConfigurationVale;   //Set_Configuration命令需要的參數值
BYTE iConfiguration;       //描述該配置的字元串的索引值
BYTE bmAttribute;          //供電模式的選擇
BYTE MaxPower;             //設備從匯流排提取的最大電流 
}
3、字元描述符
struct _STRING_DEscriptOR_STRUCT
{
BYTE bLength;          //設備描述符的位元組數大小,為0x12
BYTE bDescriptorType;  //描述符類型編號,為0x01
BYTE SomeDescriptor[36];          //UNICODE編碼的字元串
}
4、介面描述符
struct _INTERFACE_DEscriptOR_STRUCT
{
BYTE bLength;          //設備描述符的位元組數大小,為0x12
BYTE bDescriptorType;  //描述符類型編號,為0x01
BYTE bInterfaceNunber; //介面的編號
BYTE bAlternateSetting;//備用的介面描述符編號
BYTE bNumEndpoints;    //該介面使用端點數,不包括端點0
BYTE bInterfaceClass;  //介面類型
BYTE bInterfaceSubClass;//介面子類型
BYTE bInterfaceProtocol;//介面所遵循的協議
BYTE iInterface;        //描述該介面的字元串索引值
}
5、端點描述符
struct _ENDPOIN_DEscriptOR_STRUCT
{
BYTE bLength;          //設備描述符的位元組數大小,為0x12
BYTE bDescriptorType;  //描述符類型編號,為0x01
BYTE bEndpointAddress; //端點地址及輸入輸出屬性
BYTE bmAttribute;      //端點的傳輸類型屬性
WORD wMaxPacketSize;   //端點收、發的最大包的大小
BYTE bInterval;        //主機查詢端點的時間間隔
}

 

----------------------------------------------------------- 更新:20161009 關聯:http://blog.csdn.net/t5studio Email:[email protected]    
您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • (本文是從我的舊博客遷移過來的) 問題地址:http://acm.timus.ru/problem.aspx?space=1&num=1258 前幾日在博客園看到這種線上測試的時候,有一種相見恨晚的感覺,於是隨便選了一道感興趣的題(No.1258:Pool)開始做。為了準確瞭解題的意思,我把題翻譯成 ...
  • 本次將要很大家分享的是一個跨平臺運行的服務插件 - TaskCore.MainForm,此框架是使用.netcore來寫的,現在netcore已經支持很多系統平臺運行了,所以將以前的Task.MainForm改良成跨平臺的服務共大家使用和相互交流;本來這篇應該分享的是nginx+iis+redis+ ...
  • ...
  • 剖析 AssemblyInfo.cs - 從這裡瞭解常用的特性 Attribute 【博主】反骨仔 【原文】http://www.cnblogs.com/liqingwen/p/5944391.html 序 上次,我們通過《C# 知識回顧 - 特性 Attribute》已經瞭解如何創建和使用特性 A ...
  • 配置 ASP.NET HTTP 運行時設置,以確定如何處理對 ASP.NET 應用程式的請求,配置節及其描述如下所示。 <httpRuntime executionTimeout="110" 指定在被 ASP.NET 自動關閉前,允許執行請求的最大秒數 maxRequestLength="4096" ...
  • 從eclipse到android studio的安卓開發經驗告訴我原聲開發才是硬道理,其實以前很抵觸html5開發app的,雖然沒有去瞭解過,但是冥冥中就覺得它運行速度太慢了,載入渲染根本比不上原生開發,並且如果系統與硬體交互比較深的話就更沒法使用html5了。一個偶然機會,我開始接觸html5開發 ...
  • ASP.NET Core請求處理管道由一個伺服器和一組中間件構成。如果想非常深刻地認識ASP.NET Core的請求處理管道,我覺得可以分兩個步驟來進行:首先,我們可以在忽略具體細節的前提下搞清楚管道處理HTTP請求的總體流程;在對總體流程有了大致瞭解之後,我們再來補充這些刻意忽略的細節。為了讓讀者... ...
  • 1、安裝環境 安裝.Net Core SDK 安裝VS2015 Update3 安裝DotNetCore.1.0.1-VS2015Tools.Preview2.0.2.exe 2、新建Core工程 項目結構圖 3、運行 如果選擇IIS Express啟動方式,埠則隨機,如果選擇項目名稱運行預設埠 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...