Lpc2000

OK. This time I got it. One have to "prepare" for the coming byte; 
Set AA to 0 if the next incoming byte is the last.

I guess there are reasons for implementing the I2C-protocol in the 
LPC this way but I think it's kind of backwards.

Anyway, thank you for clearing this out!

--- In lpc2000@yahoogroups.com, Richard Duits <yahoo@...> wrote:
>
> 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
> > > >
> > > >
> > > >
>