1. ID 210C: Introduction to CAN/LIN Solutions
Good Morning & Welcome to the “Introduction to CAN/LIN Solutions” session
Renesas Electronics America Inc.
Sridhar Lingam
Product Marketing Manager
12 October 2010
Version 10

2. Product Marketing Manager
Sridhar Lingam
Product Marketing Manager
Renesas MCU CAN Solutions
M16C/R32C, H8S/H8SX Product Families
TFT-LCD solution for H8S and H8SX
Education
MSEE from the Clemson University, Clemson, SC
Work Experience
16 years experience with semiconductor Industry with focus on Industrial applications
Varied experience as Product Engineer, FAE and Product Marketing
Responsible for definition and Marketing of Memory & MCU product families
Previously worked at National Semiconductor, STMicroelectronics & Atmel
My name is Sridhar Lingam and I am a Product Marketing Manager responsible for the Renesas MCU CAN solutions. I am also responsible for the M16C/R32C, H8S/H8SX core product families.
I have a MSEE from Clemson and I have been in the semiconductor industry for the last 16 years starting my career as a Product and Test Engineer with National Semiconductors. Since then, I have been in varied roles as a FAE in the Industrial segment and Product Marketing for Memories and Microcontrollers. Besides Renesas and National, I was at ST and Atmel.

3. Renesas Technology and Solution Portfolio
Microcontrollers & Microprocessors #1 Market share worldwide *
Solutions for Innovation
Analog and Power Devices #1 Market share in low-voltage MOSFET**
ASIC, ASSP & Memory Advanced and proven technologies
In the session 110C, Renesas Next Generation Microcontroller and Microprocessor Technology Roadmap, Ritesh Tyagi introduces this high level image of where the Renesas Products fit. The big picture.
* MCU: 31% revenue basis from Gartner "Semiconductor Applications Worldwide Annual Market Share: Database" 25 March 2010
** Power MOSFET: 17.1% on unit basis from Marketing Eye 2009 (17.1% on unit basis).

4. Renesas Technology and Solution Portfolio
Microcontrollers & Microprocessors #1 Market share worldwide *
Solutions for Innovation
ASIC, ASSP & Memory Advanced and proven technologies
Analog and Power Devices #1 Market share in low-voltage MOSFET**
This is where our session, ‘210C Introduction to CAN/LIN Solutions’ is focused within the ‘Big picture of Renesas Products’ <Click>    
* MCU: 31% revenue basis from Gartner "Semiconductor Applications Worldwide Annual Market Share: Database" 25 March 2010
** Power MOSFET: 17.1% on unit basis from Marketing Eye 2009 (17.1% on unit basis). 4

5. Microcontroller and Microprocessor Line-up
Up to 1200 DMIPS, 45, 65 & 90nm process
Video and audio processing on Linux
Server, Industrial & Automotive
Superscalar, MMU, Multimedia
Up to 500 DMIPS, 150 & 90nm process
600uA/MHz, 1.5 uA standby
Medical, Automotive & Industrial
High Performance CPU, Low Power
Up to 165 DMIPS, 90nm process
500uA/MHz, 2.5 uA standby
Ethernet, CAN, USB, Motor Control, TFT Display
High Performance CPU, FPU, DSC
Legacy Cores
Next-generation migration to RX
H8S
H8SX
M16C
R32C
Here are the MCU and MPU Product Lines, I am not going to cover any specific information on these families, but rather I want to show you where this session is focused
General Purpose
Ultra Low Power
Embedded Security
Up to 10 DMIPS, 130nm process
350 uA/MHz, 1uA standby
Capacitive touch
Up to 25 DMIPS, 150nm process
190 uA/MHz, 0.3uA standby
Application-specific integration
Up to 25 DMIPS, 180, 90nm process
1mA/MHz, 100uA standby
Crypto engine, Hardware security 5

6. Microcontroller and Microprocessor Line-up
Up to 1200 DMIPS, 45, 65 & 90nm process
Video and audio processing on Linux
Server, Industrial & Automotive
Superscalar, MMU, Multimedia
Up to 500 DMIPS, 150 & 90nm process
600uA/MHz, 1.5 uA standby
Medical, Automotive & Industrial
High Performance CPU, Low Power
Up to 165 DMIPS, 90nm process
500uA/MHz, 2.5 uA standby
Ethernet, CAN, USB, Motor Control, TFT Display
High Performance CPU, FPU, DSC
CAN MCU Solutions
R8C/R32C/SH/RX
Legacy Cores
Next-generation migration to RX
H8S
H8SX
M16C
R32C
Since the merger, we have scrutinized the needs of our global markets, reassessed our strengths, and implemented a business strategy focusing on supporting the ‘ubiquitous computing’ paradigm. This insightful concept — often abbreviated as ‘ubicomp’, and sometimes termed ‘pervasive computing’ or ‘ambient intelligence’ — was introduced by Mark Weiser of Xerox in 1988.
Ubiquitous computing refers to a new genre of computing, a worldwide electronic environment in which computer-controlled products completely permeate the life of end users around the globe. Obviously, many types of products and an enormous range of applications are encompassed by this paradigm, all driven by human ingenuity, engineering creativity and marketing expertise. To one extent or another, people everywhere are already beginning to enjoy the first wave of benefits of the concept’s reality.
General Purpose
Ultra Low Power
Embedded Security
Up to 10 DMIPS, 130nm process
350 uA/MHz, 1uA standby
Capacitive touch
Up to 25 DMIPS, 150nm process
190 uA/MHz, 0.3uA standby
Application-specific integration
Up to 25 DMIPS, 180, 90nm process
1mA/MHz, 100uA standby
Crypto engine, Hardware security 6

