Frank A. Vorstenbosch wrote:

> True, but it is _the_other_way_around_ that might be giving headaches,
> like having an interrupt routine twiddle some bits on the same port as
> you're using for I2C, right in the middle of an I2C transaction.
Yes, you're quite right old bean. I did mention
"You have to avoid other I/O bits disturbing the I2C PORT bits."

> But you never set the state of the data register!!

Well, I do (just once) in the initialisation phase of my system.
I omitted this from my posting because twiddling the data register
bits is not done elsewhere in my general I2C code.
What you are doing is putting them in the right state (low)
at the start of an I2C message.
Which is probably easier than making every other routine
(that uses that port) leave things tidy for the I2C bits.


> OK, since you are so eager to point out that my code is wrong,

No offence meant.
I just thought you were doing the I2C bus by twiddling
the PORTB bits, rather than the TRISB bits.
I couldn't see if SDA was defined so that
        bcf     SDA
expanded to
        bcf     PORTB,2
or
        bcf     TRISB,2

> Of course, there is nothing in my code to protect the I2C from
> rogue interrupt routines doing RMW instructions on the same port.

I find a lot of difficulty lies with having to get lots of things
running together, properly choreographed.
I think I will eventually have to write some foundation code
like a real-time kernel that can manage processes and block/unblock
them. Time to dig out my M.Sc. notes I think! :-O