Searching \ for '[PIC]: CAN or RS-485 ?' 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/ios.htm?key=rs%2D485
Search entire site for: 'CAN or RS-485 ?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: CAN or RS-485 ?'
2002\08\16@155653 by Nelson Hochberg

flavicon
face
I am planning a system with a network of PICs.  The PICs will be daisy
chained together (power and communications) in a standard office environment
(fluorescent lights, networked PCs, telephones, HVAC, etc.)  The PICs will
need to communicate about two bytes (status change of nine LEDs and which
PIC sent the event) every 5-10 minutes.  Two of the events are pretty
important and would need to be acknowledged by the other PICs.  Initially,
the network will be 300' end to end with 18 PICs.  The network could expand
to 2000' end to end and about 100-200 PICs.

I've got it whittled down to either a CAN or RS-485 (unless someone can
convince me another protocol would be better.)  Which one do you think is
better and why.

If I use 18F248/448 do I need to use a transceiver interface such as
PCA82C250 or can the PICs connect to the wires directly?  Any
recommendations for an interface?

I was thinking of using the MAXX485 if I went with RS-485.  Any other
suggestions?

TIA

Nelson
spam_OUTnelsonTakeThisOuTspamnosuffering.com
http://www.nosuffering.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


2002\08\16@160153 by Hu, Luhui

flavicon
face
CAN is relative easy to implement and reliable. If you use PIC18F serials,
you still need to use transceivers per CAN2.0B.

Luke

{Original Message removed}

2002\08\16@160937 by Simon Bryden

flavicon
face
One issue here is that RS485 only defines an electrical spec; it does not
define the data format or even character framing - you have to do this
yourself. CAN on the other hand defines all of this and more and is extremely
complex. If you use CAN, you pretty much need to implemnt it in hardware which
will impact the cost. RS485 is cheaper but you will have a bit more work to
do.

I've never used the MAX485 but can highly recommend the 75176.

Cheers,
Simon.
---

On Fri, Aug 16, 2002 at 12:56:46PM -0700, Nelson Hochberg wrote:
{Quote hidden}

--
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


2002\08\16@161559 by Shawn Yates

flavicon
face
I use 485 pretty extensivly.  I have switched form the standard 75176 to a
SN65LBC184 which only counts as 1/2 a load and has some pretty good built in
static discharge protection.

{Original Message removed}

2002\08\16@165217 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

{Quote hidden}

If you use the 10bit addressing, you could get up to 1024 PICs on an
I2C bus.  You'd need the special long range trancievers at each
junction, but I don't think that would really be a big problem, since
you need trancievers with CAN or RS485 anyway.

- --Brendan

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPV1lpwVk8xtQuK+BEQIXTQCg57r2iSkM/5b2ltJcClzj0WElvGYAniCv
z9Qu+TaOqaoE8Il/CL0hS2cm
=wGpL
-----END PGP SIGNATURE-----

--
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


2002\08\17@084221 by Lyle Hazelwood

flavicon
face
> I am planning a system with a network of PICs.  The PICs will be daisy
> chained together (power and communications) in a standard office
environment
> (fluorescent lights, networked PCs, telephones, HVAC, etc.)  The PICs will
> need to communicate about two bytes (status change of nine LEDs and which
> PIC sent the event) every 5-10 minutes.  Two of the events are pretty
> important and would need to be acknowledged by the other PICs.  Initially,
> the network will be 300' end to end with 18 PICs.  The network could
expand
> to 2000' end to end and about 100-200 PICs.

The CAN protocol is complex, but most of that is done for you in hardware.
You get "free" collision detection, error checking, re-send requests, and
even
a system that will knock a bad node offline if it makes too many mistakes.
Nodes are assigned a priority, so that higher priority ones will seldom wait
for lower priority ones. Speed can be chosen based on max length of net.

