DESIGN OF A CUSTOM ASIC INCORPORATING CAN™ AND 1 ...
DESIGN OF A CUSTOM ASIC INCORPORATING CAN™ AND 1 ... DESIGN OF A CUSTOM ASIC INCORPORATING CAN™ AND 1 ...
3.1 History of CAN CHAPTER 3 CONTROLLER AREA NETWORK (CAN) PROTOCOL Robert Bosch introduced the CAN serial bus system at the Society of Automotive Engineers (SAE) congress in Detroit in 1986. It was called the “Automotive Serial Controller Area Network” because CAN systems were developed first for the automotive industry. It quickly became obvious, however, that the protocol would work extremely well in a wide variety of embedded systems applications. In 1990 CAN technology was introduced for weaving machines, and today the textile industry makes heavy use of CAN systems. CAN chips are found in elevator systems in large buildings, ships of all kinds, trains, aircraft, X-Ray machines, and other medical equipment, logging equipment, tractors and combines, coffee makers, and major appliances. Today almost every new car built in Europe has at least one CAN system, and CAN has become the industry standard for communications systems in vehicles. Intel delivered the first CAN chip in 1987, and Phillips Semiconductors responded with a CAN chip of their own shortly after that. Motorola and NEC followed; today some 15 different semiconductor vendors build CAN chips. The International Standards Organization (ISO), based in Geneva, Switzerland, is a network of standards institutes from 147 countries that defines standards for international cooperation in technology. ISO published standard 11898 in November of 1993 to define CAN for general industry use. The CAN in Automation (CiA) 41
user group was founded in March of 1992. Now in its 25 th year, the CAN protocol is still being enhanced. Early in 2000 an ISO task force defined a protocol for scheduled transmission of CAN messages called Time-Triggered CAN (TTCAN). The CAN user’s group estimates that the TTCAN extension will allow Controller Area Network to continue its rapid growth for another ten to fifteen years into a variety of other embedded systems applications. In years to come, CAN systems may be working in just about every type of machine or process. 3.2 Overview of CAN CAN is a network protocol that allows multiple nodes in a system to communicate efficiently with each other. CAN makes it possible for all of the separate nodes in a system to send and receive messages without relying on some form of central control. This makes for much more efficient control of message traffic, and it reduces the need for internal computer wiring by as much as 90 percent in some cases. Also, CAN systems are flexible and easy to maintain. A CAN system sends messages using a serial bus network, with the individual nodes in the network linked together with a twisted pair of wires as shown in Figure 3.1. Every node in the network is equal to every other node in that any node can send a message to any other node, and if any node fails, the other nodes in the system will continue to work properly and communicate with each other uninterrupted. Any node on the network that wants to transmit a message waits until the bus is free. Every message has an identifier, and every message is available to every other node in the network. The nodes select those messages that are relevant and ignore the rest. 42
- Page 15 and 16: 4.3.5 Communication Speed Different
- Page 17 and 18: 5.3.21.1 Synchronization Test (test
- Page 19 and 20: 5.3 Resource Utilization...........
- Page 21 and 22: LIST OF FIGURES 2.1 1 - Wire® Netw
- Page 23 and 24: 4.12 Read-Data Time Slot...........
- Page 25 and 26: 6.4 DS1996 Address Registers ......
- Page 27 and 28: manufacturing process. Structured o
- Page 29 and 30: describes the 1 - Wire® and CAN co
- Page 31 and 32: 2.2 1 - Wire® Overview The basis o
- Page 33 and 34: All 1 - Wire® masters described in
- Page 35 and 36: attachments, microcontroller with b
- Page 37 and 38: Figure 2.3 Bidirectional port pin w
- Page 39 and 40: 2.3.3 Synthesizable 1 - Wire® Bus
- Page 41 and 42: Figure 2.7 UART/RS232 Serial Port I
- Page 43 and 44: hardware. Through control registers
- Page 45 and 46: Table 2.2 1 - Wire® Bus Operations
- Page 47 and 48: 2.3.6 1 - Wire® Search Algorithm F
- Page 49 and 50: detected. This ‘read two bits’
- Page 51 and 52: in Figure 2.15. Alternatively, the
- Page 53 and 54: of the bit, then write the desired
- Page 55 and 56: 2.4.2 Device Functions and Typical
- Page 57 and 58: and development (R&D) investments b
- Page 59 and 60: 2.5 Network Types and Precedents As
- Page 61 and 62: 2.5.2 1 - Wire® Network Topologies
- Page 63 and 64: 2.5.3 1 - Wire® Network Limitation
- Page 65: with a single selected slave. If an
- Page 69 and 70: protocol on multiple media for maxi
- Page 71 and 72: ecessive bit and the monitored stat
- Page 73 and 74: specification: Start-Of-Frame, Arbi
- Page 75 and 76: Cyclic Redundancy Check (CRC) Field
- Page 77 and 78: Arbitration FieldThe Arbitration Fi
- Page 79 and 80: SOF SOF Bit 28 Bit 27 Arbitration f
- Page 81 and 82: Afterwards it starts transmitting s
- Page 83 and 84: Figure 3.9 Structure of the Interfr
- Page 85 and 86: error occurs, an Error Frame is gen
- Page 87 and 88: Table 3.4 Error Flag Output Timing
- Page 89 and 90: 3.5.2 Error-Passive A node becomes
- Page 91 and 92: where tNBT is the Nominal Bit Time
- Page 93 and 94: Figure 3.12 Propagation Delay Betwe
- Page 95 and 96: 3.6.4 Synchronization t t t t (3.
- Page 97 and 98: opposite value is inserted into the
- Page 99 and 100: many systems, the bus length will b
- Page 101 and 102: CHAPTER 4 THE CHALLENGES OF INTERFA
- Page 103 and 104: In June 2004, Maxim Integrated Prod
- Page 105 and 106: Wearable sensor technology is a new
- Page 107 and 108: In traditional bus architectures, o
- Page 109 and 110: Figure 4.3 Centralized arbiter with
- Page 111 and 112: For the initial prototype design pr
- Page 113 and 114: the ID of 31 transmits a ‘0’ (d
- Page 115 and 116: Recently, a technique has been prop
user group was founded in March of 1992. Now in its 25 th year, the CAN protocol is still<br />
being enhanced. Early in 2000 an ISO task force defined a protocol for scheduled transmission<br />
of CAN messages called Time-Triggered CAN (TTCAN). The CAN user’s group<br />
estimates that the TTCAN extension will allow Controller Area Network to continue its rapid<br />
growth for another ten to fifteen years into a variety of other embedded systems applications. In<br />
years to come, CAN systems may be working in just about every type of machine or process.<br />
3.2 Overview of CAN<br />
CAN is a network protocol that allows multiple nodes in a system to communicate<br />
efficiently with each other. CAN makes it possible for all of the separate nodes in a system to<br />
send and receive messages without relying on some form of central control. This makes for<br />
much more efficient control of message traffic, and it reduces the need for internal computer<br />
wiring by as much as 90 percent in some cases. Also, CAN systems are flexible and easy to<br />
maintain.<br />
A CAN system sends messages using a serial bus network, with the individual nodes in<br />
the network linked together with a twisted pair of wires as shown in Figure 3.1. Every node in<br />
the network is equal to every other node in that any node can send a message to any other node,<br />
and if any node fails, the other nodes in the system will continue to work properly and<br />
communicate with each other uninterrupted. Any node on the network that wants to transmit a<br />
message waits until the bus is free. Every message has an identifier, and every message is<br />
available to every other node in the network. The nodes select those messages that are relevant<br />
and ignore the rest.<br />
42
Change language