Searching \ for 'PICs and I2C Specification' 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: 'PICs and I2C Specification'.

Truncated match.
PICList Thread
'PICs and I2C Specification'
1999\03\03@163006 by io Carlos da Palma

flavicon
face
Hi!

Does PIC16C74B implement fully I2C specification (Philips I2C specification)?
Has it implemented broadcast address or reserved addresses? The data sheet
tells nothing about.

Thank you.


               Emilio C. Palma
               spam_OUTecdpalmaTakeThisOuTspamicmc.sc.usp.br

1999\03\04@001803 by Tjaart van der Walt

flavicon
face
Emilio Carlos da Palma wrote:
>
> Hi!
>
> Does PIC16C74B implement fully I2C specification (Philips I2C specification)?
I has enough hardware to implement an I2C slave.
The master function is best done in code, and is very easy.

> Has it implemented broadcast address or reserved addresses? The data sheet
> tells nothing about.
The I2C slave hardware is 'dumb'. You have to set up the address etc.

Beware : I2C slaving on the PIC is not a walk in the park.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
.....tjaartKILLspamspam@spam@wasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
| Mobile : tjaartspamKILLspamsms.wasp.co.za  (160 text chars) |
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\03\04@081714 by Andy Kunz

flavicon
face
>Beware : I2C slaving on the PIC is not a walk in the park.

It isn't too bad if you are using the slave hardware, though.

Andy


  \-----------------/
   \     /---\     /
    \    |   |    /          Andy Kunz
     \   /---\   /           Montana Design
/---------+   +---------\     http://www.montanadesign.com
| /  |----|___|----|  \ |
\/___|      *      |___\/     Go fast, turn right,
                              and keep the wet side down!

1999\03\04@153602 by Gerhard Fiedler

picon face
At 07:27 03/04/99 +0200, Tjaart van der Walt wrote:
>Emilio Carlos da Palma wrote:
>> Does PIC16C74B implement fully I2C specification (Philips I2C
specification)?
>> Has it implemented broadcast address or reserved addresses? The data sheet
>> tells nothing about.
>The I2C slave hardware is 'dumb'. You have to set up the address etc.

which means that "broadcast address" is essentially not supported, if i
understand it correctly, because you can set it up either to respond to
address 0 =or (exclusive)= to its own, and not to both. which would be
required for broadcast mode.

ge

1999\03\05@173802 by Gerhard Fiedler
picon face
At 18:33 03/03/99 -0300, Emilio Carlos da Palma wrote:
>Does PIC16C74B implement fully I2C specification (Philips I2C specification)?
>Has it implemented broadcast address or reserved addresses? The data sheet
>tells nothing about.

AFAIK, no broadcast address support. it reacts to whatever address you put
into the address register -- so it can react to the broadcats address, but
then =only= to that. it ignores all addresses which are not the same as in
its address register. 10bit addresses are realized by firmware control.
master mode is firmware also (you have hardware start and stop condition
detection for multi master mode).

ge

1999\03\08@170208 by John Payson

flavicon
face
|master mode is firmware also (you have hardware start and stop condition
|detection for multi master mode).

Out of curiosity, what fraction of I2C systems use...

... multiple masters in a single system ?

... clock-stretching ?

or [for that matter]

... anything other than a single EEPROM or other memory device?


It would seem that--although I2C is popular because it exists and only
uses two port pins--the protocol really is overkill in some ways for
the most common application (memory interfacing) and it not designed
optimally for that purpose.  I wonder what it would take for Microchip
to introduce a line of EEPROMs which used a different interface that
would be:

[1] Faster, even on PICs without hardware support.

