侃侃單片機裸奔的程序框架
加入技術交流群
從07年參加全國大學生電子設計大賽初次接觸單片機開發至今已經有4年了，初學單片機時，都會糾結于其各個模塊功能的應用，如串口（232，485）對各種功能IC的控制,電機控制PWM，中斷應用，定時器應用，人機界面應用，CAN總線等. 這是一個學習過程中必需的階段，是基本功。很慶幸，在參加電子設計大賽賽前培訓時，MCU周圍的控制都訓練的很扎實。經過這個階段后，后來接觸不同的MCU就會發現，都大同小異，各有各的優勢而已，學任何一種新的MCU都很容易入手包括一些復雜的處理器。而且對MCU的編程控制會提升一個高度概況——就是對各種外圍進行控制(如果是對復雜算法的運算就會
用DSP了），而外圍與MCU的通信方式一般也就幾種時序：IIC,SPI,intel8080,M6800。這樣看來MCU周圍的編程就是一個很簡單的東西了。
任何對時間要求苛刻的需求都是我們的敵人，在必要的時候我們只有增加硬件成本來消滅它；比如你要8個數碼管來顯示，我們在沒有相關的硬件支持的時候必須用MCU以動態掃描的方式來使其工作良好；而動態掃描將或多或少的阻止了MCU處理其他的事情。在MCU負擔很重的場合，我會選擇選用一個類似max8279外圍ic來解決這個困擾；
然而慶幸的是，有著許多不是對時間要求苛刻的事情：
例如鍵盤的掃描，人們敲擊鍵盤的速率是有限的，我們無需實時掃描著鍵盤，甚至可以每隔幾十ms才去掃描一下；然而這個幾十ms的間隔，我們的MCU還可以完成許多的事情；
單片機雖然是裸機奔跑，但是往往現實的需要決定了我們必須跑出操作系統的姿態——多任務程序；
比如一個常用的情況有4個任務：
1
2
3
4
如何來構架這個單片機的程序將是我們的重點；
讀書時代的我會把鍵盤掃描用查詢的方式放在主循環中，而串口接收數據用中斷，在中斷服務函數中組成相應的幀格式后置位相應的標志位，在主函數的循環中進行數據的處理，串口發送數據以及led的顯示也放在主循環中；
這樣整個程序就以標志變量的通信方式，相互配合的在主循環和后臺中斷中執行；
然而必須指出其不妥之處：
每個任務的時間片可能過長，這將導致程序的實時性能差。如果以這樣的方式在多加幾個任務，使得一個循環的時間過長，可能鍵盤掃描將很不靈敏。所以若要建立一個良好的通用編程模型，我們必須想辦法，消去每個任務中費時間的部分以及把每個任務再次分解；下面來細談每個任務的具體措施：
1 鍵盤掃描
鍵盤掃描是單片機的常用函數，以下指出常用的鍵盤掃描程序中，嚴重阻礙系統實時性能的地方；
眾所周知，一個鍵按下之后的波形是這樣的（假定低有效）：
在有鍵按下后，數據線上的信號出現一段時間的抖動，然后為低，然后當按鍵釋放時，信號抖動一段時間后變高。當然，在數據線為低或者為高的過程中，都有可能出現一些很窄的干擾信號。
unsigned char kbscan(void)
{
unsigned char sccode,recode;
P2=0xf8;
if ((P2&0xf8)!=0xf8)
{
}
鍵盤掃描是需要軟件去抖的，這沒有爭議，然而該函數中用軟件延時來去抖（ms級別的延時），這是一個維持系統實時性能的一個大忌諱；
一般還有一個判斷按鍵釋放的代碼：
While( kbscan() != KEY_NONE)
; //死循環等待
這樣很糟糕，如果把鍵盤按下一直不放，這將導致整個系統其它的任務也不能執行，這將是個很嚴重的bug。
有人會這樣進行處理：
While(kbsan() != KEY_NONE )
{
}
即在一定得時間內，如果鍵盤一直按下，將作為有效鍵處理。這樣雖然不導致整個系統其它任務不能運行，但也很大程度上，削弱了系統的實時性能，因為他用了延時函數；
我們用兩種有效的方法來解決此問題：
1 在按鍵功能比較簡單的情況下，我們仍然用上面的kbscan()函數進行掃描，只是把其中去抖用的軟件延時去了，把去抖以及判斷按鍵的釋放用一個函數來處理，它不用軟件延時，而是用定時器的計時（用一般的計時也行）來完成；代碼如下
void ClearKeyFlag(void)
{
}
void ScanKey(void)
{
}
在按鍵情況較復雜的情況，如有長按鍵，組合鍵，連鍵等一些復雜功能的按鍵時候，我們跟傾向于用狀態機來實現鍵盤的掃描；
//avr 單片機 中4*3掃描狀態機實現
char read_keyboard_FUN2()
{
}
評論