7. Innovation
CAN is a very popular interface in the automotive industry and it’s success is spilling over to the other application segments as well. Some of these application segments are BA, locomotives, Medical devices, factory automation, white goods, and others have all adopted CAN for the many features and functions it provides. Where safety and reliability are important, CAN has found a need.

8. Our CAN/LIN Solution
Renesas’ easy to design MCU CAN/LIN solutions provide highly reliable, expandable, and noise immune interfaces for industrial applications using chip to chip communications.
The CAN and LIN serial protocols were initially developed to be used in the Automotive Industry. Since then, these serial protocols have been adapted in various embedded applications.
In our presentation we will explore the advantages of the CAN and LIN interfaces and the reasons they are being adopted in embedded applications especially Industrial controllers.

9. Agenda CAN in Embedded Networks What is CAN & it’s benefits?
Can Basics
What is LIN and it’s benefits?
Renesas MCU CAN Solutions
Q&A
Just like the topic I am discussing, I wanted to keep the agenda simple. I am going to give a brief overview of CAN and LIN and then dive into a few details on each. Starting with CAN and then following up with LIN information. At the end I will have time to take questions from you to answer anything that I was not able to cover in the general material.

10. Key Takeaways Reasons for using CAN and LIN Benefits of CAN and LIN
Basics of CAN and LIN
General differences between CAN and LIN

11. What is CAN ? Controller – Area – Network
Developed in 1983 by Robert Bosch
To solve the networking issues in automotive
Main Benefits
Economical
Reliable
Real Time response
Scalable
Standards
CAN 2.0A (ISO11519)
Can 2.0B(ISO11898)
The Controller Area Network, or CAN, is a two-wire (twisted-pair), bidirectional serial-bus communication method that allows electronic subsystems to be linked together and interact in a network. It was originally developed in 1989 by Bosch for use in automotive applications.
CAN is noted for its high integrity for real-time applications. It performs well in noisy environments because CAN hardware incorporates features designed to ensure reliable communication.
CAN specifications are international standards. Two versions now in use. CAN 2.0A, the low-speed version, sometimes known as Basic or Standard CAN, is defined by the ISO11519 standard. CAN 2.0B, the high-speed version, also known as Full CAN or extended-frame CAN, is defined by the ISO11898 standard.
CAN is finding use in a growing number of non-automotive applications Industrial control. Still, better than 80% of the more than 100 million nodes now implemented per year are in vehicles.

12. CAN-Leading Choice for Embedded Networking
The main Reasons are
Economical
Low Wiring Cost
Low Hardware Cost
Reliability
Error Free Communication
Immune to EMI/EMS
Availability
Several 8/16/32 bit MCU available in the market
Standard development tools
Scalability
As previously mentioned, CAN has become the choice for embedded networking applications that need to communicate between 8/16/32 bit microcontrollers. Some of the biggest examples are in construction equipment, industrial, home appliance, recreation vehicles which use multiple controllers that need to communicate with each other.
A big advantage of CAN is the cost/performance ratio; pricewise, CAN is the most affordable next to a serial channel. The reduced number of wires makes it very cost efficient;
the inherent quality to noise immunity makes it very reliable; Built-in error detection methods help in accurate communication
There are several microcontrollers with one or multiple on-chip CAN interfaces making it easier to CAN-enable an application. However, there are
major differences in the CAN controllers available that can make a big difference when it comes to performance. One of the major differences being the
MCU capability to run the application efficiently while CAN-enabling it.
There is no limit on the number of nodes that can be added to the CAN network helping to add functionality.

13. Reliability (works well in noisy environment)
Question
Please give 3 reasons for the growing popularity of CAN in embedded applications
Reliability (works well in noisy environment)
Economical ( Have low wiring costs)
Scalability
Availability
Now it is time for a question on what we have seen so far…

