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/
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/
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/
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/