connecting a tft lcd to raspberry pi w price
I have done quite a lot of research online but I am confused as to if connecting this screen to the Pi will be trivial and something that a beginner in the field of electrical engineering should attempt. I am aware that you can purchase pre-built screens with the intention to run with Raspbian on a Pi (such as ADA-Fruit), but I am not sure of the steps required for this type of cheap LCD screen. Will I have to add hardware? I guess I will probably have to load drivers into the kernel for the screen.
I"ve been looking around for a small HDMI LCD screen to use as a seconday screen with Windows and it took a few months of research on and off before deciding on the Elecrow 5" HDMI monitor. For the most part, it took me a while because a lot of reviews here and on other sites were primarily about use and config with Raspberry Pi.
Thanks to reviewer Alan who gave a good review with plenty of photos that convinced me to go for it. Not sure if it"s just how Amazon stores user review videos but the video review was a bit pixelated so it was hard to appreciate the clarity of the screen but it seemed to be what I was looking for.
Having used it for a few months now I still can"t believe how clear and sharp the screen is! There are sadly no controls for brightness, colour, saturation or contrast but everything displayed looks very nice and accurate.
Usually when you see the resolution 800x480 you think how bad that looks when your PC doesn"t have the right drivers installed and it looks blocky. I know it"s all relative and about DPI but once I had it all connected and tested it was sharp and clear, almost HD. I wish I had bought one sooner as it is exactly what I was looking for having tried a Lilliput monitor.
As I"m using this with Windows, I"ve not needed to look through the included driver utility disc and not tried the resistive touchscreen so I can"t comment on those. Windows just detects it as a second display and lets me extend my desktop. No drivers needed. The box contains the LCD screen, a HDMI bridge connector that neatly connects the HDMI socket on the top of the screen to the HDMI socket on the Raspberry Pi when mounted together. Standoffs for mounting are also supplied plus a plastic stylus.
+ It shows the video feed straightaway without any fancy splash screens or slow initialisation pauses. This was one of the annoyances with Lilliput monitor was a slow bright blue screen on power on before it would think about showing the feed. I know it"s only a few seconds but I specifically wanted instant feed on power on for future uses.
+ Runs off a single micro USB (socket also at the top next to HDMI socket) connected to PC USB so no additional external power adapters or sockets needed. It powers down whenever my PC is scheduled to power down so no lingering standby. Some motherboard USB ports do still continue to supply power for charging devices so your experience may differ.
+ I was hoping for an on/off switch but no it only has a backlight switch which I wasn"t sure about to begin with but I"ve since found it very useful and better. I was thinking about buying a micro USB cable designed for Raspberry Pi with an inline power switch built in but for now the brightness switch is fine. As a blessing in disguise, it prevents Windows/DirectShow from blinking all screens when it realises a monitor has been disconnected, that blink would often cause the video on my TV app to freeze. Turning off backlight doesn"t cause DirectShow to have a fit.
+ Small and light enough that I have it attached to a gooseneck arm so can position it how I need. I was going to buy one of those mobile phone gooseneck arms but I kept reading reviews of some not even being able to cope with weight of a smartphone without drooping so I"ve used a photographic gooseneck clamp which is a bit overkill but no droop!
- The only negative I can think of is the availability or lack of screen cases with cutouts to suit the position of the HDMI and USB sockets on this. The Elecrow has its HDMI and USB socket at the top edge of screen and nearly all cases I have looked at are designed for screens with HDMI and USB on the right edge. I"ve had to import one from China that had the cutouts for this screen. Took about 2 weeks to arrive. Wish I"d have ordered two cases at the same time to avoid the wait as I"m impressed with the clarity of Elecrow I hope to buy another one in near future.
! Just one more thing Columbo! I had originally wanted to buy Revision B of this screen with capacitive touch screen because it has OSD menu buttons. I can"t find any manuals but I"m hoping that OSD buttons allows settings for brightness as that was my other preferred criteria. Having said that, I think it would be even more impossible to find suitable case due to the positions of sockets and extra menu buttons on Revision B screen. Maybe Elecrow could provide some insight on available cases?
In this tutorial, we are going to interface a 3.5-inch TFT display with Raspberry Pi Zero Wdevelopment board. Although Raspberry pi zero itself has an HDMI output that can be directly connected to a Monitor, but in projects where space is a constrain, we need smaller displays. This TFT touch screen display can be easily interfaced to the Raspberry Pi to display the system console, movies, and images, as well as control a relay board and other devices at your fingertips. We’ve used software like MobaXterm or putty to connect to the PC remotely in past tutorials. Here, we are going to use MobaXterm software to install the required drivers for interfacing TFT display with Raspberry Pi Zero W.
This TFT LCD display has a 3.5-inch resistive touch screen display and is compatible with any hardware of the Raspberry Pi family. This 3.5" TFT display has 480x320 pixels with a 16-bit resolution and resistive touch option. It can fit directly on top of the Raspberry Pi Zero W board and gets powered from the Vcc pin, the display communicates through SPI protocol with the Pi. Additionally, you can also use the HDMI port on the Pi to connect it to another display as well. It is designed for Raspberry Pi Zero/Pi 2 /Pi 3 Model B / B+ and can also be used on other hardware platforms which have SPI interfaces. The highlights of this display module is that it supports plug and play without rebooting the Pi and the SPI speed runs as fast as 32MHz to support games and videos.
There are 26 pins in TFT RPi LCD display. It"s used to establish SPI communication between the Raspberry Pi and the LCD, as well as to power the LCD from the Raspberry Pi"s 5V and 3.3V pins. The description of pins is shown below.
It is very easy to connect Raspberry Pi Zero W with a 3.5” TFT LCD display. There are 40 pins on the Raspberry Pi Zero W, but only 26 pins on the LCD, so make sure you connect the pins to your Pi correctly. A strip of female header pins on the LCD will fit snugly into the male header pins. To establish the connection, simply align the pins and press the LCD on top of the Raspberry Pi zero W. When everything is in place, your Pi and LCD should look like the one given below.
After you"ve connected the LCD to the Raspberry Pi Zero W and power on it, you"ll see a blank white screen on the LCD which is due to the fact that no drivers for the linked LCD have been installed on the Pi. So, open the Pi"s terminal window and start making the necessary adjustments. Here, we are going to use MobaXterm software for connecting Raspberry Pi Zero W but you can use PuTTY or any software which is most comfortable for you.
It"s expected that your Raspberry Pi already has an operating system installed and can connect to the internet. If it is not then you can follow our previous tutorial Getting Started with the RASPBERRY PI ZERO W – Headless Setup without Monitor. It"s also assumed that you have access to your Raspberry Pi"s terminal window. In this tutorial, we are going to use MobXterm in SSH mode to connect it with Raspberry Pi Zero W.
Step-2: In this step, we are going to enable SPI connection for Raspberry Pi Zero W. To enable SPI communication, select ‘Interface options’, and then select ‘SPI option’. Then click on "yes" to enable SPI interfacing.
Step-3: Now as we have enabled the SPI interfacing, in this step, we are going to install touch driver in our Raspberry Pi Zero W. You can install the touch drivers using the below command:
Step-4: After installing the touch driver use the below commands to proceed with further setup, here we are using chmod command to change the access mode of the file.
Step-5: Now, restart your Raspberry Pi Zero W. When the Raspberry Pi Zero W restarts, you will see the boot information on the LCD display before the desktop appears, as shown below.
I would like to add one thing at the end of this tutorial that while doing this interfacing, I faced a problem related to OS. TFT display interfacing with Raspberry Pi Zero W was not working on Raspberry Pi OS LiteandRaspberry Pi OS with desktopbut when I used the Raspberry Pi OS with desktop and recommended software then TFT display interfacing with Raspberry Pi Zero W worked as expected.
This is how you can interface Raspberry Pi Zero W with a 3.5 inch TFT Raspberry Pi display. In our next tutorials, we are going to interface different sensors with Raspberry Pi Zero and you will see some amazing DIY projects using Raspberry Pi Zero W. I Hope you"ve enjoyed the project and learned something useful. If you have any questions, please leave them in the comment section below or use our forum to start a discussion on the same.
※Price Increase NotificationThe TFT glass cell makers such as Tianma,Hanstar,BOE,Innolux has reduced or stopped the production of small and medium-sized tft glass cell from August-2020 due to the low profit and focus on the size of LCD TV,Tablet PC and Smart Phone .It results the glass cell price in the market is extremely high,and the same situation happens in IC industry.We deeply regret that rapidly rising costs for glass cell and controller IC necessitate our raising the price of tft display.We have made every attempt to avoid the increase, we could accept no profit from the beginning,but the price is going up frequently ,we"re now losing a lot of money. We have no choice if we want to survive. There is no certain answer for when the price would go back to the normal.We guess it will take at least 6 months until these glass cell and semiconductor manufacturing companies recover the production schedule. (Mar-03-2021)
ER-TFTV043A3-3 is 480x272 pixel 4.3 inch color tft lcd display for the Raspberry Pi with optional USB port resistive or capacitive touch panel screen,optional USB cable and HDMI cable. Of course ,it is not limited to the Raspberry Pi ,it can be used for all the universal HDMI port hardwares such as mini PCs, Raspberry Pi, BB Black, Banana Pi, as well as general desktop computers.
When works with Raspberry Pi, supports Raspbian, Ubuntu, WIN10 IOT, single touch and driver free.When work as a computer monitor, supports Windows 10/8.1/8/7, five-points touch, and driver free.Multi languages OSD menu for power management,.brightness and contrast adjustment, etc.
So, the HDMI and the GPIO are entirely unrelated. In a standard setup, the GPIO only controls the touch portion of the display, and is entirely optional. The HDMI controls the actual image on the actual LCD display itself. So, you can wire the HDMI without the GPIO at all anyway.
Now, if you are asking about how I directly wired the HDMI, I did the following. First, I removed both the LCD"s and the PI"s HDMI ports by using flush cutters to snip the mounting connectors, and then by heating up the tiny data pins so that the connector would release without damage to the board. Then, I used a wire diagram to wire up all of the HDMI pins on the PI to all of the HDMI pins on the display using some tiny magnet wire (32 guage). After that, I hot glued over the wires so that they wouldn"t be prone to damage. Please note that this is very difficult and it is extremely easy to damage either board while doing this. Shorts between pins are also very easy to make, so you will need a magnification lens just to see if there are shorts or not. Now, even though there are 19 connections on an HDMI connector, not all 19 are needed. The shielding connections, the CEC, and the NC pin are all not required for the HDMI signal to work.
This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.
One of the best features of the Rasp Pi is its graphics performance. Because of hardware acceleration, the Rasp Pi has gained areas of application that even much higher performance systems do not usually have. Not only is the graphical output good, but the small computer can silently work on its own as a headless server or control system.
Headless servers and control systems do not actually need a display screen. Sometimes, however, you might want to take a quick look at the current status or do a clean shutdown. These tasks can be performed remotely via SSH or a smartphone app, but they are easier to accomplish when a touchscreen has been connected. Likewise, other operations can benefit from real-life controls and the direct reporting of activities to the user.
A broad offering of touchscreens has become available for the Rasp Pi even for users who know nothing about soldering. For those who prefer a larger screen for something like a small jukebox, there is a 7-inch screen or larger. However, these screens usually need an additional board and their own power supply. Therefore, in this article, I focus on two smaller thin-film transistor (TFT) screens with a 2.8-inch format.
The Munich startup Pi3g [1] made just such a display screen available to us for testing. (See also the interview with Pi3g founder Maximilian Batz accompanying this article.) Pi3g offers the screen for US$ 70.68 (EUR 52) on its website. The second display screen comes from Watterott [2] and costs EUR 30.
Both screens have resistive displays that react to pressure instead of touch. This means that neither offers the comfort of modern smartphones, nor does either support multitouch. The resolution for each amounts to 320x240 pixels. When observed closely, the screen looks somewhat pixelated.
Together with the screen, Pi3g ships a small input stylus similar to the one that came with the first Palm models. The stylus makes using the screen much easier. An SD card that has been adapted to Raspbian is also included, because nothing runs without the driver (Figure 1). See the "Hunting for a Driver" box.
Both the Pi3g display and the Watterott display use a special framebuffer driver. The images provided include the applicable configuration together with the driver. The framebuffer of the display screen corresponds to the /dev/fb1 device. The first display device, /dev/fb0, operates the HDMI output that profits from the hardware acceleration of the GPU.
The mapping for fb1 to the first console (tty1) and from fb0 to the second (tty2) is achieved using the command-line parameters fbcon:map=10 from the cmdline.txt file. All consoles use the small display screen with fbcon:map=1. Only the first console displays boot messages.
The fbcp tool copies the content of /dev/fb0 every 25ms to /dev/fb1. This makes a fluid replay of video possible on the TFT screen using the standard Raspbian video player:
You will find additional fine points of the setup in the GitHub account of Watterott [4]. Their page also contains a number of links to technical information that may be of interest and is also applicable in a general sense to the screen from PiG3.
It is not possible to measure any additional power consumed by the display screen using simple measuring devices from a DIY store. However, usage can exceed the supply offered by a wobbly connection. A live view from something like a connected camera does not work because the rendering is transmitted via a CPU. At 10 percent, the amount of CPU used for driving the display screen is reasonable, and this also applies to the Watterott screen.
The Pi3g display appears a bit faster than the competition; however, this may result from serial scatter or perhaps a less than optimal configuration. This difference was only noticeable when playing videos in the absence of hardware acceleration. Note that the main task of the CPU is to reduce the video to a smaller format rather than display the results.
The TFT display screen can be connected via a short flat ribbon cable, which allows the hobbyist to mount the screen perpendicular to the computer. The cable is not a problem unless the user is seeking to achieve an especially compact setup. You can also swap out the cable without much problem.
The Watterott online shop primarily targets electronics hobbyists. Along with the Raspberry Pi and peripheral equipment, the shop offers single-drive computers. Surprisingly, a display screen that preceded the current 2.8-inch model is still available for purchase, and the shop offers larger screens as well.
Delivery from the shop was prompt (Figure 2). Unlike the Pi3G model, the Watterott screen does not need a cable. You simply plug it directly into the pin strip of the Raspberry Pi. The advantage here is that the Rasp Pi and the screen form a single unit that can be fitted with a housing – also available for purchase. The disadvantage is that you have less leeway in the assembly. First you will need to mount a Pi cam and then bend the cable with a sharp crease because the display screen covers up the camera connection.
Watterott adopts a more spartan approach than does Pi3g to including items with delivery of the screen. It has no preinstalled SD card, nor is the very useful input stylus included. On the other hand, you will pay significantly less. You can find the adapted Raspbian system and detailed documentation on GitHub [4]. The Watterott system has the same problems with updates that you will experience with Pi3g, and the solution is analog. See the "Hunting for a Driver" box.
The two displays differ in only very small ways in terms of technology. The Pi3g model uses a ILI9325 chipset with an ADS7843 touch controller. The Watterott model uses a ILI9341 chipset with an identical controller; however, the company could change feature details in the next round of production.
-Select-AfghanistanAlbaniaAlgeriaAmerican SamoaAndorraAngolaAnguillaAntigua and BarbudaArgentinaArmeniaArubaAustraliaAustriaAzerbaijan RepublicBahamasBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBoliviaBosnia and HerzegovinaBotswanaBrazilBritish Virgin IslandsBrunei DarussalamBulgariaBurkina FasoBurundiCambodiaCameroonCanadaCape Verde IslandsCayman IslandsCentral African RepublicChadChileChinaColombiaComorosCongo, Democratic Republic of theCongo, Republic of theCook IslandsCosta RicaCroatia, Republic ofCyprusCzech RepublicCôte d"Ivoire (Ivory Coast)DenmarkDjiboutiDominicaDominican RepublicEcuadorEgyptEl SalvadorEquatorial GuineaEritreaEstoniaEthiopiaFalkland Islands (Islas Malvinas)FijiFinlandFranceFrench GuianaFrench PolynesiaGabon RepublicGambiaGeorgiaGermanyGhanaGibraltarGreeceGreenlandGrenadaGuadeloupeGuamGuatemalaGuernseyGuineaGuinea-BissauGuyanaHaitiHondurasHong KongHungaryIcelandIndiaIndonesiaIraqIrelandIsraelItalyJamaicaJapanJerseyJordanKazakhstanKenyaKiribatiKorea, SouthKuwaitKyrgyzstanLaosLatviaLebanonLesothoLiberiaLibyaLiechtensteinLithuaniaLuxembourgMacauMacedoniaMadagascarMalawiMalaysiaMaldivesMaliMaltaMarshall IslandsMartiniqueMauritaniaMauritiusMayotteMexicoMicronesiaMoldovaMonacoMongoliaMontenegroMontserratMoroccoMozambiqueNamibiaNauruNepalNetherlandsNetherlands AntillesNew CaledoniaNew ZealandNicaraguaNigerNigeriaNiueNorwayOmanPakistanPalauPanamaPapua New GuineaParaguayPeruPhilippinesPolandPortugalPuerto RicoQatarReunionRomaniaRwandaSaint HelenaSaint Kitts-NevisSaint LuciaSaint Pierre and MiquelonSaint Vincent and the GrenadinesSan MarinoSaudi ArabiaSenegalSerbiaSeychellesSierra LeoneSingaporeSlovakiaSloveniaSolomon IslandsSomaliaSouth AfricaSpainSri LankaSurinameSwazilandSwedenSwitzerlandTaiwanTajikistanTanzaniaThailandTogoTongaTrinidad and TobagoTunisiaTurkeyTurkmenistanTurks and Caicos IslandsTuvaluUgandaUnited Arab EmiratesUnited KingdomUnited StatesUruguayUzbekistanVanuatuVatican City StateVenezuelaVietnamVirgin Islands (U.S.)Wallis and FutunaWestern SaharaWestern SamoaYemenZambiaZimbabwe
A simple 7.0″ High Brightness / Sunlight Readable IPS Module with HDMI / USB interface, Transmissive / All Viewing Direction / Normal Black with 1024 x (RGB) x 600 dots.
If none of these part numbers meet your requirements in terms of brightness, interface, or connection method, please email us at info@orientdisplay.com.
The official Raspberry Pi 7” Touchscreen allows you to add touch inputs to your programs, creating a new way to interact with your projects. It also makes for a fantastic desktop screen for day-to-day use of your Raspberry Pi. Wrap it in one of our screen cases and take it anywhere – events, Raspberry Jams or even just your friends house for a coding evening!
For smaller projects, LCD and ePaper displays are a fun way to add a visual element to your projects. With simple code and wiring, they’re great for projects that require text, menus and navigation.
I recently found a discount code through SlickDeals for $10 off the Elecrow 5" HDMI Touchscreen display for the Raspberry Pi. Since the Raspberry Pi was introduced, I"ve wanted to try out one of these mini screens (touchscreen or no), but they"ve always been prohibitively expensive (usually $60+).
This screen hit the right price (even regular price is $40, which is near my "okay for experimentation" range), and I picked it up, not knowing what to expect. I"ve had mixed experiences with Pi accessories from Amazon, and had never tried a product from Elecrow.
This review will walk through my experience connecting the Pi, getting the screen working correctly, getting the _touch_screen working correctly, and then how the whole system works with a Raspberry Pi 3. (See my separate Raspberry Pi 3 model B review).
The display is pretty solid, and comes well packed in styrofoam with four standoffs for mounting, a cheap plastic stylus, and a male-to-male HDMI daughter-card. Getting the Pi onto the board is easy enough; I used one standoff through one of the Pi"s mounting holes (on the side with the HDMI plug), then seated the Pi directly on top of the GPIO slot on the display board, so so the HDMI ports would line up perfectly on the other side.
After assembly, the entire unit is pretty solid; though due to all the exposed leads, I"d still recommend at least using something static-free and non-conductive to house the unit!
The Elecrow officially supports the Raspberry Pi 3 model B, but I tested it with a 2 model B as well. I didn"t try it with a B+, but the hardware layout should work, so at least the HDMI display would work correctly (not sure about the touchscreen controls). The way the hardware is laid out, you seat the Raspberry Pi directly onto a GPIO socket (it takes up the first 13 sets of GPIO pins—pins 1-26), and then there"s an included HDMI male-to-male daughtercard that slots in nicely to connect the HDMI output of the Pi to the HDMI input on the display.
There"s an extra OTG USB plug on the display if you want to give it a separate power source, but if you plug it straight into the Pi"s GPIO, it will leech off the 5V connection. As long as you have a good 2A power supply for your Pi, though, you shouldn"t have to worry about supplying independent power to the display. In my usage, I only saw the overvolt indicator every now and then (just like I do in normal usage of the Pi 3, since it uses a bit more power than a 2!).
When I first booted the Pi attached to the display, there was a large white area on the right, and only the left portion of the screen was being used by the Pi (it was only using 640x480 of the 800x480 display). To fix this, you have to set a few display options in the configuration file the Raspberry Pi reads during startup to switch certain hardware settings.
Edit /boot/config.txt (either while booted into Raspbian, or on another computer directly on the microSD card), making sure the following values are set:
Note: If the Pi boots up to a funny-looking screen and you can"t see anything, you can either reformat the microSD card, or pull it, edit the /boot/config.txt file from another computer to fix it, and put it back in the Pi.
Besides being a 800x480 HDMI display, the Elecrow also has a touchscreen overlay that allows simple one-point resistive touch detection on the screen. Note that at best, resistive touch is not nearly as responsive and intuitive as capacitive touch detection, which you"re likely used to on any recent smartphone or tablet screen. But something is better than nothing, when it comes to building simple UIs for "Internet of Things" devices or other fun things.
I tried to find some kind of downloadable driver for the XPT2046 touch controller, but didn"t find a lot of helpful information. Elecrow"s Wiki has some helpful information, a link to a setup PDF, a link to some configuration examples... but some of this seemed to be formatted incorrectly (likely due to bad copy/pasting or PDF formatting), so ignore that info and use this process instead (all commands run from the Terminal app):
These commands first install the touchscreen calibration utility, then configure the Pi to use the correct GPIO settings so touches can be interpreted as mouse moves/clicks by the Pi.
After you make those changes, reboot the Pi via the UI or in the Terminal with sudo reboot. Once it reboots, you need to calibrate the touchscreen. To do that, go to Menu > Preferences > Calibrate Touchscreen (see image below):
Once calibrated, the accuracy is pretty good, using either the included stylus or your fingernail. Note that the default Raspberry Pi UI is totally unoptimized for small (or even large) touchscreen use. You should probably get to work building your own touchscreen UI now :)
For ~$30 ($40 without discount), I wasn"t expecting a mind-blowing retina display with excellent glare-reducing coatings and contrast. But I do expect no dead pixels, and at least a crisp, vibrant picture when looking straight on. This screen is "good enough" in that regard, though viewing angles aren"t too great; side to side is okay, but looking down from above or up from below results in a bit of a washed out picture. Also, there is no antireflective coating on the screen, so wherever you use it, you need to be aware of nearby light sources.
So, to summarize the review: this is everything I expected out of a sub-$50 display. It"s nothing like a high-end smartphone display with capacitive touch, so if that"s what you"re expecting, you"ll have to look elsewhere. But if you just want a small display that mounts to the Pi easily and is more affordable than the Raspberry Pi Foundation"s own 7" touchscreen, this is a great buy!
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.
A hybrid of both Polled Mode SPI and DMA based transfers are utilized. Long sequential transfer bursts are performed using DMA, and when DMA would have too much latency, Polled Mode SPI is applied instead.
Undocumented BCM2835 features are used to squeeze out maximum bandwidth: SPI CDIV is driven at even numbers (and not just powers of two), and the SPI DLEN register is forced in non-DMA mode to avoid an idle 9th clock cycle for each transferred byte.
Good old interlacing is added into the mix: if the amount of pixels that needs updating is detected to be too much that the SPI bus cannot handle it, the driver adaptively resorts to doing an interlaced update, uploading even and odd scanlines at subsequent frames. Once the number of pending pixels to write returns to manageable amounts, progressive updating is resumed. This effectively doubles the maximum display update rate. (If you do not like the visual appearance that interlacing causes, it is easy to disable this by uncommenting the line #define NO_INTERLACING in file config.h)
A number of other micro-optimization techniques are used, such as batch updating rectangular spans of pixels, merging disjoint-but-close spans of pixels on the same scanline, and latching Column and Page End Addresses to bottom-right corner of the display to be able to cut CASET and PASET messages in mid-communication.
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.
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)
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.
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.
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:
-DFREEPLAYTECH_WAVESHARE32B=ON: If you are running on the Freeplay CM3 or Zero device, pass this flag. (this is not a hat, but still a preconfigured pin assignment)
-DPIRATE_AUDIO_ST7789_HAT=ON: If specified, targets a Pirate Audio 240x240, 1.3inch IPS LCD display HAT for Raspberry Pi with ST7789 display controller
-DKEDEI_V63_MPI3501=ON: If specified, targets a KeDei 3.5 inch SPI TFTLCD 480*320 16bit/18bit version 6.3 2018/4/9 display with MPI3501 display controller.
If you connected wires directly on the Pi instead of using a Hat from the above list, you will need to use the configuration directives below. In addition to specifying the display, you will also need to tell fbcp-ili9341 which GPIO pins you wired the connections to. To configure the display controller, pass one of:
-DILI9341=ON: If you are running on any other generic ILI9341 display, or on Waveshare32b display that is standalone and not on the FreeplayTech CM3/Zero device, pass this flag.
-DILI9340=ON: If you have a ILI9340 display, pass this directive. ILI9340 and ILI9341 chipsets are very similar, but ILI9340 doesn"t support all of the features on ILI9341 and they will be disabled or downgraded.
-DILI9486L=ON: If you have a ILI9486L display, pass this directive. Note that ILI9486 and ILI9486L are quite different, mutually incompatible controller chips, so be careful here identifying which one you have. (or just try both, should not break if you misidentified)
-DGPIO_TFT_DATA_CONTROL=number: Specifies/overrides which GPIO pin to use for the Data/Control (DC) line on the 4-wire SPI communication. This pin number is specified in BCM pin numbers. If you have a 3-wire SPI display that does not have a Data/Control line, set this value to -1, i.e. -DGPIO_TFT_DATA_CONTROL=-1 to tell fbcp-ili9341 to target 3-wire ("9-bit") SPI communication.
-DGPIO_TFT_RESET_PIN=number: Specifies/overrides which GPIO pin to use for the display Reset line. This pin number is specified in BCM pin numbers. If omitted, it is assumed that the display does not have a Reset pin, and is always on.
-DGPIO_TFT_BACKLIGHT=number: Specifies/overrides which GPIO pin to use for the display backlight line. This pin number is specified in BCM pin numbers. If omitted, it is assumed that the display does not have a GPIO-controlled backlight pin, and is always on. If setting this, also see the #define BACKLIGHT_CONTROL option in config.h.
fbcp-ili9341 always uses the hardware SPI0 port, so the MISO, MOSI, CLK and CE0 pins are always the same and cannot be changed. The MISO pin is actually not used (at the moment at least), so you can just skip connecting that one. If your display is a rogue one that ignores the chip enable line, you can omit connecting that as well, or might also be able to get away by connecting that to ground if you are hard pressed to simplify wiring (depending on the display).
To get good performance out of the displays, you will drive the displays far out above the rated speed specs (the rated specs yield about ~10fps depending on display). Due to this, you will need to explicitly configure the target speed you want to drive the display at, because due to manufacturing variances each display copy reaches a different maximum speed. There is no "default speed" that fbcp-ili9341 would use. Setting the speed is done via the option
-DSPI_BUS_CLOCK_DIVISOR=even_number: Sets the clock divisor number which along with the Pi core_freq= option in /boot/config.txt specifies the overall speed that the display SPI communication bus is driven at. SPI_frequency = core_freq/divisor. SPI_BUS_CLOCK_DIVISOR must be an even number. Default Pi 3B and Zero W core_freq is 400MHz, and generally a value -DSPI_BUS_CLOCK_DIVISOR=6 seems to be the best that a ILI9341 display can do. Try a larger value if the display shows corrupt output, or a smaller value to get higher bandwidth. See ili9341.h and waveshare35b.h for data points on tuning the maximum SPI performance. Safe initial value could be something like -DSPI_BUS_CLOCK_DIVISOR=30.
There are a couple of options to explicitly say which Pi board you want to target. These should be autodetected for you and generally are not needed, but e.g. if you are cross compiling for another Pi board from another system, or want to be explicit, you can try:
-DSINGLE_CORE_BOARD=ON: Pass this option if you are running on a Pi that has only one hardware thread (Pi Model A, Pi Model B, Compute Module 1, Pi Zero/Zero W). If not present, autodetected.
-DARMV8A=ON: Pass this option to specifically optimize for ARMv8-A instruction set (Pi 2B >= rev. 1.2, 3B, 3B+, CM3, CM3 lite, 4B, CM4, Pi400). If not present, autodetected.
-DBACKLIGHT_CONTROL=ON: If set, enables fbcp-ili9341 to control the display backlight in the given backlight pin. The display will go to sleep after a period of inactivity on the screen. If not, backlight is not touched.
-DDISPLAY_CROPPED_INSTEAD_OF_SCALING=ON: If set, and source video frame is larger than the SPI display video resolution, the source video is presented on the SPI display by cropping out parts of it in all directions, instead of scaling to fit.
-DDISPLAY_BREAK_ASPECT_RATIO_WHEN_SCALING=ON: When scaling source video to SPI display, scaling is performed by default following aspect ratio, adding letterboxes/pillarboxes as needed. If this is set, the stretching is performed breaking aspect ratio.
-DSTATISTICS=number: Specifies the level of overlay statistics to show on screen. 0: disabled, 1: enabled, 2: enabled, and show frame rate interval graph as well. Default value is 1 (enabled).
-DUSE_DMA_TRANSFERS=OFF: If specified, disables using DMA transfers (at great expense of lost CPU usage). Pass this directive if DMA is giving some issues, e.g. as a troubleshooting step if something is not looking right.
-DDISPLAY_SWAP_BGR=ON: If this option is passed, red and blue color channels are reversed (RGB<->BGR) swap. Some displays have an opposite color panel subpixel layout that the display controller does not automatically account for, so define this if blue and red are mixed up.
-DDISPLAY_INVERT_COLORS=ON: If this option is passed, pixel color value interpretation is reversed (white=0, black=31/63). Default: black=0, white=31/63. Pass this option if the display image looks like a color negative of the actual colors.
-DLOW_BATTERY_PIN=
In addition to the above CMake directives, there are various defines scattered around the codebase, mostly in config.h, that control different runtime options. Edit those directly to further tune the behavior of the program. In particular, after you have finished with the setup, you may want to build with -DSTATISTICS=0 option in CMake configuration line.
Here is a full example of what to type to build and run, if you have the Adafruit 2.8" 320x240 TFT w/ Touch screen for Raspberry Pi with ILI9341 controller:
If the above does not work, try specifying -DSPI_BUS_CLOCK_DIVISOR=8 or =10 to make the display run a little slower, or try with -DUSE_DMA_TRANSFERS=OFF to troubleshoot if DMA might be the issue. If you are using another display controller than ILI9341, using a much higher value, like 30 or 40 may be needed. When changing CMake options, you can reissue the CMake directive line without having to reclone or recreate the build directory. However you may need to manually delete file CMakeCache.txt between changing options to avoid CMake remembering old settings.
If you want to do a full rebuild from scratch, you can rm -rf build to delete the build directory and recreate it for a clean rebuild from scratch. There is nothing special about the name or location of this directory, it is just my usual convention. You can also do the build in some other directory relative to the fbcp-ili9341 directory if you please.
If the user name of your Raspberry Pi installation is something else than the default pi, change the directory accordingly to point to the user"s home directory. (Use pwd to find out the current directory in terminal)
If the size of the default HDMI output /dev/fb0 framebuffer differs from the resolution of the display, the source video size will by default be rescaled to fit to the size of the SPI display. fbcp-ili9341 will manage setting up this rescaling if needed, and it will be done by the GPU, so performance should not be impacted too much. However if the resolutions do not match, small text will probably appear illegible. The resizing will be done in aspect ratio preserving manner, so if the aspect ratios do not match, either horizontal or vertical black borders will appear on the display. If you do not use the HDMI output at all, it is probably best to configure the HDMI output to match the SPI display size so that rescaling will not be needed. This can be done by setting the following lines in /boot/config.txt:
These lines hint native applications about the default display mode, and let them render to the native resolution of the TFT display. This can however prevent the use of the HDMI connector, if the HDMI connected display does not support such a small resolution. As a compromise, if both HDMI and SPI displays want to be used at the same time, some other compatible resolution such as 640x480 can be used. See Raspberry Pi HDMI documentation for the available options to do this.
The refresh speed of the display is dictated by the clock speed of the SPI bus that the display is connected to. Due to the way the BCM2835 chip on Raspberry Pi works, there does not exist a simple speed=xxx Mhz option that could be set to define the bus speed. Instead, the SPI bus speed is derived from two separate parameters: the core frequency of the BCM2835 SoC in general (core_freq in /boot/config.txt), and the SPI peripheral CDIV (Clock DIVider) setting. Together, the resulting SPI bus speed is then calculated with the formula SPI_speed=core_freq/CDIV.
Adjust the CDIV value by passing the directive -DSPI_BUS_CLOCK_DIVISOR=number in CMake command line. Possible values are even numbers 2, 4, 6, 8, .... Note that since CDIV appears in the denominator in the formula for SPI_speed, smaller values result in higher bus speeds, whereas higher values make the display go slower. Initially when you don"t know how fast your display can run, try starting with a safe high setting, such as -DSPI_BUS_CLOCK_DIVISOR=30, and work your way to smaller numbers to find the maximum speed the display can cope with. See the table at the end of the README for specific observed maximum bus speeds for different displays.
Ensure turbo speed. This is critical for good frame rates. On the Raspberry Pi 3 Model B, the BCM2835 core runs by default at 400MHz (resulting in 400/CDIV MHz SPI speed) if there is enough power provided to the Pi, and if the CPU temperature does not exceed thermal limits. If the CPU is idle, or voltage is low, the BCM2835 core will instead revert to non-turbo 250MHz state, resulting in 250/CDIV MHz SPI speed. This effect of turbo speed on performance is significant, since 400MHz vs non-turbo 250MHz comes out to +60% of more bandwidth. Getting 60fps in Quake, Sonic or Tyrian often requires this turbo frequency, but e.g. NES and C64 emulated games can often reach 60fps even with the stock 250MHz. If for some reason under-voltage protection is kicking in even when enough power should be fed, you can force-enable turbo when low voltage is present by setting the value avoid_warnings=2 in the file /boot/config.txt.
Perhaps a bit counterintuitively, underclock the core. Setting a smaller core frequency than the default turbo 400MHz can enable using a smaller clock divider to get a higher resulting SPI bus speed. For example, if with default core_freq=400 SPI CDIV=8 works (resulting in SPI bus speed 400MHz/8=50MHz), but CDIV=6 does not (400MHz/6=66.67MHz was too much), you can try lowering core_freq=360 and set CDIV=6 to get an effective SPI bus speed of 360MHz/6=60MHz, a middle ground between the two that might perhaps work. Balancing core_freq= and CDIV options allows one to find the maximum SPI bus speed up to the last few kHz that the display controller can tolerate. One can also try the opposite direction and overclock, but that does then of course have all the issues that come along when overclocking. Underclocking does have the drawback that it makes the Pi run slower overall, so this is certainly a tradeoff.
On the other hand, it is desirable to control how much CPU time fbcp-ili9341 is allowed to use. The default build settings are tuned to maximize the display refresh rate at the expense of power consumption on Pi 3B. On Pi Zero, the opposite is done, i.e. by default the driver optimizes for battery saving instead of maximal display update speed. The following options can be controlled to balance between these two:
The main option to control CPU usage vs performance aspect is the option #define ALL_TASKS_SHOULD_DMA in config.h. Enabling this option will greatly reduce CPU usage. If this option is disabled, SPI bus utilization is maximized but CPU usage can be up to 80%-120%. When this option is enabled, CPU usage is generally up to around 15%-30%. Maximal CPU usage occurs when watching a video, or playing a fast moving game. If nothing is changing on the screen, CPU consumption of the driver should go down very close to 0-5%. By default #define ALL_TASKS_SHOULD_DMA is enabled for Pi Zero, but disabled for Pi 3B.
The CMake option -DUSE_DMA_TRANSFERS=ON should always be enabled for good low CPU usage. If DMA transfers are disabled, the driver will run in Polled SPI mode, which generally utilizes a full dedicated single core of CPU time. If DMA transfers are causing issues, try adjusting the DMA send and receive channels to use for SPI communication with -DDMA_TX_CHANNEL=
The statistics overlay prints out quite detailed information about execution state. Disabling the overlay with -DSTATISTICS=0 option to CMake improves performance and reduces CPU usage. If you want to keep printing statistics, you can try increasing the interval with the #define STATISTICS_REFRESH_INTERVAL
Enabling #define USE_GPU_VSYNC reduces CPU consumption, but because of raspberrypi/userland#440 can cause stuttering. Disabling #defined USE_GPU_VSYNC produces less stuttering, but because of raspberrypi/userland#440, increases CPU power consumption.
The option #define SELF_SYNCHRONIZE_TO_GPU_VSYNC_PRODUCED_NEW_FRAMES can be used in conjunction with #define USE_GPU_VSYNC to try to find a middle ground between raspberrypi/userland#440 issues - moderate to little stuttering while not trying to consume too much CPU. Try experimenting with enabling or disabling this setting.
There are a number of #define SAVE_BATTERY_BY_x options in config.h, which all default to being enabled. These should be safe to use always without tradeoffs. If you are experiencing latency or performance related issues, you can try to toggle these to troubleshoot.
If your SPI display bus is able to run really fast in comparison to the size of the display and the amount of content changing on the screen, you can try enabling #define UPDATE_FRAMES_IN_SINGLE_RECTANGULAR_DIFF option in config.h to reduce CPU usage at the expense of increasing the number of bytes sent over the bus. This has been observed to have a big effect on Pi Zero, so is worth checking out especially there.
If the SPI display bus is able to run really really really fast (or you don"t care about frame rate, but just about low CPU usage), you can try enabling #define UPDATE_FRAMES_WITHOUT_DIFFING option in config.h to forgo the adaptive delta diffing option altogether. This will revert to naive full frame updates for absolutely minimum overall CPU usage.
The option #define RUN_WITH_REALTIME_THREAD_PRIORITY can be enabled to make the driver run at realtime process priority. This can lock up the system however, but still made available for advanced experimentation.
In display.h there is an option #define TARGET_FRAME_RATE
A pleasing aspect of fbcp-ili9341 is that it introduces very little latency overhead: on a 119Hz refreshing ILI9341 display, fbcp-ili9341 gets pixels as response from GPIO input to screen in well less than 16.66 msecs time. I only have a 120fps recording camera, so can"t easily measure delays shorter than that, but rough statistical estimate of slow motion video footage suggests this delay could be as low as 2-3 msecs, dominated by the ~8.4msecs panel refresh rate of the ILI9341.
This does not mean that overall input to display latency in games would be so immediate. Briefly testing a NES emulated game in Retropie suggests a total latency of about 60-80 msecs. This latency is caused by the NES game emulator overhead and extra latency added by Linux, DispmanX and GPU rendering, and GPU framebuffer snapshotting. (If you ran fbcp-ili9341 as a static library bypassing DispmanX and the GPU stack, directly linking your GPIO input and application logic into fbcp-ili9341, you would be able to get down to this few msecs of overall latency, like shown in the above GPIO input video)
Interestingly, fbcp-ili9341 is about ~33msecs faster than a cheap 3.5" KeDei HDMI display. I do not know if this is a result of the KeDei HDMI display specifically introducing extra latency, or if all HDMI displays connected to the Pi would have similar latency overhead. An interesting question is also how SPI would compare with DPI connected displays on the Pi.
Unfortunately a limitation of SPI connected displays is that the VSYNC line signal is not available on the display controllers when they are running in SPI mode, so it is not possible to do vsync locked updates even if the SPI bus bandwidth on the display was fast enough. For example, the 4 ILI9341 displays I have can all be run faster than 75MHz so SPI bus bandwidth-wise all of them would be able to update a full frame in less than a vsync interval, but it is not possible to synchronize the updates to vsync since the display controllers do not report it. (If you do know of a display that does actually expose a vsync clock signal even in SPI mode, you can try implementing support to locking on to it)
You can however choose between two distinct types of tearing artifacts: straight line tearing and diagonal tearing. Whichever looks better is a bit subjective, which is why both options exist. I prefer the straight line tearing artifact, it seems to be less intrusive than the diagonal tearing one. To toggle this, edit the option #define DISPLAY_FLIP_ORIENTATION_IN_SOFTWARE in config.h. When this option is enabled, fbcp-ili9341 produces straight line tearing, and consumes a tiny few % more CPU power. By default Pi 3B builds with straight line tearing, and Pi Zero with the faster diagonal tearing. Check out the video Latency and tearing test #2: GPIO input to display latency in fbcp-ili9341 and tearing modes to see in slow motion videos how these two tearing modes look like.
Another option that is known to affect how the tearing artifact looks like is the internal panel refresh rate. For ILI9341 displays this refresh rate can be adjusted in ili9341.h, and this can be set to range between ILI9341_FRAMERATE_61_HZ and ILI9341_FRAMERATE_119_HZ (default). Slower refresh rates produce less tearing, but have higher input-to-display latency, whereas higher refresh rates will result in the opposite. Again visually the resulting effect is a bit subjective.
To get tearing free updates, you should use a DPI display, or a good quality HDMI display. Beware that cheap small 3.5" HDMI displays such as KeDei do also tear - that is, even if they are controlled via HDMI, they don"t actually seem to implement VSYNC timed internal operation.
Having no vsync is not all bad though, since with the lack of vsync, SPI displays have the opportunity to obtain smoother animation on content that is not updating at 60Hz. It is possible that content on the SPI display will stutter even less than what DPI or HDMI displays on the Pi can currently provide (although I have not been able to test this in detail, except for the KeDei case above).
The main option that affects smoothness of display updates is the #define USE_GPU_VSYNC line in config.h. If this is enabled, then the internal Pi GPU HDMI vsync clock is used to drive frames onto the display. The Pi GPU clock runs at a fixed rate that is independent of the content. This rate can be discovered by running tvservice -s on the Pi console, and is usually 59Hz or 60Hz. If your application renders at this rate, animation will look smooth, but if not, there will be stuttering. For example playing a PAL NES game that updates at 50Hz with HDMI clock set at 60Hz will cause bad microstuttering in video output if #define USE_GPU_VSYNC is enabled.
If USE_GPU_VSYNC is disabled, then a busy spinning GPU frame snapshotting thread is used to drive the updates. This will produce smoother animation in content that does not maintain a fixed 60Hz rate. Especially in OpenTyrian, a game that renders at a fixed 36fps and has slowly scrolling scenery, the stuttering caused by USE_GPU_VSYNC is particularly visible. Running on Pi 3B without USE_GPU_VSYNC enabled produces visually smoother looking scrolling on an Adafruit 2.8" ILI9341 PiTFT set to update at 119Hz, compared to enabling USE_GPU_VSYNC on the same setup. Without USE_GPU_VSYNC, the dedicated frame polling loop thread "finds" the 36Hz update rate of the game, and then pushes pixels to the display at this exact rate. This works nicely since SPI displays disregard vsync - the result is that frames are pushed out to the SPI display immediately as they become available, instead of pulling them at a fixed 60Hz rate like HDMI does.
A drawback is that this kind of polling consumes more CPU time than the vsync option. The extra overhead is around +34% of CPU usage compared to the vsync method. It also requires using a background thread, and because of this, it is not feasible to be used on a single core Pi Zero. If this polling was unnecessary, this mode would also work on a Pi Zero, and without the added +34% CPU overhead on Pi 3B. See the Known Issues section below for more details.
There are two other main options that affect frame delivery timings, #define SELF_SYNCHRONIZE_TO_GPU_VSYNC_PRODUCED_NEW_FRAMES and #define SAVE_BATTERY_BY_PREDICTING_FRAME_ARRIVAL_TIMES. Check out the video fbcp-ili9341 frame delivery smoothness test on Pi 3B and Adafruit ILI9341 at 119Hz for a detailed side by side comparison of these different modes. The conclusions drawn from the four tested scenarios in the video are:
2. vc_dispmanx_vsync_callback() + self synchronization (top right), set #define USE_GPU_VSYNC and #define SELF_SYNCHRONIZE_TO_GPU_VSYNC_PRODUCED_NEW_FRAMES:
This mode uses the GPU vsync signal, but also aims to find and synchronize to the edge trigger when content is producing frames. This is the default build mode on Pi Zero.
The codebase captures screen framebuffers by snapshotting via the VideoCore vc_dispmanx_snapshot() API, and the obtained pixels are then routed on to the SPI-based display. This kind of polling is performed, since there does not exist an event-based mechanism to get new frames from the GPU as they are produced. The result is inefficient and can easily cause stuttering, since different applications produce frames at different paces. Ideally the code would ask the VideoCore API to receive finished frames in callback notifications immediately after they are rendered, but this kind of functionality does not exist in the current GPU driver stack. In the absence of such event delivery mechanism, the code has to resort to polling snapshots of the display framebuffer using carefully timed heuristics to balance between keeping latency and stuttering low, while not causing excessive power consumption. These heuristics keep continuously guessing the update rate of the animation on screen, and they have been tuned to ensure that CPU usage goes down to 0% when there is no detected activity on screen, but it is certainly not perfect. This GPU limitation is discussed at raspberrypi/userland#440. If you"d like to see fbcp-ili9341 operation reduce latency, stuttering and power consumption, please throw a (kind!) comment or a thumbs up emoji in that bug thread to share that you care about this, and perhaps Raspberry Pi engineers might pick the improvement up on the development roadmap. 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.
Currently if one resizes the video frame size at runtime, this causes DispmanX API to go sideways. See raspberrypi/userland#461 for more information. Best workaround is to set the desired screen resolution in /boot/config.txt and configure all applications to never change that at runtime.
The speed of the SPI bus is linked to the BCM2835 core frequency. This frequency is at 250MHz by default (on e.g. Pi Zero, 3B and 3B+), and under CPU load, the core turbos up to 400MHz. This turboing directly scales up the SPI bus speed by 400/250=+60% as well. Therefore when choosing the SPI CDIV value to use, one has to pick one that works for both idle and turbo clock speeds. Conversely, the BCM core reverts to non-turbo speed when there is only light CPU load active, and this slows down the display, so if an application is graphically intensive but light on CPU, the SPI display bus does not get a chance to run at maximum speeds. A way to work around this is to force the BCM core to always stay in its turbo state with force_turbo=1 option in /boot/config.txt, but this has an unfortunate effect of causing the ARM CPU to always run in turbo speed as well, consuming excessive amounts of power. At the time of writing, there does not yet exist a good solution to have both power saving and good performance. This limitation is being discussed in more detail at raspberrypi/firmware#992.
At the moment fbcp-ili9341 is only likely to work on 32-bit OSes, on Raspbian/Ubuntu/Debian family of distributions, where Broadcom and DispmanX libraries are available. 64-bit operating systems do not currently work (see issue #43). It should be possible to port the driver to 64-bit and other OSes, though the amount of work has not been explored.
By default fbcp-ili9341 builds with a statistics overlay enabled. See the video fbcp-ili9341 ported to ILI9486 WaveShare 3.5" (B) SpotPear 320x480 SPI display to find details on what each field means. Build with CMake option -DSTATISTICS=0 to disable displaying the statistics. You can also try building with CMake option -DSTATISTICS=2 to show a more detailed frame delivery timings histogram view, see screenshot and video above.
The fbcp part in the name means framebuffer copy; specifically for the ILI9341 controller. fbcp-ili9341 is not actually a framebuffer copying driver, it does not create a secondary framebuffer that it would copy bytes across to from the primary framebuffer. It is also no longer a driver only for the ILI9341 controller. A more appropriate name might be userland-raspi-spi-display-driver or something like that, but the original name stuck.
Yes, it does, although not quite as well as on Pi 3B. If you"d like it to run better on a Pi Zero, leave a thumbs up at raspberrypi/userland#440 - hard problems are difficult to justify prioritizing unless it is known that many people care about them.
Edit the file config.h and comment out the line #define DISPLAY_OUTPUT_LANDSCAPE. This will make the display output in portrait mode, effectively rotating it by 90 degrees. Note that this only affects the pixel memory reading mode of the display. It is not possible to change the panel scan order to run between landscape and portrait, the SPI displays typically always scan in portrait mode. The result is that it will change the panel vsync tearing mode from "straight line tearing" over to "diagonal tearing" (see the section About Tearing above).
If you do not want to have diagonal tearing, but would prefer straight line tearing, then additionally enable the option #define DISPLAY_FLIP_ORIENTATION_IN_SOFTWARE in config.h. That will restore straight line tearing, but it will also increase overall CPU consumption.
Enable the option #define DISPLAY_ROTATE_180_DEGREES in config.h. This should rotate the SPI display to show up the other way around, while keeping the HDMI connected display orientation unchanged. Another option is to utilize a /boot/config.txt option display_rotate=2, which rotates both the SPI output and the HDMI output.
Note that the setting DISPLAY_ROTATE_180_DEGREES only affects the pixel memory reading mode of the display. It is not possible to flip the panel scan to run inverted by 180 degrees. This means that adjusting these settings will also have effects of changing the visual appearance of the vsync tearing artifact. If you have the ability to mount the display 180 degrees around in your project, it is recommended to do that instead of using the DISPLAY_ROTATE_180_DEGREES option.
Edit the file config.h in a text editor (a command line one such as pico, vim, nano, or SSH map the drive to your host), and find the appropriate line in the file. Add comment lines // in front of that text to disable the option, or remove the // characters to enable it.
Some options are passed to the build from the CMake configuration script. You can run with make VERBOSE=1 to see which configuration items the CMake build is passing. See the above Configuring Build Options section to customize the CMake configure items. For example, to remove the statistics overlay, pass -DSTATISTICS=0 directive to CMake.
Yes, both work fine. For linux command line terminal, the /dev/tty1 console should be set to output to Linux framebuffer 0 (/dev/fb0). This is the default mode of operation and there do not exist other framebuffers in a default distribution of Raspbian, but if you have manua
Ms.Josey 
Ms.Josey