14. Features and Benefits of CAN
Multiple Master Hierarchy
1 Mbps of Data transfer rate
0-8 Bytes of User Data
Unique mail box Identifiers
Acceptance Filtering by nodes
Provides Error Detection
Fault Confinement measures
Auto re-transmit if corrupted
Redundant Intelligent Systems
Real Time Response
Simplifies design requirements
Flexibility in System Design
Arbitration & Prioritization
Ensures high Reliability
Keeps the traffic undisturbed
Accurate communication link
With those five reasons in mind, let’s now summarize the main features of CAN that underlie its growing application popularity.
CAN has a multi-master hierarchy. This arrangement gives good design flexibility and allows building intelligent and redundant systems.
It operates at transfer rates up to 1 Megabit/sec (1 Mbps or 1 Mbaud) in CAN 2.0B. This speed provides sufficient data-communication bandwidth for many real-time control systems.
The CAN protocol allows each CAN data frame to carry from zero to as many as eight bytes of user data per message, thus accommodating a wide span of signaling requirements. If necessary, more data can be transmitted per message using a higher-layer segmentation protocol.
Each node on a CAN network can have have several buffers or message mailboxes. On initialization, each mailbox is assigned an identifier that is either unique or is shared with certain other nodes. Also, each node is individually configured as a transmitter or receiver. This approach offers considerable flexibility in system design.
Data messages (data frames) transmitted from any node on a CAN bus do not contain the addresses of either the transmitting node or of any intended receiving node. This eliminates data bits that would otherwise use up some of the available bus bandwidth. It also simplifies the communication software.
In lieu of transmit and receive node addresses, messages are labeled by an identifier (ID) assigned one or more nodes on the network. All nodes receive the message and perform a filtering operation. That is, each node executes an acceptance test on the identifier to determine if the message — and thus its content — is relevant to that particular node. Only the node(s) for which the message is relevant will process it. All others ignore the message. The identifier has two more functions, as well. It contains data that specifies the priority of the message and it allows the hardware to arbitrate for the bus. That is, it’s used to determine which node gets to transmit if several nodes attempt to do so simultaneously.
Every node on the bus validates every message. Corrupted messages aren’t validated, of course, and that situation triggers automatic re-transmissions.
Error detection and error signaling features and fault-confinement measures are defined in the CAN standard. They make the CAN bus very reliable — even in noisy environments — by ensuring that the information communicated between nodes is correct and consistent. If a node is faulty, it goes into a (safe, limited, restricted, ??) operating mode that prevents it from disturbing the traffic on the bus

15. CAN and the 7-layer model
ISA/OSI Reference Model
7. Application Layer
6. Presentation Layer
Partially implemented by higher-level CAN protocols (CANOpen)
5. Session Layer
4. Transport Layer
3. Network Layer
The Controller Area Network (CAN) specification defines the Data Link Layer, ISO defines the Physical Layer. Having the Data Link Layer managed in hardware allows for more CPU cycles available for application management and better real-time control since time does not need to be allotted for simple message monitoring. This single reason should give all of the software engineers and management reason to listen intently about CAN. Using CAN will make designing easier while providing better functionality than other serial communication protocols, especially the RS-485.
The standard CAN implementation bypasses the connection between the Data Link layer and the Application layer. The layers above the Data Link Layer are implemented in software which as per definition are called the Higher Layer Protocol – CANOpen for machine Control, DeviceNet for factory automation, J1939 for vehicles.
These
Standard CAN implementation
2. Data Link Layer
Managed in Hardware.
Dramatic Real-time advantage to System Design
1. Physical Layer

16. Data Frame is broadcast to the bus
Data Flow in CAN
Node Configured to
receive identifier
Node not Configured to
receive identifier
Transmitting Node
MCU Firmware
MCU Firmware
MCU Firmware
Identifier [id_n]
Identifier [id_n]
Data [values_x]
Data [values_x]
Tx Mail Box [id_n]
Rx Mail Box [id_c]
Rx Mail Box [id_b]
Rx Mail Box [id_d]
Rx Mail Box [id_b]
Data [values_x]
Rx Mail Box [id_n]
Rx Mail Box [id_c]
Rx Mail Box [id_a]
Rx Mail Box [id_c]
Rx Mail Box [id_b]
Data [values_x]
When a transmitter at a CAN node sends a data frame, it broadcasts that message to all nodes on the bus. However, only those nodes configured to receive the identifier in that message will accept and save the data. All other nodes don’t do anything with the data; they ignore it.
CAN 2.0A has an 11-bit message identifier and was originally specified to operated at a maximum frequency of 250Kbits/sec. CAN 2.0B has 11-bit or 29-bit message identifiers and can be used speeds at up to 1Mbit/sec.
This diagram illustrates the basic data flow process. The block on the left represents a transmitting node; the one in the middle and the one on the right represent receiving nodes.
The middle node has a receiver mailbox set to an identifier that either matches the transmitted identifier exactly or is within a software-defined identifier range of it, so it accepts the data frame. The node on the right has a receiver mailbox set to a different identifier than the transmitted one, so it doesn’t accept the message.
Nevertheless, both receiver nodes (and all other receiver nodes in this CAN implementation) subsequently verify and acknowledge the data frame content to prove successful message transmission.
CAN Peripheral
CAN Peripheral
CAN Peripheral
CAN Transceiver
CAN Transceiver
CAN Transceiver
Data Frame is broadcast to the bus [ id _ n ][
value _ x ]

