Searching \ for '[PIC]: Having 16f877 talk to each other.' 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/microchip/devices.htm?key=16F
Search entire site for: 'Having 16f877 talk to each other.'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Having 16f877 talk to each other.'
2001\04\26@185914 by Donovan Parks

flavicon
face
Hello,

I need a bunch (max 6) 16f877 pic's to be able to talk to each other.  From
the literature on the Microchip site I gather I can use SSP with SPI(Master
Mode) and I2C(Master/Slave).  Is this the only(best) way to have my pic's
talk?  What are the benefits of SPI to I2C?

Thanks for all help.

Donovan

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


2001\04\27@030635 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Donovan Parks [SMTP:.....dparksKILLspamspam@spam@UVIC.CA]
> Sent: Thursday, April 26, 2001 11:49 PM
> To:   PICLISTspamKILLspamMITVMA.MIT.EDU
> Subject:      [PIC]: Having 16f877 talk to each other.
>
> Hello,
>
> I need a bunch (max 6) 16f877 pic's to be able to talk to each other.
> From
> the literature on the Microchip site I gather I can use SSP with
> SPI(Master
> Mode) and I2C(Master/Slave).  Is this the only(best) way to have my pic's
> talk?  What are the benefits of SPI to I2C?
>
> Thanks for all help.
>
> Donovan
>
The advantages of SPI are: higher bit rate (Megabits/s possible on some
devices), more simple and robust protocol (i.e. no start or stop
conditions).  It is also more simple to bit bash SPI in software than I2C.

The downsides of SPI are: Chip Select wire needed for every slave device.
If you have several slaves, you'll be using up pins on your PIC pretty
quickly.

It sounds like you are going to require a Multimaster bus, which is possible
with I2C and Microchip even have an app note on this.
I don't know about SPI and multi-master systems, it should be possible with
some kind of arbitration.  However, if your network 'o' PIC's really need to
talk to each other, i.e. any PIC and send and recieve to/from any other PIC,
then SPI is going to be hard work to implement.  I'd suggest sticking to
I2C.

Regards

Mike

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\27@083543 by Olin Lathrop

face picon face
> The advantages of SPI are: higher bit rate (Megabits/s possible on some
> devices), more simple and robust protocol (i.e. no start or stop
> conditions).  It is also more simple to bit bash SPI in software than I2C.

I agree with faster and simpler, but not with more robust.  Properly
implemented, both SPI and IIC should get the bits there all the time.  IIC
has some flow control and ACK/NACK built into the protocol, which could add
robustness depending on how you look at it.  I certainly disagree that
having start and stop conditions somehow makes IIC less robust.


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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\27@083555 by Olin Lathrop

face picon face
> I need a bunch (max 6) 16f877 pic's to be able to talk to each other.
From
> the literature on the Microchip site I gather I can use SSP with
SPI(Master
> Mode) and I2C(Master/Slave).  Is this the only(best) way to have my pic's
> talk?

Of course not.  You can invent an infinite number of schemes.

> What are the benefits of SPI to I2C?

SPI can go faster because each line is actively driven in both directions,
and two bits (one in each direction) are transferred each clock cycle.  On
the other hand, it requires three bus wires instead of two, and usually a
separate "chip select" line per slave device.

IIC specifies a bit more protocol than just pumping bits between master and
slave.  It is therefore more flexible, and the PIC implementation allows for
flow control in one direction at least.

I would use IIC unless you are trying to go off board or the transfer rate
isn't fast enough.  Due to a bug in the PIC implementation, you need to put
a capacitor on the SDA, and I personally won't use it above 500Kbits/second.


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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\27@085842 by Barry King

flavicon
face
Olin,

You said:
> Due to a bug in the PIC implementation, you need to put
> a capacitor on the SDA, and I personally won't use it above 500Kbits/second.

What is the bug?  Is it documented somewhere?  You said you have to
add a cap to SDA, I guess that slows the SDA risetime.  Why does that
help?

I'm using I2C (MSSP on 18Cs) from PIC to PIC and don't see any
evidence that there is anything odd going on with bit timing.

Thanks for any info you may have.

------------
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: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\27@090045 by Tim Thompson

flavicon
face
Humm I'm using i2c in my project and have a '877 talking to two phillips
i/o expander chips..what size
cap is supposed to go on SDA?


At 07:26 AM 4/27/2001 -0400, you wrote:
{Quote hidden}

Remember, 'kill' doesn't kill processes, users kill processes.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\27@104301 by Olin Lathrop

face picon face
> Humm I'm using i2c in my project and have a '877 talking to two phillips
> i/o expander chips..what size
> cap is supposed to go on SDA?

