先看最終效果

看著很簡(jiǎn)單吧？

但就這么個(gè)簡(jiǎn)單的演示，我踩了無數(shù)的坑。

本來想仔細(xì)說說的，

但是作為一個(gè)有100多年開發(fā)經(jīng)驗(yàn)的程序員，必然是選擇偷懶。

只說幾個(gè)重點(diǎn)的吧：

這個(gè)演示用的是lvgl負(fù)責(zé)繪圖，只需要寫個(gè)“簡(jiǎn)單”的回調(diào)就能支持新設(shè)備，就是這段my_disp_flush。

然后，這段簡(jiǎn)單的代碼花了我好幾周時(shí)間，因?yàn)閯偨佑|設(shè)備開發(fā)，當(dāng)然是從例程開始。

例程能有什么問題呢？最大的問題就是性能！

原始例程里的代碼我試著直接用，結(jié)果發(fā)現(xiàn)不要說每秒30幀，連10幀都無法保證。

仔細(xì)看了各種文檔資料，閱讀了幾遍源代碼，發(fā)現(xiàn)一些“小”問題。

看這段清屏程序，先不說這種用屏幕等大數(shù)組做清屏效率高低，就這句，交換高低字節(jié)？

這看著就有點(diǎn)不正常，研究了屏幕驅(qū)動(dòng)文檔發(fā)現(xiàn)，它本該用16位接口傳輸像素?cái)?shù)據(jù)，但是它用的居然是8位傳輸代碼。

小數(shù)據(jù)量無所謂，清屏這種像素顏色相同，可以提前反轉(zhuǎn)原始顏色的也無所謂，問題是真實(shí)環(huán)境下每像素反轉(zhuǎn)字節(jié)序？

那就效率太低了，這是在處理器本不富裕的情況下雪上加霜啊。

后來閱讀了代碼和顯示驅(qū)動(dòng)的開發(fā)手冊(cè)，發(fā)現(xiàn)這個(gè)問題來自于8位傳輸，顯示驅(qū)動(dòng)的開發(fā)手冊(cè)里明確說明應(yīng)該用16位傳輸?shù)模晕易⑨屃俗止?jié)反轉(zhuǎn)，換用16位傳輸（源代碼沒帶，我自己寫的）測(cè)試，果然一切正常。

然后是演示代碼采用 “繪制” “傳輸” 循環(huán)，而傳輸速度是每秒40兆位，也就是5兆字節(jié)。

而在后續(xù)測(cè)試中，讀取出的實(shí)際速度還要低一點(diǎn)點(diǎn)。

每屏幕的數(shù)據(jù)是112.5K字節(jié)，也就是說在不繪圖的情況下，傳輸滿屏數(shù)據(jù)本身最高也就40多幀。

所以用DMA傳輸是必須的，在DMA傳輸像素?cái)?shù)據(jù)的時(shí)候，繪圖可以繼續(xù)。

我還嘗試了利用雙核來分開處理繪圖和傳輸，但是想了想沒什么必要，可以把另一個(gè)核心留著做點(diǎn)別的事。

至于其他代碼，都是我現(xiàn)在做實(shí)驗(yàn)的，可以無視

另外，作為一個(gè)有100多年開發(fā)經(jīng)驗(yàn)的程序員，注釋就不要想了，必然是沒有（主要是懶）

有問題可以留言，但我未必回答的了，因?yàn)槲沂浅鯇W(xué) 附上代碼，請(qǐng)自取，純純的C代碼，在樹莓派上用vscode編寫調(diào)試， 鏈接: https://pan.baidu.com/s/1BMvz-oaHj_JPW32D0CeOzg?pwd=rffx 提取碼: rffx