1. 我使用CH375的字節(jié)模式進行寫U盤，如果我循環(huán)寫，每次寫入32字節(jié)，循環(huán)16次，一共是512字節(jié)，正好是一個扇區(qū)，在字節(jié)模式下，CH375ByteWrite庫函數(shù)是不是要對該扇區(qū)擦除16次？ 重寫了16次？（當然會結(jié)合使用DISK_BASE_BUF）

2. 為什么沒有提供類似C語言標準庫的流式文件IO？ 字節(jié)模式容易寫壞U盤（不能加個512字節(jié)的扇區(qū)buffer嗎？），扇區(qū)模式太難用了。

3. 看例子里有查詢U盤插入的兩種方式，有什么區(qū)別？

1）while ( CH375DiskStatus != DISK_CONNECT ) xQueryInterrupt();

2) while ( CH375DiskStatus < DISK_CONNECT ) { if ( CH375DiskConnect( ) == ERR_SUCCESS ) break; }

4.在編寫xWriteCH375Cmd 等外部函數(shù)時，按說明前后延時大于4us就可以，結(jié)果我延時20us，在調(diào)用CH375FileOpen時死掉，改成4us左右才行，為什么？

5.模擬并口方式與375通信，對CPU的速度有要求嗎？我用C8051F410,在1.5M時鐘以下不能工作，在調(diào)用CH375FileOpen時死掉，在3M以上正常 ，為什么？

能不能發(fā)我郵箱一份你的代碼？個人信息保護，已隱藏

是這樣的,如果你操作一個扇區(qū),往一個扇區(qū)里以字節(jié)的形式去寫16次的話,這個扇區(qū)就被寫了16次,底層寫是按扇區(qū)寫的.扇區(qū)先被讀出在寫入. 扇區(qū)和字節(jié)一樣,不知道您所的難用是指在那些地方難用.你可以定義512個字節(jié)的緩沖區(qū),這樣就一次寫1個扇區(qū).是可以更改的. 我們DATASHEET里面所說的延時是說這個時順可以正常操作375,但是由于U盤本身的特性,如果操作延時過長可能會導(dǎo)致掛起睡眠等現(xiàn)象.

樓上，你應(yīng)該用過C語言標準庫函數(shù)數(shù)吧（fread,fwrite），不需要考慮扇區(qū)就可以很好工作，而又不會像字節(jié)模式那樣重復(fù)寫同一個扇區(qū)，windows api用起來也是一樣（ReadFile,WriteFile)，當然PC機有比較大的內(nèi)存也是一個原因，不過我想用兩個512字節(jié)的ram，一個作為扇區(qū)buf,另一個作為文件buf應(yīng)該可以做到C標準庫的功能吧，包括自動更新文件長度。你們的庫函數(shù)（扇區(qū)模式）連文件長度都要自己算用modify來改（EXAM8），Locate竟然也是以扇區(qū)為單位，而且還不包括最后一個扇區(qū)的零碎數(shù)據(jù)，還要修改CH375vFileSize欺騙一下，也太麻煩了吧。

（注，所有問題都在4個不同品牌的U盤和讀卡器下有相同表現(xiàn)）

應(yīng)該不存在睡眠問題，20us不會使U盤進入睡眠模式，現(xiàn)象是死機死在調(diào)用xQueryInterrupt時查詢int#管腳上，此時該管腳電平恒為高電平，所以出現(xiàn)死等，不過之前調(diào)用GetDiskSize是正常通過的，容量也對。到調(diào)用FILEOPEN就死了（EXAM7）。

其它幾個在樓主位的問題還請wch的技術(shù)人員回答一下。問題都是用EXAM7出現(xiàn)的（只修改了延時和必要的sbit）

WCH的技術(shù)支持呢，好幾天了都不回答！

樓主位的 問題3 和問題5 請wch回答一下。

問題3：這2個函數(shù)在本質(zhì)上面沒有任何的區(qū)別，只是下面的一個函數(shù)是做到了庫里面，用來判斷設(shè)備是否插上，而前面一個函數(shù)是在頭文件里面定義的，你可以自己去修改這個函數(shù)。 問題5：這個并不是我們的子程序庫的問題，而是U盤本身的問題，因為當速度過慢的話，在操作的時候可能U盤已經(jīng)掛起了，所以U盤對你發(fā)下去的命令是沒有響應(yīng)的，但是如果速度快的話就不會出現(xiàn)掛起的現(xiàn)象。

謝謝hcn的回答，不過你們的文件庫函數(shù)寫的真是不好用，我正在重新包裝，否則編程太難受了。