[2] Less expensive in PIC resources, using only one I/O pin on most
   PICs (using the PIC's clock pin as the clock).

[3] Super fast on PICs which provided hardware support [e.g. sequen-
   tial memory reads in three CPU cycles].

[4] Royalty-free, since it wouldn't be I2C...

Not that I2C is terrible or anything, but for a common subset of
applications it would be possible to do MUCH BETTER...

1999\03\08@175016 by ry (Nahum Tchernihhovsky)

flavicon
face
We are using it a lot in multi processors network. It is used with 2 and 3
PICs + EEprom and a DTMF transmitter etc.
Cherry,.....nKILLspamspam.....visonic.com




John Payson <EraseMEsupercatspam_OUTspamTakeThisOuTCIRCAD.COM> on 09/03/99 00:03:45

Please respond to pic microcontroller discussion list
     <PICLISTspamspam_OUTMITVMA.MIT.EDU>

To:   @spam@PICLISTKILLspamspamMITVMA.MIT.EDU
cc:    (bcc: Nachum Tchernichovski/Visonic Ltd.)
Subject:  Re: PICs and I2C Specification




|master mode is firmware also (you have hardware start and stop condition
|detection for multi master mode).

Out of curiosity, what fraction of I2C systems use...

... multiple masters in a single system ?

... clock-stretching ?

or [for that matter]

... anything other than a single EEPROM or other memory device?


It would seem that--although I2C is popular because it exists and only
uses two port pins--the protocol really is overkill in some ways for
the most common application (memory interfacing) and it not designed
optimally for that purpose.  I wonder what it would take for Microchip
to introduce a line of EEPROMs which used a different interface that
would be:

[1] Faster, even on PICs without hardware support.

[2] Less expensive in PIC resources, using only one I/O pin on most
   PICs (using the PIC's clock pin as the clock).

[3] Super fast on PICs which provided hardware support [e.g. sequen-
   tial memory reads in three CPU cycles].

[4] Royalty-free, since it wouldn't be I2C...

Not that I2C is terrible or anything, but for a common subset of
applications it would be possible to do MUCH BETTER...

1999\03\08@193025 by Gerhard Fiedler

picon face
At 16:03 03/08/99 -0600, John Payson wrote:
>|master mode is firmware also (you have hardware start and stop condition
>|detection for multi master mode).
>
>Out of curiosity, what fraction of I2C systems use...
>
> ... multiple masters in a single system ?
>
> ... clock-stretching ?
>
>or [for that matter]
>
> ... anything other than a single EEPROM or other memory device?

i just started to think i2c is really good because it has these features.
like in a system with many 100s of rarely changing inputs: each set of
inputs is handled by a controller who acts as an i2c master and sends its
message out when it detects a change in its inputs, and the "master
controller" acts as an i2c slave. makes for a pretty flexible and easily
expandable system, and it seems to be especially suited for pics (except
for the fact that only the bigger ones have a hardware slave).

because of clock stretching i don't have to think about speed issues
between the different participating controllers.

for just eeprom it's probably not optimal, but i think it's a pretty well
designed protocol if you use it for more than one peripheral. it's a system
bus, not a memory-access bus.

which also means, that if you run out of memory in your chip (say you
already have the biggest available in there), you can put a second memory
chip on the same bus with minor changes in hardware and firmware. if you
have only one dedicated memory access pin, you're probably out of luck
here. maybe if the devices would also be addressable... would the vast
range of clock speeds be a problem? if you use the pic's clock, the memory
device has to be able to handle a 20MHz clock or more.

ge

1999\03\09@004232 by Lynx {Glenn Jones}

flavicon
face
As a matter of fact, my robot uses I2C extensively. not with multiple
masters, but other things. Also, i dont know if this is what you meant by
a faster bus, but I2C now has a High Speed mode capable of 3.4Mbits/sec.
Granted PICs cant go that fast, but its better than teh 400kHz fast mode.
For more info on my robot, please see
http://www.efn.org/~jones_gl/vadar.html

------------------------------------------------------------------------------
A member of the PI-100 Club:
3.1415926535897932384626433832795028841971693993751
058209749445923078164062862089986280348253421170679

On Mon, 8 Mar 1999, John Payson wrote:

{Quote hidden}

1999\03\26@093934 by tmariner

flavicon
face
The hardware module is better, but there are still a few pitfalls. We just
ran into a condition in a Pic 16C77 where the SCLK is held low in the
hardware slave RECEIVE mode. In the transmit mode, the Pic slave hardware
holds the clock low to give time to retrieve the data to be transmitted, but
no such feature is needed or specified for the receive mode. We think that
the problem is caused by a combination of getting a succeeding transaction
byte piling on top of one in SSPBUF, causing an overflow. The only way we
could fix it was to either a) master clear the Pic or b)set the SSP module
out of I2C hardware slave and then back in.

