Comparison between CAN and RS-485

Hi there - I'm trying to figure out the major disadvantages and advantages between RS-485 and CAN. So far, this is my understanding:

CAN is limited to 1Mbps (though I have read it can go faster? Anybody have experience with this?) while RS-485 can go much faster - I think as fast as 40Mbps

CAN is more limited in range (40M@1Mbps for CAN, or 10M@35Mbps for RS-485, and much farther at 1Mbps)

CAN is much higher level - with collision handling built in, addressing built in, CRC built in. This also means more overhead, however.

RS-485 is cheaper to implement, as CAN is a much less (and typically more expensive) feature than a UART.

Any mistakes in that list? What other major differences are there?

Thanks!

-Michael

Reply to
Michael
Loading thread data ...

It's not a fair comparison. CAN defines the protocol AND the physical properties. RS-485 is just the physical spec. On RS-485 you need to define all the bits yourself, and find a way to make sure the data gets to where it's supposed to when it needs to. That's what CAN does for you already.

..so to say that RS-485 is cheaper to implement is not quite true. The hardware may be cheaper, but depending on what you need the system to do you could spend a lot of time developing low-level communications. CAN is a much more complete solution.

As always, it depends on you application which one is "better".

Reply to
Anders

Very true. I was referring to ISO-11898-2, by the way.

And for us, I'm not sure all of that is seen as a good thing. There is a significant amount of additional overhead with CAN.

However - cost is the smallest factor in our choice. Really, I care about speed, ease of implementation, maximum line length, and noise protection. I would go with CAN by default, however 1Mbps is lower than what we'd really like.

-Michael

Reply to
Michael

And if you want, you can run CAN on RS-485 (that's supposedly how they tested CAN controller chips before CAN xcvr chips were ready). It's sort of a hack, because you're not driving the bus for both bit transitions.

--
Grant Edwards                   grante             Yow! I'm into SOFTWARE!
                                  at               
 Click to see the full signature
Reply to
Grant Edwards
[...]

If cost is not prohibiting, and speed is a priority, that sounds a lot like Ethernet to me....

Reply to
Anders

Too many wires! Also, too complicated to implement. This network is going to be between a bunch of 8 bit microcontrollers.

-Michael

Reply to
Michael

How much speed do you HAVE to have, in Mbps, and message latency ? Once you have that nailed down, the choices will simplify.

Besides CAN and half-duplex RS485, there are also RS422 ring-bus topologies - these allow very simple, fast slaves and the TDM nature of the mesages makes response very defined. In the simplest form, slaves are addressed by their physical location on the BUS, and adding new slaves does not need any address settings/tables.

-jg

Reply to
Jim Granville

We need a couple Mbps. Latency is not terribly important, within reason (

Reply to
Michael

RS485 is half duplex, whilst RS422 is the same driver specs, but duplex, and normally point to point. More wires in RS422, but no collision issues to manage. With RS485, you need some SW layer to manage 'who talks when', and the DIRN control is normally in under fast SW control on the smaller uC.

What micros are on this bus, and how many ?

-jg

Reply to
Jim Granville

Why do you call it a hack ?

You can use RS-485 hardware for CANbus communication by simply connecting the input transceiver input to 0 "dominant state" and connect the data to the Transmit enable pin. When sending 0 (dominant state) the bus is actively driven, when sending recessive state 1 the bus relies on the "fail safe" termination. This is a form of balanced current loop.

On the other hand, you could use CAN hardware for ordinary RS-485 multidrop applications for much longer distances available for CANbus applications as long as you are not interested to listen for collisions. This is also a form of balanced current loop.

The 20 mA current loop, RS422/485 and CANbus were designed to match the 100-120 ohm characteristic impedance of the twisted pair transmission line.

Paul

Reply to
Paul Keinanen

Just because that's not how RS-485 drivers were intended to work.

If your protocol prevents collisions, then using a CAN controller with RS-485 transceivers is sort of clever. The one problem with CAN is the small frame size. Too bad they didn't have a "long" version with maybe 256 byte payloads instead of 8.

OTOH, if you're not using the collision detection/arbitration in the CAN controller, you can also go longer distances using a CAN transceiver.

--
Grant Edwards                   grante             Yow! PARDON me, am I
                                  at               speaking ENGLISH?
 Click to see the full signature
Reply to
Grant Edwards

CAN has a maximum packet length of 6 bytes, including header. This makes it somewhat illsuited for block transfers. There are those that route Ethernet over CAN. In this case the ethernet packet of 1500 bytes is broken down into 400 CAN packets. Then the performance drops to one or two storeys below the basement.

There is more to it.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
Reply to
Rene Tschaggelar

Oh, no. RS422 is fullduplex. There is one line pair in each direction. A usual implementation is to have a master "always on" sending in one direction, and a selected slave reply on the other pair as required.

To me the RS422 is the improved 485, as the 485 is having a rather strict timing on switching the direction. A normal PC is not able to switch the direction that fast. And as second point, since the PC is the master anyway, the 422 is the natural choice for a master-slave multipoint serial network.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
Reply to
Rene Tschaggelar

I assume this is a typo for 8

That's...horrible...

--
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
 Click to see the full signature
Reply to
Rich Walker

CAN is a protocol specification that doesn't cover the physical layer, but puts demands on it (in the form of passive & active bits, for collision detection).

RS-485 is a physical layer specification that doesn't cover the overlaying protocol, but puts demands on it (in that the protocol must avoid collisions).

But they do both have something to do with shoving bits around, and they're often found in close proximity to little black plastic rectangles with wires sticking out of them, so I guess they're practically the same thing.

Most embedded software engineers, when they say "RS-485" really mean "half-duplex asynchronous serial being carried over RS-485 with all the accompanying baggage". But "RS-485" could mean a lot more (or less); I've seen it used for the above-mentioned asynchronous serial, as well as wide parallel bidirectional busses, and I've brushed up against (but never worked with) synchronous serial implementations.

This same group of people, when they say "CAN" they mean "CAN protocol on the usual automotive two-wire physical layer". But the CAN protocol only lays requirements on the physical layer, and puts an upper bound on the bit rate -- it doesn't do anything more. With the right hardware you could implement CAN using closely spaced foghorns, although your data rate might be disappointingly low.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

That is interesting because Ethernet was designed as high speed medium not suitable for real-time while CAN was designed as real-time priority based medium not suitable for bulk data transfers. Combining the two gets you worst of both worlds.

There must be a dozen other ways to route Ethernet over a twisted pair that CAN uses, for example even good old RS485.

Reply to
Roman

That's a technique I'll have to remember :)

Robert

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Robert Adsett

Then whats the reason both Beoing and Airbus are using Can over tcpip on the latest aircraft ?

Can't remember which arinc standard covers it - 629 , 653 or ?

I've even seen a linn bus over tcpip implementation (not aircraft) in a test cell.

Alex

Reply to
Alex Gibson

Read again: Rene mentioned ethernet over CAN which is something completely different that CAN over TCP/IP....

Meindert

Reply to
Meindert Sprang

Reminds me of RFC1149 (CPIP - Carrier Pigeon IP):

formatting link

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.