If these features sound useful (or required), CAN might be a good choice.
One problem is the expansion to 100-200 PICs. There's plenty of
"address space" with CAN, but the specs for most can transcievers top
out at about 100 nodes per net, so a repeater will be needed to get up
around or above those levels.

The choice of a "Higher Level Protocol" will determine if your CAN net
is "Multi-Master" where every node can transmit at will, or if a polled
system with slaves is used. Many (like myself) just ignore the existing
HLP's and work out what we need on the fly.

CAN messages are 8 bytes or less per message, this sounds OK for
what you described.

So far the 18Fxx8 CAN PIC's are a bit rare, though a few samples have
made it to the light of day. You can still add CAN to any pic with an SPI
port by using the MCP2510. Which ever way you go, you'll still need a
CAN transciever. Most of these transcievers are 8SOP, but I did notice
that Microchip is promising one of their own "real soon now", available
in either SOP or DIP forms.

If you'd like to experiment, there is a pretty cool CAN developers kit
done with PICs at http://www.diversifiedengineering.net/devel_f.htm .
I built this one based on their documents, and it's been working great
24/7 for a few months now. This is a good way to get started with
proven HW and SW, then edit up from there.

[Shameless Plug] I made mine a bit prettier, let me know if you want
to see a photo. 8^)

A wireless RF PIC CAN node is available from
www.autoartisans.com/documents/canrf_prod_announcement.pdf
I have not had the opportunity (yet) to play with this one, but it looks
like a lot of fun! John is a member of this list.

Good Luck,
Lyle
>

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


2002\08\17@094212 by 250?B?QnJhbmtvIEthcmFrbGFqaeY=?=
flavicon
face
Hello Nelson,

Friday, August 16, 2002, 9:56:46 PM, ste napisali:

Nelson> I am planning a system with a network of PICs.  The PICs will be daisy
Nelson> chained together (power and communications) in a standard office environment
Nelson> (fluorescent lights, networked PCs, telephones, HVAC, etc.)  The PICs will
Nelson> need to communicate about two bytes (status change of nine LEDs and which
Nelson> PIC sent the event) every 5-10 minutes.  Two of the events are pretty
Nelson> important and would need to be acknowledged by the other PICs.  Initially,
Nelson> the network will be 300' end to end with 18 PICs.  The network could expand
Nelson> to 2000' end to end and about 100-200 PICs.

I suggest you RS485 and 75176 transceiver. I do it lots of time in
noisy environment and didn't have any problems. Only hard thing is to
implement your own protocol... but that's not hard to much! And main
advantage is it's much cheaper of the CAN... at least here in
Yugoslavia!

--
sincerely,
Branko
branekspamKILLspameunet.yu
http://solair.eunet.yu/~branek
ICQ: 15616778

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


2002\08\17@211352 by Douglas Wood

picon face
If you are interested in a full-duplex, multi-drop RS-485 circuit with
collision detection, I have in a 17C756 reference design (does not rely on
using the 17C756).

Douglas Wood
Software Engineer
.....dbwoodKILLspamspam.....kc.rr.com

{Original Message removed}

2002\08\18@035351 by ISO-8859-1?Q?Ruben_J=F6nsson?=

flavicon
face
> If you are interested in a full-duplex, multi-drop RS-485 circuit with
> collision detection, I have in a 17C756 reference design (does not
> rely on using the 17C756).
>
I was under the impression that RS485 can not handle collision detection reliably. Does this really work?

Ruben

==============================
Ruben Jönsson
AB Liros Elektronik
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
EraseMErubenspam_OUTspamTakeThisOuTpp.sbbs.se
==============================

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


2002\08\18@044250 by Claudio Tagliola

picon face
Hi Nelson

Go with CAN. It takes some study to get it up and running because the
controller is pretty advanced but once it's on air, it won't come off. We
have a test setup running in the office (DeviceNet) and it only stops when
you take of both terminators or only leave one node on the bus. We're
develloping the units while they are on the bus, and it doesn't give a
hitch.

