configuring raspberry pi without tft display price

However, this is no longer required as newer versions of Raspbian provide it by default. This information has been compiled from that provided here and here.

There is a specific way in which the display must be connected to the pi. This detail is provided in the rpi-display overlay in the /boot/overlays folder.

In the rpi-display@0 section you will see details of pin numbers. The numbers provided here are in hex format. You will need to convert them to decimal.

For example, the RESET pin is labelled to connect to number 17 in hex, which is 23 in decimal. This 23 corresponds to BCM / GPIO 23. Which is pin 16 counted from the top left, row-wise. You can use the following command to convert to decimal from the command line.

The first part maps the boot console to frame buffer 1. Then we change the font to a small size and remove the raspberries that appear on the top left of the screen while booting. Reboot and you should see the console appear on your screen. If you have an external HDMI screen plugged in while doing this, you will notice that the boot messages appear on the TFT. The HDMI display goes to the splash screen and desktop after booting.

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-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.

Give the name "Raspberry connection", go to IPv4 settings and select "shared with other computers". Save, close and connect an ethernet cable between the RPi and the PC.

WARNING: after next commands you will not see the Raspberry on the HDMI monitor, so if PuTTY or Remmina are not working you will not be able to see the terminal or desktop of your Raspberry.

Hey guys , i am sharing the super easy way to install raspberry pi 3.5 inch LCD. You can install your LCD in few seconds just follow the step in this video: https://youtu.be/Fj3wq98pd20

The quick method on Youtube works like a charm for me and my 3.5" display is great using the stylus supplied. However I have a problem. I want to use an 8GB SD card to setup my rpi as a Kodi Box, but as this is a new operating system install, it will revert to needing a monitor, keyboard and mouse and my little touchscreen is ignored. This would be fine it I could use Terminal to setup the 3.5" screen, but neither of the NOOBS options for Kodi allow a direct interface. So, does anyone know of a Kodi install that allows a terminal interface, or is pre-loaded to include the 3.5" screen?

Now I want to do something else with my Raspberry. I removed the touchscreen, attached a standard monitor (one that worked before the install of the touchscreen) and inserted a SD card with NOOBS. The system starts but the resolution is bad and the screen is constantly flashing.

Now I want to do something else with my Raspberry. I removed the touchscreen, attached a standard monitor (one that worked before the install of the touchscreen) and inserted a SD card with NOOBS. The system starts but the resolution is bad and the screen is constantly flashing.

There is no means of saving changes on the Raspberry Pi SBC itself, probably best to start with a new post about your issues as they are not related to previously using a XPT2046 Touch Screen

Now I want to do something else with my Raspberry. I removed the touchscreen, attached a standard monitor (one that worked before the install of the touchscreen) and inserted a SD card with NOOBS. The system starts but the resolution is bad and the screen is constantly flashing.

There is no means of saving changes on the Raspberry Pi SBC itself, probably best to start with a new post about your issues as they are not related to previously using a XPT2046 Touch Screen

This works perfectly for me on the new "2020-05-27-raspios-buster-armhf" image however when I do "apt-get upgrade" it updates the following packages and after rebooting it does not work anymore. I have replicated it several times by doing a fresh install, one of the upgraded packages seems to break it.

libjavascriptcoregtk-4.0-18 libnss3 libopenmpt-modplug1 libopenmpt0 libpostproc55 libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc libraspberrypi0 libswresample3 libswscale5 libvlc-bin libvlc5 libvlccore9 libwebkit2gtk-4.0-37 lxpanel lxpanel-data lxplug-bluetooth lxplug-network lxplug-ptbatt

lxplug-volume pcmanfm pi-greeter pi-package pi-package-data pi-package-session piclone pipanel piwiz pprompt raspberrypi-bootloader raspberrypi-kernel raspberrypi-ui-mods raspi-config realvnc-vnc-server rp-bookshelf rp-prefapps rpi-chromium-mods rpi-eeprom rpi-eeprom-images vlc vlc-bin vlc-data vlc-l10n

I have the same display, and have had the same issue. Works fine with a 4.x kernel, but the upgrade to 5.4 renders it useless. Just a white screen on boot.

I only use my display for text (no graphical desktop) so I"ve not tested that but there"s no reason to believe it isn"t going to work. The last 2 lines will add the SPI and overlay parameters to the config.txt and add the boot console bits to the cmdline.txt

