本來對ＵＳＢ接口緩沖區(qū)的知識等于零，因為在前想圖點省事曾請教關(guān)于串口編程的知識而不得（并無怨言，與芯片結(jié)構(gòu)無直接關(guān)聯(lián)的內(nèi)容理當自己去學習），就不得不去廣泛查找相關(guān)的知識，當然因此誘發(fā)了這個討論就是意外的收獲了。

　　這里要探討的不是串口通訊，借用控件“MSComm”數(shù)據(jù)緩沖區(qū)讀寫（同時清空）的功能，自己編寫的程序就可以源源不斷地讀取串口通訊后臺存貯的數(shù)據(jù)，而不必隨時照料芯片什么時間填充這些存貯空間。

　　具體地說就是同樣在一個ＣＨ３４１芯片結(jié)構(gòu)中，既然串口傳輸已經(jīng)成功地嚙合到操作系統(tǒng)控件的數(shù)據(jù)緩沖區(qū)中，用戶只要在沒有發(fā)生溢出之前及時取走現(xiàn)存的數(shù)據(jù)，就不會造成數(shù)據(jù)損失，那么并口照樣也可以輕易地做到，所差不過是把ＡＰＩ結(jié)構(gòu)中由應用軟件直接調(diào)用讀寫的操作，改變?yōu)椴僮飨到y(tǒng)直接進行罷了。

　　例如我在那篇《[原創(chuàng)]巧用CH341評估板測試并口接收速率 》帖子中闡明的那樣，實測選擇了最大限度選擇了4096字節(jié)的緩沖區(qū)，也只能做到每毫秒22到23組32字節(jié)（總數(shù)大約700左右）的接收速率。雖然對比芯片公開的數(shù)據(jù)還是明顯不足，但至少是現(xiàn)實能夠達到的標準；而因為實際運用中再大的緩沖區(qū)也難以滿足需要，再次調(diào)用同樣的ＡＰＩ指令就存在銜接的問題，甚至因為不能確定硬件實際傳輸效益，為避免幀間數(shù)據(jù)的損失不得不再降低標準保守使用。

　　這樣的改變對芯片用戶而言就有莫大的好處。后臺操作的結(jié)果是芯片及配套的ＡＰＩ只要面對操作系統(tǒng)，或者簡單地說就是最大限度地不斷填充系統(tǒng)內(nèi)存劃撥出來的緩沖區(qū)，而用戶則只要隨時從緩沖區(qū)取走數(shù)據(jù)而不管你的填充速度。于是只要１Ｋ而不是現(xiàn)在上限的４Ｋ就足夠無限量連續(xù)采集而不怕傳輸遺失了。

　　其實發(fā)表這個討論的題目還真不是一時興致所致，而是經(jīng)歷了許多艱辛勞動得出的一些數(shù)據(jù)總結(jié)出來的。年前曾借用CH341評估板的VB程序做了些修改，試圖通過不斷調(diào)用縮小到1幀可能容納的最大限度再降低一格標準，來完成連續(xù)采集的需要，結(jié)果是取到2A0H（21組）就已經(jīng)不能保證可靠性了， 繼續(xù)減少不過提高那么一點半點也無完全的保證。所以，如果按上述的做法就可以在保證最大效益的基礎上保證采集數(shù)據(jù)的完整性，當然外設的單片機程序也是必不可少的緩沖機制，就不在這個話題的討論范圍了。

　　正因為沒有可靠的保證，才不得不選擇速度要慢得多的串行傳輸，也因此感覺到那幾條指令確實能夠解決實際的問題。具體的說就是只有緩沖區(qū)里邊有數(shù)據(jù)，無論多少都可以一次讀出來同時空閑出原來的位置，只要取值的間隔遠遠小于填充的速度就可以，而無須關(guān)注這個差異是否過大。

　　換句話說，就是現(xiàn)在的做法是主動型，一次索取多少就是多少（而并非說明的那樣“返回實際數(shù)量”），你沒滿足我將一直等待你的完成，“其余的事情什么也干不了”或者可以接受，但完成的時間恰好進入下一幀，就不是簡單地浪費了已經(jīng)占用的時間，而是在剩余的時間必須眼睜睜白白地等待！于是你就只好考慮犧牲那么一兩組數(shù)據(jù)的時間來遷就，卻總也難免意外的情況發(fā)生。相反，我這里要說的方式就是改主動為被動，人家有多少就拿多少，大不了多“跑”幾次，偶爾“跑空”罷了，不在每次有多少收獲，只要保證沒有遺漏就好。

　　這個問題應該不局限于ＣＨ３４１，其他ＣＨ３７Ｘ系列也應該存在相同的因素……