Since the Pics are involved in intercity high volume data transport of data,
in central offices, a hanging of the entire I2C bus is not all that funny!

Two questions:

1. Has anyone run across this problem? and what exactly causes it (So we can
stay out of those places.) We have a fix, but I really want to understand
the mechanism.

2. Is there a less drastic way of curing the problem?

Tom



> {Original Message removed}

1999\03\26@114432 by Barry King

flavicon
face
> The hardware module is better, but there are still a few pitfalls. We just
> ran into a condition in a Pic 16C77 where the SCLK is held low in the
> hardware slave RECEIVE mode.  In the transmit mode, the Pic slave hardware
> holds the clock low to give time to retrieve the data to be transmitted, but
> no such feature is needed or specified for the receive mode.

I2C spec allows a slave reciever to use clock stretching to slow down
the master, by holding SCL low.

BUT I don't see that this facility is supposed to be used by the
16C76 (which I use) nor presumably the '77 (same I2C hardware,
AFAIK).

> We think that the problem is caused by a combination of getting a succeeding t
ransaction
> byte piling on top of one in SSPBUF, causing an overflow.

An overflow into the SSP as slave reciever will cause the SSP to not
generate the -ACK pulse, but it is not supposed to lock SCL low.
(according to the specs)

> Two questions:
> 1. Has anyone run across this problem? and what exactly causes it
> (So we can stay out of those places.) We have a fix, but I really
> want to understand the mechanism.
Not exactly.  I had (have, its back! ) a lot of trouble with slave
TRANSMIT synch, where the SSP thinks there is another byte to send,
(I overran the transmitter and my "last" send byte got lost).  The
SSP is holding SCL low waiting for my code to write to SSPBUF.

The only way to stop the slave transmitter is to for the master to
not -ACK on its last byte (which is the usual I2C termination).  If
the master does generate -ACK, (or you get a fault that reads as
high) you HAVE to send another data byte.  Just setting CKP won't
cure it, there is no way to unlock SCL, short of a device reset.

> 2. Is there a less drastic way of curing the problem?
>
Once it's hung like this (which could happen in a noise induced
bus fault, I think) I have to write dummy bytes to the SSP under some
circumstances to recover.  Cycling the SSP off and back on DOESN'T
unlock it from this state.  Believe it or not.  Very ugly.

Loading a dummy byte into the SSPBUF, then setting CKP, then cycling
the SSP should work.  I hope.   I'm working on this now.  Anyone else
have any better ideas?  I'd love to hear them.

------------
Barry King, KA1NLH
Engineering Manager
NRG Systems "Measuring the Wind's Energy"
Hinesburg, Vermont, USA
KILLspambarryKILLspamspamnrgsystems.com
"The witty saying has been deleted due to limited EPROM space"

1999\03\26@122617 by David Reinagel

picon face
Tom,
       Perhaps not all PIC part are created equal.  But I have implemented
the I2C slave using the PIC14000 and it has worked flawlessly.  It does
run under interrupt control, and as I recall there was one queer interrupt
at the end of each transmission where looking at just the I2C status bits,
you make the wrong conclusion as to what state you are in.  To fix this,
I set a flag to let me know that the next I2C interrupt is at the end of
a transmission, and then everything worked great.