gpio = "/fragment@1:target:0", "/fragment@2/__overlay__/tft35a@0:reset-gpios:0", "/fragment@2/__overlay__/tft35a@0:dc-gpios:0", "/fragment@2/__overlay__/tft35a-ts@1:interrupt-parent:0", "/fragment@2/__overlay__/tft35a-ts@1:pendown-gpio:0";

fixup = "/fragment@2/__overlay__/tft35a@0:pinctrl-0:0", "/__overrides__:speed:0", "/__overrides__:txbuflen:0", "/__overrides__:rotate:0", "/__overrides__:fps:0", "/__overrides__:bgr:0", "/__overrides__:debug:0", "/__overrides__:swapxy:0";

[ 44.756917] fb_ili9486 spi0.0: fbtft_write_spi(len=15360): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...

The TFT isn’t ‘plug & play’ with the Raspberry, a patch has to be applied to the kernel to be able to interface via SPI with the ST7735R controller chip on the TFT. Once working, the display will act as a framebuffer device.

As it takes over three hours to compile the kernel on the PI, I will show how to cross compile from another Linux PC. In my case, it is Ubuntu 12.10 running within VMWare on a Windows 7 Quad core PC. Kernel compile time is 15 mins.

-Copy config from the Raspberry Pi to the Ubuntu box using SCP. Replace ‘raspberrypi’ below with the IP address of your Raspberry Pi if hostname lookup fails.

If you are planning on displaying the console on the TFT, then enabling these options in .config will allow you to change the font size and rotate the display later on.

To enable parallel processing for a faster compile. If you have a dual core processor add -j 3 to the end of the command below. If you have quad core, add -j 6

The last step below is to SCP the files from from Ubuntu to the Raspberry Pi. If you have trouble SCPing into your Ubuntu box you may need to install open SSH on Ubuntu with sudo apt-get install openssh-server. This step also copies the files from my home folder ‘mark’… yours would be different.

If you build the st7735 driver pair as built-in, add these options to the end of the line in /boot/cmdline.txt. This will display the console on the TFT.

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.

Raspberry Pi has become the first choice for makers because of its compact size, low price, free and diverse software, and community resources. Although the original intention of Raspberry Pi is to assist students in computer science learning, the rapid progress of open-source software such as Linus and Python has led to many Raspberry Pi enthusiasts creating their own robots, servers, IOT devices, Industrial equipment networking devices, or even supercomputers by connecting multiple Raspberry Pi.

When using the Raspberry Pi as a server or industrial monitoring device, it is naturally inevitable to be combined with a touch screen. This article will explain in detail how to connect an external capacitive touch monitor with Raspberry Pi, and execute the touch calibration program to obtain more sensitive and precise touch operation.

Understanding that many people have problems configuring their Kuman TFT display on the Raspberry Pi together with RetroPie, I have decided to make this step-by-step of how to install the Kuman TFT 3.5" display which you can connect directly to the GPIO ports of the Raspberry Pi and run your applications. A lot of people have been buying this Kuman display from Amazon and other online markets for its economical price but it is not an easy display to install for certain applications, compared to other displays that come with integrated HDMI ports that will surely be a lot easier to manipulate and start working.

I advise you to buy a GPIO cable or a ribbon cable to connect the display to the Raspberry Pi, because sometimes (and it happened to me) at the time of manipulating the display and fitting it on the pins of the Raspberry, the screen being so the thin can be broken easily.

Verify that you have RetroPie burn on your SD Card, if you have not already done so, click on the following link, install it and come back here to continue the steps.

Step Three: Connect to the Raspberry Pi via SSHTurn on your Raspberry Pi and make sure it is connected to Internet.Go to RetroPie settings, then RaspConfig and turn on SSH.You can use your preferred ssh client as Putty, WinSCP or in my case I will use Terminal in my MAC to connect to the Raspberry Pi.

Next, copy the following code to download the best driver from Github:git clone https://github.com/goodtft/LCD-show.gitchmod -R 755 LCD-showcd LCD-show/chmod +x LCD35­-show./LCD35­-show

If, after installing, the screen is a mess together with the TV missing icons or words, please connect via SSH to your Raspberry Pi and run this command:cd RetroPie­-Setup/sudo ./retropie­-setup.sh

