An embedded systems engineer knows that each type of bus has unique characteristics in terms of reliability, throughput, topology, priority handling, cost, and noise immunity. Cheesy title aside, I would like to talk a little bit about the controller area network (CAN) bus found in the RX62N, which has proved itself in the automotive industry and can be found in applications as disparate as airplanes and coffee machines.
The CAN bus was invented in 1986 by engineers from the Robert Bosch company. Designed to be reliable and extendable, it is multi-master. A single-master bus, such as USB, makes sense when there is a natural master/slave relationship, as there is between a PC and its peripherals. But a multi-master bus avoids single-point-of-failure scenarios and allows any node on the bus to produce messages, without requiring any changes to existing nodes.
The CAN bus has a number of other features that help make the bus highly reliable:
Each message contains a Cyclic Redundancy Code (CRC) portion that allows each node to verify that it has received the message successfully. In the case of a CRC failure, the sender will be notified and the message is retransmitted.
Each node also counts the number of times it transmits a message that is unintelligible or is unable to successfully receive a message from another node. If either happens too often, the node will disconnect itself from the bus.
Typical CAN bus implementations use a twisted-pair differential signal in the physical layer. This allows for operation in high-noise environments, and, with the right drivers, will continue to work even if one of the wires is cut!
The CAN bus also has a particularly clever solution to priority handling. Other multi-master protocols, such as Ethernet, use a backoff-and-retry mechanism when more than one node begins sending at the same time. However, the CAN bus includes an arbitration protocol where the lower-priority sender will simply quit sending, without interrupting the higher-priority sender, and try again later. This makes the bus especially suited for hard-realtime applications.
So how do you include the capabilities of CAN in your application? The good news is that it is very straightforward. Renesas provides free CAN middleware, and every member of the RX family of microcontrollers includes robust CAN peripherals.
CAN applications require each node to filter messages. Simple CAN implementations rely on the CPU for filtering, which keep the CPU from doing other things, but the RX CAN peripheral handles filtering in hardware. It also includes a FIFO that allows messages to be processed asynchronously, allowing for even better CPU utilization.
Where should you go to learn more? I recommend starting with the “CAN Application Programming Interface” document, that will introduce you to the API provided by Renesas to get you started quickly.