17. Data Frame Start of Frame – 1-bit Arbitration Field – 11-bits/29-bits
Control Field – 6 bits (2 reserved, 4 representing number of Data Field bytes)
Data Field – 0 to 8 BYTES
CRC – 15-bits
ACK Field – 1-bit/variable
End of Frame – 7-bits (recessive) S O F 1
Identifier
11/29
Rem Req 1
ID extend 1
Control 4
Data
(Bytes)
0-8 bytes C R 15 A C K 1 E O F 7+
The Data Frame consists of the following ‘fields’:
- Start of Frame
- Arbitration Field, this is where the identifier is placed. The upper frame is a data frame with a standard 11-bit id and the lower data frame has the less common extended 29-bit id length (for CAN2.0B spec)
- Control Field containing the Data length Code, DLC, the number of bytes In the Data Field
- Data Field, contains the payload
- CRC
- ACK Field
- End of Frame
SOF: CAN has a multi-master capability, meaning any node on the bus can initiate communication to any node configured to receive. This is done with a Start of Frame. A single dominant bit while the bus is idle indicates a transmitting node is starting a frame.
All nodes on the bus will synchronize their bit timing to the leading edge of SOF.
Arbitration Field: ID, or identifier of CAN 2.0B, may be 11 or 29 bits long This is determined by FW at initialization by setting the ID-extension bit (and then configuring each can mailbox with a long ID instead of a standard). Extended ID is less common but you need extended ID in case you have more than 2032 IDs to differentiate.
CAN has a multi-master capability meaning any node on the bus can initiate communication to any other node. This is where the Arbitration Field comes in...
Note that because of backward compatibility to CAN 2.0A which just has 11 bit long only, the extended ID is split into two pieces; a high order 11 bit field, and a low order 18 bit field. Because the ID extend bit is recessive in the extended format, that the standard ID has a higher priority than the extended ID for the same leading 11 bit identifier.
To allow multiple devices to initiate communication, the arbitration protocol determines which device will receive priority and access to the bus. This is called Carrier Sense Multiple Access/Collision Resolution (CSMA/CR).
When two nodes negotiate for the bus at the same time, a dominant bit state will override a recessive bit state. When a node transmits a recessive state on the bus, but detects a dominant state on its receiver, it knows that higher priority message is being transmitted and immediately ceases transmission. The losing node will renegotiate for the bus as each new opportunity comes until the message is transmitted.
The Control Field consists of six bits
- 2 are reserved
- 4 are the Data Length Code which indicates number of data bytes in the data field [0-8 bytes being valid sizes]
DLC codes not shown in the figure are reserved
This field carries the actual payload of the can-bus communication. It may be 0 to 8 bytes long, as defined by the Data Length Code in the Control Field. The most significant bit is transmitted first within each byte.
The CRC Field is sent by the transmitter and verified by all receivers. Each receiver generates a CRC on the observed data frame and compares it with the transmitted CRC check value. If it is they match, a dominant bit is put into the ACK slot. If the result is a mismatch, nothing is transmitted by that node; instead, a ‘no’ vote is sent AFTER the upcoming ACK delimiter, that is at End of Frame.
The ACK FIELD is two bits long and contains the ACK slot and the ACK delimiter. In the ACK slot the transmitting station sends two recessive bits. Every receiver which has received a valid message correctly, reports this to the transmitting node with a ’dominant’ bit during the ACK slot. Any node that disagrees, votes no after the delimiter by sending an error flag.
This is the last of the fields of the data frame. The End of Frame field provides the necessary portion of idle between messages, for example for the transmitter to detect if a node decided to send an error frame, which is allowed anytime.
The End of Frame field consists of seven recessive bits.

18. Overall data bandwidth decreases Decrease in reliability
Question
Why do most CAN applications use CAN 2.0A (11-bit identifiers) and not CAN 2.0B (29-bit identifiers)?
Overall data bandwidth decreases
Decrease in reliability
Increase in worse case delay
Now time for another question…
Why do most CAN applications use CAN 2.0A (11-bit identifiers) and not CAN 2.0B (29-bit identifiers)?
A: CAN supports both protocol variants, however - switching to the 29-bit identifiers has several consequences:
As only the address field is extended, but not the data field, the overall available data bandwidth decreases. More bits of overhead were added to each message.
The overall reliability decreases, as the CRC checksum in each message now needs to cover 18 bits more.
The worst case delay for high priority messages becomes longer. Even a low priority message can not be interrupted or aborted once it won arbitration to the bus. And the maximum length of messages on the bus was now increased by 18 bits.

19. CAN Bus Characteristics
Dominant bits (0’s) override recessive bits (1’s) on the CAN bus.
Node 1 Backs Off
Node 1 1
Node 2 Backs Off
Node 2
The “0”s are defined as dominant and “1”s are recessive bits.
Each node senses the bus while transmitting. When there is a difference between what the node is transmitting and the bus value, the node recognizes it does not have control of the bus and backs off automatically. CAN 1 1
Node 3
LSB…MSB

20. Maintaining Synchronization
‘Bit Stuffing’ is applied to keep the bus synchronized
Five bits of consecutive dominant or recessive bits inserts a bit of the opposite polarity
Resulting signal edge is used to establish timing synchronization at all nodes
Stuffed bits are managed by hardware
It’s essential that timing synchronization always be maintained at all network nodes. Many network communication methods mandate that a signal line return to the zero state after each bit is transmitted. The resulting transitions are used to keep the serial data synchronized.
But as mentioned before, CAN uses a NRZ serial data transmission method, so a string of repeating 1s or 0s contains no state transitions. Such strings, if they were long enough, might cause a loss of synchronization due to variations in the frequencies of the clocks at different nodes.
For this reason, CAN uses ‘bit stuffing’ to maintain synchronization. Bit stuffing means that when too many dominant or recessive bits are sent consecutively to keep the bus synchronized, the transmitting node inserts an opposite-polarity bit. Specifically, CAN requires that bit stuffing be applied after there is a sequence of five bits with the same polarity.

