MPC823: i2c-algo-8xx read interrupt?

MPC823: i2c-algo-8xx read interrupt?

[bart]

Hi,

When testing with i2c reading an eeprom on a MPC823e I get the message "IIC
read; complete but rbuf empty". IMHO this is because the interrupt in the TX
buffer is enabled intead of the the interrupt of the RX buffer. Is this a bug
or is there a reason behind this?

Best regards,
		Bart Thissen,	Ardis Technologies bv


i2c-algo-8xx.c: cpm_iic_read

Original (with TX interrupt and warning)

	tbdf->cbd_datlen = count + 1;
	tbdf->cbd_sc =
		BD_SC_READY | BD_SC_INTRPT | BD_SC_LAST |
		BD_SC_WRAP | BD_IIC_START;

	rbdf->cbd_datlen = 0;
	rbdf->cbd_bufaddr = __pa(buf);
	rbdf->cbd_sc = BD_SC_EMPTY | BD_SC_WRAP;



With RX interrupt (without warning):

	tbdf->cbd_datlen = count + 1;
	tbdf->cbd_sc =
		BD_SC_READY | BD_SC_LAST |
		BD_SC_WRAP | BD_IIC_START;

	rbdf->cbd_datlen = 0;
	rbdf->cbd_bufaddr = __pa(buf);
	rbdf->cbd_sc = BD_SC_EMPTY | BD_SC_WRAP | BD_SC_INTRPT;

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC823: i2c-algo-8xx read interrupt?

[Dan Malek]

bart@ardistech.com wrote:


> When testing with i2c reading an eeprom on a MPC823e I get the message "IIC
> read; complete but rbuf empty".

What speed processor and what kernel?

> .... IMHO this is because the interrupt in the TX
> buffer is enabled intead of the the interrupt of the RX buffer. Is this a bug
> or is there a reason behind this?

The transmit and receive run concurrently on the I2C controller.  This is why
the transmit interrupt is always used.  Basically, on a read the transmit
buffer contains the device information to be written, and when the bus is
turned around the received data ends up in the receive buffer.  The transmit
provides all of the timing for the bus, which is why you need a "dummy"
transmit buffer that includes the length you want to receive.

A couple of things could be happening.  One is that the latency of clearing
the receive BD ready flag is longer than the interrupt processing overhead, but
I don't believe this is the case except that you say when you wait for the
receive interrupt it works OK.  Another is that the device isn't properly
terminating the I2C transfer (you tell it to transfer more bytes that the
dummy transmit clocks out), so you have to wait for a recieve time out to
close the BD.  If you wait for the receive interrupt, are there any errors
posted in the BD?  Does the receive buffer contain the proper data even when
the transmit complete occurs?

One of the reasons for using the transmit interrupt is when there are receive
errors, you still get an interrupt to go looking at the receive BD.  Maybe
the newer parts work differently and we need to accomodate this.

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC823: i2c-algo-8xx read interrupt?

[bart]

>
> > .....  Alternatively, turn off the TX
> > interrupt and use the RX interrupt instead....
>
I turned of the TX interrupt and used the RX interrupt, and this very often works :(
But not always. Approx. one out of 300 reads (reading one byte off a I2C expander chip)
the RX interrupt gets 'lost' (in the CPM?). Maybe the distance in time between the RX
and TX internal interrupt flags get to close and one of them wins? Or something like
Wolgang Denk found in RISC timers overwriting port B data register, but now parts
of the RISC software competing for the I2CER?

Anyway, I now use the TX interrupt again because the RX is not reliable.

	Bart

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC823: i2c-algo-8xx read interrupt?

[Dan Malek]

bart@ardistech.com wrote:


> The way I interpret the data sheet (I assume the 823 and 860 are similar) is that I get the TX
> interrupt when the I2C address is sent plus the two character times. The rest of the TX buffer
> is just a place holder and will not be sent.

Not correct.  The data isn't sent on the data lines, but the CPM decrements the
counter and uses it to time the receive transfer.  The I2C thinks it is sending
something, but the bits just fall off the sand into a bucket.  It is used to generate
the timing of the clock and count how many receive bytes you wish to acquire.

> .... The RX interrupt is fired when all the RX bytes are
> received and written to mem.

How do you know when you have received the proper number of bytes?  Are we
always changing the value of mrblr (I don't remember the code anymore)?

> So I assume waiting for two char times would not help.

You could just poll the receive buffer for about two plus a little character
times.  If you don't get the empty flag cleared in this time report some error.

The interesting thing about any I2C controller is the overhead of trying to
manage this thing is higher than just clocking bits in software.  I seldom
use the I2C controller, just a few lines of C code to do the job.  Think about it.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC823: i2c-algo-8xx read interrupt?

[bart]

Dan Malek wrote:

>
> How do you know when you have received the proper number of bytes?  Are we
> always changing the value of mrblr (I don't remember the code anymore)?
>
I knew about the TX counter being used for the number of RX'd bytes, but expected
the RX interrupt to be the last one, after the RX buffer was closed (This often
seems to be the case, as long as the RX interrupt does not dissapear).

>
> You could just poll the receive buffer for about two plus a little character
> times.  If you don't get the empty flag cleared in this time report some error.
>
I think that's the best solution.

> The interesting thing about any I2C controller is the overhead of trying to
> manage this thing is higher than just clocking bits in software.  I seldom
> use the I2C controller, just a few lines of C code to do the job. Think about it.
>
You're right, but spending XX$ on a fast PPC chip and after that let it run
busy loops to time the I2C control makes me feel bad :)

	Bart

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: MPC823: i2c-algo-8xx read interrupt?

[Pergola, Michael]

	>> The way I interpret the data sheet (I assume the 823 and 860 are
similar) is that I get the TX
	>> interrupt when the I2C address is sent plus the two character
times. The rest of the TX buffer
	>> is just a place holder and will not be sent.

	>Not correct.  The data isn't sent on the data lines, but the CPM
decrements the
	>counter and uses it to time the receive transfer.  The I2C thinks
it is sending
	>something, but the bits just fall off the sand into a bucket.  It
is used to generate
	>the timing of the clock and count how many receive bytes you wish
to acquire.

According to the MPC823e User's Manual:

"The I2C receiver and transmitter are double-buffered, which corresponds to
an effective
FIFO size of 2 characters. The MPC823e I2C bit 0 (MSB) is shifted out
first." pg. 16-456

I interpret this to account for the additional two character clock times
you'll need to do.

Just my $.02,
     Michael Pergola
     Software Engineer
     Baltimore, MD  21236     (410) 931-6778 x4259


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC823: i2c-algo-8xx read interrupt?

[Dan Malek]

bart@ardistech.com wrote:


> You're right, but spending XX$ on a fast PPC chip and after that let it run
> busy loops to time the I2C control makes me feel bad :)

So, you think interrupt and management overhead of the software to send a
couple of bytes on a 100k serial interface is free?  The chip designers are
often upset when you don't use every feature, but you need to apply some
real systems engineering methods and analyze how all of these little things
help (or hurt) your application.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC823: i2c-algo-8xx read interrupt?

[bart]

Dan Malek wrote:
>
>
> So, you think interrupt and management overhead of the software to send a
> couple of bytes on a 100k serial interface is free?  The chip designers are
> often upset when you don't use every feature, but you need to apply some
> real systems engineering methods and analyze how all of these little things
> help (or hurt) your application.
>
Most important reason for me to do the i2c with the RISC is the scalebility:
if the application needs to do a lot more i2c io as expected it won't affect
the overal performance.

	Bart

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/