If you start to play you will notice that the game is not very fluid on your screen, the way to fix this is by making some changes at the Config File. Remember to connect via ssh to your Raspberry Pi to run this command:sudo nano /boot/config.txt

The previous command will open the Retropie configuration file where in the end you have to look for something like SPEED and FPS and change the values to something like:dtparam=audio=ondtoverlay=tft35a,speed=62000000,fps=40,rotate=90#dtoverlay=ads7846,cs=1,penirq=17,penirq_pull=2,speed=25000000,fps=20,keep_vref$gpu_mem_256=128gpu_mem_512=256gpu_mem_1024=256overscan_scale=1

One thing I’ve learned over and over from working on the Raspberry Pi is that it’s most likely going to take a chunk of time to get things set up just the way you want.  And this display is no different.

I’ve written in the past about How to Play HD Video on a Raspberry Pi — so this is a continuation from a Raspbian Linux distribution image already in that state.  I was feeling lazy and didn’t want to write this post, but if I ever have to do this again I don’t want to have to google so many steps again.  So hopefully you’ll find this useful as well.

First I tried the instructions from here: Adafruit: Detailed Installation before realizing the available manual has an auto-configure option.  But I couldn’t get these working at first because the Debian package mirrors wouldn’t work so I had to modify my apt sources list to use some working mirrors. The download of the adafruit-pitft-helper package was still unavailable to me via apt but you can get it from Github.

You need to run this script adafruit-pitft-helper specifically to enable the console on your display.  The manual instructions on their website do not tell you how to do this, only for enabling the display for the graphical interface X11.  This script does the heavy lifting.

At this point the terminal is all set for your display.  Following this I will show you how to enable high definition video playback on your TFT display from the command line.  I won’t go into setting up the touchscreen for the X11 desktop, you can refer to the manual for that.  Personally I don’t think the Raspberry Pi makes a good desktop system as it’s slow, I much prefer the console.

If you try the omxplayer from the previous blog post you’ll find the video doesn’t show up on the display.  The reason is that it’s rendering on frame buffer 0 when the TFT is using frame buffer 1.  To get around this you need to use frame buffer copying with the fbcp program.  The instructions they provide are close but don’t follow the second modprobe command (as it messed up my display).

Now when you want to play a video you type omx myvideo.mp4 and it switches to frame buffer copying, plays the video given as the first parameter with omxplayer (taking advantage of GPU high speed graphics), after omxplayer exits fbcp is closed out with the killall command, we then clear the display of any visual artifacts left behind and we’re back to where we need to be with a nice looking display!

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.

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.

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.

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!

The 3.5 inch LCD Display is directly pluggable into a Raspberry Pi and perfectly fits various Pi models from B+ to Raspberry Pi 3B+. It is a brilliant alternative for an HDMI monitor. When set up, it behaves as a human-machine interface enabling the user to prototype with the Raspberry Pi device anywhere at any time.

I have an old car DVD player sitting around that has a fairly decent secondary TFT LCD screen (hannstar 721h440b19-a1) that I thought I could use with my Raspberry Pi 3 Model B.

I opened up the unit, and the issue I"m running into is that the control board receives the video, power and audio signal all through a single USB connection. I was curious if there was a simple way to get the display to work with my raspberry pi with the least amount of hacking to the control board. Is there a way to pass video through USB on the Pi? Or could I desolder the USB connection and run wiring for power, video, and audio separately?

A number of people have used a Motorola Atrix Lapdock to add a screen and keyboard with trackpad to RasPi, in essence building a RasPi-based laptop computer. Lapdock is a very clever idea: you plug your Atrix smart phone into Lapdock and it gives you an 11.6" 1366 x 768 HDMI monitor with speakers, a keyboard with trackpad, two USB ports, and a large enough battery for roughly 5 hours of use. The smart phone acts as a motherboard with "good enough" performance. The advantage over a separate laptop or desktop computer is that you have one computing device so you don"t need to transfer files between your phone and your desk/laptop.

Unfortunately for Motorola, Lapdock was not successful (probably because of its US$500 list price) and Motorola discontinued it and sold remaining stock at deep discounts, with many units selling for US$50-100. This makes it a very attractive way to add a modest size HDMI screen to RasPi, with a keyboard/trackpad and rechargeable battery power thrown in for free.

