1、C51串口的弊端。

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

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

char putchar（char c）{

while（！TI）;

TI = 0;

return（SBUF = c）;

}

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

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

2、刨根問底

為什么C51這么別有用心的設計這樣一個基礎的函數(shù)來實現(xiàn)收發(fā)呢，為什么必須用TI來支持這個判斷，我在寫程序的時候發(fā)現(xiàn)了一點，其實就是51中UART的一點特性。

51 的UART可以理解為一個自動的串行輸出外設，每對SBUF寫一個數(shù)據(jù)就會觸發(fā)UART的一次串行輸出操作，即在定時器分頻的基礎上逐步移初所有數(shù)據(jù)位 （包括啟始為和結束位等等），移出速度是靠定時器溢出時間來來度量的，所以對于MCU來說這個時間一般都比較長。因此如果在定時器還沒有溢出的時候再對 SBUF寫數(shù)據(jù)的話會重新引起這個新數(shù)據(jù)的發(fā)送。這樣如果你寫

while（1）

SBUF = ‘a’;

其實是沒有任何意義的，發(fā)出的肯定是亂碼。

由于以上的原因我們就可以看出TI確實是上次發(fā)送的結束和下次發(fā)送的開始的結點。C51也是利用了這樣一個特性來實現(xiàn)自己的函數(shù)。

3 改進的PUTCHAR函數(shù)

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

這個正好符合隊列的概念，我就設計了一個循環(huán)隊列來實現(xiàn)這個功能。而在

putchar函數(shù)就應該設計成

void putchar（char c）

{

if（UART不忙）

直接發(fā)送數(shù)據(jù)到SBUF

else

把數(shù)據(jù)寫到BUFF里

}

而中斷函數(shù)則應該寫為

ISR（）{

……

if（TI）{

TI = 0；

if（BUFF里面還有數(shù)據(jù)）

取下一個數(shù)據(jù)并發(fā)送；

}

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

前兩個問題先不說，最后一個問題的答案很顯然是“no！”，從最極端的角度來看，上電后UART就是空閑，TI也應該等于0！

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

4、最后的設計概要

從OS的角度來看UART是一種資源，對于我們的程序我們把SBUF看做它的載體，所以對于高速和低速設備的同步問題我們應該引入互斥量來實現(xiàn)對這個資源占用情況的標志。所以我設計的串口驅(qū)動里寫了一個mutex_sbuf來實現(xià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;

取下一個數(shù)據(jù)并送；

}

}

}

寫到這里說的差不多了，沒興致了：（ 以后我把程序貼上來供大家參考

希望大家能把我的程序優(yōu)化一下，我現(xiàn)在的這個版本的driver是用純C寫的，對ROM的占用太大了。以后我會用ASM來改寫部分代碼。

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

過兩天我會放上來希望大家能一起把這個寫好。

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

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

確實是這樣的，根據(jù)項目需要吧，我現(xiàn)在只是想寫一個模塊出來給大家參考：）

代碼量大是因為我用了循環(huán)隊列，對于buff的操作幾乎是透明的，所以幾乎不用考慮，還有一點因為我用的是RD2的芯片，所以有ERAM，我對內(nèi)存的考慮就稍微少了一些。

如果不用中斷的話就要寫一個scheduler來實現(xiàn)，我想以后要寫一個調(diào)度器的實現(xiàn)方式，不過我現(xiàn)在不知道怎么模擬串口收數(shù)據(jù)，好象這個問題比較麻煩，斑竹有沒有什么好的想法？

于這個問題我想還是有必要討論一下的，你可能認為我對buff的校驗不到位，所以產(chǎn)生了越界，但是我想問為什么有了casting以后就可以不越界了呢

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

另外一個需要注意的是為什么總是跑到IDATA里面，這個我也不解：）

我所有的buff都是在XDATA中的，而且我用了MALLOC函數(shù)，但我又用的是compact mode