CanBus (2005-08-10 06:09:16)

Overview

CAN stands for Controller Area Network. It is a high reliability network typically used for connecting microcontrollers, in the industrial and transportation fields.


Time Triggered messages - messages are transmitted even when there is no event (so network disconnects can be detected and handled more gracefully)

Read about the [war between standards] that is reaching it's climax soon.

Network model

Higher layer protocols

Although the lower level CAN protocols are well documented with freely available information, we need a higher layer protocol to actually define the data we are using. It is possible to design this from scratch, but this work has already been done before many times. A free standard would be ideal, and it should be compatible with existing autmotive systems and tools.

Some applicable standards are :-

Controllers

As CAN useage grows in non-automotive areas, more microcontrollers are available with CAN networking built in. The ATMega128 doesn't have this however, so an external CAN controller must be used. Any future ARM controller used will include at least one CAN networking module. More modules are useful, to allow different speed buses to be used for different tasks. For a Genboard 3.x add-on, we need an SPI or similar interface to talk to a standalone CAN controller.

Some applicable parts are :

Transceivers

Media

2 wire sheilded twisted pair is the ideal media for high-speed CAN usage. In an automotive environment there is electrical noise all over the place, so the added cost of this wire is worth it. Wire should have an impedance of 120 Ohms, and a resistance of up to 70 mOhm/m. The bus should have 120 Ohm termination resistors on each end, while the plugs used for connection should have 120 Ohm impedance and a 70 mOhm resistance. Connectors are commonly 9 pin D-Sub type, however for automotive use, a smaller circular connector may be desirable. Several purpose designed heavy-duty connectors are available from Deutsch, AMP/Tyco, and Amphenol, among others.

Alternatives

If CAN is overkill for a given application, a Local Interconnect Network or LIN may be used. This would be appropriate for anicllary devices that don't need the reliability or overhead of CAN.

Future directions

An even higher-reliability replacement for the CAN network are the Flexray and ByteFlight networks. These allow higher datarates.

CAN links

http://www.can.bosch.com/content/Links.html
http://groups.yahoo.com/group/CANbus
http://www.port.de/cgi-bin/CAN (CAN Wiki)
http://www.mjschofield.com/
http://www.port.de/software/can4linux.3.0.tgz
http://www.algonet.se/~staffann/developer/frames.htm
http://www.racelogic.co.uk/downloads/app_Notes/CAN%20Bus%20Parameters%20by%20manufacturer.pdf
http://www.esacademy.com/myacademy/ (A few online CAN courses)
http://caraca.sourceforge.net/ SW CAN with small AVR! (Even if we have the LPC2119 big guy, small CANcapable units might be nice for simple tasks, eg. lights and alike).

CAN substitute

CAN is not a miracle. There is nothing about CAN that couldn't be implemented with simpler HW (network-protocols) and smart software. CAN is just a standard so some commonly used features are implemented at low level, and licence-fees is guaranteed to be paid to ... whoever ... instead of other parties. The good side is interoperability, and that engineers with less skills can also design powerful and reliable systems.

Features CAN helps in:

Here's a decent list of automotive bus alternatives... CAN is only one of many, but has been adopted outside the automotive industry so is relatively easy to work with now. http://www.interfacebus.com/Design_Connector_Automotive.html

GenBoard/VerThree needs a small addon board for CAN,

and Jörgen ruled out the possibility to add CAN to first production AfreshTiny, I think we should play a bit with homebrewn solutions of digitally connecting boards.

options:

In any case, error checking with chechsum is a must. See GenBoard/BinaryProtocol.


CAN to nonCAN see CommMatrix

unfortunately (thanx to intel's revenue-hunt) the technically very very very bad USB became the standard in the PC world (instead of some modified Ethernet, to include power supply; or firewire or CAN).

We need to connect to the PC. We will have

Making/buying an interface board/cable could work.

options:

<richb> the kvaser product looks ideal for development. i don't think it's sensible for end users though

guys, please when you discuss on irc, please, please someone take 3 minutes, and put the result to wiki, so others won't need to search for hours to find the same. thanx.


An implementation plan:

CAN is good, but what's more useful right now is something we can implement quickly. How about this:

If we've got good inter-node networking, we can simplify each component *a lot*. This can give us faster time to market, and improve QA.