1樓
wangxinxin 發(fā)表于：2010-12-7 13:58:03
案例：
一文本框中有4個(gè)字節(jié)數(shù)據(jù)，點(diǎn)command后mscomm控件將這4個(gè)字節(jié)發(fā)送給了AT89S52，MCU接到數(shù)據(jù)，我的下位機(jī)程序利用中斷處理了這4個(gè)字節(jié)數(shù)據(jù)（我一直在說字節(jié)哦）。
疑問：
單片機(jī)每次只能接收一個(gè)字節(jié)數(shù)據(jù)（SBUF只能裝一個(gè)，否則會(huì)被后來的數(shù)覆蓋），雖然MSCOMM是一次發(fā)了4個(gè)，但單片機(jī)收到一個(gè)字節(jié)后就應(yīng)該中斷（是收一個(gè)而不是4個(gè)都收到后才中斷置位RI吧？），等我的程序把數(shù)據(jù)從SBUF后取走并清0RI后，它再接收下一個(gè)字節(jié)(是因?yàn)槭盏絊BUF中數(shù)被移走的信號(hào)還是收到RI為0的信號(hào)？)直到4個(gè)都收到。但在MCU端中斷時(shí)MSCOMM仍在發(fā)數(shù)據(jù)，這部分?jǐn)?shù)豈不是會(huì)漏掉？另外我說的通信流程對(duì)嗎？
|
這種情況通常不會(huì)出現(xiàn)，因?yàn)椋?br/>
1、單片機(jī)每“次”的確只能接收1個(gè)字節(jié)，但由于串口的速度實(shí)在太低，通常都在115200bps以下（即使用了同步方式也“只能”達(dá)到1Mbps）。注意，是bps，位/秒，而不是“字節(jié)/秒”，這就是“串”行通信，要至少8個(gè)“bps時(shí)間”才能接收一個(gè)完整的字符，事實(shí)上，加上起始位等，8個(gè)位往往傳送不了一個(gè)字節(jié)（不知道我的理解是不是有偏差），這就是說，速度至少還要再慢上8倍。
2、帶有USART的單片機(jī)里USART一般都是做為“外部設(shè)備”，獨(dú)立于MCU進(jìn)行收發(fā)工作，即其收發(fā)過程中的串-并和并-串轉(zhuǎn)換以及數(shù)據(jù)IO過程都是“自主”和“自動(dòng)”的，不需要CPU逐位進(jìn)行收發(fā)處理，因此，在CPU將數(shù)據(jù)送到SBUF后，便可以放手不管了，USART收發(fā)器會(huì)自動(dòng)將SBUF的內(nèi)容轉(zhuǎn)換成串行數(shù)據(jù)發(fā)送出去。接收時(shí)也是由USART將串行數(shù)據(jù)轉(zhuǎn)成并行數(shù)據(jù)并存放到SBUF后才會(huì)通知MCU（產(chǎn)生接收中斷）。MCU所需要做的只是往SBUF送數(shù)或從SBUF中取數(shù)（都只要1個(gè)指令周期）。
3、設(shè)置串口參數(shù)的時(shí)候應(yīng)該能看出，為了適應(yīng)串口的慢，不得不動(dòng)用定時(shí)器進(jìn)行延時(shí)，以“產(chǎn)生”所需要的波特率，而這個(gè)“延時(shí)”通常都要給8位甚至16位定時(shí)器設(shè)置初值，定時(shí)器每一次計(jì)數(shù)都需要一個(gè)指令周期，即CPU可以執(zhí)行一條指令的時(shí)間，而定時(shí)器兩次串口溢出才僅僅接收或發(fā)送一個(gè)“位”，接收一個(gè)字節(jié)需要數(shù)倍于此的時(shí)間，那么這么長的時(shí)間對(duì)CPU來說，足以從容地從SBUF里取出數(shù)據(jù)并對(duì)其進(jìn)行處理了。
4、即使CPU的任務(wù)相當(dāng)繁重，或?qū)邮盏降拿總�(gè)字節(jié)都需要進(jìn)行相當(dāng)復(fù)雜的處理，我們也完全可以通過建立接收緩沖區(qū)的方式將暫時(shí)來不及處理的數(shù)據(jù)暫存起來，等CPU空閑時(shí)再做處理。而從SBUF取出數(shù)據(jù)并保存到緩沖區(qū)只需要很少的幾條指令就能完成，不會(huì)影響到串口繼續(xù)接收。
5、標(biāo)準(zhǔn)的RS-232協(xié)議并非只有TX、RX和GND三個(gè)引腳，即便是最簡單的9針插口，也專門設(shè)計(jì)了檢測傳輸狀態(tài)和收發(fā)請(qǐng)求的針腳。如果單片機(jī)真的實(shí)在無法及時(shí)完成收發(fā)動(dòng)作，也完全可以利用一個(gè)口線作為狀態(tài)標(biāo)識(shí)，使PC能夠知道單片機(jī)什么時(shí)候可以接收數(shù)據(jù)，而不會(huì)任由數(shù)據(jù)丟失。
6、為了增加數(shù)據(jù)傳輸?shù)目煽啃�，大量�?shù)據(jù)傳輸時(shí)通常都會(huì)采用CRC校驗(yàn)方式，并以“包”或“幀”的方式發(fā)送有格式約定的字節(jié)流，而非單個(gè)字符，這樣一來，完全可以通過約定一些“通信協(xié)議”的方式，使收發(fā)雙方都能夠及時(shí)知道接收的數(shù)據(jù)是否完整，并及時(shí)重發(fā)新發(fā)送出錯(cuò)的數(shù)據(jù)。
現(xiàn)在所能想到的暫時(shí)就這么多，思路較亂，文字表述也挺羅索，謹(jǐn)供參考，歡迎交流。