by JOHN SCHILL
`
`An Overview of the CAN Protocol
`
`The CAN protocol offers a comprehensive standard for network
`communications. It supports numerous automotive and industrial
`control applications. This article lays out the major elements of the
`CAN protocol and describes two application layer definitions.
`
`The
`
`Area
`Controller
`Network (CAN) protocol,
`developed
`by Robert
`Bosch GmbH, offers a
`comprehensive
`solution
`for managing communication between
`controllers, sensors, actuators, and
`human-machine interfaces. The CAN
`
`protocol specifies versatile message
`formats that can be mapped to specific
`control
`information
`categories.
`Industrial applications such as plant
`floor automation successfully imple-
`ment CAN-based networks using open
`standards developed by Allen-Bradley
`(DeviceNet) and Honeywell (Smart
`
`Distributed System—SDS). CAN
`chips help link devices within the sys-
`tem, enabling them to work harder,
`smarter, and faster than before. In this
`article, I present an overview of the
`CAN protocol and descriptions of
`DeviceNet and SDS.
`The CAN protocol is an open stan-
`dard, and over eight companies are
`currently licensed to design and manu-
`facture CAN chips. The broad assort-
`ment of CAN chips and wide-spread
`usage in automotive and industrial
`applications are good indicators of
`CAN’s long term viability.
`
`BENEFITS FROM CAN
`
`The CAN protocol provides five
`
`primary benefits. First, as a
`standard communications pro-
`tocol, CAN simplifies and economizes
`the task of interfacing subsystems from
`various vendors onto a common net-
`work. Second, the CAN protocol sup-
`ports over five million message identi-
`fiers and provides the flexibility to
`implement sophisticated messaging
`schemes. Error detection and response
`are handled in hardware by the CAN
`chips themselves, which minimizes
`error recovery software. Third, the
`communications burden is shifted
`from the host CPU to an intelligent
`peripheral; the host CPU then has more
`time to run its system tasks. Fourth, as
`a multiplexed network, CAN reduces
`wire harness size by eliminating much
`of the point-to-point wiring.
`Last, as a standard protocol, CAN
`
`Nance Paternoster
`
`46 EMBEDDED SYSTEMS PROGRAMMING SEPTEMBER 1997
`
`Page 1 of 8
`
`Mercedes Exhibit 1018
`
`

