1. 程式人生 > >STM32 之 USB 虛擬串列埠

STM32 之 USB 虛擬串列埠

        在現代個人電腦的USB是幾乎所有外設的標準通訊埠。然而許多工業應用軟體仍然使用經典的串列埠(UART)。USB虛擬串列埠提供了繞過這個問題的一個簡單的解決方案。

        為了讓USB被視為一個COM埠,USB裝置必須根據通訊裝置類(CDC)規範來實現兩個介面:

1.抽象控制模型通訊,在端點中有1箇中斷:在我們的實現中,這個介面在描述符中宣告,但是相關的端點(端點2)不被使用。

2.抽象控制模型資料,具有1個bulk in端點和一個bulk out 端點,這個介面在實際中由端點1(in)和端點3(out)表示。端點1用於通過USB將從UART接收到的資料傳送到PC。端點3用於接收來自PC的資料並通過UART傳送。

為了實現虛擬COM埠,該裝置支援以下類特定請求:

● SET_CONTROL_LINE_STATE:

RS-232訊號用於告訴裝置資料終端裝置現在是存在的.該請求總是在Virtual_Com_Port_NoData_Setup() 函式中返回一個USB_SUCCESS(usb_prop.c中 )。

● SET_COMM_FEATURE:

控制特定通訊功能的設定。這個請求總是在Virtual_Com_Port_NoData_Setup() 函式中返回一個USB_SUCCESS(usb_prop.c中 )。

● SET_LINE_CODING:

傳送裝置的配置。它包括波特率、停止位、奇偶校驗和字元位數。所接收的資料儲存在一個特定的資料結構中,稱為“linecoding”,用於更新UART引數。

● GET_LINE_CODING:

此命令要求獲取裝置當前波特率、停止位、奇偶校驗和字元位數。該裝置用儲存在“linecoding”結構中的資料做出響應。

硬體配置介面

在虛擬COM埠中的硬體配置介面(hw _ config.c)管理以下程式:

●配置的系統和外設(USB和USART)時鐘和中斷

●USART預設值初始化

●用通過SET_LINE_CODING命令收到的引數配置串列埠

●把收到的資料傳送到PC,通過USB串列埠通訊

●傳送收到的資料通過USB串列埠通訊

1、USB標準規範型別

    USB規範大致可分為以下三類:

1)、標準規範

    標準規範為最基礎的規範,主要有USB1.0、USB1.1、USB2.0和USB3.0等等。

2)、USB裝置類規範

    裝置類規範主要是針對於具體的USB裝置而推出的類規範,有Mass Storage、Audio Device、Video Device等等裝置相關規範。

3)、USB HOST控制器規範

    主要有OHC和UHC等

1、標準規範

     USB是通用序列匯流排的英文縮寫,是Intel公司開發的匯流排架構,使得在計算機上新增序列裝置非常容易。只須將裝置插入計算機的USB埠中,系統會自動識別和配置。根據時代發展,USB介面標準經歷了一代USB、第二代USB 2.0和第三代USB 3.0。

    USB規格第一次是於1995年,由Intel、IBM、Compaq、Microsoft、NEC、Digital、North Telecom等七家公司組成的USBIF(USB Implement Forum)共同提出,USBIF於1996年1月正式提出USB1.0規格,頻寬為1.5Mbps.不過因為當時支援USB的周邊裝置少的可憐,所以主機板商不太把USB Port直接設計在主機板上。

    USB2.0技術規範是有由Compaq、Hewlett Packard、Intel、Lucent、Microsoft、NEC、Philips共同制定、釋出的,規範把外設資料傳輸速度提高到了480Mbps,是USB 1.1裝置的40倍!2000年制定的USB 2.0標準是真正的USB 2.0,被稱為USB 2.0的高速(High-speed)版本,理論傳輸速度為480 Mbps.

    USB 3.0是最新的USB規範,該規範由英特爾等公司發起,USB3.0的最大傳輸頻寬高達5.0Gbps(640MB/s),USB3.0 引入全雙工資料傳輸。5根線路中2根用來發送資料,另2根用來接收資料,還有1根是地線。也就是說,USB 3.0可以同步全速地進行讀寫操作。

USB版本

最大傳輸速率

速率稱號

最大輸出電流

推出時間

USB1.0

1.5Mbps(192KB/s)

低速(Low-Speed)

5V/500mA

1996年1月

USB1.1

12Mbps(1.5MB/s)

全速(Full-Speed)

5V/500mA

1998年9月

USB2.0

480Mbps(60MB/s)

高速(High-Speed)

5V/500mA

2000年4月

USB3.0

5Gbps(500MB/s)

超高速(Super-Speed)

5V/900mA

2008年11月

USB 3.1

10Gbps(1280MB/s)

超高速+(Super-speed+)

20V/5A

2013年12月

這是從時間維度上來看的,但是每一代USB介面針對不同的裝置又細分出來具體的型號,如USB Type A/B/C/Mini/Micro。下面是USB2.0和USB3.0標準下的各類介面示意圖:

一、USB系統的結構

    USB系統是由三個邏輯層組成:功能層、USB裝置層和USB匯流排介面層。並且每一層都是由主機和USB裝置不同的功能模組組成,如下圖所示:

1、功能層(介面)

    功能層是由客戶軟體和裝置方的功能單元組成,其能夠實現USB裝置傳輸的特定功能。通過功能層可直觀地理解USB傳輸的資料內容。其中,客戶軟體通過USB系統軟體來與USB裝置進行通訊。功能單元對於客戶軟體,可視為介面的集合。

2、USB裝置層 (端點)

    USB裝置層是由USB系統軟體和USB裝置的USB邏輯裝置組成,其實現主機和USB裝置之間傳輸的具體配置。USB邏輯裝置對於USB系統軟體,可視為端點的集合。

3、USB匯流排介面層

    USB匯流排介面層是由主機的USB主控制器和裝置的USB匯流排介面組成。其實現主機和USB裝置實際的資料傳輸。

4、主機部分

    USB主機部分由客戶軟體、USB系統軟體和USB匯流排介面組成。

4.1 客戶軟體

    客戶軟體負責和USB裝置的功能單元進行通訊,以實現特定的功能。客戶軟體不能直接與USB裝置相連線,必須通過USB系統軟體和USB匯流排接口才能實現連線。客戶軟體包括USB裝置驅動程式和介面應用程式兩部分。

4.2 USB系統軟體

    USB系統軟體負責和USB邏輯裝置進行配置通訊,並管理客戶軟體啟動的資料。一般包括USB匯流排驅動程式、USB主控制驅動程式和非USB主機軟體三個部分,這部分會由系統提供。

4.3 USB匯流排接

    USB匯流排介面包括主控制器和跟集線器兩部分。其中,主控制器是負責完成主機和USB裝置間的資料實際傳輸。根集線器是為USB系統連線起點。

