手把手教你用位圖映射方式優(yōu)化灰度液晶控制器驅(qū)動

單色液晶控制器通常的寫顯示RAM方式是一次寫8個像素，容易實現(xiàn)MCU主存到控制器的位圖映射。但是支持灰度的液晶控制器不一定有這樣的操作方式，于是只用黑白二色的顯示時，也不得不每個像素都要寫灰階編碼到控制器。但是在MCU主存中每個像素用8-bit甚至16-bit來表示，開銷就大多了，很多時候是不必要的。如果用二值的位圖存放顯示內(nèi)容，在顯示驅(qū)動軟件中轉(zhuǎn)換，就可能實現(xiàn)和單色液晶在圖形庫上的兼容性。

例如ST7529液晶控制器的顯存數(shù)據(jù)是5-bit灰度，采用并行接口(8080模式)驅(qū)動時，有16-bit表示3個像素的辦法和3個8-bit表示3個像素的辦法。這個控制器是給CSTN液晶設(shè)計的，所以總是要RGB 3個像素一起寫，作為FSTN的驅(qū)動顯得有些別扭——列方向的坐標(biāo)只能以3像素為單位。如果能忍受這一點，用8-bit數(shù)據(jù)模式，每次寫顯存操作就是更新一個像素，按列優(yōu)先模式能實現(xiàn)逐條掃描線的數(shù)據(jù)寫入。

現(xiàn)在考慮類似ST7529這種控制器的位圖映射軟件驅(qū)動。在MCU的SRAM中開辟一塊連續(xù)空間作為顯示區(qū)域內(nèi)容的位圖存儲（只顯示兩種顏色，每個像素1 bit），向控制器寫像素數(shù)據(jù)時每次根據(jù)位圖中的一個bit，決定寫控制器的數(shù)據(jù)是兩種顏色代碼中哪一個。如果控制器是用MCU的內(nèi)存控制器（如STM32的FMC）連接的，寫操作就對應(yīng)到一條STR指令；如果不能用FMC，就要用一組GPIO輸出并行數(shù)據(jù)，另一單獨GPIO產(chǎn)生寫脈沖。

基本的顯示代碼：

在寫每個像素數(shù)據(jù)的時候，要進(jìn)行位運(yùn)算測試內(nèi)存中數(shù)據(jù)的某位是1還是0. 按照低地址數(shù)據(jù)在前，每個字中LSB在前的順序訪問整個位圖。取數(shù)據(jù)的時候一次取32 bit的效率要高于8 bit. 內(nèi)層循環(huán)就是逐位處理。在Cortex-m4上，以上代碼的實現(xiàn)效率約為12.2 時鐘周期每像素。

這樣的代碼足夠簡潔了。用位運(yùn)算是因為不能直接尋址SRAM的某一位…… 但是真的不能嗎？Cortex-m3/m4有bit-banding的功能，雖然我以前沒覺得有什么用，SRAM是處于bit-band區(qū)域中的。也就是，在SRAM中存儲了位圖，就有某一段地址是每個32-bit映射到位圖中一個bit的。按連續(xù)地址訪問就可以遍歷位圖中每個像素。于是顯示代碼就只需要一個循環(huán)了：

針對ST7529，如果輸出是全黑和全白兩種顏色，數(shù)據(jù)接口上有效位是全0或者全1，還可以把條件判斷也省去，修改成這樣：

代碼中直接輸出數(shù)據(jù) -p[n] , 因為p[n]為1則寫數(shù)據(jù)就成了 0xFF，是滿足需要的。這樣又能少用指令了。實際測試的執(zhí)行時間減少到 8~9 時鐘周期每像素，有一個浮動可能是CPU流水線的關(guān)系。看一下編譯的結(jié)果：

標(biāo)出的部分就是循環(huán)主體，一共7條指令，顯得沒有任何多余操作，實際執(zhí)行時間變化可能是總線的緣故。

到這里，好象已經(jīng)優(yōu)化到頭了，不繞彎。

回頭看，從原理上呢，根據(jù)每個像素判斷一下要寫什么數(shù)據(jù)是沒錯的，但是如果寫的數(shù)據(jù)和上次一樣其實可以不用更新接口上的并行數(shù)據(jù)，所以可以少一步操作？然而要增加這個條件判斷其實是又繞彎了，因為測試、保存前次結(jié)果和條件分支會消耗更多的周期。實際測試也是平均執(zhí)行時間到了 10.4 時鐘周期每像素。 程序如下：

