Lpc2000

The documentation is not wrong, but it may be incomplete. The actions 
are correct, you just have to add that clearing the SI bit must be the 
last action you do.
In master receiver mode you have to tell the I2C controller to ack or 
not to ack before the data is received, not during the interrupt after 
receiving the data byte.

Richard.


andersryl wrote:
> Thanks for the quick reply.
>
> If I interpret you correctly I can control the "reponse" to the data
> bytes by altering AA BEFORE clearing the SI bit (not an exact quote
> of your reply I hope ;)).
>
> If this is correct the document IS wrong! Because the Ack that the
> document says has been returned has NOT been returned. And might not
> be returned at all if AA is cleared before the SI is cleared.
>
> Correct?
>
> /Anders
>
> --- In lpc2000@yahoogroups.com, Richard Duits <yahoo@...> wrote:
> >
> > The next byte is received/transmitted on the I2C bus after you
> clear the
> > SI bit. So if you set/clear AA before or in the same write as the
> SI bit
> > you also can control the ACK in the first byte.
> >
> > Richard.
> >
> >
> > andersryl wrote:
> > > Hi,
> > >
> > > I'm writing a driver for the I2C-bus on a LPC2214. The idea is to
> > > avoid busy waiting and instead use the I2C interrupt for
> capturing
> > > events on the I2C-bus. My uC will at all times act as the bus
> master
> > > and will transmit as well as receive data.
> > >
> > > I have studied
> > >
> http://www.semiconductors.philips.com/acrobat/various/8XC552_562OVERV
> > > IEW_2.pdf for guidance but one thing puzzles me.
> > >
> > > In table 4 (page 24) on the row describing 0x50 status code, the
> > > column stating what has happened on the I2C-bus in order to reach
> > > the 0x50 "state" must be wrong!
> > >
> > > It says: "Data byte has been received; ACK has been returned"
> > >
> > > This means that the master has already sent an ACK for the
> received
> > > byte from the slave before the interrupt is activated (and the
> > > status code is set).
> > >
> > > Depending on what AA then is set to, the next byte from the slave
> > > will be Acked/Nacked (transmission stopped). One is hence forced
> to
> > > receive at least two bytes since the action after the first byte
> > > always is "ACK".
> > >
> > > My guess is that the document is wrong. The interrupt should
> occur
> > > right after the byte has been received and BEFORE the Ack is
> sent,
> > > right?
> > >
> > > I'm greatful for clarifications regarding this.
> > >
> > > /Anders
> > >
> > >
> > >