手把手教你用位圖映射方式優化灰度液晶控制器驅動

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

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

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

基本的顯示代碼：

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

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

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

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

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

到這里，好象已經優化到頭了，不繞彎。

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

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

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

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

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

上面這段程序實際測試大約平均 20.4 時鐘周期每像素, 是明顯慢多了。

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

還是要嘗試的，下面的代碼看起來過于復雜了。可能還有可優化的地方。

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

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

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

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

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

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

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

歡迎將我們設為“星標”，這樣才能第一時間收到推送消息。

歡迎關注EEWorld旗下訂閱號：“汽車開發圈”

掃碼添加小助手回復“進群”

和電子工程師們面對面交流經驗