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

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

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

VMIN自然就是最少接收的字節(jié)數(shù)了。那不足VMIN的話(huà)怎么辦呢？ VTIME就是經(jīng)過(guò)這么多個(gè)百毫秒后，即使不足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個(gè)字節(jié)了，變成了16個(gè)字節(jié)。

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

為了測(cè)試接收延時(shí)，在程序中加入了毫秒級(jí)的時(shí)間打印信息，然后測(cè)試接收長(zhǎng)字符串 “123456789012345678901234567890123456789”。

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

第二第三條之間間隔100毫秒。因?yàn)榈谌龡l不足16個(gè)字節(jié)，所以等待到VTIME時(shí)間才會(huì)被讀到。

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

總結(jié)：

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

2、VTIME的單位是“百毫秒”，即最小等待100毫秒。對(duì)實(shí)時(shí)性要求較高的場(chǎng)合太長(zhǎng)了。

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