21. Bus Access and Arbitration
The CAN protocol handles bus accesses according to the concept of “Carrier Sense Multiple Access with Collision Detection”
For a collision, messages are NOT destroyed! No bandwidth is wasted on collisions!
The message with the higher priority wins bus access
NDA – “Non-destructive Arbitration”
Each message has an identifier that determines the priority
Each node defined by unique identifier to avoid collisions
AMP – “Arbitration by Message Priority”
When used with a differential bus, a Carrier Sense Multiple Access/Bitwise Arbitration (CSMA/BA) scheme is often implemented: if two or more devices start transmitting at the same time, there is a priority based arbitration scheme to decide which one will be granted permission to continue transmitting. The CAN solution to this is prioritized arbitration (and for the dominant message delay free), making CAN very suitable for real time prioritized communications systems.
During arbitration, each transmitting node monitors the bus state and compares the received bit with the transmitted bit. If a dominant bit is received when a recessive bit is transmitted then the node stops transmitting (i.e., it lost arbitration). Arbitration is performed during the transmission of the identifier field.
Each message has an identifier that determines the priority
This ID may only be transmitted by one node in the system to avoid collisions due to messages of the same priority
AMP – “Arbitration by Message Priority”
Each node starting to transmit at the same time sends an ID with dominant as binary 0, starting from the high bit. This ID may only be transmitted by one node in the system to avoid collisions due to messages of the same priority. As soon as their ID is a larger number (lower priority/recessive) and see 0 (higher priority/dominant), they back off. At the end of ID transmission, all nodes but one have backed off, and the highest priority message gets through unimpeded
Unlike with Ethernet, a collision within CAN is resolved

22. (Differential Serial Bus)
CAN and EMI
Node A
Node B
Node C V
U diff
CAN_H
CAN_L t
(dominant level)
CAN_H
Differential: the difference between the voltage at one input and the voltage at another input that is not necessarily ground is maintained. Being a differential serial bus, CAN is not sensitive to electromagnetic interference
Since CAN is a differential interface, it inherently is less sensitive to noisy environments. When EMI is injected into the system, the signal levels move appropriately together to keep the voltage difference between the lines the same. Shielding of twisted pair is also useful in protecting against noise.
EMI
CAN_L
CAN-Bus
(Differential Serial Bus)

