[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [oc] I2C polling question




>
>Ujjal Bose wrote:
> > 1) Initialise PRER to proper value (0x00A5).
>....
> > Thats all. After the read of 8 bits from the slave, the I2C core will be
> > giving ACK with proper timing.
>
>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_
>issue a STOP? If of any interest I will post code so I can pinpoint
>the problem.

Both is possible. You can set the STOP bit at the same time you set the 
last WRITE bit. The core will correctly transfer the last byte and then 
generate a stop bit.

>That is pretty unclear in the docs and does _not_ scale for
>multiple byte transfer!
>
>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!),

Hmm this is a strange remark, maybe you are right. At startup no transfer 
has been initiated so the ACK-bit is undetermined, I think both ACK and 
NACK are wrong, so does it matter what the flag is set to at startup ???

>  and TIP being strobed
>long _before_ the actual bits get set. This makes the detecion
>of actual moment when the byte has been output/input from the bus
>undetermined. Of course I might have misinterpreted the docs but
>I found no explanation about that.

This is not true. TIP is an active high signal, so Transfer In Progress is 
high ('1') as long as the core is transferring data. When TIP is negated 
('0') then all data has been send/read (including ACK bits).

>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
>byte transfer because there is no example as to what to do with the
>bytes that are _not_ last, i.e. those that an ack is necessary. Do I
>have to order the core to issue an ACK or does it do it automatically?

During reads from a slave device, the master-core issues ACKs automatically 
(it sends an ack to the slave). What kind of ack-bit (ACK/NACK) is sent is 
determined by bit3 in the command register. The ack-bit (CR-reg bit 3) 
should be set at the same time the READ bit is set.


>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