See my other response to a similar question.  Search the PIClist archives
for "IIC bug" or similar.


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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\27@104311 by Olin Lathrop

face picon face
> You said:
> > Due to a bug in the PIC implementation, you need to put
> > a capacitor on the SDA, and I personally won't use it above
500Kbits/second.
>
> What is the bug?  Is it documented somewhere?  You said you have to
> add a cap to SDA, I guess that slows the SDA risetime.  Why does that
> help?
>
> I'm using I2C (MSSP on 18Cs) from PIC to PIC and don't see any
> evidence that there is anything odd going on with bit timing.
>
> Thanks for any info you may have.

I sent a rather lengthy description of this bug to the PIC list when I first
discovered it.  I doubt I still have a copy of it anymore, but it should be
in the PIClist archives.  If you can't find it, I'll try to track it down.
But please try yourself first.  Try searching for things like "IIC bug".


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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\27@135508 by Ronald Cotton

flavicon
face
Barry,
You mentioned that you have PIC to PIC communications working using I2C.  I
have been working for the last 3 wks
trying to establish communication.

I can not begin to say what is wrong except that I am using the HI-Tech C
compiler and their routines do not appear to
work properly.  For the slave, I used the I2C slave app note from MicroChip.

Any help will be greatly appreciated.

I was wondering if I could take a look at the master and slave code.

I can be reached via RemoveMErcottonTakeThisOuTspammindspring.com.

Thanks

{Original Message removed}

2001\04\27@140544 by Donovan Parks

flavicon
face
Thanks Mike,

It looks like we will have one pic collecting data from a number of other
pics.  Thus, SPI sounds like the best solution provided we have enough pins
on the master for CS.  Can you recommend any sources of information for
implementing SPI amongst several pics?

Thanks again,
Donovan

> The advantages of SPI are: higher bit rate (Megabits/s possible on some
> devices), more simple and robust protocol (i.e. no start or stop
> conditions).  It is also more simple to bit bash SPI in software than I2C.
>
> The downsides of SPI are: Chip Select wire needed for every slave device.
> If you have several slaves, you'll be using up pins on your PIC pretty
> quickly.
>
> It sounds like you are going to require a Multimaster bus, which is
possible
> with I2C and Microchip even have an app note on this.
> I don't know about SPI and multi-master systems, it should be possible
with
> some kind of arbitration.  However, if your network 'o' PIC's really need
to
> talk to each other, i.e. any PIC and send and recieve to/from any other
PIC,
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\27@180549 by Olin Lathrop

face picon face
> You mentioned that you have PIC to PIC communications working using I2C.
I
> have been working for the last 3 wks
> trying to establish communication.
>
> I can not begin to say what is wrong except that I am using the HI-Tech C
> compiler and their routines do not appear to
> work properly.

So don't use them!  In 3 weeks you could have written your own IIC routines
several times over.

What exactly happens other than "doesn't work"?  Does the slave ACK the
address byte?  Are you doing a write message and the slave fails to ACK a
byte sometimes?  Does the bus hang?  If so, when?

Keep breaking the problem down until you find the individual thing that
doesn't work.  Just knowing that will probably point you to the bug.


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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\28@182321 by Ronald Cotton

picon face
Olin,
I should know better than to use the phrase "doesn't work".  Specifically,
the slave does not ack the address so effectively communication will never
proceed properly.

I read on an email that mentioned something about a slave pic using the R/W
bit as its ack mechanism.  Is this true ?

The documentation implies that act of acking is automatically handled by the
slave.

{Original Message removed}

2001\04\29@090658 by Olin Lathrop

face picon face
> I should know better than to use the phrase "doesn't work".  Specifically,
> the slave does not ack the address so effectively communication will never
> proceed properly.

First make sure the slave MSSP module is set up correctly.  Look at the SCL
and SDA lines on a dual trace scope with the master sending the address byte
in a loop.  If you can't do that you can debug IIC by wiggling the lines
manually.  Just remember to debounce SDA.  I made a IIC tester once with two
pushbuttons, two LEDs, two resistors, and a 12C508A.

If you know the slave is responding correctly but the master still doesn't
get the ACK, then you may be running into the PIC MSSP bug.  What is your
data rate?  What size pullups do you have on the two lines?  Do you have a
cap on SDA?

> I read on an email that mentioned something about a slave pic using the
R/W
> bit as its ack mechanism.  Is this true ?

This doesn't make any sense.

> The documentation implies that act of acking is automatically handled by
the
> slave.

Yes, if everthing is properly enabled.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, TakeThisOuTolinEraseMEspamspam_OUTembedinc.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...