最近遇到的單片機(jī)串口設(shè)置問(wèn)題
最近測(cè)試涉及到底層串口代碼的修改。經(jīng)過(guò)這次修改，突然發(fā)現(xiàn)其實(shí)自己對(duì)于串口的一些特性以前并不是十分清楚。
首先遇到的一些問(wèn)題：
1)在使用IO的數(shù)據(jù)位的時(shí)候，沒(méi)有考慮校驗(yàn)位所占的位數(shù)。
2)在設(shè)置串口輸入的時(shí)候，使用懸空輸入。
關(guān)于1)，在一次使用STM32串口參數(shù)9600,N,8,1與另一個(gè) 8051MCU通信的時(shí)候發(fā)現(xiàn)偶校驗(yàn)沒(méi)有問(wèn)題，但是無(wú)校驗(yàn)通信就出現(xiàn)異常。但是，當(dāng)將STM32與電腦通信的時(shí)候，偶校驗(yàn)與無(wú)校驗(yàn)通信又完全都是正確的。8051MCU單獨(dú)與電腦通信也都是完全正確的。查看代碼，還真不知道有什么不對(duì)勁的。因?yàn)檫@段代碼，用了很長(zhǎng)時(shí)間了。后來(lái)一個(gè)同事看代碼后，提醒說(shuō)對(duì)于數(shù)據(jù)位的設(shè)置，偶校驗(yàn)和無(wú)校驗(yàn)是一致的，既然沒(méi)有數(shù)據(jù)位，有可能會(huì)少一位。從這點(diǎn)看，這段代碼可以修改看看。于是在這個(gè)地方，將偶校驗(yàn)的時(shí)候數(shù)據(jù)位長(zhǎng)度設(shè)置為9bit，無(wú)校驗(yàn)的時(shí)候設(shè)置為8bit。重新測(cè)試，發(fā)現(xiàn)通信正常了。
原來(lái)這段代碼，由于一直用偶校驗(yàn)進(jìn)行通信，所以對(duì)于奇校驗(yàn)和無(wú)校驗(yàn)的參數(shù)設(shè)置，沒(méi)有測(cè)試過(guò)。雖然，已經(jīng)存在很長(zhǎng)時(shí)間，但是由于一直沒(méi)有用到奇校驗(yàn)和無(wú)校驗(yàn)，于是這個(gè)BUG。一直潛伏到現(xiàn)在。直到這次使用到才發(fā)現(xiàn)。
關(guān)于2)，是在一次使用中發(fā)現(xiàn)，串口線的連接如果與從機(jī)分離，則串口上會(huì)莫名接收到一些00數(shù)據(jù)。一開始沒(méi)有在意，以為是離開確定電平后，導(dǎo)致的什么干擾造成的。但是，沒(méi)有去考慮是什么造成接收這么容易受干擾。直到有一次，和同事確認(rèn)串口的初始化電平設(shè)置時(shí)，他告訴說(shuō)是懸空設(shè)置。這下子感覺(jué)不對(duì)了，懸空很容易造成受干擾。于是馬上查看串口的初始化代碼，發(fā)現(xiàn)確實(shí)是懸空設(shè)置。馬上修改了。在測(cè)試，將連接的串口懸空，也沒(méi)有再收到。
后來(lái)查看了關(guān)于串口的內(nèi)容發(fā)現(xiàn)以前有些東西沒(méi)有注意到：
串口分為同步串口，異步串口。
這里說(shuō)的串口指通常說(shuō)的UART，異步串行通信接口。
還有就是同步串口，即SPI，I2C之類。
首先，UART不需要接收和發(fā)送兩端嚴(yán)格的時(shí)鐘同步，在不通信的時(shí)候IO電平呈現(xiàn)高電平，即空閑。所以對(duì)于UART來(lái)說(shuō)，如果沒(méi)有數(shù)據(jù)交互，數(shù)據(jù)線是呈現(xiàn)高電平的。
對(duì)于UART的數(shù)據(jù)位問(wèn)題，是包含數(shù)據(jù)+校驗(yàn)的bit數(shù)總和。
為了提高UART的抗干擾性，無(wú)論在哪一種工作模式下，都能夠保證數(shù)據(jù)線上有穩(wěn)定的電平。所以串口設(shè)置時(shí)，對(duì)于串口輸入引腳設(shè)置為上拉輸入。對(duì)于串口的設(shè)置，輸出一般設(shè)置為push-pull，輸入一般設(shè)置為pull up。
(這里有一個(gè)疑問(wèn)，為什么串口還會(huì)留下懸空輸入?既然一般情況下，上拉輸入對(duì)于接收方而言會(huì)處于一個(gè)比較穩(wěn)定的狀態(tài)。如果將輸入設(shè)置為懸空輸入反而會(huì)引入接收不穩(wěn)定的因素，為什么會(huì)有懸空輸入。在什么地方，又會(huì)使用懸空輸入呢?在不同電壓的時(shí)候可能是一種情況，及3.3VTTL電平的CPU，與5.0VTTL的CPU直接使用串口通信的時(shí)候，為了避免電平問(wèn)題采用懸空有可能是一個(gè)種情況。)
這里也提出一個(gè)問(wèn)題，對(duì)于系統(tǒng)的底層代碼要格外嚴(yán)謹(jǐn)。保證開發(fā)出來(lái)的代碼，有高的穩(wěn)定性，可靠性。才能保證其他程序順利開發(fā)。
同時(shí)對(duì)于代碼的測(cè)試要盡可能覆蓋所有代碼。對(duì)于開發(fā)過(guò)程中，引入的功能及代碼要進(jìn)行實(shí)際測(cè)試，明確其執(zhí)行到的時(shí)候?qū)τ诔绦虻挠绊。沒(méi)有運(yùn)行過(guò)的代碼，在程序中就是一座可能噴發(fā)的活火山。所以對(duì)于添加的功能及代碼，要確保執(zhí)行過(guò)。
在開發(fā)過(guò)程中，要時(shí)刻保持警惕，警惕可能出現(xiàn)異常的地方，學(xué)著用推理去找到BUG的巢穴。
編輯：admin 最后修改時(shí)間：2018-05-18
