fbcp ili9341
1.0.0
FBCP-ILI9341時代已經結束。 FBCP-ILI9341建於Raspberry Pi的視頻Despmanx API之上。
但是，Raspberry Pi基金會已將此API棄用了一段時間，最後在Raspberry Pi 5及以後過時了（=不可用）。
後來的Raspberry Pi發行版甚至對於PI0-PI4默認情況下也不再具有dispManx活動性，而是Raspberry Pi已移至較新的KMS驅動程序Compositor堆棧，該堆棧具有不同的抽象來集成SPI顯示器驅動程序。其他人正在為與KMS堆棧兼容的PI開發SPI顯示驅動程序。前往此Raspberry Pi論壇線程以了解更多信息。
該存儲庫很高興被認為是存檔/陳舊的，儘管我沒有使用GitHub功能進行存檔，因為該功能顯然也將使問題跟踪器僅閱讀。隨時繼續討論跟踪器上的問題。
該存儲庫實現了針對Raspberry Pi A，B，2、3、4和零的某些基於SPI的LCD顯示的驅動程序。
這項工作是出於好奇心的動機，在Retomancave YouTube頻道上看到了這一系列視頻：
在這些視頻中，SPI（GPIO）巴士被稱為瓶頸。基於SPI的顯示器對串行數據總線的更新進行更新，並在總線上每一個時鐘週期傳輸一個位。因此，320x240x16bpp顯示屏需要SPI總線時鐘速率為73.728MHz，以實現完整的60fps刷新頻率。在實踐中，很少有SPI LCD控制器可以快速通信，但是被限制為16-50MHz SPI總線時鐘速度，限制了最大更新速率。我們可以對此做任何事情嗎？
FBCP-ILI9341項目最初是Adafruit 2.8“ 320x240 TFT w/ touch屏幕的顯示驅動程序，用於Raspberry Pi顯示器，用於使用ILI9341控制器。在該顯示器上，FBCP-ILI9341可以實現60fps的更新速率，具體取決於60fps的更新速率正在顯示這些視頻，以獲取驅動程序的示例：
鑑於SPI總線可能會受到帶寬的限制，因此FBCP-ILI9341如何以60fps的速度更新？實現這一目標的方法是可以稱為自適應顯示流更新。與其在每個顯示器刷新周期上上傳每個像素，不如將屏幕上實際更改的像素提交到顯示屏上。這是可行的，因為與許多其他受歡迎的控制器一樣，ILI9341控制器具有通信接口功能，允許指定部分屏幕更新，直至子級別，甚至單個像素級別。這允許擊敗帶寬限制：例如，儘管它是一個快速節奏遊戲，但平均只有大約46％的屏幕上像素上的46％更改每個渲染框架。某些零件，例如UI幾乎在多個幀中保持不變。
其他優化也被用來擠出更多的性能：
#define NO_INTERLACING在文件config.h中來禁用此功能很容易禁用此功能）結果是，SPI總線可以保持接近100％的飽和度，即通常的〜94-97％，以最大化總線的利用率，而僅傳輸幾乎可以描述每個新框架所需的最小字節數。
已檢查駕駛員在以下系統上工作（至少過去的某個時刻）：
儘管並非所有董事會都經過積極測試，因此尤其是在較舊的板上的YMMV。 （歡迎使用錯誤修復，使用https://elinux.org/rpi_hardwarehistory確定您正在運行的板）
測試了以下LCD顯示：
檢查以下各節以設置驅動程序。
該驅動程序不會使用Notro/FBTFT FrameBuffer驅動程序，因此如果活動活動，則需要禁用。也就是說，如果您的/boot/config.txt文件的行看起來像dtoverlay=pitft28r, ... ， dtoverlay=waveshare32b, ...或dtoverlay=flexfb, ... ，應將其刪除。
該程序均未使用默認的SPI驅動程序，因此也應刪除諸如dtparam=spi=on之類的線路= on /boot/config.txt以免引起衝突。
同樣，如果您與觸摸控制器相關的DToverlays活動，例如dtoverlay=ads7846,...或任何具有penirq=指令的內容，則應將其刪除以避免衝突。如果某人想對此進行刺傷，則有可能向FBCP-ILI9341增加觸摸支持。
在覆盆子Pi的控制台中運行：
sudo apt-get install cmake
cd ~
git clone https://github.com/juj/fbcp-ili9341.git
cd fbcp-ili9341
mkdir build
cd build
cmake [options] ..
make -j
sudo ./fbcp-ili9341特別注意兩個點..在Cmake Line上，在這種情況下，該點表示“一個目錄”（而不是指“更多的項目”）。
請參閱下一部分，以查看[選項]下輸入的內容。
如果您一直在運行現有的fbcp驅動程序，請確保首先通過sudo pkill fbcp刪除該驅動程序（在SSH提示下運行或連接到HDMI顯示屏），這兩個無法同時運行。如果/etc/rc.local or /etc/init.d包含啟動fbcp條目，則應刪除該指令。
通常有兩種方法可以配置構建選項，在CMAKE命令行和文件Config.h中。
在CMAKE命令行上，可以配置以下選項：
當使用FBCP-ILI9341已經識別的PI頂部的顯示器之一時，您無需指定GPIO PIN分配，但是FBCP-ILI9341代碼已經具有這些。通過以下帽子的CMAKE指令之一：
-DADAFRUIT_ILI9341_PITFT=ON ：如果您在Adafruit 2.8“ 320x240 tft w/ touch屏幕上奔跑）raspberry pi（或Adafruit Pitft 2.2” HAT MINI KIT -320x240 2.2旗幟。-DADAFRUIT_HX8357D_PITFT=ON ：如果您有Adafruit Pitft-組裝480x320 3.5“ TFT+觸摸屏，用於Raspberry Pi顯示屏，請添加此行。-DFREEPLAYTECH_WAVESHARE32B=ON ：如果您在自由層CM3或零設備上運行，請傳遞此標誌。 （這不是帽子，但仍然是預配置的銷售分配）-DWAVESHARE35B_ILI9486=ON ：如果指定，則針對WaveShare 3.5“ 480x320 ILI9486顯示屏。-DTONTEC_MZ61581=ON ：如果您在tontec 3.5“ 320x480 lcd顯示屏上運行，請傳遞此信息。-DPIRATE_AUDIO_ST7789_HAT=ON ：如果指定，則針對海盜音頻240x240，1.3英寸IPS LCD lcd display Hat for Raspberry pi for ST7789顯示器顯示器-DWAVESHARE_ST7789VW_HAT=ON ：如果指定，則針對240x240，1.3英寸IPS LCD顯示帽，用於Raspberry Pi，帶有ST7789VW顯示器控制器。-DWAVESHARE_ST7735S_HAT=ON ：如果指定，則針對128x128、1.44inch lcd顯示帽子，用於帶有ST7735S顯示器控制器的Raspberry Pi。-DKEDEI_V63_MPI3501=ON ：如果指定，則針對kedei 3.5英寸SPI TFTLCD 480*320 16bit/18bit版本6.3 2018/4/9顯示帶有MPI3501顯示器控制器。 如果您直接在PI上連接了電線，而不是從上面列表中使用帽子，則需要使用以下配置指令。除了指定顯示外，您還需要告訴FBCP-ILI9341您將連接連接到哪個GPIO引腳。要配置顯示控制器，請傳遞：
-DILI9341=ON ：如果您在任何其他通用ILI9341顯示器上運行，或者在WaveShare32b顯示屏上顯示為獨立的，而不是在Freeplaytech CM3/Zero設備上，請傳遞此標誌。-DILI9340=ON ：如果您有ILI9340顯示屏，請通過此指令。 ILI9340和ILI9341芯片組非常相似，但是ILI9340不支持ILI9341上的所有功能，它們將被禁用或降級。-DHX8357D=ON ：如果您有HX8357D顯示屏，請通過此指令。-DSSD1351=ON ：如果您有SSD1351 OLED顯示屏，請使用此。-DST7735R=ON ：如果您有ST7735R顯示屏，請使用此。-DST7789=ON ：如果您有ST7789顯示器，請使用此。-DST7789VW=ON ：如果您有ST7789VW顯示，請使用此。-DST7735S=ON ：如果顯示ST7735S，請使用此。-DILI9486=ON ：如果您有ILI9486顯示屏，請通過此指令。-DILI9486L=ON ：如果您有ILI9486L顯示屏，請通過此指令。請注意，ILI9486和ILI9486L截然不同，相互不兼容的控制器芯片，因此請在此處小心確定您擁有哪一個。 （或只是嘗試兩者，如果您誤認了）-DILI9488=ON ：如果您有ILI9488顯示屏，請通過此指令。-DMPI3501=ON ：如果指定了MPI3501顯示器控制器的顯示。此外，將以下內容傳遞以自定義您使用的GPIO PIN分配：
-DGPIO_TFT_DATA_CONTROL=number ：指定/覆蓋4-Wire SPI通信上的GPIO PIN用於數據/控制（DC）線。該引腳編號在BCM PIN號中指定。如果您的3線SPI顯示器沒有數據/控制線，請將此值設置為-1 ，即-DGPIO_TFT_DATA_CONTROL=-1告訴FBCP-ili9341溝通。-DGPIO_TFT_RESET_PIN=number ：指定/覆蓋gpio pin用於顯示重置行。該引腳編號在BCM PIN號中指定。如果省略，則假定顯示屏沒有重置銷，並且始終為ON。-DGPIO_TFT_BACKLIGHT=number ：指定/覆蓋GPIO PIN用於顯示背光行。該引腳編號在BCM PIN號中指定。如果省略，則假定顯示器沒有GPIO控制的背光引腳，並且始終處於打開狀態。如果設置此設置，請參見config.h中的#define BACKLIGHT_CONTROL選項。FBCP-ILI9341始終使用硬件SPI0端口，因此MISO，MOSI，CLK和CE0引腳始終相同，無法更改。實際上，味o銷至少目前尚未使用，因此您可以跳過連接該的。如果您的顯示器是一個忽略芯片啟用行的盜賊，您也可以忽略連接它，或者如果用力將其連接到地面以簡化佈線（取決於顯示），也可以通過將其連接到地面來擺脫。
為了從顯示屏中獲得良好的性能，您將使顯示屏超過額定速度規格（額定規格的產量約為10fps，具體取決於顯示）。因此，您需要明確配置要驅動顯示屏的目標速度，因為由於製造差異，每個顯示副本都達到了不同的最大速度。 FBCP-ILI9341不會使用“默認速度”。設置速度是通過選項完成的
-DSPI_BUS_CLOCK_DIVISOR=even_number ：設置時鐘除數數號，該號碼與pi core_freq = ins.un /boot/config.txt中的選項一起指定顯示SPI通信總線的總體速度。 SPI_frequency = core_freq/divisor 。 SPI_BUS_CLOCK_DIVISOR必須是偶數號碼。默認的pi 3b和Zero w core_freq為400MHz，通常值-DSPI_BUS_CLOCK_DIVISOR=6似乎是ILI9341顯示器可以做到的最好的。如果顯示器顯示損壞的輸出或較小的值以獲得更高的帶寬，請嘗試更大的值。有關調整最大SPI性能的數據點，請參見ILI9341.H和Waveshare35b.h。安全初始值可能是-DSPI_BUS_CLOCK_DIVISOR=30 。 有幾個選擇可以明確說明您要針對哪個PI板。這些應該為您自動進行自動進行，通常不需要，例如，如果您從另一個系統中為另一個PI板進行了交叉編譯，或者想明確，您可以嘗試：
-DSINGLE_CORE_BOARD=ON ：如果您在只有一個硬件線程的PI上運行（PI Model A，Pi Model B，Compute Module 1，Pi Zero/Zero/Zero W），則傳遞此選項。如果不存在，請自動進行。-DARMV6Z=ON ：將此選項傳遞給ARMV6Z指令集（PI 1A，1A+，1B，1B，1B+，零，零W）。如果不存在，請自動進行。-DARMV7A=ON ：將此選項傳遞給ARMV7-A指令集（PI 2B <Rev 1.2）。如果不存在，請自動進行。-DARMV8A=ON ：通過此選項專門針對ARMV8-A指令集（PI 2B> = Rev。1.2，3b，3b，3b+，cm3，CM3 Lite，4B，4B，CM4，PI400）。如果不存在，請自動進行。 以下構建選項是所有顯示器和PI板的一般性，它們進一步自定義了構建：
-DBACKLIGHT_CONTROL=ON ：如果設置，則啟用FBCP-ILI9341可以控制給定背光引腳中的顯示背光。屏幕上不活動後，顯示屏將入睡。如果沒有，則不會觸摸背光。-DDISPLAY_CROPPED_INSTEAD_OF_SCALING=ON ：如果設置，源視頻框架大於SPI顯示視頻分辨率，源視頻是通過在所有方向上裁剪出來的部分，而不是縮放為fit。-DDISPLAY_BREAK_ASPECT_RATIO_WHEN_SCALING=ON ：當將源視頻縮放到SPI顯示時，默認情況下按以下縱橫比執行縮放，並根據需要添加信箱/支柱。如果設置了這一點，則進行拉伸的破壞縱橫比。-DSTATISTICS=number ：指定要在屏幕上顯示的疊加統計信息的級別。 0：禁用，1：啟用，2：啟用和顯示幀速率間隔圖。默認值為1（啟用）。-DUSE_DMA_TRANSFERS=OFF ：如果指定，請使用DMA Transfers（以丟失的CPU使用費用）禁用。如果DMA提出了一些問題，請通過此指令，例如，如果某事看起來不正確，則可以作為故障排除步驟。-DDMA_TX_CHANNEL=<num> ：指定用於SPI發送命令的DMA通道號。如果您發現DMA頻道沖突，請更改此操作。-DDMA_RX_CHANNEL=<num> ：指定用於SPI接收命令的DMA通道號。如果您發現DMA頻道沖突，請更改此操作。-DDISPLAY_SWAP_BGR=ON ：如果傳遞此選項，則將紅色和藍色通道逆轉（RGB <-> bgr）交換。某些顯示器具有相反的顏色面板子像素佈局，顯示控制器不會自動考慮，因此如果混合了藍色和紅色，請定義此。-DDISPLAY_INVERT_COLORS=ON ：如果傳遞此選項，則對像素顏色值解釋進行反轉（白色= 0，黑色= 31/63）。默認值：黑色= 0，白色= 31/63。如果顯示圖像看起來像實際顏色的顏色負面，則傳遞此選項。-DDISPLAY_ROTATE_180_DEGREES=ON ：如果設置，則旋轉顯示180度。這不會影響HDMI輸出，僅影響SPI顯示輸出。-DLOW_BATTERY_PIN=<num> ：指定可以進行輪詢以獲得電池狀態的GPIO引腳。默認情況下，設置此設置時，如果將引腳拉動較低，將顯示一個低電池圖標（有關對其進行調整的方式，請參見config.h ）。除上述CMAKE指令外，在代碼庫周圍（主要在Config.h）周圍，還有各種定義，主要控制著不同的運行時選項。直接編輯這些內容以進一步調整程序的行為。特別是，完成設置後，您可能需要在CMake配置行中使用-DSTATISTICS=0選項構建。
這是一個完整的示例，說明要構建和運行什麼，如果您的Adafruit 2.8“ 320x240 TFT/ touch w/ touch屏幕均用於Raspberry Pi，並帶有ILI9341控制器：
cd ~
sudo apt-get install cmake
git clone https://github.com/juj/fbcp-ili9341.git
cd fbcp-ili9341
mkdir build
cd build
cmake -DSPI_BUS_CLOCK_DIVISOR=6 -DADAFRUIT_ILI9341_PITFT=ON ..
make -j
sudo ./fbcp-ili9341如果以上不起作用，請嘗試指定-DSPI_BUS_CLOCK_DIVISOR=8或=10以使顯示器運行稍慢一點，或者使用-DUSE_DMA_TRANSFERS=OFF嘗試如果DMA可能是問題，則進行故障排除。如果您使用的是與ILI9341相比的另一個顯示控制器，則可能需要使用更高的值，例如30或40。更改CMAKE選項時，您可以重新發行CMAKE指令線，而無需重音或重新創建build目錄。但是，您可能需要在更改選項之間手動刪除文件cmakecache.txt，以避免記住舊設置。
如果您想從頭開始進行完整的重建，則可以rm -rf build以刪除構建目錄並重新創建其以從頭開始進行清潔重建。該目錄的名稱或位置沒有什麼特別的，這只是我通常的慣例。如果您願意，您也可以在其他目錄中與FBCP-ILI9341目錄進行構建。
要設置驅動程序以在啟動時啟動，請在sudo模式下編輯file /etc/rc.local
sudo /path/to/fbcp-ili9341/build/fbcp-ili9341 &到最後。記下所需的and &該行末尾。
例如，如果您使用上面列出的命令行步驟來構建，則文件/etc/rc.local將接收一行
sudo /home/pi/fbcp-ili9341/build/fbcp-ili9341 &如果您的Raspberry Pi安裝的用戶名除默認pi外，請相應地更改目錄以指向用戶的主目錄。 （使用pwd在終端中找出當前目錄）
systemd啟動顯示驅動程序另外，使用所提供的systemd單元文件，而不是修改/etc/rc.local ，如下所示：
sudo install -m 0644 -t /etc fbcp-ili9341.conf
sudo install -m 0644 -t /etc/systemd/system fbcp-ili9341.service
sudo systemctl daemon-reload
sudo systemctl enable fbcp && sudo systemctl start fbcp如果默認HDMI輸出/dev/fb0 Framebuffer的大小與顯示的分辨率不同，則默認情況下，源視頻大小將被重新縮放以適合SPI顯示屏的大小。 FBCP-ILI9341將在需要時管理設置此重新進行，並由GPU完成，因此性能不應受到太大影響。但是，如果決議不匹配，則小文本可能看起來難以辨認。調整大小將以縱橫比保留方式進行，因此，如果縱橫比不匹配，則顯示在顯示屏上的水平或垂直黑色邊界。如果您根本不使用HDMI輸出，則最好配置HDMI輸出以匹配SPI顯示大小，以便不需要重新進行重新制定。這可以通過在/boot/config.txt中設置以下行來完成。
hdmi_group=2
hdmi_mode=87
hdmi_cvt=320 240 60 1 0 0 0
hdmi_force_hotplug=1
如果您的SPI顯示器的分辨率與320x240不同，請將320 240零件更改為EG 480 320 。
這些行暗示本機應用程序有關默認顯示模式的應用程序，並讓它們渲染到TFT顯示的本機分辨率。但是，如果HDMI連接的顯示器不支持如此小的分辨率，則可以防止使用HDMI連接器。作為妥協，如果要同時使用HDMI和SPI顯示，則可以使用其他一些兼容的分辨率，例如640x480。有關可用選項，請參見Raspberry Pi HDMI文檔。
顯示屏的刷新速度取決於顯示屏連接的SPI總線的時鐘速度。由於Raspberry Pi作品上的BCM2835芯片的方式，因此不存在簡單的speed=xxx Mhz選項，該選項可以設置為定義總線速度。取而代之的是，SPI總線速度來自兩個單獨的參數：BCM2835 SOC的核心頻率（in /boot/config.txt中的core_freq ）和SPI外圍CDIV （時鐘分隔線）設置。然後使用公式SPI_speed=core_freq/CDIV一起計算所得的SPI總線速度。
為了優化顯示器以盡可能快地運行，
通過傳遞指令-DSPI_BUS_CLOCK_DIVISOR=number來調整CDIV值。可能8值是4 2 ... 6請注意，由於CDIV出現在SPI_speed公式中的分母中，因此較小的值會導致較高的總線速度，而較高的值則使顯示器變慢。最初，當您不知道顯示屏可以運行的速度時，請嘗試從安全的高設置開始，例如-DSPI_BUS_CLOCK_DIVISOR=30 ，然後以較小的數字來找到顯示顯示可以應對的最大速度。有關不同顯示的特定觀察到的最大總線速度，請參見README末尾的表。
確保渦輪速度。這對於良好的幀速率至關重要。在Raspberry Pi 3型B上，如果提供足夠的功率，則BCM2835核心默認情況下以400MHz運行（ 400/CDIV MHz SPI速度），如果CPU溫度不超過熱限。如果CPU空轉或電壓低，則BCM2835核心將恢復到非渦輪增壓250MHz狀態，從而導致250/CDIV MHz SPI速度。渦輪速度對性能的這種影響非常重要，因為400MHz與非渦輪增壓250MHz的影響佔多個帶寬的60％。獲得60fps的地震，聲音或Tyrian通常需要此渦輪頻率，但是即使庫存為250MHz，例如NES和C64模擬遊戲也可能達到60fps。如果由於某種原因即使應餵養足夠的功率，也可以通過在file /boot/config.txt中設置值avoid_warnings=2來強制啟動電壓保護。
也許有點違反直覺，核心核心。設置比默認渦輪增壓400MHz較小的核心頻率可以使用較小的時鐘分隔器啟用，從而獲得較高的SPI總線速度。例如，如果使用默認的core_freq=400 spi CDIV=8工作（導致SPI BUS SPEED 400MHz/8=50MHz ），但是CDIV=6不（ 400MHz/6=66.67MHz太多），您可以嘗試降低core_freq=360和設置CDIV=6以獲得360MHz/6=60MHz的有效SPI總線速度，這是兩者之間可能起作用的中間立場。平衡core_freq=和CDIV選項使人們可以找到最大的SPI總線速度到顯示器可以忍受的最後幾個kHz。一個人也可以嘗試相反的方向和超頻，但這當然會在超頻時出現所有問題。底關節確實具有使PI總體運行較慢的缺點，因此這無疑是一個權衡。
另一方面，希望控制允許使用多少CPU時間FBCP-ILI9341。對默認的構建設置進行了調整，以最大化顯示刷新速率，以犧牲PI 3B的功耗為代價。在Pi Zero上，相反的情況是，默認情況下，驅動程序優化了用於節省電池的驅動程序，而不是最大顯示更新速度。可以控制以下選項以在這兩個方面之間取得平衡：
控制CPU使用情況與性能方面的主要選項是#define ALL_TASKS_SHOULD_DMA在config.h中。啟用此選項將大大減少CPU使用情況。如果該選項被禁用，SPI總線利用率將最大化，但CPU使用率可以高達80％-120％。啟用此選項後，CPU的使用通常高達15％-30％。觀看視頻或玩快速移動的遊戲時，最大CPU使用發生。如果屏幕上沒有任何變化，則CPU的驅動程序消耗量應非常接近0-5％。默認情況下， #define ALL_TASKS_SHOULD_DMA啟用了Zero的啟用，但對於PI 3B而言是禁用的。
CMAKE選項-DUSE_DMA_TRANSFERS=ON應始終啟用以良好的低CPU使用。如果禁用了DMA傳輸，則驅動程序將以輪詢的SPI模式運行，該模式通常使用CPU時間的完整專用單核。如果DMA傳輸引起問題，請嘗試調整DMA發送和接收頻道，用於與-DDMA_TX_CHANNEL=<num>和-DDMA_RX_CHANNEL=<num> CMAKE選項。
統計覆蓋層打印出有關執行狀態的相當詳細的信息。使用-DSTATISTICS=0選項以提高性能並減少CPU使用情況。如果要繼續打印統計信息，則可以嘗試使用#define STATISTICS_REFRESH_INTERVAL <timeInMicroseconds>選項在config.h中增加間隔。
啟用#define USE_GPU_VSYNC可以減少CPU的消耗，但是由於Raspberrypi/userland＃440可能會導致口吃。禁用#defined USE_GPU_VSYNC會產生較少的口吃，但是由於RaspberryPi/Userland＃440，增加了CPU功耗。
選項#define SELF_SYNCHRONIZE_TO_GPU_VSYNC_PRODUCED_NEW_FRAMES可以與#define USE_GPU_VSYNC結合使用，以嘗試在RaspberryPi/userland＃440問題之間找到中間立場 - 中度到中度到小stutter，同時又試圖掌握很多CPU。嘗試嘗試啟用或禁用此設置。
config.h中有許多#define SAVE_BATTERY_BY_x選項，所有這些選項都默認為啟用。這些應該是安全使用的，而無需折衷。如果您遇到了延遲或與績效有關的問題，則可以嘗試切換這些問題以進行故障排除。
選項#define DISPLAY_FLIP_ORIENTATION_IN_SOFTWARE確實會導致一些額外的CPU使用，因此禁用其會減輕CPU負載。
如果與顯示大小相比，SPI顯示總線能夠非常快速運行，並且在屏幕上更改內容的數量，則可以嘗試啟用#define UPDATE_FRAMES_IN_SINGLE_RECTANGULAR_DIFF選項config.h在公共汽車上發送的字節數。已經觀察到這對Pi Zero有很大的影響，因此值得在那裡進行檢查。
如果SPI Display Bus能夠非常非常快速運行（或者您不在乎幀速率，而是僅在CPU使用率較低），則可以嘗試在config.h中啟用#define UPDATE_FRAMES_WITHOUT_DIFFING選項，以放棄自適應的delta擴散選項完全。這將恢復為幼稚的全幀更新，以最低的總體CPU使用。
選項#define RUN_WITH_REALTIME_THREAD_PRIORITY可以實現在實時過程優先級時運行驅動程序。但是，這可以鎖定係統，但仍可用於高級實驗。
在display.h中，有一個選項#define TARGET_FRAME_RATE <number> 。將其設置為較小的價值，例如30，將交易刷新率以減少CPU消費量。
FBCP-ILI9341的一個令人愉悅的方面是，它引入了很少的延遲開銷：在119Hz刷新的ILI9341顯示屏上，FBCP-ILI9341在GPIO輸入中獲得像素的響應，以便從GPIO輸入中響應屏幕，遠低於16.66毫秒。我只有一個120FPS錄像機，因此不能輕易地測量延遲的延遲，但是慢動作視頻鏡頭的粗略統計估計表明，這種延遲可能低至2-3毫秒，以〜8.4msecs面板刷新率主導ILI9341。
這並不意味著顯示遊戲延遲的總體輸入將是如此直接。簡要測試了NES模擬遊戲，這表明總延遲約為60-80毫秒。該延遲是由NES遊戲模擬器開銷和Linux，Despmanx和GPU渲染以及GPU FrameBuffer快照添加的額外延遲引起的。 （如果您將FBCP-ILI9341作為靜態庫繞過Despmanx和GPU堆棧，將您的GPIO輸入和應用程序邏輯直接鏈接到FBCP-ILI9341中GPIO輸入視頻上方）
有趣的是，FBCP-ILI9341比便宜的3.5英寸Kedei HDMI顯示器快〜33msecs。我不知道這是否是kedei hdmi顯示的結果，專門引入了額外的延遲，或者所有與PI連接的所有HDMI顯示延遲開銷。
不幸的是，SPI連接的顯示器的限制是，在SPI模式下運行時，Vsync線信號在顯示器控制器上不可用，因此即使顯示屏上的SPI BUS BARSWIDTH足夠快，也無法進行Vsync鎖定更新。例如，我所擁有的4個ILI9341顯示器的運行速度都比75MHz快，因此SPI BUS帶寬方面的運行速度所有這些都可以在少於Vsync間隔的情況下更新全幀，但是不可能將更新同步到更新Vsync由於顯示控制器沒有報告。 （如果您確實知道確實在SPI模式下確實會揭示Vsync時鐘信號的顯示，則可以嘗試實現支持以鎖定它）
但是，您可以在兩種不同類型的撕裂工件之間進行選擇：直線撕裂和對角線撕裂。看起來更好的哪個是主觀的，這就是兩個選項存在的原因。我更喜歡直線撕裂的人工製品，它似乎不如對角線撕裂。要切換此操作，請編輯選項#define DISPLAY_FLIP_ORIENTATION_IN_SOFTWARE在config.h中。啟用此選項後，FBCP-ILI9341會產生直線撕裂，並且消耗了幾％的CPU功率。默認情況下，Pi 3b的直線撕裂構建，而Pi零是零撕裂。查看視頻潛伏期和撕裂測試＃2：GPIO輸入以顯示fbcp-ili9341中的延遲，並在慢動作視頻中查看撕裂模式，這兩個撕裂模式的樣子。
眾所周知，會影響撕裂偽像的樣子的另一種選擇是內部面板刷新速率。對於ILI9341，可以在ili9341.h中調整此刷新率，並且可以將其設置為介於ILI9341_FRAMERATE_61_HZ和ILI9341_FRAMERATE_119_HZ之間。較慢的刷新率會產生較少的撕裂，但輸入到顯示延遲較高，而較高的刷新率將導致相反的情況。同樣，從視覺上看，結果效果有點主觀。
要獲取免費的免費更新，您應該使用DPI顯示器或優質的HDMI顯示屏。請注意，諸如Kedei之類的便宜的3.5英寸HDMI顯示器也確實會撕裂 - 也就是說，即使它們是通過HDMI控制的，它們實際上並沒有實現Vsync的定時內部操作。
但是，沒有vsync並不是很糟糕，因為由於缺乏vsync，SPI顯示器有機會在無法更新60hz的內容上獲得更平滑的動畫。 SPI顯示器上的內容可能比DPI或HDMI在PI當前可以提供的內容少得多（儘管除了上面的Kedei案例外，我無法詳細測試它）。
影響顯示更新平滑度的主要選項是config.h中的#define USE_GPU_VSYNC行。如果啟用了此功能，則使用內部pi gpu hdmi vsync時鐘將幀驅動到顯示屏上。 PI GPU時鐘以獨立於內容的固定速率運行。可以通過在PI控制台上運行tvservice -s來發現此速率，通常為59Hz或60Hz。如果您的應用程序以此速率呈現，則動畫看起來會流暢，但如果不是，將會有口吃。例如，如果啟用了#define USE_GPU_VSYNC則使用設置為60Hz的HDMI時鐘在50Hz更新50Hz的PAL NES遊戲將導致視頻輸出不良。
如果禁用了USE_GPU_VSYNC ，則使用忙碌的旋轉GPU框架快照線程來驅動更新。這將產生無法維持固定60Hz速率的內容的更平滑的動畫。尤其是在Opentyrian中，該遊戲以固定的36FPS呈現並具有緩慢的滾動風景，由USE_GPU_VSYNC引起的口吃特別明顯。在pi 3b上啟用pi 3b，啟用了無用的USE_GPU_VSYNC在ADAFRUIT 2.8“ ILI9341 pitft上的視覺上看起來更光滑滾動，該pitft設置為在119Hz上進行更新，與啟用USE_GPU_VSYNC ，而無需使用USE_GPU_VSYNC poll opter_gpu_vsync polling oplop poll oplop poll opter oplop poll opter'遊戲，然後以此精確的速率將像素推到顯示器上，因為SPI顯示無視Vsync-結果是將框架立即推到SPI顯示器時，而不是將它們拉開像HDMI這樣的60Hz速率也是如此。
一個缺點是，這種投票比Vsync選項消耗更多的CPU時間。與Vsync方法相比，額外的開銷約為CPU使用的34％。它還需要使用背景線程，因此，在單個Core Pi Zero上使用不可行。如果不需要此輪詢，則此模式也將在Zero上起作用，並且在PI 3B上沒有添加 +34％CPU開銷。有關更多詳細信息，請參見下面的已知問題部分。
還有其他兩個主要選項會影響框架交付時間， #define SELF_SYNCHRONIZE_TO_GPU_VSYNC_PRODUCED_NEW_FRAMES和#define SAVE_BATTERY_BY_PREDICTING_FRAME_ARRIVAL_TIMES 。在119Hz上查看pi 3b和Adafruit ILI9341上的視頻FBCP-ILI9341框架交付平滑度測試，以對這些不同模式進行詳細的並排比較。視頻中四個經過測試的方案得出的結論是：
1。VC_DISPMANX_VSYNC_CALLBACK（）（左上） ，設置#define USE_GPU_VSYNC和UNSET #define SELF_SYNCHRONIZE_TO_GPU_VSYNC_PRODUCED_NEW_FRAMES ：
此模式使用dispmanx hdmi vsync信號回調將幀驅動到顯示。
優點：
缺點：
2。VC_DISPMANX_VSYNC_CALLBACK（） +自我同步（右上） ，設置#define USE_GPU_VSYNC和#define SELF_SYNCHRONIZE_TO_GPU_VSYNC_PRODUCED_NEW_FRAMES ：
該模式使用GPU VSYNC信號，但也旨在在內容產生幀時查找並同步到邊緣觸發器。這是PI Zero上的默認構建模式。
優點：
缺點：
3。GPU輪詢線 +睡眠啟發式（左下） ，未設置#define USE_GPU_VSYNC並設置#define SAVE_BATTERY_BY_PREDICTING_FRAME_ARRIVAL_TIMES ：
此模式運行一個專用的背景線程，該線程將框架從GPU驅動到SPI顯示屏。這是PI 3B上的默認構建模式。
優點：
缺點：
4。gpu投票線程不睡覺（右下） ，unset #define USE_GPU_VSYNC和unset #define SAVE_BATTERY_BY_PREDICTING_FRAME_ARRIVAL_TIMES ：
此模式盡可能快地運行專用的GPU線程，而無需嘗試睡覺CPU。
優點：
缺點：
注意以下局限性：
vc_dispmanx_snapshot() API捕獲屏幕框架緩衝器，然後將所獲得的像素路由到基於SPI的顯示。進行這種民意調查，因為沒有基於事件的機制可以從GPU生成的情況下獲取新框架。結果效率低下，很容易引起口吃，因為不同的應用程序在不同的步伐下產生幀。理想情況下，代碼會要求視頻API在渲染後立即在回調通知中接收完成的幀，但是當前GPU驅動程序堆棧中不存在這種功能。在沒有這種事件交付機制的情況下，該代碼必須使用精心定時的啟發式方法來訴諸顯示框架的快照，以在保持潛伏期和口吃低之間平衡，同時又不會導致過多的功耗。這些啟發式方法不斷猜測屏幕上動畫的更新速率，並且在屏幕上沒有檢測到的活動時，它們已經進行了調整，以確保CPU使用率下降到0％，但這肯定不是完美的。該GPU限制將在Raspberrypi/Userland＃440上討論。如果您想查看FBCP-ILI9341操作減少延遲，口吃和功耗，請在該錯誤線程中扔一個（善良的評論！）評論或大拇指表情符號，以分享您關心的問題，也許可能是Raspberry Pi工程師在開發路線圖上獲取改進。 If this issue is resolved, all of the #define USE_GPU_VSYNC , #define SAVE_BATTERY_BY_PREDICTING_FRAME_ARRIVAL_TIMES and #define SELF_SYNCHRONIZE_TO_GPU_VSYNC_PRODUCED_NEW_FRAMES hacks from the previous section could be deleted from the driver, hopefully leading to a best of all worlds scenario without drawbacks. /boot/config.txt中設置所需的屏幕分辨率，並配置所有應用程序，以免在運行時更改該應用程序。 400/250=+60% 。因此，當選擇使用SPI CDIV值時，必須選擇一個適合怠速和渦輪時鐘速度的工作。相反，BCM核心在僅有輕度CPU負載活動時會恢復到非渦輪速度，並且這會減慢顯示屏，因此，如果應用程序在圖形上很密集，但在CPU上進行了輕度以最大速度。解決此問題的一種方法是強迫BCM核心在force_turbo=1 /boot/config.txt始終保持其渦輪狀態，但這具有不幸的效果，即導致ARM CPU始終以Turbo速度運行為好吧，消耗過多的功率。在撰寫本文時，還沒有一個很好的解決方案來具有節能和良好的性能。 RaspberryPI/固件＃992正在更詳細地討論此限制。 有關更多已知的問題和限制，請查看“錯誤跟踪器”，特別是標記已退休的條目，以了解超出當前範圍的項目。
默認情況下，FBCP-ILI9341啟用了統計覆蓋層。請參閱視頻FBCP -ILI9341移植到ILI9486 WaveShare 3.5“（b）Spotpear 320x480 SPI顯示顯示，以查找每個字段的含義的詳細信息。使用CMAKE選項-DSTATISTICS=0 to disable disable disable顯示統計信息。您還可以嘗試使用CMAKE構建選項。 -DSTATISTICS=2顯示更詳細的框架交付時間直方圖視圖，請參見上面的屏幕截圖和視頻。
名稱中的fbcp部分錶示FrameBuffer副本；專門針對ILI9341控制器。 FBCP-ILI9341實際上並不是框架複製驅動程序，它不會創建輔助幀緩衝程序，它將從主幀緩衝器中復製字節。它也不再僅是ILI9341控制器的驅動程序。更合適的名稱可能是Userland-raspi-spi-display-Driver或類似的東西，但原始名稱卡住了。
是的，確實不如PI 3B上的好。如果您希望它能在Zero上更好地運行，請在Raspberrypi/userland＃440上留下大拇指 - 硬問題很難確定優先級，除非知道許多人關心它們。
編輯文件config.h並評論#define DISPLAY_OUTPUT_LANDSCAPE行。這將使顯示器輸出以肖像模式有效地旋轉90度。請注意，這僅影響顯示屏的像素內存讀取模式。不可能更改面板掃描順序以在景觀和肖像之間運行，SPI通常顯示在肖像模式下掃描。結果是它將將面板Vsync撕裂模式從“直線撕裂”更改為“對角線撕裂”（請參閱上面有關撕裂的部分）。
如果您不想有對角線撕裂，但寧願直線撕裂，則在config.h中啟用選項#define DISPLAY_FLIP_ORIENTATION_IN_SOFTWARE 。這將恢復直線撕裂，但也將增加總體CPU消耗量。
在config.h中啟用選項#define DISPLAY_ROTATE_180_DEGREES 。這應該旋轉SPI顯示屏以顯示另一種方式，同時保持HDMI連接的顯示方向不變。另一個選項是利用A /boot/config.txt選項display_rotate = 2，它同時旋轉SPI輸出和HDMI輸出。
請注意，設置DISPLAY_ROTATE_180_DEGREES僅影響顯示的像素內存讀取模式。不可能將面板掃描翻轉以倒入180度的倒置。這意味著調整這些設置也將具有更改Vsync撕裂偽像的視覺外觀的影響。如果您可以在項目中安裝180度的顯示器，則建議這樣做，而不是使用DISPLAY_ROTATE_180_DEGREES選項。
在文本編輯器中編輯文件config.h （命令行，例如pico ， vim ， nano或ssh映射到主機的驅動器），並在文件中找到適當的行。在該文本的前面添加註釋行//禁用選項，或刪除//字符以啟用它。
編輯並保存文件後，在構建目錄中重新發行make -j並重新啟動FBCP -ILI9341。
一些選項將從CMAKE配置腳本傳遞給構建。您可以使用make VERBOSE=1運行，以查看CMAKE構建通過的哪些配置項目。請參閱上面的配置構建選項部分，以自定義CMAKE配置項目。例如，要刪除統計覆蓋層，請通過-DSTATISTICS=0指令到CMAKE。
建築物需要在PI上安裝CMAKE：嘗試sudo apt-get install cmake 。
嘗試在更改Cmake設置之間刪除cmakecache.txt。
是的，兩個都很好。對於Linux命令行終端，應將/dev/tty1控制台設置為輸出到Linux Framebuffer 0（ /dev/fb0 ）。這是默認的操作模式，在Raspbian的默認分佈中不存在其他幀緩衝器，但是如果您在安裝中手動用con2fbmap命令弄亂了，則可能會無意中更改此配置。運行con2fbmap 1以查看/dev/tty1控制台正在輸出哪個framebuffer，它應打印console 1 is mapped to framebuffer 0 。鍵入con2fbmap 1 0重置控制台1返回到輸出到FrameBuffer 0。
同樣，應將X窗口系統配置為渲染到framebuffer 0。默認情況下這是這種情況。 X窗口服務的目標幀緩衝器通常在啟動X之前通過FRAMEBUFFER環境變量進行配置。如果X不起作用，則可以嘗試通過使用FRAMEBUFFER=/dev/fb0 startx啟動X來嘗試覆蓋FrameBuffer，而不僅僅是運行startx 。
我不知道，我目前沒有任何測試。也許該代碼確實需要某些特定模型的配置，或者也許可以從開箱即用。我只有PI 3B，PI 3B+，Pi Zero W和一個基於PI 3計算模塊的系統進行實驗。據報導，PI 2 B的用戶工作（＃17）。
如果顯示控制器是當前測試的一個（請參見上面的列表），並且使用4線SPI將其連接到運行，則應使用。請注意正確配置Data/Control GPIO PIN編號，並在設備具有一個設備（如果設備具有）時指定Reset GPIO PIN號。
如果顯示控制器不是經過測試的控制器，則如果與現有的控制器類似，則可能仍然可以工作。例如，ILI9340和ILI9341實際上是同一控制器。您只需嘗試一個特定的方法即可查看它的發展。
如果FBCP-ILI9341不支持您的顯示控制器，則必須為其寫支持。 FBCP-ILI9341沒有“通用SPI TFT驅動程序例程”，該程序可能會在多個設備上工作，但每個設備都需要特定的代碼。如果您有可用的規格表，則可以尋求建議，但請不要要求為顯示“盲人”的顯示控制器添加支持，這是不可能的。
也許。這是一個最新的實驗功能，可能不那麼穩定，並且存在一些局限性，但是現在可以使用3線（“ 9位”）SPI顯示支持。如果您有3線SPI顯示屏，即沒有數據/控件（DC）GPIO PIN可以連接的一個，請使用指令-DGPIO_TFT_DATA_CONTROL=-1來告訴FBCP-ILI9341，它應該驅動fbcp-ili9341使用3線協議顯示。
3線通信的當前局限性是：
ALL_TASKS_SHOULD_DMA ，DMA鏈的問題可以防止啟用此功能。結果，3線顯示器上的CPU使用率將比4線顯示器略高。OFFLOAD_PIXEL_COPY_TO_DMA_CPP 。結果，在單核PI（例如pi Zero）上，3線顯示可能無法很好地工作。不。這些完全是完全不同的技術。如果有人有興趣，應該可以將驅動程序算法移植到I2C上。
目前，人們在運行FBCP-ILI9341時無法使用XPT2046/ADS7846觸摸控制器，因此觸摸與該驅動程序是互不相容的。為了使FBCP-ILI9341運行，您需要刪除與觸摸相關的/boot/config.txt中的所有dtoverlay s。
我已經接近所有可能的顯示器 - 在操作中間削減功率，發送隨機數據和命令字節，將其操作電壓命令和時鐘計時設置為任意高和低值，測試未指定和保留的命令字段，並驅動顯示數十個MHz的速度比他們能夠跟上的快速速度快，但我尚未對任何顯示器或PI造成永久損害。
造成永久損壞的最簡單方法是在接線上失敗，例如，如果您的顯示器需要3.3V或短時間連接或類似的東西，例如驅動5伏。
FBCP-ILI9341保持清晰的一件事是，它不會編程任何顯示器的非揮發性內存區域。因此，顯示屏上的強力關閉應清除所有執行的初始化，並在下一個電源下將顯示器重置為其初始狀態。
話雖這麼說，如果它破裂了，您將可以購買一種新的閃亮的閃光來代替它。
是的，FBCP-ILI9341顯示了SPI屏幕上HDMI顯示的輸出，並且兩者都可以同時附加。但是，儘管FBCP-ILI9341操作仍將受到任何HDMI顯示模式的影響，但不必連接HDMI顯示屏。在命令行上查看tvservice -s ，以檢查當前DESCMANX HDMI輸出模式是什麼。
目前，FBCP-ILI9341已開發出來僅顯示主Dispmanx GPU Framebuffer的內容到SPI顯示屏。也就是說，SPI顯示屏將顯示與HDMI輸出相同的圖片。不過，沒有任何需要此的技術限制，因此，如果您知道C/C ++很好，那麼將FBCP-ILI9341轉動為一個屏幕外顯示庫以顯示一個完全獨立的（非GPU加速）圖像，這應該是一個易於管理的項目。比主HDMI顯示輸出的內容。例如，您可以有兩個不同的輸出，例如HUD覆蓋，一個用於網絡統計，天氣，溫度等的儀表板，同時在HDMI上顯示主Raspberry Pi桌面時顯示。
在這種模式下，您可能會從fbcp-ili9341中剝離dispmanx位，並將其重新出現為靜態庫，然後在圖紙應用程序中鏈接到該庫，而不是快照框架，然後可以編程地寫入Framebuffer ，在您的C/C ++代碼中的內存中。
不幸的是，有很多事情要出錯，所有這些都會導致白屏。這可能是診斷最困難的部分。一些想法：
這表明電源線或背光線可能無法正確連接。或者，如果背光連接到PI（而不是電壓引腳）上的GPIO引腳，則可能是銷釘不處於正確的狀態，可以打開背光。大多數LCD TFT顯示我在收到電源時立即點亮了背光。 Tontec One具有一個背光GPIO引腳，該引腳抬高，但必須將其拉低以激活背光。另一方面，OLED顯示器似乎即使在等待其初始化的同時都可以保持全黑，因此對於OLEDS來說，啟動後立即在屏幕上沒有什麼可以正常出現。
如果背光連接到GPIO PIN，則可能需要在cmake命令行或config.h中定義-DGPIO_TFT_BACKLIGHT=<pin> ，然後編輯config.h啟用#define BACKLIGHT_CONTROL 。
fbcp-ili9341在初始化後首先以低速運行一個清晰的屏幕命令，因此，如果通過的話，這是一個好兆頭。嘗試增加-DSPI_BUS_CLOCK_DIVISOR= cmake選項到更高的數字，以查看顯示驅動率是否太快。或嘗試使用-DUSE_DMA_TRANSFERS=OFF禁用DMA，以查看這可能是DMA衝突。
這表明與上述相同，增加SPI總線除數或故障排除禁用DMA。如果檢測到DMA為罪魁禍首，請嘗試更改DMA通道。仔細檢查/boot/config.txt是否沒有有關其他SPI顯示驅動程序或觸摸屏控制器的任何dtoverlay s，並且它沒有dtparam=spi=on在其中-FBCP -ILI9341不使用Linux Kernel SPI驅動程序。
確保其他fbcp程序未運行，或者fbcp-ili9341的另一份副本未在後台運行。
這很可能是由於調整視頻分辨率在運行時大小的程序引起的，這會破壞Despmanx。有關更多詳細信息，請參見Raspberrypi/Userland＃461。
檢查PI是否可以從可以跟上電壓的電源中電源，並且低電壓圖標未顯示。 （刪除/boot/config.txt的任何avoid_warnings=1/2指令如果用來擺脫警告覆蓋層，以檢查電壓是否很好），已經觀察到，如果沒有足夠的電源，則顯示器可以可以成為第一個餓死的人，而PI可能會保持良好狀態。如果您超頻以驗證顯示崩潰與用法無關，請嘗試刪除渦輪設置或降低時鐘速度。
另外，請嘗試將SPI總線速度降低至安全的較低值，例如顯示屏能夠管理的最大速度的一半。
在物理和CMAKE命令行中仔細檢查數據/命令（D/C）GPIO PIN。每當FBCP-ILI9341引用PIN號時，始終在BCM PIN編號中指定它們。嘗試設置更高的-DSPI_BUS_CLOCK_DIVISOR= cmake值。確保不啟用其他fbcp程序或SPI驅動程序或DToverlays。
如果混合了顏色通道（紅色為藍色，藍色為紅色，綠色為綠色），如左圖所示，請傳遞cmake選項-DDISPLAY_SWAP_BGR=ON to Build。
如果顏色強度看起來錯誤（白色是黑色，黑色，顏色看起來像一個負面圖像），例如中間圖像中的CMAKE選項-DDISPLAY_INVERT_COLORS=ON to build build。
如果顏色以其他方式看待，則顯示顯示器可能只是以太高的SPI總線速度驅動，在這種情況下，嘗試通過選擇較高的-DSPI_BUS_CLOCK_DIVISOR= cmake選項來使顯示器運行較慢。特別是在ILI9486顯示器上，已經觀察到，如果顯示屏運行得太快，則顯示屏上的顏色可能會變形。
如果啟用了DMA傳輸，則FBCP-ILI9341需要一些GPU內存的兆字節才能起作用。 GPU_MEM啟動配置選項決定了PI的存儲區域的多少分配給GPU。默認情況下，這是64MB，如果HDMI以1080p運行，則觀察到它不會為FBCP-ILI9341留下足夠的內存。如果發生此錯誤，請嘗試通過在/boot/config.txt中添加一行gpu_mem=128來將GPU內存增加到EG 128MB。
隨著支持顯示的數量，Raspberry Pi設備型號，Raspbian/Retropie/Lakka OS版本，隨附的C ++編譯器版本和FBCP-ILI9341構建選項的數量已經增長，有一個組合模式的組合爆炸，可以放置所有可能的構建模式。通用代碼庫，因此，請始終對所有可能的組合進行測試並不容易。某些東西可能已經退化或過時了。保持冷靜，報告一個錯誤。
您還可以嘗試查看“提交歷史記錄”，以查找與您的配置組合相關的更改，以查看是否提到已知的良好及時提交，適合您的情況。如果您在cmake或make線路上遇到奇數編譯器錯誤，通常這些錯誤很容易修復，因為它們大多是某些配置監督的結果。
首先，確保顯示器是4線SPI，而不是3線SPI。如果顯示器具有需要連接的數據/控件（DC）GPIO線，則顯示為4線SPI。有時D/C引腳標記為RS（寄存器選擇）。確實存在對3線SPI顯示器的支持，但是它是實驗性的，並且測試不如4線顯示。
第二是關於顯示速度的考慮。以下是我測試過的不同顯示的性能圖表。請注意，這些是一個樣本量，我不知道存在多少樣本差異。另外，我不知道與不同製造商的同一控制器顯示器之間是否存在很大的差異。至少我所擁有的不同ILI9341顯示器在性能上都非常一致，無論是來自Adafruit還是WaveShare還是BuyDisPlay.com。
| 小販 | 尺寸 | 解決 | 控制器 | 額定的SPI巴士速度 | 獲得了公共汽車速度 | 幀速率 |
|---|---|---|---|---|---|---|
| Adafruit Pitft | 2.8” | 240x320 | ILI9341 | 10MHz | 294MHz/4 = 73.50MHz | 59.81 fps |
| Adafruit Pitft | 2.2” | 240x320 | ILI9340 | 15.15MHz | 338MHz/4 = 84.50MHz | 68.76 fps |
| Adafruit Pitft | 3.5” | 320x480 | HX8357D | 15.15MHz | 314MHz/6 = 52.33MHz | 21.29 fps |
| Adafruit Ole | 1.27“ | 128x96 | SSD1351 | 20MHz | 360MHz/20 = 18.00MHz | 91.55 fps |
| Waveshare RPI LCD（B）IPS | 3.5” | 320x480 | ILI9486 | 15.15MHz | 255MHz/8 = 31.88MHz | 12.97 fps |
| Maithoga TFT LCD | 3.5” | 320x480 | ILI9486L | 15.15MHz | 400MHz/8 = 50.00MHz | 13.56 fps* |
| buydisplay.com spi tft副本＃1 | 3.2” | 240x320 | ILI9341 | 10MHz | 310MHz/4 = 77.50MHz | 63.07 fps |
| BuyDisplay.com SPI TFT copy #2 | 3.2” | 240x320 | ILI9341 | 10MHz | 300MHz/4=75.00MHz | 61.03 fps |
| Arduino A000096 LCD | 1.77" | 128x160 | ST7735R | 15.15MHz | 355MHz/6=59.16MHz | 180.56 fps |
| Tontec MZ61581-PI-EXT 2016.1.28 | 3.5” | 320x480 | MZ61581 | 128MHz | 280MHz/2=140.00MHz | 56.97 fps |
| Adafruit 240x240 Wide Angle TFT | 1.54" | 240x240 | ST7789 | ？ | 340MHz/4=85.00MHz | 92.23 fps |
| WaveShare 240x240 Display HAT | 1.3” | 240x240 | ST7789VW | 62.5MHz | 338MHz/4=84.50MHz | 91.69 fps |
| WaveShare 128x128 Display HAT | 1.44" | 128x128 | ST7735S | 15.15MHz | （未經測試） | （未經測試） |
| KeDei v6.3 | 3.5” | 320x480 | MPI3501 | ？ | 400MHz/12=33.333MHz | 4.8fps ** |
In this list, Rated SPI Bus Speed is the maximum clock speed that the display controller is rated to run at. The Obtained Bus Speed column lists the fastest SPI bus speed that was achieved in practice, and the core_freq BCM Core speed and SPI Clock Divider CDIV setting that was used to achieve that rate. Note how most display controllers can generally be driven much faster than what they are officially rated at in their spec sheets.
The Frame Rate column shows the worst case frame rate when full screen updates are being performed. This occurs for example when watching fullscreen video (that is not a flat colored cartoon). Because fbcp-ili9341 only sends over the pixels that have changed, displays such as HX8357D and ILI9486 can still be used to play many games at 60fps. Retro games work especially well.
All the ILI9341 displays work nice and super fast at ~70-80MHz. My WaveShare 3.5" 320x480 ILI9486 display runs really slow compared to its pixel resolution, ~32MHz only. See fbcp-ili9341 ported to ILI9486 WaveShare 3.5" (B) SpotPear 320x480 SPI display for a video of this display in action. Adafruit's 320x480 3.5" HX8357D PiTFTs is ~64% faster in comparison.
The ILI9486L controller based maithoga display runs a bit faster than ILI9486 WaveShare, 50MHz versus 31.88MHz, ie +56.8% bandwidth increase. However fps-wise maithoga reaches only 13.56 vs WaveShare 12.97 fps, because the bandwidth advantage is fully lost in pixel format differences: ILI9486L requires transmitting 24 bits per each pixel (R6G6B6 mode), whereas ILI9486 supports 16 bits per pixel R5G6B5 mode. This is reflected in the above chart refresh rate for the maithoga display (marked with a star).
If manufacturing variances turn out not to be high between copies, and you'd like to have a bigger 320x480 display instead of a 240x320 one, then it is recommended to avoid ILI9486, they indeed are slow.
The KeDei v6.3 display with MPI3501 controller takes the crown of being horrible, in all aspects imaginable. It is able to run at 33.33 MHz, but due to technical design limitations of the display (see #40), effective bus speed is halved, and only about 72% utilization of the remaining bus rate is achieved. DMA cannot be used, so CPU usage will be off the charts. Even though fbcp-ili9341 supports this display, level of support is expected to be poor, because the hardware design is a closed secret without open documentation publicly available from the manufacturer. Stay clear of KeDei or MPI3501 displays.
The Tontec MZ61581 controller based 320x480 3.5" display on the other hand can be driven insanely fast at up to 140MHz! These seem to be quite hard to come by though and they are expensive. Tontec seems to have gone out of business and for example the domain itontec.com from which the supplied instructions sheet asks to download original drivers from is no longer registered. I was able to find one from eBay for testing.
Search around, or ask the manufacturer of the display what the maximum SPI bus speed is for the device. This is the most important aspect to getting good frame rates, but unfortunately most web links never state the SPI speed rating, or they state it ridiculously low like in the spec sheets. Try and buy to see, or ask in some community forums from people who already have a particular display to find out what SPI bus speed it can achieve.
One might think that since Pi Zero is slower than a Pi 3, the SPI bus speed might not matter as much when running on a Pi Zero, but the effect is rather the opposite. To get good framerates on a Pi Zero, it should be paired with a display with as high SPI bus speed capability as possible. This is because the higher the SPI bus speed is, the more autonomously a DMA controller can drive it without CPU intervention. For the same reason, the interlacing technique does not (currently at least) perform well on a Pi Zero, so it is disabled there by default. ILI9341s run well on Pi Zero, ILI9486 on the other hand is quite difficult to combine with a Pi Zero.
Ultimately, it should be noted that parallel displays (DPI) are the proper method for getting fast framerates easily. SPI displays should only be preferred if display form factor is important and a desired product might only exist as SPI and not as DPI, or the number of GPIO pins that are available on the Pi is scarce that sacrificing dozens of pins to RGB data is not可行的。
Hardware-wise, there are six different ways to connect displays to the Pi. Here are the pros and cons of each:
Displays are generally manufactured to utilize one specific interfacing method, with the exception that some displays have a both I²C and SPI modes that can be configured via soldering.
Fbcp-ili9341 driver is about interfacing with SPI displays. If your display utilizes some other connection mechanism, fbcp-ili9341 will not apply.
Software-wise, there are two possible alternatives to fbcp-ili9341:
The following links proved helpful when writing this:
If you would like to help push Raspberry Pi SPI display support further, there are always more things to do in the project. Here is a list of ideas and TODOs for recognized work items to contribute, roughly rated in order of increasing difficulty.
top / htop , or with a power meter off the wall and report the results.SPI_3WIRE_PROTOCOL + ALL_TASKS_SHOULD_DMA to work together, or 3) fix up SPI_3WIRE_PROTOCOL + OFFLOAD_PIXEL_COPY_TO_DMA_CPP to work together.ALL_TASKS_SHOULD_DMA mode to be always superior in performance and CPU usage so that the non- ALL_TASKS_SHOULD_DMA path can be dropped from the codebase. (probably requires the above chaining to function efficiently)This driver is licensed under the MIT License. See LICENSE.txt. In nonlegal terms, it's yours for both free and commercial projects, DIY packages, kickstarters, Etsys and Ebays, and you don't owe back a dime. Feel free to apply and derive as you wish.
If you found fbcp-ili9341 useful, it makes me happy to hear back about the projects it found a home in. If you did a build or a project where fbcp-ili9341 worked out, it'd be great to see a video or some photos or read about your experiences.
I hope you build something you enjoy!
Best way to discuss the driver is to open a GitHub issue. You may also be able to find me over at sudomod.com Discord channel.
