CanBus (2019-06-05 14:44:49)

Overview

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

VEMS v3 has SPI_CAN since the very beginning. It's used for BMW S65 and S68 CAN-bus of DBW throttles and idle valve (the termination resistor differs between S65 and S68, but otherwise the protocol is same).

CAN bus is also useful for dashes. The [VEMS STM32 Aim to CAN] (2nd CAN interface via 2nd serial => AIM, see AimToCanBusPinout ) is used in general to send data to dash.

To specify your requirement, on your project page, use


Using CAN bus involves:


See VemsFrontier/NetWorkHardWare for other ways to connect microcontrollers.

Important notes

If 2 devices are incompatible on the physical or datalink layer, it does not make sense to talk about making them more compatible or "standard". But bridging these segments is possible of course. Even real CAN devices are incompatible if (configured to) different speed ! With different speeds, they must be on different segments.


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.


( move to VemsFrontier/NetWorkHardWare )

Alternatives

If CAN is overkill for a given application, that don't need the reliability or overhead (and speed) of CAN:

Note that a segment like this would not be compatible with a real CAN segment (had to be separated).

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).
http://en.wikipedia.org/wiki/Controller_Area_Network

"Devicenet" is a higher-layer protocol on top of CAN hardware ( http://en.wikipedia.org/wiki/DeviceNet ).


( move to VemsFrontier/NetWorkHardWare )

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

Jason, can you buy the data-link layer of this from vems money ? - appr. $50. It's OK licensed to you, easier to buy that way (since paid from your account). But Marcell will read it, and might ask Richard Barrington to help understand it :-)

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.


The OBD-II (On-Board Diagnostics) plug is required by law on every car sold in the US.

http://www.pcmag.com/article2/0,1895,2012389,00.asp

http://en.wikipedia.org/wiki/On_Board_Diagnostics

http://en.wikipedia.org/wiki/Talk:On_Board_Diagnostics