> > The final fix appears to be running the "100kHz" buss at > 104kHz.

> But do you have any idea why this fiex works (or rather: why the
> slightly lowe speed fails)?                  

I have absolutely no idea, which is why a problem with the clock speed
never occured to me before. I thought a 100kHz buss would tolerate
1% on a byte-by-byte basis. The only reason I looked at it now was
because of the remote possibility of line reflections or ringing or
something equally dopey (although even connecting the two PICs
together 1" apart made no difference). Slowing the clock down just
made it worse, so I tried speeding it up. Not until it reached +4% did
the comms become reliable and repeatable. Now I have four slave
boards attached to the master, and comms between them all is exactly
how I wanted it

I've run several tests with this today and it's as solid with the higher
frequency as it was unreliable with the slower. Everything works
perfectly. With the old speed, I was seeing things on the analyser
that just didn't make sense. Particularly a marker pulse I was putting
out on PortB5. I presume that the I2C module gets it's knickers in
a twist and the h/w messes up PortB, perhaps through some r-m-w
effect. I noticed a little improvement when the marker was moved
to PortA2

I understood the I2C module to be edge-triggered via SCL, not
sampled as RS232 is. Although not actually spelled out in black and
white, this is what I infer from the manuals and references. For
example, mention is made of bits changing on clock edge, the block
diagram is laid out as you'd expect a h/w shift register to be and so on.
Plus there's no explicit mention of a sampling rate


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist