Re: [oc] I2C polling question

[Ujjal Bose <ujjal@cdotb.ernet.in>]

> I was referring specifically to this: When I want to write several 
> bytes to the slave, do I need to set the STOP bit explicitly when 
> transmitting the last char or do I first transmit it and _then_
> the problem.
--
This I2C core is byte based. So any multibyte transfer is broken down into
several 1 byte transfers. I think after the address phase (1 byte transfer
from master), every successive byte is transferred only after the
interrupt for the current byte transfer is serviced.The ISR for this
should be somewhat like this :
 a) read SR and verify that TIP='0'
 b) Write next byte into TXR
 c) Write into CR to set WR bit and IACK bit
This sequence is repeated for every byte transfer. Note that for the
address phase , additionally STA also has to be set in CR. Do not set the
STA/STO bits in any subsequent ISRs, until the last byte to be transferred
is written to TXR. In that ISR, set the STO bit along with the above
mentioned bits.
 -- I think the diagram given in the programming example in the spec doc
is slightly wrong bcos it shows back to back transfers : actually there is
a ISR phase in between. During that time the core will hold
SCL line low.Any comments Richard .......?
 
> Also, I found out by simulation
> that the TIP and ACK flags are not set properly, ACK being 0 at
> startup whereas it should be 1 (NACK!), and TIP being strobed

-- I think ACK being '0' or '1' during startup does'nt make any difference
in the functioning of the core. TIP shows '0' correctly. Also it is not
required to know the 'exact' moment when the byte goes out into the
I2C bus, as the processor will anyway get an interrupt on completion
 
 > 
> At read, do I need to issue NACK/ACK commands explicitly or implicitly,
> at the time the last byte being read or _after_ it is read. No mention
> of this in the docs. The example, once again does not scale to multiple

-- The I2C specs say that the I2C slave has to issue a ACK on every
intermediate byte transfers and a NACK on the last byte transfer for
write. I did'nt quite get what does implicit/explicit setting mean. The
I2C core does generate ACK/NACK on reads. 
-- One discrepancy I found when core is doing a slave read is that during
the first read (immediately after the address phase following a slave
ACK), the RxACK bit gets set. This happens almost immediately after 
the D7 bit transfer. I found no reason why  it should get set there. I am
yet to look into the code in detail , but any pointers ?

Regards, Ujjal.
 

> f.
> --
> To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml
> 



--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml