Lpc2000

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
> >
> >
> >
> >
> >
> > SPONSORED LINKS
> > Microcontrollers 
> > <http://groups.yahoo.com/gads?
t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Inte
l+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=mfaAujKZXA2Z_
vxre9sGnQ> 
> > 	Microprocessor 
> > <http://groups.yahoo.com/gads?
t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+
microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=9jjd2D3GOLIESVQ
ssLmLsA> 
> > 	Intel microprocessors 
> > <http://groups.yahoo.com/gads?
t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3
=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=OMnZuqMZ
X95mgutt4B-tDw> 
> >
> > Pic microcontrollers 
> > <http://groups.yahoo.com/gads?
t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=
Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=Malspbd0T
4Rq3M4Q0nHrfw> 
> >
> >
> >
> > -----------------------------------------------------------------
-------
> > YAHOO! GROUPS LINKS
> >
> >     *  Visit your group "lpc2000
> >       <http://groups.yahoo.com/group/lpc2000>" on the web.
> >        
> >     *  To unsubscribe from this group, send an email to:
> >        lpc2000-unsubscribe@yahoogroups.com
> >       <mailto:lpc2000-unsubscribe@yahoogroups.com?
subject=Unsubscribe>
> >        
> >     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms 
of
> >       Service <http://docs.yahoo.com/info/terms/>.
> >
> >
> > -----------------------------------------------------------------
-------
> >
>