> No Sir, it takes much more than that. DO NOT code IIC without
> taking everything into consideration, it WILL be a (intermittent) disaster.

I *am* taking everything into consideration.
And this is not my first design using I2C, it's just the first one with
the I2C controller of the LPC932.

>>> Polling IIC has the disadvantage that you have to disable all interrupts
>>> while polling.
>> Why? I don't see this from the manual.
> Of course not, "the manual" expect you to use the hardware.

I *will* be using the hardware. All I intend is checking the SI flag
directly within my routines instead of letting it cause an interrupt.

If other interrupts were forbidden during I2C operation, this *must*
be mentioned in the manual. However, these chips won't sell then
since I2C communication can just take some time...

> There is a Philips appnote for IIC on the 932 that is basically
> codearchitect output with the slave parts removed.

I mentioned this AN in my first post. It's not much help in this case.

> ... with the codearchitect code you can verify your hardware
> before fooling around with the software.

The hardware works. Remember that I can already access the
peripherals with my primitive routines. I just need more detailed
information about the exact order of events and commands. This
is textually described in the LPC932 UM, but not precisely.