reading Data using I2C

Since you have probably a _specific_ processor and a _specific_ sensor, I have to ask: Have you considered Google?

yes i tried, but fail, Atmel 89S52, and the sensor is TC74/TC74A0

What did you try?

How did it fail?

What debugging have you done to find the cause of the failure?

www.8052.com/.../160143

Here are some tips & techniques:

www.8052.com/.../120313

www.techonlineindia.com/.../Developing_a_good_bedside_manner.aspx

//External functions, and function prototypes
unsigned char lcdPutRomString(unsigned char lcdAdr, const rom char* s);

//Defines
#define LCD2S_I2C_ADR 80    /* Default LCD I2C address when both switches on back of LCD2S board are set to 0 */

void delay (unsigned long dly)
{
  unsigned long i;
  for (i = 0; i < dly; i++);
}

void main (void)
{
    unsigned char i;

    //Delay at while before writing to LCD display
    delay(200000ul);

    /////////////////////////////////////////////////
    //Send "Hello World" string. Sring is contained in ROM memory
    if (lcdPutRomString(LCD2S_I2C_ADR, "\fhello\nworld") == 1) {
        //An error will be returned if there is no LCD display on I2C bus for example
        //...... Handle Error!!!!!
    }

    while (1)
    {  /* ....... Main Program ...... */   }
}

/** Waits until the I2C bus is IDLE, and available to be used. */
#define i2cWaitForIdle()

/** Generate bus start condition, and waits until it is finished */
#define i2cPutStartAndWait()

/** Generate bus stop condition, and waits until it is finished */
#define i2cPutStopAndWait()

/** Tests if an ACK was received from the slave. Returns true if it was, else false. */
#define i2cWasAckReceived()

/**
 * This routine writes a single byte to the I2C bus,
 * and waits until the bus is idle before returning.
 *
 * @param data_out  Single data byte for I2C bus
 *
 * @return      Status byte for WCOL detection.  Returns 0 if OK, else 1 if error
 */
unsigned char i2cPutByteAndWait(unsigned char data_out) {
    if ( collision  ) {         // test if write collision occurred
        return ( 1 );           // if WCOL bit is set return negative #
    }

    while( doing );             // wait until write cycle is complete

    i2cWaitForIdle();           // wait until bus goes idle

    return ( 0 );               // if WCOL bit is not set return non-negative #
}

unsigned char lcdPutRomString(unsigned char lcdAdr, const rom char* s) {
    unsigned char i = 0;
    char c;
    rom char* p;

    i2cWaitForIdle();

    i2cPutStartAndWait();       //Write I2C Start Condition, and wait for it to complete

    //Write module address
    i2cPutByteAndWait(lcdAdr);

    //Only continue if slave sent ACK. If no slave present, no ACK is sent. If no slave with address sent is present, no ACK is sent.
    if(i2cWasAckReceived()==0) {
        i2cPutStopAndWait();    //Reset I2C bus
        return 1;               //Error
    }

    //Write "Write Parsed String" command
    i2cPutByteAndWait(0x80);

    p = s;
    while((c = *p++)) {
        //Write next character to LCD display
        i2cPutByteAndWait(c);
    }

    i2cPutStopAndWait();    //Write I2C Stop condition, and wait for it to complete

    return 0;   //OK
}
<end code>

You do two things.

1: You google for I2C support for your specific processor. And you also download the relevant datasheets/user manuals/application notes/... that are applicable for your processor.

2: You google for your specific sensor. And you also download the relevant datasheets/user manuals/application notes/... that are applicable for that sensor.

You should not expect to find a perfect match - someone who have a program that is using your exact processor and your exact sensor. But that is irrelevant. Whatever code you do find, you must still be able to understand the code or you will be 100% lost. Embedded programs are not turn-key. They always requrie adaptations. And that adaptation requires you to understand the code so you will know what you must adapt. Hence, there shouldn't be a problem to adapt a I2C code for your processor to send the correct addresses/commands to make use of your specific sensor.

Remember also that your school teacher expects you to learn something from this project. And he/she expects that you understands what happens when the program runs - how else are you going to explain the design and your thought behind the design?

Why claim "the answer" when it isn't?

Software delay loops like that, without connection to any hardware and without any defined side effect is not good to use.

Documentation like:

    //Delay at while before writing to LCD display
    delay(200000ul);

are not making anyone happy. How long is "at while"? Wouldn't it be much better to have a _real_ delay function and to be able to do: delay_ms(500) and know that you get a delay of 500ms +/- internal rounding/truncation?

Dummy code like:

/** Waits until the I2C bus is IDLE, and available to be used. */
#define i2cWaitForIdle()

is obviously not the answer to any problem.

Yes, that is basically the process described here: www.8052.com/.../160143

The most important tool here is the one between your ears - you need to think and understand.

it is posts like this that keep me sleep at night.

glad to be of service

it is posts like this that keep me sleep at night.

... if they also kept you asleep at day, so we did not get your snide remarks