Lpc2000

Sanjiwani wrote:

>Hi Everyone,
>
> 
>
>I am facing one problem in My Project.
>
> 
>
>Should we read ACK (Acknowledgement) Signal from I2C?
>  
>
You're using the exact correct word: should ...

It is not a must but there are some good reasons for checking the ACK.
Verifying the ACK makes sure that your I2C device still exists and that 
you are reading and/or writing the correct data.
The hardware of the I2C controller will take care of this (and make sure 
that you do not send a next byte before an ACK is received), but you 
should in your software that the ACKs are indeed received.

I just browsed through the user manual but cannot determine at a glance 
if it is possible to disable the check on the ACK or if there is a 
timeout that can be set in hardware.

Please note, there are 3 different types of devices (seen from an ACK 
point of view):

    1) Regular devices that always respons with an ACK immediately after 
receiving the databits.
    2) EEPROM devices that may strech the clock by holding the ACK until 
a programming cycle is complete
    3) special devices that never generate an ACK.

In this 3rd category you may find devices that have a "2 wire serial 
interface". Due to licensing issues these devices are not marked as I2C 
and may not generate an ACK pulse (but some do).
Also some LCD drivers that are marked as I2C may fall into this 
category. I used some on-glass mounted devices that do not generate an 
ACK because of power constraints.

Depending on "My Project" take care of the ACK:
If the end product is used to guard a petrol tank, I would flash lights 
and ring a bell if the ACK fails.
For a petrol pump I would place a warning on the screen and possibly put 
an "out of order" sign on the display.
For an I2C controlled printer on a POS, just continue without printing 
tickets and let the operator ring the bells ...

Good Luck,

       Rob