The biggest advantage of the CAN network as I see it now is the easy of
actually doing the communication. You just have to write a few registers and
the rest is done by the controller. The only thing you need is a line
driver, but I thing you need that as well for the 485 option on these
network sizes. The length of the network can be handled at lower speeds, but
you have a very low bus usage, so that won't be a problem. One thing to keep
in mind is the number of network nodes. The MCP2510 can handle 127 nodes (if
I'm well informed), so it's possible you need a repeater somewhere on the
net, however, those can come off the shelf.

Regards,

Claudio

-----Oorspronkelijk bericht-----
Van: pic microcontroller discussion list
[@spam@PICLISTKILLspamspamMITVMA.MIT.EDU]Namens Nelson Hochberg
Verzonden: vrijdag 16 augustus 2002 21:57
Aan: KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU
Onderwerp: [PIC]: CAN or RS-485 ?


I am planning a system with a network of PICs.  The PICs will be daisy
chained together (power and communications) in a standard office environment
(fluorescent lights, networked PCs, telephones, HVAC, etc.)  The PICs will
need to communicate about two bytes (status change of nine LEDs and which
PIC sent the event) every 5-10 minutes.  Two of the events are pretty
important and would need to be acknowledged by the other PICs.  Initially,
the network will be 300' end to end with 18 PICs.  The network could expand
to 2000' end to end and about 100-200 PICs.

I've got it whittled down to either a CAN or RS-485 (unless someone can
convince me another protocol would be better.)  Which one do you think is
better and why.

If I use 18F248/448 do I need to use a transceiver interface such as
PCA82C250 or can the PICs connect to the wires directly?  Any
recommendations for an interface?

I was thinking of using the MAXX485 if I went with RS-485.  Any other
suggestions?

TIA

Nelson
RemoveMEnelsonTakeThisOuTspamnosuffering.com
http://www.nosuffering.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

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


2002\08\18@053248 by Douglas Wood

picon face
Because RS-485 is an electrical specification and not a hardware or protocol
specification, as such, it does not describe any method for collision
detection. However, for this circuit I have added it.

Also, I've included an "anti-chatter" circuit (basically a charge pump) to
the "talk enable"; in the event that the PIC goes south while talking to the
bus, the device can not tie up the bus (note: the interface circuit does not
require the use of the anti-chatter circuit).

Douglas Wood
Software Engineer
TakeThisOuTdbwoodEraseMEspamspam_OUTkc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://epicis.piclist.com

{Original Message removed}

2002\08\18@164337 by ISO-8859-1?Q?Ruben_J=F6nsson?=

flavicon
face
The problem with anti collision detection is that it is the node that is talking that also checks for collision (by listening and comparing the transmitted data with the received data) and that a '1' is equally strong as a '0' on the bus. This could mean that two nodes far enough apart from each other could both be talking and still not see the collision with the other since they are so far apart that the other transmitter isn't strong enough to affect the looped back data to the receiver in the same chip, especially if there exists some extra protection components (resistors and or inductors) in series with the driver input/output.

This is why it is hard to make a network with nodes that is spontaneously transmitting as opposed to polled by a master with RS485. CAN on the other hand, is designed just for this.

{Quote hidden}

Ruben

==============================
Ruben Jönsson
AB Liros Elektronik
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
RemoveMErubenspamTakeThisOuTpp.sbbs.se
==============================

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


2002\08\18@170108 by Douglas Wood

picon face
Ok, ok! You found me out! It isn't really a "collision detection" technique
as much as it is a "collision avoidance" technique... The unit that is about
to talk tests the collision input to see if there is any traffic currently
on the bus. If not, it waits a small about of time and tests again. The
actual amount of testing required if up to the user. When a sufficent number
of tests indicate that there is n traffic then the unit begins talking. This
method has worked well in systems that had 128 units on one bus; should work
for many more.

