屏幕剛亮起來(lái)系統(tǒng)就卡死。這是我第一次遇到 OLED 一調(diào)用畫線函數(shù)就整機(jī)假死的情況。一塊 128x64 分辨率的 OLED 顯示模塊接在常見(jiàn)的 Cortex-M 系列 MCU 上I2C 接口底層的畫點(diǎn)函數(shù)單獨(dú)調(diào)沒(méi)有任何問(wèn)題顯示字符數(shù)字也正常但只要調(diào)用了畫線功能肉眼可見(jiàn)的就是程序掛在原地不動(dòng)了。剛開始沒(méi)有人往算法頭上想I2C 時(shí)序不對(duì)、復(fù)位引腳沖突、供電毛刺、中斷嵌套卡死這些才是優(yōu)先懷疑對(duì)象。邏輯分析儀抓了半天波形也沒(méi)看出異常最后接上調(diào)試器單步執(zhí)行才逮住真兇Bresenham 畫線函數(shù)內(nèi)部藏了一個(gè)死循環(huán)。這篇文章把這顆雷完整拆開從現(xiàn)象定位、算法原理、死循環(huán)觸發(fā)條件到最終的修復(fù)代碼和驗(yàn)證方案全部講清楚。適合正在調(diào) OLED 圖形庫(kù)的朋友、寫過(guò)畫線函數(shù)但只測(cè)過(guò)正向直線的同學(xué)以及所有不想再被 while 循環(huán)卡到頭皮發(fā)麻的嵌入式開發(fā)者。1. 問(wèn)題現(xiàn)場(chǎng)一次畫線引發(fā)的整機(jī)“假死”1.1 現(xiàn)象描述與初查路徑故障的現(xiàn)象很規(guī)律程序啟動(dòng)后 OLED 正常初始化顯示開機(jī)頁(yè)、清屏、畫字符都沒(méi)問(wèn)題但只要執(zhí)行到“畫線段”的調(diào)用整機(jī)立刻失去響應(yīng)。因?yàn)楫?dāng)時(shí)測(cè)試程序沒(méi)有開看門狗所以 MCU 不是復(fù)位重啟而是硬生生掛死在某個(gè)地方。外部表現(xiàn)就是屏幕停在那不動(dòng)串口調(diào)試助手沒(méi)有任何新輸出按鍵也都沒(méi)反應(yīng)。初查階段我把懷疑點(diǎn)按概率排序分了幾路。第一路是 I2C 通信擔(dān)心畫線過(guò)程中頻繁寫像素把總線搞掛于是單獨(dú)在畫線循環(huán)里加延時(shí)問(wèn)題依舊存在。第二路是屏幕驅(qū)動(dòng)芯片的顯示 RAM 尋址方式有些屏在連續(xù)寫數(shù)據(jù)時(shí)要先設(shè)置頁(yè)地址和列地址如果越界寫到了不存在的頁(yè)地址驅(qū)動(dòng)芯片可能返回異常 ACK 甚至拖死總線但實(shí)測(cè)單獨(dú)寫像素函數(shù)循環(huán)幾千次都沒(méi)問(wèn)題。第三路才是偶然間想到的——拿調(diào)試器暫停程序看 PC 指針停在哪里結(jié)果發(fā)現(xiàn)主循環(huán)被卡在畫線函數(shù)里一個(gè) while 結(jié)構(gòu)上怎么都繞不出來(lái)。這里想先多說(shuō)一句遇到“一運(yùn)行就死機(jī)”的問(wèn)題不要一上來(lái)就重新焊接、換屏、換電機(jī)而是花五分鐘用調(diào)試器暫停一下看程序到底停在哪個(gè)地址。硬件問(wèn)題會(huì)分散在各種中斷或者外設(shè)初始化流程里軟件死循環(huán)則通常指向某幾個(gè)文件里的特定行號(hào)區(qū)別非常明顯。1.2 三條直觀懷疑怎么被排除的我用一張小表記錄當(dāng)時(shí)的排查過(guò)程很多問(wèn)題排查到最后其實(shí)依賴這種“排除法可復(fù)現(xiàn)”的組合。懷疑方向排查方式結(jié)論I2C 總線異常邏輯分析儀抓取畫線前后的總線波形檢查 ACK/NACK波形正常無(wú)總線鎖死OLED 驅(qū)動(dòng)尋址越界單獨(dú)連續(xù)調(diào)用畫點(diǎn)函數(shù)寫入邊界坐標(biāo)單點(diǎn)寫入正常未觸發(fā)異常系統(tǒng)時(shí)鐘/中斷配置不當(dāng)關(guān)閉所有中斷后單獨(dú)調(diào)用畫線函數(shù)仍然死機(jī)排除中斷因素畫線算法內(nèi)部死循環(huán)調(diào)試器暫停后查看 PC 指針與調(diào)用棧定位到 Bresenham 函數(shù)的 while 循環(huán)排除了前三項(xiàng)之后問(wèn)題范圍已經(jīng)縮得很小要么是畫線算法本身在某種參數(shù)下死循環(huán)要么是算法里疊加了超出屏幕范圍的坐標(biāo)寫入把內(nèi)存寫壞。接下來(lái)要做的事情就是老老實(shí)實(shí)把 Bresenham 算法連同它的邊界條件一起重新讀一遍。2. Bresenham 算法的底牌它為什么快又為什么脆2.1 從直線方程到整數(shù)決策一個(gè)具體推演要在 OLED 上畫一條直線最直接的做法是從起點(diǎn)到終點(diǎn)按 x 方向逐點(diǎn)前進(jìn)每個(gè) x 用直線方程算一個(gè)浮點(diǎn) y。y y1 k * (x - x1)其中 k 是斜率。這個(gè)思路本身沒(méi)錯(cuò)但在沒(méi)有硬件浮點(diǎn)單元的 MCU 上每畫一個(gè)點(diǎn)都要做浮點(diǎn)乘法一幀畫面幾百條線就是幾千次浮點(diǎn)運(yùn)算幀率直接被拖垮。Bresenham 的核心思想是把浮點(diǎn)斜率換成整數(shù)誤差項(xiàng)每次只做加法、減法和比較因此特別適合嵌入式場(chǎng)景。我以一個(gè)具體直線為例從 (1,1) 到 (6,4)。這時(shí)候 dx 5dy 3。經(jīng)典寫法會(huì)維護(hù)一個(gè)決策參數(shù) p初始值 pInit 2 * dy - dx 2 * 3 - 5 1。步數(shù)當(dāng)前坐標(biāo)當(dāng)前 p判斷與動(dòng)作更新后的 p0(1,1)1起點(diǎn)直接畫點(diǎn)11(2,2)p 0x 和 y 都加 1p 2dy - 2dx 1 6 - 10 -32(3,2)-3p 0只 x 加 1p 2dy -3 6 33(4,3)3p 0x 和 y 都加 1p 6 - 10 -14(5,3)-1p 0只 x 加 1p 6 55(6,4)5p 0x 和 y 都加 1p 6 - 10 1最終輸出點(diǎn)序列是 (1,1)、(2,2)、(3,2)、(4,3)、(5,3)、(6,4)和真實(shí)直線吻合。這個(gè)推演過(guò)程看起來(lái)毫無(wú)波瀾但它隱藏了一個(gè)前提dx 和 dy 都是正數(shù)而且曲線的整體走向是第一象限、x 方向?yàn)橹鲗?dǎo)。2.2 一個(gè)“能跑但經(jīng)不起考驗(yàn)”的參考實(shí)現(xiàn)網(wǎng)上有很多簡(jiǎn)化版畫線函數(shù)大多數(shù)長(zhǎng)這樣void Line_Basic(int x1, int y1, int x2, int y2) { int dx x2 - x1; int dy y2 - y1; int p 2 * dy - dx; int x x1; int y y1; while (x x2) { OLED_DrawPixel(x, y, 1); x; if (p 0) { p 2 * dy; } else { p 2 * dy - 2 * dx; y; } } }這個(gè)函數(shù)只在“x2 大于 x1、y2 大于 y1、dx 大于 dy”的條件下正確。也就是說(shuō)它只能畫從左下到右上、且比較平緩的直線。第一象限正斜率的一部分線段湊合能畫其余七個(gè)方向基本全錯(cuò)某些方向直接死循環(huán)。真正通用的畫線函數(shù)必須同時(shí)處理坐標(biāo)的四種符號(hào)組合和斜率大于 1 兩種情況這正好是很多 OLED 圖形庫(kù)移植時(shí)翻車最集中的地方。2.3 脆弱點(diǎn)逐個(gè)點(diǎn)名方向、符號(hào)、主循環(huán)軸對(duì)照上面這段代碼可以找出三個(gè)致命設(shè)計(jì)缺陷。第一沒(méi)有處理 dx、dy 的符號(hào)。當(dāng) x2 x1 時(shí)dx 是負(fù)數(shù)pInit 的計(jì)算結(jié)果就完全偏離了正常范圍。比如從 (100,20) 畫到 (10,80)dx 10 - 100 -90dy 80 - 20 60p 2 * 60 - (-90) 210這個(gè)參數(shù)已經(jīng)失去決策意義。第二循環(huán)體里 x 永遠(yuǎn)做自增。如果終點(diǎn)在 x 的負(fù)方向x 每次加 1 只會(huì)離目標(biāo)越來(lái)越遠(yuǎn)。配合 while (x ! x2) 這種寫法x 從 100 出發(fā)目標(biāo)是 10x 朝著 101、102、103 一路跑下去條件永遠(yuǎn)不成立這就是死循環(huán)的直接來(lái)源。如果循環(huán)條件是 while (x x2)反向時(shí)條件一開始就是假循環(huán)體根本不執(zhí)行屏幕畫不出線倒是不會(huì)死機(jī)。第三主循環(huán)軸固定為 x 軸。當(dāng) dy 大于 dx 時(shí)直線更“陡”每一列 x 對(duì)應(yīng)多行 y。如果仍然以 x 為主循環(huán)軸相鄰兩個(gè)點(diǎn)之間 y 方向會(huì)跳變畫出來(lái)的線會(huì)出現(xiàn)明顯斷點(diǎn)俗稱“虛線感”。正確的做法是讓循環(huán)軸自動(dòng)選擇 dx 和 dy 中較大的一方。還有一個(gè)很多人忽視的隱藏問(wèn)題決策參數(shù) p、dx、dy 的類型選擇。如果用了 unsigned int 或者 uint16_tdx x2 - x1 在反向時(shí)會(huì)發(fā)生無(wú)符號(hào)回繞得到一個(gè)巨大正數(shù)后面所有判斷全部錯(cuò)亂。這個(gè)問(wèn)題單獨(dú)拎出來(lái)說(shuō)因?yàn)樗趩尾秸{(diào)試時(shí)非常迷惑人。3. 死循環(huán)的完整推演從(100,20)到(10,80)3.1 逐行跟蹤循環(huán)變量的變化我用一個(gè)具體調(diào)用把死循環(huán)的過(guò)程完整推演一遍。假設(shè)代碼是while (x ! x2) { OLED_DrawPixel(x, y, 1); x; if (p 0) { p 2 * dy; } else { p 2 * dy - 2 * dx; y; } }入?yún)⑹?x1 100y1 20x2 10y2 80。按錯(cuò)誤實(shí)現(xiàn)計(jì)算dx 10 - 100 -90dy 80 - 20 60pInit 2 * 60 - (-90) 210x 100y 20。進(jìn)入循環(huán)第一次迭代畫點(diǎn) (100,20)然后 x 變成 101。因?yàn)?p 是正數(shù)走 else 分支p 更新為 210 120 - 2 * (-90) 210 120 180 510y 變成 21。第二次迭代畫點(diǎn) (101,21)x 變成 102p 繼續(xù)增大。觀察這個(gè)趨勢(shì)就明白了x 每次加 1而終點(diǎn) x2 是 10兩者之差從 90 變成 91、92、93……永遠(yuǎn)不可能相等。y 倒是朝終點(diǎn)方向走但循環(huán)的退出條件只檢查 x 不檢查 y所以算法根本不知道 y 已經(jīng)到位。程序就這樣在 while 里無(wú)限畫點(diǎn)看似瘋狂工作實(shí)則原地空轉(zhuǎn)。如果換成 while (x x2) 這種條件反向畫線時(shí) x 100 大于 10循環(huán)體一次都不執(zhí)行函數(shù)直接返回。這倒是不會(huì)死機(jī)但調(diào)用方期待看到一條從 (100,20) 到 (10,80) 的線實(shí)際什么都沒(méi)畫出來(lái)。兩種寫法都不對(duì)只是后果不同。3.2 另一種隱蔽炸彈無(wú)符號(hào)整型下溢死循環(huán)還有一種非常隱蔽的觸發(fā)方式和算法結(jié)構(gòu)無(wú)關(guān)純粹是 C 語(yǔ)言類型轉(zhuǎn)換在搗亂。假設(shè)把 dx、dy 聲明成 uint16_t那么執(zhí)行 uint16_t dx x2 - x1 時(shí)如果 x2 - x1 是負(fù)數(shù)結(jié)果會(huì)變成一個(gè)巨大的無(wú)符號(hào)數(shù)。舉例來(lái)說(shuō)x1 10x2 100正常應(yīng)該是正 90。反過(guò)來(lái) x1 100x2 10得到 -90按 uint16_t 存儲(chǔ)就是 65536 - 90 65446。后面的 pInit 2 * dy - dx 會(huì)基于這個(gè) 65446 參與計(jì)算得到的決策參數(shù)同樣是天文數(shù)字。p 的正負(fù)判斷因此完全失去意義循環(huán)內(nèi)部的 x、y 增長(zhǎng)方向和終點(diǎn)完全脫節(jié)。單步調(diào)試時(shí)你會(huì)看到變量值在 60000 上下跳動(dòng)第一反應(yīng)往往以為是數(shù)據(jù)長(zhǎng)度不夠很少意識(shí)到它其實(shí)代表一個(gè)負(fù)數(shù)。這種問(wèn)題在“偶爾死機(jī)、不是必然死機(jī)”的故障里更常見(jiàn)。因?yàn)橹挥挟?dāng)坐標(biāo)差值恰好為負(fù)時(shí)才會(huì)觸發(fā)而測(cè)試者可能只在圖上畫了幾個(gè)固定方向的線段恰好避開了反向場(chǎng)景。等后面加菜單、畫波形、畫任意方向箭頭時(shí)死機(jī)就隨機(jī)冒出來(lái)了。3.3 順帶排查 OLED 畫點(diǎn)坐標(biāo)越界定位到死循環(huán)之后我順手做了一次代碼走查又發(fā)現(xiàn)一個(gè)藏在畫點(diǎn)函數(shù)里的隱患。OLED 顯示模塊的坐標(biāo)范圍有限128x64 意味著 x 是 0 到 127y 是 0 到 63。錯(cuò)誤版的畫線函數(shù)在反向場(chǎng)景下會(huì)把 x 推到 128、129、130 甚至更大直接調(diào)用底層畫點(diǎn)函數(shù)。如果底層畫點(diǎn)函數(shù)沒(méi)有做邊界裁剪這些越界坐標(biāo)會(huì)一路寫進(jìn)顯示 RAM 之外的內(nèi)存區(qū)域。更麻煩的是很多 OLED 驅(qū)動(dòng)庫(kù)會(huì)把顯示緩沖區(qū)定義成數(shù)組數(shù)組越界寫入可能覆蓋相鄰的全局變量包括循環(huán)變量、狀態(tài)標(biāo)志甚至函數(shù)返回地址。一旦循環(huán)變量被污染即使你修復(fù)了畫線算法本身程序也可能在別的地方出現(xiàn)莫名字段錯(cuò)誤或死機(jī)。我的建議是底層畫點(diǎn)函數(shù)永遠(yuǎn)保留邊界判斷最差也要做坐標(biāo)裁剪。這個(gè)習(xí)慣能讓上層圖形函數(shù)在調(diào)試期少背負(fù)一類“幽靈 bug”。就算性能緊張畫點(diǎn)函數(shù)里兩個(gè)比較指令的成本也遠(yuǎn)低于一次意外內(nèi)存覆蓋造成的排查時(shí)間損失。4. 修復(fù)與驗(yàn)證一套能覆蓋全象限的畫線函數(shù)4.1 修復(fù)后的完整代碼正確的 Bresenham 畫線函數(shù)有很多種等價(jià)寫法我推薦下面這個(gè)版本它同時(shí)處理了方向符號(hào)、斜率大于 1、主循環(huán)軸自動(dòng)切換三個(gè)問(wèn)題void OLED_DrawLine(int x1, int y1, int x2, int y2) { int dx (x2 x1) ? (x2 - x1) : (x1 - x2); int dy (y2 y1) ? (y2 - y1) : (y1 - y2); int sx (x2 x1) ? 1 : -1; int sy (y2 y1) ? 1 : -1; int err dx - dy; int e2; while (1) { OLED_DrawPixel(x1, y1, 1); if (x1 x2 y1 y2) { break; } e2 2 * err; if (e2 -dy) { err - dy; x1 sx; } if (e2 dx) { err dx; y1 sy; } } }幾個(gè)關(guān)鍵點(diǎn)說(shuō)明一下。dx 和 dy 都取絕對(duì)值這樣后續(xù)判斷不用關(guān)心坐標(biāo)差值的正負(fù)。sx 和 sy 記錄真實(shí)的前進(jìn)方向取 1 或 -1。err 初始值是 dx - dy它像一根“蹺蹺板”哪個(gè)方向落后就朝哪個(gè)方向補(bǔ)一步。e2 是臨時(shí)變量用來(lái)同時(shí)判斷 x 和 y 兩個(gè)方向是否都需要步進(jìn)。這個(gè)實(shí)現(xiàn)沒(méi)有顯式交換 x、y 軸但算法本身天然支持斜率大于 1 的情況當(dāng) dy 大于 dx 時(shí)err 初始值為負(fù)e2 dx 的條件會(huì)更頻繁成立y 方向自然變成主導(dǎo)方向。這也是它比一開始那個(gè)樸素版全面得多的原因。循環(huán)為什么用 while (1) 配合 break而不是 while (x1 ! x2 || y1 ! y2)因?yàn)槊枯喌?x1 和 y1 可能同時(shí)變化也可能只變化其中一個(gè)用 break 在“當(dāng)前點(diǎn)剛好是終點(diǎn)”時(shí)立即退出邏輯更直觀也不容易出現(xiàn)跨越終點(diǎn)的情況。坐標(biāo)值不超過(guò)屏幕范圍時(shí)最多執(zhí)行與長(zhǎng)軸像素?cái)?shù)相同次數(shù)的迭代性能完全夠用。4.2 六個(gè)方向八組用例的驗(yàn)證矩陣修復(fù)完代碼后我沒(méi)有直接燒錄到屏幕上而是先在 PC 上做了一次軟件模擬。做法很簡(jiǎn)單把 OLED_DrawPixel 替換成一個(gè)向控制臺(tái)打印坐標(biāo)點(diǎn)的函數(shù)然后用一組覆蓋全象限的用例跑一遍。編號(hào)測(cè)試直線覆蓋方向預(yù)期結(jié)果1(0,0) - (127,63)左下到右上dx dy完整連續(xù)直線2(127,63) - (0,0)右上到左下反向完整連續(xù)直線3(0,63) - (127,0)左上到右下反向斜率完整連續(xù)直線4(127,0) - (0,63)右下到左上反向斜率完整連續(xù)直線5(0,30) - (127,30)水平線每個(gè) x 對(duì)應(yīng)唯一 y6(64,0) - (64,63)垂直線每個(gè) y 對(duì)應(yīng)唯一 x7(0,0) - (63,63)45 度對(duì)角線無(wú)斷點(diǎn)、無(wú)重復(fù)點(diǎn)8(10,10) - (120,12)接近水平的小斜率線點(diǎn)和真實(shí)直線偏差不超過(guò) 1第一輪模擬就跑出了兩條輕微變形的斜線原因是模擬程序里畫點(diǎn)坐標(biāo)我用了 x、y 直接打印沒(méi)有做坐標(biāo)換行對(duì)齊以為是算法問(wèn)題調(diào)整打印格式后所有用例全部通過(guò)。這也提醒了我算法驗(yàn)證階段一定要把可視化和算法本身剝離開別把顯示層的問(wèn)題怪到算法頭上。4.3 上板驗(yàn)證時(shí)想加的兩個(gè)安全措施模擬測(cè)試通過(guò)之后我又在板子上補(bǔ)了兩道保險(xiǎn)。第一道是給畫線循環(huán)加一個(gè)看門狗喂狗機(jī)制。如果有意外情況導(dǎo)致函數(shù)長(zhǎng)時(shí)間不返回至少系統(tǒng)能觸發(fā)復(fù)位而不是像第一次那樣徹底假死。第二道是在畫線函數(shù)入口和出口各放一條串口日志記錄入?yún)⒆鴺?biāo)和循環(huán)結(jié)束后的實(shí)際坐標(biāo)。這樣跑自動(dòng)化測(cè)試時(shí)如果某條隨機(jī)線段讓函數(shù)“陷進(jìn)去”日志文件里能看到最后一次正常調(diào)用的坐標(biāo)組合復(fù)現(xiàn)概率會(huì)高很多。我還順手寫了一段隨機(jī)線段測(cè)試代碼每輪隨機(jī)生成 1000 組坐標(biāo)坐標(biāo)范圍限制在 0 到 127、0 到 63 之間依次調(diào)用畫線函數(shù)并在每次調(diào)用后檢查一個(gè)全局計(jì)數(shù)器是否增長(zhǎng)。這個(gè)計(jì)數(shù)器放在主循環(huán)里一旦畫線卡住串口調(diào)試助手會(huì)立刻發(fā)現(xiàn)計(jì)數(shù)不再增加。連續(xù)跑了幾萬(wàn)條隨機(jī)線段沒(méi)有再出現(xiàn)死循環(huán)。5. 把死循環(huán)按死在搖籃里避坑清單與排查手段5.1 嵌入式循環(huán)里最常見(jiàn)的七種死法畫線函數(shù)的死循環(huán)只是眾多死法之一。這些年調(diào)試過(guò)不少“程序跑飛”的問(wèn)題總結(jié)出七種最常見(jiàn)的循環(huán)結(jié)構(gòu)誤用逐一列出來(lái)供排查時(shí)對(duì)號(hào)入座。死法典型代碼特征觸發(fā)條件循環(huán)變量方向與判定條件相反while (x ! x2) 但 x反向遍歷時(shí)無(wú)符號(hào)數(shù)參與減法產(chǎn)生回繞uint16_t dx x2 - x1x2 x1 時(shí)for 循環(huán)體內(nèi)修改循環(huán)變量循環(huán)體內(nèi)調(diào)用函數(shù)間接改 i函數(shù)副作用浮點(diǎn)數(shù)判等while (f ! 0.0f)浮點(diǎn)截?cái)鄬?dǎo)致恒不等中斷與主循環(huán)共享變量無(wú)保護(hù)主循環(huán)等待標(biāo)志位清 0中斷修改標(biāo)志時(shí)機(jī)不確定越界寫壞相鄰循環(huán)變量數(shù)組寫越界覆蓋 while 條件特定輸入數(shù)據(jù)時(shí)優(yōu)化器對(duì)循環(huán)變量過(guò)度優(yōu)化volatile 缺失看似無(wú)限循環(huán)實(shí)際被優(yōu)化掉大多數(shù)情況下只要把循環(huán)條件改成可收斂的等價(jià)形式或者明確變量的符號(hào)屬性問(wèn)題都能直接消除。比如 while (x ! x2) 改成 while (x x2) 或者引入方向符號(hào)之后用 while (x ! x2) 才安全。5.2 定位死循環(huán)的三板斧條件斷點(diǎn)、串口日志、看門狗真遇到死循環(huán)我的排查順序有講究。首選是調(diào)試器的條件斷點(diǎn)在循環(huán)入口處設(shè)置斷點(diǎn)條件寫成 x 200這樣變量接近終點(diǎn)時(shí)斷點(diǎn)才觸發(fā)不用單步幾千次。斷點(diǎn)觸發(fā)后查看 x、y、err 三個(gè)變量的變化趨勢(shì)比盲猜高效太多。如果硬件調(diào)試器不方便就用串口日志。在循環(huán)內(nèi)部每 100 次迭代打印一次當(dāng)前坐標(biāo)和 err 值跑幾秒鐘之后看日志規(guī)律是收斂還是發(fā)散一目了然。等到定位完問(wèn)題再把日志刪掉或者變成條件編譯別影響最終性能。看門狗是我建議常開的調(diào)試伴侶。不是靠它解決問(wèn)題而是靠它把“整機(jī)死機(jī)”變成“反復(fù)復(fù)位”配合復(fù)位原因寄存器可以統(tǒng)計(jì)死機(jī)頻率。有時(shí)候問(wèn)題只在特定路徑出現(xiàn)沒(méi)有看門狗你只能手動(dòng)按復(fù)位鍵次數(shù)多了很容易煩躁有看門狗至少能自動(dòng)跑測(cè)試。5.3 一個(gè)值得養(yǎng)成的習(xí)慣先畫坐標(biāo)紙?jiān)俅a代碼最后分享一個(gè)我后來(lái)一直保持的習(xí)慣。任何圖形算法要寫到 OLED 或 LCD 之前先拿一張方格紙把坐標(biāo)系畫出來(lái)左上角是 (0,0)x 正方向朝右y 正方向朝下。然后把你要支持的八個(gè)方向直線全部標(biāo)一遍再對(duì)照代碼判斷每個(gè)方向下 dx、dy、sx、sy、err 各自是什么值。這一步看起來(lái)花了幾分鐘實(shí)際上能擋掉九成以上的邊界 bug。那次 OLED 畫線死機(jī)事件之后我再也沒(méi)有在圖形函數(shù)的邊界條件上翻過(guò)車。后來(lái)寫菜單圖標(biāo)、畫波形、做簡(jiǎn)易指針表盤都是先把方向、符號(hào)、邊界條件寫在注釋里再開始填代碼。調(diào)試器暫停的那一瞬間我看到程序卡在畫線函數(shù)的 while 循環(huán)里心里其實(shí)松了一口氣。因?yàn)閱?wèn)題找到就好辦最怕的是查了兩天找不到原因?，F(xiàn)在回頭想這個(gè)坑本質(zhì)上不是算法太深?yuàn)W而是寫代碼時(shí)只考慮了最常見(jiàn)的正向場(chǎng)景把所有其他方向都當(dāng)成了“用戶不會(huì)用到”的情況。嵌入式開發(fā)里哪有那么多“不會(huì)用到”屏幕一旋轉(zhuǎn)、UI 一換風(fēng)格、坐標(biāo)一反向隱藏的邊角條件立刻集體出動(dòng)。好在 Bresenham 算法本身并不復(fù)雜理解它如何用誤差項(xiàng)在 x、y 兩個(gè)方向之間做取舍這個(gè)坑就永遠(yuǎn)不再是坑。