Lapdock has two connectors that plug into an Atrix phone: a Micro HDMI D plug for carrying video and sound, and a Micro USB plug for charging the phone and connecting to the Lapdock"s internal USB hub, which talks to the Lapdock keyboard, trackpad, and two USB ports. With suitable cables and adapters, these two plugs can be connected to RasPi"s full-size HDMI connector and one of RasPi"s full-size USB A ports.

The RasPi forum has a long thread on Lapdock with many useful suggestions, photos, and links: I made a Raspberry PI Laptop. There"s also a good "blog entry at element14 with photos and suggestions of where to get cables and adapters: Raspberry Pi Laptop. TechRepublic has a tear-down article with photos of Lapdock internal components here: Cracking Open the Motorola Droid Bionic Lapdock. Paul Mano has a wealth of photos of Lapdock innards at Motorola Atrix Lapdock mod projects.

Lapdock uses the HDMI plug to tell if a phone is plugged in by seeing if the HDMI DDC/CEC ground pin is pulled low. If it"s not, Lapdock is powered off. As soon as you plug in a phone or RasPi, all the grounds short together and Lapdock powers itself on. However, it only does this if the HDMI cable actually connects the DDC/CEC ground line. Many cheap HDMI cables do not include the individual ground lines, and rely on a foil shield connected to the outer shells on both ends. Such a cable will not work with an unmodified Lapdock. There is a detailed "blog entry on the subject at element14: Raspberry Pi Lapdock HDMI cable work-around. The "blog describes a side-benefit of this feature: you can add a small power switch to Lapdock so you can leave RasPi attached all the time without draining the battery.

The Lapdock Micro USB plug is the upstream port of Lapdock"s internal USB hub, and connects to one of RasPi"s full-size USB ports. Lapdock is not USB compliant since it provides upstream power on its Vbus pin. Lapdock uses this to charge the Atrix phone. You can use this feature to power RasPi if you have a newer RasPi. The original RasPi rev 1 has 140 mA polyfuses F1 and F2 to protect the USB ports, which are too small for powering RasPi using upstream power. Newer RasPis replace F1 and F2 with zero Ohm jumpers or eliminate them entirely, which allows Lapdock to provide power. If you don"t mind modifying your original RasPi, you can add shorting jumpers over F1 and F2 or replace them with higher-current fuses.

What gets powered on depends on whether Lapdock is open or closed. If it"s open, the screen and all Lapdock USB ports are powered. If you close Lapdock, the screen and full-size USB ports are powered down, but the Micro USB still provides upstream power. This is for charging an Atrix phone. When you open or close Lapdock, the Micro USB power switches off for about a second so if your RasPi is connected it will reboot and you may have a corrupted file system. There"s discussion about this at the RasPi forum link, and someone has used a supercapacitor to work around the problem: Raspberry Pi lapdock tricks.