Douglas Wood
Software Engineer
EraseMEdbwoodspamkc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://epicis.piclist.com

{Original Message removed}

2002\08\18@172031 by Olin Lathrop

face picon face
> Ok, ok! You found me out! It isn't really a "collision detection"
technique
> as much as it is a "collision avoidance" technique... The unit that is
about
> to talk tests the collision input to see if there is any traffic currently
> on the bus. If not, it waits a small about of time and tests again. The
> actual amount of testing required if up to the user. When a sufficent
number
> of tests indicate that there is n traffic then the unit begins talking.
This
> method has worked well in systems that had 128 units on one bus; should
work
> for many more.

This has two problems:

1  -  It forces a minimum amount of quiet time between packets, thereby
wasting bandwidth.

2  -  It doesn't guarantee collision avoidance any more than checking once.
If two nodes are out of sync, the second will see the first transmit either
way and therefore not transmit itself.  If both nodes are in sync, then
neither will see the other no matter how many times each of them check.
They will both check a bunch of times, see that nobody is talking, and then
both try to talk simultaneously.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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


2002\08\19@014314 by rubenj

flavicon
face
OK, sort of a CSMA system.

I assume that this scheme also requires ACKing of the messages in order for the transmitter to know
that the message has actually arrived at its intended receiver.

Ruben

{Quote hidden}

==============================
Ruben Jvnsson
AB Liros Electronic
Box 9124, 200 39 Malmv, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
RemoveMErubenTakeThisOuTspamspampp.sbbs.se
==============================

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


2002\08\24@114349 by Nelson Hochberg

flavicon
face
Brendan,

Any part numbers for the I2C long range transceivers?

Nelson

If you use the 10bit addressing, you could get up to 1024 PICs on an
I2C bus.  You'd need the special long range trancievers at each
junction, but I don't think that would really be a big problem, since
you need trancievers with CAN or RS485 anyway.

- --Brendan

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


2002\08\24@152001 by Brendan Moran

flavicon
face
At 08:19 AM 24/08/2002 -0700, you wrote:
>Brendan,
>
>Any part numbers for the I2C long range transceivers?

You can find all the Philips I2C components from here:

http://www.philipslogic.com/i2c/

For transceivers, the P82B96 should be good, since it has the ability to
split the bidi signals into unidirectional signals, which allows you to use
just about any kind of buffering you want.

--Brendan

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


2002\08\24@180024 by Dwayne Reid

flavicon
face
At 05:20 PM 8/18/02 -0400, Olin Lathrop wrote:
> > Ok, ok! You found me out! It isn't really a "collision detection"
>technique
> > as much as it is a "collision avoidance" technique... The unit that is
>about
>
>This has two problems:
>
>2  -  It doesn't guarantee collision avoidance any more than checking once.
>If two nodes are out of sync, the second will see the first transmit either
>way and therefore not transmit itself.  If both nodes are in sync, then
>neither will see the other no matter how many times each of them check.
>They will both check a bunch of times, see that nobody is talking, and then
>both try to talk simultaneously.

I use a similar protocol where the 'wait' time is determined by the node
ID: lower numbered nodes have higher priority.  Works OK with in bandwidth
applications - which the original poster was asking about.

CAN seems like expensive overkill for the application.

dwayne

--
Dwayne Reid   <spamBeGonedwaynerSTOPspamspamEraseMEplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 18 years of Engineering Innovation (1984 - 2002)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

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


2002\08\24@182607 by Olin Lathrop

face picon face
> CAN seems like expensive overkill for the application.

I would hardly call CAN expensive.  18F248 costs $5.76 in quantity 25 from
DigiKey.  Add another $1.50 or so for the CAN tranceiver and you're in
business.  You would still need a transceiver and a mirco for RS-485.  A
micro with a UART is a little cheaper, but the transceiver should be
similar.  CAN is quite a deal when you consider that the low level protocol
is taken care of for you.  It is full peer to peer, and you don't have to
worry about collision detection, error recovery, etc.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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


