Can i use i2c communication between two micro controllers(Not having internal I2C hardware)

if not having internal I2C arrangement. means "no hardware I²C" then get some processors that do.
a bit-banged I²C is fairly simple, but an I²C slave is just about the most difficult thing to implement.

Erik

can u use mores code?

If you don't have I2C, you can consider SPI or UART.

Or create your own synchronous protocol with two-way acknowledge of every bit (which solves the timing issue with bit-banged slave.

Thanks for your reply, Please can I have some detail explanation in creating my own synchronous protocol with two-way acknowledge of every bit. I am going to use two separate micro controllers(One is P89V51RD2 and other is 80C52) for different Tasks.But I will access contents of EEPROM for both controllers.Some times there is need to exchange some Status information between two controllers. I have few port pins available in first controller and all interrupts pins in second controller.
I am waiting for your valuable reply.
With regards,
Bhaskar,
bhaskar@blazeautomation.com

The standard SPI protocol lets the master send out data and a clock signal. Everything the slave does is based on the clock signal flanks.

But if the clock runs too fast while the slave is busy doing some task that takes a bit of time (maybe handling an interrupt) then the slave will miss bits.

This can be solved by using SPI but have the master freeze the clock after each bit, until it sees an acknowledge signal toggle from the slave. So you still have a synchronous communication, but with self-adjusting baudrate depending on how fast the slave can react to every single bit transfer.

If you read up on the SPI protocol, you really shouldn't need any more help to figure out how to get a bit-banged SPI master to "insert wait states" as needed to make sure the bit-banged slave can keep up.

whatever you do, besides using micros with hardware interfaces, you are VERY likely to get in timing trouble or "holdup trouble"

one scheme that could work if you have a free port and a few bits on both would be:
sender (S) set a byte on px toggle a bit that is connected to an interrupt on the receiver(R) the (R) ISR read the byte and toogle a bit that is conneted to an interrupt on (S) the (S) ISR then know the transfer is completed and can continue.

anyhow, save yourself some trouble and get some micros with a hardware interface (I²C, SPI, second UART, CAN, ...)

Erik

"holdup trouble": something does not get taken care of because some wait loop 'hangs' the micro

can u use mores code?

Do you really mean using MORSE code for multiprocessor communication ???

The simplest way to exhange data, is the UART already installed between the two '51s.

Morse is just an encoding - but it relies on careful timing. So the speed can't be higher than what the receiver is guaranteed to have time to poll (or handle interrupts for).

So Morse is basically one of several "one-wire" protocols possible. The Maxim/Dallas one-wire protocol is another. The common thing for one-wire protocols is that they use timing for both data and synchronization since they have only a single signal to play with.