1、頭文件：#include (我用的是 STC 89C54RD+)

2、預定義：sbit LED = P1^0// 定義 P1 口的 0 位為 LED

注：“P1^0”這個寫法，與 A51 不同(A51 是 P1.0)，P1 是一組端口，端口號范圍 0~7

注2：sbit 用于定義 SFR(特殊功能寄存器)的位變量，上例中 LED 作為“全局變量”進行定義

注3：以下寫法是錯誤的：

sbit code table[ ] = {P1^0, P1^1, P1^2, P1^3};// 想用 table[i] 指定不同的引腳，但這么做會報錯

sbit table[ ] = {P1^0, P1^1, P1^2, P1^3}; // 考慮到上面可能是 code 關鍵字使用錯誤，使用標準 C 數(shù)組寫法，但這同樣是錯的

3、主函數(shù)寫法：void main (void)

4、數(shù)值的表示：

P1 = 1111 1111// 二進制

P1 = 0xff 或者 P1 = 0xFF // 十六進制，0x 開頭，且數(shù)值不分大小寫

P1 = 255// 十進制

5、定義小數(shù)值時，可以使用 unsigned char i，這樣 i 的范圍為 0~255，作為循環(huán)變量比較好用

6、左右移位：

P1 <<= 2 等價于 P1 = P1 << 2　　// P1 左移 2 位，左移一位相當于乘以 2

P1 >>= 3 等價于 P1 = P1 >> 3// P1 右移 3 位，右移一位相當于除以 2

注：左右移位默認為“邏輯移位”，即無論左移還是右移，空位都補 0

7、按位與或：

P1 = P1 & 0x01

P1 = P1 | 0x01

8、定義 ROM 表格(就是數(shù)據(jù)為常量的數(shù)組)：

unsigned char code table[ ] = {0xff, 0xff, 0xff, 0xff};

使用：P1 = table[i]

注：table[ ] 定義為“全局變量”，上例中 i 的范圍為 0~3

注2：code 定義的常量存于“代碼區(qū)”，即 ROM 區(qū)，可以節(jié)省 RAM 空間

9、在使用數(shù)碼管編程時，假如你正在使用 temp[i] 代表某一個顯示字符，突然想顯示小數(shù)點，可以使用 temp[i] | 0x80，通過“或”運算實現(xiàn)加上小數(shù)點……

10、如果你用 Keil C51 進行編譯，記住一點：它不區(qū)分大小寫!!!臥槽，今天編程序那個調錯啊，就因為一個數(shù)組名和一個變量名完全一樣，只是大小寫不一樣罷了，標準 C 我怎么記得這樣可以啊……上網一查，臥槽，Keil C51 不區(qū)分大小寫，準確的說是“連接的時候不區(qū)分大小寫”，更準確一點就是“具有外部連接的變量區(qū)分大小寫，內部連接 static 區(qū)分大小寫”……至少 Keil uVision2 是這樣，不知道別的版本是不是，待驗證……

11、沒有 unsigned float x !float 型變量從來沒有前邊加 unsigned 的語法!

12、Keil 編譯的程序，main 函數(shù)執(zhí)行完不會停止，會循環(huán)執(zhí)行 main 函數(shù)，何解?

結論 1：如果主程序中沒有 while(1) 這個無限循環(huán)，程序走到最后會再次從頭開始執(zhí)行。

結論 2：如果主程序有 while(1) 這個無限循環(huán)，程序走到最后會一直在這個死循環(huán)中運行，不會出現(xiàn)再從頭執(zhí)行的情況。

這應該屬于 Keil 編譯器的 bug，有網友做過實驗，表示 Keil 編譯后期產生的匯編代碼中，結尾有一條 LJMP main，意思就是跳到 main 函數(shù)重復執(zhí)行……還有一種說法是 PC 指針溢出，溢出后的地址指向開頭，造成繼續(xù)執(zhí)行的效果……(博主覺得還是 Keil 的問題，要是 Keil 編譯器不產生 LJMP main 這種語句，也不會產生循環(huán)效應……)

不管怎么說，在程序結尾加上 while(1) 能夠解決循環(huán)執(zhí)行 main 函數(shù)的 bug……