5、裝置部分

    USB裝置部分由三個功能模組組成,分別是USB匯流排介面、USB邏輯裝置和功能單元。

    功能單元看作是一個介面的集合;USB 邏輯裝置被USB系統軟體看作一個端點的集合;USB匯流排介面是USB裝置中的序列介面引擎(SIE)。

    當客戶程式通過USB管道傳送或接收資料時,它首先呼叫Win32 APl,呼叫最終將使功能驅動程式收到一個IRP。而驅動程式的工作就是把客戶的請求引導到有正確端點的管道上。它把請求提交到匯流排驅動程式,匯流排驅動程式再把請求分解成多個事務,然後這些事務被送往匯流排。總線上的資訊流以每毫秒一幀資料的形式流動。匯流排驅動程式必須安排好多個事務以使它們能被裝入同一幀中。

二、USB的拓撲結構

    USB是一種主從結構的系統。主機叫Host,從機叫做Device(也叫裝置)。通常所說的主機具有一個或者多個USB主控制器(host  controller)和根集線器(root hub)。主控制器主要負責資料處理,而跟集線器則提供一個連線主控制器與裝置之間的介面和通路。

    通常情況下,PC機上有多個主控器和多個USB口,一個主控器下有一根集線器,一根集線器通常具有一個或者幾個USB介面。通常集線器可以通過USB集線器來擴充套件USB介面,只是頻寬是不能夠拓寬的,因為頻寬是共享一個USB主控器的。

    瞭解上面的資訊後,再來看USB的拓撲結構如下圖:

USB的拓撲結構看起來是一個金字塔形的結構,具體構成如下:

    塔頂是USB的主控器和根集線器,下面接USB集線器,USB集線器將一個USB口擴充套件為多個USB口,多個USB口同樣可以通過USB集線器擴展出更多的介面。不過USB口並不能通過USB集線器無止境的擴充套件,他是有限制的,例如在USB2.0規定它最多擴充套件6次。

    理論上一個USB主控器最多可接127個裝置,這是因為協議規定每個USB裝置具有一個7bit地址(取值範圍為0~127,地址用於給主機識別是哪個裝置,其中0地址值得注意,是給剛接入未初始化的裝置使用的)。

三、USB的裝置架構

    裝置架構認為裝置是由一些配置、介面和端點構成的。其中配置和介面是USB功能的抽象,實際的資料傳輸由端點來完成。其對應關係如下圖所示:

1.裝置

    裝置代表USB裝置,它由一個或多個配置組成。裝置描述符用於說明裝置的總體資訊,並指出其所包含配置的個數。

2.配置 

    在使用USB裝置前,必須為其選擇一個合適的配置。如USB裝置的低功耗模式和高功耗模式分別對應一個配置。配置描述符用於說明USB裝置中各個配置的特性。

3.介面 

    一個配置可以包含一個或多個介面。介面是一個端點的集合。介面描述符用於說明USB裝置中各個介面的特性。 

4.端點 

    端點是USB裝置中的實際物理單元,USB資料傳輸就是在主機和USB裝置各個端點之間進行的。

5、管道

    管道,是主機軟體(資料緩衝區)和USB裝置的各個端點之間的資料傳輸連結,它是兩者之間通訊流的抽象。然而,實際的資料傳輸是由USB匯流排介面層來完成的。管道和USB裝置中的端點一一對應,並且各個管道的資料傳輸是相互獨立的。

    管道有兩種型別:流管道和訊息管道。其中最為重要的訊息管道是“預設控制管道”,這個管道在裝置開始上電後就存在了,它用於提供裝置的配置與狀態等資訊。主機與裝置之間的聯絡就是通過訊息管道實現的。

四、USB列舉與通訊的具體過程

1、USB接頭

    下圖是一個USB接頭的結構圖:

    由圖可以看出,標準的USB連結線使用4芯電纜:5V電源線(Vbus)\差分資料線負(D-)、差分資料線正(D+)和地線(GND)。

    在hub端,資料線D+和D-都有一個阻值在14.25k到24.8k的下拉電阻Rpd,而在裝置端,D+(全速,高速)和D-(低速)上有一個1.5k的上拉電阻Rpu。當裝置插入到hub埠時,有上拉電阻的一根資料線被拉高到幅值的90%的電壓(大致是3V)。hub檢測到它的一根資料線是高電平,就認為是有裝置插入,並能根據是D+還是D-被拉高來判斷到底是什麼裝置(全速/低速)插入埠。

2、USB通訊過程

    主機和USB裝置可以相互傳輸資料,其具體過程如下(以主機箱裝置傳輸為例):

step1:客戶軟體首先將要傳輸的資料放入緩衝區,同時向USB匯流排驅動程式發出IRPS,請求資料傳輸。(客戶軟體)step2:USB匯流排驅動接收到程式接收請求,並對資料進行處理,轉化為具有USB格式的事務處理。(USB系統軟體)

step3:USB主控制器驅動程式將這些事務處理建立成事務列表,同時要求不能超過USB頻寬。(USB系統軟體)

step4:USB主控制器讀取到事務列表並將事務轉化為資訊包,傳送到USB總線上。(USB匯流排介面)

step5:USB裝置收到這些資訊後,SIE(USB匯流排介面是USB裝置中的序列介面引擎)將其解包後放入指定端點的接收緩衝區內,由晶片韌體對其進行處理。

用框圖表示如下:

3、USB列舉通訊具體過程

   列舉就是從裝置讀取一些資訊,知道裝置是什麼樣的裝置,如何進行通訊,這樣主機就可以根據這些資訊來載入合適的驅動程式。除錯USB裝置,很重要的一點就是USB的列舉過程,只要列舉成功了,那麼就已經成功大半了。

列舉通訊過程具體如下:

step1:檢測電壓變化,報告主機

    首先,USB裝置上電後,一直監測USB裝置介面電平變化HUB檢測到有電壓變化,將利用自己的中斷端點將資訊反饋給主控制器有裝置連線。

Step2:主機瞭解連線裝置

    主機在知道有裝置接入後會傳送一個Get_Port_Status請求(request)給hub以瞭解此次狀態改變的確切含義。

Step3:Hub檢測所插入的裝置是高速還是低速

    hub通過檢測USB匯流排空閒(Idle)時差分線的高低電壓來判斷所連線裝置的速度型別,當host發來Get_Port_Status請求時,hub就可以將此裝置的速度型別資訊回覆給host。USB 2.0規範要求速度檢測要先於復位(Reset)操作。

Step4:hub復位裝置

    主機一旦得知新裝置已連上以後,它至少等待100ms以使得插入操作的完成以及裝置電源穩定工作。然後主機控制器就向hub發出一個 Set_Port_Feature請求讓hub復位其管理的埠(剛才裝置插上的埠)。hub通過驅動資料線到復位狀態(D+和D-全為低電平 ),並持續至少10ms。當然,hub不會把這樣的復位訊號傳送給其他已有裝置連線的埠,所以其他連在該hub上的裝置自然看不到復位訊號,不受影響。

