TFT touchscreens for the Raspberry Pi

Starting Up

As was the case with earlier resistive screens, calibration is an important step when starting up a touchscreen. For the Pi3g [5], you begin with a rough hardware calibration. This process is awkward, but it is also well documented. Ultimately, the calibration deals with determining optimal parameter settings for the touch driver which then land in the /etc/modules file and are automatically activated by the Rasp Pi when it boots. Next comes the fine calibration using the software program ts_calibrate. The program brings up points on the screen that are meant to be lightly touched (Figure  3).

Figure 3: When first booted, Pi3g starts with a calibration program that allows you to fine-tune the display screen.

The Pi3g image boots normally, starting the text-based configuration program from Raspbian. Connecting a keyboard will be necessary because the system only supports the touchscreen via X. The entire process can be tiring for the eyes, and you might find it easier to use secure shell from another computer. By contrast, the Watterott system comes with a basic configuration, and X starts immediately. However, if you want to change settings like the keyboard layout, you will have to call up the configuration program.

Watterott has devised a clever way for performing the calibration that loads when X first starts. It creates the /etc/pointercal.xinput file with the parameters that are determined. If this file already exists, the start scripts of X will skip over the calibration process. Watterott does not mention the rough hardware calibration in its documentation. However, depending on the serial scatter, you should adapt the corresponding values for the ads7846_device module in the /etc/modules files.

Ultimately, both systems differ only in a minimal fashion in the way in which they first start up. The normal Raspbian desktop is ready for use after startup (Figure  4). At this point, you will notice that the screen is simply too small to use the desktop effectively. Hardly any graphical program exists that can be used just by operating the left mouse button. Another form of user interaction is needed.

Figure 4: The mini-display screen proves too small and almost unusable for a normal Raspbian desktop.

Special Solutions

The previous issue of Raspberry Pi Geek contained an article that introduced the C-Berry display screen [6]. Control over the screen was accomplished via low-level APIs by means of C code because of the lack of X drivers.This proved to be an efficient and resource-saving solution, but it is not meant for everybody.

This approach would be possible because both of the displays described here come with an X-capable framebuffer driver, but it is not necessary. Every toolkit, whether Qt, Gtk+ or any other that sits on top of X, takes care of applications with a graphical interface. Many of the constituent parts, however, don't fit on the mini-screen – in particular, standard components like scrollbars, menus, and highly specialized file selection dialogs are not suited at all for small screens.

Adafruit offers a similar display screen on the basis of ILI9341 for hobbyists with experience in soldering [7]. Adafruit also has a camera application for this screen built on the basis of PyGTK [8] that systematically implements the user interface by itself. Although these special solutions are desirable, they are often not worthwhile because they require too much effort to use.

Buy this article as PDF

Express-Checkout as PDF

Pages: 6

Price $2.95
(incl. VAT)

Buy Raspberry Pi Geek

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content