Searching \ for '[EE]: I2C Question' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/i2cs.htm?key=i2c
Search entire site for: 'I2C Question'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: I2C Question'
2001\01\03@045923 by Michael Rigby-Jones

flavicon
face
When a slave is sending data to a master, I know the master is supposed to
ACK every byte apart from the last one.  What I'm not sure about is:  Should
the master not produce the 9th clock at all, or should it produce a NACK?
I've read the Philips I2C guide and it's not very clear on this point, it
says at one point:

"If a master-reciever is involved in a transfer, it must signal the end of
data to the slave-transmitter by not generating an acknowledge on the last
byte that was clocked out of the slave"

However, a couple of pages later, a diagram clearly shows the master
generating a NACK at the end of the last byte.  Now, I have tried both on
some master code I have on a PC, and when it's talking to my PIC slave
device, both methods seem to work ok.  Anyone know which is correct?

Regards

Mike

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\01\03@051622 by Soren Knudsen

flavicon
face
> "If a master-reciever is involved in a transfer, it must signal the end of
> data to the slave-transmitter by not generating an acknowledge

not generating an acknowledge = not acknowledge = N ACK = NACK

> on the last
> byte that was clocked out of the slave"

YES, At last someone to help with something i know about:))

Happy Newyear to yall ;~} ( <-this is how my face WAS looking newyears eve:)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\01\03@053336 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Soren Knudsen [SMTP:spam_OUTpiclistTakeThisOuTspamPOST.CYBERCITY.DK]
> Sent: Wednesday, January 03, 2001 10:14 AM
> To:   .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
> Subject:      Re: [EE]: I2C Question
>
> > "If a master-reciever is involved in a transfer, it must signal the end
> of
> > data to the slave-transmitter by not generating an acknowledge
>
> not generating an acknowledge = not acknowledge = N ACK = NACK
>
Ok, I wasn't sure if these two actually meant the same thing.  I knew that
NACK was Not Acknowledge, but the master still has to send the extra clock
pulse, just with the data line high instead of low.  The Philips description
almost sounded as if the ninth clock pulse was never sent.


> > on the last
> > byte that was clocked out of the slave"
>
> YES, At last someone to help with something i know about:))
>
> Happy Newyear to yall ;~} ( <-this is how my face WAS looking newyears
> eve:)
>
Thanks for clearing that up, and Happy New Year to you as well :oO~~##@@#
<---don't ask....

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\01\03@112748 by Herbert Graf

flavicon
face
> When a slave is sending data to a master, I know the master is supposed to
> ACK every byte apart from the last one.  What I'm not sure about
> is:  Should
> the master not produce the 9th clock at all, or should it produce a NACK?
> I've read the Philips I2C guide and it's not very clear on this point, it
> says at one point:
>
> "If a master-reciever is involved in a transfer, it must signal the end of
> data to the slave-transmitter by not generating an acknowledge on the last
> byte that was clocked out of the slave"
>
> However, a couple of pages later, a diagram clearly shows the master
> generating a NACK at the end of the last byte.  Now, I have tried both on
> some master code I have on a PC, and when it's talking to my PIC slave
> device, both methods seem to work ok.  Anyone know which is correct?

    I think the confusion sets in because the I2C bus is not a tristate bus
but only a dual state. What the master has to do is "let go" of the data
line during a NACK, this allows the slave to "bring down" the data line. In
I2C every driver is open collector, it cannot bring a line up, but it can
bring a line down. Perhaps this is what Phillips is indicating, the master
"bringing the line up" which just means the master doesn't bring the line
down, the slave does that. Unfortunately I have never gotten reliable NACKs,
most of my slaves never seem to NACK, which can be a pain since I can't use
that method to detect if they are there, but that's OK. I am also working
through a PC interface. TTYL

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\01\03@162406 by Olin Lathrop

face picon face
> When a slave is sending data to a master, I know the master is supposed to
> ACK every byte apart from the last one.  What I'm not sure about is:
Should
> the master not produce the 9th clock at all,

The master always produces all the clock signals, including the one for the
ACK/NACK.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinspamKILLspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\01\03@162409 by Olin Lathrop