Step5: Host檢測所連線的全速裝置是否是支援高速模式

    因為根據USB 2.0協議,高速(High Speed)裝置在初始時是預設全速(Full Speed )狀態執行,所以對於一個支援USB 2.0的高速hub,當它發現它的埠連線的是一個全速裝置時,會進行高速檢測,看看目前這個裝置是否還支援高速傳輸,如果是,那就切到高速訊號模式,否則就一直在全速狀態下工作。

    同樣的,從裝置的角度來看,如果是一個高速裝置,在剛連線bub或上電時只能用全速訊號模式執行(根據USB 2.0協議,高速裝置必須向下相容USB 1.1的全速模式)。隨後hub會進行高速檢測,之後這個裝置才會切換到高速模式下工作。假如所連線的hub不支援USB 2.0,即不是高速hub,不能進行高速檢測,裝置將一直以全速工作。

Step6:Hub建立裝置和主機之間的資訊通道

    主機不停地向hub傳送Get_Port_Status請求,以查詢裝置是否復位成功。Hub返回的報告資訊中有專門的一位用來標誌裝置的復位狀態。

       當hub撤銷了復位訊號,裝置就處於預設/空閒狀態(Default state),準備接收主機發來的請求。裝置和主機之間的通訊通過控制傳輸,預設地址0,端點號0進行。此時,裝置能從總線上得到的最大電流是100mA。(所有的USB裝置在匯流排復位後其地址都為0,這樣主機就可以跟那些剛剛插入的裝置通過地址0通訊。)

Step7:主機發送Get_Descriptor請求獲取預設管道的最大包長度

     預設管道(Default Pipe)在裝置一端來看就是端點0。主機此時傳送的請求是預設地址0,端點0,雖然所有未分配地址的裝置都是通過地址0來獲取主機發來的請求,但由於列舉過程不是多個裝置並行處理,而是一次列舉一個裝置的方式進行,所以不會發生多個裝置同時響應主機發來的請求。

      裝置描述符的第8位元組代表裝置端點0的最大包大小。雖然說裝置所返回的裝置描述符(Device Descriptor)長度只有18位元組,但系統也不在乎,此時,描述符的長度資訊對它來說是最重要的,其他的瞄一眼就過了。當完成第一次的控制傳輸後,也就是完成控制傳輸的狀態階段,系統會要求hub對裝置進行再一次的復位操作(USB規範裡面可沒這要求)。再次復位的目的是使裝置進入一個確定的狀態。

Step8:主機給裝置分配一個地址

     主機控制器通過Set_Address請求向裝置分配一個唯一的地址。在完成這次傳輸之後,裝置進入地址狀態(Address state),之後就啟用新地址繼續與主機通訊。這個地址對於裝置來說是終生制的,裝置在,地址在;裝置消失(被拔出,復位,系統重啟),地址被收回。同一個裝置當再次被列舉後得到的地址不一定是上次那個了。

Step9:主機獲取裝置的資訊

    主機發送 Get_Descriptor請求到新地址讀取裝置描述符,這次主機發送Get_Descriptor請求可算是誠心,它會認真解析裝置描述符的內容。裝置描述符內資訊包括端點0的最大包長度,裝置所支援的配置(Configuration)個數,裝置型別,VID(Vendor ID,由USB-IF分配), PID(Product ID,由廠商自己定製)等資訊。

    之後主機發送Get_Descriptor請求,讀取配置描述符(Configuration Descriptor),字串等,逐一瞭解裝置更詳細的資訊。事實上,對於配置描述符的標準請求中,有時wLength一項會大於實際配置描述符的長度(9位元組),比如255。這樣的效果便是:主機發送了一個Get_Descriptor_Configuration 的請求,裝置會把介面描述符,端點描述符等後續描述符一併回給主機,主機則根據描述符頭部的標誌判斷送上來的具體是何種描述符。

      接下來,主機就會獲取配置描述符。配置描述符總共為9位元組。主機在獲取到配置描述符後,根據裡面的配置集合總長度,再獲取配置集合。配置集合包括配置描述符,介面描述符,端點描符等等。

     如果有字串描述符的話,還要獲取字串描述符。另外HID裝置還有HID描述符等。

Step10: 主機給裝置掛載驅動(複合裝置除外)

    主機通過解析描述符後對裝置有了足夠的瞭解,會選擇一個最合適的驅動給裝置。  然後tell the world(announce_device)說明裝置已經找到了,最後呼叫裝置模型提供的介面device_add將裝置新增到 usb 匯流排的裝置列表裡,然後 usb匯流排會遍歷驅動列表裡的每個驅動,呼叫自己的 match(usb_device_match) 函式看它們和你的裝置或介面是否匹配,匹配的話呼叫device_bind_driver函式,現在就將控制權交到裝置驅動了。   

     對於複合裝置,通常應該是不同的介面(Interface)配置給不同的驅動,因此,需要等到當裝置被配置並把介面使能後才可以把驅動掛載上去。

Step11:裝置驅動選擇一個配置

    驅動(注意,這裡是驅動,之後的事情都是有驅動來接管負責與裝置的通訊)根據前面裝置回覆的資訊,傳送Set_Configuration請求來正式確定選擇裝置的哪個配置(Configuration)作為工作配置(對於大多數裝置來說,一般只有一個配置被定義)。至此,裝置處於配置狀態(Configured),當然,裝置也應該使能它的各個介面(Interface)。

    對於複合裝置,主機會在這個時候根據裝置介面資訊,給它們掛載驅動。

一、端點概念。

    端點(Endpoint),是主機與裝置之間通訊資料的接收或來源。主機與裝置之間通訊時最終會總用於裝置上的各個端點,它是主機與裝置間通訊流的一個邏輯終端。一系列相互獨立的端點在一起構成了USB邏輯裝置,在系統結構中,位於下方紅色方框內:

二、端點的分類

    每個USB裝置都有一個唯一的裝置地址,裝置地址是裝置連線上主機時由主機分配的,主機主要依靠這個裝置地址對USB裝置進行訪問。但是在裝置內部地址會被分的更細,裝置會分出一些端點來,每個端點在裝置都會有唯一的端點號,這個端點號是設計裝置時給定的。如端點0,端點1等。一個裝置最多可以包含16個端點,每個端點的地址為0-15。(網上也有說幾十個的,有待考究)    

    其中每個端點地址對應一個方向。例如端點3-IN,端點3-OUT,這兩個含義完全不同。但是需要注意其中的一個特殊端點--端點0,每個USB裝置必須要有一個端點0,其作用為對裝置列舉和對裝置進行一些基本的控制功能,端點0也被稱為控制端點。並且它與其他的端點還有一個不同之處在於端點0的資料傳輸方向是雙向的,即端點0既可以給主機發送資料,也可以接收主機發送過來的資料,而其它端點均為單向。

    雖然有16個端點,但通常我們只用到3個,如下:

     1)、EP0:做傳輸配置和控制資訊;

     2)、EP1:做資料輸入IN_EP;

     3)、EP2:做資料輸出OUT_EP。

注意:除了端點0,其餘的端點在裝置配置之前不能與主機通訊,只有向主機報告這些端點的特性並被確認後才能被啟用。

