Hardware manual

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 3 of 29
Mar 23, 2013
1. CAN Basics
CAN was designed to provide reliable, error-free network communication for applications in which safety and real-time
operation cannot be compromised. Its main attributes can be summarized as follows:
• High reliability and noise immunity
• Fewer connections
• Flexible architecture
• Error handling through peripherals
• Low wiring cost
• Scalability
The MCU and bus connectors need only two pins. Therefore, a CAN network is more reliable than other networking
schemes that need more wires and connections. Adding new nodes is simple; just tap the bus wire at any point.
CAN is based on a “multiple master, multiple slave” topology. Message or Data Frames transmitted do not contain the
addresses of either the transmitting node or of any intended receiving node. This means that any node can act as master
or slave at any time. Messages can be broadcast, or sent between nodes depending on which nodes at a particular
moment are listening to a certain ID. New nodes can be added without having to update others. Such design flexibility
makes it practical for building intelligent, redundant, and easily reconfigured systems.
Bit rate determines the number of nodes that can be connected and cable length. Allowed CAN data bit rates are: 62.5,
125, 250, 500 Kbps and 1 Mbps. At the highest speed, the network can support 30 nodes on a 40-meter cable. At lower
speeds, the network can support more than 100 nodes on a 1000-meter cable.
The basic building blocks of a CAN network are a CAN microcontroller, the firmware to run it, a CAN transceiver to
drive and read the bus signal, and a physical bus media (2 wires). Choose a CAN MCUs with enough mailboxes to fit
your applications.
2. The CAN Peripheral
The Protocol Controller of the CAN peripheral in your CAN MCU must via the CAN Tx and Rx MCU pins be
connected to a bus transceiver located outside the chip. The Protocol Controller reads and writes to the peripheral
mailboxes depending on how they are configured. The configuration is done through the CAN Special Function
Registers described in your MCU’s HW manual. As the registers in the CAN peripheral must be configured and read in
the proper sequence to achieve useful communication, a CAN API greatly simplifies this – the API takes numerous
tedious issues and does them for you.
After initializing the peripheral, all you need to do is use the receive and transmit API calls, and on a regular basis
check for any CAN error states. If an error state is encountered the application can just wait and monitor for the
peripheral to recover, as the CAN peripheral takes itself on or off line depending on its state. After a recovery is
discovered, the application should restart.