SPI Switching

[rackley]

Hi all,

I need to run a bunch of stuff over an RJ45 cable which is only 8 conductors, so I'm scheming ways to save conductors.

On the MCU end I'm running an 18F4620. On the other end of the cable is an MCP23S17 (16-bit port expander from Microchip, runs over SPI.)

I need two for power and ground, two for USB D+ and D-, three for SDO SDI and SCL, two for CS and RESET, and one for a piezo speaker.

That's ten. I have eight conductors.

I can live without the reset function by tying it high permanently. That brings me down to nine.

I'm trying to eliminate the need for the chip select/enable wire going over the cable. What I'm thinking is tying it to GND on the port expander side (always enabled). I have other devices on the SPI bus though (SSR and USB chips), so I still need to regulate what goes over that line. So what I'm thinking of doing is using a NC7ST08M5X (2-input AND gate, https://www.fairchildsemi.com/ds/NC/NC7ST08.pdf), tying one input to the SDO line and one to a pin on the PIC. When I want to send data to the port expander, just pull that pin high so the SPI goes through the gate and off over the cable to the expander. I'd also have to pull down the SDO line on the port expander side of the cable to ground so it doesn't freak out from EMI. Any suggestions on the resistor value for this?

My SPI bus is running at about 1.25mhz, so I don't think switching speed would be too much of an issue (I hope.)

Did this make any sense at all? If so, does it sound like it would work?

 

[Tuxicle]

First, about the switching speed. At 1.25 MHz, you would be limited to about, say, 20 ft. of cable before you run in to problems with crosstalk and noise pick-up. The way around this is to use differential signalling (use AM26LS31/26LS33 or LVDS transceivers), but unfortunately that means more wires

If you have hefty driver chips like a 74AC244 driving these lines, you can even go down to 50 ohm termination. It won't be enough if your cables are too long, though.

Here's a thought: you have some USB chip on the SPI bus, why not put it on the remote end rather than running the D+ and D- wires through the Cat-5? You will need a pair of CS signals, then, but that looks like a total of 8.

 

[Nigel Goodwin]

You don't mention what you're trying to do?, so it's really impossible to make any sensible suggestions - do you need any great amount of speed to the remote I/O lines? - if not all you need is a single wire, and a PIC at the far end.

 

[rackley]

You don't mention what you're trying to do?, so it's really impossible to make any sensible suggestions - do you need any great amount of speed to the remote I/O lines? - if not all you need is a single wire, and a PIC at the far end.

That was originally the plan (the PIC on the other end) but I can do about 95% of what I need to do through a port expander. I need 10 pins on the far end for 4-bit LCD output and checking the state of four push-buttons. These can all be handled by the expander. Plus, the expander is $0.95 while PICs that fit the requirements seem to be more in the $4-5 range (min), and basically all I'd be using the PIC on the far end for is a glorified port expander anyhow.

The plan is to have two versions of what is currently a one-version only product, a regular version and a budget version. The regular has the ECU and a nice keypad w/LCD display for monitoring & configuation, and the budget is the ECU half only with USB-only monitoring & config. If you're interested, there are some pics of the current one using a 14-pin ribbon cable here (**broken link removed**, **broken link removed**. No real bearing on the question but if you're interested..

Since the ECU is normally buried somewhere out of sight, this is why, as Tuxicle pointed out, I have D+ and D- going over the cable as I have another mini-B connector on the keypad for easy access. The PIC is locally (on the same PCB) driving another MCP23S17 expander which drives a FT245RL chip for USB communications. Since the ECU needs to be able to do USB communications on it's own that's why the USB chip lives there.

Someone actually pointed out to me on my compiler's forum that I'd want to cut off SCK and not SDO because if I cut SDO it will clock in a bunch of zeros, so I've made modifications to that effect.

With regard to cable length, 6-8 feet will be the maximum distance but since it's in a car EMI is always in the back of my mind. Would sticking a ferrite bead on one or two of the lines help?

Does that help with background info?

Thanks,
Ray

 

[Nigel Goodwin]

As you don't have enough wires to run a port expander, then using a PIC instead seems to make sense!.

 

[rackley]

Agreed, but if I can use one or two $0.10 logic gates to save $5 per part + the time to program a second PIC, that adds up quickly. Over just 50 parts that adds up to about $250..

 

[Nigel Goodwin]

Agreed, but if I can use one or two $0.10 logic gates to save $5 per part + the time to program a second PIC, that adds up quickly. Over just 50 parts that adds up to about $250..

Then just add more wires!.

 

[evandude]

What speed is this USB device? Running USB through a cat5 cable with other signals is a gross violation of the USB specs, and you could run into trouble. Low speed (1.5MB/s) isn't as picky and doesn't require nice shielded cables, but I still wouldn't be surprised to see issues when it's wrapped up with other signals over a distance of 8 feet (which is only about a foot shorter than the maximum specified length)... and if it's full-speed or high-speed, I would fully expect issues since it's not getting the dedicated, shielded cable it is meant for...

Though, I suppose if you already have it working with a ribbon cable, then cat5 can't be too much worse...

 

[Tuxicle]

Given that your operating environment is a car, go with differential signalling. Single-ended will bring you nothing but grief, especially since the SPI protocol has no checksum/error detection. If you can afford it, invest in shielded twisted pair, and connect only one end of the shield to ground.

 

[rackley]

Low speed USB, there is no need for high speed for this application. I see your point about the max length specified by the standard.

The USB isn't currently going over the ribbon cable.

I can use shielded Cat5, it isn't TOO much more than regular UTP if you shop around. Example, **broken link removed**. Do you think that should help address possible issues with the SPI signaling as well, or will I still run into issues with it? Are there any other simple components that can be used to try to clean up an SPI signal such a ferrite beads or some kind of magnetics?

I don't want to give up the SPI if I don't have to, since that means sticking another PIC + associated components (caps, crystal, etc) on the other end, which increases complexity and costs..

 

[Nigel Goodwin]

I don't want to give up the SPI if I don't have to, since that means sticking another PIC + associated components (caps, crystal, etc) on the other end, which increases complexity and costs..

Use a PIC with an internal oscillator, a 16F628 will give you 16 I/O pins (with restrictions on some) in an 18 pin chip - certainly as far as complexity goes, it will be less complex.