face picon face
> Unfortunately I have never gotten reliable NACKs,
> most of my slaves never seem to NACK, which can be a pain since I can't
use
> that method to detect if they are there,

You should get a NACK if no slave is connected to the bus at all because the
passive pullups will pull the data line high.  Something is seriously wrong
if this is not what you're getting.  It's probably not wired right if you
are using the built in MSSP module, or you've got a bug if it's a manually
programmed interface.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, .....olinKILLspamspam.....embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\01\03@163830 by Herbert Graf

flavicon
face
> > Unfortunately I have never gotten reliable NACKs,
> > most of my slaves never seem to NACK, which can be a pain since I can't
> use
> > that method to detect if they are there,
>
> You should get a NACK if no slave is connected to the bus at all
> because the
> passive pullups will pull the data line high.  Something is
> seriously wrong
> if this is not what you're getting.  It's probably not wired right if you
> are using the built in MSSP module, or you've got a bug if it's a manually
> programmed interface.

    It's a manually programmed interface and everything's works right,
except that. I live by a "if it's not broke don't fix it" mentality. All of
the devices I read will not produce 255 as a data result, so I used that to
determine if the device is present. Inelegant but it works. It's a hobby
project so I don't have to worry about problems down the road. TTYL

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\01\03@210453 by Olin Lathrop

face picon face
>      It's a manually programmed interface and everything's works right,
> except that. I live by a "if it's not broke don't fix it" mentality.

But is IS broke.  If it were my project, hobby or not, I would at least want
to uderstand what is going on.  Your error is with something very
fundamental.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, EraseMEolinspam_OUTspamTakeThisOuTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\01\04@041432 by Caisson

flavicon
face
> Van: Herbert Graf <mailinglistspamspam_OUTFARCITE.NET>
> Aan: @spam@PICLISTKILLspamspamMITVMA.MIT.EDU
> Onderwerp: Re: [EE]: I2C Question
> Datum: woensdag 3 januari 2001 17:28

Hey guys (& girls ofcourse :-) ,

> > When a slave is sending data to a master, I know the master is supposed
to
> > ACK every byte apart from the last one.  What I'm not sure about
> > is:  Should
> > the master not produce the 9th clock at all, or should it produce a
NACK?
> > I've read the Philips I2C guide and it's not very clear on this point,
it
> > says at one point:

The *Master* generates all clock's.  The *receiver* (either being the Slave
-or- Master) generates the ACK.  the *sender* (either being the Slave -or-
Master) provides the data.

> > "If a master-reciever is involved in a transfer, it must signal the end
of
> > data to the slave-transmitter by not generating an acknowledge on the
last
> > byte that was clocked out of the slave"
> >
> > However, a couple of pages later, a diagram clearly shows the master
> > generating a NACK at the end of the last byte.  Now, I have tried both
on
> > some master code I have on a PC, and when it's talking to my PIC slave
> > device, both methods seem to work ok.  Anyone know which is correct?

Look at the next :

The Master requests some data from a Slave.  The *request* is send to the
Slave, and therefore the Slave has to ACK every byte.  After that the
data-stream turns around, because the Slave send's the requested data to
the Master.  This means that the Master has to ACK every byte.  When it
does not want any more data, it just does not generate an ACK.

During all this time the Master privides the Clock-signals.


> Unfortunately I have never gotten reliable NACKs,
> most of my slaves never seem to NACK, which can be a pain since I can't
use
> that method to detect if they are there, but that's OK. I am also working
> through a PC interface. TTYL

Well, the above get's me confused.  You're saying that "most of my slaves
never seem to NACK" .  That's quite normal.  If the Slave comes at the end
of it's data-space, *most* of them just wrap-around, sending you the very
first byte.

Why do you want to have a NACK from a Device ?  The presence of an ACK is
the proof that a Device is present.  A NACK can mean that there is no
Device present at the choosen address, or that the Device does not want any
more data ...  Take your pick. (meaning, it's not the way to go)

Send a Write-address, and see if it get's ACK-ed.  If so , there is an
Device present.  If not, ... well, you get the picture :-)

Regards,
 Rudy Wieser

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\01\04@101337 by Barry King

