本文轉自公眾號系列文章,歡迎關注
基于DWC2的USB驅動開發(fā)-USB包詳解 (qq.com)

一.前言

前面我們對SETUP完成標志DOEPINTn.SetUp進行了詳細的分析，該標志用于表明SETUP階段的完成，數(shù)據(jù)階段(無數(shù)據(jù)階段則是狀態(tài)階段)的開始。我們知道控制傳輸有三個階段SETUP階段，數(shù)據(jù)階段，狀態(tài)階段，現(xiàn)在我們知道了什么時候由SETUP階段轉數(shù)據(jù)階段，那么什么時候數(shù)據(jù)階段轉狀態(tài)階段呢? 這個問題就引出了我們繼續(xù)這篇文章的分析。

我們發(fā)現(xiàn)本系列文章很多都是自然而然地問題引出的，然后針對問題去查找答案，以此來進行USB的學習和開發(fā)，相信這種狀態(tài)是一種很好的狀態(tài)，甚至很多人會有意猶未竟，追劇的感覺，解決一個問題又冒出一個問題，又促使繼續(xù)深挖，搞技術就是要如此。

二.DOEPINTn.StsPhseRcvd

之前我們就講了手冊中的如下表格，對應的不同的控制傳輸?shù)臓顟B(tài)，但是當時還是云里霧里不甚理解，上一篇我們抽絲剝繭了解了Setup的含義，這一篇繼續(xù)來分析StsPhseRcvd，把每一個bit的精確含義理解了，再來理解這個表格就容易了。

還是老規(guī)矩我們先來看手冊的描述

定義就是StsPhseRcvd表示控制傳輸切換到了狀態(tài)階段。

只有Scatter Gather DMA模式，控制OUT端點有，順便提一下本系列文章沒有單獨說明則都是針對Scatter Gather DMA模式。

下面也說明了本標志產(chǎn)生的條件是:控制器接收了控制寫傳輸?shù)臄?shù)據(jù)階段,主機發(fā)過來的所有數(shù)據(jù)，并搬運到了緩沖區(qū)中(注意并不是用戶空間中，搬運到用戶空間還需要XferCompl來指明，即上述Case D和Case E的區(qū)別)。表明主機由數(shù)據(jù)階段切換到了狀態(tài)階段。

該中斷后設備程序可以進行狀態(tài)階段的響應了。

這里順便提一下控制器處理時DOEPINTn.StsPhseRcvd優(yōu)先級高于DOEPINTn.Setup。

以上的說明還是不夠精確，還是協(xié)議層面的描述，比如數(shù)據(jù)階段切換到狀態(tài)階段到底是對應的具體的哪個節(jié)點呢，對應的是誰發(fā)了什么包之后呢？

編程手冊中如下有描述，實際是數(shù)據(jù)OUT階段之后，設備收到了IN令牌之后置該位。

是不是很熟悉，原來和Setup的置位原理是差不多的，也是設備端延遲確認。

同樣的是因為OUT數(shù)據(jù)階段，設備回了ACK之后，主機收沒收到ACK，設備并不知道，主機下一步是不是需要重新OUT還是進入狀態(tài)階段設備也不知道，所以只能等主機發(fā)了IN才知道主機切換到了狀態(tài)階段。

如下所示

這里我們還是同樣的會有一個疑問，為什么只有控制寫的OUT端點有這個標志，為什么控讀IN端點沒有？

前面我們知道判斷Setup完成的標志是，設備在SETUP后收到了OUT或者IN，

如果收到了OUT則表示SETUP階段完成，開始控制寫數(shù)據(jù)階段，

如果收到了IN則表示SETUP階段完成，可能是開始讀數(shù)據(jù)階段或無數(shù)據(jù)，直接進入狀態(tài)階段。因為是硬件判斷的對于IN存在兩種情況，所以硬件實際不好判斷 ，所以交給軟件去判斷。

所以對于這幾種模式軟件操作流程如下:

所以對于控制讀操作，SETUP完成后，軟件就需要同時準備好OUT描述符以接收狀態(tài)包，同時準備IN描述符以發(fā)送數(shù)據(jù)。數(shù)據(jù)和狀態(tài)同時處理。

SETUP階段 -> 數(shù)據(jù)和狀態(tài)

對于控制寫操作，SETUP完成后，軟件準備OUT描述符以接收數(shù)據(jù)，StsPhseRcvd中斷后再準備IN描述符發(fā)送狀態(tài)包。數(shù)據(jù)階段和狀態(tài)階段分開處理。

SETUP階段-> 數(shù)據(jù)階段 -> 狀態(tài)階段

對于無數(shù)據(jù)控制傳輸

SETUP完成后，準備IN描述符準備發(fā)送狀態(tài)包。

SETUP階段- -> 狀態(tài)階段

三.DOEPINTn.XferCompl/DIEPINTn.XferCompl

分別表示IN和OUT描述符已經(jīng)被DMA處理，即RxFIFO的內(nèi)容搬運到了用戶空間，或者用戶空間數(shù)據(jù)搬運到了TxFIFO。

注意這里DMA處理完和實際總線上數(shù)據(jù)發(fā)送和接收是兩碼事。

比如對于IN端點，XferCompl完成，只是表示用戶數(shù)據(jù)搬運到了TxFIFO中，

下一次IN令牌，硬件才從TxFIFO中取出數(shù)據(jù)發(fā)送到總線上去。

這里注意如果TxFIFO中還有殘留的之前的數(shù)據(jù)，則本次搬運到TxFIFO的數(shù)據(jù)還不會發(fā)送，要等后續(xù)的IN才會發(fā)送。

所以一般這里需要先Flush掉TxFIFO，保證下一次IN發(fā)送的就是本次的數(shù)據(jù)。

四. **DIEPINTn.INTknTX****FEmp /DOEPINTn.OUTTknEPdis **

五.驅動編寫注意事項

設備軟件必須等到StsPhseRcvd中斷即主機發(fā)了IN才能切換到狀態(tài)階段，準備IN描述符準備發(fā)0長包。因為如果主機不發(fā)IN則主機可能還在數(shù)據(jù)階段，此時設備并不能確認下一包就是IN。

同樣的因為設備確認有滯后，實際是在IN令牌后才能進該中斷，確認主機進入了狀態(tài)階段，所以對于該IN硬件是自動NAK的，

所以中斷服務函數(shù)中軟件除了EPEna之外還要CNAK，以在后續(xù)IN中硬件根據(jù)新設置的IN描述符響應狀態(tài)包(0長包)。

注意IN端點，及時Flush掉TxFIFO，保證下一次IN，傳輸?shù)氖潜敬卧O置的IN描述符對應的數(shù)據(jù)。

六.總結

以上對DOEPINTn.StsPhseRcvd進行了詳細的解析，和Setup原理基本類似，同時也介紹了其他一些相關中斷位。

審核編輯 黃宇