`
`CAN has a broad
`market appeal,
`which motivates
`semiconductor
`makers to develop
`competitively-
`priced CAN chips.
`
`has a broad market appeal, which moti-
`vates semiconductor makers to devel-
`op competitively-priced CAN chips.
`For example, future high-volume
`applications may expect CAN node
`costs in the two- to four-dollar range.
`This includes the CAN protocol chip
`and its bus driver.
`The CAN protocol is implemented
`with a standalone CAN controller chip
`interfaced to a host CPU or with a
`CAN peripheral integrated with the
`host CPU, as shown in Figure 2. A
`CAN bus driver or transceiver supplies
`the current to drive the bus and con-
`verts CAN bus signals to CMOS levels
`for the CAN peripheral.
`
`CAN PROTOCOL OVERVIEW
`
`The CAN protocol is licensed to
`
`silicon manufacturers by Robert
`Bosch GmbH to design and
`manufacture CAN chips. CAN silicon
`implementation must satisfy the CAN
`protocol so that any CAN chip will
`communicate with another CAN chip,
`regardless of manufacturer or vintage.
`The CAN protocol defines the format
`of messages transmitted on the bus, the
`timings of transmitted bits, arbitration
`priority, and error detection. CAN net-
`works may operate at up to 1Mbit/s,
`allowing a device to request and then
`receive information back from another
`device in less than 0.2ms.
`Figure 1 shows an industrial net-
`
`work application. In material handling
`applications, a photoelectric sensor can
`recognize an overload condition on a
`conveyer. The sensor will then signal
`the host controller to re-route packages
`along another conveyer, which is con-
`trolled by a set of actuators.
`The message format consists of a
`start bit, an 11- or 29-bit message iden-
`tifier, a remote message bit, data length
`code, data bytes, and error detection
`code.
`The CAN message formats are
`shown in Figure 3. With an 11-bit mes-
`sage identifier, called a standard for-
`mat 2032, distinct messages may be
`defined in the system. Likewise, a 29-
`bit message identifier, or extended for-
`mat, permits over 500 million distance
`message identifiers, providing signifi-
`cant flexibility to partition messages
`by system function. A CAN node typi-
`cally supports multiple CAN message
`identifiers because it transmits and
`receives a number of system messages
`containing various parameter data. One
`may associate a message identifier
`with a system parameter and not neces-
`sarily with a particular system node or
`module address, as with conveyer
`speed and motor temperature.
`The timings of transmitted bits are
`specified with respect to a bit sampling
`procedure. This procedure ensures that
`all nodes transmit and receive mes-
`sages by synchronizing themselves
`with the CAN bus.
`The arbitration priority is deter-
`mined by the priority of the transmitted
`messages in which the lowest-num-
`bered message identifier has the high-
`est priority. The CAN protocol
`requires each node to continuously
`monitor the CAN bus transmissions at
`all times. If two CAN nodes begin
`transmitting at the same time, one node
`will detect that the message identifier
`transmitted on the CAN bus doesn’t
`match the message identifier it’s
`attempting to transmit. When this
`occurs, the node with the unmatched
`message identifier discontinues its
`message transfer until the bus is once
`
`SEPTEMBER 1997 EMBEDDED SYSTEMS PROGRAMMING 47
`
`Page 2 of 8
`
`

`
`CAN Protocol
`
`again free. This process is called mes-
`sage arbitration.
`The CAN protocol also defines an
`error detection algorithm that must be
`executed against all transmitted mes-
`sages by each CAN bus node. If an
`error occurs, automatic retransmission
`takes place. Additionally, if a node
`finds repetitive errors, it will take itself
`off the bus and notify its host CPU.
`
`COMMUNICATION MESSAGE OBJECTS
`
`The CAN protocol supports two
`
`types of communications mes-
`sage objects:
`and
`transmit
`receive. Communication message
`objects correspond to specific “mail-
`boxes” or “communication slots”
`available within the CAN implementa-
`tion. Currently available CAN chips
`implement no less than two message
`
`objects (one transmit, one receive) and
`up to 15 message objects, which may
`be independently configured as trans-
`mit or receive.
`A message object consists of several
`dedicated bytes including control, the
`message identifier, message configura-
`tion, and data. The control bytes man-
`age message operations and contain
`bits such as message valid, transmit
`request, message lost status, and inter-
`rupt pending status.
`Message identifiers usually corre-
`spond to a particular control message.
`In an industrial application, there may
`be different message identifiers for
`parameters such as motor speed,
`device temperature, and device load.
`The data associated with each message
`object may be one to eight bytes. The
`message configuration byte specifies
`the number of data bytes, transmit or
`receive function, and possibly whether
`the message identifier is standard or
`extended (11 or 29 bits).
`Network nodes use receive message
`objects to receive information from
`other nodes. The CAN protocol per-
`mits a receive message object to
`request data by sending a remote mes-
`sage. A motor may require position
`information from a gearbox. Remote
`messages allow the motor to request
`information from the gearbox without
`waiting for the gearbox’s CPU to initi-
`ate data transmission. Enabled transmit
`message objects will respond to remote
`messages automatically by sending
`data (without host CPU intervention).
`
`CAN PROTOCOL CHIP FEATURES
`
`Silicon implementations of the
`
`typically
`CAN protocol are
`viewed as smart RAM chips.
`The RAM locations are reserved for
`communication objects used to man-
`age and for control registers. The host
`CPU reads and writes to the CAN chip,
`where read operations usually interro-
`gate receive messages and write opera-
`tions load data to be transmitted. Read
`and write operations also manage con-
`trol registers such as the interrupt
`pointer, CAN bus transmission rate
`
`48 EMBEDDED SYSTEMS PROGRAMMING SEPTEMBER 1997
`
`Page 3 of 8
`
`

`
`CAN Protocol
`
`configuration, and error status. The
`CAN chip continues to monitor and
`transmit messages on the CAN bus,
`even when the host CPU is addressing
`the CAN chip.
`Interrupts may be enabled when
`messages are received or transmitted,
`or when errors are detected. Status bits
`
`indicate message and error status.
`Some CAN implementations sup-
`port acceptance mask filtering. This
`feature allows certain communication
`objects to receive more than one mes-
`sage by declaring certain message
`identifier bits to be “don’t care,” mean-
`ing either a 1 or a 0 will suffice for the
`
`FIGURE 1
`Industrial network application.
`
`PLC
`
`Solenoid(cid:13)
`Valve
`
`Pressure(cid:13)
`Sensor
`
`Photoelectric(cid:13)
`Sensor
`
`Network using CAN
`
`Intelligent Terminal(cid:13)
`Strip (ITS)
`
`corresponding bit. For each don’t care
`bit, the number of message identifiers
`accepted by a receive message object
`increases by a factor of two. With this
`feature, a CAN chip may receive more
`than one message per communication
`message object.
`
`COMMUNICATIONS INTEGRITY
`
`To increase data integrity, the
`
`CAN protocol specifies that
`each node should continually
`check bus transmissions for errors,
`using a cyclical redundancy test. Each
`CAN chip is capable of calculating a
`polynomial which is compared with 15
`cyclic redundancy check (CRC) bits to
`detect burst errors and up to five ran-
`domly distributed errors within a mes-
`sage. When an error is detected, a
`stream of bits called an error frame is
`transmitted to initiate a synchroniza-
`tion of all CAN bus nodes.
`
`STANDARD AND EXTENDED MESSAGE
`FORMATS
`
`Both standard and extended
`
`CAN message formats support
`four frame types:
`
`FIGURE 2
`CAN bus implementation (integrated/stand-alone).
`
`Stand-Alone CAN Chip Implementation
`
`Host CPU
`
`CAN
`
`CAN(cid:13)
`Bus(cid:13)
`Driver
`
`CAN(cid:13)
`BUS
`
`On-chip (integrated) CAN Implementation
`
`CPU(cid:13)
`w/Integrated(cid:13)
`CAN
`
`CAN(cid:13)
`Bus(cid:13)
`Driver
`
`50 EMBEDDED SYSTEMS PROGRAMMING SEPTEMBER 1997
`
`n Data: carries data
`n Remote: sent when a node requests
`data from another node
`n Error: sent when a node detects a
`message error
`n Overload: sent when a node
`requires extra delay
`
`The data and remote frame types are
`initiated by the application, meaning
`that CAN nodes transmit these frame
`types to exchange necessary informa-
`tion. The error and overload frames are
`initiated by the CAN hardware, inde-
`pendent of the application, to recover
`from an error condition or to delay
`message transmissions. Most CAN
`chips are capable of handling the max-
`imum CAN bus speeds of 1Mbit/s, and
`therefore do not transmit overload
`frames.
`The following describes the stan-
`dard and extended message formats for
`the data frames shown in Figure 3.
`
`Page 4 of 8
`
`

`
`n SOF: start of frame (dominant bit)
`marks
`the
`beginning
`of
`a
`data/remote frame
`n Arbitration: one or two fields that
`contain the message identifier bits.
`The standard format consists of one
`11-bit field and the extended format
`has two fields, 11- and 18-bits wide
`n RTR: remote transmission request
`bit is dominant for data frames and
`is recessive for remote frames. This
`bit is in the arbitration field
`n SRR: substitute remote request bit
`is used in extended messages and is
`recessive. This bit is a substitute for
`the RTR bit in the standard format
`and is in the arbitration field of the
`extended format
`n IDE: identifier extension bit is dom-
`inant for standard format and reces-
`sive for extended format. This bit is
`in the arbitration field of the extend-
`ed format and in the control field of
`the standard format
`n Control Field: reserved bits r0 and
`r1 are sent as dominant bits. The 4-
`bit data length code (DLC) indicates
`the number of bytes in the data field
`n Data Field: the data bytes are locat-
`ed in the data frame (zero to eight
`bytes). A remote frame contains
`zero data bytes
`n CRC Field: this field is composed
`of a 15-bit cyclic redundancy code
`error code and a recessive CRC
`delimiter bit
`n ACK Field: acknowledge is a dom-
`inant bit sent by nodes receiving the
`data/remote frame and is followed
`by a recessive ACK delimiter bit
`n End of Frame: seven recessive bits
`end the frame
`n INT: intermission is the three reces-
`sive bits that separate data and
`remote frames
`
`In addition to these pre-defined bits,
`“stuff” bits may be added to the mes-
`sage. Stuff bits assist synchronization
`by adding transitions to the message. A
`stuff bit is inserted in the bit stream
`after five consecutive equal-value bits
`are transmitted; the stuff bit is the
`opposite polarity of the five consecu-
`
`tive bits. Because CAN chips synchro-
`nize on high to low transitions on the
`CAN bus, stuff bits ensure a sufficient
`number of synchronization events
`occur regardless of the message con-
`tents. All message fields are stuffed
`except the CRC delimiter, the ACK
`field, and the end of frame.
`
`FIGURE 3
`CAN message format.
`
`INDUSTRIAL APPLICATIONS:
`DEVICENET AND SDS
`
`Allen-Bradley’s DeviceNet and
`
`Honeywell’s SDS are open
`communication standards par-
`ticularly suited for industrial and facto-
`ry floor applications. This technology
`provides solutions to users and device
`
`CAN Standard Message Format (11-bit Identifier)
`
`Arbitration(cid:13)
`Field
`
`Control(cid:13)
`Field
`
`Data(cid:13)
`Field
`
`CRC(cid:13)
`Field
`
`ACK(cid:13)
`Field
`
`End of(cid:13)
`Frame
`
`INT
`
`Bus(cid:13)
`Idle
`
`S(cid:13)
`O(cid:13)
`F
`
`1
`
`#(cid:13)
`bits
`
`11-bit(cid:13)
`Identifier
`
`11
`
`r(cid:3)
`0
`
`R(cid:13)
`T(cid:13)
`R
`
`I(cid:13)
`D(cid:13)
`E
`
`1 1 1
`
`DLC
`
`4
`
`0 - 8(cid:13)
`Data Bytes
`
`0 - 64
`
`15 -bit(cid:13)
`CRC
`
`15
`
`D(cid:13)
`E(cid:13)
`L
`
`A(cid:13)
`C(cid:13)
`K
`
`D(cid:13)
`E(cid:13)
`L
`
`1 1 1
`
`7
`
`3
`
`CAN Extended Message Format (29-bit Identifier)
`
`Arbitration(cid:13)
`Field
`
`Control(cid:13)
`Field
`
`Data(cid:13)
`Field
`
`CRC(cid:13)
`Field
`
`ACK(cid:13)
`Field
`
`End(cid:13)
`INT
`of(cid:13)
`Frame
`
`Bus(cid:13)
`Idle
`
`S(cid:13)
`O(cid:13)
`F
`1
`
`11-bit(cid:13)
`Identifier
`
`11
`
`S (cid:13)
`I(cid:13)
`
`R(cid:13)
`D(cid:13)
`R
`E
`1 1
`
`18-bit(cid:13)
`Identifier
`
`18
`
`#(cid:13)
`bits
`
`r(cid:3)
`1
`
`r(cid:3)
`0
`
`R(cid:13)
`T(cid:13)
`R
`1 1 1
`
`DLC
`
`0 - 8(cid:13)
`Data Bytes
`
`4
`
`0 - 64
`
`15 -bit(cid:13)
`CRC
`
`15
`
`D(cid:13)
`E(cid:13)
`L
`
`A(cid:13)
`D(cid:13)
`C(cid:13)
`E(cid:13)
`K
`L
`1 1
`
`1
`
`7
`
`3
`
`FIGURE 4
`Seven-layer OSI communications model.
`
`APPLICATION
`PRESENTATION
`SESSION
`TRANSPORT
`NETWORK
`
`DATALINK
`PHYSICAL
`
`n The application layer is the message
`field usage and device hierarchy
`defined by DeviceNet and SDS.
`n The CAN protocol specifies the
`datalink layer by defining message
`format and transmission rules.
`n The physical layer defines the elec-
`trical medium to support the net-
`work, such as tranceivers and bus
`wire.
`
`DeviceNet and SDS application layers
`are consistent with CAN Specification
`1.2; however, CAN Specification 2.0
`may also be used, resulting in a slightly
`reduced message.
`
`SEPTEMBER 1997 EMBEDDED SYSTEMS PROGRAMMING 57
`
`Page 5 of 8
`
`

`
`CAN Protocol
`
`manufacturers who interconnect sen-
`sors, actuators, PLCs, and controllers
`for real-time control applications, as in
`Figure 1. Users gain the flexibility to
`interconnect devices from multiple
`suppliers, knowing the network is
`proven and well-supported. Device
`manufacturers benefit from reduced
`development cost and quicker time to
`market. CAN is the communications
`
`technology chosen to support both
`DeviceNet and SDS because of its
`robust arbitration and advanced error
`management capabilities.
`
`SYSTEM-WIDE NETWORK
`
`Referencing the OSI seven-layer
`
`communications model, as
`depicted
`in
`Figure
`4,
`DeviceNet and SDS networks utilize
`
`the application, datalink, and physical
`layers. The implementation of these
`three layers offers optimized dialogue
`between network devices with minimal
`overhead. Although the presentation,
`session, transport, and network layers
`support unique services to the network,
`the additional complexity and required
`device intelligence is not justifiable for
`the targeted applications.
`
`APPLICATION LAYER: DEVICENET
`
`DeviceNet networks are capable
`
`four-level hierarchy
`of a
`known as Message Groups 1 to
`4. This hierarchy allows the proper
`device priority on the network so that
`computers, PLCs, and actuators and
`sensors may coexist on the network.
`Peer-to-peer and master/slave configu-
`rations are supported. Figure 5 shows
`the DeviceNet CAN identifier field
`usage to create the four Message
`Groups.
`Group 1 messages have the highest
`priority on the network and are avail-
`able for peer-to-peer communication.
`The Source Media Access Control
`(MAC) ID field identifies up to 64
`source nodes. A particular transmitting
`node may implement up to 16 different
`messages using the 4-bit Group 1
`Message ID field. The intent of the
`Group 1 Message scheme is to provide
`each transmitting node access to high-
`priority messages.
`Message Group 2 has lower network
`priority than Message Group 1 and is
`used for devices that are more control
`oriented. The MAC ID used for Group
`2 messages may indicate either source
`or destination node IDs, as specified by
`the end point. Within the range of
`Group 2 messages, the value of the
`MAC ID determines bus priority;
`therefore, particular nodes (transmit-
`ting or receiving) are assigned priority.
`The outcome of the Group 2 message
`schemes is to rank device priority by
`MAC ID.
`Message Group 2 also serves two
`other important network features.
`Some Group 2 messages are reserved
`for predefined master/slave connection
`
`58 EMBEDDED SYSTEMS PROGRAMMING SEPTEMBER 1997
`
`Page 6 of 8
`
`

`
`CAN Protocol
`
`FIGURE 5
`CAN identifiers field usage.
`
`IDENTIFIER BITS
`10
`9
`8
`7
`Group 1(cid:13)
`Message ID
`0
`MAC ID
`
`1
`
`0
`
`1
`
`1
`
`1
`10
`
`1
`
`1
`
`1
`9
`
`Group 3(cid:13)
`Message ID
`1
`1
`1
`
`1
`8
`
`1
`7
`
`1
`6
`
`6
`
`5
`4
`3
`2
`Source MAC ID
`
`1
`
`0
`
`Group 2(cid:13)
`Message ID
`Source MAC ID
`
`Group 4 Message ID(cid:13)
`(0-2FH)
`1
`1
`5
`4
`
`X X X X
`3
`2
`1
`0
`
`HEX(cid:13)
`RANGE
`000-3FF
`
`IDENTITY(cid:13)
`USAGE
`Message Group 1
`
`400-5FF
`
`Message Group 2
`
`600-7BF
`
`Message Group 3
`
`7C0-7EF
`
`Message Group 4
`
`7F0-7FF
`
`Invalid CAN Identifiers
`
`FIGURE 6
`SDS application protocol data unit (APDU), long form, in a CAN message.
`
`7
`
`6
`
`5
`
`4
`
`3
`
`2
`
`1
`
`0
`
`BITS
`
`B(cid:13)
`Y(cid:13)
`T(cid:13)
`E(cid:13)
`S
`
`Device Address {0 ... 125}
`DIR{0,1}
`Data Length Code
`PDU Type {0 ... 7}
`0
`Request/Response/Error Fragment Reserved Object/Group ID {0 ... 15}
`PDU Modifier (Attribute, Action, Event, {0 ... 255})
`Variable Data (Byte 0)
`Variable Data (Byte 1)
`Variable Data (Byte 2)
`Variable Data (Byte 3)
`Variable Data (Byte 4)
`Variable Data (Byte 5)
`
`FIGURE 7
`SDS APDU, short form, in a CAN message.
`
`7
`
`6
`
`5
`
`4
`
`3
`
`2
`
`1
`
`0
`
`BITS
`
`CAN(cid:13)
`Header
`
`DIR{0,1} Device Address {0 ... 125}
`PDU Type {0 ... 7}
`RTR
`
`Data Length Code = 0
`
`60 EMBEDDED SYSTEMS PROGRAMMING SEPTEMBER 1997
`
`CAN supports
`both DeviceNet
`and SDS with its
`robust arbitration
`and advanced
`error management
`capabilities.
`
`management and other messages are
`reserved to resolve duplicate MAC ID
`assignments, which are prohibited by
`the CAN protocol.
`The Group 3 message scheme is
`similar to that of Group 1, except each
`node is allowed eight messages of
`lower priority.
`Group 4 messages have lower prior-
`ity than Groups 1 to 3 and are current-
`ly reserved for future use.
`DeviceNet specifies the application
`layer information within the 11-bit
`CAN message identifier. This place-
`ment leaves all eight data bytes of the
`CAN message available for informa-
`tion communication.
`
`APPLICATION LAYER: SDS
`
`The SDS application layer sup-
`
`ports four generic classes of ser-
`vices, called read, write, action,
`and event. Read and write are used for
`configuration and interrogation of
`attributes of a device. Attributes of a
`node are parameters such as device
`name, date code, device address, and
`vendor name. Action is a command to
`a device to perform a specified func-
`tion. Event
`is a notification by the
`device of an event that was sensed or
`generated by the device.
`SDS may be operated in either peer-
`to-peer or master/slave environments.
`In peer-to-peer mode, devices such as
`sensors may transmit data of an event
`
`Page 7 of 8
`
`

`
`CAN Protocol
`
`as a broadcast message without an
`explicit acknowledgment from other
`devices that the message was received.
`In master/slave mode, the initiating
`master device receives acknowledg-
`ment by the slave device responding to
`the requested action.
`The device address supports up to
`126 devices to be present on the net-
`work. The DIR field indicates whether
`the device address is a source or desti-
`nation address. The PDU type field
`indicates the service class: read, write,
`action, or event.
`The APDU long form, shown in
`Figure 6, utilizes two CAN message
`data bytes to create additional fields.
`The first CAN data byte contains a
`field to specify particular message ser-
`vices such as request, response, or
`error response. A transport layer type
`feature is supported by the fragment
`and object/group ID fields, whereby a
`
`fragment = 1 indicates that the mes-
`sage is one of 16 possible objects of a
`larger total message. The second CAN
`data byte stores the PDU modifier that
`contains attribute, action, and event
`information. The remaining six CAN
`data bytes are available to transfer
`data.
`SDS also specifies a short message
`type, shown in Figure 7, which is used
`to quickly communicate simple digital
`input or output such as device on/off
`status.
`
`PHYSICAL LAYER
`
`DeviceNet and SDS have similar
`
`physical layer requirements.
`DeviceNet and SDS imple-
`ment a five-wire cable with a shielded
`twisted pair to carry the two CAN bus
`signals, another shielded twisted pair
`for power, and a drain wire attached to
`the shielding. Industry standard tee
`
`connectors allow quick installation and
`disconnect capability. Up to 64 nodes
`may be attached to a single bus.
`Transmission speed is dependent on
`overall length (for example, 500Kbps
`@ 100m, 250Kbps @ 200m, 125Kbps
`@ 300m). Future SDS physical layer
`specifications are planned to support
`128 nodes.
`Both DeviceNet and SDS adopted
`practices consistent with ISO/DIS
`11898, a working discussion commit-
`tee establishing physical layer stan-
`dards for CAN communications.
`
`CAN OUTLOOK
`
`The CAN protocol provides users
`
`with a clear and comprehensive
`standard for network communi-
`cations. CAN is supporting a growing
`number of applications in automotive
`and industrial control applications.
`With the number of CAN products
`increasing, CAN will continue to be a
`versatile and cost-effective networking
`solution.
`
`John Schill is a technical marketing
`engineer for automotive operation at
`Intel, and is responsible for technical
`support of Intel’s CAN product family.
`He has an extensive background in test
`development and fault grading of 16-
`bit microcontrollers. Schill is a gradu-
`ate of DeVry Institute of Technology.
`
`This article was taken from a manu-
`script originally written by Craig
`Szydlowski.
`
`REFERENCES
`82527 Serial Communications
`Controller data sheet, order #272250,
`Intel Literature, (800) 548-4725.
`CAN Specification version 2.0,
`Robert Bosch GmbH, Postfach 50, D-
`7000 Stuttgart, 1991.
`Crovella, Robert M. SDS: A CAN
`Protocol for Plant Floor Control.
`Presented at CAN In Automation
`Conference, Mainz,
`Germany,
`September 1994.
`DeviceNet Specification, Volume 1,
`Release 1.1, Allen-Bradley.
`
`62 EMBEDDED SYSTEMS PROGRAMMING SEPTEMBER 1997
`
`Page 8 of 8