131 1300 0010
1、C51串口的弊端。
C51的串口收發程序相信大家都很熟悉了，在hello.c里面有很簡單的例程，不知 道大家有沒有注意到hello.c里面有一句很不顯眼的語句“TI = 1;” 當你在初始化串口的時候如果你不讓TI = 1的話，相信你看到你的數據永遠都發不出去，debug里運行stop會看到程序實際上是進行到了while（！TI）;的語句處進入死循環了。
深 入一點的看，可以在keil/c51/lib下發現putchar函數的原文件，和許多軟件串口驅動一樣printf（）都是反復調用putchar（） 來實現的，所以putchar函數是我們進入死循環的癥結。putchar函數很簡單，在其中有一個最小實現方式，我就以這個簡單的例子來解釋。
char putchar（char c）{
while（！TI）;
TI = 0;
return（SBUF = c）;
}
很 顯然，C51中缺省的putchar函數是靠查詢并等待TI這個標志位來實現串口發送的，也就是說，在putchar函數中確實發送了所有的數據，但是每 發送一個BYTE前都等待了一段時間。這就不難理解為什么在初始化串口的時候必須把TI置位了，無非是想讓發第一個數據的時候讓putchar函數能順利 執行。
注意，這里有一個問題出現了，我們可以把UART理解為一個獨立的外設，在一次數據裝訂后就應該交給UART自動完成數據收發，也 就是說寶貴的CPU時間應該不在這里浪費掉，所以我們可以做出這樣一個結論C51的putchar函數其實是有弊端的，它在等待TI置位時大大占用了 CPU時間。
2、刨根問底
為什么C51這么別有用心的設計這樣一個基礎的函數來實現收發呢，為什么必須用TI來支持這個判斷，我在寫程序的時候發現了一點，其實就是51中UART的一點特性。
51 的UART可以理解為一個自動的串行輸出外設，每對SBUF寫一個數據就會觸發UART的一次串行輸出操作，即在定時器分頻的基礎上逐步移初所有數據位 （包括啟始為和結束位等等），移出速度是靠定時器溢出時間來來度量的，所以對于MCU來說這個時間一般都比較長。因此如果在定時器還沒有溢出的時候再對 SBUF寫數據的話會重新引起這個新數據的發送。這樣如果你寫
while（1）
SBUF = ‘a’;
其實是沒有任何意義的，發出的肯定是亂碼。
由于以上的原因我們就可以看出TI確實是上次發送的結束和下次發送的開始的結點。C51也是利用了這樣一個特性來實現自己的函數。
3 改進的PUTCHAR函數
緩 沖區是連接告訴設備和低速設備的接口，我們的串口收發其實就是MCU的高速和UART的低速的協同工作，所以我們應該設計一個緩沖區作為數據的暫存位置， 當設備發送數據的時候如果UART正在忙于發上一個數據那么就應該把數據存在BUFF里面，而如果UART不忙了就應該把數據從BUFF里面順序讀出并發 送。
這個正好符合隊列的概念，我就設計了一個循環隊列來實現這個功能。而在
putchar函數就應該設計成
void putchar（char c）
{
if（UART不忙）
直接發送數據到SBUF
else
把數據寫到BUFF里
}
而中斷函數則應該寫為
ISR（）{
……
if（TI）{
TI = 0；
if（BUFF里面還有數據）
取下一個數據并發送；
}
新的問題又出現了，什么是UART忙，他與TI的關系如何，是不是TI = 0就是UART忙？
前兩個問題先不說，最后一個問題的答案很顯然是“no！”，從最極端的角度來看，上電后UART就是空閑，TI也應該等于0！
上面的幾個問題從另一個角度也可以得到答案，這里有一點點哲理的問題，一個物品一般只能完成一件事情，既然TI已經作為上次發送的結束和下次發送的開始的結點那么它應該不是作為UART忙的標致。
4、最后的設計概要
從OS的角度來看UART是一種資源，對于我們的程序我們把SBUF看做它的載體，所以對于高速和低速設備的同步問題我們應該引入互斥量來實現對這個資源占用情況的標志。所以我設計的串口驅動里寫了一個mutex_sbuf來實現這個功能。
后面的事情就簡單了
void putchar（char c）
{
if（mutex_sbuf == 0）{
EA = 0
mutex_sbuf = 1;
SBUF = c;
EA = 1
}
else
把數據寫到SBUF里面
}
ISR（）
{
……
if（TI）{
TI = 0；
mutex_sbuf = 0;
if（BUFF里面還有數據）{
mutex_sbuf = 1;
取下一個數據并送；
}
}
}
寫到這里說的差不多了，沒興致了：（ 以后我把程序貼上來供大家參考
希望大家能把我的程序優化一下，我現在的這個版本的driver是用純C寫的，對ROM的占用太大了。以后我會用ASM來改寫部分代碼。
而且還有一個問題就是C51對于指針的使用很麻煩，程序很容易跑飛，我的代碼還不是足夠的清晰，因為就是指針的亂跑，所以我在必要的函數里面加了指針類型限定，但是我發現如果都加限定的話反而也會飛。
過兩天我會放上來希望大家能一起把這個寫好。
寫得不錯，但我不傾向采用中斷發送。因為如果采 用中斷發送的話，需要一個發送緩沖區，緩沖區設多大？只設一個字節的話，那么調用putchar的時候是不是先得判斷緩沖區非空，如果不空則printf 一類的函數仍然需要等待。緩沖區設很大的話，有兩個問題，一是51本來內存就小，二仍然是需要判斷緩沖區空不空?？紤]再三，還是用的查詢發送。到底采用查 詢或中斷發送，可能要根據自己的需求來選擇。
另外，KeilC寫的不見得就比asm寫的占空間大；c指針跑飛的原因，大部分是指針越界，比如申請了5字節內存，使用了第6個，把別的變量沖掉了等等，不在于你是否加cast，也就是說與強制類型轉換無關，要加強對查表等索引指針的檢查，確保指針不越界。
確實是這樣的，根據項目需要吧，我現在只是想寫一個模塊出來給大家參考：）
代碼量大是因為我用了循環隊列，對于buff的操作幾乎是透明的，所以幾乎不用考慮，還有一點因為我用的是RD2的芯片，所以有ERAM，我對內存的考慮就稍微少了一些。
如果不用中斷的話就要寫一個scheduler來實現，我想以后要寫一個調度器的實現方式，不過我現在不知道怎么模擬串口收數據，好象這個問題比較麻煩，斑竹有沒有什么好的想法？
于這個問題我想還是有必要討論一下的，你可能認為我對buff的校驗不到位，所以產生了越界，但是我想問為什么有了casting以后就可以不越界了呢
我對C51不是很熟悉，但是我覺得癥結可能在于函數嵌套過多，雖然結構明晰了，但是堆棧不夠用了。
另外一個需要注意的是為什么總是跑到IDATA里面，這個我也不解：）
我所有的buff都是在XDATA中的，而且我用了MALLOC函數，但我又用的是compact mode
