1、C51串口的弊端。
C51的串口收發(fā)程序相信大家都很熟悉了，在hello.c里面有很簡(jiǎn)單的例程，不知 道大家有沒(méi)有注意到hello.c里面有一句很不顯眼的語(yǔ)句"TI = 1;" 當(dāng)你在初始化串口的時(shí)候如果你不讓TI = 1的話,相信你看到你的數(shù)據(jù)永遠(yuǎn)都發(fā)不出去，debug里運(yùn)行stop會(huì)看到程序?qū)嶋H上是進(jìn)行到了while(!TI);的語(yǔ)句處進(jìn)入死循環(huán)了。

深 入一點(diǎn)的看，可以在keil/c51/lib下發(fā)現(xiàn)putchar函數(shù)的原文件，和許多軟件串口驅(qū)動(dòng)一樣printf()都是反復(fù)調(diào)用putchar() 來(lái)實(shí)現(xiàn)的，所以putchar函數(shù)是我們進(jìn)入死循環(huán)的癥結(jié)。putchar函數(shù)很簡(jiǎn)單，在其中有一個(gè)最小實(shí)現(xiàn)方式，我就以這個(gè)簡(jiǎn)單的例子來(lái)解釋。

char putchar(char c){
while(!TI);
TI = 0;
return(SBUF = c);
}

很 顯然，C51中缺省的putchar函數(shù)是靠查詢并等待TI這個(gè)標(biāo)志位來(lái)實(shí)現(xiàn)串口發(fā)送的，也就是說(shuō)，在putchar函數(shù)中確實(shí)發(fā)送了所有的數(shù)據(jù)，但是每 發(fā)送一個(gè)BYTE前都等待了一段時(shí)間。這就不難理解為什么在初始化串口的時(shí)候必須把TI置位了，無(wú)非是想讓發(fā)第一個(gè)數(shù)據(jù)的時(shí)候讓putchar函數(shù)能順利 執(zhí)行。

注意，這里有一個(gè)問(wèn)題出現(xiàn)了，我們可以把UART理解為一個(gè)獨(dú)立的外設(shè)，在一次數(shù)據(jù)裝訂后就應(yīng)該交給UART自動(dòng)完成數(shù)據(jù)收發(fā)，也 就是說(shuō)寶貴的CPU時(shí)間應(yīng)該不在這里浪費(fèi)掉，所以我們可以做出這樣一個(gè)結(jié)論C51的putchar函數(shù)其實(shí)是有弊端的，它在等待TI置位時(shí)大大占用了 CPU時(shí)間。

2、刨根問(wèn)底
為什么C51這么別有用心的設(shè)計(jì)這樣一個(gè)基礎(chǔ)的函數(shù)來(lái)實(shí)現(xiàn)收發(fā)呢，為什么必須用TI來(lái)支持這個(gè)判斷，我在寫程序的時(shí)候發(fā)現(xiàn)了一點(diǎn)，其實(shí)就是51中UART的一點(diǎn)特性。
51 的UART可以理解為一個(gè)自動(dòng)的串行輸出外設(shè)，每對(duì)SBUF寫一個(gè)數(shù)據(jù)就會(huì)觸發(fā)UART的一次串行輸出操作，即在定時(shí)器分頻的基礎(chǔ)上逐步移初所有數(shù)據(jù)位 （包括啟始為和結(jié)束位等等），移出速度是靠定時(shí)器溢出時(shí)間來(lái)來(lái)度量的，所以對(duì)于MCU來(lái)說(shuō)這個(gè)時(shí)間一般都比較長(zhǎng)。因此如果在定時(shí)器還沒(méi)有溢出的時(shí)候再對(duì) SBUF寫數(shù)據(jù)的話會(huì)重新引起這個(gè)新數(shù)據(jù)的發(fā)送。這樣如果你寫

while(1)
SBUF = 'a';

其實(shí)是沒(méi)有任何意義的，發(fā)出的肯定是亂碼。
由于以上的原因我們就可以看出TI確實(shí)是上次發(fā)送的結(jié)束和下次發(fā)送的開(kāi)始的結(jié)點(diǎn)。C51也是利用了這樣一個(gè)特性來(lái)實(shí)現(xiàn)自己的函數(shù)。

3 改進(jìn)的PUTCHAR函數(shù)
緩 沖區(qū)是連接告訴設(shè)備和低速設(shè)備的接口，我們的串口收發(fā)其實(shí)就是MCU的高速和UART的低速的協(xié)同工作，所以我們應(yīng)該設(shè)計(jì)一個(gè)緩沖區(qū)作為數(shù)據(jù)的暫存位置， 當(dāng)設(shè)備發(fā)送數(shù)據(jù)的時(shí)候如果UART正在忙于發(fā)上一個(gè)數(shù)據(jù)那么就應(yīng)該把數(shù)據(jù)存在BUFF里面，而如果UART不忙了就應(yīng)該把數(shù)據(jù)從BUFF里面順序讀出并發(fā) 送。

這個(gè)正好符合隊(duì)列的概念，我就設(shè)計(jì)了一個(gè)循環(huán)隊(duì)列來(lái)實(shí)現(xiàn)這個(gè)功能。而在
putchar函數(shù)就應(yīng)該設(shè)計(jì)成
void putchar(char c)
{
if(UART不忙)
直接發(fā)送數(shù)據(jù)到SBUF
else
把數(shù)據(jù)寫到BUFF里
}

