Overview

Description

The Controller Area Network, CAN, was originally designed for use in automotive systems where many small sensors report small values frequently. Consequently, CAN uses small messages of up to 8 bytes payload, which permits many messages to be passed each second and also reduces packet transmission latency.

CAN is a simple broadcast network carried on a twisted pair. It uses CSMA/CD, like ethernet, to access the medium, however the signal levels and messages format are designed to resolve collisions in favour of the highest priority packet, rather than the jam and random retry of ethernet. This yields a priority-based approach to contention that is better suited to real time applications.

CAN messages contain an 11 bit message id, up to 8 bytes of data, a 15 bit CRC and assorted control bits. The message ID is also the priority used to resolve collisions, and has to be unique. Since the network is broadcast, and there are no fixed node addresses, receivers need to have hardware acceptance filters to avoid having to process every packet.

There are two very distinct operational modes for CAN devices. The first of these is BasicCAN. This is the approach familiar from Ethernet controllers. Packets to be transmitted are fed one at a time into an output FIFO and are sent on the wire when it appears to be idle. Received packets are pulled off the wire and are compared against one or more acceptance filters. If they match they are placed into an input FIFO ready for the CPU to collect them.

The second approach is FullCAN. Here, the controller contains a number of packet buffers which are used for transmission or reception. To transmit, the packet is put into a buffer and the buffer state changed to "transmit" and the packet goes out when the controller and the line are ready. Received packets are compared against an acceptance filter on each buffer that is marked "receive" and copied into whichever buffer matches first. The clear intention here is that specific buffers are statically dedicated to particular communication channels.

The eCos CAN subsystem currently supports the BasicCAN mode only. FullCAN devices are driven in such a way as to provide BasicCAN functionality. FullCAN functionality can always be emulated using software.

You can find more information at the CAN in Automation website.

eCos Support for CAN

The eCos CAN support for any given platform is spread over a number of different packages:

• This package, CYGPKG_IO_CAN, exports a generic API for accessing devices attached to an CAN network. This API handles issues such as locking between threads. The package does not contain any hardware-specific code. Instead it will use a separate CAN device driver to handle the hardware, and it defines the interface that such network drivers should provide.

• Each CAN device will have its own device driver, which is implemented as a separate package. For devices that may be attached to a variety of different boards the device driver will be generic and a second platform specific package will be used to customize it to each platform. For devices that are associated with a specific chipset, only a single package may be present.

Typically all appropriate packages will be loaded automatically when you configure eCos for a given platform. If the application does not use any of the CAN I/O facilities, directly or indirectly, then linker garbage collection should eliminate all unnecessary code and data. All necessary initialization should happen automatically. However the exact details may depend on the platform, so the platform HAL documentation should be checked for further details.

There is an important exception to this: if the CAN devices are attached to an expansion connector, such as PCI, then the platform HAL will not know about these devices. Instead the necessary packages will need to be added explicitly during configuration.