I have a question on I2C trace layout, I know it is considered a bus, and one would run the SDA/SCK lines from one device to the next.
I'm laying out a pcb and have four devices, one master, three slaves, is it ok to run the bus lines in a star configuration from the master to the three devices?
Or must it be daisy chained from one to the other?
The PCB is approx. 3x5 inches, 100kHz bus speed, the three slaves are spread across the pcb with the master some what in the middle of the board.
Jim
Does the I2C spec offer any guidance?
...100kHz bus speed...
100kHz? That's positively DC territory!
On board that size, or indeed down several feet of cable, you'll not have a problem. If your edges look a bit slow you can always drop the value of the pull-up resistors.
Oh, BTW, don't forget the pull-up resistors or you'll end having to bodge add them on...
Thanks Brian, been there, done that already in the past!
Jim
I believe the main issue with I2C is to keep capacitance down.
Maybe make the clearance between traces a bit larger then usual?
When finished check signal quality with a scope.
Uses lower value pullups if rising flank is too shallow.
Edit (addition):
Philiips (nxp) has written an AN about I2C signal integrity guidelines.
At the speed you give, signals are almost "DC". I've done chains and have done stars, with no obvious performance effect. There are three things to watch for, but only one really effects you.
1. Transmission termination effects. When this happens, a reflection from the far end of the line "interferes" with the signal. But, when you look at a really fast edge on a long period signal, what you see is indistinguishable from the RC rising time constant. Except, if you look at it REALLY closely, you can see that the edge is made up of little steps. Why is it not an issue? Well, the propagation velocity on a circuit board is around 1.3ns per foot. So, the echo will come back in about 2.6ns on a foot long trace. AVR port pin rise times are around 10ns so you never see it, and even less so, if it is a physically small bus.
2. Skew between clock and data. Again, the important number is propagation velocity. if there were a 6" difference in trace length between data and clock, the skew would be about 0.6ns. Again, invisible with 10ns rise/fall times.
3. Trace capacitance. This is a bigger effect on rise than on fall because there is a low resistance NMOS transistor to ground, discharging the line capacitance rapidly. On the rise, the is a pull-up of several hundred ohms or higher. So, inherently, Trise > Tfall. The higher the line capacitance, the higher the energy to clock a byte of data. This CAN be important in battery operated systems. Also, the higher the capacitance, the lower the pull-up resistance has to be (to produce an acceptable rise time) and, again, more energy is used every time a line is pulled low.
Many true I2C devices have a controlled slow fall time to minimize EMI transmission line effects. Not sure what AVRs do.
West Coast Jim
Thanks guys, I have downloaded the NXP spec and some interesting app notes too.
All good advise!
Fly over Jim
ts. Not sure what AVRs do.
Good old M8 is slew rate limited for I2C.
• SCL/ADC5 – Port C, Bit 5 SCL, Two-wire Serial Interface Clock: When the TWEN bit in TWCR is set (one) to enable the Two-wire Serial Interface, pin PC5 is disconnected from the port and becomes the Serial Clock I/O pin for the Two-wire Serial Interface. In this mode, there is a spike filter on the pin to sup- press spikes shorter than 50 ns on the input signal, and the pin is driven by an open drain driver with slew-rate limitation.
ATTINY2313 is not.
Two-wire Mode The USI Two-wire mode does not incorporate slew rate limiting on outputs and input
noise filtering. Pin names used by this mode are SCL and SDA.
I found this pretty dissapointing wen I tried to build a multi processor system.
Idea was to offload keyboard scanning & lcd display to a 2nd cpu so I could easily add user I/O to a uC on a breadboard via I2C.
I wanted I2C Especially because of the slew rate limiting after I found that 4x4 keyboard scanning generated lots of noise on ciruits build on veroboard or breadboard (No ground planes etc).
ATTiny214 has I2C (twi instead of usi) but no mention of slew rate limiting in the data sheet.