23. CAN Baud Rate vs. Bus Length
1000
500 10 5
Bit Rate
[kbps] 20 50
200
100
Bus lines assumed to be an electrical medium
(e.g. twisted pair)
While the electrical characteristics allow for higher then 1Mbps, CAN limits the bit rate. This is one of the differences between RS-485 and CAN, where CAN has added an additional control to provide reliability.
Up to 40m bus length (120 feet)
Up to 1000m bus length ( kbit/s
For a length > 1000m, special drivers or repeaters should be used 40
100
1000
10,000
CAN Bus Length [m] 10
200

24. Error Detection in CAN
Error statistics depend up on the entire environment
Total number of nodes
Physical Layout
EMI Disturbance
CAN application example running at
2000 hours/year, 500 Kbps, 25% Bus load
Results in one undetected error in 1000 years
Some common practices are transmitting key control packets twice. The second time the message is inverted. This allows redundant verification and removes issues like physical bus or transceiver issues.
Protocols and proper practices for handling critical messages can remove even this probability!

25. (Differential, e.g Twisted Pair)
Physical Layer
CAN_Txd
CAN_Rxd
Controller
CAN
Differential
Transceiver
CAN_Txd
CAN_Rxd
Physical CAN Bus
(Differential, e.g Twisted Pair)
Optical
Transceiver
CAN_Txd
CAN_Rxd
Optical Fiber
Media needs to support Recessive and Dominant states
Usual ISO Physical Layer:
Bus wires twisted pair, 120R Termination at each end
2 wires driven with differential signal (CAN_H, CAN_L)
Other physical layers also possible
(e.g. fiber-optical, wire-less, power-line)

26. Cables and Connectors CAN does not specify the physical media
Common Wire
Twisted pair
Shielded twisted pair
If optional power is needed: additional twisted pair
A pair of “shielded twisted pair”
Application specific
Common Connector
9-pin Dsub
5-pin mini style
Terminal blocks
Application specific (e.g. telephone jacks)
While CAN does not require specific cabling or connectors, there have become a few commonly used. Shielded twisted pair and pairs are common wiring, while Terminal Blocks are the most common connector.

27. What is LIN ? Local Interconnect Network
A slower & low cost alternative to CAN
Developed by LIN Consortium in 2002
Developed as a sub-network of CAN to reduce the Bus Load
Applications
Automotive, White Goods, Medical – for sensors and actuators

28. Features & Benefits of LIN
Complementary to CAN
Single Wire Implementation
Speed up to 20Kbps
Single Master/Multiple Slave
Based on common UART/SCI
Self Synchronization
Guaranteed latency times
Extends CAN to sub-nets
Reduce harness costs
Improves EMI response
No arbitration necessary
Reduces risk of availability
No external crystal
Deterministic & Predictable
The main features of the Lin are
LIN is an able ally of CAN; It is intended to complement the existing CAN network leading to hierarchical sub networks within applications
It is a single wire implementation thereby reducing harness costs
The speed is 20 Kbps to help maintain the reliability of the network
LIN is a broadcast serial network comprising one master and many (up to 16) slaves. No collision detection exists, therefore all messages are initiated by the master with at most one slave replying for a given message identifier.
uses a low cost silicon implementation based on common UART/SCI interface hardware and hence almost any Microcontroller has necessary hardware on chip
Self synchronization without crystal or ceramics resonator in the slave nodes and helps in a significant cost reduction of hardware platform
Guaranteed latency times for signal transmission making it a predictable network.

29. Typical LIN Network Simplex 12V Operation ECU & Gateway Node A Node B
Node C
Node D
CAN phys IF 5V
CAN
SCI
SCI
SCI
SCI
XCVR
XCVR
XCVR
XCVR
SCI
LIN phys IF
Simplex
12V Operation
The LIN solution works with a simple SCI and an enhanced ISO 9141 interface, the subnodes don't need a crystal and the connection is just one wire.
This is unlike in CAN, where all nodes need to have a CAN interface, a crystal, there is a two wire connection between the nodes.
A significant advantage with LIN protocol is that it offers message timing predictability.
The number of transmitted data bytes and the distance between the beginning of two messages is known. This helps in the calculation of the minimum length and the max. message length. Each Message has length budget of 140% of it’s minimum length and therefore the maximum allowed length is known.

30. LIN Message Frame Identifier Byte Synchronization Message Frame
message header
0 to 8 data fields
checksum
message response
synch break
 13 bit
synch field
identifier
Identifier Byte
Message
Synchronization
Frame
LIN synchronizes using a 0x55 sync frame. After synchronizing, the slaves are able to maintain accuracy for the rest of the frame. Since the message frame is so short and the device is able to sync at the start, LIN slaves are able to function with internal RC’s accurately, to reduce cost.
Synch BREAK: The BREAK field is used to activate all attached LIN slaves to listen to the following parts of the header. It consists of one start bit and several dominant bits. The length is at least 11-bit times; standard use as of today are 13-bit times, and therefore differs from the basic data format. This is used to ensure that listening LIN nodes with a main-clock differing from the set bus baud rate in specified ranges will detect the BREAK as the frame starting the communication and not as a standard data byte with all values zero (hexadecimal 0x00).
Synch Field: The SYNC is a standard data format byte with a value of hexadecimal 0x55. LIN slaves running on RC oscillator will use the distance between a fixed amount of rising and falling edges to measure the current bit time on the bus (the master's time normal) and to recalculate the internal baud rate.
The identifier field is sent by the master node to all LIN nodes and normally contains one of 64 different values and includes 2 parity bits in the 8 bit data. The identifier contains information such as sender, receiver, purpose and data field length, that are subsequently transmitted on the LIN bus
In a specific case this can initiate SLEEP mode in the LIN slave nodes – in this case no further data is transmitted on the LIN bus
4 classes of 1/2/4/8 Data Bytes. The length coding is in the 2 LSB of the ID-Field
Synchronization
Field

31. LIN Physical Interface
Usually managed by a transceiver
LIN Control Unit
recessive
logic ‘1’
dominant
logic ‘0’
60%
40%
Bus Voltage
Time
VBAT
8...18V
master: 1k
slave: 30k
controlled slope
~2V/µs
UART Rx
Bus Tx
Most LIN implementations use a transceiver to manage the interfacing and support the higher voltage levels. Some applications have moved to reduce costs by removing the transceiver and act as “LIN-like” designs. These systems maintain the functionality and features of LIN but due to the 5V bus voltage have less range with noise immunity.
GND
Example capacitances
master: 2.2nF
slave: 220pF

32. Taking account of Ground-Shift
Sense voltage
Data timing
The detection point for data transitions can be affected by voltage references. Ground shift can change this reference by a significant amount, affecting the bit timing of the data
Ground shift causes a difference in the valid read time for either 0 or 1. LIN takes this into consideration manages the sampling time to exclude the area between the Green and Blue lines. It does this by allowing 140% for time slicing. Controlling and maintaining this is the reason for the LIN bus being rated so slow.
Lin Handles this by implementing 140% for time slicing
Available bit sampling zone can reduce worst case bit width to around 40us at 20k baud (20% for each bit)
This affects the overall baud rate tolerance required for safe LIN communications

33. LIN Baud Rate Requirements
(1)The pre-synchronization accuracy in rev. 1.3 is ±15%, but this is tightened to 14% in LIN 2.0
BREAK: The BREAK field is used to activate all attached LIN slaves to listen to the following parts of the header. It consists of one start bit and several dominant bits. The length is at least 11-bit times; standard use as of today are 13-bit times, and therefore differs from the basic data format. This is used to ensure that listening LIN nodes with a main-clock differing from the set bus baud rate in specified ranges will detect the BREAK as the frame starting the communication and not as a standard data byte with all values zero (hexadecimal 0x00).
SYNC: The SYNC is a standard data format byte with a value of hexadecimal 0x55. LIN slaves running on RC oscillator will use the distance between a fixed amount of rising and falling edges to measure the current bit time on the bus (the master's time normal) and to recalculate the internal baud rate.

34. To save the bandwidth of another main bus
Question
What are the reasons when LIN is preferred over CAN?
To save the bandwidth of another main bus
Size of Network is 16 nodes or less
When lower speed is acceptable
Economical
Single Master with multiple slaves
Now time for another question…
Let us look at some of the reasons when LIN is chosen over CAN
Size of network is 16 nodes or less
When lower speed (2-20 kbit/s) is acceptable
When EMI/EMS characteristics are important
When guaranteed latency times for signal transmissions needed
Single Master with multiple Slaves
When bandwidth of another main bus should be freed
Need a protocol without licensing fees

35. LIN versus CAN LIN versus CAN Access Control Single Master
Multiple Master
Max Bus Speed
20 Kbps
1 Mbps
Typical # nodes
2 to 16
4 to 20
Message Routing
6-bit Identifier
11/29-bit Identifier
Data byte/frame
2,4,8 bytes
0-8 bytes
Error detection
8-bit checksum
16-bit CRC
Physical Layer
Single-wire
Twisted-pair
Wrapping up the session in which we have completed a high level overview of CAN & LIN, I would like to summarize the differences….
Let us look at some of the reasons when LIN is chosen over CAN
Size of network is 16 nodes or less
When lower speed (2-20 kbit/s) is acceptable
When EMI/EMS characteristics are important
When guaranteed latency times for signal transmissions needed
Single Master with multiple Slaves
When bandwidth of another main bus should be freed
Need a protocol without licensing fees

36. Renesas CAN/LIN Solutions

37. Renesas MCU CAN Solutions
Single
CAN
Multi
CAN
New
SH7216
RX600
SH7264/62
High End
Up to 1 MB Flash
1-2 CAN
176 pin
SH7286
CAN API
Compatible
R32C/117
With FPU
R32C/118
With FPU
Mid End
Up to 1 MB Flash
1-2 CAN
100/144/176 pin
M16C/29
Low End
Up to 128 KB Flash
1 CAN
48-64 pin
R8C/2x

38. Implementation of CAN in Renesas MCURX
CAN 2.0A / CAN 2.0B
Protocol Engine
Up to 1Mbps data rate TX
16/32
Message Buffers
INTs
CPU
Interface
Message Buffer
Acceptance
Filter
Control
Registers
Clock
Data
Control
Unique Features: Hardware support to simplify SW & Reduce CPU load
Disable Automatic Retransmission on Bus Error
Automatic Priority-based transmission – Mailbox number or ID-based
16 or 32
Common
Control/Status
Registers

39. Renesas M16C LIN Roadmap Common LIN API Support for all M16C Products
R32C
Dedicated LIN
Hardware
M32C
Common LIN API
Support for all
M16C Products
M16C
UART LIN
M16C Platform
For LIN devices, Renesas has written API software to support LIN on any M16C device using the serial channels. For R8C devices and some R32C devices, there is a dedicated serial interface designed specifically for LIN. This ability to support both LIN and CAN makes the M16C Family the perfect gateway devices.
M16C/Tiny
R8C/3x

40. Renesas CAN Development Kit
R32C CAN-D kit now available
CAN Development Kits for R8C & R32C– CAN-D Kit
Two R8C/23 or R32C/118 Renesas Starter Boards
Systec CAN protocol Analyzer included in the kit
E8/E30a Debug Interface
Up to 3 CAN interfaces with 32 mailboxes each
Time-triggered CAN support
All board specific APIs and drivers available in included CD
Extensive third-party middleware support available Sample projects and evaluation software
CAN API
LIN API
Common API for all Renesas CAN MCU Solutions
We have a CAN and LIN Development & Demo Kit available.
One key item of this development kit is the inclusion of the Systec bus analyzer/sniffer.
The API for both CAN and LIN handle the common functions for communicating. There is a lab presented later that goes into details of the CAN API.
Some example projects are UART to CAN bridge, a Flash-over-CAN boot loader, and basic CAN messaging. The order number is RCDK8C.
RCDK8C (R8C), MSRP: $495
YRCDK32C (R32C), MSRP: $550

41. Innovation
CAN has become popular in many secondary CAN industries like recreation devices such as snowmobiles as well as land moving devices and trains. Medical devices, factory automation, white goods, and others have all adopted CAN for the many features and functions it provides. Where safety and reliability are important, CAN has found a need.

42. Questions?

43. Feedback Form Please fill out the feedback form!
If you do not have one, please raise your hand

44. Thank You!

45. Appendix

46. Serial Communications
CAN, LIN, RS-485, RS-232, SPI, I2C, etc. are all serial communications
Advantages
No line-to-line timing skew
Fewer wires lowering cable, connector, and design costs
Saves on board space and power consumption per bit
Disadvantages
Generally point-to-point
Overhead above actual data payload that uses bandwidth
Higher signal rates shorten transmission distances
While some embedded systems never communicate with any other device. Most require communication with external sensors, EEPROMs, debuggers or system loggers, microprocessors, etc. The 2 common ways to interface are parallel and serial. The most common ones, which I expect all of you have seen at least a few, are CAN, LIN, RS-232/422, RS-485, SPI, I2C, etc.
The real advantage over Parallel is the ease of designing. There rarely are line matching requirements to make sure 0’s and 1’s are all getting to the target at the right timing. There are fewer lines and cables to design in, and ultimately the power and board space become optimized for the solution.
Of course the down-sides are that most serial implementations were meant for point-to-point communications and required faster communication to match parallels through-put. For example a serial bus running at 1Mbps would require only 125Kbps for a 8-bit parallel interface.

47. Transmission Topologies
Point-to-Point (Simplex)
One transmitter and one receiver per line
Transmission is possible only in one direction, i.e. unidirectional.
Multidrop (Distributed Simplex)
point-to-point configuration with one transmitter and many receivers
Only unidirectional transfer is possible.
Point-to-point provides communication with feedback. Since only one target is allowed, it is rarely considered a networking topology.
Multi-drop is the classic Master-Slave architecture where one node controls the communications to entire network. All devices see the data, but only one can originate communications.
Simplex: Of or relating to a telecommunications system in which only one message can be sent in either direction at one time.

48. Transmission Topologies
Multipoint (Multiplex)
Many transmitters and many receivers per line.
Transmission is possible in either direction, i.e. bidirectional.
In a multipoint system, any node has the ability to communicate or take control of the network. Management of bus arbitration and bandwidth conservation is required.
Multiplex: designating or of a system for transmitting or receiving simultaneously two or more messages or signals over a common circuit, carrier wave, etc.

49. Number of CAN Nodes Built
~Over 2 Billion Nodes Shipped YTD!!!*
There were 600M CAN Nodes built in While most were used in traditional automotive applications. Many are now finding their way into secondary markets such at Land Moving Equipment, Trucks, Recreational vehicles such as boats and 4-Wheelers. In addition to all these applications, CAN has also been making a strong push into industries focused on reliable communications and distributed system architecture.
Source: CiA (CAN-in-Automation): REA estimates

50. A Typical 2-channel CAN Solution
2-channel CAN MCU
CPU
CAN
CAN
Lighting System
Monitor
Motion Sensor
HVAC
CAN Transceiver
CAN Transceiver
Temp Sensor
Motor Control
CAN Bus 1
Low-Speed
CAN Bus 2
High-Speed

51. RS-485 is used primarily due to Legacy. Remember 8051?
RS-485 vs. CAN
CAN equals RS-485?
Similar costs
Similar distances
Similar electrical immunity
Similar chip availability
Similar connectors
Same 32 nodes (loads) standard
Duplex (4 wire) or Half-Duplex (2 wire) options available
RS-485 is used primarily due to Legacy. Remember 8051?
While RS-485 offers a higher theoretical data rate, in practice, CAN and RS-485 have similar electrical characteristics, distances, availability, connector, and node quantity.

52. RS-485 and the 7-layer model
ISA/OSI Reference Model
7. Application Layer
6. Presentation Layer
Partially implemented by higher-level RS-485 protocols (i.e. MODBUS)
5. Session Layer
4. Transport Layer
3. Network Layer
The published TIA/EIA 485 and RS-422 standards define only the electrical characteristics of the drivers and receivers. They did not standardize such things such as cables and connectors, pinouts, bus arbitration, signaling protocols, or physical wiring topology. Many different implementations have come into use and they are often incompatible with each other. This creates issues with interoperability between vendors.
Managed by CPU in Software
2. Data Link Layer
Standard RS-485 implementation
1. Physical Layer
Only Low Layer specification

53. CAN Protocol Versions Two CAN protocol versions are available:
V2.0A (Standard) - 11 bit Message ID’s ID’s available
V2.0B (Extended) - 29 bit Message ID’s - more than 536 Million ID’s available
CAN has two (2) common standards; v2.0A and v2.0B. The difference between the two involves the Message ID size. For CAN2.0A the message ID is 11 bits, while CAN2.0B supports 29 bits. Having more bits allows for more custom IDs, but also the ability to segment ID sections to specify groupings. Separating the ID field like this is common in industry protocols.
Devices that support CAN2.0B support CAN2.0A as well. There are also two (2) types of CAN2.0A nodes. A true CAN2.0A can not manage CAN2.0B extended message frames. The second CAN2.0A device (often called CAN2.0B passive) sends and receives CAN2.0A messages, but successfully ACKs extended frames, but ignores them.

54. Termination Settings High-Speed CAN (125Kbps+)
For High-Speed CAN, both ends of the pair of signal wires (CAN_H and CAN_L) must be terminated
ISO requires a cable with a nominal impedance of 120 ohms
120 ohm resistors should be used for termination
Only the devices on the ends of the cable need termination resistors
High-Speed CAN:
For High-Speed CAN, both ends of the pair of signal wires (CAN_H and CAN_L) must be terminated. This is because communication flows both ways on the CAN bus. CAN_L is pin 2, and CAN_H is pin 7 on the standard 9-Pin D-Sub connector. The termination resistors on a cable should match the nominal impedance of the cable. ISO requires a cable with a nominal impedance of 120 ohms, and therefore 120 ohm resistors should be used for termination. If multiple devices are placed along the cable, only the devices on the ends of the cable need termination resistors.

55. Termination Settings Low-Speed CAN (Up to 125Kbps)
Each device on the network needs a termination resistor for each data line: R(RTH) for CAN_H and R(RTL) for CAN_L
Requires termination on the transceiver rather than on the cable
The resistance of each resistor is calculated through several formulas
Low-Speed CAN:
For Low-Speed CAN, each device on the network needs a termination resistor for each data line: R(RTH) for CAN_H and R(RTL) for CAN_L. Unlike the High-Speed CAN termination, Low-Speed CAN requires termination to be on the transceiver rather than on the cable. The resistance of each resistor is calculated through several formulas.

56. An example of LIN Implementation