Dave Reinagel
RemoveMEdaverTakeThisOuTspamcisco.com

{Quote hidden}

1999\03\26@125320 by Andy Kunz

flavicon
face
>BUT I don't see that this facility is supposed to be used by the
>16C76 (which I use) nor presumably the '77 (same I2C hardware,
>AFAIK).

Better be - it's just a strapping of the same die!

Andy

  \-----------------/
   \     /---\     /
    \    |   |    /          Andy Kunz
     \   /---\   /           Montana Design
/---------+   +---------\     http://www.montanadesign.com
| /  |----|___|----|  \ |
\/___|      *      |___\/     Go fast, turn right,
                              and keep the wet side down!

1999\03\26@193320 by tmariner

flavicon
face
> An overflow into the SSP as slave reciever will cause the SSP to not
> generate the -ACK pulse, but it is not supposed to lock SCL low.
> (according to the specs)

True, my copy of the specs have no mention of irrevocable hanging of SCL,
but I am sure I am violating other limits (including SSPOV).
>
> Not exactly.  I had (have, its back! ) a lot of trouble with slave
> TRANSMIT synch, where the SSP thinks there is another byte to send,
> (I overran the transmitter and my "last" send byte got lost).  The
> SSP is holding SCL low waiting for my code to write to SSPBUF.

Found another interesting feature today. It seems as though the last stop
bit causes a SSP interrupt on the transmit (from the Pic in slave mode). It
looks as though the stop bit indicator is on in SSPSTAT, but strangely
enough, it comes through with the Write bit on (which was causing the
program logic to write an erroneous byte). I'll bet it is in the data sheet
or app notes, but being terminally lazy, I have not found it yet. Could this
be your SSP thinking you have another byte to send?
>
> The only way to stop the slave transmitter is to for the master to
> not -ACK on its last byte (which is the usual I2C termination).  If
> the master does generate -ACK, (or you get a fault that reads as
> high) you HAVE to send another data byte.  Just setting CKP won't
> cure it, there is no way to unlock SCL, short of a device reset.

I know the CKP won't write, but I loaded SSPCON with a XB (firmware
controlled master mode with slave idle, then restored the X6 (hardware I2C
slave, 7 bit address). This seems to always clear it in two days of
continuous running. Does you experience say that as soon as I turn my back
(or this gets mounted in a $500,000 intercity driver rack I am going to
lunch the entire I2C bus until I power down the whole thing?
>
> > 2. Is there a less drastic way of curing the problem?
> >
> Once it's hung like this (which could happen in a noise induced
> bus fault, I think) I have to write dummy bytes to the SSP under some
> circumstances to recover.  Cycling the SSP off and back on DOESN'T
> unlock it from this state.  Believe it or not.  Very ugly.

(See above -- I think I am successfully "turning SSP off and on" with the
mode, but haven't tried SSPEN.
>
> Loading a dummy byte into the SSPBUF, then setting CKP, then cycling
> the SSP should work.  I hope.   I'm working on this now.  Anyone else
> have any better ideas?  I'd love to hear them.

I'll look into that also.

My feeling is that the logic is under control in that I seem always to
detect the condition and reliably fix it. There is a month more testing and
I'm sure that my customer will let me know in 12 fempto seconds if I2C hangs
again.

1999\03\27@195916 by tmariner

flavicon
face
Evidently the Pic 14000 I2C is similar to the PIC 16C77 since I observed the
same phenomena and made a similar fix. I first tried looking at the P bit,
since it was on for the final interrupt, but it didn't seem to work, I
presume because of some additional strangeness in our program. In addition,
I have some worry about the interaction of the SSPOV bit in case we are late
in retrieving the SSPBUF. I would certainly prefer a solution without an
artifical flag, but it does seem to work.

Tom

{Quote hidden}

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