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?
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}
> 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
> .....nelsonKILLspam@spam@nosuffering.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
>
>
>
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.
> 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?
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>
> 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.
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!
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).
> 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_OUTTakeThisOuTpp.sbbs.se
==============================
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.
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?
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).
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.
> 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).
> Clever, I will have that in mind for my next RS485 network.
Ruben
==============================
Ruben Jönsson
AB Liros Elektronik
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388 RemoveMErubenTakeThisOuTpp.sbbs.se
==============================
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.
> 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
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.
> 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
> RemoveMEdbwoodspam_OUTKILLspamkc.rr.com
>
> Home of the EPICIS Development System for the PIC and SX
> http://epicis.piclist.com
>
==============================
Ruben Jvnsson
AB Liros Electronic
Box 9124, 200 39 Malmv, Sweden
TEL INT +46 40142078
FAX INT +46 40947388 RemoveMErubenTakeThisOuTspampp.sbbs.se
==============================
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.
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.
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.
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.
> 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
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
> -----Original Message-----
> From: pic microcontroller discussion list
> [@spam@PICLIST@spam@spam_OUTMITVMA.MIT.EDU]On Behalf Of Nelson Hochberg
> Sent: Monday, 26 August 2002 8:59 PM
> To: spamBeGonePICLISTKILLspamMITVMA.MIT.EDU
> Subject: Re: [PIC]: CAN or RS-485 ?
>
>
> My thanks to everyone who has given me advice on this question -- really
> good info.
>
> 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?
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
> 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.
> 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
nosuffering.com
