在《CH341DS2.PDF》的5.3節(jié)有“可以連接兩組74LS244+74LS273，從而實現(xiàn)16 位數(shù)字信號輸入和16 位數(shù)字信號輸出”的說法，事實上如果單純考慮現(xiàn)場信號輸入，只要兩片4位數(shù)據(jù)選擇器（74系列的157或257）就可以搞定，現(xiàn)實中這種需求很多。
遺憾的是無論公開的API，還是提供的示例都沒有實際的介紹。感覺是只要把讀寫地址0和地址1的命令綜合為一組連續(xù)讀寫，能直接組成16位當然更好，否則單獨連續(xù)存貯也比沒有的好。我自己雖然需要，估計一年最多也不會超過幾千片，但沒準就有人會成萬的需要，所以建議考慮追加一組至少是讀取的API。
關于MEM并口時序我們提供了4個API接口函數(shù)能滿足客戶的需求,關于16位數(shù)字信號輸入和16位數(shù)字信號輸出,你可以通過讀寫兩次來實現(xiàn)
如果對速度有要求，這種外部過程的調用就顯得很差勁了。而且由于微機對USB接口信號的處理不是太及時，有時候這種額外的延遲往往造成無法使用的后果。如果增加一組讀寫16位的API，就能夠解決大部分問題。
感覺作為元件的開發(fā)商，本來硬件可以做到的功能，卻在軟件的配合上“差之毫厘”，實在是非常值得惋惜的事情。
你提得這個我們會考慮. USB接口信號的處理不是太及時,其實是因為USB的傳輸是定時傳輸,且所有任務需要HOST統(tǒng)籌分配.ms級以內的實時響應不易實現(xiàn). 對于支持16位操作,1樓已提供方法.如您覺得您程序速度慢,您發(fā)郵件到tech@wch.cn,把您操作的步驟寫上,我們看一下,是否可以幫您提高些速度.你單次傳輸?shù)臄?shù)據(jù)越多,函數(shù)執(zhí)行的效率越高.
呵呵，我個人認為：只要API處理得當，實時響應速度達到100K（8位）是完全有可能的。這個理念是基于按100K字節(jié)的速率每個周期占用時間為10微秒，而微機處理USB信號的周期為1ms，如無其它任務僅需要處理一個設備的流通時，在正式建立溝通后每周期開始的聯(lián)絡應該可以在10個字節(jié)內完成，于是理想的情況下就可以作到完全無遺漏的傳遞過程（特別是輸入）。
當然每幀信號間會有一點間隔，偶爾的意外也可能發(fā)生，但這些情況不過造成“萬一”甚至更小比例的遺漏，即使按我“邏輯分析儀”這樣的實際用途，除了通常也不是完全不能“容忍”外，還有多次收集信號互相比較補回遺漏信號的補救措施可用哈。而多數(shù)實時采集系統(tǒng)對于偶然的遺漏甚至完全不“感冒”，所以我的建議并非只是個別的需要，而是對貴公司提高產(chǎn)品競爭力有著至關重要的意義。
我還不至于幼稚到勞駕貴公司技術人員花費很大精力來滿足自己數(shù)量不會太大的需求，事實上CH341這種主動型元件，即使達到上述要求也滿足不了我的16位速度要求，本來已經(jīng)改用帶內部緩沖的CH372解決我的問題，并且完成了單片機的編程任務，如果不是因為管角密度太大的制約，恐怕已經(jīng)做好樣機了。我15日（剛剛頂起來的）帖子《CH372有沒有可能提供SOP封裝？ 》就是因此而發(fā)表的。
之所以發(fā)表這個討論帖，固然因為實際上體現(xiàn)了一種可能會有著廣泛的需求，或許會得到貴公司的重視，當然也有自己的需要，而這一切本來就是建立在足夠的可行性這樣的基礎上，具體的技術問題另外發(fā)表主帖討論，這里只談需要：事實上我的需要僅僅在于一條簡化了的指令，就是不帶緩沖區(qū)的“CH341MemReadAddr0（）”。
不要告訴我可以用原來那個API直接指定連續(xù)讀取數(shù)據(jù)的長度為1就ＯＫ了，事實上那條指令包含了建立緩沖區(qū)、甚至還有為了遷就硬件速度的延遲等額外的時間占用，我需要的僅僅是沒有任何附加因素的“讀”命令，在意的就是一個絕對的速度。當然，只要有了這個無須過多更改的指令，受益的不僅僅是本人，而將必然大大擴展了貴公司芯片的適應范圍。
有一點我是要聲明,我們技術支持是給客戶提供關于我們芯片的技術支持.不管什么客戶,他有多少量,我們都會盡力去協(xié)助. 對于CH341并口的操作,可能改動的是將您所操作的一些的命令代碼整合到一起發(fā)給CH341,減少SOF包的間隔,不是單純的將函數(shù)進行拼接.默認的是每個函數(shù)執(zhí)行一次進行一次USB傳輸,執(zhí)行之間有SOF的間隔.之前我們也幫客戶做過這樣改動. 但在并口操作上大家做法都不一定相同,有在讀寫之前先進行片選,有做一些IO操作.
呵呵，感覺6樓的帖子好象修改過，跟我周日上來時看過的有不同。只記得當時看過一句令我非常吃驚的說法，所以就沒敢跟帖繼續(xù)詢問了。感覺現(xiàn)在的說法好象比較貼切些。
我試圖說明的是：作為芯片制造商，既然硬件已經(jīng)擁有16位的讀寫能力（A0輸出高低電平不同的連續(xù)兩次操作），利用軟件實現(xiàn)起來應該完全沒什么問題的，而充分發(fā)揮這個特性的作用，對于提高產(chǎn)品的市場競爭力具有很大的優(yōu)勢。
而現(xiàn)實情況是明明產(chǎn)品的性能介紹如主帖所述那樣包含的功能，卻在實際的操作指令（或者說是函數(shù)集合）中卻應該包括而不去實現(xiàn)，不得不說是一重大的失誤！
說得直白一點：只要存在數(shù)組（緩沖區(qū)）哪怕只有2個不同的數(shù)值，就不能把地址0和地址1的數(shù)值當作16位數(shù)來看待，而只能說是兩個不同地址的8位數(shù)；而只要連續(xù)變化A0電平，即使間或有些單獨的變化，則不但可以當作16位看待，且只要數(shù)值變化的速度不大于雙倍的檢測周期，就可以根據(jù)連續(xù)三次的數(shù)值來判斷變化的規(guī)律。
我現(xiàn)在已經(jīng)沒精力管什么16位數(shù)據(jù)的問題了，急于知道的是當發(fā)布一條需要讀或寫數(shù)據(jù)的命令，最多會被延遲多少時間、是否會經(jīng)常發(fā)生這些延遲等。
關于這個問題我們說明書上有講(CH341DS2.PDF第四節(jié))
呵呵，你大概誤會了我問題的關鍵：
我的問題不是已經(jīng)被“執(zhí)行”了的指令延遲，而是因為上位機的USB傳輸過程，就是說一旦在1mS的同步周期內沒有被響應的指令，是否在下一周期會被在第一時間內響應？在最惡劣的情況下（當然指在同一時刻不會發(fā)生任何其它USB請求的獨占） ，這種延遲可能達到的最長時間。
按理想的說法：就是只有在一個數(shù)值讀寫命令（或者說是貴公司技術人員常用的“函數(shù)”說法）在一個同步周期已經(jīng)結束“工作”后，指令才不會被傳輸?shù)叫酒?zhí)行，然后應該在下一周期優(yōu)先被響應。所以，我的問題實質上就是“一個同步周期不會響應指令的最終時刻，到下一周期及時響應”這樣一段時間，最惡劣的情況有多長……
當然，我上述的說法已經(jīng)是在貴公司可能提供的API中有效的緩存中的數(shù)據(jù)，自己編寫的程序在調用這些“函數(shù)”需要額外占用的、恐怕遠不止內部過程那樣簡單的延遲時間還沒有被統(tǒng)計進去。
沒人理睬了……
是我的問題太幼稚了嗎？
建議樓主不要依賴USB接口做精確的時間控制操作，不保險，USB接口只能用來傳輸數(shù)據(jù)。可以使用單片機控制，并緩沖USB數(shù)據(jù)。實時控制需要建立數(shù)據(jù)緩沖時間，依賴于自己能控制的，不依賴自己不能控制的。
記號
你們提供的API不能對CH341直接進行IO輸出吧？