flavicon
face
Hello Boys and Girls,

A few more things about this question of ACK/NACK:

> > Unfortunately I have never gotten reliable NACKs,
> > most of my slaves never seem to NACK, which can be a pain since I can't
> use
> > that method to detect if they are there, but that's OK. I am also working
> > through a PC interface. TTYL

The usual sequence is for the master to send a slave address (read or
write), the ACK/NACK of that address byte tells you whether the
device is present.

If it is, then when the data is transferred, each byte is ACKed by
the receiver.  As Rudy said, most slave-only devices e.g. EEPROMs,
always ACK data bytes written by the master, and always supply the
"next" byte when read, defining something reasonably sensible to do
with them (like a wrap around).

A master, when reading a slave, is SUPPOSED to not ACK (ACK bit is
high=NACK) the last byte it is reading to signal the slave that it is
done.  However, since the next event is either a stoP or Start bit,
most slaves will work fine if the master doesn't NACK the last byte,
because the transaction is aborted by the P or S anyway.

To be robust, one must handle the cases where the master is reading
more bytes then the slave transmitter is expecting to supply.  Most
notably, if your PIC SSP module is doing a slave transmit, it WILL
LOCK SCL low while waiting for the next byte to be loaded into the
SSP.  Firmware MUST supply another byte if the master asks (by ACKing
the previous byte), even if the byte count is "wrong".  I got bit by
this when I had bus errors. The slave thought he sent all his bytes
then went back to doing something else and left the SSP holding SCL
low, locking up the bus.  The only way to get the SSP out of slave
transmit mode (short of resetting the SSP) is to have the master NACK
that last byte.

Regards,

Barry.
------------
Barry King
NRG Systems "Measuring the Wind's Energy"
http://www.nrgsystems.com
Check out the accumulated (PIC) wisdom of the ages at:
PIC/PICList FAQ: http://www.piclist.com/faq

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\01\04@104136 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Barry King [SMTP:KILLspambarryKILLspamspamNRGSYSTEMS.COM]
> Sent: Thursday, January 04, 2001 3:01 PM
> To:   RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU
> Subject:      Re: [EE]: I2C Question
>
> To be robust, one must handle the cases where the master is reading
> more bytes then the slave transmitter is expecting to supply.  Most
> notably, if your PIC SSP module is doing a slave transmit, it WILL
> LOCK SCL low while waiting for the next byte to be loaded into the
> SSP.  Firmware MUST supply another byte if the master asks (by ACKing
> the previous byte), even if the byte count is "wrong".  I got bit by
> this when I had bus errors. The slave thought he sent all his bytes
> then went back to doing something else and left the SSP holding SCL
> low, locking up the bus.  The only way to get the SSP out of slave
> transmit mode (short of resetting the SSP) is to have the master NACK
> that last byte.
>
This is exactly why I asked the question.  I knew of this problem and had
coded my master software accordingly to send a NACK after the last byte.
However, after re-reading the Philips guide I wasn't sure if this was
correct, so I tried not sending anything after the last byte which also
worked fine.  Due to popular opinion I've switched back to sending the NACK
:o)

Regards

Mike

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\01\04@134407 by Herbert Graf

flavicon
face
> >      It's a manually programmed interface and everything's works right,
> > except that. I live by a "if it's not broke don't fix it" mentality.
>
> But is IS broke.  If it were my project, hobby or not, I would at
> least want
> to uderstand what is going on.  Your error is with something very
> fundamental.

    Perhaps it is broke from your point of view, but if everything else is
working fine and I use a different method to detect if a slave is present or
not I don't consider it broke. I spent days trying to nail it down and then
one day just decided not to bother, if it works perfectly except for that
then why tempt fate? TTYL

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\01\04@134623 by Herbert Graf

flavicon
face
{Quote hidden}

       Yes that's what I meant, none of my slaves seems to ACK, which is OK since
I use another method to detect them. TTYL

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\01\04@175126 by Bob Ammerman