When you do not connect a HDMI monitor, the GPU in the PI will simply rescale (http://en.wikipedia.org/wiki/Image_scaling) anything that would have appeared on the HDMI screen to a resolution suitable for the TV standard chosen, (PAL or NTSC) and outputs it as a composite video signal.

The Broadcom BCM2835 only provides HDMI output and composite output. RGB and other signals needed by RGB, S-VIDEO or VGA connectors are however not provided, and the R-PI also isn"t designed to power an unpowered converter box.

Note that any conversion hardware that converts HDMI/DVI-D signals to VGA (or DVI-A) signals may come with either an external PSU, or expects power can be drawn from the HDMI port. In the latter case the device may initially appear to work, but there will be a problem, as the HDMI specs only provide in a maximum of 50mA (@ 5 Volt) from the HDMI port, but all of these adapters try to draw much more, up-to 500mA, in case of the R-PI there is a limit of 200mA that can be drawn safely, as 200mA is the limit for the BAT54 diode (D1) on the board. Any HDMI to VGA adapter without external PSU might work for a time, but then burn out D1, therefore Do not use HDMI converters powered by the HDMI port!

The solution is to either only use externally powered converters, or to replace D1 with a sturdier version, such as the PMEG2010AET, and to replace the power input fuse F3 with a higher rated one, as the current one is only 700mA, and the adapter may use 400mA itself. Also notice that the R-PI"s power supply also must be able to deliver the extra current.

Alternatively, it may be possible to design an expansion board that plugs into the LCD headers on the R.Pi. Here is something similar for Beagleboard:

The schematics for apples iPhone 3gs and 4g suggest they speak DSI, thus they can probably be connected directly. The older iPhones use a "Mobile Pixel Link" connection from National Semiconductor. The 3GS panel (480×320) goes as low as US $14.88, while the 4G one (960×640, possibly the LG LH350WS1-SD01, with specifications) can be had for US $17.99 or as low as US $14.28. The connectors used might be an issue, but this connector might fit. Additional circuitry might be necessary to provide the display with required 1.8V and 5.7V for operation, and an even higher voltage for the backlight.

The Raspberry Pi provides one clock lane and two data lanes on the S2 connector, as can be read from the schematics. It is currently unknown whether this is enough to drive the iPhone 4G screen, as that screen seems be driven with three data lanes in its original application.

I2C/SPI ADC can be used to interface 4 pin resistive Touch Screens, For example STMPE812A. Texas Instruments has a solution for 4 or 8 wire touchscreens using their rather cheap MSP4309.

Parallel interface displays can be found in many sizes, usually up to 7" and more. Parallel interfaces are usually 8 or 16-bits wide (sometimes 18 or 24-bit wide), plus some control-lines. The Raspberry Pi P1-connector does not contain enough GPIOs for 16-bit wide parallel displays, but this could be solved by borrowing some GPIOs from the CSI-connector or from P5 (on newer Raspberry Pis). Alternatively, some additional electronics (e.g. shift-registers or a CPLD) can be used, which could also improve the framerate or lower the CPU-load.

AdvaBoard RPi1: Raspberry Pi multifunction extension board, incl. an interface and software for 3.2"/5"/7" 16-bit parallel TFT-displays incl. touchscreen with up to 50 frames/s (3.2", 320x240)

Texy"s 2.8" TFT + Touch Shield Board: HY28A-LCDB display with 320 x 240 resolution @ 10 ~ 20fps, 65536 colors, assembled and tested £24 plus postage, mounts on GPIO pins nicely matching Pi board size, or via ribbon cable

There’s a lot of interest in these little Pi-shaped screens, but there doesn’t seem to be one that is truly “plug n’ play” working straight out of the box.

I may have found something that makes it a little closer to that true plug n’play goal – the 3.5″ TFT screen from NeoSec Solutions. They offer a similar product to the PiTFT however overall I’ve found it a lot easier to set up.

It’s hard to look at any small touch screen for the Pi without comparing it to the ever popular PiTFT – so rather than pretend to not be comparing it – this review will face the boards off against each other and see what’s the best screen in each category. I don’t normally do this, but it just makes sense in this scenario.

The NeoSec 3.5″ TFT is a small touchscreen LCD display that pushes on to your Raspberry Pi (Model A/B) via the GPIO pins. The screen makes use of nearly all available space above the Pi, allowing a decent 480×320 resolution. It comes packaged in a small clip-top box with everything inside.

The GPIO is accessible via the extra PCB tab below the screen, allowing you to connect any kind of header you want (or none at all). It looks as though this could be cut/snapped off if required, as there are a number of droll holes creating the break for you. It’s subtle and out of the way:

The image file is the big winner here for me. I put the image on to a blank SD card (8Gb as it didn’t fit my 4Gb), turned on the Pi, and it was ready to go. No messing around, no code – just a working screen out of the box. Compare that to the hassle of some other TFT screens for the Pi and you’ll see why I’m so impressed with this.

The screen itself is nice and bright, with rich blacks, and that 480×320 resolution keeping the font to a nice size to see as much as possible on screen. I love the size of this screen, and the way it covers the Pi completely. There’s also very little blank space on the screen itself.

I guess it’s hard to keep us happy – we all want the biggest screen on our Pi, but to achieve that you need to remove the PCB area. A tough balance to strike.

Whilst I dont normally compare products when writing a review, theres an obvious competitor that you cant help but compare to when you see other small Raspberry Pi screens…so this review will focus on the pros/cons of the NeoSec 3.5″ TFT compared to the 2.8″ PiTFT from Adafruit.

Although these screens are different in features and size, they’re suitable for comparison in terms of “Pi sized touchscreen vs Pi sized touchscreen”.

The AdaFruit screen rolls up at $34.95 – including the screen only (no buttons). You also have to assemble this screen, including soldering the main GPIO connector and taping down the screen element.

