First I have to thank everyone who gave me info and pointers on this. I
have alot of reading to do now. I have a few more questions first.
Are the I/O pins on the 16C84 (or other Pics without built in I2C)
compatible with I2C directly (with pull ups) or do I need to attach some
piece of hardware in between the pins and I2C lines?
What are the advantages of using a Pic which has I2C capabilities built
into it? Do they contain instructions for I2C protocol? Is it a
hardware thing?
Thanks again.
Charles
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
> -----Original Message-----
> From: pic microcontroller discussion list
> [spam_OUTPICLISTTakeThisOuTMITVMA.MIT.EDU]On Behalf Of Charles Laforge
> Sent: Saturday, January 10, 1998 15:04
> To: .....PICLISTKILLspam@spam@MITVMA.MIT.EDU
> Subject: MORE... I2C protocol
>
>
> Hi
>
> First I have to thank everyone who gave me info and pointers on this. I
> have alot of reading to do now. I have a few more questions first.
>
> Are the I/O pins on the 16C84 (or other Pics without built in I2C)
> compatible with I2C directly (with pull ups) or do I need to attach some
> piece of hardware in between the pins and I2C lines?
No, the pins will work fine. If you are using the PIC as a lone master,
or
if you are using it as only a slave, than almost every PIC outthere would
work through bit banging. However, in a multimaster environment you would
need an open drain output, something the 16C84 does have, so it should work
for almost any situation. About the only thing you might need are pullups on
the data line, depending how you do it.
> What are the advantages of using a Pic which has I2C capabilities built
> into it? Do they contain instructions for I2C protocol? Is it a
> hardware thing?
Warning, the I2C hardware on the PICs that have it only does slave mode,
for master you will have to bit bang. Aside from that, if you are looking
for a PIC to be a slave, many people recommend using a PIC with the
hardware, it is just simpler. TTYL
>Are the I/O pins on the 16C84 (or other Pics without built in I2C)
>compatible with I2C directly (with pull ups) or do I need to attach some
>piece of hardware in between the pins and I2C lines?
1K pullups to Vcc should do.
>What are the advantages of using a Pic which has I2C capabilities built
>into it? Do they contain instructions for I2C protocol? Is it a
>hardware thing?
Not much. They can do I2C slave mode, but not master mode. And
master (and multi-master) are the real headaches. Note that Mchip
has put out some new PICs that supposedly support master and
multi-master mode (16c726 or something like that) in the hardware.
> Not much. They can do I2C slave mode, but not master mode. And
> master (and multi-master) are the real headaches. Note that Mchip
> has put out some new PICs that supposedly support master and
> multi-master mode (16c726 or something like that) in the hardware.
Master mode is the easiest by far, especially if you restrict yourself to
EEPROM chips that don't implement the entire protocol (some I2C chips use
clock-based flow control, but I've never seen an EEPROM that did) and if
your chip is the only master on the bus. Multi-master is probably the
hardest, because you always need to be aware of what's happening on the
bus even when it doesn't directly concern you. This latter part makes
multi-master systems essentially impossible without hardware assistance
since the only difference between a "1" data bit and a "stop" is the order
in which the clock and data wires change state (and they may happen within
a microsecond of each other!). Even if the bus appears idle (both wires
high) you can't know if it really is unless you saw the data-wire state on
the last rising edge of clock. Fortunately, the I2C PICs have a circuit
for just that purpose; I don't know whether they handle all the tricky det-
ails just right, but it should be possible to do multi-master I2C on them.
Personally, I find myself sometimes wondering why I2C is so popular? It
would seem that for the common case where a single micro hooks up to a small
number of devices over a short distance other protocols could be simpler and
faster (and cheaper--no I2C $$royalties$$). What I'd like to see I think
would be a memory chip which could use the PIC's CLKOUT wire along with one
data pin; the data rate could then be set for CLKOUT (for PIC's with special
hardware for that purpose) or CLKOUT/12 (for PIC's without such hardware).
To make 8x51 fans happy, a CLKOUT/36 mode could also be added. Anyone ever
heard of such a beast?
> > (and cheaper--no I2C $$royalties$$).
>
> Royalties. What royalties - and when do you have to pay them?
Andrew:
Don't worry... Although Philips own the I2C protocol and charge a
license fee for its implementation in other manufacturers' chips,
USERS of those chips don't have to pay. Well, not directly, anyway.
What exactly does Philips own. I meen they came up with the protocol I
know but can someone make a device which uses a different protocol which
could be I2C compatible? It could go something like this... although
not I2C, this stuff is compatible with I2C devices. Ensure pull ups are
used... blah blah.... Remember, these software routines are mine...
blah blah... but they will talk to I2C devices.
Just a thought. Philips would sue me for all I have... I know! Too bad
the 8584 takes up so many I/O lines.
Charles
>Date: Sun, 11 Jan 1998 18:50:05 -0600
>Reply-To: pic microcontroller discussion list
<EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU>
>From: John Payson <supercatspam_OUTMCS.NET>
>Subject: Re: MORE... I2C protocol
>To: @spam@PICLISTKILLspamMITVMA.MIT.EDU
>
>> Not much. They can do I2C slave mode, but not master mode. And
>> master (and multi-master) are the real headaches. Note that Mchip
>> has put out some new PICs that supposedly support master and
>> multi-master mode (16c726 or something like that) in the hardware.
>
>Master mode is the easiest by far, especially if you restrict yourself
to
>EEPROM chips that don't implement the entire protocol (some I2C chips
use
>clock-based flow control, but I've never seen an EEPROM that did) and
if
>your chip is the only master on the bus. Multi-master is probably the
>hardest, because you always need to be aware of what's happening on the
>bus even when it doesn't directly concern you. This latter part makes
>multi-master systems essentially impossible without hardware assistance
>since the only difference between a "1" data bit and a "stop" is the
order
>in which the clock and data wires change state (and they may happen
within
>a microsecond of each other!). Even if the bus appears idle (both
wires
>high) you can't know if it really is unless you saw the data-wire state
on
>the last rising edge of clock. Fortunately, the I2C PICs have a
circuit
>for just that purpose; I don't know whether they handle all the tricky
det-
>ails just right, but it should be possible to do multi-master I2C on
them.
>
>Personally, I find myself sometimes wondering why I2C is so popular?
It
>would seem that for the common case where a single micro hooks up to a
small
>number of devices over a short distance other protocols could be
simpler and
>faster (and cheaper--no I2C $$royalties$$). What I'd like to see I
think
>would be a memory chip which could use the PIC's CLKOUT wire along with
one
>data pin; the data rate could then be set for CLKOUT (for PIC's with
special
>hardware for that purpose) or CLKOUT/12 (for PIC's without such
hardware).
>To make 8x51 fans happy, a CLKOUT/36 mode could also be added. Anyone
ever
>heard of such a beast?
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
If you programmed a PIC to be an I2C controller, instead of doing it
with a bunch of logic gates hardwired on a chip, does this attract a
royalty if you tried to sell the software or the PIC chip - after all,
from a functionality point of view, isn't this the same thing?
> ----------
> From: Andrew Warren[SMTP:KILLspamfastfwdKILLspamIX.NETCOM.COM]
> Reply To: pic microcontroller discussion list
> Sent: Monday, January 12, 1998 4:25 PM
> To: RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU
> Subject: Re: MORE... I2C protocol
>
> Andrew Mayo <spamBeGonePICLISTspamBeGoneMITVMA.MIT.EDU> wrote:
>
> > > (and cheaper--no I2C $$royalties$$).
> >
> > Royalties. What royalties - and when do you have to pay them?
>
> Andrew:
>
> Don't worry... Although Philips own the I2C protocol and charge a
> license fee for its implementation in other manufacturers' chips,
> USERS of those chips don't have to pay. Well, not directly, anyway.
>
> -Andy
>
> === Andrew Warren - TakeThisOuTfastfwdEraseMEspam_OUTix.netcom.com
> === Fast Forward Engineering - Vista, California
> === http://www.geocities.com/SiliconValley/2499
>
> > > (and cheaper--no I2C $$royalties$$).
> >
> > Royalties. What royalties - and when do you have to pay them?
>
> Don't worry... Although Philips own the I2C protocol and charge a
> license fee for its implementation in other manufacturers' chips,
> USERS of those chips don't have to pay. Well, not directly, anyway.
True, but from what I've read the manufacturers of things like I2C-style
memory chips do have to pay royalties; personally, given a choice between
a 2-wire I2C memory chip and a 1- or 2-wire chip which worked as well but
was a nickel cheaper, I'd probably tend toward the latter for large jobs
(assuming it was reliably available) and I'd use whichever was more con-
venient for small ones.
I don't think there is much to worry about. The first patents for I2C
were issued late 1970's and thus expired. I was using the protocol in
1980 while at Signetics (Philips).
> ----------
> From: Charles Laforge[SMTP:RemoveMEcjoachimTakeThisOuTHOTMAIL.COM]
> Reply To: pic microcontroller discussion list
> Sent: Sunday, January 11, 1998 7:41 PM
> To: PICLISTEraseME.....MITVMA.MIT.EDU
> Subject: Re: MORE... I2C protocol
>
> About those royalties....
>
> What exactly does Philips own. I meen they came up with the protocol
> I
> know but can someone make a device which uses a different protocol
> which
> could be I2C compatible? It could go something like this... although
> not I2C, this stuff is compatible with I2C devices. Ensure pull ups
> are
> used... blah blah.... Remember, these software routines are
> mine...
> blah blah... but they will talk to I2C devices.
>
> Just a thought. Philips would sue me for all I have... I know! Too
> bad
> the 8584 takes up so many I/O lines.
>
> Charles
>
>
MITVMA.MIT.EDU]On Behalf Of Charles Laforge
