Insight why display fails with buffer board

Question

Can someone share their insight into why no images are displayed on the LCD display when a buffer/level shifter board is inserted between the Pi and the display?

The project is to display images on a 1.3 inch display using a Raspberry Pi. Inspiration for the project came from Episode 465: Lego Raspberry Pi HQ Camera . I'm using the LCD screen Katie's hifromkatie used in the project.

I can display images on the display https://github.com/pimoroni/st7789-python connected directly to the Pi. Images are not displayed if I insert a buffer board between the Pi and the display. I have tried modules with TXS0108E and BSS138 chips and get the same results.

Attached is the pin out for connections. I confess I have limited experience with this communication protocol. I was hoping the buffer would provide some isolation for the Pi to enable me to move the display away from the Pi. I assumed a level shifter would not introduce issues but that does not appear to be the case.

Can you share any insight into what is causing the issue and possible solution.

Message was edited by: sean conway I added pictorials of the buffer/level shifting modules. The module on the left is is based on the TXS0108E chip and the right is a BSS138 fet based on an adafruit model https://www.adafruit.com/product/757

Jan Cumps · Answer

I think MISO is not used. All data goes from master to display.

colporteur · Answer

First, I stabilized power for the display. The display was getting power from the module, not a channel but the power rail, now the display power is completely independent with ground reference the same.

Next, I established a setup that had the display working but enabled me to move each connection to a level converter (one type first and then the second). Any of the signals CS, SCK, MOSI or DC that are moved to the level converters (the two I have on hand) the display doesn't work.

This new knowledge, motivated me to look at how SPI signals are amplified to extend distances. It seems SPI and LED arrays have spawned a number of amplifiers. My research took me to the Open Source Hardware Association link https://www.oshwa.org/a-resolution-to-redefine-spi-signal-names , the fog of my confusion started to lift. I wasn't aware that industry used different nomenclature to describe the signals for the same protocol. Awe Shite, no wonder I was confused.

Self directed learning has it pit falls. If you don't know, what you don't know, how do you know, when you don't know. Oh well, now I know, this has aligned or realigned me towards finding a solution. I have tried to avoid using the adjective "simple" in my dialog. I think it fits in the same category as the words, common sense. Knowledge can lead to understanding that gives the allusion its simple.

If anyone has an SPI signal extender they have had success with I would be interested in exploring any references.

Gough Lui · Answer

My best guess is that you're using level shifter boards or wiring which is too slow to accommodate the high-speed SPI that the display is demanding. The code you are using has this in the ST7789's __init__.py: SPI_CLOCK_HZ = 16000000 This tells me that the communications between the Pi and the screen are going at 16MHz. This is not a speed you can just carelessly whip around jumper wires or any-old-level-shifter. My guess is the BSS138-based shifter you're using is one intended for I2C usage which is only 0.4MHz in the "fast" mode. The TXS0108E may well be able to do it - it does say it can do 60Mbps maximum at 3.3V in push-pull which is plenty but only 2Mbit/s in open-drain (check the configuration of the module you're using). But I fear that the wiring you're using just may not be good enough to get 16MHz consistently - I've not had much luck myself above 8MHz going with jumper wires. Long wires add capacitance that will serve to increase the load on the drivers and round-off your edges, but also have a tendency to radiate signal so may even cause radio interference to nearby electronics. Probably best to get a scope onto the lines with the display load connected to see what is arriving at the display ... I suspect the signal just isn't clean. Perhaps another way is to try and modify the library and use a slower SPI clock and see if the display would come up (perhaps with reduced performance if not timing critical). - Gough

ralphjy · Answer

The results of your experiment moving individual signals is interesting. Maybe you should check that you aren’t missing something obvious. The chip select pin is fairly low frequency. You should check the levels and prop delay through your translator. I think an issue on CS should be easy to spot.

colporteur · Answer

Thank you for reviewing my data. Another set of eyes can help uncover anomalies.

I confess the cold medication induced stupor wasn't the ideal condition to be in for testing. On further review (i.e. testing) you observations are correct and the pins that won't work through the level converter are in fact different.

Two pins (SCK & MOSI) if connected through the level converter cause the display to present no image. I thought maybe MISO would also would be included in the set but not according to my testing.

dougw · Answer

Is this module intended to shift voltage levels or drive a long cable?

Presumably the Pi is 3.3 volts, what voltage is the LCD logic?

How long is the cable? Some of these bidirectional level shifters cannot drive long cables.

As Jan points out display driving signals are all unidirectional, so a bidirectional driver may not be needed.

It sounds like the display works fine directly with Pi voltages - why is this buffer needed?

Does the display cease to work because the cable gets too long?

Make sure there is a good ground connection all the way from the Pi to the display, even with the buffer module in place.

Jan Cumps · Answer

Sean, I have an additional question. The top line, indicating 3 - 5 V, is that the power for the display? That should not go through a data line shifter.

ralphjy · Answer

I think in this instance the pin normally used for MISO is used for DC as shown in his first diagram (not sure why they did it that way). Apparently, it can be remapped in the display class in the example programs from the library..

# Create ST7789 LCD display class.

