一个运行速度极快的驱动程序,用于基于 SPI 的 LCD 显示器,适用于 Raspberry Pi A、B、2、3、4 和 Zero
一个运行速度极快的驱动程序,用于基于 SPI 的 LCD 显示器,适用于 Raspberry Pi A、B、2、3、4 和 Zero
The era of fbcp-ili9341 has come to an end. Fbcp-ili9341 was built on top of the Raspberry Pi's VideoCore DispmanX API.
However, this API has been deprecated by the Raspberry Pi Foundation for a while now, and finally obsolete (=unavailable) on Raspberry Pi 5 and onwards.
The later Raspberry Pi distros no longer have DispmanX active by default even for Pi0-Pi4, but instead Raspberry Pi has moved over to the newer KMS driver compositor stack, which has a different abstraction for integrating SPI display drivers. Other people are developing SPI display drivers for the Pi that are compatible with the KMS stack. Head on to this Raspberry Pi forum thread to learn more.
This repository is good to be considered archived/stale, although I am not marking it Archived using the GitHub feature, since that feature apparently would also make the issue tracker read-only. Feel free to continue discussing issues on the tracker.
This repository implements a driver for certain SPI-based LCD displays for Raspberry Pi A, B, 2, 3, 4 and Zero.
The work was motivated by curiosity after seeing this series of videos on the RetroManCave YouTube channel:
In these videos, the SPI (GPIO) bus is referred to being the bottleneck. SPI based displays update over a serial data bus, transmitting one bit per clock cycle on the bus. A 320x240x16bpp display hence requires a SPI bus clock rate of 73.728MHz to achieve a full 60fps refresh frequency. Not many SPI LCD controllers can communicate this fast in practice, but are constrained to e.g. a 16-50MHz SPI bus clock speed, capping the maximum update rate significantly. Can we do anything about this?
The fbcp-ili9341 project started out as a display driver for the Adafruit 2.8" 320x240 TFT w/ Touch screen for Raspberry Pi display that utilizes the ILI9341 controller. On that display, fbcp-ili9341 can achieve a 60fps update rate, depending on the content that is being displayed. Check out these videos for examples of the driver in action:
Given that the SPI bus can be so constrained on bandwidth, how come fbcp-ili9341 seems to be able to update at up to 60fps? The way this is achieved is by what could be called adaptive display stream updates. Instead of uploading each pixel at each display refresh cycle, only the actually changed pixels on screen are submitted to the display. This is doable because the ILI9341 controller, as many other popular controllers, have communication interface functions that allow specifying partial screen updates, down to subrectangles or even individual pixel levels. This allows beating the bandwidth limit: for example in Quake, even though it is a fast pacing game, on average only about 46% of all pixels on screen change each rendered frame. Some parts, such as the UI stay practically constant across multiple frames.
Other optimizations are also utilized to squeeze out even more performance:
#define NO_INTERLACING in file config.h)The result is that the SPI bus can be kept close to 100% saturation, ~94-97% usual, to maximize the utilization rate of the bus, while only transmitting practically the minimum number of bytes needed to describe each new frame.
The driver has been checked to work (at least some point in the past) on the following systems:
although not all boards are actively tested on, so ymmv especially on older boards. (Bug fixes welcome, use https://elinux.org/RPi_HardwareHistory to identify which board you are running on)
The following LCD displays have been tested:
Check the following sections to set up the driver.
This driver does not utilize the notro/fbtft framebuffer driver, so that needs to be disabled if active. That is, if your /boot/config.txt file has lines that look something like dtoverlay=pitft28r, ..., dtoverlay=waveshare32b, ... or dtoverlay=flexfb, ..., those should be removed.
This program neither utilizes the default SPI driver, so a line such as dtparam=spi=on in /boot/config.txt should also be removed so that it will not cause conflicts.
Likewise, if you have any touch controller related dtoverlays active, such as dtoverlay=ads7846,... or anything that has a penirq= directive, those should be removed as well to avoid conflicts. It would be possible to add touch support to fbcp-ili9341 if someone wants to take a stab at it.
Run in the console of your Raspberry 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
Note especially the two dots .. on the CMake line, which denote "up one directory" in this case (instead of referring to "more items go here").
See the next section to see what to input under [options].
If you have been running existing fbcp driver, make sure to remove that e.g. via a sudo pkill fbcp first (while running in SSH prompt or connected to a HDMI display), these two cannot run at the same time. If /etc/rc.local or /etc/init.d contains an entry to start up fbcp at boot, that directive should be deleted.
There are generally two ways to configure build options, at CMake command line, and in the file config.h.
On the CMake command line, the following options can be configured:
When using one of the displays that stack on top of the Pi that are already recognized by fbcp-ili9341, you don't need to specify the GPIO pin assignments, but fbcp-ili9341 code already has those. Pass one of the following CMake directives for the hats:
-DADAFRUIT_ILI9341_PITFT=ON: If you are running on the Adafruit 2.8" 320x240 TFT w/ Touch screen for Raspberry Pi (or the Adafruit PiTFT 2.2" HAT Mini Kit - 320x240 2.2" TFT - No Touch display, which is compatible), pass this flag.-DADAFRUIT_HX8357D_PITFT=ON: If you have the Adafruit PiTFT - Assembled 480x320 3.5" TFT+Touchscreen for Raspberry Pi display, add this line.暂无开放 Issues，或尚未同步最近议题。