can basics1

Upload: zam-biloiu

Post on 08-Jan-2016

16 views

Category:

Documents


0 download

DESCRIPTION

CAN

TRANSCRIPT

  • 1Course Introduction

    Purpose This training course provides an introduction to Controller Area

    Network (CAN) technology, which is used to build networked, multiprocessor embedded systems.

    Objectives Understand what CAN technology is, why its important and

    where it can be a good design solution. Learn the fundamental operating concepts and capabilities of

    CAN implementations. Find out how CAN fits into the 7-layer OSI model.

    Content 19 pages 3 questions

    Learning Time 30 minutes

    Welcome to the Part-1 introductory course on the basics of controller area network (CAN) technology. This course provides technical details that will help you design reliable, cost-effective distributed systems that link together a network of microcontrollers (MCUs). To get the most out of the material presented, you should be familiar with data communication networks in general and understand the fundamentals of designing and developing embedded control systems.

    In this course, we will present an overview of CAN technology what it is, why its important, and where it is used and can be applied to good advantage. Then, we will highlight various key CAN design aspects, including the physical interface, data flow, timing issues, Physical layer, OSI model, and higher-level protocols used in CAN-based systems. At the end, we include a helpful glossary of key terms.

    The CAN Basics Part-2 course discusses Message Frames, bus errors and network implementation strategies. Other online CAN courses at Renesas Interactive cover the Application Programming Interface (API) for the CAN peripheral built into microcontrollers in the Renesas R8C and M16C product groups. These courses also provide additional design information for implementing CAN-based multiprocessor systems.

  • 2What is CAN?

    Two-wire, bidirectional serial-bus communication method Originally developed in the mid 1980s by Bosch for

    automotive use Main design objective: economical solution for implementing

    high-integrity networking in real-time control applications Now standardized internationally:

    CAN 2.0A: ISO11519 low speed CAN 2.0B: ISO11898 high speed CAN Validation: ISO16845

    Usage exceeded 200,000,000 nodes in 2001, still growing at a 30% rate annually

    Many current and potential non-automotive application opportunities

    Controller Area Network:

    The Controller Area Network (CAN) is a two-wire (twisted-pair), bidirectional serial-bus communication method that allows electronic subsystems to belinked together and interact in a network. It was originally developed in the mid 1980s by Bosch for use in automotive applications, where it replaces point-to-point wiring.

    CAN is noted for its high integrity for real-time applications. It performs well in noisy environments, for example, because CAN hardware incorporates features designed to ensure reliable communication.

    CAN specifications are international standards, and two versions are 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, is also known as Full CAN or extended-frame CAN. It is defined by the ISO11898 standard. ISO16845 covers CAN validation.

    CAN is finding use in a growing number of non-automotive applications. Usage exceeded 200,000,000 nodes in 2001 and has grown at a 30% rate annually since then.

  • 3Non-automotive CAN Applications

    Electronically controlled production and packaging equipment

    Machine tools; machines for molding, weaving, knitting, and sewing; systems for folding and wrapping; etc.

    Industrial freezers, printing machines Ships, locomotives, railway systems Farm and construction machinery Semiconductor manufacturing equipment Building automation: HVAC systems, elevators, etc. Hospital patient-monitoring systems Many others

    More application information available at: www.canopen.us

    Here we list some of the non-automotive applications that now use CAN technology or are excellent candidates for using it. They span a wide range and include production and packaging equipment, industrial freezers, high-speed printing machines, ships, locomotives and other elements of railway systems, machinery used in farming and building construction, semiconductor manufacturing equipment, building automation systems, and patient monitoring systems in hospitals and clinics. Many others exist, as well.

  • 4Key Reasons for Using CAN

    1. Reliability Error-free communication

    2. Economy Low wiring cost

    Low hardware cost

    3. Scalability Easy expandability

    Low node-connection costs

    4. Availability More chips with CAN hardware

    More off-the-shelf tools

    Higher-level protocols

    5. Popularity Knowledge base expanding

    Having briefly discussed what CAN is and where it can be used, lets now look at five main reasons why its an excellent choice for implementing networked communication in embedded systems.

    First, CAN technology has been carefully designed to provide very reliable, error-free network communication. This is a major issue for some types of safety critical equipment and real-time systems.

    Second, since the bus is a simple twisted pair wire, network wiring cost is low. Moreover, the peripheral circuit that implements connectivity in the microcontroller doesnt occupy too much chip area, which helps to keep MCU cost low, usually less than a few dollars more than a device with the same features except CAN.

    Third, the CAN network is readily expandable. Its simple to add nodes to the network: just tap into the two wires at any point on the bus. This doesnt require a re-configuration of existing nodes. Of course, only two pins are needed on the MCU and in the bus connectors. And with just two connection points per node, a CAN network has a reliability advantage over other networking schemes that use more wires and connections.

    Fourth, more and more MCUs with on-chip CAN functions are becoming available. The same holds true for tools for debugging CAN networks. Also, the availability of standardized higher-level protocols helps system designers to build complex control applications efficiently.

    Fifth and last, CAN is a mature technology, having been used for over 15 years. During that time, a substantial body of knowledge has been accumulated about its application, and the database continues to grow.

  • 5Main Features of CAN

    For flexibility in system designPuts multiple transmit or receive message boxes at each node and assigns each an identifier

    To accommodate diverse design requirements

    Allows 0-8 bytes of user data per message

    For adequate real-time response in many embedded control applications

    Provides transfer rates up to 1 Megabit/sec

    For building intelligent and redundant systems

    Has a multiple-master hierarchy

    BenefitsFeatures

    With the five key reasons for using CAN in mind, lets now summarize the main features of CAN that underlie its growing application popularity.

    CAN has a multiple-master hierarchy. This arrangement gives good design flexibilityand allows us to build intelligent and redundant systems.

    CAN operates at transfer rates up to 1 Megabit/second (1Mbps) 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 up to 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.

  • 6Main Features of CAN

    To ensure highly reliable network operation

    Provides error detection, signaling and fault-confinement measures

    For accurate communication, even in noisy environments

    Automatically retransmits messages if corruption occurs

    To simplify node hardware and software

    To permit message prioritization

    To allow the hardware to arbitrate the CAN bus

    Causes receiving nodes to filter messages based on their assigned identifiers (IDs)

    To save bus bandwidth, simplify software, and allow simultaneous transmission of node-to-node and broadcast messages

    Eliminates addresses of transmitting and receiving nodes in data messages

    BenefitsFeatures

    The Message Frames transmitted on a CAN bus do not contain the addresses of either the transmitting node or of any intended receiving node. This message-based approach eliminates data bits that would otherwise use up some of the available bus bandwidth. It also simplifies the communication software, allows both node-to-node and broadcast messages to be transmitted simultaneously, and makes it possible to add new nodes to a system without updating other nodes.

    In lieu of transmit and receive node addresses, messages are labeled by an identifier (ID) assigned to 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 dont. 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 if several nodes attempt to transmit simultaneously.

    Every node on the bus validates every message. Corrupted messages arent validated, of course, and that situation triggers automatic retransmissions.

    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 will eventually go into a Bus Off mode that shuts it down to prevent it from disturbing the traffic flow.

  • 7Design Factors to Consider

    Distance/environment CAN 2.0B: 1Mbps, up to 40m CAN 2.0A: 125kbps, up to 500m Suitable for difficult environments

    industrial, automotive, and more

    Reliability requirements Integrated error detection and confinement Automatic retransmission of corrupted message Probability of undetected bad message

    is 100 is feasible

    Number of masters Every node can initiate communication and negotiate for the bus

    Net data transfer rate Up to 577Kbps net at 1Mbps total data transfer rate

    Message priority Message with lowest numerical value identifier wins if two nodes

    try to transmit at the same time

    Node A Node B Node C

    Node D Node E

    CAN Bus

    Node x

    A good question now is, What parameters and design requirements define a suitable application for CAN? The factors listed here are among those to consider.

    This serial data communication technology provides communication at up to 1Mbps at distances up to 40 meters for high-speed CAN 2.0B. (For low-speed CAN 2.0A, the capability is up to 125kbps at distances up to 500 meters.) Both CAN versions are good choices for systems that must perform dependably in noisy, difficult environments.

    The CAN reliability features previously described reduce the probability of an undetected bad message to a very low level: less than 4.7 x 10-11. This is virtually a 0% failure rate.

    A CAN implementation can have over 100 nodes, or individual MCUs, depending on the Physical layer of the network.

    Because the CAN bus is not controlled by a single master node, all nodes can negotiate for the bus and send messages. This makes possible intelligent, redundant systems. Also, a defective network node doesnt disable the network.

    The 1Mbps maximum transfer rate that the CAN 2.0B bus delivers includes the overhead imposed by the network protocol. At that speed, the net transfer rate for message data is 577kbps.

    The priority of a CAN message is determined by the numerical value of its identifier. The message with the lowest numerical value ID in its header has the highest priority. It wins if another node with lesser priority tries to transmit at the same time.

  • 8Data Flow

    CAN bus traffic: The transmitter at a CAN node broadcasts the data frame to all

    nodes on the bus. Nodes configured to accept the data save it Other nodes do nothing with the data

    CAN 2.0A has an 11-bit message identifier and operates at a maximum frequency of 250kbps.

    CAN 2.0B has 11-bit or 29-bit message identifiers and operates at up to 1Mbps.

    Traffic on the CAN bus consists of five types of message frames. They are covered in detail in the part-2 introductory course. To illustrate how data flows on the bus, lets use a data frame, which carries actual data.

    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 dont do anything with the data.

    CAN 2.0A has an 11-bit message identifier and was originally specified to operate at a maximum frequency of 250kbps. CAN 2.0B has 11-bit or 29-bit message identifiers and can be used at speeds up to 1Mbps.

    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. It then decides whether to process or discard data, a decision that is made via software or by using masks and filters.

    The node on the right has a receiver mailbox set to a different identifier than the transmitted one, so it doesnt accept the message. Nevertheless, both receiver nodes (and all other receiver nodes on the network) subsequently verify and acknowledge the data frame content to prove successful message transmission. (Incidentally, to further enhance reliability, the transmitting node checks the message, too.)

  • 9Match each CAN item to the most appropriate explanation by dragging the letters on the left to the correct locations on the right. Click Done when you are finished.

    CAN

    Multiple-master hierarchyB A

    Done Reset ShowSolution

    A Must be sent by all receiver nodes, or message is re-transmitted

    D

    C Message identifier

    A 2-wire serial bus communication method for multiprocessor systems

    C Used for addressing, prioritization, and bus arbitration

    D Acknowledgment B Enables the design of intelligent and redundant systems

    Question

    Heres a question for you on some of the aspects of CAN technology wehave discussed so far.

    Correct.

    CAN is a 2-wire serial bus that provides highly reliable communication between nodes of multiprocessor embedded control systems. Its multiple-master hierarchy enables intelligent and redundant designs. The message identifier specifies the intended receivers for the message, stipulates the priority of the message, and is used for bus arbitration. Unless all receiver nodes on the network acknowledge a message, that message will automatically be re-transmitted.

  • 10

    Physical Interface

    Dominant low (voltage) line Recessive high line Bus must be terminated Most common Physical-layer

    choice: ISO11898-2

    Having covered the basic concept of the CAN data flow, lets examine how a node physically interfaces to the bus.

    The node produces a dominant value by simultaneously driving the C_HIline high and the C_LO line low. That is, it actively creates a positive differential voltage between these signals.

    A recessive state is created on the CAN bus whenever all nodes on the network leave the C_HI and C_LO lines in a high-impedance state. That causes the termination resistors to passively create a zero differential voltage between these signals.

    The CAN bus must be terminated to provide the recessive state and to eliminate wave reflections at ends of the bus wires. Typical DC bus terminations are in the 60-Ohm range, and the twisted-pair cables have a 120-Ohm characteristic impedance, which is specified in ISO11898-2. Many Physical-layer choices are possible, but ISO11898-2 is probably the most common.

    If the application requires that network nodes be electrically isolated from the CAN bus, this is typically achieved by inserting optical isolators between the bus transceiver and the MCU. Those isolators will introduce an additional delay that will almost always limit the maximum bus speed of a CAN 2.0B network to 500kbps.

  • 11

    Physical-Layer Implementation

    CAN transceiver: the Renesas HA13721 ASSP IC:

    For in-vehicle applications ISO11898-2 compliant High-speed CAN (up to 1Mbps) Active Standby modes Over-temperature detection Over-current detection

    (Vcc-short/GND-short detection) Optimized EMI performance Txd, MODE input pins; 3.3V compatibleCANH = C_HI

    CANL = C_LO

    The CAN Physical-layer implementation is not defined by the Bosch CAN specification. However, it is defined in the ISO11898-2 standard. Here is an example of a Physical-layer transceiver that connects to the bus: the Renesas HA13721 application-specific standard product (ASSP), which is a CAN transceiver IC designed specifically for in-vehicle use.

    The HA13721 transceiver is a standards-compliant high-speed design with Active and Standby operating modes. It features over-temperature and over-current detection to help protect the system, provides good EMI performance, and has 3.3V-compatible Txd and mode input pins.

  • 12

    CAN Bus Data Frame

    CAN TX

    CAN HI

    CAN LO

    TX Low levels aredominant (drive bus)

    TX High levels arerecessive (bustermination controls)

    MCU Output toTransceiver

    TransceiverOutput to Bus

    CAN uses non-return-to-zero (NRZ) serial data

    CAN TX

    C_HI

    C_LO

    TX LO levels are dominant (drive bus)

    TX HI levels are recessive (bus termination controls)

    This captured data frame shows actual bus operation. The top scope trace, in green, is the signal that drives the transceiver. The other two traces are the C_HI, in red, and C_LO, in blue, signal lines relative to each other.

    Again, a dominant value (CAN_TX = logic low) is created by driving C_HI high and C_LO low to create a positive differential voltage between them. A recessive state (CAN_TX = logic high) is created by having all nodes put the C_HI and C_LO lines in the high-impedance state, so the differential voltage is zero because no current flows in the bus termination resistors.

    Receivers at bus nodes detect a dominant state when a differential voltage greater than 900mV exists between C_HI and C_LO. They detect a recessive state when the differential voltage is less than 500mV.

    Please notice three things with regard to this scope photo. First, the MCU transmit pin runs at standard logic levels. Second, there is a 2.5V offset on the transceiver output to the bus. This is compliant with the ISO11898-2 standard, which allows a common-mode range of -7V to +12V. And third, CAN uses a non-return-to-zero (NRZ) serial data transmission method a fact that we will revisit shortly.

  • 13

    Message Bit Time: 4 Segments

    PROP_SEG: Propagation delay compensation value [ = 2 x (signal propagation time + input comparator delay + output driver delay)]

    NOMINAL BIT TIME

    Sample Point

    SYNC_SEG PROP_SEG PHASE_SEG1 PHASE_SEG2

    SYNC_SEG: Nodes are synchronized within this phase

    PHASE_SEG1 and PHASE_SEG2: Establish correct sampling point

    Turning now from voltage to timing issues, it goes without saying that proper timing is essential to establishing and maintaining good communication on any data network. To ensure that each message bit on the CAN bus is sampled at a proper point within the nominal bit time, four phases or values (parameters) are defined: SYNC_SEG, PROP_SEG, PHASE_SEG1, and PHASE_SEG2.

    The SYNC_SEG portion of the bit time is used to synchronize the various nodes on the bus. A signal-transition edge is expected to lie within this phase of the bit-time segment.

    The PROP_SEG part of the bit time is used to compensate for the physical delay times within the network.

    The PHASE_SEG1 and PHASE_SEG2 phase-buffer parts of the message bit time are used to compensate for edge-phase errors. They can be lengthened or shortened by resynchronization to establish the correct sampling point.

    The values for the four bit-time parameters typically are defined in the top-level specification for a network. They are set by taking into account factors such as wiring length, bandwidth requirement, operating environment, etc. Its important to remember that the timing parameter values must be the same for all nodes.

  • 14

    Bit stuffing is applied as needed to keep the bus synchronized:

    Too many consecutive dominant or recessive bits cause the transmitting node to insert a bit of the opposite polarity

    Resulting signal edge is used to establish timing synchronization at all nodes on the bus

    The bit is inserted whenever a sequence of five bits with the same polarity occurs

    Maintaining Synchronization

    Of course, its 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 an 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.

  • 15

    Maintaining Synchronization

    Stuffed bit

    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. The resulting signal edge is used to establish timing synchronization at all nodes on the bus. Specifically, CAN requires that bit stuffing be applied after there is a sequence of five bits with the same polarity.

  • 16

    Question

    Which of these statements correctly describe voltage and timing aspects of CAN bus operation? Select all that apply and then click Done.

    A dominant value (positive differential voltage >900 mV) is created by driving the C_HI line high and the C_LO line low.

    Mandatory CAN bus termination resistors create a recessive value when all bus nodes go to a high-impedance state.

    Because CAN uses NRZ serial data, synchronization between nodes is maintained automatically.

    The PROP_SEG portion of the bit time is used to compensate for physical delays within the network.

    Done

    Heres another question for you. This one covers CAN bus voltages andtiming.

    Correct.

    A dominant value that is, a positive differential voltage greater than 900 mV is created by driving the C_HI line high and the C_LO line low. CAN bus termination resistors must be used; they create a recessive value when all nodes on the bus go to a high-impedance state. CAN uses NRZ serial data, so bit stuffing is needed to maintain synchronization whenever five consecutive bits of the same polarity occur. The PROP_SEG portion of the bit time is used to compensate for physical delays within the network.

  • 17

    CAN in the OSI Model

    CAN FeaturesHigher-Layer Protocols

    ISO 11898

    HostLayers

    Data

    Data

    Data

    Segments

    Packets

    Frames

    Bits

    ApplicationNetwork Process to Application

    PresentationData Representation and

    Encryption

    SessionInterhost Communication

    TransportEnd-to-End Connections and

    Reliability

    NetworkPath Determination and IP

    (Logical Addressing)

    Data LinkMAC and LLC

    (Physical Addressing)

    PhysicalMedia, Signal and Binary

    Transmission

    MediaLayers

    Data LinkLLC

    Acceptance FilteringOverload Notification

    Recovery Management

    MACData Encapsulation/Decapsulation

    Frame Coding (Stuffing, Destuffing)Medium Access Management

    Error DetectionError Signaling

    AcknowledgmentSerialization / Deserialization

    PhysicalBit Encoding/Decoding

    Bit TimingSynchronization

    Driver/Receiver Characteristics

    Mouse over any of the blocks containing fine print to learn more.

    Up until now, we have talked about the Physical layer of the network without explaining what it is. Lets briefly address that deficiency now.

    The Physical layer is part of the 7-layer Open Systems Interconnect (OSI), a standard definition or reference model for how messages should be transmitted in a network.

    The bottom three layers in the OSI communication model Physical, Data Link and Network are the Media layers. The top four Transport, Session, Presentation and Application are the Host layers.

    CAN by itself is only concerned with the lowest layers of the model. That is, ISO11898 defines the Data Link and Physical layers, which are shown here in red. Additionally, the CAN 2.0B specification covers a portion of theTransport layer: the retransmission/retry control function. You can learn more by rolling your mouse pointer over any of the blocks containing fine print.

  • 18

    Higher-layer CAN Protocols

    CAN Interface

    Automotive Industrial Other

    Incompatible OEMGM (LAN3.0)

    Daimler-ChryslerFord

    Toyota, etc. SAE J1939(heavy trucks)

    DeviceNet

    CAN Open

    Proprietary

    NMEA2000 (marine)

    CANaerospace(avionics)

    ISO11783(agricultural vehicles)

    Proprietary

    Circuits or subsystems at CAN nodes generally have software that uses protocols that implement the upper 5 levels of the 7-layer OSI model. In the automotive market, vehicle manufacturers use proprietary CAN protocols. In the industrial market, the most commonly used standard protocols are CAN Open and DeviceNet.

    CAN Open was developed as a standardized embedded network with highly flexible configuration capabilities. Now it is used in many fields, such as medical equipment, off-road vehicles, public transportation, building automation, etc. The CAN Open specifications cover the application layer and communication profile. They also provide a framework for programmable devices; recommendations for cables, connectors and SI units; and prefix representation.

    DeviceNet is an open low-level network protocol that provides connections between simple industrial devices such as sensors and actuators, and higher-level devices such as embedded controllers and computers. The DeviceNet network is flexible and works with products from multiple vendors. It uses the proven Common Industrial Protocol (CIP) to provide control, configure, and data-collection capabilities for industrial devices.

    Other standard CAN protocols include NEMA2000 for marine applications, CANaerospace for aircraft systems, SAE J1939 for heavy trucks and ISO11783 for agricultural vehicles. Incidentally, most of the protocols discussed here dont implement several of the intermediate levels of the OSI model because it isnt necessary to do so.

    The availability of these standardized higher-level protocols helps system designers to build complex control applications efficiently. The combination of standard off-the-shelf CAN hardware and standard but customizable protocol software makes system development time more accountable and accurate.

    Before wrapping up this introductory course on CAN, we provide a two-page glossary of key terms used in the technology. Click Glossary to examine these definitions.

  • 19

    Glossary Advanced CAN: CAN peripheral with varying numbers of buffers configurable for transmit/receive. Receive

    buffers have hardware filtering on at least mask/match identifier content. Basic CAN: CAN peripheral with no hardware filtering. Typically two receive buffers act as a FIFO and

    accept all bus traffic. Usually one transmit buffer. Bit Time: Nominal time of one bit on the CAN bus. Made up of multiple segments that allow each node to

    synchronize to the received bus traffic. All nodes on a bus must be configured to the same (nominal) bit time. CAN: Controller Area Network. CAN 2.0B: Version 2.0 was the last version of CAN defined by Bosch. Part B added extended identifiers and

    the idea of hardware filtering. CIA: CAN in Automation. Group controlling the CANOpen protocol. CANOpen: Multi-area communication protocol using CAN. CRC: Cyclic Redundancy Check. DeviceNet: Industrial communication protocol using CAN. Dominant/Recessive: Dominant bits on Physical layer can override recessive bits. Filters: Hardware in the CAN peripheral that can mask/match bits within the identifier field. Used to

    determine whether or not to route bus data to a mailbox. GM LAN 3.0: GM protocol. Encompasses all GM serial protocols. Identifier: Frame field that indicates the message content. This field also is used to arbitrate the message

    priority on the bus. A lower ID has a higher priority. Standard Format: Frames use an 11-bit identifier. Extended Format: Frames use a 29-bit ID.

    ISO 11898: ISO standardized version of CAN. Mailbox: CAN hardware buffer that can be used to transmit or receive data. Most FullCAN implementations

    have at least 16 mailboxes. ODVA: Open DeviceNet Vendor Association. Group controlling DeviceNet protocol. Time Quanta: Smallest time unit used by CAN. Multiple time quanta make up the segments of a bit time. TT CAN: Time Triggered CAN. More deterministic form of CAN. Assigns time slots when nodes may

    transmit. FlexRay: Next-generation automotive network. Time slots on the bus provide more deterministic behavior. Vector-CanTech: Supplier of the majority of CAN software drivers and tools for ECUs of North American and

    European automobiles.

    Reference information for Glossary button on previous page

  • 20

    Is the following statement true or false? Click Done when you are finished.

    Basically, CAN is concerned with the lowest layers of the OSI model, but CAN 2.0B also implements part of the transport layer.

    True

    False

    Done

    Question

    Consider this question regarding the OSI model.

    Correct.

    Basically, CAN implements only the lowest layers of the OSI model, the Data Link and Physical layers. One exception to this rule is the CAN 2.0B specification, which also implements the retransmission/retry control function of the Transport layer.

  • 21

    CAN description, applications, features/benefits Design factors/parameters Data frame and data flow Timing issues Physical interface, OSI model, and higher-level protocols Glossary

    Course Summary

    This concludes our Part-1 CAN Basics course. You learned what CAN is, why its important, and where its used most often. You also discovered key CAN features, benefits and design factors, then gained insight into data flow, the Physical layer and bus voltages and timing issues. Finally, you learned how CAN fits into the OSI model and read definitions of key terms.

    The Part-2 CAN Basics course covers Message Frames, bus errors and network implementation issues. Other courses in this series on CAN technology discuss the API for Renesas microcontroller CAN peripherals and provide specific design information for designing CAN-based multiprocessor systems.

    Thank you for your interest in CAN technology and for using the tutorial area of the Renesas Interactive website. We now invite you to take additional courses that are available and to use the many other free resources offered here.