Executive Summary
Because CAN was introduced inside the ’80s, it has observed a tremendous evolution with regards to specifications and needs. Its extended capabilities have led to its wide adoption across applications, from automotive to the industrial machine and factory automation. With this development, the complexity of implementation has also improved on two levels:
- CAN controller design has gone from a fundamental controller to a complete CAN controller and, in some instances, an extended full CAN controller.
- CAN application stacks vary, from an automotive communication stack to CANOpen, and DeviceNet?
Given which can is only a single element within the automotive system, developers have to be capable of implementing it with a handful challenges as possible so they could focus on system-level functionality instead of struggle with peripheral configuration.
This article will explore the CAN interface and talk about diverse strategies of implementing, configuring, and tuning interfaces to facilitate the simplified design. The Controller Region Network (CAN) was initially introduced by Robert Bosch to address the increasing complexity of automobile functions and networks. Within the early days of embedded systems development, modules contained a single MCU, performing a single or various basic functions such as reading a sensor level through an ADC and controlling a DC motor. As these functions became a lot more complicated, designers adopted distributed module architecture, implementing functions in 2 or extra MCUs on the very same PCB, and using I2C or SPI protocols to communicate among these functions. Applying the identical instance above, a complex module would have the most important MCU performing all system functions, diagnostics, and failsafe, even though an additional MCU handles a BLDC motor control function. This was produced attainable with all the wide availability of basic objective MCUs at a low cost.
In today’s vehicles, as functions grow to be distributed inside a car instead of a module, the require for any high fault tolerance, inter-module communication protocol led to the design and introduction of CAN inside the automotive the mid-nineties, CAN have seen wider adoption beyond automotive, with industrial controls with all the introduction of DeviceNet and CANOpen protocols. With this traction within the market, numerous MCU suppliers have integrated a CAN Controller as an integrated peripheral to address these markets. Even though at a higher level, CAN appear comparable in function to I2C or SPI, allowing communication amongst 2 nodes, CAN’s communication is fundamentally distinctive at the controller level, together with the services listed below:
- CAN communication is message-based, not address based.
- A CAN node can send or request a message around the bus.
- Complex error handling.
- Up to 5 corrupted bits in a row can be detected with CRC-15 protection.
Being message primarily based versus address-based, a node on the CAN bus could own many messages for transmission; i.e. A Brake module may possess a message containing car speed facts, a message containing sensor info, which includes wheel speed sensors, along with a message containing the diagnostics information, the latter having the highest transmit priority. At first, appear at message priority and message ID decoding in a node, 1 may well believe that can would generate a higher load on the CPU, preventing additional complicated functions from becoming integrated.
- Standard CAN Controller: Pretty basic filtering implemented within the CAN Controller hardware, with reduced message handling, top to a higher CPU load. Inside a fundamental CAN controller, the CPU would get multiple interrupts from the CAN controller to acquire, acknowledge, and parse a message, and on the application side, determine no matter if or not a response ought to be transmitted according to the ID of the received message. Standard CAN controllers ought to only be applied in low baud price, and low message count communications, enabling the CPU to handle additional non-communication tasks.
- Complete CAN Controller: supplies a comprehensive implementation of message filtering, too as message parsing within the hardware, thus releasing the CPU in the process of getting to respond to just about every received message. Complete CAN controllers are often configured to interrupt the CPU only when messages whose Identifiers have already been set up as acceptance filters within the controller. Full CAN controllers are also set up with many message objects known as mailboxes, which can store precise message details for instance ID and information bytes received for the CPU to retrieve. The CPU in this case would retrieve the message any time, on the other hand, ought to total the activity before an update of that very same message is received and overwrites the current content of your mailbox. This scenario is resolved in the final variety of CAN controllers.
- Extended Complete CAN controller: gives a more degree of hardware-implemented functionality, by supplying a hardware FIFO for received messages. Such an implementation permits an extra than 1 instance on the same message to become stored just before the CPU is interrupted thus preventing any data loss for high-frequency messages, or perhaps enabling the CPU to concentrate on the most important module function to get a longer period.
Depending on the message architecture, the above 2 configurations can coexist in a single module, as a way to implement high-level message priority and enhance received message handling for the CPU. For instance, a module getting failsafe facts in a single message (i.e. ID = 0x250) and temperature sensor data in yet another message (i.e. ID = 0x3FF) could configure the CAN controller as full for the initial, and extended completely with 4 buffer FIFO for the second: CPU is interrupted when every failsafe message is received, and after every single 4 temperature sensor message received; CAN controller configuration having a visual CAN controller customizer for quickly implementation of complicated message handling schemes where all 3 sorts of CAN controllers co-exist:
- Message 5 – Standard CAN Mailbox.
- Message 0x250 – Full CAN Mailbox.
- Message 0x3FF – Extended Full CAN Mailbox.
Also to its functional capabilities, CAN has been extensively adopted for its higher fault tolerance. With bit rates as much as 1Mbps, or bus length as much as 1000m (at 50Kbps), CAN bit timing should be implemented to permit functionality in an electrically noisy atmosphere even though keeping a high degree of failure detection and correction.
To guarantee a higher level of fault tolerance, a sub-bit timing configuration has been introduced with CAN to allow a tighter handle of determining the appropriate bus state for every CAN Bus.