picon face
> > >      It's a manually programmed interface and everything's works
right,
> > > except that. I live by a "if it's not broke don't fix it" mentality.
> >
> > But is IS broke.  If it were my project, hobby or not, I would at
> > least want
> > to uderstand what is going on.  Your error is with something very
> > fundamental.
>
>      Perhaps it is broke from your point of view, but if everything else
is
> working fine and I use a different method to detect if a slave is present
or
> not I don't consider it broke. I spent days trying to nail it down and
then
> one day just decided not to bother, if it works perfectly except for that
> then why tempt fate? TTYL

Well, fine for your hobby project, but I sure don't want you working on any
of my power plant stuff!

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\01\04@190124 by Herbert Graf

flavicon
face
That's why I said, for a hobby I'm happy. If it were actually for a customer
I wouldn't have let it leave my premises. TTYL

> {Original Message removed}


'[EE]: I2C question'
2001\05\25@173822 by Peter L. Peres
picon face
Hi,

I am unable to locate a piece of information about I2C in any manuals (of
parts and of the protocol proper, from Philips):

When a slave device is to transmit its data on the bus *when* does it turn
output:
a) after the 8th data bit of the host is sent (when clock goes low after 8th)
b) at some other time
c) does it *stay* low or output between this time and when the host raises
the 1st clock to read a byte from the slave (assuming that the first bit
to be read is a 0).
d) when does the slave release the data line after it has sent the last
bit of a byte: immediately after the last clock pulse goes low ?

For some reason (why ?!) there are no complete protocol transition
diagrams neither in the Philips spec (PDF file) nor in parts data sheets
(from Philips, and National in this case).

any help would be appreciated,

Peter

PS: This is for driving I2C 'otherwise' than with an open collector driver
on the host side (using a low end PIC where manipulating TRIS is
expensive). I will use Rp resistors anyway (see Philips I2C Spec and User
Guide).

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@184132 by Olin Lathrop

face picon face
> When a slave device is to transmit its data on the bus *when* does it turn
> output:
> a) after the 8th data bit of the host is sent (when clock goes low after
8th)

If you replace HOST with MASTER, then yes.  At this point the slave may
start driving the ACK bit onto SDA.  The bus must be stable with the ACK bit
by the time SCL goes high.

> c) does it *stay* low or output between this time and when the host raises
> the 1st clock to read a byte from the slave (assuming that the first bit
> to be read is a 0).

Between what time?  I don't know what "this" time is.

On a read, the slave controls SDA after the falling edge of SCL of the
master's 8th bit (which will be high indicating a read).  The slave
continues to control the bus until the end of its 8th data bit, at which
time the master writes the ACK bit to SDA.  Note that "owning" doesn't mean
"driving" since the lines are open collector.

> d) when does the slave release the data line after it has sent the last
> bit of a byte: immediately after the last clock pulse goes low ?

Yes.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, TakeThisOuTolinEraseMEspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\26@052015 by Peter L. Peres

picon face
Olin, thanks for answering, I'll make it clearer:

A SEEPROM is read using bit banged I2C. The SDA line is driven by a
tristate pin on a MCU (bit banged). The option to simulate an open
collector output using a tristate pin (by manipulating the tristate
control) is not available.

When reading a byte from the SEEPROM I have the I2C command sequence:

START> - SELECT> - ACK1< - ADDRESS> - ACK2< - READ< - ACK3? - STOP

The last ACK is not important (I never read bursts in this project).

The question was: *when* does the SDA line of the slave turn output and
back again for:

a) the first ACK1 (after SELECT):
a.1) when the 8th SCK pulse of the SELECT byte goes low ?
a.2) very quickly after the clock pulse of the first ACK1 rises (this may
or may not violate bus specs).
a.3) when does it turn off: together with the SCK dropping or later

b) the second ACK2 (after ADDRESS):
... see as above and
b.4) since the next byte will be sent by the slave, does the slave keep
the line low beyond the low-going SCL of the ACK2 until the whole word is
sent or not ?

I can answer all these questions using a scope for any single device but I
want a more complete picture if possible.

thanks,

Peter

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam.....mitvma.mit.edu


2001\05\26@100626 by Roman Black

flavicon
face
Peter L. Peres wrote:
{Quote hidden}

The Microchip "basic serial eeprom operation"
datasheet has some of the best I2C timing diagrams
i've seen yet which are well commented.