三、端點的特性

    一個端點的特性決定了它與客戶軟體進行傳送的型別。一個端點具有以下一些特性:

   ·端點的匯流排訪問頻率要求

   ·端點的匯流排延遲要求

   ·端點的頻寬要求

   ·端點的端點號

   ·對錯誤處理的要求

   ·端點能接收或傳送的包的最大長度

   ·端點的傳送型別

   ·端點與主機的資料傳送方向

四、端點描述符

    USB裝置中端點描述符描述了端點資訊,端點描述符格式如下:

typedef struct _USB_ENDPOINT_DESCRIPTOR_

{

    BYTE        bLength,

    BYTE        bDescriptorType,

    BYTE        bEndpointAddress,

    BYTE        bmAttributes,

    WORD      wMaxPacketSize,

    BYTE        bInterval

}USB_ENDPOINT_DESCRIPTOR;

各變數具體釋義如下:

bLength : 描述符大小.固定為0x07.

bDescriptorType : 介面描述符型別.固定為0x05.

bEndpointType : USB裝置的端點地址.Bit7,方向,對於控制端點可以忽略,1/0:IN/OUT.Bit6-4,保留.BIt3-0:端點號.

bmAttributes : 端點屬性.Bit7-2,保留.BIt1-0:00控制,01同步,02批量,03中斷.

wMaxPacketSize : 本端點接收或傳送的最大資訊包大小.

bInterval : 輪訓資料傳送端點的時間間隔.對於批量傳送和控制傳送的端點忽略.對於同步傳送的端點,必須為1,對於中斷傳送的端點,範圍為1-255。

五、端點與管道

1、管道的概念

    管道是主機軟體(資料快取區),和USB裝置各各端點之間的資料傳輸連線,他是兩者之間通訊流的抽象(實際上資料傳輸是USB匯流排介面完成)。管道與USB裝置中的端點逐個對應,並且各個管道的資料傳輸是相互獨立的。

2、管道的格式分類

    管帶的通訊格式分為兩種,一種為流,另一種為訊息,這兩種通訊格式不同且互斥。

1)、“流”指不具有USB定義格式的資料流,流通道中的資料是流的形式,也就是該資料內容不具有USB要求的結構。資料從流通道一端流進的順序與它們從流通道另一端流出時的順序是一樣的(先進先出),並且流通道中的通訊流總是單向的。

2)、“訊息”指具有某種USB定義格式的資料流。訊息通道與端點的關係同流通道與端點的關係是不同的。首先,主機向USB裝置發出一個請求;接著,就是資料的傳送;最後,是一個狀態階段(這部分即一次命令請求的過程)。為了能夠容納請求/資料/狀態的變化,訊息通道要求資料有一個格式,此格式保證了命令能夠被可靠地傳送和確認。訊息通道允許雙方向的資訊流。

六、端點的傳輸型別

    一個具體的端點只能屬於四個傳輸模式下中的一種。資料傳輸型別分為四種分別是:控制傳輸、批量傳輸、同步傳輸和中斷傳輸。一般情況下,通常把工作在什麼模式下的端點就叫什麼端點,例如:控制端點、批量端點、同步端點和中斷端點。

    端點0,是裝置的預設控制端點,在裝置上電後就存在並可以使用,在Set Config之前所有的傳輸都是通過端點0傳輸的。

USB控制傳輸分為以下四種:

  • 批量傳輸:批量傳輸一般用於批量的和非實時的資料傳輸,通俗的來說就是用於資料量大但對時間要求又不高的場合的一種傳輸方式,類似用於USB印表機和USB掃描器等等。
  • 中斷傳輸:中斷傳輸一般用於小批量的和非連續的資料傳輸,通俗的來說就是用於資料量小的資料不連續的但實時性高的場合的一種傳輸方式,類似用於USB滑鼠和USB鍵盤等等。
  • 等時傳輸:等時傳輸也有“同步傳輸”的叫法,一般用於要求資料連續、實時且資料量大的場合,其對傳輸延時十分敏感,類似用於USB攝像裝置,USB語音裝置等等。
  • 控制傳輸:控制傳輸是一種特殊的傳輸方式,且傳輸過程相對以上三種而言更復雜一些,但也十分重要。當USB裝置初次連線主機時,用控制傳輸傳送控制命令等對裝置進行配置。同時裝置接入主機時,需要通過控制傳輸去獲取USB裝置的描述符以及對裝置進行識別,在裝置的列舉過程中都是使用控制傳輸進行資料交換。

一、控制傳輸的結構

    一次完整控制傳輸可以分為三個階段:初始設定階段--->資料階段(不必須)--->狀態資訊階段。下面的

1、初始設定階段

    初始設定階段用於固定建立SETUP事務,標誌一次控制傳輸的開始。初始設定階段為一個SETUP事務,同樣分為三個階段如下:

令牌包階段:

    主機會發送一個SETUP令牌包,如下:

相當於告訴裝置,我要跟你進行通訊請你做好準備。

資料包階段:

    傳送DATA0資料包(注意SETUP只能使用DATA0包,8位元組),讓裝置接收。例如傳送獲取裝置描述符命令包:

相當於告訴裝置,請將裝置描述符的內容發給我。

握手包階段:

    裝置自動應答。

結合上面的過程可以用下圖表示初始設定階段。

2、資料階段

    初始設定階段中命令如果要求讀/寫資料,資料階段就會在這一階段來具體交換資料(如果沒有資料交換要求則可省去該步驟,具體有SETUP事務標準請求命令決定)。在此需要做一些說明:傳輸控制在前言有說到控制傳輸的用途是獲取裝置資訊與對裝置進行配置。所以這些資料操作分為以下三類:

1)、控制讀傳輸;

2)、控制寫傳輸;

3)、無資料控制傳輸。

    一次控制傳輸必定為上面三種中的其中一種,所以資料階段中的資料事務也是根據該規則來決定資料事務的。

    此處還應該注意的是資料階段是由一到多個IN/OUT事務組成。這是由於有時候存在一個事務傳不完的資料,所以可能存在多個連續IN/OUT事務的情況。這也就決定了,在同一次資料傳輸階段中事務型別必定相同(IN/OUT事務)。

2.1、傳輸格式

    綜上所述,所以從傳輸控制的不同型別來講述資料階段的格式會更好理解。

1)、控制讀傳輸

    控制讀傳輸時資料階段在整個傳輸的格式如下圖藍框部分:

資料方向為:裝置 —> 主機 (讀取USB描述符)

    這裡每個資料包是DATA0和DATA1交替出現的。需要注意的是當最後一個包剛好為允許的最大資料包大小時需要再傳一個0長度的資料包,表示傳輸的結束。

控制讀傳輸的資料過程IN事務的三個階段如下:

令牌包階段:

    主機會發送一個IN令牌包,觸發裝置產生IN包中斷,如下:

資料包階段:

    裝置回覆主機請求,迴應資料。例如回覆裝置描述符命令請求:

握手包階段:

    主機自動應答。

2)、控制寫傳輸

    控制寫傳輸時資料階段在整個傳輸的格式如下下圖藍框部分:

