Insight why display fails with buffer board

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 ( SN74LVC125SN74LVC125  ) or something like that.

I updated the drawing to provide a visual of the type of bidirectional modules the red circle represents. Each output operates on its own channel. I have used these type of units in the past with good success.

I interchange the terms buffer and level shifter. A bidirectional level shifter is the name pulled from the parts sites. To me it buffers the Pi from the outside world.

The power supply I have tried a number of power configurations. Power both sides from the Pi, power both sides from external sources, power one side 3.3v Pi and the other side external. I have also confirmed that each channel is working or the level shifts. Using gpiozero I confirm the output can turn an LED on and off.

The choice of bidirectional module was dependent on what was on the shelf. I was hoping to not have to introduce another parts module to deal with the issue. Again never used this com protocol before so maybe that is something I need to be aware of.

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

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.

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.

Thanks for the insight folks. I'm going to attempt some testing to explore the areas of concern you have suggested. I will keep you informed of the results.

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.

Are all these display communication protocols pins the same or are they different? Now I know. Back at it.

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.

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.