--- In l..., "jon.trem" wrote:
>
> It's very strange. When i add while(1); after
> I2C_transfer_byte(0x7E,0x30); Nothing happens! No LEDs is on which
> means that no START condition has been sent, or whatever. When I
have
> not while(1) LED1 and LED3 are on.
>

Be careful not to overlook the speed at which I2C is running and your
LEDs are blinking. How fast are your I2C clocks. Say it is 100 KHz. An
I2C write byte transaction is 20 bits on the wire at 10 uSec per bit
that is 200 uSec (plus a little more for overhead, ISR latency, etc.).
However, your LEDs are probably on for only a fraction of this total
time. If I remember correctly your eye has a hard time seeing stuff
below 10ms.

However, without looking at your code again how you are using the
LEDs. Would you expect both LEDs to be off if the transaciton
completed?

Since you have no test equipment you could try this approach with the
LEDS:

- Set one LED just prior to your call to I2C_transefer_byte( ).
- Set a second LED when the byte has been received in the I2C1 ISR.

That way, you won't miss it visually because of speed.

TC
Start a New Thread

In fact, the LEDs are not blinking. I just light them in some
interrupt cases and one they are on, I never put them off.
LED1 is on when I2C0STAT is 0x18 (SLA+W has been transmitted; ACK has
been received).

LED2 should be on when :
I2C0STAT is 0x28 (Data byte in I2DAT has been transmitted; ACK has
been received)
or
I2C0STAT is 0x30 (Data byte in I2DAT has been transmitted; NOT ACK has
been received)
or
I2C1STAT is 0x80 (DATA has been received, ACK has been returned)

LED3 is on when I2C1STAT is 0x60 (Own SLA+W has been received; ACK has
been returned)

Just LED1 and 3 are lighten up for the moment.
--- In l..., "tcirobot" wrote:
>
> --- In l..., "jon.trem" wrote:
> >
> > It's very strange. When i add while(1); after
> > I2C_transfer_byte(0x7E,0x30); Nothing happens! No LEDs is on which
> > means that no START condition has been sent, or whatever. When I
> have
> > not while(1) LED1 and LED3 are on.
> > Be careful not to overlook the speed at which I2C is running and your
> LEDs are blinking. How fast are your I2C clocks. Say it is 100 KHz. An
> I2C write byte transaction is 20 bits on the wire at 10 uSec per bit
> that is 200 uSec (plus a little more for overhead, ISR latency, etc.).
> However, your LEDs are probably on for only a fraction of this total
> time. If I remember correctly your eye has a hard time seeing stuff
> below 10ms.
>
> However, without looking at your code again how you are using the
> LEDs. Would you expect both LEDs to be off if the transaciton
> completed?
>
> Since you have no test equipment you could try this approach with the
> LEDS:
>
> - Set one LED just prior to your call to I2C_transefer_byte( ).
> - Set a second LED when the byte has been received in the I2C1 ISR.
>
> That way, you won't miss it visually because of speed.
>
> TC
>

Start a New Thread

--- In l..., "jon.trem" wrote:
>
> In fact, the LEDs are not blinking. I just light them in some
> interrupt cases and one they are on, I never put them off.
> LED1 is on when I2C0STAT is 0x18 (SLA+W has been transmitted; ACK
has
> been received).
>
> LED2 should be on when :
> I2C0STAT is 0x28 (Data byte in I2DAT has been transmitted; ACK has
> been received)
> or
> I2C0STAT is 0x30 (Data byte in I2DAT has been transmitted; NOT ACK
has
> been received)
> or
> I2C1STAT is 0x80 (DATA has been received, ACK has been returned)
>
> LED3 is on when I2C1STAT is 0x60 (Own SLA+W has been received; ACK
has
> been returned)
>
> Just LED1 and 3 are lighten up for the moment.

Thanks for the explanation of your LED usage. I'm not sure how else to
help you at this point without observing the I2C signals. Without test
equipment and the ability to observe the I2C signals you simply have
to walk through your code methodically. I can assure you that the
problem is with your code since I have successfully done what your are
trying to do (use I2C0 as a master and I2C1 as a slave) with interrupt
driven code.

TC
Start a New Thread