資料方向為:主機 —> 裝置(配置USB裝置)

傳輸過程和規則基本與讀取相似,不多做贅述。

3)、無資料控制

    控制傳輸不一定要傳輸很多資料,有些控制可能只是告訴裝置要做一件事,這個命令包含在建立階段的建立事務的8位元組資料中即可,裝置只需回覆主機收到命令與否即可,所以就跳過資料階段直接進入到狀態階段。無資料控制的格式如下圖:

所以注意在無資料控制傳輸時,是無資料階段的!

3、狀態資訊階段

    狀態資訊階段是要返回資料傳輸的成功與否,具體也需要看控制傳輸的型別。需要注意的是,狀態資訊的資料傳輸方向與資料階段方向相反。例如,資料階段為IN事務則狀態資訊階段為OUT事務。

3.1、控制讀傳輸

    在控制讀傳輸時,該階段則為OUT事務,其中的資料包固定為DATA1資料包。返回資料成功與否以有以下情況:

    1)、讀資料成功                      主機發送OUT令牌包(ping令牌包,高速情況下),主機發送0長度資料包,裝置ACK。

    2)、資料傳輸出錯                   主機發送OUT令牌包(ping令牌包,高速情況下),主機發送0長度資料包,裝置STALL。

    3)、裝置忙(比如正在寫資料)   主機發送OUT令牌包(ping令牌包,高速情況下),主機發送0長度資料包,裝置NAK。 

控制讀傳輸的狀態資訊階段OUT事務的三個階段如下(以ACK為例):

令牌包階段:

    主機會發送一個OUT令牌包,如下:

資料包階段:

    主機發送0位元組資料包,作為狀態正常資訊迴應:

握手包階段:

    裝置自動應答。

3.2、控制寫傳輸

    在控制讀傳輸時,該階段則為IN事務,其中的資料包固定為DATA1資料包。返回資料成功與否以有以下情況:

    1)、寫資料成功                      主機發送IN令牌包,主機發送0長度資料包,裝置回覆ACK。

    2)、資料傳輸出錯                   主機發送IN令牌包,裝置回覆STALL。

    3)、裝置忙(比如正在寫資料)   主機發送IN令牌包,裝置回覆NAK。 

控制讀傳輸的狀態資訊階段IN事務過程與讀類似。

3.3、無資料控制傳輸

    該階段則為IN事務,其規則與控制寫傳輸相似。

至此,一次控制傳輸完成,整個過程結束。

STM32F103 的 MCU 自帶 USB 從控制器,符合 USB 規範的通訊連線;PC 主機和微控制器
之間的資料傳輸是通過共享一專用的資料緩衝區來完成的,該資料緩衝區能被 USB 外設直接訪
問。這塊專用資料緩衝區的大小由所使用的端點數目和每個端點最大的資料分組大小所決定,
每個端點最大可使用 512 位元組緩衝區(專用的 512 位元組,和 CAN 共用),最多可用於 16 個單
向或 8 個雙向端點。USB 模組同 PC 主機通訊,根據 USB 規範實現令牌分組的檢測,資料傳送
/接收的處理,和握手分組的處理。整個傳輸的格式由硬體完成,其中包括 CRC 的生成和校驗。
每個端點都有一個緩衝區描述塊,描述該端點使用的緩衝區地址、大小和需要傳輸的位元組
數。當 USB 模組識別出一個有效的功能/端點的令牌分組時,(如果需要傳輸資料並且端點已配
置)隨之發生相關的資料傳輸。USB 模組通過一個內部的 16 位暫存器實現埠與專用緩衝區的
資料交換。在所有的資料傳輸完成後,如果需要,則根據傳輸的方向,傳送或接收適當的握手
分組。在資料傳輸結束時,USB 模組將觸發與端點相關的中斷,通過讀狀態暫存器和/或者利用
不同的中斷來處理。
USB 的中斷對映單元:將可能產生中斷的 USB 事件對映到三個不同的 NVIC 請求線上:
1、USB 低優先順序中斷(通道 20):可由所有 USB 事件觸發(正確傳輸,USB 復位等)。韌體
在處理中斷前應當首先確定中斷源。
2、USB 高優先順序中斷(通道 19):僅能由同步和雙緩衝批量傳輸的正確傳輸事件觸發,目
的是保證最大的傳輸速率。
3、USB 喚醒中斷(通道 42):由 USB 掛起模式的喚醒事件觸發

ST 提供的 USB 驅動庫,可以在: http://www.stmcu.org/document/detail/index/id-213156 這裡
下載到(STSW-STM32121)

 

ST 不但提供原始碼,還提供了說明檔案:CD00158241.pdf(UM0424),專門講解 USB 庫怎
麼使用。有了這些資料對我們瞭解 STM32F103 的 USB 會有不少幫助,尤其在不懂的時候,看
看 ST 的例程,會有意想不到的收穫。本實驗的 USB 部分就是移植 ST 的 Virtual_COM_Port 例
程相關部分而來,完成一個 USB 虛擬串列埠的功能。
硬體設計

53.3 軟體設計
程式碼移植自 ST 官方例程:

有了這個官方例程做指引,我們就知道具體需要哪些檔案,從而實現本例程。
首先,在工程資料夾下面,新建 USB 資料夾,
並拷貝官方 USB 驅動庫相關程式碼到該資料夾下,即拷貝STM32_USB-FS-Device_Lib_V4.0.0Libraries 資料夾下的 STM32_USB-FS-Device_Driver 資料夾到該資料夾下面。然後,在 USB 資料夾下,新建 CONFIG 資料夾存放 Virtual COM 實現相關程式碼,即:STM32_USB-FS-Device_Lib_V4.0.0ProjectsVirtual_COM_Portsrc 資料夾下的部分程式碼:
hw_config.c、usb_desc.c、usb_endp.c、usb_istr.c、usb_prop.c 和 usb_pwr.c 等 6 個.c 檔案,同時
拷貝:STM32_USB-FS-Device_Lib_V4.0.0ProjectsVirtual_COM_Portinc 資料夾下面的:
hw_config.h、platform_config.h、usb_conf.h、usb_desc.h、usb_istr.h、usb_prop.h 和 usb_pwr.h 等
7 個頭檔案到 CONFIG 資料夾下,最後 CONFIG 資料夾下的檔案如圖

之後,根據 ST 官方 Virtual_COM_Port 例程,在我們本章例程的基礎上新建分組新增相關
程式碼,具體細節,這裡就不詳細介紹了,新增好之後,如圖  所示: 

移植時,我們重點要修改的就是 CONFIG 資料夾下面的程式碼,USB_CORE 資料夾下的代
碼一般不用修改。現在,我們先來簡單介紹一下 USB_CORE 資料夾下的幾個.c 檔案。

