SPI and tristate buffers

Thread Starter

Gibson486

Joined Jul 20, 2012
355
I am getting confused about how people use trisate buffers on SPI lines. Are people only supposed to use them if the chip itself does not have a tristate output on the MISO line only? Also, you could effectively use the 74XX series of chips as a mux, correct (tie the OE to the chip select)? It would, in turn be a kind of a sketchy or poor man's version of multiple fan out buffers or a mux for the MOSI line or clock?
 

Papabravo

Joined Feb 24, 2006
21,157
I am getting confused about how people use trisate buffers on SPI lines. Are people only supposed to use them if the chip itself does not have a tristate output on the MISO line only? Also, you could effectively use the 74XX series of chips as a mux, correct (tie the OE to the chip select)? It would, in turn be a kind of a sketchy or poor man's version of multiple fan out buffers or a mux for the MOSI line or clock?
You have it correct. The MISO line is the only SPI line which potentially needs needs a tri-state buffer. It only needs this buffer IF the device does not tri-state the MISO line when chip select is deasserted. The other three lines(SCLK, MOSI, SS*) are uni-directional and can be buffered to suit your purposes.
 

MrChips

Joined Oct 2, 2009
30,704
Tri-state buffers are used in party-line situations when there are multiple drivers attempting to drive a common bus.
This is a common situation with SPI communications where there could be multiple slaves driving one MISO line.
The solution is to ensure that only a single slave is activated at any time by asserting only one SLAVE SELECT (SS) signal, usually active-LOW.
External tri-state buffers are not needed since tri-state buffers are included in the SPI controller.
 

Papabravo

Joined Feb 24, 2006
21,157
Tri-state buffers are used in party-line situations when there are multiple drivers attempting to drive a common bus.
This is a common situation with SPI communications where there could be multiple slaves driving one MISO line.
The solution is to ensure that only a single slave is activated at any time by asserting only one SLAVE SELECT (SS) signal, usually active-LOW.
External tri-state buffers are not needed since tri-state buffers are included in the SPI controller.
This is not true for all SPI peripherals. You need to read the datasheet carefully. I do suspect your statement is more true today than it was only 15 years ago though.
 

MrChips

Joined Oct 2, 2009
30,704
This crossed my mind when I wrote this:
External tri-state buffers are not needed since tri-state buffers are included in the SPI controller.
I thought of saying if instead of since. But I took the chance referring to modern controllers. There is always someone on AAC keen enough to catch you out. (ignore the poor grammar).

Edit: posting on AAC has thought me a lot of things, such as watch your wording, phrasing and spelling.
 

Thread Starter

Gibson486

Joined Jul 20, 2012
355
You have it correct. The MISO line is the only SPI line which potentially needs needs a tri-state buffer. It only needs this buffer IF the device does not tri-state the MISO line when chip select is deasserted. The other three lines(SCLK, MOSI, SS*) are uni-directional and can be buffered to suit your purposes.
What do you usually use to buffer the MOSI and clk? I was thinking about using the a bunch 74XX series of chips as a mux.
 

Papabravo

Joined Feb 24, 2006
21,157
I would not even think of using 74xx chips any more. My preferred chips are the single gate variety from the low voltage CMOS with TTL threshold family.
I've made this identical recommendation numerous times on this board; thirteen times in fact.
http://www.onsemi.com/pub_link/Collateral/MC74VHC1GT50-D.PDF
The big advantage is that they are OK with a +5V input with a VCC of 3.3V, and a 3.3V input with a Vcc of +5V
 

Papabravo

Joined Feb 24, 2006
21,157
This crossed my mind when I wrote this:

I thought of saying if instead of since. But I took the chance referring to modern controllers. There is always someone on AAC keen enough to catch you out. (ignore the poor grammar).

Edit: posting on AAC has thought me a lot of things, such as watch your wording, phrasing and spelling.
And things keep changing as chip designers become hip to how their parts are being used. Most of my SPI experience was with A/D and D/A converters from two decades ago.
 

Thread Starter

Gibson486

Joined Jul 20, 2012
355
There is no mention of it in the datasheet, but I am going to go out on a limb and say that the MC74VHC1GT50 needs a bypass capacitor?
 

Papabravo

Joined Feb 24, 2006
21,157
There is no mention of it in the datasheet, but I am going to go out on a limb and say that the MC74VHC1GT50 needs a bypass capacitor?
In designing SSI/MSI boards we seldom went so far as to put a bypass capacitor on every chip. The idea was to distribute the capacitance over the area of the board and employ a mix of values , e.g. 105,104 & 103. It also depends on the nature of the chips. A synchronous counter made out of flip-flops requires more than a collection of random gates.

BTW this gate is part of a family of similar parts. The one you actually need for buffering the MISO line is the MC74VHC1GT125 or MC74VHC1GT126
http://www.onsemi.com/pub_link/Collateral/MC74VHC1GT125-D.PDF
Sorry for the confusion.
 

Thread Starter

Gibson486

Joined Jul 20, 2012
355
Got my PCB back....I neglected capacitance...my pulse on the miso line is barely .5 volts :( All my devices were tristate, but being trisate was not enough (there where 18 spi devices, so capacitance must have been a nightmare). Lesson learned.
 

Papabravo

Joined Feb 24, 2006
21,157
I don't think capacitance is your problem. If it was you would see a slow rise to +5V(+3.3V). Excess capacitance on the MISO line will not hold the MISO line at +0.5V.
To debug this problem isolate the master and a single slave to compare the results. Sounds more like the enables on the tri-state drivers are not being handled correctly.
 

Thread Starter

Gibson486

Joined Jul 20, 2012
355
Thanks....I thought the same thing after leaving on Friday....however, I should also note that there are 16 other SPI devices on the bus...I have seen this issue before, and I fixed it by putting each line through a mux. Yeah, it was sort of a "cheap" way out, but we needed this to work ASAP. For this project, I have no room for the muxes, so that cannot be a solution. Perhaps the pull ups are not strong enough on the select lines? Could it be that 16 high impedance inputs is too much load?
 

Papabravo

Joined Feb 24, 2006
21,157
You analysis seems dubious without more information. On the MISO line we are talking about one input and 16 high-impedance outputs. It would really help if you could keep the conditions straight.
 

Thread Starter

Gibson486

Joined Jul 20, 2012
355
I just removed all the other spi devices. It is still barely hitting .5V. I am not too sure what the issue is at this point. Perhaps is just a bad board design. Everything works with the vendors demo board, so I know it is not software. I did not not mean to be not forthcoming with info, I just thought it may have been obvious what I was trying to do. Sorry.
 

Papabravo

Joined Feb 24, 2006
21,157
This is an important piece of information. The next thing I would look for is a wiring mistake that has two outputs fighting each other.
 

Thread Starter

Gibson486

Joined Jul 20, 2012
355
Well...I removed the other devices from the PCB. So the only thing it could be fighting is the chip itself. Or maybe there is a short somewhere?
 

Thread Starter

Gibson486

Joined Jul 20, 2012
355
I fixed it....turns out the assembly house mixed up a resistor and a capacitor. The capacitor was the on the reference as a bypass, so having a resistor there killed the built in reference on the chip and made the whole chip struggle. It did not fix the whole issue, however. Everything looked perfect, but it did not work still. What I eventually ended up doing was putting software delays in the spi transfers. That fixed it. It's weird because I am already running the spi speed pretty low (125Khz), so maybe the buffers I added have a latency of more than I thought.
 
Top