:LED點陣驅(qū)動與狀態(tài)機完整實現(xiàn))
簡介一份基于89C52單片機的貪食蛇游戲機完整設(shè)計面向51單片機入門與進階學(xué)習(xí)者以及需要課程設(shè)計或?qū)嵱?xùn)參考的電子類學(xué)生。方案依托清翔MCS51開發(fā)板包含驅(qū)動代碼、上位機軟件與演示視頻鏈接實現(xiàn)八乘八點陣LED主屏幕、LCD1602液晶狀態(tài)顯示并打通按鍵、紅外遙控、上位機三種操控方式同時利用EEPROM保存最高分記錄。壓縮包約36.95MB平臺未提供明確的文件總數(shù)與類型明細從資源描述看內(nèi)容以C語言工程源碼、上位機程序及相關(guān)說明為主便于對照移植到其他51開發(fā)板。已有1559人學(xué)習(xí)下載適合希望快速上手外設(shè)驅(qū)動、中斷掃描與多模式交互設(shè)計的開發(fā)者可作為完整參考項目直接研讀并二次開發(fā)。視頻中的運行效果可幫助理解整體交互邏輯與顯示刷新方式。1. 一個 rar 里裝的不是游戲是 51 的完整人機交互課設(shè)“51貪食蛇游戲機.rar”這個包名第一眼會讓人覺得里面就是一個貪食蛇游戲拿來編譯燒錄就能玩。實際動手做過的人都知道這個工程的價值遠不止“能玩”——它把 LED 點陣驅(qū)動、定時器中斷、按鍵消抖、狀態(tài)機、串口燒錄這幾條線串成了一個能完整跑起來的人機交互系統(tǒng)。對正在做課程設(shè)計、或者第一次想從“流水燈”往“完整作品”跳的讀者來說這個項目比電子鐘更合適作為過渡載體。它能讓你在幾天之內(nèi)把“硬件接線 → 寫驅(qū)動 → 跑游戲邏輯 → 調(diào)體驗”這條路完整走一遍后面再做任何單片機小系統(tǒng)都會順手得多。2. 硬件怎么搭點陣、按鍵、最小系統(tǒng)的選型與連接2.1 從點陣到屏幕三種顯示方案的取舍貪食蛇的顯示方案基本就三條路8x8 單色點陣、16x16 單色點陣、LCD/OLED 屏。很多人第一反應(yīng)是“用 OLED 多高級”真正做出來才發(fā)現(xiàn)OLED 刷新整屏需要幾十毫秒像素點要反復(fù)翻寫畫像素類游戲非常別扭而且 128x64 的屏做 16x16 的蛇大量面積閑著觀感并不好。LCD1602 同理更適合做菜單和分數(shù)顯示不適合做游戲畫面。方案游戲分辨率引腳占用驅(qū)動難度適合人群8x8 單色點陣8x8蛇最大 64 格約 16 個 IO低直推即可第一次接觸點陣16x16 單色點陣16x16畫面舒服約 8 個 IOHC595 擴展中數(shù)據(jù)串行化課程設(shè)計、正經(jīng)作品LCD1602/OLED不適合作游戲畫面2~4 個 IO中但動畫刷新拉胯只做菜單分數(shù)我的建議很直接如果只是想跑通流程8x8 點陣就夠了P0 送列數(shù)據(jù)、P1 送行選通邏輯最簡單半天能搞定。但如果你想拿這個作品去答辯或者放進作品集直接上 16x16。四個 8x8 點陣拼成 16x16 之后蛇的長度、轉(zhuǎn)彎半徑、視覺反饋都明顯更像一個“游戲機”而不是一個演示板。16x16 需要 32 根驅(qū)動線51 的 IO 口總共才 32 個加上按鍵和蜂鳴器根本不夠分。常見做法是用兩片 74HC595 級聯(lián)把 16 位列數(shù)據(jù)串行發(fā)出去行選通用 P2 口的低四位經(jīng) 74HC154 譯碼器擴展。這樣單片機的 IO 占用被壓縮到2 根時鐘線 1 根數(shù)據(jù)線 4 根行選擇線總共 7 個引腳資源一下子就寬裕了。2.2 按鍵電路獨立按鍵上拉與矩陣擴展貪食蛇需要 4 個方向鍵加 1 個開始/暫停鍵一共 5 個按鍵用獨立按鍵就是最省事的接法。按鍵一端接地另一端接 P1 口的低四位和 P1.4讀取時按鍵按下對應(yīng)引腳讀到低電平。51 的 P1 口內(nèi)部有上拉電阻直接用內(nèi)部上拉就行讀取低四位后按位判斷即可不需要額外的鎖存器。有人會問要不要外接上拉。內(nèi)部上拉阻值通常在幾十千歐級別對數(shù)字信號來說完全夠用。如果現(xiàn)場電磁環(huán)境差、線又長按鍵信號出現(xiàn)抖動導(dǎo)致誤觸發(fā)再在按鍵兩端并一個 0.1μF 電容、或者外接 10kΩ 上拉電阻加強一下。實際踩坑經(jīng)驗是軟件消抖做到位之后外接上拉多數(shù)時候是多余的反而增加焊接量。矩陣鍵盤在這個項目里沒有意義因為按鍵一共才 5 個矩陣是為了在按鍵數(shù)量超過 8 個時省 IO 口用的。硬上矩陣除了讓讀鍵代碼復(fù)雜化沒有任何收益。真正需要矩陣的場景是數(shù)字鍵盤、密碼鎖那一類。貪食蛇用獨立按鍵P1 的低四位正好四個方向代碼里讀一次端口就能拿到全部鍵值簡潔可靠。2.3 最小系統(tǒng)的 3 個必查點晶振、復(fù)位、電源51 的最小系統(tǒng)看著簡單但很多新手焊完板子跑不起來問題幾乎都出在晶振、復(fù)位、電源這三處。晶振我強烈建議直接用 11.0592MHz而不是 12MHz。原因是 12MHz 雖然讓定時器初值更好算但串口波特率會帶誤差燒錄和調(diào)試時經(jīng)常出現(xiàn)“連不上”的玄學(xué)問題。11.0592MHz 分頻出來的 9600、115200 波特率都是整數(shù)分頻USB 轉(zhuǎn) TTL 模塊在這種速率下通信非常穩(wěn)定。如果你的工程代碼里的延時函數(shù)是按 12MHz 校準的那就保持一致別混用否則新做的板子一律 11.0592MHz。復(fù)位電路用經(jīng)典的 10μF 電解電容加 10kΩ 電阻到地。上電瞬間電容充電RST 引腳保持高電平十幾毫秒讓單片機完成復(fù)位。這里有個新手容易翻車的點電解電容極性接反會導(dǎo)致復(fù)位時序不對板子表現(xiàn)為反復(fù)重啟或者干脆不啟動檢查時先看電容方向再查別的。用示波器量 RST 引腳正常上電應(yīng)該是一段高電平然后跌到低電平要是波形不對多半是電容容值或者電阻阻值用錯了。電源是這三項里最容易讓“游戲機”出問題的。16x16 點陣一行同時點亮 16 個 LED按每個 5mA 算就是 80mA 的瞬時電流雖然行掃描是分時點亮但電源瞬時響應(yīng)跟不上就會導(dǎo)致電壓跌落。單片機 VCC 腳必須就近放一個 104 去耦電容點陣的電源線單獨走不要和單片機共用一根細跳線。最靠譜的做法是點陣的電源直接從 USB 的 5V 出來后先過一個大電容再分別給單片機和點陣供電避免點陣拉低電壓把單片機拉復(fù)位。3. 軟件怎么跑貪食蛇狀態(tài)機與 32ms 時間片刷新3.1 游戲邏輯拆成狀態(tài)移動、進食、判定貪食蛇的核心數(shù)據(jù)結(jié)構(gòu)不是鏈表而是一個數(shù)組加兩個索引。51 的內(nèi)存就 128 字節(jié)鏈表節(jié)點需要額外的指針開銷兩三個節(jié)點還好蛇長 30 格之后內(nèi)存直接爆炸。用數(shù)組存蛇身的 x、y 坐標再用 head_idx 標記當前蛇頭在數(shù)組里的下標。移動的時候蛇頭往前走一步蛇尾丟掉一個格子整個蛇身就“跟隨”了。這個做法在數(shù)據(jù)結(jié)構(gòu)里叫環(huán)形隊列思路是單片機貪食蛇最省內(nèi)存的實現(xiàn)。#define SNAKE_MAX_LEN 64 unsigned char snake_x[SNAKE_MAX_LEN]; // 蛇身所有格子的 x 坐標 unsigned char snake_y[SNAKE_MAX_LEN]; // 蛇身所有格子的 y 坐標 unsigned char snake_len; // 當前蛇長 unsigned char head_idx; // 蛇頭在數(shù)組中的下標隊尾 signed char dir; // 0上 1下 2左 3右 // 方向增量表上、下、左、右 const signed char dir_step[4][2] { {0, -1}, {0, 1}, {-1, 0}, {1, 0} };邏輯上每次移動就是“頭往前加一格尾往后減一格”。如果吃到食物尾就不減蛇長度加 1。這里說的“頭往前”是指把新頭坐標寫進數(shù)組里原頭位置的下一個下標然后更新 head_idx 指向它。數(shù)組里的蛇身順序可能是從頭到尾巴連續(xù)排列的也可能是繞了一圈之后首尾相鄰的但因為我們只需要通過索引找到頭和尾順序并不影響邏輯正確性。移動和判定寫在一個函數(shù)里每 100ms 調(diào)用一次這是游戲的主心跳void Game_Update(void) { unsigned char i; unsigned char new_idx; unsigned char new_x, new_y; // 新頭坐標 蛇頭當前坐標 方向增量 new_idx (head_idx 1) % SNAKE_MAX_LEN; new_x snake_x[head_idx] dir_step[dir][0]; new_y snake_y[head_idx] dir_step[dir][1]; // 撞墻判定坐標越界直接結(jié)束 if (new_x 15 || new_y 15) { Game_Over(); return; } // 撞自己判定尾巴這一格馬上要讓出來所以只檢查蛇身長度-1格 for (i 0; i snake_len - 1; i) { if (snake_x[i] new_x snake_y[i] new_y) { Game_Over(); return; } } // 寫入新蛇頭 snake_x[new_idx] new_x; snake_y[new_idx] new_y; head_idx new_idx; // 吃到食物長度加 1尾巴不動否則尾巴丟掉一格 if (new_x food_x new_y food_y) { snake_len; Food_Generate(); } else { // 沒吃到食物時蛇尾那一格在下一次覆蓋前就是廢位置 // 實際邏輯里通過 head_idx 和 snake_len 計算尾下標這里省略 } }這段代碼的邏輯說明new_idx是蛇頭要去的新位置寫成數(shù)組下標后head_idx更新。撞自身檢查時只遍歷snake_len - 1格是因為蛇尾那一格在移動后會被讓出來如果把它也算進去蛇在追自己尾巴時會誤判死亡。這個細節(jié)是很多實現(xiàn)翻車的根源之一細節(jié)定生死。食物的生成必須避開蛇身這是最容易寫錯的點。正確做法是用 do-while 循環(huán)隨機生成坐標后遍歷蛇身數(shù)組檢查沖突有沖突就重新生成void Food_Generate(void) { unsigned char i, x, y, ok; do { x rand() % 16; y rand() % 16; ok 1; for (i 0; i snake_len; i) { if (snake_x[i] x snake_y[i] y) { ok 0; break; } } } while (!ok); food_x x; food_y y; }食物坐標存成全局變量顯示刷新時會用到。rand()的種子建議在按鍵響應(yīng)時隨手取一下當前計數(shù)值做種子能避免每次上電食物位置完全一樣。3.2 16x16 點陣的行掃描刷新代碼16x16 點陣的刷新必須用行掃描每一時刻只點亮一行靠人眼的視覺暫留讓人感覺整屏同時亮。以一幀 16 行為例如果 32ms 掃完一整屏幀率約 31fps動態(tài)畫面基本流暢。行掃描的典型實現(xiàn)是“先送列數(shù)據(jù)再選通當前行”把這一行的 16 個點一次性點亮保持 2ms 左右然后換下一行。關(guān)鍵在于送數(shù)據(jù)和選行的順序不能反否則會出現(xiàn)殘影和花屏。下面是我基于兩片 74HC595 級聯(lián)的串行驅(qū)動代碼。兩片 595 級聯(lián)數(shù)據(jù)先發(fā)高位那片也就是第 0~7 列一個字節(jié)然后發(fā)第 8~15 列一個字節(jié)// HC595_DS 數(shù)據(jù)腳, HC595_SHCP 移位時鐘, HC595_STCP 鎖存時鐘 sbit HC595_DS P2^0; sbit HC595_SHCP P2^1; sbit HC595_STCP P2^2; void HC595_SendData(unsigned int dat) { unsigned char i; for (i 0; i 16; i) { HC595_SHCP 0; HC595_DS (dat 0x8000) ? 1 : 0; // 先發(fā)最高位 HC595_SHCP 1; // 上升沿把數(shù)據(jù)移入 dat 1; } HC595_STCP 0; HC595_STCP 1; // 鎖存并行輸出到點陣列腳 }邏輯說明595 是串入并出移位寄存器16 位數(shù)據(jù)在 16 個時鐘上升沿逐位移入最后用鎖存腳的上升沿一次性輸出。dat 0x8000取出當前最高位數(shù)據(jù)判斷成 1 或 0 送到 DS 腳。兩片級聯(lián)時先發(fā)送的 8 位會停在較遠的那片 595 上剛好對應(yīng)點陣的左半邊。顯示刷新函數(shù)里每一幀從頭掃到尾逐行點亮// screen[row][0] 是第 row 行的左 8 列, screen[row][1] 是右 8 列 unsigned char screen[16][2]; void Disp_Refresh(void) { static unsigned char row 0; unsigned int dat; // 組合成 16 位列數(shù)據(jù)高字節(jié)對應(yīng)左半邊 dat ((unsigned int)screen[row][0] 8) | screen[row][1]; HC595_SendData(dat); // 選行之前先關(guān)閉所有行避免上一行的余暉殘留 ROW_PORT 0xF0; ROW_PORT | row; // P2 低四位輸出當前行號 row; if (row 16) row 0; }邏輯說明screen是顯存數(shù)組游戲邏輯只往數(shù)組里寫點顯示刷新只管把數(shù)組內(nèi)容搬上屏幕。ROW_PORT 0xF0先讓 74HC154 所有輸出無效等列數(shù)據(jù)穩(wěn)定后再把新行號輸出這樣能杜絕行切換瞬間的“鬼影”。這個坑我在第 5 章會展開說——很多人殘影怎么消都消不掉就是少了這一句。3.3 定時器中斷與主循環(huán)的職責劃分時間基準用定時器 0 的 16 位模式1ms 中斷一次。晶振 11.0592MHz、12T 模式下機器周期約 1.085μs1ms 需要 922 個計數(shù)初值就是 65536 - 922 0xFC66void Timer0_Init(void) { TMOD 0x01; // 定時器 016 位不自動重裝 TH0 0xFC; // 1ms 初值高 8 位 TL0 0x66; // 1ms 初值低 8 位 ET0 1; // 開定時器 0 中斷 TR0 1; // 啟動定時器 EA 1; // 開總中斷 }定時器中斷里只做一件事置flag_1ms 1其余全部放到主循環(huán)處理。這是我從這個項目里學(xué)到的最重要原則——中斷里只做最輕量的事。很多人把顯示刷新和游戲邏輯都塞進中斷結(jié)果按鍵一按蛇飛出去好幾格本質(zhì)是中斷占用了過多 CPU 時間主循環(huán)根本沒機會處理按鍵。主循環(huán)的骨架如下void main(void) { unsigned int tick_cnt 0; Timer0_Init(); Game_Init(); while (1) { if (flag_1ms) { flag_1ms 0; tick_cnt; // 每 2ms 刷新一行點陣16 行約 32ms 掃完一幀 if (tick_cnt % 2 0) { Disp_Refresh(); } // 每 10ms 采樣一次按鍵消抖依賴這個間隔 if (tick_cnt % 10 0) { Key_Scan(); } // 每 100ms 蛇走一步也就是游戲速度 if (tick_cnt % 100 0) { Game_Update(); } } } }邏輯說明tick_cnt只加不減時間片通過取余切開。2ms 掃一行對應(yīng)幀率約 31fps基本流暢10ms 采樣一次按鍵配合狀態(tài)機完成消抖100ms 走一步是默認速度想加速改成 80ms 甚至 60ms 就行變量抽出來做成全局調(diào)節(jié)會更方便。所有任務(wù)都在主循環(huán)里做中斷只負責打拍子這保證了系統(tǒng)的實時性和可調(diào)試性。4. 拿到工程包先做四件事打開、改配置、編譯、燒錄4.1 工程里通常有哪些文件各自干嘛你從網(wǎng)上下到的 51 貪食蛇工程包打開 rar 之后大概率會看到這幾類東西Keil 工程文件后綴是 .uvproj 或 .uvprojx、若干個 .c 源文件、對應(yīng)頭文件 .h可能還有原理圖 PDF 或者 Proteus 仿真文件。先別急著點編譯按順序認識一下它們。main.c 是游戲主邏輯所在包含初始化、主循環(huán)、游戲狀態(tài)更新。顯示驅(qū)動的代碼可能單獨放在 disp.c 里按鍵掃描在 key.c 里。這種拆分在老式課設(shè)代碼里不常見很多課設(shè)就是一個 main.c 寫完所有東西但你拿到手之后不要抱怨結(jié)構(gòu)亂——恰恰因為它是單文件你更容易順著從上往下讀一遍把每個函數(shù)的作用搞明白。原理圖文件比源碼更值得先看。PCB 圖也好、仿真圖也好先確認點陣的接線方式和代碼里的引腳定義一致。最常見的問題就是代碼里寫sbit HC595_SHCP P2^1;而你的原理圖把 SHCP 接到了 P2.2這種不一致會讓屏幕怎么點都不亮。我拿到任何板子工程的習(xí)慣是先畫一張引腳對照表原理圖一個引腳代碼一個引腳核對完再編譯。燒錄相關(guān)的文件一般不會在包里需要自己準備 USB 轉(zhuǎn) TTL 模塊和燒錄軟件。這部分我在 4.3 節(jié)詳細說。4.2 編譯前要改的三個地方Keil 打開工程之后不要直接按編譯鍵。先打開 Options for Target檢查三個設(shè)置這三處不對編譯能過、跑起來也是錯的。第一處是芯片型號。很多工程默認按 AT89C51 建的但實際用的是帶 ISP 功能的國產(chǎn) 51 芯片比如 STC89C52。芯片型號選錯一般不影響編譯但影響燒錄——燒錄軟件讀不到芯片 ID或者說“芯片型號不匹配”。在 Target 標簽頁的 Device 欄重新選擇實際芯片型號。第二處是晶振頻率。Options for Target → Target → Xtal(MHz) 這個值是給 Keil 做串口仿真和延時分析用的。工程如果默認 24MHz而你板子上是 11.0592MHz仿真時的時間基準全錯delay 函數(shù)實際延時長了一倍。第三處是 Memory Model。默認 Small 模式就行51 的片內(nèi) RAM 只有 128/256 字節(jié)這個項目的變量也小不需要改 Large。如果代碼量很大導(dǎo)致 data 段溢出編譯時會報DATA SEGMENT TOO LARGE再改成 Large 也不遲。改完之后重新編譯確保 0 Error 0 Warning 再往下走。// 一個常見的坑代碼里沒有包含 reg52.h // 如果 main.c 里直接用了 P0、P1、TMOD 這些寄存器名 // 記得在頭部加上 #include reg52.h邏輯說明reg52.h 是 Keil 自帶的寄存器定義頭文件里面定義了 P0、P1、TMOD、TH0 這些 SFR 的地址。有些工程會自己寫一個頭文件原理一樣。如果編譯報undefined identifier P199% 是頭文件沒包含或者目標芯片選成了非 51 內(nèi)核的型號。4.3 燒錄失敗時先查電平與串口參數(shù)燒錄是新手翻車重災(zāi)區(qū)最常見的現(xiàn)象是燒錄軟件一直顯示“正在檢測單片機...”然后超時。先做排除法。查接線USB 轉(zhuǎn) TTL 模塊的 TXD 接單片機 RXDRXD 接單片機 TXD交叉連接共地。很多人第一次燒錄把 TXD 接 TXD、RXD 接 RXD完全對不上。還要確認模塊是 3.3V/5V 兼容的如果模塊輸出 3.3V 而單片機需要 5V 供電務(wù)必用外部 5V 給板子供電模塊只負責信號。查上電時序STC 系列單片機的下載方式是“冷啟動”。操作順序是先點燒錄軟件的“下載/編程”按鈕再給板子重新上電。很多人習(xí)慣先上電再點下載結(jié)果永遠等不到握手信號。這個流程反直覺但用一次就記住了。查波特率9600 和 115200 是燒錄軟件默認的高兼容性波特率。如果電腦的 USB 轉(zhuǎn) TTL 模塊是舊的主控芯片115200 可能不穩(wěn)定降到 9600 通常能解決。還有一個小技巧燒錄軟件里勾選“每次下載前重新裝入文件”和“編程后執(zhí)行”可以少一些手動步驟。最后查驅(qū)動。USB 轉(zhuǎn) TTL 模塊插上電腦后設(shè)備管理器里要能看到對應(yīng)的 COM 口看不到就裝驅(qū)動。這一步是純環(huán)境問題和工程代碼無關(guān)但很多人卡在這里誤以為是代碼寫錯了。5. 避坑點陣鬼影、按鍵失靈、復(fù)位反復(fù)的排查記錄5.1 現(xiàn)象點陣出現(xiàn)殘影、拖尾整屏像蒙了一層灰點陣在顯示運動畫面時蛇尾巴拖著一串“虛影”或者整屏亮度不均勻有幾行明顯發(fā)暗。這個現(xiàn)象幾乎是 16x16 點陣新手必踩的坑。原因是行切換時上一行的列數(shù)據(jù)還留在 595 的輸出鎖存里而新的行選通已經(jīng)打開了導(dǎo)致上一行的數(shù)據(jù)在新行上閃了一下。人的視覺對這一閃很敏感看起來就成了殘影。解決的辦法就是在選新行之前先關(guān)閉所有行。上文的Disp_Refresh里ROW_PORT 0xF0這一句就是干這個的。先把輸出全部關(guān)掉再更新行號最后新行才亮起來。順序不能變“先送列數(shù)據(jù) → 關(guān)所有行 → 選新行”。另外還要檢查行掃描周期是否太慢如果每行停留超過 5ms整屏 16 行掃完要 80ms幀率只有 12fps那殘影就不不是行切換的問題了而是視覺暫留不夠需要把刷新調(diào)快。5.2 現(xiàn)象按鍵按下去偶爾沒反應(yīng)或者一次跳兩步按鍵問題的表現(xiàn)分兩種一是快速連按時丟失按鍵二是按一下方向鍵蛇走了兩格。這兩種現(xiàn)象對應(yīng)兩個不同的原因。丟失按鍵是因為沒消抖。機械按鍵在按下和釋放的瞬間都有幾毫秒的抖動如果主循環(huán)在抖動期間讀到一次高、一次低就把它當成兩次按鍵邏輯就亂了。一次跳兩步的原因更隱蔽有些實現(xiàn)里把方向修改直接放在了定時器中斷里中斷每次進來都讀按鍵而游戲移動在主循環(huán)里。按鍵按下期間中斷觸發(fā)了多次方向標志被重復(fù)改寫蛇自然就連續(xù)轉(zhuǎn)向。我使用的方案是 10ms 采樣一次 狀態(tài)機消抖。每次采樣到的電平如果和上一次穩(wěn)定值不同就計數(shù)連續(xù)兩次相同才認為電平真正變了。按下瞬間產(chǎn)生一次事件之后按住不動不會重復(fù)觸發(fā)。方向鍵事件在主循環(huán)里只做一次方向更新不直接操作蛇的位置。這樣按一下就是一下永遠不會有跳兩步的問題。5.3 現(xiàn)象上電后反復(fù)復(fù)位跑幾秒就白屏板子剛上電時正常玩不了幾秒就重啟或者 LED 點陣亮度明顯不均勻、單片機像在“呼吸”。這是典型的電源問題。原因有兩類一是 USB 供電線太細太長壓降過大點陣瞬時電流一拉單片機 VCC 跌到復(fù)位閾值以下二是電源濾波電容不足點陣行掃描的電流波動直接耦合到單片機電源腳。解決的辦法先把點陣電源和單片機電源分開走線在板子入口放置一個大容量的電解電容100μF 起步有條件上 470μF再用一個 104 陶瓷電容緊貼單片機 VCC 腳。如果還不行降低整體亮度——把點陣列的限流電阻從 470Ω 換成 1kΩ或者用軟件把點亮的占空比從 1/16 降到 1/20犧牲一點亮度換穩(wěn)定性。另外檢查一下是不是 74HC154 的電源腳忘記加去耦電容這種數(shù)字芯片的電源抖動同樣會影響輸出波形。5.4 現(xiàn)象蛇往右走按一下方向鍵卻直接掉頭撞墻這個現(xiàn)象發(fā)生時你會覺得方向“串”了。蛇頭明明朝右按下鍵蛇卻往上或者往下走了有時候甚至直接反向 180 度回頭撞上自己的身體瞬間死亡。原因有兩個一是消抖狀態(tài)機里沒有處理“兩個按鍵同時按下”或者“按鍵切換瞬間”。如果上一次穩(wěn)定值是“無按鍵”這次讀到“上鍵按下”但讀取時另一路抖動干擾導(dǎo)致鍵值錯誤映射。二是方向更新沒有做禁止反向的判斷。方向鍵允許蛇在朝右時直接改成朝左這是一種非常反直覺但新手常犯的放縱設(shè)計游戲體驗極差。解決方法是雙管齊下。按鍵映射函數(shù)里只接受 0x01、0x02、0x04、0x08 這四個單鍵值其余都按無效處理。方向更新時加一個判斷// new_dir 來自按鍵映射dir 是當前實際移動方向 if (new_dir 0 ((new_dir 2) % 4 ! dir)) { dir new_dir; }邏輯說明方向編號 0上、1下、2左、3右任意兩個相差 2 的方向互為反方向。(new_dir 2) % 4得到的就是 new_dir 的反方向如果它和當前方向相同就說明這次按鍵會導(dǎo)致 180 度掉頭直接丟棄。這樣蛇永遠只能做左轉(zhuǎn)或右轉(zhuǎn)想回頭只能先轉(zhuǎn) 90 度再等下一次按鍵這是貪食蛇的基礎(chǔ)手感。5.5 現(xiàn)象食物生成后看不見或者直接消失食物偶爾刷不出來開局就找不到食物或者玩到一半食物突然“消失”。出現(xiàn)這種情況定位起來最容易但也最容易犯。原因是食物生成時只規(guī)避了蛇頭坐標沒有規(guī)避整條蛇身。如果蛇身很長食物落在蛇身某個身體的格子上顯示層把蛇身畫上去食物就被覆蓋了看起來像消失。還有一種情況是隨機數(shù)只取了坐標范圍但沒檢查這個坐標是否已經(jīng)存在——同樣的位置反復(fù)生成兩次視覺效果更奇怪。解決方式在 3.1 節(jié)的Food_Generate里已經(jīng)寫了do-while 循環(huán)里遍歷snake_x數(shù)組、snake_y數(shù)組只要新坐標和任何一節(jié)蛇身重疊就重新隨機。這里注意邊界條件當蛇長接近 64 格時整個場地幾乎沒有空位這個函數(shù)會變成死循環(huán)。實際游戲里要在蛇長達到一定值后宣布通關(guān)或者提前結(jié)束游戲避免掉進這個死循環(huán)里。6. 從 8x8 到 16x16 再到雙緩沖把顯示刷新這條路走到底6.1 數(shù)據(jù)都映射成二維數(shù)組后換分辨率其實是改一張表如果你已經(jīng)用screen[16][2]這種顯存數(shù)組把游戲邏輯和顯示驅(qū)動分開那換硬件分辨率會比你想象中輕松。游戲邏輯只往screen里寫坐標點顯示驅(qū)動只負責把screen搬上點陣。換成 8x8 時把screen改成screen[8][1]行列數(shù)宏改一下繪制函數(shù)里的邊界判斷同樣跟著宏走其余代碼基本不用動。這里有個值得養(yǎng)成的習(xí)慣不要直接在游戲邏輯里寫硬件引腳操作所有畫面輸出都走SetPixel(x, y, on)這一層抽象。我見過不少工程顯示代碼和游戲邏輯耦合在一起換一次屏就得重寫半個游戲就是因為沒做這層隔離。你的下一個作品可能從點陣換成 LCD、從 LCD 換成 TFT顯存抽象能幫你省掉大把重構(gòu)時間。6.2 終極驗證用一幀空閑時間去斷言每一幀的用時游戲跑起來之后不要只靠眼睛判斷流暢度。用一個最樸素的辦法實測幀時間在Disp_Refresh()函數(shù)開頭翻轉(zhuǎn)一個閑置的 IO 口結(jié)尾再翻轉(zhuǎn)回來用示波器或者邏輯分析儀量這個方波的高電平寬度。如果每行刷新耗時超過 2ms一幀 16 行就會超過 32ms肉眼能感覺到卡頓。另一個更實用的技巧是把游戲邏輯幀率和顯示刷新率分開算賬。顯示刷新靠時間片每 2ms 一次游戲移動靠計數(shù)每 100ms 一次。兩者互不阻塞你可以在調(diào)試時把移動間隔調(diào)到 50ms 看蛇飛跑再調(diào)回 100ms 感受正常速度這時候你會明顯察覺到“游戲卡不卡”和“點陣閃不閃”是兩個獨立問題。能區(qū)分這兩種現(xiàn)象說明你對這套時間片架構(gòu)的理解已經(jīng)到位了。我在這個項目上踩過的最后一個坑是為了追求“畫面更順”把游戲更新也搬進了中斷結(jié)果主循環(huán)沒事可干按鍵響應(yīng)全亂。后來才明白中斷就適合做節(jié)拍發(fā)生器任務(wù)調(diào)度留在主循環(huán)里51 這種資源有限的芯片反而能跑出穩(wěn)定的效果。這個原則后來做其他小系統(tǒng)也一直沒變過。希望幫到你。本文還有配套的精品資源點擊獲取