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)
- the lastest CAN variant appears to be Time Triggered CAN, or TTCAN. This allows for time triggered CAN messages as opposed to the event triggered messages used by regular CAN.
- FlexRay
- TTA (Time Triggered Architecture)
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 :-
- ISO 11898 - Road vehicles -- Controller area network (CAN) parts 1 to 4 (part 3 is still under review).
- ISO 15765 - Road vehicles -- Diagnostics on Controller Area Networks (CAN) parts 1 to 3.
- ISO 16845 - Conformance test plan. To make sure the above is kosher.
- SAE J1939 - Designed for heavy and off-highway vehicles, and includes lots of engine and drivetrain specific messages. Not free, but very complete and allows interaction with 3rd party tools if needed.
- CANaerospace - Designed for aircraft usage, but free, and does have some basic engine messages defined.
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 :
- LPC2119 has 2 CAN controllers onboard
- Microchip MCP2515 - Standalone CAN controller IC, with an SPI communication interface.
- An universal FPGA with apropriate IO can use http://opencores.gds.tuwien.ac.at/projects.cgi/web/can/ Open Source Core license free for non comercial application (so licensing is on the edge for us). Is this useful when 2 CAN controllers from the ARM is not enough, but there is an FPGA onboard (with costly parallel interconnection to the main uC for this verilog model) ? If it works for first try, it's fine, but debugging such a gizmo (or CAN related competibility problems) is very hard. (don't take it Personal this is just a collection of Information Marcell! There won't always be the cost of designated Microcontrollers, FPGA's Rule ;-) (lets remove this Noise soon ok!)
Transceivers
- Microchip MCP2551 - CAN transceiver. Not compatible with 3.3V IO (sigh, microchip....)
- A new ATmega128 with a CAN contoller is under development and samples are availabal as far as I understand.
- add your favorite transceiver here
- http://www.google.com/search?q=%22CAN+bus+transceiver%22&ie=ISO-8859-1
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:
- framing (generation of frames and detection of frame boundaries)
- error detection
- unit addressing (and message routing)
- TTCAN, TTA and FlexRay helps to detect lost frames also
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:
- the 2nd RS232 is there
- using twisted pair and symmetrical drive would allow longer cables or higher bandwidth. This can be achieved by a differential input, and 2 outputs, one inverted, the other noniverted. Max freq for midOPA would be around 1MHz, but serial comm over 230kbaud is not really useful with v3.
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
- CAN on every board and
- RS232 on every board.
options:
- http://www.everythingusb.com/hardware/index/Delkin_USB_Bridge.htm
- http://www.cypress.com/products/datasheet.cfm?partnum=CY7C67200&familyid=A6B8BB1A-BDB2-4175-8B47D1F27AEDBD27&errataid=B197CA6A-7D02-4ACE-9B69E13D879B8D51 but we try to avoid BGA.
- CAN - USB: http://www.kvaser.com/prod/hardware/usbcan2.htm
- http://www.semiconductors.philips.com/buses/usb/products/otg/
- USB - CAN logger: http://www.kvaser.com/prod/hardware/memorator.htm
- schematics for CAN - USB: http://www.circuitcellar.com/flash2002/First/abstractM250.htm
<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:
- KWP-2000/ISO-14230 for starters. This is a serial specification that doesn't use CAN. It's used on a range of vehicles such as VW Toureg and Phateon, BMW E60 5 and 7 series, and Mercedes Benz... also Hyndai and Suzuki. The main competitor is ISO-9141. See http://www.etools.org/i4a/pages/index.cfm?pageid=1866
- When this is stable, move to KWP-CAN/ISO-15765. The is basically KWP-2000 on a CANbus. Used on a similar stable as above, but from around '05 onwards.
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.