Re: [oc] I2C polling question

[Richard Herveille <richard@asics.ws>]

> > 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 .......?

I assume you are talking about "example 2". As described in the "commands" 
section there is an ISR stage between each byte transfer. But I assumed the 
ISR to be much faster than the I2C bus, so I made it look like a continuous 
transfer. Between each byte transfer the core will hold the SCL and SDA 
lines in the current state, which is low for SCL and transfer dependant for 
SDA.

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

Wow, this is a strange bug. Does the bug also occur in the new core 
version, or is it a bug in the old version ??


A final question/thought;
Is the I2C document unclear and should it be updated, or are these problems 
which should be handled by a FAQ (on the web-page) ??
If the document is unclear please send any comments/updates and I will 
incorporate them. If we should have some kind of FAQ please help to 
assemble it.

Richard

>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

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