Quantcast
Viewing all articles
Browse latest Browse all 4829

Official Display • Mistakes and Fun with Touch Displays

Display Issues

Overview
The following is MY debugging journey connecting the Raspberry Pi official touchscreen to various Pi modules. I don't claim to be correct, nor have read the a vast number of these forum posts. I will likely contradict some best practices. I struggled over the last month with a new CM5, CM5IO, and Touch Display. Some of the help many forums, not use this one, was not very helpful. Many recommendations were unnecessary and arbitrary. Although intentions were good, I could tell from many of the response were coming from a different perspective than someone coming into this fresh. When you've been practicing best practices for a long time, you must forget the frustration and obvious human errors. I was unable to find any guide like what I am attempting to publish below. Feel free to correct me or add to it. Hopefully someone finds this helpful. Also, a bummer we cannot post pictures here, I have a lot of detailed photographs of working setups.

Jumping In
I learned right away that there are 2 modules. They are both often called “Raspberry Pi Official 7 Inch Touchscreens”.

My advice is to thoroughly read the documentation for your particular version of the touchscreen. Should be a short read.

The original version, the “Touch Display” is colloquially called “V1” and is 800x480.
https://www.raspberrypi.com/documentati ... ch-display

The updated version, the “Touch Display 2”, is colloquially called “V2” and is 1280x720.
https://www.raspberrypi.com/documentati ... ifications

Power
Both will only need power supplied from the GPIO pins.

If sharing power to the Pi and display, use a powerful enough supply. Many have been successful on supplies rated at 3A at 5V. I do recommended the official Pi adapter to reduce clutter. It provides 5A at 5V so you won’t get low voltage alerts. Also, if you are using HDMI, PCIe, or any USB devices such keyboard, mouse, storage, it WILL add load to the power supply.

Some blame lower amperage power supplies resulting in low voltage operations on failures, but this has never been an issue for me in the past or with my current experiences. I don’t use HDMI, USB devices, or any other add on. My interaction with the Pi is through WiFi and SSH. However, if you think power is a factor, and you don’t have a powerful supply, you can power the touchscreen on its own supply. The ribbon cable doesn’t require the same electrical ground.

Connectors
The connectors are called Zero Insertion Force (ZIF) connectors and there are many styles. You will typically find two styles used, I personally call them the “3 side wedge” and “hinged door”. They are called zero insertion force, but if you use them the wrong way, with “non-zero exercise force”, they will break. For example, we use 3 side wedge style connectors where I work. One recently broke on another kind of device. To prevent soldering, you can carefully insert wedge. It will stay until you unplug it, then you are looking all over your workbench for the little wedge part.

Ribbon Cables
Both displays will receive video data from the Pi over the ribbon cable. Both displays will take commands and give touch data over I2C, that is included in the ribbon cable. No additional wires should be needed.

Although a single cable for video and touch seems error prone, the cable is what gets most people from my research. Most cables and connectors for public consumption eliminate the human error factor. The cables and connectors give lots of opportunity for human error.
It’s not Raspberry’s fault, it is the industries fault for not keying the connectors somehow. If you found this posting, and your Touch Display doesn’t turn on, you likely made a human error due to the lousy choice of connectors or haste in researching something so simple and plugging in a cable.

Let’s discuss the cables used in displays in more detail. Technically they are called Flat Flexible Cables (FFC) or Flexible Printed Circuit (FPC) in the industry. The ends of each cable have conductors. They may be copper or aluminum in color. The cables used for displays will have conductors on only 1 side. Cables obviously have 2 ends to them, but they may or may not be the same end type. The two ends will either be the 15 pin end or the 22 pin end. The 15 pin end will have conductors spaced 1mm on center, aka pitch. The 22 pin end will have conductors spaced at 0.5mm on center, aka pitch. The 22 pin end is actually narrower than the 15 pin end due to the pitch. Since the cables are single sided, there is the possibility that the conductors are on the same side of the cable, when laid flat, or on opposite sides. When the conductors at opposite ends are on the same side, it is called type A. When the conductors at opposite ends are on the opposite side, it is called type B. There is no rule with Pis and displays that you should always buy type A or type B, it is mixed in practice.

Using the correct type A or type B cable is very important. Since the cable is used to carry a signal between two devices, the pin numbering will matter. The designers of the hardware have very carefully intended a trace on one device to be connected to a trace on the other device. To make sure the traces match up, they typically number the traces (aka pins) through the cable. I wouldn’t worry so much about making sure pin 1 on 1 end is pin 1 on the other, as numbering schemes can be different. More importantly is the continuity through the cable matches.

Specific Cables

I am only listing those cables that I have experience with. There are many other versions of Pi that I have yet to connect displays to, so others can add details. If you do add a cable recommendation for a specific Pi model, please show a photo of the cable alone and another photo of the cable plugged in to the Pi and display. Be detailed enough to show the conductors up or down when inserted in the connector.

Pi 3B+ to Touch Display (V1)
Type B, 15 pin on both ends

This is also a pass-thru cable as each conductor/pin goes from one end to the other end.
When plugging into the Pi, the cable conductors are facing the center of the Pi.
When plugging into the Touch Display, the cable conductors are facing away from the PCB, e.g. up.

White cable seen in this image.
Image may be NSFW.
Clik here to view.
Image


Pi4, Pi5, CM4, and CM5 to Touch Display (V1)
Type A, 22 pin to 15 pin

When plugging into the pi4 or pi5, the cable conductors must away from the Broadcom chip.
When plugging into the cm4 or cm5, the cable conductors must toward the PCB, e.g. down.
When plugging into the Touch Display, the cable conductors are facing away from the PCB, e.g. up.

See this add for a picture.
https://www.amazon.com/UeeKKoo-Official ... B0D12N6TLW

Alternate Option
If you have the cable above and inspect it closely, or think about how 15 pins on one end and 22 pins on the other should match up, you will see it’s not simply a pass-thru cable. There are changes. Pin 1 on one end is not necessarily pin 1 on the other end. However, Raspberry Pi engineers designed a small circuit board to allow developers to use cheaper and more available pass-thru cables with the adapter to make the 22 pin to 15 pin transition.

This is an official adapter. You will see it labeled “RPI-DISPLAY to CMIO-DISPLAY”. The name CMIO stands for compute module IO, so you know it is correct.

See this add for a picture.
https://www.amazon.com/Compute-Display- ... B094WC68WH

When I use this cable with Touch Display (V1), I used the following pass-thru cables. On the CMIO-DISPLAY side, the actual Pi side, the 22 pin pass-thru connector is a type A. On the RPI-DISPLAY side, the actual display side, the 15 pin pass-through connector is a type A. The adapter must have BOTH cables connected to it with cable conductors facing toward the PCB, i.e. down. Once the adapter is cabled properly, following the orientation described above for the 1-piece cable.

NOTE: I have NOT used this with Touch Display 2 (V2) yet. I believe that it will not work and the 22 pin side might need a type B connection, but I am not sure.

Pi4, Pi5, CM4, and CM5 to Touch Display 2 (V2)
Type B, 22 pin to 15 pin

Copper cable seen in this picture.
Image may be NSFW.
Clik here to view.
Image


Making the Connection
So now you have the right cables. You have then inserted with the proper conductor orientation. The ribbon cable carry signals for video but also I2C. The I2C is used for reading settings from the display, writing settings to the display (like backlight), and tracking touches.

For compute modules, you may need the J6 jumpers set. The need for jumpers depends on the dsi the display is connected to, ds10 or dsi1, and the type of CM you have. Technically, the jumpers are used to connect/route GPIO pins for one of the I2C buses into one of the dsi interfaces and cable. The dsi are not identical and the I2C is the difference. I suspect I2C ports are a limited commodity on the Pi and two dsi displays are not common, so it was an engineering decision. On a CM4IO, dsi0 is lacking I2C by default and needs the J6 jumpers in place. On a CM5IO, dsi1 is lacking I2C by default and needs the J6 jumpers in place. Yes, this is backward between the CM4IO and CM5IO. I am speculating they have a new plugin module that preferrs that I2C bus. My perspective is that if you have no explicit need for the extra I2C, just install the J6 jumpers and don’t worry about it.

I am not aware of a similar need for jumpers on Pi4 and Pi5 boards.

Configuration of config.txt
First, it is recommended that you start with a latest and unmodified OS installation. I like to use the Pi Imager and override the initial configuration with my hostname, username, wifi name and password, etc.

Pi 3B+, Pi 4, and Pi 5 all have boot firmware that automatically detects the dsi devices. I believe there is a “dtoverlay” setting that performs the actual detection and knows about a lot of different brands of displays. I think the concept of a probe is used to find which display(s) are connected. Anyway, on these Pis, there is NO need to modify anything in the config.txt file.

