這兩天在某嵌入式系統(tǒng)做了個串口通訊程序，遇到了每次只接收8個字節(jié)的問題。相信很多人都遇到了。

上網(wǎng)一查資料，找到串口配置結(jié)構(gòu)體struct termios中的c_cc[VTIME] 和?c_cc[VMIN]參數(shù)。

c_cc[VTIME] ? // 等待時間，單位百毫秒?
c_cc[VMIN] ? ? // 最小字節(jié)數(shù)?

VMIN自然就是最少接收的字節(jié)數(shù)了。那不足VMIN的話怎么辦呢？ VTIME就是經(jīng)過這么多個百毫秒后，即使不足VMIN定義的最少字節(jié)數(shù)，也讀出。

當(dāng)VTIME＝0，就是一直等待。當(dāng)然，串口需要設(shè)置成阻塞模式。

好，試一下：

程序中 read(fd, buf, 40); ?// ?偽代碼

c_cc[VTIME] = 1;
c_cc[VMIN] ?= 10;

用串口工具發(fā)送字符串“1234567890123456789”

結(jié)果分為兩次接收

“1234567890123456”

“789”

不是8個字節(jié)了，變成了16個字節(jié)。

看來，最少接收字節(jié)數(shù)會被設(shè)定為大于VMIN參數(shù)的那個8的倍數(shù)。

為了測試接收延時，在程序中加入了毫秒級的時間打印信息，然后測試接收長字符串 “123456789012345678901234567890123456789”。

結(jié)果接收分成了3條。第一第二條之間的時間間隔約25毫秒，可能是我的其他代碼占用了些時間。

第二第三條之間間隔100毫秒。因為第三條不足16個字節(jié)，所以等待到VTIME時間才會被讀到。

另外測試得出：當(dāng)VMIN大于read的第三個參數(shù)時，以read的第三個參數(shù)為準(zhǔn)。

總結(jié)：

1、嵌入式系統(tǒng)的默認(rèn)串口緩沖是8個字節(jié)，可被配成8的倍數(shù)。最大值未驗證。

2、VTIME的單位是“百毫秒”，即最小等待100毫秒。對實時性要求較高的場合太長了。

3、為了保證數(shù)據(jù)接收完整性，串口通訊協(xié)議還是應(yīng)該做的。