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

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.

Support for CAN-FD

The eCos CAN subsystem also provides support for CAN-FD messages. CAN-FD messages mainly looks similar to standard CAN messages except that the length field can specify packet sizes up to 64 bytes, and there is an option to transmit the data part of a message at a higher baud rate than the rest.

CAN-FD support is only enabled if a driver capable of supporting the protocol is present. Otherwise CAN-FD is not present.

CAN-FD support mainly consist of some extra fields in the CAN message structure and some additional API functions. Both standard CAN and CAN-FD messages may be sent and received using the common structure.