Many of the code examples I collected show the
ack as simply a "send bit" or "receive bit", and
even used the same code routines for handling acks
in this way. Like any send or receive bit the SDA
must be held stable for the entire time the SCL
is high, and it doesn't matter when SCL is low.
-Roman

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspammitvma.mit.edu


2001\05\28@035126 by Chris Carr

flavicon
face
----- Original Message -----
From: "Peter L. Peres" <RemoveMEplpEraseMEspamEraseMEACTCOM.CO.IL>
To: <RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU>
Sent: Monday, May 28, 2001 7:15 AM
Subject: Re: [EE]:


> Chris (Carr): do you mean this:
>
>  The I 2 C-bus and how to use it
>  (including specifications)
>  1995 update

Yes, but the latest Specification is here, I don't think any of the
changes will affect you though.
http://www.us.semiconductors.philips.com/
acrobat/various/I2C_BUS_SPECIFICATION_3.pdf

sorry I had to split the URL

>
> ? Cos' if you do, this is the document I referred to in my original
> posting.

Yes you did but for some reason the subject line went blank and the
thread to the original message was lost. My appologies.

>I will be using Rs as in Fig.24 in said document but still I'd
> like to solve the mystery. In the end I'll have to tristate I think, or
> use two pins on the host for SDA and a NPN as OC driver, or even a shottky
> diode and a resistor in antiparallel. Oh well, I tried hard.
>
I'm afraid you will, this might be of help, it refers to interfacing to a PC
parallel port but it could equally apply to any chip with a non open
collector output.

http://www-us.semiconductors.philips.com/acrobat/various/I2CPPP.pdf

If current consumption is more important than speed, you may want to
increase the resistor values although R1 and R3 are probably just about
right.

Chris Carr

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\28@035333 by Roman Black

flavicon
face
Peter L. Peres wrote:
>
> > Like any send or receive bit the SDA
> > must be held stable for the entire time the SCL
> > is high, and it doesn't matter when SCL is low.
> > -Roman
>
> It matters because my driver is NOT o.c. If the driver disagrees with the
> SEEPROM then silicon will fight silicon and someone will loose (probably
> the power supply, because this project runs on a single lithium cell). I
> am trying to avoid that.


Peter, that sounds unusual, the master must go
O/C to sense the ack! Unless you are using
a resistor and the master has two PIC pins,
one for send and one for sense.

Anyway I think the answer you are looking for
is that the slave inits the ack straight after
SCL for bit 8 goes low. It must maintain the
ack as low for the entire time of the next SCL
pulse, and after that SCL goes low it can release
it. Page 3 of the 24LC256 eeprom datasheet shows
Taa (eeprom SDA output) takes typically 900nS
to stabilise from the last neg-going edge of
SCL.
-Roman

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\29@094223 by Olin Lathrop

face picon face
> A SEEPROM is read using bit banged I2C. The SDA line is driven by a
> tristate pin on a MCU (bit banged). The option to simulate an open
> collector output using a tristate pin (by manipulating the tristate
> control) is not available.

This is a bad idea.  It can lead to race conditions and possible power
glitches.  If you have no open collector output available, you can make one
with an NPN transistor and a resistor.

> When reading a byte from the SEEPROM I have the I2C command sequence:
>
> START> - SELECT> - ACK1< - ADDRESS> - ACK2< - READ< - ACK3? - STOP
>
> The last ACK is not important (I never read bursts in this project).
>
> The question was: *when* does the SDA line of the slave turn output and
> back again for:

The slave is allowed to pull SDA low immediately after the falling edge of
SCL of the 8th bit of the address byte.

In general, a bit is over on the falling edge of SCL.  The SDA line is
allowed to change while SCL is low, and must be stable by the rising edge of
SCL.  Most devices clock in SDA on the rising edge of SCL, although it would
be legal to read SDA anytime SCL is high.  Unless you are the master, you
don't know when SCL is about to go low, so it is safer to sample SDA on the
rising edge of SCL.  In my software master IIC routines, I release SCL, then
sample SDA, then pull SCL low again.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, RemoveMEolinTakeThisOuTspamspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...