usb_regs.c 檔案,該檔案主要負責 USB 控制暫存器的底層操作,裡面有各種 USB 暫存器
的底層操作函式。
usb_init.c 檔案,該檔案裡面只有一個函式:USB_Init,用於 USB 控制器的初始化,不過對
USB 控制器的初始化,是 USB_Init 呼叫用其他檔案的函式實現的,USB_Init 只不過是把他們
連線一下罷了,這樣使得程式碼比較規範。
usb_int.c 檔案,該檔案裡面只有兩個函式 CTR_LP 和 CTR_HP,CTR_LP 負責 USB 低優先
級中斷的處理。而 CTR_HP 負責 USB 高優先順序中斷的處理。
usb_mem.c 檔案,該檔案用於處理 PMA 資料,PMA 全稱為 Packet memory area,是 STM32
內部用於 USB/CAN 的專用資料緩衝區,該檔案內也只有 2 個函式即: PMAToUserBufferCopy
和 UserToPMABufferCopy,分別用於將 USB 端點的資料傳送給主機和主機的資料傳送到 USB
端點。
usb_croe.c 檔案,該檔案用於處理 USB2.0 協議。
usb_sil.c 檔案,該檔案為 USB 端點提供簡化的讀寫訪問函式。
以上幾個檔案具有很強的獨立性,除特殊情況,不需要使用者修改,直接呼叫內部的函式即
可。接著我們介紹 CONFIG 資料夾裡面的幾個.c 檔案。
hw_config.c 檔案,該檔案用於硬體的配置,比如初始化 USB 時鐘、USB 中斷、低功耗模
式處理等。
usb_desc.c 檔案,該檔案用於 Virtual Com 描述符的處理。
usb_endp.c 檔案,該檔案用於非控制傳輸,處理正確傳輸中斷回撥函式。
usb_pwr.c 檔案,該檔案用於 USB 控制器的電源管理;
usb_istr.c 檔案,該檔案用於處理 USB 中斷。
usb_prop.c 檔案,該檔案用於處理所有 Virtual Com 的相關事件,包括 Virtual Com 的初始
化、復位等等操作。
另外官方例程用到 stm32_it.c 來處理 USB 相關中斷,包括兩個中斷服務函式,第一個是:
USB_LP_CAN1_RX0_IRQHandler 函式,我們在該函式裡面呼叫 USB_Istr 函式,用於處理 USB
發生的各種中斷。另外一個就是 USBWakeUp_IRQHandler 函式,我們在該函式就做了一件事:
清除中斷標誌。為了方便,我們直接將 USB 中斷相關程式碼,全部放到 hw_config.c 裡面,所以,
本例程直接用不到 stm32_it.c。
USB 相關程式碼,就給大家介紹到這裡,詳細的介紹,請大家參考:CD00158241.pdf 這個文
檔。
注意,以上程式碼,有些是經過修改了的,並非完全照搬官方例程。接著我們在工程檔案裡
面新建 USB_CORE 和 USB_CONFIG 分組,分別加入 USB\ STM32_USB-FS-Device_Driver\src
下面的程式碼和 USB\CONFIG 下面的程式碼,然後把 USB\STM32_USB-FS-Device_Driver\inc 和
USB\CONFIG 資料夾加入標頭檔案包含路徑。
最後修改 main.c 裡面程式碼如下:
int main(void)
{
u16 t; u16 len;
u16 times=0; u8 usbstatus=0;
delay_init(); //延時函式初始化
NVIC_PriorityGroupConfig(NVIC_PriorityGroup_2); //設定 NVIC 中斷分組 2
uart_init(115200); //串列埠初始化為 115200
LED_Init(); //初始化與 LED 連線的硬體介面

LCD_Init(); //初始化 LCD
POINT_COLOR=RED; //設定字型為紅色
LCD_ShowString(30,50,200,16,16,"WarShip STM32");
LCD_ShowString(30,70,200,16,16,"USB Virtual USART TEST");
LCD_ShowString(30,90,200,16,16,"[email protected]");
LCD_ShowString(30,110,200,16,16,"2015/1/28");
LCD_ShowString(30,130,200,16,16,"USB Connecting...");//提示 USB 開始連線
delay_ms(1800);
USB_Port_Set(0); //USB 先斷開
delay_ms(700);
USB_Port_Set(1); //USB 再次連線
Set_USBClock();
USB_Interrupts_Config();
USB_Init();
while(1)
{
if(usbstatus!=bDeviceState)//USB 連線狀態發生了改變.
{
usbstatus=bDeviceState;//記錄新的狀態
if(usbstatus==CONFIGURED)
{
POINT_COLOR=BLUE;
LCD_ShowString(30,130,200,16,16,"USB Connected "); //連線成功
LED1=0;//DS1 亮
}else
{
POINT_COLOR=RED;
LCD_ShowString(30,130,200,16,16,"USB disConnected "); //提示斷開
LED1=1;//DS1 滅
}
}
if(USB_USART_RX_STA&0x8000)
{
len=USB_USART_RX_STA&0x3FFF;//得到此次接收到的資料長度
usb_printf("\r\n 您傳送的訊息為:%d\r\n\r\n",len);
for(t=0;t<len;t++)
{
USB_USART_SendData(USB_USART_RX_BUF[t]);//按位元組傳送給 USB
}
usb_printf("\r\n\r\n");//插入換行
USB_USART_RX_STA=0;
}else
{

times++;
if(times%5000==0)
{
usb_printf("\r\n 戰艦 STM32 開發板 USB 虛擬串列埠實驗\r\n");
usb_printf("正點原子@ALIENTEK\r\n\r\n");
}
if(times%200==0)usb_printf("請輸入資料,以回車鍵結束\r\n");
if(times%30==0)LED0=!LED0;//閃爍 LED,提示系統正在執行.
delay_ms(10);
}
}
}
在此部分程式碼用於實現我們在硬體設計部分提到的功能,USB 的配置通過三個函式完成:
USB_Interrupts_Config()、Set_USBClock()和 USB_Init(),第一個函式用於設定 USB 喚醒中斷和
USB 低優先順序資料處理中斷,Set_USBClock 函式用於 配置 USB 時鐘,也就是從 72M 的主頻
得到 48M 的 USB 時鐘(1.5 分頻)。最後 USB_Init()函式用於初始化 USB,最主要的就是呼叫
了 Virtual_Com_Port_init 函式,開啟了 USB 部分的電源等。這裡需要特別說明的是,USB 配置
並沒有對 PA11 和 PA12 這兩個 IO 口進行設定,是因為,一旦開啟了 USB 電源(USB_CNTR
的 PDWN 位清零)PA11 和 PA12 將不再作為其他功能使用,僅供 USB 使用,所以在開啟了 USB
電源之後不論你怎麼配置這兩個 IO 口,都是無效的。要在此獲取這兩個 IO 口的配置權,則需
要關閉 USB 電源,也就是置位 USB_CNTR 的 PDWN 位,我們通過 USB_Port_Set 函式來禁止/
允許 USB 連線,在復位的時候,先禁止,再允許,這樣每次我們按復位電腦都可以識別到 USB
滑鼠,而不需要我們每次都拔 USB 線。USB_Port_Set 函式在 hw_config.c 裡面實現,程式碼請參
考本例程原始碼。
USB 虛擬串列埠的資料傳送,我們通過函式:USB_USART_SendData 來實現,該函式在
hw_config.c 裡面實現,該函式程式碼如下:
//傳送一個位元組資料到 USB 虛擬串列埠
void USB_USART_SendData(u8 data)
{
uu_txfifo.buffer[uu_txfifo.writeptr]=data;
uu_txfifo.writeptr++;
if(uu_txfifo.writeptr==USB_USART_TXFIFO_SIZE)//超過 buf 大小了,歸零.
{
uu_txfifo.writeptr=0;
}
}
該函式實現傳送 1 個位元組到虛擬串列埠,這裡,我們用到了一個 uu_txfifo 的結構體,該結構
體是我們在 hw_config 裡面定義的一個 USB 虛擬串列埠傳送資料 FIFO 結構體,定義如下:
//定義一個 USB USART FIFO 結構體
typedef struct
{
u8 buffer[USB_USART_TXFIFO_SIZE]; //buffer
vu16 writeptr; //寫指標

vu16 readptr; //讀指標
}_usb_usart_fifo;
extern _usb_usart_fifo uu_txfifo; //USB 串列埠傳送 FIFO
該結構體用於處理 USB 串列埠要傳送的資料,所有要通過 USB 串列埠傳送的資料,都將先存
放在該結構體的 buffer 陣列(FIFO 快取區)裡面,USB_USART_TXFIFO_SIZE 定義了該陣列
的大小,通過 writeptr 和 readptr 來控制 FIFO 的寫入和讀出,該結構體 buffer 資料的寫入,是
通過 USB_USART_SendData 函式實現,而 buffer 資料的讀出(然後傳送到 USB)則是通過端
點 1 回撥函式:EP1_IN_Callback 函式實現,該函式在 usb_endp.c 裡面實現,程式碼如下:
void EP1_IN_Callback (void)
{
u16 USB_Tx_ptr;
u16 USB_Tx_length;
if(uu_txfifo.readptr==uu_txfifo.writeptr) return; //無任何資料要傳送,直接退出
if(uu_txfifo.readptr<uu_txfifo.writeptr) //沒有超過陣列,讀指標<寫指標
{
USB_Tx_length=uu_txfifo.writeptr-uu_txfifo.readptr; //得到要傳送的資料長度
}else //超過陣列了 讀指標>寫指標
{
USB_Tx_length=USB_USART_TXFIFO_SIZE-uu_txfifo.readptr;//傳送的資料長度
}
if(USB_Tx_length>VIRTUAL_COM_PORT_DATA_SIZE) //超過 64 位元組?
{
USB_Tx_length=VIRTUAL_COM_PORT_DATA_SIZE; //此次傳送資料量
}
USB_Tx_ptr=uu_txfifo.readptr; //傳送起始地址
uu_txfifo.readptr+=USB_Tx_length; //讀指標偏移
if(uu_txfifo.readptr>=USB_USART_TXFIFO_SIZE) //讀指標歸零
{
uu_txfifo.readptr=0;
}
UserToPMABufferCopy(&uu_txfifo.buffer[USB_Tx_ptr], ENDP1_TXADDR, USB_Tx_
length);
SetEPTxCount(ENDP1, USB_Tx_length);
SetEPTxValid(ENDP1);
}
這個函式由 USB 中斷處理相關函式呼叫,將要通過 USB 傳送給電腦的資料拷貝到端點 1
的傳送區,然後通過 USB 傳送給電腦,從而實現串列埠資料的傳送。因為 USB 每次傳輸資料長
度不超過 VIRTUAL_COM_PORT_DATA_SIZE,所以 USB 傳送資料長度:USB_Tx_length 的最
大值只能是 VIRTUAL_COM_PORT_DATA_SIZE。
以上,就是 USB 虛擬串列埠的資料傳送過程,而 USB 虛擬串列埠資料的接收,則是通過端點
3 來實現的,端點 3 的回撥函式為 EP3_OUT_Callback,該函式也是在 usb_endp.c 裡面定義,代
碼如下:
void EP3_OUT_Callback(void)