2002\08\26@085928 by Nelson Hochberg

flavicon
face
part 1 4132 bytes content-type:text/plain; (decoded 7bit)

My thanks to everyone who has given me advice on this question -- really
good info.

I have speadsheeted the options, feel free to post corrections or additions:

                               RS-485  RS-485  RS-485  CAN             CAN             I2C
                               75176           SN65LBC184      MAX485  MCP2510 18F448  P82B96

~ max length ft
   @ ~500bts/hz                4000            4000            4000            2000            2000            1000
~ max nodes                     64[?]           128             128             100             100             1028
chip count                      2               2               2               3               2               2
noise immunity          high            high            high            high            high            low
transient suppression   low             high            high            high            high            low
anti collision          no              no              no              yes             yes             yes
disabled node dropout   no              no              no              yes             yes             no
parts readily available yes             yes             yes             yes             no              yes
cost USD (quant 25)     5.86            7.08            7.21            9.09            7.45            7.34
Notes                           16F877  16F877  16F877  16F877  82C250  w/ active
                                                                               82C250                  pull up

I have gotten the other parts of my project worked out but this decision is
a tough one.  I can't just breadboard two or three nodes to determine if 25
(or more) PICs would be happy talking with each other.  In a short time I
have seen this list has a lot of experience and brain power so I'll share my
current thinking for feedback.

In this project, any node can randomly create an event that other nodes
would want to know about.  These events would happen about one every fifteen
minutes or so.  Events have different priorities.  Sounds exactly like CAN
territory but the 18F448 is currently scarce and the MCP2510 solution uses
more precious pcb real estate and the additional cost adds up in large
quantities.  I think this is my choice if I can get enough of the 18F448
chips.

I don't see any advantage of I2C over CAN w/18F448.

The cost of RS-485 using the 75176 is certainly attractive.  Using one
master to poll all the others every second to determine a once in 5-15
minute event has occurred then the master telling each of the slaves the
event occurred does not make sense to me.  The suggestions from Douglas Wood
and Dwayne Reid of having a node check the net for activity twice before
transmitting is intriguingly simple.  I especially like Dwayne's idea of
every node waiting a different length of time.  I would change that to
adding the event priority (high priority = lower number) to the node id to
determine the wait time.  That way, a higher event priority would get
transmitted first.  I would also include nodes acknowledge all
understandable transmissions using the same wait scheme with only one
acknowledgement sent.  This way, node 0 would normally send the
acknowledgement but if node 0 went belly up, node 1 would take over, etc.
If a node found the network to be busy, it would wait for the acknowledgment
before starting a transmission.  If two nodes tried to transmit at the same
time, the message would not be understandable; they would not get an
acknowledgement and would resend.  If I can be convinced this would be
reliable, it would be the way I'd go.  So Douglas and Dwayne, do you have
much real experience with this wait scheme?  Are messages lost?  Does anyone
else have ideas or even better experience with this?

TIA

Nelson

BTW:  I went to the Mchip Masters conference thinking I would learn how to
use these things -- I didn't.  Following the piclist beginners guide and
reading the piclist posts the last several weeks have been the best learning
I have gotten so far.  Thanks to all!


part 2 903 bytes content-type:text/plain;
(decoded quoted-printable)

       "RS-485 75176"  "RS-485 SN65LBC184"     "RS-485 MAX485" "CAN MCP2510"        "CAN 18F248" "I2C P82B96*"
"~ max length ft @ ~500bts/hz"   4000    4000    4000    2000    2000    1000
~ max nodes     64?     128     128     100     100     1028
chip count      2       2       2       3       2       2
noise immunity  high    high    high    high    high    low
transient suppression   low     high    high    high    high    low
anti collision  no      no      no      yes     yes     yes
disabled node dropout   no      no      no      yes     yes     no
parts readily available yes     yes     yes     yes     no      yes
cost USD (quant 25)     5.69    6.91    7.04    8.92    7.30    7.17
Notes   16F877  16F877  16F877  "16F877 82C250" 82C250  w/ active pull up


