1、C51串口的弊端。

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

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

char putchar（char c）{

while（！TI）;

TI = 0;

return（SBUF = c）;

}

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

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

2、刨根問底

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

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

while（1）

SBUF = ‘a’;

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

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

3 改進(jìn)的PUTCHAR函數(shù)

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

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

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ù)）

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

}

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

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

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

4、最后的設(shè)計(jì)概要

從OS的角度來看UART是一種資源，對于我們的程序我們把SBUF看做它的載體，所以對于高速和低速設(shè)備的同步問題我們應(yīng)該引入互斥量來實(shí)現(xiàn)對這個資源占用情況的標(biāo)志。所以我設(shè)計(jì)的串口驅(qū)動里寫了一個mutex_sbuf來實(shí)現(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對于指針的使用很麻煩，程序很容易跑飛，我的代碼還不是足夠的清晰，因?yàn)榫褪侵羔樀膩y跑，所以我在必要的函數(shù)里面加了指針類型限定，但是我發(fā)現(xiàn)如果都加限定的話反而也會飛。

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

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

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

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

代碼量大是因?yàn)槲矣昧搜h(huán)隊(duì)列，對于buff的操作幾乎是透明的，所以幾乎不用考慮，還有一點(diǎn)因?yàn)槲矣玫氖荝D2的芯片，所以有ERAM，我對內(nèi)存的考慮就稍微少了一些。

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

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

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

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

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