{
u16 USB_Rx_Cnt;
USB_Rx_Cnt = USB_SIL_Read(EP3_OUT, USB_Rx_Buffer);
//得到 USB 接收到的資料及其長度
USB_To_USART_Send_Data(USB_Rx_Buffer, USB_Rx_Cnt);
//處理資料(其實就是儲存資料)
SetEPRxValid(ENDP3); //時能端點 3 的資料接收
}
該函式也是被 USB 中斷處理呼叫,該函式通過呼叫 USB_To_USART_Send_Data 函式,實
現 USB 接收資料的儲存,USB_To_USART_Send_Data 函式在 hw_config.c 裡面實現,程式碼如下:
//用類似串列埠 1 接收資料的方法,來處理 USB 虛擬串列埠接收到的資料.
u8 USB_USART_RX_BUF[USB_USART_REC_LEN];
//接收緩衝,最大 USART_REC_LEN 個位元組.
//接收狀態
//bit15, 接收完成標誌
//bit14, 接收到 0x0d
//bit13~0, 接收到的有效位元組數目
u16 USB_USART_RX_STA=0; //接收狀態標記
//處理從 USB 虛擬串列埠接收到的資料
//databuffer:資料快取區
//Nb_bytes:接收到的位元組數.
void USB_To_USART_Send_Data(u8* data_buffer, u8 Nb_bytes)
{
u8 i;
u8 res;
for(i=0;i<Nb_bytes;i++)
{
res=data_buffer[i];
if((USB_USART_RX_STA&0x8000)==0) //接收未完成
{
if(USB_USART_RX_STA&0x4000) //接收到了 0x0d
{
if(res!=0x0a)USB_USART_RX_STA=0;//接收錯誤,重新開始
else USB_USART_RX_STA|=0x8000; //接收完成了
}else //還沒收到 0X0D
{
if(res==0x0d)USB_USART_RX_STA|=0x4000;
else
{
USB_USART_RX_BUF[USB_USART_RX_STA&0X3FFF]=res;
USB_USART_RX_STA++;
if(USB_USART_RX_STA>(USB_USART_REC_LEN-1))
USB_USART_RX_STA=0;//接收資料錯誤,重新開始接收

}
}
}
}
}
該函式接收資料的方法,同第九章串列埠通訊實驗的串列埠中斷接收資料方法完全一樣,在這
裡就不詳細介紹了,請參考第九章相關內容即可。USB_To_USART_Send_Data 函式類似於串列埠
通訊實驗的串列埠中斷服務函式(USART1_IRQHandler),完成 USB 虛擬串列埠的資料接收。

相關推薦

STM32 USB 虛擬串列

        在現代個人電腦的USB是幾乎所有外設的標準通訊埠。然而許多工業應用軟體仍然使用經典的串列埠(UART)。USB虛擬串列埠提供了繞過這個問題的一個簡單的解決方案。         為了讓USB被視為一個COM埠,USB裝置必須根據通訊裝置類(CDC)規範來實現