disp = ST7789.ST7789(

port=0,

cs=ST7789.BG_SPI_CS_FRONT, # BG_SPI_CS_BACK or BG_SPI_CS_FRONT

dc=9,

backlight=19, # 18 for back BG slot, 19 for front BG slot.

spi_speed_hz=80 * 1000 * 1000,

offset_left=40 if display_type == "round" else 0

)

colporteur have you tried reducing the speed? I think you do it by powers of 2. Maybe you could try it at half speed to see if that helps.

Jan Cumps · Answer

dougw wrote: Is this module intended to shift voltage levels or drive a long cable? ... The ICs mentioned here don't buffer. They are FETs in series with the signal.

colporteur · Answer

The display will be separated from the Pi by a cable.

My testing has been addressing requirements. First was to prove the display worked (i.e. I could get it working). Then size and how it could be accommodated physically in the layout and now cable lengths.

The Pi resides on a distribution panel approx three feet from the display. I'm hoping (maybe with the aid of a driver) the display will work.

The final requirement is can two displays be operated from the same Pi. Each independent in term of images. This last requirement I hoping to reduce the need for another Pi.

Jan Cumps · Answer

colporteur wrote:

(maybe with the aid of a driver)

None of these ICs drive (the 2 you suggested, nor the one I put in the comments). They actually add resistance (and capacitance) to the path.

There are FETs in the ICs. But they block or pass the signal (with the additional benefit of shifting the level). They will not buffer, protect or boost.

They can't be used to allow for longer signal paths. They do the opposite - add an extra hurdle to the path.

They have good use: they switch levels. But they don't do what you seem to be looking for.

michaelkellett · Answer

How about using SN74HCT244N (Farnell 3006173).

This is a dual 4 way buffer which runs from 5V but the input thresholds are 3V friendly - I've picked the DIL version which is easy to prototype with.

You can't use this to drive the Pi MISO (without a resistor divider) because it outputs 5V.

It can drive serious current (although it would be worth adding some series resistors to improve the pulse shape if you use long leads.)

You would need a scope to check.

I second Doug's point that running the SPI clock slower would improve chances.

The '244 should be at the Pi (driving) end of the wires.

You could do 2 displays by giving each one half of the '244 and driving both halfs from the Pi. You could then use 2 Pi GPIOs to control the '244 output enables.

Put a pull up resistor on the display side of each /CS pin so that the disabled outputs set /CS to invalid.

MK

jc2048 · Answer

It might help us if you gave a bit more detail of the thing you're having the problem with. A red oval isn't very illuminating. Having said that, the reason might be that you aren't using a 'buffer board', you're using a level-translation board. The 'A' side of the TXS0108E device can only go to 3.6V max, so don't power that side with 5V or you'll blow it up. You'd have to add a regulator to drop the 5V to power the 3.3V side. So Pi to 'B' side, display to 'A' side, and a 3.3V regulator to power the display and the 'A' side from the Pi's 5V. Does that make sense? If not, say and I'll try and draw something. If you wanted to [had to?] power the display from 5V, maybe two level-translate boards back-to-back, one at each end of the cable [depends how cheap they are, really]. The cable section would then operate 3.3V [you'd still need a 3.3V supply, though, for the cable section]. But since you just want to buffer, why not use a buffer logic chip? Or even just try it without any buffering and see how far you can get: the Pi I/O pins probably drive quite well. With CMOS outputs to CMOS inputs, where the high and low side are fairly well balanced, series termination at the sending end works quite nicely [for ribbon cable, try something like 100R] and you could probably manage several feet without any problems at all, and further with abit of care [to improve your chances, best to keep crosstalk down and regularise the cable impedance by interleaving grounds with the signal wires]. The weakest part might be the return data from the display, depending how they've done it, but you could add a buffer at the display end or maybe you might be able to just ignore that if you don't use any return data. Edit, 31st March. I'm wrong here. I took it from your drawing that the signalling on the Pi was 5V, but it's not: it's 3.3V. So what I've written is gibberish [though the bit about getting signals down a ribbon cable still stands]. Perhaps take more note of what the others are writing below. If I were in your place, I'd ditch any idea of working with 5V, run everything on 3.3V, and, if it were even necessary to buffer, consider a bus buffer like a 74LVC125 ( SN74LVC125 SN74LVC125 ) or something like that.

Jan Cumps · Answer

I'm using this design for FPGA level shifting: Make a Logic Analyzer from your Dev Kit Part 3: Level Translator and Buffer A shifter - not a buffer, and you have to use the exact IC that's listed in the blog. But the IC can handle GHz. 16 data lines. The use case here is one direction. But not sure if the use case needs a buffer. It's not common in this scenario. These displays are made to directly attach to the logic and seem voltage compliant.

nathandumont · Answer

This is a great insight into your problem, thanks for the update.

Have you tried the display with an approximately accurate length of cable? I would suspect with a suitable SPI clock speed you'd be able to run that distance without any extra hardware. How fast do you want to update the display, is it mostly static images or do you need to change images very frequently?

Two displays off one Pi should be possible as the Pi has two Chip Select outputs on the SPI peripheral.

michaelkellett · Answer

In the examples in the git repo. you link there are lines in the setup code of each like: spi_speed_hz=80 * 1000 * 1000 try changing it to spi_speed_hz = 20 * 1000 * 1000 MK