SPI, circuit board routing

[CarbonWerkes]

Hello-

Im converting an MCU<->MCU interface from I2C to SPI. Problem is, the MCUs are on different PCBs- where one is on a daughter card connected via standard IDC Header/socket. The trace length is minimal- 6" or so. But, I have no experience with routing high-speed signal lines; the I2C version works well (electrically, anyway), but that is at 100khz clock.

Aside from the standard guidlines on EMF/ground planes, can anyone provide me any guidance on dos and donts regarding this type of signal path? That is, are vias OK? Will an IDC header/socket support SPI signaling without horrible reflections, etc? Since this header is effectively the same as is used in a PC IDE motherboard, and since an IDE interface is running with a clock of at least 8Mhz, Im hoping SPI is not a big deal in terms of routing.

Any guidance is appreciated-

Regards,
R

 

[itsmoked]

See the light did we?

SPI has speed limits too. What speed are you planning to use? Hint: Use the slowest that will serve your needs.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[MacGyverS2000]

It's not the frequency you necessarily need to worry about (especially at 100kHz!), it's the rise/fall time of the signal... that's where the problems come into play.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[itsmoked]

Well it is the general point... And SPI can really crank in some cases, multi-Mhz.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[CarbonWerkes]

Hi Keith/Dan-

Thanks for the responses. Im not really 'anti-I2C,' it has worked for me in the past. But clearing the bus can be a pain, and it seems that the interface to most support devices Im looking to implement (FPGAs, Flash, EEProms, etc) is SPI (presumably, a speed thing, but maybe a royalty thing also??).

On clock rate, I dont really need much more than 100Khz, but I think my fastest devices are 2Mhz-capable. So, if I can approach 1-2Mhz, that will free up bus time. Unfortunately, with PICs anyway, you have such limited RAM that the concept of 'bursting' data is prety silly; at most I have 1K RAM available, so my ability to store and forward tons of data is limited.

Here is an added problem though- I have some daughter cards that are I2C-based. So, at least for development, it would be better to have the main bus be I2C and SPI capable. For the PIC, this means external pullups on SDA/SCL. Since those pins are multiplexed with SDI/SCK, Im wondering if those pullups will screw up the SPI comms? On my dev board, with pullups enabled, SPI seems to work just fine- but I cant find any spec from Microchip on the internals of their SPI module (if it is push/pull, open drain, etc), so this remains another unknown. You guys have any ideas?

And on rise/fall times, is this mostly a function of keeping trace length and capacitance down? I have some docs on USB routing- and presumably the rules are similar- but I expect that the clock rise/fall time with SPI is a different animal.

Regards,
Rob

 

[itsmoked]

1-2MHz.. Give it no further thought. It will work fine.

The pullups won't be a problem either. Rise and fall times will not be an issue with those PIC pins. Nor will the connector.

Have at it.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[geekEE]

If you're running across a ribbon cable, it would be best to make sure your return path (ground) is close to your I2C lines. It would be ideal (possibly overkill) if you could alternate ground and signal lines (but not always possible, depending on space and cost), but at least make sure you don't have your I2C lines and ground are not far apart.

 

[CarbonWerkes]

Thanks Keith- if the proto PCB fails, I know where you work

Much appreciated on all the feedback- now if I could just figure out why SPI-based SD storage is so slow! Ugh.

Rob