CM4 and CM5 do NOT automatically detect the dsi devices. Compute modules will detect HDMI displays however, so if you use HDMI or not, you still don’t need to modify the config.txt. The rest of this section only applies to compute modules.

The “dtoverlay” settings must be explicitly configured for any DSI displays in your /boot/firmware/config.txt file. If you are new to config.txt and ‘dtoverlays’, the config.txt is like BIOS settings, and ‘dt’ means device tree. There will be multiple dtoverlay entries, 1 per device driver. You can have many different dtoverlay lines.

See here for details on the config.txt file. https://www.raspberrypi.com/documentati ... ml#content. My recommendation is to just add the appropriate dtoverlay line at the end of the file, after the ‘[all]’ line. However if you use SD cards in your CM that move to Pi4 or Pi5’s, you may want to add the dtoverlay line in the appropriate [cm4] or [cm5] section of the time.

Although there are implicit default dsi numbers you can specify on the dtoverlay line, my recommendation is to be explicit. For example, the following should work.

When you have a Touch Display (V1) in dsi0, add this line:

Code:

dtoverlay=vc4-kms-dsi-7inch,dsi0
When you have a Touch Display (V1) in dsi1, add this line:

Code:

dtoverlay=vc4-kms-dsi-7inch,dsi1
When you have a Touch Display 2 (V2) in dsi0, add this line:

Code:

dtoverlay=vc4-kms-dsi-ili9881-7inch,dsi0
When you have a Touch Display (V2) in dsi1, add this line:

Code:

dtoverlay=vc4-kms-dsi-ili9881-7inch,dsi1
If you have multiple displays then just add the dtoverlay lines for the appropriate dsi numbers from above. And if a dsi slot is empty, you should have no dtoverlay lines with the dsi number.

There are other default setting included in the config.txt, and may seem suspicious like frame buffers, overscan, etc., but they should be left alone and will not affect your configuration/debugging.

Some people suggest disabling automatic camera and display detection, but since the cm4/cm5 ignore it, you can safely leave it in the config.txt as is.

Debugging

Some bullet items:
  • Debugging with HDMI displays, keyboards, and mice will NOT affect the dsi display configuration/debugging/use experience.
  • It is highly recommended to enable Wifi or ethernet immediately, enable SSH, and get comfortable with using the CLI remotely. This will keep the clutter down and allow you to revert any changes should you mess up displays including HDMI.
  • Display hardware generally starts with the backlight disabled by default. When the backlight is disabled, the pixels are not driven for energy conservation reasons. It requires an I2C command to set the backlight on.
  • On non compute module Pis, use the latest OS and default config.txt on this Pis
  • On compute module Pis, use the latest OS and change the config.txt for ONLY adding ONLY the dtoverlay for the dsi you need.
  • Some log messages seem like you have communication. Not always. If you see an overlay loaded, it doesn’t mean it found the hardware. Look for success in the logs of setting the backlight for example. An error here likely means I2C is not working. An unpowered display or improperly inserted cable (upside down, wrong type, etc) will all fail to set the backlight and you may get an error.
  • I’ve failed quite a few times and once I got cable, connectors, jumpers, and config.txt right, the screen came to life. There was no damage to the board.
If the display just never lights ups, you might need to check continuity of a signal. I’ve had to use a volt meter and test continuity of the same signal on the Pi (GPIO) reaches the proper place on the Touch Display. If you have continuity, you cabled it correctly.

Some helpful commands in my experience are:

Code:

dmesg | grep backlight
Immediately shows if you have issues with I2C communication with the display.

Code:

raspinfo
This dumps all the details of configuration, startup logs, startup errors, etc.
If you ever ask for help from an expert this is a good and concise collection of helpful information.
Also, this is where you can look to find indications that i2c is not working properly.

Code:

i2cdetect -l (lower case L)i2cdetect -y 11 (11 is an example)
Less likely to be helpful, but shows if all of the I2C busses device addresses, which is a positive indication. The first iteration of the command lists the ic2 buses. They will be numbered something like ’i2c-11’ but you can drop the ‘i2c-‘ prefix in other versions of the command. The second iteration of the command dumps which I2C addresses are in use on which i2c buses.

Code:

vcgencmdvcgencmd commands
Just a nice command to read various state of equipment. It’s how I tell when my CM5 is getting hot.

Good luck!

Statistics: Posted by 8mhz — Sun Jan 12, 2025 8:08 pm



Viewing all articles
Browse latest Browse all 4829

Trending Articles