而中斷函數(shù)則應(yīng)該寫為
ISR(){
……

if(TI){
TI = 0；
if(BUFF里面還有數(shù)據(jù))
取下一個(gè)數(shù)據(jù)并發(fā)送；
}

新的問(wèn)題又出現(xiàn)了，什么是UART忙，他與TI的關(guān)系如何，是不是TI = 0就是UART忙？

前兩個(gè)問(wèn)題先不說(shuō)，最后一個(gè)問(wèn)題的答案很顯然是“no!”，從最極端的角度來(lái)看，上電后UART就是空閑，TI也應(yīng)該等于0!

上面的幾個(gè)問(wèn)題從另一個(gè)角度也可以得到答案，這里有一點(diǎn)點(diǎn)哲理的問(wèn)題，一個(gè)物品一般只能完成一件事情，既然TI已經(jīng)作為上次發(fā)送的結(jié)束和下次發(fā)送的開(kāi)始的結(jié)點(diǎn)那么它應(yīng)該不是作為UART忙的標(biāo)致。

4、最后的設(shè)計(jì)概要
從OS的角度來(lái)看UART是一種資源，對(duì)于我們的程序我們把SBUF看做它的載體，所以對(duì)于高速和低速設(shè)備的同步問(wèn)題我們應(yīng)該引入互斥量來(lái)實(shí)現(xiàn)對(duì)這個(gè)資源占用情況的標(biāo)志。所以我設(shè)計(jì)的串口驅(qū)動(dòng)里寫了一個(gè)mutex_sbuf來(lái)實(shí)現(xiàn)這個(gè)功能。
后面的事情就簡(jiǎn)單了

void putchar(char c)
{
if(mutex_sbuf == 0){
EA = 0
mutex_sbuf = 1;
SBUF = c;
EA = 1
}
else
把數(shù)據(jù)寫到SBUF里面
}

ISR()
{
……

if(TI){
TI = 0；
mutex_sbuf = 0;
if(BUFF里面還有數(shù)據(jù)){
mutex_sbuf = 1;
取下一個(gè)數(shù)據(jù)并送；
}
}
}

寫到這里說(shuō)的差不多了，沒(méi)興致了：（ 以后我把程序貼上來(lái)供大家參考
希望大家能把我的程序優(yōu)化一下，我現(xiàn)在的這個(gè)版本的driver是用純C寫的，對(duì)ROM的占用太大了。以后我會(huì)用ASM來(lái)改寫部分代碼。

而且還有一個(gè)問(wèn)題就是C51對(duì)于指針的使用很麻煩，程序很容易跑飛，我的代碼還不是足夠的清晰，因?yàn)榫褪侵羔樀膩y跑，所以我在必要的函數(shù)里面加了指針類型限定，但是我發(fā)現(xiàn)如果都加限定的話反而也會(huì)飛。

過(guò)兩天我會(huì)放上來(lái)希望大家能一起把這個(gè)寫好。

寫得不錯(cuò)，但我不傾向采用中斷發(fā)送。因?yàn)槿绻?用中斷發(fā)送的話，需要一個(gè)發(fā)送緩沖區(qū)，緩沖區(qū)設(shè)多大？只設(shè)一個(gè)字節(jié)的話，那么調(diào)用putchar的時(shí)候是不是先得判斷緩沖區(qū)非空，如果不空則printf 一類的函數(shù)仍然需要等待。緩沖區(qū)設(shè)很大的話，有兩個(gè)問(wèn)題，一是51本來(lái)內(nèi)存就小，二仍然是需要判斷緩沖區(qū)空不空?？紤]再三，還是用的查詢發(fā)送。到底采用查 詢或中斷發(fā)送，可能要根據(jù)自己的需求來(lái)選擇。

另外，KeilC寫的不見(jiàn)得就比asm寫的占空間大；c指針跑飛的原因，大部分是指針越界，比如申請(qǐng)了5字節(jié)內(nèi)存，使用了第6個(gè)，把別的變量沖掉了等等，不在于你是否加cast，也就是說(shuō)與強(qiáng)制類型轉(zhuǎn)換無(wú)關(guān)，要加強(qiáng)對(duì)查表等索引指針的檢查，確保指針不越界。

確實(shí)是這樣的，根據(jù)項(xiàng)目需要吧，我現(xiàn)在只是想寫一個(gè)模塊出來(lái)給大家參考：）
代碼量大是因?yàn)槲矣昧搜h(huán)隊(duì)列，對(duì)于buff的操作幾乎是透明的，所以幾乎不用考慮，還有一點(diǎn)因?yàn)槲矣玫氖荝D2的芯片，所以有ERAM，我對(duì)內(nèi)存的考慮就稍微少了一些。

如果不用中斷的話就要寫一個(gè)scheduler來(lái)實(shí)現(xiàn)，我想以后要寫一個(gè)調(diào)度器的實(shí)現(xiàn)方式，不過(guò)我現(xiàn)在不知道怎么模擬串口收數(shù)據(jù)，好象這個(gè)問(wèn)題比較麻煩，斑竹有沒(méi)有什么好的想法？
于這個(gè)問(wèn)題我想還是有必要討論一下的，你可能認(rèn)為我對(duì)buff的校驗(yàn)不到位，所以產(chǎn)生了越界，但是我想問(wèn)為什么有了casting以后就可以不越界了呢

我對(duì)C51不是很熟悉，但是我覺(jué)得癥結(jié)可能在于函數(shù)嵌套過(guò)多，雖然結(jié)構(gòu)明晰了，但是堆棧不夠用了。

另外一個(gè)需要注意的是為什么總是跑到IDATA里面，這個(gè)我也不解：）
我所有的buff都是在XDATA中的，而且我用了MALLOC函數(shù)，但我又用的是compact mode