雖然上面這個嘗試改進(jìn)失敗，減少不必要的操作的思路是有價值的。實際的顯示驅(qū)動就是寫連續(xù)一串（個數(shù)不確定）的前景色像素，再寫連續(xù)一串背景色像素，交替進(jìn)行的。假如SRAM存儲的不是位圖，而是按順序排列的兩種顏色各自連續(xù)的像素個數(shù)的序列，則顯示代碼有可能執(zhí)行更快。

但是現(xiàn)在SRAM存儲的是位圖，只能在此前提下討論。那么，從位圖掃描的角度，統(tǒng)計連續(xù)的1個的個數(shù)，再統(tǒng)計后面連續(xù)的0的個數(shù)，再統(tǒng)計后面連續(xù)1的個數(shù)……如此下去也可以，只不過效率是個問題。不妨對比以下：

這段程序?qū)?1"像素和"0"像素分組輸出，包含了測試統(tǒng)計和連續(xù)寫脈沖的過程，屬于是繞了彎路的做法，最后的執(zhí)行時間大約是 15.5 時鐘周期每像素. 比最基本的方法還要慢，也是可想而知的。

如果不用bit-banding呢，像最基本的方法那樣每次先取一個字，那么程序還會可預(yù)期地多耗費點時間：

上面這段程序?qū)嶋H測試大約平均 20.4 時鐘周期每像素, 是明顯慢多了。

但之所以要這么改寫，是我想嘗試一下能否快速地找出連續(xù)的1或0的個數(shù)——Cortex-m3/m4有CLZ (Count Leading Zeros)指令。在一個32-bit字之內(nèi)，用這條指令直接得到從最高位開始往下有多少個連續(xù)的0. 它能省去一個循環(huán)的位測試。

還是要嘗試的，下面的代碼看起來過于復(fù)雜了。可能還有可優(yōu)化的地方。

調(diào)試查錯過后，上面這段代碼在我用的測試位圖(文本字符為主)上達(dá)到了平均約 8 時鐘周期每像素的效率，追上了前面用bit-band的最快的代碼。不枉這份努力啊。這種方式，執(zhí)行時間與顯示內(nèi)容是關(guān)聯(lián)的，一般圖形界面的話像素顏色連續(xù)出現(xiàn)的時候多，所以應(yīng)該是適用的。

到了這個地步，覺得還有更快的可能嗎？其實使用CLZ指令得以提升效率的原因是減少了循環(huán)次數(shù)，上面這個程序仍然有循環(huán)：除了不可避免的從SRAM中取數(shù)據(jù)之外，連續(xù)產(chǎn)生多少次寫脈沖是用循環(huán)來實現(xiàn)。而后者還有優(yōu)化的可能：

1. 不用GPIO翻轉(zhuǎn)的方式，用硬件自動產(chǎn)生N個脈沖。STM32的TIM1/TIM8等定時器的PWM能做到，或者用一個定時器作為另一個輸出PWM的定時器的門控。我暫時還沒有實驗，好象用的板子GPIO連接缺少條件。

2. 如果用了FMC接口的話可以用借用這個思路，用DMA內(nèi)存到內(nèi)存的方式快速寫。

3. 循環(huán)展開，這要費一些代碼空間了。在上面的程序中，連續(xù)的寫脈沖一般不會太長。比如說，在32個以內(nèi)就完全展開循環(huán)：

用這個 wr_pulses() 函數(shù)代替前一段代碼中的產(chǎn)生WR脈沖的循環(huán)，實現(xiàn)部分的循環(huán)展開，之后…… 執(zhí)行速度提升到了 6 時鐘周期每像素的水平。

當(dāng)然，要求刷屏刷得快簡單地把時鐘頻率提上去就是了，是否要糾結(jié)這種優(yōu)化是MCU玩家自己決定，本文只是假期時候的一點研究分享。關(guān)鍵點：一是bit-band的使用，二是CLZ指令的使用。這兩個特性都得要m3/m4起才有，m0是沒有的（現(xiàn)在國產(chǎn)m4也很便宜了嘛）。

歡迎將我們設(shè)為“星標(biāo)”，這樣才能第一時間收到推送消息。

歡迎關(guān)注EEWorld旗下訂閱號：“汽車開發(fā)圈”

掃碼添加小助手回復(fù)“進(jìn)群”

和電子工程師們面對面交流經(jīng)驗