STM32學習筆記USB虛擬串列描述符簡介

Descriptor即描述符,是一個完整的資料結構,可以通過C語言等程式設計實現,並存儲在USB裝置中,用於描述一個USB裝置的所有屬性,USB主機是通過一系列命令來要求裝置傳送這些資訊的。它的作用就是通過如問答節中的命令***作來給主機傳遞資訊,從而讓主機知道裝置具有

轉 [經驗] STM32 USB虛擬串列(有原始碼)

原文出處:http://bbs.elecfans.com/jishu_467116_1_1.html   串列埠除錯在專案中被使用越來越多,串列埠資源的緊缺也變的尤為突出。很多本本人群,更是深有體會,不準備一個USB轉串列埠工具就沒辦法進行開發。本章節來簡單概述STM32低端晶片上

STM32 USB虛擬串列問題彙總

彙總1:STM32的USB例程修改步驟,來自http://blog.csdn.net/cy757/archive/2010/01/01/5117610.aspx 以下是筆者將ST的Custom_HID例程修改為“自定義USB裝置”例程時總結出來的,因為筆者也是剛剛學USB開發不久,某些方面理解錯誤在所難免,

USB虛擬串列

現代嵌入式系統中,非同步序列通訊介面往往作為標準外設出現在微控制器和嵌入式系統中。但是隨著個人計算機通用外圍裝置越來越少地使用串列埠,串列埠正在逐漸從個人計算機特別是行動式電腦上消失。於是嵌入式開發人員常常發現自己新買來的計算機上沒有串列埠,或者出現除錯現場使用者的計算機沒有串列埠的尷尬局面。相反,

Android USB Host 串列程式設計

1.OTG:  A.手機作為Host,裝置作為Device,手機給裝置充電,需要通過OTG線實現(microUSB);(裝置可以為鍵盤/滑鼠/主機等等) B.手機作為Host,另一手機作為Device,通過OTG可以通訊; 2.PC連線Android:(不需要OTG) A.

USB虛擬串列實驗_STM32F1開發指南_第五十三章——USB學習筆記

前言     STM32F103系列晶片都自帶USB,不過STM32F103的USB都只能用來做裝置,而不能用作主機。 目錄: 53.1 USB簡介     USBF103自帶的USB符合USB2.0規範。     在USB主機上,D-和D+都接了15K下拉電

WinCE usb虛擬串列

1.Usb驅動程式的載入 識別到USB裝置插入到電腦上(姑且這麼認為吧) fRet = LoadDeviceDrivers(pDev, &fLoaded); if(fRet && !fLoaded) { //失敗了,提示使用者對話方塊, } 1.1L

一種通過登錄檔獲取USB虛擬串列號的方法

在開發一個Modbus的串列埠監測工具軟體的時候,啟動工具軟體,希望一開始就能在下拉框檢測到當前有效的USB串列埠。 剛開始做的時候是用的窮舉法,就是“COM0”~“COM15”一個一個嘗試開啟。但是,這樣做一個是效率低下,另一個是換了新的USB-串列埠介面卡,有可能虛擬串

USB 虛擬串列簡介

1. USB虛擬串列埠簡介 USB虛擬串列埠屬於USB通訊裝置類。在物理層通過USB匯流排,採用虛擬串列埠的方式為主機提供一個物理串列埠。在系統內部,USB控制器提供了一個批量傳輸IN端點和一個批量傳輸的OUT端點,用於資料的接收和傳送,模擬串列埠的RX和TX線。另外USB

嵌入式開發USB串列驅動:Win10不再支援PL2303

1.開啟裝置管理器,可以看到PL2303對應的驅動上有一個感嘆號: 2.Outline... 3.Outline... 4.

Win7雙機除錯環境搭建配置VMware的管道虛擬串列

轉:http://www.16boke.com/article/detail/171 WinDbg除錯核心時,被設計為雙機除錯,需要另一臺計算機(除錯機)來除錯被除錯的計算機(被除錯機),WinDbg必須安裝在除錯機上,除錯機與被除錯機通過串列埠相連線。   環境: 主機:

STM32 USB Virtual COM USB串列的功能實現

/* USB標準裝置描述符*/ constuint8_tVirtual_Com_Port_DeviceDescriptor[VIRTUAL_COM_PORT_SIZ_DEVICE_DESC]= { 0x12,/*bLength:長度,裝置描述符的長度為18位元組*/ USB_DEVICE_DESC

v虛擬機器Linux(Fedora10)下USB串列的使用, minicom: cannot open /dev/ttyUSB0的解決

轉自:http://blog.csdn.net/boygrass/article/details/6878167 網路上有很多Linux下USB轉串列埠的使用方式,但在我這邊好像總是出現 minicom: cannot open /dev/ttyUSB0:No such

虛擬機器Linux(Fedora10)下USB串列的使用, minicom: cannot open /dev/ttyUSB0的解決

網路上有很多Linux下USB轉串列埠的使用方式,但在我這邊好像總是出現 minicom: cannot open /dev/ttyUSB0:No such file or directory 或no such device的情況。 以下是我自己的解決方法,在這裡記錄一下。

虛擬機器識別串列USB串列

1.虛擬機器識別串列埠 VM -> Settings -> (左下角)Add  -> Serial Port   (注意: 要在虛擬機器系統未啟動時設定) 選擇要新增的串列埠(建議不要使用Auto detect) 勾選 Connected  和 Conne

linux使用USB串列驅動設定

【一】、驅動相關說明: 如果直接使用串列埠線,而沒有用到USB轉串列埠裝置,就不需要安裝驅動。 如果使用了USB轉串列埠,一般情況下也不需要安裝驅動了,目前linux系統已經包含了該驅動,可以自動識別,亦可通過以下命令檢視以便確認是否支援。 檢視模組裝載的情況: 引用 lsmod |

ubuntu安裝USB串列驅動(PL2303)

在Ubuntu下利用minicom進行嵌入式開發時可能會用到USB轉串列埠,這時就會用到USB轉串列埠驅動,以前的Ubuntu是直接將此驅動編譯進核心,但不知道從哪個版本開始Ubuntu將其從核心去掉了,所以要用到Ubuntu的minicom時只能由我們自己安裝USB轉串列埠驅動,方法如下:

WIN7 64位系統 CDC類 虛擬串列驅動無法安裝的解決辦法(2)

(1)最近用STM32使用USB——CDC類出現驅動安裝失敗的情況。 百度了一些網頁,方法很多,大多數是按照如下步驟處理: 首先,確保C:\Windows\System32\drivers\usbser.sys檔案存在; 其次,修改C:\Windows\inf\mdmcpq.inf檔

WIN7 64位系統 CDC類 虛擬串列驅動無法安裝的解決辦法

最近用STM32使用USB——CDC類出現驅動安裝失敗的情況。 百度了一些網頁,方法很多,但是我這裡按如下步驟處理: 首先,確保C:\Windows\System32\drivers\usbser.sys檔案存在; 其次,修改C:\Windows\inf\mdmcpq.inf檔案;