part 3 144 bytes
--
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


2002\08\26@092448 by Katinka Mills

flavicon
face
> -----Original Message-----
> From: pic microcontroller discussion list
> [@spam@PICLIST@spam@spamspam_OUTMITVMA.MIT.EDU]On Behalf Of Nelson Hochberg
> Sent: Monday, 26 August 2002 8:59 PM
> To: spamBeGonePICLISTspamKILLspamMITVMA.MIT.EDU
> Subject: Re: [PIC]: CAN or RS-485 ?
>
>
> My thanks to everyone who has given me advice on this question -- really
> good info.
>

<el snipo>

{Quote hidden}

I prefer polling, as it guarantes (as long as a node does not crash on the
netwrok and pull it down or up) that collisions do not occur.

I have worked in the security industy for many years in access controlling
equipment, and they mainly use 2 types of networks :

RS-485 : Large number of nodes, at 9600 baud can travel a fair few KM's
(longest network I have been involved in was 8KM's with 255 slave nodes)

20mA current loop, each node passes the data on to the next, and forms a
ring. Large cable length, limited number of nodes in one loop due to delay
in each node.

Regards,

Kat.

**********************************************
K.A.Q. Electronics.
Electronic and Software Engineering.
Perth, Western Australia.
Ph +61 (0) 419 923 731
**********************************************
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.384 / Virus Database: 216 - Release Date: 21/08/2002

--
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


2002\08\26@130641 by Brendan Moran

flavicon
face
> I have speadsheeted the options, feel free to post corrections or
additions:
>
>                                 RS-485  RS-485  RS-485  CAN
CAN             I2C
>                                 75176           SN65LBC184      MAX485
MCP2510 18F448  P82B96
>
> ~ max length ft
>     @ ~500bts/hz                4000            4000            4000
2000            2000            1000
> ~ max nodes                     64[?]           128             128
100             100             1028
> chip count                      2               2               2
3               2               2
> noise immunity          high            high            high
high            high            low
> transient suppression   low             high            high
high            high            low
> anti collision          no              no              no
yes             yes             yes
> disabled node dropout   no              no              no
yes             yes             no
> parts readily available yes             yes             yes
yes             no              yes
> cost USD (quant 25)     5.86            7.08            7.21
9.09            7.45            7.34
> Notes                           16F877  16F877  16F877  16F877  82C250  w/
active
>
82C250                  pull up

For I2C, I think you meant 1024, rather than 1028.  I2C also has bus
arbitration (is that what you mean by anticollision?).  You can check the
spec. sheet from Philips, or someone else on the list can give you more
information.

[snip]

> I don't see any advantage of I2C over CAN w/18F448.

Couldn't tell you.  I just thought you should know that there was the
option.

[snip]

--Brendan

--
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


2002\08\26@162223 by Olin Lathrop

face picon face
> Sounds exactly like CAN
> territory but the 18F448 is currently scarce and the MCP2510 solution uses
> more precious pcb real estate and the additional cost adds up in large
> quantities.  I think this is my choice if I can get enough of the 18F448
> chips.

These parts are real.  I'm holding ten full production 18F458 in my hands
right now.  It might be a little while before the distributors stock them.
Talk to your local Microchip office.  They should be able to help you out.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, 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


2002\08\28@021616 by GVH Unnau

flavicon
face
-----Urspr|ngliche Nachricht-----
Von: "Katinka Mills" <.....katinkaspam_OUTspamMAGESTOWER.COM>
An: <TakeThisOuTPICLIST.....spamTakeThisOuTMITVMA.MIT.EDU>
Gesendet: Montag, 26. August 2002 15:19
Betreff: Re: [PIC]: CAN or RS-485 ?


> > {Original Message removed}

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