Verdict: NeoSec wins this one. Considering the extras you get with it, I personally think it’s a better deal for a ‘screen on Pi’ solution. (and the basic $25 package is clearly much cheaper)

The PiTFT requires assembly, including GPIO and button soldering, and taping the screen to the PCB. That tape isn’t very sticky at all so you’ll probably need to get your own – I used No Nails tape.

Verdict: I think self-assembly can be a good learning experience, but considering how many people I’ve heard complaining of the difficulty of assembling the PiTFT, NeoSec wins this one.

The NeoSec weighs in at a more comfortable 3.5″ and a clearer 480×320 resolution. The 3.5″ screen covers more of the Pi, which I think looks much smarter. That extra screen space does come at a price, which is the slightly more delicate feel it has, and no mounting holes for support screws like the PiTFT:

The font on the NeoSec screen seems smaller yet clearer, allowing more on screen, but there may be a way to match this on the PiTFT that I haven’t discovered yet:

Verdict: You can’t argue with the bigger screen of the NeoSec, and it does seem to have much better colour and clarity. It seems an easy decision when considering these two as being in the same product market – however the PiTFT certainly feels more sturdy with that PCB surround. I’m going for the NeoSec here – but it is tight.

The PiTFT has holes around it to use nylon screws as a screen support. It also has PCB area around the screen acting as a bit of protection. The PCB covers the entire underside of the screen, ensuring no light comes out of the back.

The NeoSec screen doesnt have any support holes, and has no PCB area around the screen (but its a bigger screen, which is more important in my eyes). I can’t see the NeoSec doing well on a Model A without that Ethernet port holding it up. The NeoSec’s PCB doesn’t cover the rear of the screen either, so light comes out on to your Pi.

Verdict: The PiTFT wins this one, it feels much more secure, and I’m pretty sure light bleed from the back isn’t meant to happen – even if it does look cool.

The PiTFT has an optional upside-down connector to attach a belt to breakout to a breadboard. I don’t like the whole belt thing, it feels a bit too 90’s computing for me, and the upside down back to front thing makes it hard to do something different like add a regular GPIO header.

The NeoSec is a little more traditional with the GPIO, and simply gives you a mirror of the GPIO next to the screen. This is good if you want a simple prototyping access, but perhaps not as ideal if you just want a screen, as it does stick out. It looks as though it can be removed as drill holes indicate an easy option to cut or snap it off.

Verdict: Tie – it all depends on what you want the screen for. The PiTFT may be better for breakout projects, whilst breaking off the GPIO tab on the NeoSec may be better for those looking for a simple screen solution.

The PiTFT comes ready to fit 4 tactile buttons to, however these need to be purchased and fitted separately. The blue PCB of the Adafruit board is attractive when compared to traditional colours.

The NeoSec on the other hand, was much easier to get going. I simply installed the image provided on the DVD supplied (no long download required) and it worked straight away. You have to tweak a couple of settings if you’re using a Rev1 board, but with a Model A/B it’s real easy. You also don’t seem to need to push things to the display using code – it picks up everything as default from what I’ve tested.

I thought I’d add a final section on support, as I had a few questions while writing this review, and previously had questions on the PiTFT when I first used it.

The PiTFT benefits from the massive following and fan base that Adafruit command. Their forums are full of information, and generally a lot of people buy their products, so most people have had the issue and written about it on blogs and forums.

The NeoSec screen doesn’t have that massive following that AdaFruit does, so finding information already out there can be difficult. Fortunately NeoSec counteract this by providing excellent personal support by email and also regularly on the Raspberry Pi forum.

It’s important to stress “personal choice” here. Everyone will have different uses for a Pi-sized screen, so a lot of us will probably sway one way or another purely based on the features and functionality we need.

Sure the PiTFT has that sexy blue AdaFruit styling we all love, and the screen feels more secure and has an overall better ‘feel’ to it (plus those optional buttons are very cool), but the setup involved many hours of my life that I’m unlikely to get a refund for.

The extra size and resolution gives a much better picture too – the colour and clarity are beautiful. Add to that the extras such as the pen and the touchpad, and for a extra few dollars the NeoSec feels like the better 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.

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.

-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=: Specifies a GPIO pin that can be polled to get the battery state. By default, when this is set, a low battery icon will be displayed if the pin is pulled low (see config.h for ways in which this can be tweaked).

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 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 opti