DESIGN OF A CUSTOM ASIC INCORPORATING CAN™ AND 1 ...

DESIGN OF A CUSTOM ASIC INCORPORATING CAN AND 1-WIRE®
COMMUNICATION PROTOCOLS
by
MICHAEL ALAN McNEES
KENNETH G. RICKS, COMMITTEE CHAIR
DAVID JEFF JACKSON
JOSEPH NEGGERS
WILLIAM A. STAPLETON
LARRY T. WURTZ
A DISSERTATION
Submitted in partial fulfillment of the requirements for the
degree of Doctor of Philosophy in the Department
of Electrical and Computer Engineering
in the Graduate School of
The University of Alabama
TUSCALOOSA, ALABAMA
2012

Copyright Michael Alan McNees 2012
ALL RIGHTS RESERVED

ABSTRACT
The vast majority of today’s digital designs utilize custom ASICs (Application-Specific
Integrated Circuits) or gate arrays. In general, ASICs offer the lowest possible device power
consumption for implementing a given function. Each year the number of custom ASICs
designed increases, while the number of parts required for each design decreases. This is due in
part to the increasing use of FPGAs (Field Programmable Gate Arrays) and their ability to
provide a lower cost ASIC-based alternative for limited production designs.
This paper presents a VLSI (Very Large Scale Integration) design and simulation of a
custom ASIC incorporating two serial bus communication protocols, CAN (Controller Area
Network) and 1 – Wire®, and is targeted towards wearable medical technology and devices as
well as advanced vehicular technologies. In designing a custom communications interface
module, a number of technical and potentially challenging problems had to be addressed and
overcome. These include but are not limited to: combining a multimaster and a single-master
protocol, event-triggered and time-triggered control paradigms, differential communication
speeds, and messages by addressing and messages by IDs. By combining the low-cost and ease
of CAN-enabling almost any device with the variety of 1 – Wire® devices currently in-
production, the combinations of sensor networks is only limited by the creativity of the system
designer. Given the limited FPGA resources utilized by the design presented in this manuscript,
a low-cost ASIC could handle the data demands and provide the communications interface of
most any application for either market.
ii

DEDICATION
This work is dedicated to my wife, DeVonna, son, Joseph Darrell, and parents, Barbara
and Joe. Without their continuing love and support, returning to graduate school would have
only been a dream, and none of this work would have been possible. I would also like to thank
the rest of my friends and family, whose names I have not mentioned here, for their support, as
each has played an important role in my continuing success not only as a graduate student but as
a professional in my chosen career.
iii

LIST OF ABBREVIATIONS AND SYMBOLS
AA DS1996 Authorization Accepted Flag
ACK Acknowledge
ACR Acceptance Code Register
ADC Analog-to-Digital Converter
AMP Arbitration on Message Priority
AMR Acceptance Mask Register
AND Automatic Node Discovery
ASIC Application-Specific Integrated Circuits
B m
Longest delay time of a message from a lower priority message
BRP Baud Rate Prescaler
BSP Bit Stream Processor
C m
Longest time to send a CAN message
CAN Controller Area Network
CiA CAN in Automation
CIL Controller Interface Logic
CMOS Complementary Metal-Oxide Semiconductor
CRC Cyclic Redundancy Check
CSMA/CD Carrier Sense Multiple Access/Collision Detection
iv

D m
Deadline for a given CAN message
DLC Data Length Code
EEPROM Electrically Erasable Programmable Read-Only Memory
EML Error Management Logic
EOF End Of Frame
EPROM Erasable Programmable Read Only Memory
ERBF Enable Receive Buffer Full Interrupt
ESD Electrostatic Discharge Protection
f NBT
Nominal Bit Time Frequency
FIFO First-In-First-Out
FOW Force One Wire
FPGA Field Programmable Gate Array
GPIO General Purpose Input/Output
HLP Higher Layer Protocol
I/O Input/Output
I 2 C Inter-Integrated Circuit
IC Integrated Circuit
ID Identification
IDE Identifier Extension
IEC International Electrotechnical Organization
IP Intellectual Property
IR Infrared
v

ISO International Organization for Standardization
ISR Interrupt Service Routine
J m
Queuing jitter of CAN message
JTAG Joint Test Action Group
LED Light Emitting Diode
LIN Local Interconnect Network
LLC Logical Link Control
LSS Layer Setting Services
MAC Medium Access Control
MCAN Motorola CAN Module
MCU Microcontroller
MDI Medium Dependent Interface
NBT Nominal Bit Time (tNBT)
NRZ Non-Return To Zero
NVSRAM Non-Volatile Static Random Access Memory
OEM Original Equipment Manufacturer
OF DS1996 Overflow Flag
OSI Open Systems Interconnection
OTP One-Time Programmable
PCB Printed Circuit Board
PD 1 – Wire® Presence Detect
PF DS1996 Partial-byte Flag
vi

PIC® Programmable Interrupt Controller
PLS Physical Signaling
PMA Physical Medium Attachment
PHASE_SEG Phase Buffer Segment (tPHASE_SEG1/tPHASE_SEG2)
POR Power-On Reset
PROP_SEG Propagation Time Segment (tPROP_SEG)
R m
Worst-case response time of CAN message
R&D Research and Development
RBF Receive Buffer Flag
REC Receive Error Counter
RF Radio Frequency
RJW Resynchronization Jump Width
ROM Read-Only-Memory
RPUP Pull-up Resistor
RTL Register Transfer Level
RTR Remote Transmission Request
RTS Request To Send
RXD Receive Exchange Data
s m
Bounded size of a CAN message in bytes
SAE Society of Automotive Engineers
SFN Single line of contacts, Flat, No leads
SHA Secure Hash Algorithm
vii

SI Serial In
SO Serial Out
SOF Start Of Frame
SOIC Small Outline Integrated Circuit
SOT23 Small Outline Transistor, Style 23
SRA Search ROM Accelerator
SRR Substitute Remote Request
SPI Serial Peripheral Interface
SYNC_SEG Synchronization Segment (tSYNC_SEG)
bit
Bit time of the CAN bus
T m
Period of a given CAN message
tPDH 1 – Wire® Presence-detect high time
tPDL 1 – Wire® Presence-detect low time
tREC 1 – Wire® bus recovery time
tRSTH 1 – Wire® Reset high time
tRSTL 1 – Wire® Reset low time
tSCL System Clock time
tSLOT Time to communicate one bit excluding recovery time
ttxclk Transmit Clock
tW1L 1 – Wire® Write-one low time
Tax DS1996 Target Address number
TBE Transmit Buffer Empty
viii

TCL Transceive Logic
TCP/IP Transmission Control Protocol/Internet Protocol
TEC Transmit Error Counter
TEDS Transducer Electronic Data Sheet
TEMT Transmit Shift Register Empty
TO – 92 Transistor Outline Package, Case Style 92
t Q
Time Quantum
TSOC Thin Small Outline C-lead
TTA Time-Triggered Architectures
TTCAN Time-Triggered CAN
TTL Transistor-Transistor Logic
TTP Time-Triggered Protocols
TXD Transmit Exchange Data
UCSP Ultra Chip Scale Package
VCC Common-collector voltage supply
VDD Supply voltage
VPROH High-level of the Power-on Reset comparator
VPUP 1 – Wire® Pull-up Voltage
VHDL VHSIC Hardware Description Language
VHSIC Very-High-Speed Integrated Circuit
w m
Worst-case queuing delay of a CAN message
ix

ACKNOWLEDGEMENTS
I would like to express my sincere gratitude and thanks to Dr. Kenneth G. Ricks for all of
his guidance, support, and supervision of this research project. His countless reviews and
seemingly endless revisions were instrumental in finalizing this work. I would also like to
express my appreciation to all members of my committee: Dr. Jeff Jackson, Dr. Joseph Neggers,
Dr. Kenneth G. Ricks, Dr. William Stapleton, and Dr. Larry Wurtz. Thanks to all for their
continued belief and support to help make this work possible.
x

CONTENTS
ABSTRACT .................................................................................................................................... ii
DEDICATION ............................................................................................................................... iii
LIST OF ABBREVIATIONS AND SYMBOLS .......................................................................... iv
ACKNOWLEDGEMENTS .............................................................................................................x
LIST OF TABLES ...................................................................................................................... xvii
LIST OF FIGURES .......................................................................................................................xx
1 INTRODUCTION ........................................................................................................................1
2 1 – WIRE® COMMUNICATION PROTOCOL .........................................................................5
2.1 History of 1 – Wire® ...........................................................................................................5
2.2 1 – Wire® Overview ............................................................................................................6
2.3 1 – Wire® Communication ..................................................................................................9
2.3.1 Microprocessor Port-Pin Attachments ......................................................................11
2.3.2 Microprocessor with Built-In 1 – Wire® Master......................................................13
2.3.3 Synthesizable 1 – Wire® Bus Master .......................................................................14
2.3.4 Serial Interface Protocol Conversions ......................................................................15
2.3.5 Timing/Transaction Sequence on the 1 – Wire® Bus ..............................................19
2.3.6 1 – Wire® Search Algorithm ....................................................................................22
2.3.7 1 – Wire® CRC Check .............................................................................................25
2.3.8 1 – Wire® Commands ..............................................................................................27
xi

2.4 Types of Devices................................................................................................................29
2.4.1 1 – Wire® Device Packaging ...................................................................................29
2.4.2 Device Functions and Typical Applications .............................................................30
2.4.3 Unique Address and Device Customization .............................................................33
2.5 Network Types and Precedents ..........................................................................................34
2.5.1 Slave Device Weight.................................................................................................35
2.5.2 1 – Wire® Network Topologies ...............................................................................36
2.5.3 1 – Wire® Network Limitations ...............................................................................38
2.5.4 Parasitic Power..........................................................................................................39
2.5.5 Making Reliable 1 – Wire® Networks .....................................................................39
3 CONTROLLER AREA NETWORK (CAN) PROTOCOL ...................................................41
3.1 History of CAN ..............................................................................................................41
3.2 Overview of CAN ..........................................................................................................42
3.3 CAN-Message-Based Communication ..........................................................................46
3.3.1 Data Frames ..............................................................................................................47
3.3.2 Remote Frames .........................................................................................................53
3.3.3 Error Frames .............................................................................................................54
3.3.4 Overload Frame ........................................................................................................56
3.3.5 Interframe Space .......................................................................................................57
3.4 Error Detection and Handling ............................................................................................58
3.4.1 Output Timing of an Error Frame .............................................................................61
3.5 Fault Confinement and Error States ...................................................................................62
xii

3.5.1 Error-Active ..............................................................................................................63
3.5.2 Error-Passive .............................................................................................................64
3.5.3 Bus-Off .....................................................................................................................64
3.6 CAN Bit Timing Requirements .....................................................................................65
3.6.1 CAN Bit Structure .................................................................................................65
3.6.2 Synchronization Segment .........................................................................................67
3.6.3 Propagation Segment ................................................................................................69
3.6.4 Synchronization ........................................................................................................70
3.6.5 Re-Synchronization...................................................................................................71
3.7 Oscillator Tolerance ...........................................................................................................72
3.8 Propagation Delay ..............................................................................................................72
3.9 Selection of Bit Timing Values..........................................................................................73
3.9.1 Step-by-Step Calculation of Bit Timing Parameters .............................................74
4 THE CHALLENGES OF INTERFACING CAN AND 1 – WIRE® COMMUNICATION
PROTOCOLS ................................................................................................................................76
4.1 The Need for the Interface .................................................................................................76
4.2 Applications .......................................................................................................................78
4.3 Challenging Problems ........................................................................................................80
4.3.1 Multi-Master to Single Master ..................................................................................81
4.3.2 Message IDs vs. Addresses .......................................................................................86
4.3.3 Event-Triggered vs. Time-Triggered Control Paradigms .........................................93
4.3.4 Timing Performance .................................................................................................97
xiii

4.3.5 Communication Speed Differential ........................................................................112
5 THE INTERFACE OF CAN AND 1 – WIRE® COMMUNICATION PROTOCOLS ......113
5.1 Interface Overview...........................................................................................................113
5.2 1 – Wire® FPGA Implementation ...................................................................................113
5.2.1 1 – Wire® Master Overview ...................................................................................114
5.2.2 Command Register..................................................................................................118
5.2.3 Search ROM Accelerator Description ....................................................................119
5.2.4 Transmit/Receive Buffer Register ..........................................................................122
5.2.5 Interrupt & Interrupt Enable Registers ...................................................................123
5.2.6 Clock Divisor Register ............................................................................................127
5.2.7 Control Register ......................................................................................................128
5.2.8 Verification of 1 – Wire® Module .........................................................................130
5.2.8.1 Single Search ROM (single_search_rom) Test..............................................134
5.2.8.2 Multiple One-Wire Network (multi_ow_network) Test ................................135
5.2.8.3 Scratchpad Memory (scratchpad_integrity) Test ...........................................136
5.2.8.4 Command Recognition (cmd_recognition) Test ............................................138
5.3 CAN (Controller Area Network) FPGA Implementation ............................................139
5.3.1 Register Map and Address Allocation ....................................................................143
5.3.2 CAN Module Control Registers Overview .........................................................144
5.3.3 CAN Module Control Register (CCNTRL) ........................................................145
5.3.4 CAN Module Command Register (CCOM) .......................................................147
5.3.5 CAN Module Status Register (CSTAT) .............................................................149
xiv

5.3.6 CAN Module Interrupt Register (CINT) ............................................................152
5.3.7 CAN Module Acceptance Code Register (CACC) .............................................153
5.3.8 CAN Module Acceptance Mask Register (CACM) ...........................................154
5.3.9 CAN Module Bus Timing Register 0 (CBT0) ....................................................155
5.3.10 CAN Module Bus Timing Register 1 (CBT1) ..................................................157
5.3.11 CAN Module Output Control Register (COCNTRL) .......................................159
5.3.12 CAN Module Transmit Buffer Registers Overview .........................................161
5.3.13 CAN Module Transmit Buffer Identifier Register (TBI)..................................162
5.3.14 CAN Module Remote Transmission Request/Data Length Code Register
(TRTDL) ..........................................................................................................................162
5.3.15 CAN Module Transmit Data Segment Registers (TDS) 1 – 8 ..........................163
5.3.16 CAN Module Receive Buffer Registers Overview ...........................................164
5.3.17 CAN Module Receive Buffer Identifier Register (RBI) ...................................165
5.3.18 CAN Module Remote Transmission Request/Data Length Code Register
(RRTDL) ..........................................................................................................................165
5.3.19 CAN Module Receive Data Segment Registers (RDS) 1 – 8 ...........................165
5.3.20 CAN Node Overview ........................................................................................166
5.3.20.1 Firmware Description ..................................................................................171
5.3.20.2 PIC® MCU Initialization .............................................................................173
5.3.20.3 MCP2515 Initialization ................................................................................175
5.3.20.4 Interrupt Service Routine .............................................................................175
5.3.21 Verification of CAN Module ............................................................................181
xv

5.3.21.1 Synchronization Test (test_synchronization) ...............................................182
5.3.21.2 Bus-Off Test (bus_off_test) .........................................................................183
5.3.21.3 Error Test (error_test) ..................................................................................185
5.3.21.4 Send Basic Frame Test (send_frame_basic) ................................................190
5.3.21.5 Send Extended Frame Test (send_frame_extended) ....................................191
6 1 – WIRE® AND CAN COMBINED SYSTEM PROTOTYPE IMPLEMENTATION ....193
6.1 Overview of Integrated System .......................................................................................193
6.2 Verification of Combined Prototype System ...................................................................195
6.2.1 Test Verification and Overview ..............................................................................196
6.2.1.1 DS1996 Addressing and Memory Layout .....................................................197
6.2.1.2 Test Results – Transferring CAN data bytes to 1 – Wire® devices ..........199
6.2.1.3 Test Results – 1 – Wire® Master requests data from CAN nodes ............201
7 CONCLUSIONS AND FUTURE WORK ...............................................................................206
REFERENCES ............................................................................................................................218
xvi

LIST OF TABLES
2.1 Port Adapters for 1 – Wire® Devices ..........................................................................................18
2.2 1 – Wire® Bus Operations ...........................................................................................................20
2.3 1 – Wire® Bit Search Information ...............................................................................................23
2.4 1 – Wire® Master and Slave Search Sequence............................................................................24
2.5 1 – Wire® Search Path Direction ................................................................................................25
3.1 Frame Types and Roles of Each Frame .......................................................................................47
3.2 Data Length Code Field ...............................................................................................................49
3.3 Types of Errors ............................................................................................................................61
3.4 Error Flag Output Timing ............................................................................................................62
3.5 Types of Segments and Their Roles ............................................................................................68
4.1 Address claim status and reserved bits ........................................................................................90
4.2 Time-Triggered vs. Event-Triggered ...........................................................................................94
4.3 Categorization of Real-Time Systems .........................................................................................96
4.4 Time Savings for a Read ROM Function ....................................................................................103
4.5 Parameters of Impact ...................................................................................................................107
4.6 Results Matrix ..............................................................................................................................108
4.7 Example results with N 20 .......................................................................................................110
5.1 1 – Wire® Register Addresses .....................................................................................................116
5.2 Clock Divisor Register Settings for Input Clock Rates ...............................................................128
xvii

5.3 Resource Utilization.....................................................................................................................131
5.4 Single Search ROM (single_search_rom) Test Results ...............................................................134
5.5 Multiple One-Wire Network (multi_ow_network) Test Results .................................................135
5.6 Scratchpad Memory (scratchpad_integrity) Test Results ............................................................137
5.7 Command Recognition (cmd_recognition) Test Results .............................................................138
5.8 Control Registers .........................................................................................................................145
5.9 Synchronization Jump Width (SJW) ...........................................................................................156
5.10 Baud Rate Prescaler ...................................................................................................................156
5.11 Time Segment Values ................................................................................................................158
5.12 Output Control Modes ...............................................................................................................159
5.13 Output Control Bits ....................................................................................................................161
5.14 CAN driver output levels .......................................................................................................161
5.15 Transmit Buffer Registers ..........................................................................................................161
5.16 Data Length Code Bits ...............................................................................................................163
5.17 Receive Buffer Registers ...........................................................................................................164
5.18 CAN Node Message Identifiers .............................................................................................169
5.19 Resource Utilization...................................................................................................................182
5.20 Bus-Off Test (bus_off_test) Results ..........................................................................................185
5.21 Send Basic Frame (send_frame_basic) Test Results .................................................................190
5.22 Send Extended Frame (send_frame_extended) Test Results .....................................................191
6.1 Resource Utilization.....................................................................................................................194
6.2 Test Results ..................................................................................................................................200
xviii

6.3 FILHITx Bit Definitions ..............................................................................................................203
6.4 Test Results ..................................................................................................................................204
7.1 FIFO Buffer Memory Pin Names and Descriptions ....................................................................215
xix

LIST OF FIGURES
2.1 1 – Wire® Network .....................................................................................................................5
2.2 Typical 1 – Wire® Communication Flow ...................................................................................10
2.3 Bidirectional port pin with optional circuit for strong pullup (dashed lines) ..............................12
2.4 Unidirectional port pins with optional circuit for strong pullup (dashed lines) ...........................12
2.5 µC with Built-In 1 – Wire® Master & optional strong pullup circuit (dashed lines) ..................13
2.6 ASIC/FPGA with optional circuit for strong pullup (dashed lines) ............................................14
2.7 UART/RS232 Serial Port Interface .............................................................................................16
2.8 I 2 C interface with optional circuit for extra strong pullup (dashed lines)....................................17
2.9 1 – Wire® Master for a USB interface ........................................................................................17
2.10 Reset/Presence Detect Sequence ................................................................................................20
2.11 Write Zero Time Slot .................................................................................................................21
2.12 Write One/Read One Time Slot .................................................................................................21
2.13 Read Zero Time Slot ..................................................................................................................22
2.14 64 – Bit Unique ROM ‘Registration’ Number ..........................................................................23
2.15 1 – Wire® 8 – bit CRC ..............................................................................................................26
2.16 Linear Network Topology..........................................................................................................36
2.17 Stubbed Network Topology .......................................................................................................36
2.18 Star Network Topology..............................................................................................................37
3.1 Typical CAN Bus Network ......................................................................................................43
xx

3.2 ISO/OSI Reference Model ...........................................................................................................44
3.3 Standard CAN Data Frame Format ..........................................................................................48
3.4 Extended CAN Data Frame Format .........................................................................................51
3.5 Standard and Extended Remote Frame Structures.......................................................................54
3.6 Structure of the Error Frame ........................................................................................................55
3.7 Structure of the Overload Frame..................................................................................................57
3.8 Structure of the Interframe Space (non error-passive nodes) ......................................................57
3.9 Structure of the Interframe Space (error-passive nodes) .............................................................58
3.10 CAN Bus Error States ............................................................................................................63
3.11CAN Bit Segments ..................................................................................................................66
3.12 Propagation Delay Between Nodes ...........................................................................................68
4.1 Centralized arbiter in a daisy-chain scheme ................................................................................82
4.2 Centralized arbiter with independent request and grant lines ......................................................83
4.3 Centralized arbiter with two priority levels (four devices) ..........................................................84
4.4 Decentralized bus arbitration .......................................................................................................84
4.5 CAN node components simplified block diagram ...................................................................88
4.6 CAN Node Message Acceptance Filtering ..............................................................................89
4.7 Address Claim Unit......................................................................................................................90
4.8 Message Queuing Jitter ................................................................................................................98
4.9 Initialization Procedure: Reset and Presence Pulse .....................................................................105
4.10 Write-One Time Slot..................................................................................................................106
4.11 Write-Zero Time Slot .................................................................................................................106
xxi

4.12 Read-Data Time Slot..................................................................................................................107
5.1 one_wm Synthesizable 1 – Wire® Bus Master Block Diagram ..................................................115
5.2 Command Register Bits ...............................................................................................................118
5.3 Search ROM Accelerator Mode Send Bytes ...............................................................................120
5.4 Search ROM Accelerator Mode Response Bytes ........................................................................121
5.5 Transmit/Receive Buffer Register ...............................................................................................122
5.6 Interrupt Register .........................................................................................................................124
5.7 Interrupt Enable Register .............................................................................................................126
5.8 Clock Divisor Register .................................................................................................................127
5.9 Control Register ...........................................................................................................................129
5.10 Single Search ROM Test Setup .................................................................................................134
5.11 Multiple One-Wire Network Test Setup ....................................................................................135
5.12 Scratchpad Memory Test Setup .................................................................................................137
5.13 CAN Controller Block Diagram ............................................................................................140
5.14 Controller Interface Logic Unit (CIL) .......................................................................................143
5.15 CAN Module memory map....................................................................................................144
5.16 CAN Control Register ............................................................................................................145
5.17 CAN Command Register .......................................................................................................147
5.18 CAN Status Register ..............................................................................................................150
5.19 CAN Interrupt Register ..........................................................................................................152
5.20 CAN Acceptance Code Register ............................................................................................154
5.21 CAN Acceptance Mask Register ...........................................................................................155
xxii

5.22 CAN Bus Timing Register 0 ..................................................................................................155
5.23 CAN Module Oscillator Block Diagram ...............................................................................157
5.24 CAN Bus Timing Register 1 ..................................................................................................157
5.25 CAN Output Control Register ...............................................................................................159
5.26 CAN Transmit Buffer Identifier Register ..............................................................................162
5.27 CAN Remote Transmission Request/Data Length Code Register ........................................162
5.28 CAN Transmit Data Segment Registers ................................................................................164
5.29 CAN Receive Buffer Identifier Register ................................................................................165
5.30 CAN Remote Transmission Request/Data Length Code Register ........................................165
5.31 CAN Receive Data Segment Registers ..................................................................................165
5.32 CAN Node Block Diagram ....................................................................................................167
5.33 CAN Node Operation Flowchart ...........................................................................................172
5.34 PIC12CE674 Pin Names ............................................................................................................173
5.35 CAN Node Interrupt Service Routine Flowchart ...................................................................176
5.36 Timer0 Interrupt Service Routine Flowchart .............................................................................177
5.37 CAN Node Message Received Flowchart .............................................................................178
5.38 Error Handler Routine Flowchart ..............................................................................................179
5.39 Bus-Off Test Setup ....................................................................................................................184
5.40 Error Test Setup .........................................................................................................................188
6.1 Combined CAN & 1 – Wire® Prototype System ....................................................................193
6.2 1 – Wire® & CAN Combined Prototype System ....................................................................195
6.3 DS1996 iButton Memory Map ................................................................................................197
xxiii

6.4 DS1996 Address Registers ..........................................................................................................198
6.5 RXB1CTRL – Receive Buffer 1 Control Register Bit Definitions .............................................202
7.1 FIFO Buffer Memory ...................................................................................................................213
xxiv

CHAPTER 1
INTRODUCTION
An ASIC (Application-Specific Integrated Circuit) is a collection of memory and logic
circuits on an individual silicon die. ASICs are custom designed by end-customers to perform a
specific function and thereby meet the specific needs of their application. The use of ASICs
improves performance over general-purpose CPUs, because ASICs are “hardwired” to do a
specific job and do not incur the overhead of fetching and interpreting stored instructions.
Customers implement their designs in a single silicon die by mapping their functions to a set of
predesigned, preverified logic circuits typically provided by the ASIC vendor. ASICs are used in
an assortment of products ranging from everyday consumer products such as personal
computers, automobiles, digital cameras and video games, to high-end technology products such
as workstations and supercomputers [1].
ASICs are usually classified into one of three categories: full custom, semi-custom, and
structured or platform ASICs. Full-custom ASICs are those that are entirely tailor-fitted to a
particular application from the very start and are the most costly. This means that a full custom
ASIC cannot be modified to suit different applications, and is generally produced as a single,
specific product for a particular application only. Semi-custom ASICs can be partly customized
to serve different functions within its general area of application. Unlike full-custom ASICs,
semi-custom ASICs are designed to allow a certain degree of modification during the
1

manufacturing process. Structured or platform ASICs, which belong to a relatively new ASIC
classification, are those which have been designed and produced from a tightly defined set of:
design methodologies; intellectual properties (IP’s); and well-characterized silicon, aimed at
shortening the design cycle and minimizing the development costs of the ASIC [2].
A new application emerging recently in the medical field, wearable sensor technology
can be widely used in clinical care, home health care, special people monitoring, elderly care and
assistance, psychological evaluation, physical training and many other different medical areas.
Wearable technology may provide an integral part of the solution for providing healthcare to a
growing world population that will be strained by a ballooning aging population. By providing a
means to conduct telemedicine – the monitoring, recording, and transmission of physiological
signals from outside of the hospital – wearable technology solutions could ease the burden on
health-care personnel and use hospital space for more emergent or responsive care. In addition,
employing wearable technology in professions where workers are exposed to dangers or hazards
could help save their lives and protect health-care personnel [3].
Another application is in the rapid introduction of green technology in the form of hybrid
and electric vehicles. This will strongly increase the use of electronics as the electrical features
and increased powertrain complexity will rely on sophisticated electronic control to achieve
maximum efficiency, performance, and reliability. The replacement of mechanical components
by electronics, such as relay replacement by electronic switches, is a means by which electronics
can address several needs of the automobile industry. This would not only reduce the weight of
wire harnesses but would also increase reliability. The wire harness forms the backbone of the
2

entire electrical system of automotive vehicles. The correct implementation of the wire harness
represents one of the most expensive and technically challenging aspects of vehicle design.
This paper presents the design and simulation of a full custom ASIC conjoining two
robust, serial protocols, 1 – Wire® and CAN, that can provide a rugged, reliable
communications backbone for wearable medical technology devices as well as advanced
vehicular technologies. There are numerous devices that use either CAN or 1 – Wire® for
communication. By conjoining these two serial bus protocols this will allow data exchange
between an almost unlimited number of devices.
There are many benefits to the use of serial communication for wearable medical
technology and advanced vehicular communications. First, serial communication allows the
transfer of data between two computers, two master devices, a master and a slave device, etc.
Therefore, it is very flexible. Serial communication also allows one to interface with a PC either
during development and/or in the field. Another major benefit of serial protocols is the low pin
count; communication can be established with just one I/O pin, compared to eight or more for
parallel communications. Finally, most physiological characteristics are monitored at relatively
slow rates allowing for lower speed communication protocols to be effective. This makes serial
communications ideal for wearable medical devices.
The remainder of this dissertation is organized as follows: Chapter 2 describes the 1 –
Wire® communication protocol, Chapter 3 describes the CAN communication protocol,
Chapter discusses the challenges of interfacing CAN and 1 – Wire® communication protocols,
Chapter 5 describes the interface of CAN and 1 – Wire® communication protocols, Chapter 6
3

describes the 1 – Wire® and CAN combined system prototype implementation, and Chapter 7
discusses the conclusions reached from this research and future directions of this work.
4

2.1 History of 1 – Wire®
CHAPTER 2
1 – WIRE® COMMUNICATION PROTOCOL
The Dallas 1 – Wire® bus architecture has been around for more than a decade.
Historically, the 1 – Wire® network was envisioned as a single twisted pair (data line and ground
reference) routed throughout the area of interest with 1 – Wire® slaves connected as shown in
Figure 2.1. It was originally designed to facilitate communication with nearby devices on a short
connection. 1 – Wire® was also a way to add auxiliary memory on a single microprocessor port
pin. As the use of 1 – Wire® devices increased, methods were developed to extend the protocol
to network applications well beyond the size of a printed circuit board [4]. The 1 – Wire®
system is sometimes also referred to as MicroLAN or iButton. Figure 2.1 shows a simple 1
– Wire® network topology.
Figure 2.1 1 – Wire® Network.
5

2.2 1 – Wire® Overview
The basis of 1 – Wire® technology is a serial protocol using a single data line plus
ground reference for communication. Note that by convention the ground or reference wire is
not normally counted [5]. The 1 – Wire® bus uses a simple signaling scheme that performs two-
way communications with peripheral devices over a single electrical connection. This scheme
provides the end user with a low-cost bus driven by a PC or microcontroller (master)
communicating digitally over twisted-pair cable with 1 – Wire® components. The network is
defined with an open-drain master/slave multidrop architecture that uses a resistor pull-up to a
nominal 5V supply at the master. The 1 – Wire® protocol uses conventional CMOS/TTL
(Complementary Metal-Oxide Semiconductor/Transistor-Transistor Logic) logic levels
(maximum 0.8V for logic “zero” and a minimum 2.2V for a logic “one”) with operation
specified over a supply voltage range of 2.8V to 6V [6]. Data transfers are half-duplex and bit
sequential over a single wire, from which the slaves steal power by means of an internal diode
half-wave rectifier and capacitor. Most 1 – Wire® devices support two data rates. The lower
(standard) data rate is approximately 14 kbps and the higher (overdrive) data rate is
approximately 140 kbps. However, an even higher data rate of 1Mbps is currently in
development [7]. Since the protocol is self-clocking and tolerant to long inter-bit delays, this
makes for easy operation in input/output (I/O) intensive environments.
There are several terms often used to describe the operation and components of a 1 –
Wire® network. These are not limited to but include the following: Host Interface, Strong
Pullup, 1 – Wire® Timing, Overdrive Support, and Active Pullup.
6

Host InterfaceIn section 2.3.1 through 2.3.4, all of the circuits discussed are 1 – Wire®
masters; they all communicate with 1 – Wire® slave devices. These 1 – Wire® masters,
however, cannot function as stand-alone entities; they need a host (computer) that tells
them what to do on the 1 – Wire® side. The term “host interface” refers to the type of
connection between the 1 – Wire® Master and the host.
Strong PullupThis term refers to a means for providing extra power to the 1 – Wire®
network between time slots. Extra power is needed for several functions: by EEPROM
(Electrically Erasable Programmable Read-Only Memory) devices, when copying data
from a buffer to EEPROM cells; with secure memories, when the SHA – 1 engine is
running; or with 1 – Wire® temperature sensors during a temperature conversion. When
such 1 – Wire® devices are used in a 3V environment, strong pullup is necessary; in a 5V
environment with the same 1 – Wire® slave devices, strong pullup may be optional.
1 – Wire TimingThis is a general expression for the shape of the 1 – Wire® time slots
and the reset/presence detect sequence, and the means to generate these waveforms.
Special chips with their own timing generator can be used or waveforms can be generated
through software. Sometimes it may be necessary for the low-level functions to generate
time slots and for the reset/presence detect sequence to be written in assembly language,
so that individual instructions and the number of clock cycles to execute them can be
calculated.
Overdrive SupportMost 1 – Wire® slaves can communicate at two speeds: standard
speed and overdrive speed. In overdrive, the timing is approximately eight times faster
than at standard speed. All 1 – Wire® slave devices can communicate at standard speed.
7

All 1 – Wire® masters described in sections 2.3.2 through 2.3.4 support overdrive speed.
In section 2.3.1, the overdrive speed support depends on the capabilities of the
microcontroller (i.e. clock rate and number of clock cycles per instruction cycle).
Active PullupThe 1 – Wire® bus or network is an open-drain environment, with 0V
(logic 0) being the active state. When the bus is idle, it is pulled high to the pullup
voltage through a resistor (RPUP). Falling edges, consequently, are sharp; rising edges,
due to the resistor and the parasitic supply, can be quite slow. Active pullup refers to a
method that tests rising edges, and, if a specific threshold has been crossed, bypasses the
pullup resistor for a limited time with a low-impedance path. Active pullup is generally
not needed in short networks or with a single slave device. If available, active pullup
recharges the 1 – Wire® line faster than resistive pullup and, therefore, supports multiple
1 – Wire® slaves in the network without having to extend the recovery time between
time slots. The 1 – Wire® masters covered in section 2.3.4 differ in the strength
(impedance) of the bypass and the method that controls the duration of the active pullup
[8].
A typical 1 – Wire® net-based system consists of three main elements: a bus master with
controlling software or 1 – Wire® interface, the electrical connection between master and slaves,
and the 1 – Wire® devices, i.e. slaves. The primary job of the 1 – Wire® Master is to initiate
and control the communication with one or more 1 – Wire® slave devices on the bus. Each
slave device has a unique, unalterable, factory-programmed 64-bit identification number, which
8

serves as a device address on the bus. The 8-bit family code, a subset of the 64-bit ID, identifies
the device type and functionality.
What makes the 1 – Wire® protocol unique is that it is the only voltage-based digital
system that works with two contacts, data and ground, for half-duplex bidirectional
communication. In contrast to other serial communication systems such as I 2 C [9] or SPI, 1 –
Wire® devices are designed for use in a contact environment. Either disconnecting from the 1 –
Wire® bus or a loss of contact puts the 1 – Wire® slaves into a defined reset state. When the
voltage returns, the slaves wake up and signal their presence. With only one contact to protect,
the built-in ESD protection of 1 – Wire® devices is extremely high. With two contacts, 1 –
Wire® devices are the most economical way to add electronic functionality to nonelectronic
objects for identification, read/write memories, authentication, addressable switches, digital
temperature sensors, and delivery of calibration data or manufacturing information [10].
2.3 1 – Wire® Communication
To take advantage of 1 – Wire® technology, a 1 – Wire® Master that can generate the
waveforms to identify the devices on the bus and to communicate with them is required. There
are numerous ways to construct a 1 – Wire® Master. The differences depend on whether the 1 –
Wire® Master is for a short network (e.g. those that do not extend beyond a radius of 1 meter
and have no more than three to five slaves) or for a larger network (e.g. those that can extend the
radius beyond 1 meter to over 500 meters and can have hundreds of slaves). In general, 1 –
Wire® Master implementations can be grouped into four categories: microprocessor port-pin
9

attachments, microcontroller with built-in 1 – Wire® Master, synthesizable 1 – Wire® Bus
Master, and serial interface protocol conversions [8].
Since data on any 1 – Wire® network is transferred by time slots, a system clock is not
required, as each 1 – Wire® device is self-clocked by its own internal oscillator synchronized to
the falling edge of the master. The first part of communication on any 1 – Wire® network
involves the selection of a 1 – Wire® slave device for communications. This can be
accomplished by selecting all slave devices (i.e. broadcast), selecting a specific slave device
(using the serial number of the device), or discovering the next slave on the bus using a binary
search algorithm. Not to be confusing, all slave devices can be selected, but the 1 – Wire®
Master can only communicate with one slave at a time. Once a slave has been selected, all other
slaves drop out and ignore subsequent communications until the next reset is issued. At this
point, the bus master can issue device-specific commands to the selected slave, send data to it, or
read data from it.
In a typical 1 – Wire® network there will be more than one slave and also different types
of slave devices. Because each slave type (see section 2.4) performs different functions and
serves a different purpose, each has a unique communication sequence once it has been selected
[11]. Even though each slave type may have a different communication sequence and features,
they all have the same selection process and follow the command flow shown in Figure 2.2.
Figure 2.2 Typical 1 – Wire® Communication Flow [11].
10

2.3.1 Microprocessor Port-Pin Attachments
As the only prerequisite, this configuration requires a microprocessor with a spare
bidirectional port pin and some spare space in the program memory. Figure 2.3 shows the most
basic implementation of this 1 – Wire® Master. The upside of this implementation is its low,
additional hardware cost, since it requires just a pullup resistor. On the downside, the 1 – Wire®
timing, to communicate with slave devices, is generated through software, which can increase
the initial software development time and cost. Depending on the number of 1 – Wire® slaves
on the bus and the 1 – Wire® pullup voltage, an additional port pin may be required to
implement a strong pullup. With more than one slave device on the 1 – Wire® bus, the value of
RPUP needs to be lowered. If communicating with 1 – Wire® slaves at overdrive speed, a
microcontroller with a high clock frequency and/or a low number of clock cycles per instruction
is required.
A variation of the implementation shown in Figure 2.3 is shown in Figure 2.4. As a
prerequisite, this new implementation requires two spare unidirectional port pins, a pulldown
transistor, and some spare space in the program memory. The upside of this design is that it does
not need a bidirectional port pin, but on the downside, the 1 – Wire® timing is generated through
software, which can increase the initial software development time and cost. Depending on the
number of 1 – Wire® slaves on the bus and the 1 – Wire® pullup voltage, an additional port pin
may be required to implement a strong pullup. With more than one slave device on the 1 –
Wire® bus, the value of RPUP needs to be lowered. If communicating with 1 – Wire® slaves at
overdrive speed, a microcontroller with a high clock frequency and/or a low number of clock
cycles per instruction is required.
11

Figure 2.3 Bidirectional port pin with optional circuit for strong pullup (dashed lines) [8].
Figure 2.4 Unidirectional port pins with optional circuit for strong pullup (dashed lines) [8].
12

2.3.2 Microprocessor with Built-In 1 – Wire® Master
The implementation in Figure 2.5 is very similar to that in Figure 2.3. The difference is
in the type of microcontroller. The main prerequisites for this implementation include a
microcontroller with a built-in 1 – Wire® Master (e.g., the DS80C400, DS80C410, or
DS80C411) and some spare space in the program memory. The upside is that the 1 – Wire®
timing is generated by hardware, which can reduce the initial software development time and
cost. Consequently, the entire application software can be written in a high-level language. On
the downside, only high-end microcontrollers have a built-in 1 – Wire® Master. Depending on
the number of 1 – Wire® slaves on the bus and the 1 – Wire® pullup voltage, an additional port
pin may be required to implement a strong pullup. With more than one slave device on the 1 –
Wire® bus, the value of RPUP needs to be lowered.
Figure 2.5 µC with Built-In 1 – Wire® Master & optional strong pullup circuit (dashed lines) [8].
13

2.3.3 Synthesizable 1 – Wire® Bus Master
The circuit in Figure 2.6 is very similar to the circuit in Figure 2.5. The difference is that
the microcontroller and 1 – Wire® port are embedded in an ASIC or FPGA (Field Programmable
Gate Array). This circuit requires an ASIC or FPGA with microcontroller capability, at least one
spare bidirectional port pin, unused logic gates, and some spare space in the program memory.
The upside of this circuit is that the 1 – Wire® timing is generated by hardware, which can
reduce the initial software development time and cost. Consequently, the entire application
software can be written in a high-level language. On the downside, not all ASICs or FPGAs
have 5V – tolerant ports. The 1 – Wire® operating voltage is limited by the port characteristics
of the ASIC/FPGA. Depending on the number of 1 – Wire® slaves on the bus and the 1 –
Wire® pullup voltage, an additional port pin may be required to implement a strong pullup.
With more than one slave device on the 1 – Wire® bus, the value of RPUP needs to be lowered.
Figure 2.6 ASIC/FPGA with optional circuit for strong pullup (dashed lines) [8].
14

2.3.4 Serial Interface Protocol Conversions
The final category of 1 – Wire® Master implementation is created using an interface
between some type of controller and an off-the-shelf 1 – Wire® Master. As shown in Figure 2.7,
one way to accomplish this is to interface the controller to the 1 – Wire® Master via a serial
interface. This implementation requires a way to control a UART, such as a microcontroller,
FPGA, or PC serial port, and some spare space in the program memory. The upside of this
design is that the 1 – Wire® timing is generated by hardware leading to the benefits mentioned
above. Through control registers, the 1 – Wire® timing can be fine-tuned.
The DS2480B is a serial port to 1 – Wire® interface chip that supports both standard and
overdrive speeds [12]. It directly interfaces UARTs and 5V RS232 systems with its lines TXD
(transmit) and RXD (receive) to a 1 – Wire® bus. In addition, the device performs a speed
conversion allowing the data rate at the communication port to be different from the 1 – Wire®
data rate. The DS2480B supports a strong pullup and active pullup. It is also the strongest (i.e.
capable of delivering the most power) single-chip 1 – Wire® Master available and is good for
communicating with a large number of slave devices. On the downside, the DS2480B is more
costly than the discrete components shown in Figures 2.3 through 2.6.
15

Figure 2.7 UART/RS232 Serial Port Interface [8].
For those applications that already use an I 2 C [9] bus, the implementation in Figure 2.8 is
most convenient to establish a 1 – Wire® Master. This design makes use of an existing I 2 C bus
controller, such as a microcontroller, or ASIC/FPGA, and some spare space in the program
memory. The advantages to this implementation are its relatively low cost for the features
provided, and the fact that the 1 – Wire® timing is generated by hardware. The DS2482
supports a strong pullup as well as an active pullup. On the downside, the DS2482 cannot drive
as many 1 – Wire® slave devices as the DS2490 or DS2480B. The single-channel version, the
DS2482-100 as shown in Figure 2.8, has a control output for an additional strong pullup (Q1)
circuit as shown in Figures 2.3 through 2.6 [13 – 15].
16

Figure 2.8 I 2 C interface with optional circuit for extra strong pullup (dashed lines) [8].
Figure 2.9 1 – Wire® Master for a USB interface [8].
A 1 – Wire® Master application circuit can also be created using a USB port, as shown in
Figure 2.9. The upside of this implementation is that the 1 – Wire® timing is generated by
17

hardware. Through control registers, the 1 – Wire® timing can be fine-tuned. The DS2490, like
the DS2482 and DS2480B, supports a strong pullup and an active pullup. On the downside, the
DS2490 is more costly than the other implementations presented here and also the DS2490
pullup is not as strong as the DS2480B.
In addition to the interface circuits described previously, 1 – Wire® can also be
connected to a PC using a bus converter. The primary function of the bus converter is to
generate the appropriate 1 – Wire® communication signals and perform level conversion
depending on the type of port device used. USB, RS232 serial, and parallel port adapters are
available to connect 1 – Wire® devices to a host PC. Table 2.1 lists the different types of PC
adapters available. Since the PC-ready adapters do not require any software development by the
user, PC attachments that function as a 1 – Wire® Master are very convenient for evaluating 1 –
Wire® devices and for prototyping.
Table 2.1 Port Adapters for 1 – Wire® Devices.
Port Type Converter
1 – Wire®
Port
Part Number Notes
USB DS2490
iButton
RJ – 11
DS9490B
DS9490R
Built-in ID chip is hardwired to 1 –
Wire® bus
iButton
DS1411-009
Built-in ID chip is hardwired to 1 –
Wire® bus
DS1411-S09 No ID chip
RS232 DS2480B
DS9097U-009
Built-in IC chip is hardwired to 1 –
Wire® bus
RJ – 11
DS9097U-S09 No ID chip
No ID chip; w/ external 12V supply,
DS9097U-E25 this adapter can program 1 – Wire®
EPROMs
Parallel DS1481 iButton DS1410E-001
Built-in ID chip is hardwired to 1 –
Wire® bus
18

2.3.5 Timing/Transaction Sequence on the 1 – Wire® Bus
In any 1 – Wire® network, there are four basic signaling operations that comprise all
device communications: Reset, Write ‘0’ bit, Write ‘1’ bit, and Read bit. Referring back to
Figure 2.2, these four signaling operations are an integral part of each step in the typical 1 –
Wire® communication flow. The 1 – Wire® bus requires strict signaling protocol to ensure data
integrity. A typical 1 – Wire® transaction sequence consists of four steps: Initialization, ROM
(read-only-memory) Function Command, Memory Function Command, if applicable (not all 1 –
Wire® devices support these commands, i.e. identification (ID) only devices), and
Transaction/Data.
An initialization sequence begins when the bus master drives a defined length “Reset”
pulse that synchronizes the entire bus. Every slave then responds to the “Reset” pulse with a
logic low “Presence” pulse. To write data, the master first initiates a time slot by driving the 1 –
Wire® line low, and then, either holds the line low (wide pulse) to transmit a logic ‘0’ or releases
the line (short pulse) to allow the bus to return to the logic ‘1’ state. To read data, the master
again initiates a time slot by driving the line with a narrow low pulse. A slave can then either
return a logic ‘0’ by turning on its open-drain output and holding the line low to extend the pulse,
or return a logic ‘1’ by leaving the open-drain output off to allow the line to recover. Table 2.2
provides a list of operations and implementation steps for standard speed communications
(overdrive speeds are shown in parentheses) on a typical 1 – Wire® bus network. Figures 2.10
through 2.13 show scope traces of the 1 – Wire® operations described in Table 2.2.
19

Table 2.2 1 – Wire® Bus Operations.
Operation Description Implementation
Reset
Write ‘0’ Bit
Write ‘1’ Bit
Read Bit
Reset all of the 1 – Wire® bus slave
devices and get them ready for a
command.
Send ‘0’ bit to all of the 1 – Wire®
slaves (Write ‘0’ slot time).
Send ‘1’ bit to all of the 1 – Wire®
slaves (Write ‘1’ slot time).
Read a bit from the 1 - Wire® slaves
(Read time slot).
20
Delay 0µs. (2.5µs)
Drive the bus low, delay 480µs. (70µs)
Release the bus, delay 70µs. (8.5µs)
Sample the bus: ‘0’ = device(s) present,
‘1’ = no device present.
Delay 410µs. (40µs)
Drive the bus low, delay for 60µs. (7.5µs)
Release the bus, delay for 10µs. (2.5µs)
Drive the bus low, delay for 6µs. (1.0µs)
Release the bus, delay for 64µs. (7.5µs)
Drive the bus low, delay for 6µs. (1.0µs)
Release the bus, delay for 9µs. (1.0µs)
Sample the bus to read from slave(s), delay for
55µs. (7µs)
Figure 2.10 Reset/Presence Detect Sequence.

Figure 2.11 Write Zero Time Slot.
Figure 2.12 Write One/Read One Time Slot.
21

2.3.6 1 – Wire® Search Algorithm
Figure 2.13 Read Zero Time Slot.
As stated previously, all 1 – Wire® slaves each have a 64 – bit unique registration
number in ROM that is used to address them individually by a 1 – Wire® Master. If the ROM
numbers of the slave devices on the 1 – Wire® network are not known, then they can be
discovered by using a search algorithm. This is a binary tree search where branches are followed
until a device ROM number, or leaf, is found. Subsequent searches then take the other branch
paths until all of the leaves present are discovered.
The search algorithm begins with the devices on the 1 – Wire® being reset using the reset
and presence pulse sequence. If this is successful then the 1 – byte search command is sent. The
search command readies the 1 – Wire® devices to begin the search. There are two types of
search commands. The normal search command (0xF0) will perform a search with all devices
22

participating. The alarm or conditional search command (0xEC) will perform a search with only
the devices that are in some sort of alarm state. This reduces the search pool to quickly respond
to devices that need attention.
Figure 2.14 64 – Bit Unique ROM ‘Registration’ Number.
Following the search command, the actual search begins with all of the participating
devices simultaneously sending the first bit (least significant) in their ROM number as shown in
Figure 2.14. As with all 1 – Wire® communication, the 1 – Wire® Master initiates every bit
whether it is data to be read or written to the slave devices. Due to the characteristics of the 1 –
Wire® bus, when all devices respond at the same time, the result will be a logical AND of the
bits sent. After the devices send the first bit of the ROM number, the master initiates the next bit
and the devices then send the complement of the first bit. From these two bits, information can
be derived about the first bit in the ROM numbers of the participating devices. This information
is summarized in Table 2.3.
Table 2.3 1 – Wire® Bit Search Information.
Bit (true) Bit (complement) Information Known
0 0
There are both 0s and 1s in the current bit position of the
participating ROM numbers. This is a discrepancy.
0 1 There are only 0s in the bit of the participating ROM numbers.
1 0 There are only 1s in the bit of the participating ROM numbers.
1 1 No devices participating in search.
Next, according to the search algorithm, the 1 – Wire® Master must then send a bit back
to the participating devices. If a participating device has that bit value, it continues participating.
If it does not have the bit value, it goes into a wait state until the next 1 – Wire® reset is
23

detected. This ‘read two bits’ and ‘write one bit’ pattern, from the perspective of the Master, is
then repeated for the remaining 63 bits of the ROM number (see Table 2.4). In this way the
search algorithm forces all but one device to go into this wait state. At the end of one pass, the
ROM number of this last participating device is known. On subsequent passes of the search, a
different path is taken to find the other device ROM numbers.
Table 2.4 1 – Wire® Master and Slave Search Sequence.
Master Slave
1 – Wire® reset stimulus Produce presence pulse.
Write search command (normal or alarm) Each slave readies for search
Read ‘AND’ of bit 1 Each slave sends bit 1 of its ROM number.
Read ‘AND’ of complement of bit 1 Each slave sends complement of bit 1 of its ROM number.
Each participating slave receives the bit written by master, if bit
Write bit 1 direction (according to algorithm) read is not the same as bit 1 of its ROM number then go into a
wait state.
Read ‘AND’ of bit 64 Each slave sends bit 64 of its ROM number.
Read ‘AND’ of complement of bit 64 Each slave sends complement bit 64 of its ROM number.
Write bit 64 direction (according to algorithm)
Each participating slave receives the bit written by master, if bit
read is not the same as bit 64 of its ROM number then go into a
wait state.
On examination of Table 2.3, it is obvious that if all of the participating devices have the
same value in a bit position then there is only one choice for the branch path to be taken. The
condition where no devices are participating is an atypical situation that may arise if the device
being discovered is removed from the 1 – Wire® bus during the search. If this situation arises
then the search should be terminated and a new search started with a 1 – Wire® reset. The
condition where there are both 0s and 1s in the current bit position is called a discrepancy and is
the key to finding devices in the subsequent searches. The search algorithm specifies that on the
first pass, when there is a discrepancy (bit/complement = 0/0), the ‘0’ path is taken. The bit
position for the last discrepancy is recorded for use in the next search [16]. Table 2.5 describes
the paths taken on subsequent searches when a discrepancy occurs.
24

Table 2.5 1 – Wire® Search Path Direction.
Search Bit Position vs. Last Discrepancy Path Taken
= Take the ‘1’ path.
< Take the same path as last time (from the last ROM number found).
> Take the ‘0’ path.
The search algorithm also keeps track of the last discrepancy that occurs within the first
eight bits of the algorithm. The first eight bits of the 64 – bit registration number is a family
code. As a result, the devices discovered during the search are grouped into family types. The
last discrepancy within that family code can be used to selectively skip whole groups of 1 –
Wire® devices. The 64 – bit ROM number also contains an 8 – bit cyclic-redundancy-check
(CRC). This CRC value is verified to ensure that only correct ROM numbers are discovered.
2.3.7 1 – Wire® CRC Check
Serial data can be checked for errors in a variety of ways. One common way is to include
an additional bit in each packet being checked that will indicate if an error has occurred. The
error detection scheme most effective at locating errors in a serial data stream with a minimal
amount of hardware is the Cyclic Redundancy Check. The most significant byte in the ROM
code of each 1 – Wire® device contains a CRC value based on the previous seven bytes of data
for that part. When the host system begins communication with a device, the 8 – byte ROM is
read, least significant bit first. If the CRC that is calculated by the host agrees with the CRC
contained in byte 7 of the ROM data actually read, the communication is considered valid. If
this is not the case, an error has occurred and the ROM code should be read again.
The CRC can be most easily understood by considering the function as it would actually
be built in hardware, usually represented as a shift register arrangement with feedback as shown
25

in Figure 2.15. Alternatively, the CRC is sometimes referred to as a polynomial expression in a
dummy variable X, with binary coefficients for each of the terms. The coefficients correspond
directly to the feedback paths shown in the shift register implementations.
Figure 2.15 1 – Wire® 8 – bit CRC.
The 1 – Wire® CRC magnitude is 8 bits, which is used for checking the 64 – bit ROM
code written into each 1 – Wire® product. This ROM code consists of an 8 – bit family code
written into the least significant byte, a unique 48 – bit serial number written into the next six
bytes, and a CRC value that is computed based on the preceding 56 bits of ROM and then
written into the most significant byte. The location of the feedback paths represented by the
exclusive-or gates in Figure 2.15, or presence of coefficients in the polynomial expression,
determine the properties of the CRC and the ability of the algorithm to locate certain types of
errors in the data. The types of errors that are detectable are:
Any odd number of errors anywhere within the 64 – bit number.
All double-bit errors anywhere within the 64 – bit number.
Any cluster of errors that can be contained within an 8 – bit ‘window’ (1 – 8 bits
incorrect).
Most larger clusters of errors.
26

From Figure 2.15, the input data gets exclusive-or’d with the output of the eighth stage of the
shift register. The shift register can be considered mathematically as a dividing circuit. The
input data is the dividend, and the shift register with feedback acts as a divisor. The resulting
quotient is discarded, and the remainder is the CRC value for that particular stream of input data,
which resides in the shift register after the last data bit has been shifted in. The final result (CRC
value) is dependent on the past history of the bits presented. Therefore, it would take an
extremely rare combination of errors to escape detection by this method [17].
2.3.8 1 – Wire® Commands
After initialization has been completed and the bus master has detected a presence pulse
on the bus, it can issue one of the following ROM function commands:
READ ROM [33h] – This command allows the bus master to read a device’s 8 – bit
family code, unique 48 – bit serial number, and 8 – bit CRC code. This command can
only be used if there is a single slave device on the bus. If more than one slave (See
Figure 2.1) is present on the bus, a data collision will occur when all slaves try to transmit
at the same time (open drain will produce a wired – AND result). The resultant family
code and 48 – bit serial number will result in a mismatch of the CRC.
SEARCH ROM [F0h] – When a system is initialized, the bus master might not know the
number of devices on the 1 – Wire® bus or their registration numbers. The SEARCH
ROM command allows the bus master to use a process of elimination to identify the 64 –
bit ROM codes of all slave devices on the bus. The process is the repetition of a simple 3
– step routine on each bit of the ROM by the bus master: read a bit, read the complement
27

of the bit, then write the desired value of that bit. After one complete pass, the bus
master knows the contents of the ROM in one device. The remaining number of devices
and their ROM codes can be identified by additional passes.
MATCH ROM [55h] – This command followed by a 64 – bit ROM sequence, allows the
bus master to address a specific slave device on a bus topology having one or more
slaves. Only the device that exactly matches the 64 – bit ROM sequence will respond to
the following memory function command. All slaves that do not match the 64 – bit ROM
sequence wait for a reset pulse.
SKIP ROM [CCh] – This command can save time in a single slave network by allowing
the bus master to access the memory functions without providing the 64 – bit ROM code.
If more than one slave is present on the bus and, for example, a read command is issued
following the SKIP ROM command, data collision will occur on the bus as multiple
slaves transmit simultaneously (open-drain pulldowns produce a wired – AND result).
All iButtons and 1 – Wire® devices support at least some basic set of ROM function
commands such as those previously mentioned. The number of supported ROM functions
depends on the device itself but most importantly, these ROM functions (there are a total of 9)
have the same command number regardless of the iButton or 1 – Wire® device being used.
After a ROM function command has been successfully executed, the bus master may then
provide any one of the memory function commands specific to the device being addressed. (See
device documentation for specific number and type of memory functions as these can be
different for each device and also not all devices support these commands.) This allows further
data and other transactions to take place between the bus master and slave devices.
28

2.4 Types of Devices
Dependent on their function, 1 – Wire® devices are available in a variety of packages
such as single components in an integrated circuit (IC) package and in some cases a portable
form called an iButton that resembles a watch battery. Manufacturers also produce products
that are more complex than a single component, and use the 1 – Wire® bus to communicate. A 1
– Wire® device may be just one of many components on a circuit board within a product, but are
also found in isolation within devices or attached to a device being monitored.
2.4.1 1 – Wire® Device Packaging
Most 1 – Wire® devices are available in durable, stainless steel containers about the size
of four stacked dimes called iButtons. 1 – Wire® devices are also offered in conventional
transistor (TO – 92) and IC packages (TSOC, SOIC, SOT23). Designed for contact applications
and easy attachment, the 2 – contact SFN (Single line of contacts, Flat, No leads) package
accommodates parasitically powered 1 – Wire® devices. The 16mm-diameter stainless steel
iButton package protects 1 – Wire® devices from harsh environments, making them suitable
for indoor and outdoor use [10]. Many devices are also available in flip chip and UCSP (Ultra
Chip Scale Package) versions. In addition to the various device package types for 1 – Wire®
devices, 1 – Wire® peripherals also come in a wide variety including various serial- and parallel-
port adaptors for PCs, probes, fob and holders, and a wide array of iButton attachments. A 1 –
Wire® peripheral can be thought of as an auxiliary device that connects to a 1 – Wire® network
and allows communication between 1 – Wire® devices and a host computer or 1 – Wire®
devices and 1 – Wire® networks.
29

2.4.2 Device Functions and Typical Applications
At this time, there are approximately 40 1 – Wire® devices, including some close to the
end of their lifetime. iButton 1 – Wire® devices can be categorized into one of seven
categories: ID only, NV SRAM, EPROM, EEPROM, Real-Time Clocks, Secure, and Data
Loggers. Remaining 1 – Wire® devices fall into one of eight categories: EPROM; EEPROM;
Memory with GPIO; Temperature Sensors and Switches; 1 – Wire® Interface Products; four
Channel A-to-D Converter; Timekeeping and Real-Time Clocks; and Battery Protectors,
Selectors, and Monitors.
Although the original concept behind the development of the 1 – Wire® protocol was to
provide simplified communications on a single PCB, the main applications of 1 – Wire® devices
today are primarily but not limited to the following:
Print Cartridge ID – using unique SFN packaging, 1 – Wire® devices can easily be
attached to nonelectronic peripherals like printer consumables. The SFN package can be
mounted with snap-fit or adhesive into a recessed area. This allows 1 – Wire®
authentication and monitoring features with a single, dedicated connector contact, which
reduces connector complexity and cost. The 1 – Wire® devices typically used include
the DS1990A/DS1990R, DS1982, and DS1985.
Medical Consumable ID – SFN packaging allows easy attachment to nonelectronic
peripherals like medical sensors (ID and calibration), blood glucose strips (calibration
and authentication), and reagent bottles (ID). The 1 – Wire® devices typically used
include the DS2401, DS2413, DS2502, DS2506, DS2431, DS28EC20, DS2433, DS2432,
and DS28E01.
30

Rack Card Calibration and Control – the controller in a module-based rack or chassis
system often needs to identify what cards are installed, monitor key metrics like
temperature, and track hot-swapped units. The 1 – Wire® memory, I/O, and
temperature-sensor products solve this problem by providing a unique identity for every
module in the system. The 1 – Wire® devices typically used include the DS2413,
DS28EA00, DS2502, DS2505, DS2431, DS28EC20, DS2433, DS28E04, and DS28E01.
PCB identification and authentication – factory-administered 64-bit serialization with
embedded memory provides PCB/product labeling and storage of product information.
Programmable features like OTP (One-Time Programmable) mode and write protection
combine with SHA-1 based secure authentication to ensure that critical data cannot be
altered once it is programmed. Storage of product characteristics, PCB
hardware/software revision, maintenance records, and calibration constants are examples
of typical usage. The 1 – Wire® devices typically used include the DS2401, DS2411,
DS1963S, DS1992L, DS2502-E48, DS2502-E64, DS1982, DS1985, DS2431,
DS28EC20, DS2433, DS28E01, and DS1961S.
Accessory/Peripheral Identification and Control – typical applications include battery-
pack and power-adapter identification, LED control, TEDS (Transducer Electronic Data
Sheet) sensor identification/control, and consumable identification/control. The 1 –
Wire® devices typically used include the DS2401, DS2411, DS2413, DS2502, DS2505,
DS2431, DS28EC20, DS2433, and DS28E01.
IP Protection, Secure Feature Control Clone Prevention – authentication solutions help
OEMs (Original Equipment Manufacturers) protect product development and research
31

and development (R&D) investments by preventing low-quality knockoffs from entering
the marketplace. Authentication solution options range from customization of the unique
serial number factory-lasered into each device (providing controlled procurement access)
to secure crypto-strong ISO/IEC 10118-3 SHA-1 based challenge and response for bi-
directional authentication. The 1 – Wire® devices typically used include the DS2401,
DS2411, DS1963S, DS1993L, DS1995L, DS1996L, DS2431, DS28EC20, DS28E01, and
DS1961S.
Consumer electronics – the types of 1 – Wire® devices used in consumer electronics
include those of identification only (DS2401 and DS2411), identification plus control
(DS2450), identification plus time (DS2417 and DS1904L), identification plus EEPROM
(DS28EC20 and DS2431), and identification plus SHA – 1 secure EEPROM (DS28E01).
Access control – the types of 1 – Wire® devices used for access control include those of
identification only (DS1990A/DS1990R), identification plus NV SRAM (DS1992L,
DS1993L, DS1995L, DS1996L), and identification plus EEPROM (DS1971, DS1972,
DS1973).
Electronic cash – the type of 1 – Wire® devices used for electronic cash tokens include
those of identification plus NV SRAM (DS1963S) and identification plus SHA – 1
Secure EEPROM (DS1961S).
Gaming devices – the type of 1 – Wire® devices used for the gaming industry include
those of identification plus EEPROM (DS1977) due to high capacity (32KB) and
password protection.
32

2.4.3 Unique Address and Device Customization
Within each 1 – Wire® slave device is stored a lasered ROM section with its own
guaranteed unique, 64-bit serial number that acts as its node address. This globally unique
address is composed of eight bytes divided into three main sections: the first byte stores the 8 –
bit family code identifying the device type, the next six bytes store a customizable 48 – bit
individual address, and the last byte contains the CRC data based on the data contained in the
first seven bytes. With a 2 48 address pool, conflicting or duplicate node addresses on the bus are
almost never a problem.
Because 1 – Wire® devices can be formatted with a file directory like a floppy disk, files
can be randomly accessed and changed without disturbing other records. Information is read or
written when the master addresses a slave device connected to the bus, or an iButton is
touched to a probe somewhere along the 1 – Wire® network. The inclusion of up to 64k of
memory in 1 – Wire® devices allows a great deal of information to be stored within the device
[6].
Additionally, 1 – Wire® devices are afforded several types of device customization.
Custom ROM is perhaps the most popular with identification-only devices, but is applicable to
all devices with a 64 – bit ID number. With custom ROM, a pool of 68.7 x 10 9 numbers
(equivalent to 36 bits) is committed to the sole use of a single customer. This type of
customization occurs before packaging, which leads to a fairly long lead-time. For OTP
EPROMs, an alternate customization, called UniqueWare, takes place after packaging. Instead
of modifying the ID number, customer-specified serialization is programmed into EPROM and
then write protected [10].
33

2.5 Network Types and Precedents
As the use and popularity of 1 – Wire® devices has increased over the past two decades,
so to have the methods to extend the 1 – Wire® protocol to networked applications well beyond
the size of a circuit board. There have been many application notes, tech briefs, and other
documents published over the years from a variety of sources, authorized and unauthorized alike,
regarding 1 – Wire® implementations. As the world of 1 – Wire® devices and systems has
grown and evolved, some of the information in these documents has been augmented, modified,
or sometimes even proven incorrect. This has lead to the creation of some misinformation before
a complete analysis of large 1 – Wire® networks was completed, and some was perhaps based
on anecdotal information. As the scope of 1 – Wire® networks has grown, much has been
learned about those characteristics that make a large network reliable, and the devices themselves
have undergone a process of evolution that continues in earnest today.
As is the case with most other communication protocols and buses, a proper match
among network components (i.e., master, network cabling, and 1 – Wire® slave devices) is the
precondition for reliable 1 – Wire® operation. When bus masters are improperly designed or
implemented, or when masters intended for short-line use are pressed into service with greatly
extended communication lines, then satisfactory performance cannot always be expected [4].
Since 1 – Wire® networks are often quite “free form” in structure, this leads to numerous
combinations of wire types and topologies that can be used with 1 – Wire® devices. Due to
space limitations here, only the most general and typical applications associated with 1 – Wire®
networks are considered.
34

Often to describe measurements that are critical to 1 – Wire® network performance, two
simple terms are used: radius and weight. The radius of a network is the wire distance from the
1 – Wire® Master to the most distant slave and is measured in meters. The weight of a network
is the total amount of connected wire in the network, and it too is measured in meters. In
general, the weight of the network limits the rise time on the cable, while the radius establishes
the timing of the slowest signal reflections [4].
2.5.1 Slave Device Weight
The weight that can be supported in a 1 – Wire® network is limited and depends on the
driver (1 – Wire® Master interface). In simple terms, the weight can consist of many slaves on
very little cable, or very few slaves on a lot of cable. Slave devices add equivalent weight to a
network. Each device adds weight similar to that of a small length of wire, so devices can be
rated in terms of their equivalent wire weight. Consequently, when a network is designed, the
weight of the devices is an important consideration. A slave in iButton form usually
contributes more weight than a slave packaged as a soldered-in component. iButtons add a
weight of approximately 1m, and non-iButton slaves add a weight of approximately 0.5m [4].
In addition to the weight added by the slave devices, circuit-board traces, connectors and ESD
protection devices also contribute to the weight of a 1 – Wire® network. Although weight is
influenced by many factors, capacitance is clearly the largest single contributor. As a general
rule, the weight contribution of ESD circuits and PC-board traces can be related to their
capacitance by a factor of approximately 24pF/m [4].
35

2.5.2 1 – Wire® Network Topologies
Although there are countless configurations of 1 – Wire® networks, they usually fit into
a few general categories including linear, stubbed, and star topologies. 1 – Wire® network
topologies are based on the distribution of the 1 – Wire® slaves and the organization of the
interconnecting wires.
Linear topology: The 1 – Wire® bus is a single pair, starting from the master and extending to
the farthest slave device. Other slaves are attached to the 1 – Wire® bus with (

Star Topology: The 1 – Wire® bus is split at or near the master end and extends in multiple
branches of varying lengths. There are slave devices along, or at the ends of, the branches.
Figure 2.18 shows an example of a star topology 1 – Wire® network.
Figure 2.18 Star Network Topology.
When different topologies are intermixed, it becomes much more difficult to determine
the effective limitations for the 1 – Wire® network. As a rule, the designer should apply the
most conservative of the criteria in these cases. Unswitched star topologies (i.e. those with
several branches diverging at the master) are the most difficult to make reliable. The junction of
the various branches presents highly mismatched impedances; reflections from the end of one
branch can travel distances equal to nearly the weight of the network and cause data errors.
37

2.5.3 1 – Wire® Network Limitations
Several factors determine the maximum radius and weight of a network. Some of these
factors can be controlled and some cannot. The master-end interface greatly influences the
allowable size of a 1 – Wire® network. This interface must provide sufficient drive current to
overcome the weight of the cable and slaves. The master-end interface must also generate the 1
– Wire® waveform with timing that is within specification and optimized for the charge and
discharge times of the network. Finally, the interface must provide a suitable impedance match
to the network, so that signals are not reflected back down the line to interfere with other
network slaves.
When the network is very small, very simple master-end interfaces are acceptable.
Capacitance is low, reflected energies arrive too soon to pose a problem, and cable losses are
minimal. A simple active FET pulldown and passive resistor pullup are sufficient. However,
when cable lines lengthen and more slave devices are connected, complex signal interactions
come into play. This requires the master-end interface to be properly designed to handle these
complex signal characteristics.
The network radius is limited by several factors: the timing of waveform reflections, the
time delay produced by the cable, the resistance of the cable, and the degradation of signal
levels. Network weight is limited by the ability of the cable to be charged and discharged
quickly enough to satisfy the 1 – Wire® protocol. A simple pullup resistor has a weight
limitation of about 200m. Sophisticated 1 – Wire® Master designs have overcome this
limitation by using active pullups, that provide higher currents under logic control and have
extended the maximum supportable weight to over 500m.
38

2.5.4 Parasitic Power
The 1 – Wire® waveform must not only be sufficient for communication, but also
provide operating power for the slaves. Each slave “steals” power from the bus when the voltage
on the bus is greater than the voltage on its internal energy storage capacitor. When the weight
of the network becomes excessive, the current delivered by the master may not be sufficient to
maintain operating voltage in the slaves.
The worst-case scenario for parasitic power is a very long sequence of zero bits issued by
the master. When this occurs, the bus data line spends most of its time in the low state, and there
is very little opportunity to recharge the slaves. If the bus reaches a sufficient voltage during the
recovery time between bits and if the recovery time is long enough, there is no problem. As the
internal operating voltage in each slave drops, the slave’s ability to drive the bus to make zero
bits is reduced, and the timing of the slave changes. Eventually, when the parasitic voltage drops
below a critical level, the slave enters a reset state and stops responding. Then, when the slave
again receives sufficient operating voltage, it will issue a presence pulse and may corrupt other
bus activity in doing so. When a network has insufficient energy to maintain operating power in
the slaves, failures will be data-dependent and intermittent.
2.5.5 Making Reliable 1 – Wire® Networks
Of all the activity that occurs on a 1 – Wire® bus, device searches are the most complex
and the most difficult to perform in the presence of bus problems. Searches are the only time
(with the exception of presence pulses) when all slaves may drive the bus low at the same time.
This means that bus conditions during searches are much different from normal communications
39

with a single selected slave. If any of the many slaves misses an edge or fails to discriminate a
pulse, then it will become unsynchronized with the search algorithm and will cause errors in
subsequent bits of the search. This means that the search will fail if: a bus problem causes a
glitch on the rising edge of the waveform; the waveform fails to reach a valid low level; or any
device is starved for power during the search. Most search algorithms handle a search failure by
terminating the search algorithm and starting over, at which point yet undiscovered slaves will
seem to drop from the search.
Searching algorithms typically assume that devices may be missed due to noise. In
networks with touch-contact iButtons, the arrival of new iButtons to the network can
introduce momentary short circuits in the form of a presence pulse from the newly arrived
device. Depending on the timing of these events, those presence pulses will interfere with search
activity. The search algorithms manage such problems by removing slaves from their list of
discovered slaves only after the devices have been observed missing for a “debounce” period of
time [4].
The causes of search failures vary widely. Among the most common are starvation of
parasitic power with large radius, heavyweight networks; reflections on waveform edges with
small- and medium-radius, lightweight networks; and false triggering of the active pullup
master-end interface due to ringing in the waveform’s falling edges. Consequently, it is critical
that designers adhere to published specifications and guidelines to assure reliable networks with
good safety margins and tolerance of variations in cable, distance, and connections. In summary,
a network that reliably and consistently performs searches can generally perform other 1 –
Wire® functions reliably.
40

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

The CAN protocol was designed for short messages, no more than eight bytes long.
The protocol never interrupts an ongoing transmission, but it assigns priorities to messages to
prevent conflicts and to make sure that urgent messages are delivered first, and includes error
checking to make the communications highly reliable.
Figure 3.1 Typical CAN Bus Network.
Most network applications follow a layered approach to system implementation, which
enables interoperability between products from different manufacturers. A standard was created
by the ISO as a template to follow for this layered approach. It is called the ISO Open Systems
Interconnection (OSI) Network Layering Reference Model and is shown in Figure 3.2 for
reference.
The CAN protocol itself implements most of the lower two layers of this reference
model. The communication medium portion of the model was purposely left out of the Bosch
CAN specification to enable system designers to adapt and optimize the communication
43

protocol on multiple media for maximum flexibility (twisted pair, single wire, optically isolated,
RF, IR, etc.). With this flexibility, however, comes the possibility of interoperability concerns.
Figure 3.2 ISO/OSI Reference Model.
To ease some of these concerns, the ISO and Society of Automotive Engineers (SAE)
have defined some protocols based on CAN that include the Media Dependent Interface
definition such that all of the lower two layers are specified. ISO11898 is a standard for high-
speed applications. ISO11519 is a standard for low-speed applications, and J1939 is targeted for
truck and bus applications. All three of these protocols specify a 5V differential electrical bus as
the physical interface.
The rest of the layers of the ISO/OSI protocol stack are left to be implemented by the
system software developer. Higher Layer Protocols (HLPs) are generally used to implement the
upper five layers of the OSI Reference Model. HLPs are used to: standardize startup procedures
44

including bit rates used, distribute addresses among participating nodes or types of messages,
determine the structure of the messages, and provide system-level error handling routines.
The CAN communication protocol is a CSMA/CD protocol. The CSMA stands for
Carrier Sense Multiple Access, which means that every node on the network must monitor the
bus for a period of no activity before trying to send a message on the bus (Carrier Sense). Also,
once this period of no activity occurs, every node on the bus has an equal opportunity to transmit
a message (Multiple Access). The CD stands for Collision Detection, which means if two nodes
on the network start transmitting at the same time, the nodes will detect the ‘collision’ and take
the appropriate action. In CAN protocol, a non-destructive bitwise arbitration method is
utilized. This means that messages remain intact after arbitration is completed even if collisions
are detected. All of this arbitration takes place without corruption or delay of the higher priority
messages.
There are a couple of things that are required to support non-destructive bitwise
arbitration. First, logic states need to be defined as dominant or recessive, and second, the
transmitting node must monitor the state of the bus to see if the logic state it is trying to send
actually appears on the bus. CAN defines a logic bit ‘0’ as a dominant bit and a logic bit ‘1’
as a recessive bit.
A dominant bit state will always win arbitration over a recessive bit state, therefore the
lower the value in the Message Identifier (the field used in the message arbitration process), the
higher the priority of the message. As an example, suppose two nodes are trying to transmit a
message at the same time. Each node will monitor the bus to make sure the bit that it is trying to
send actually appears on the bus. The lower priority message will at some point try to send a
45

ecessive bit and the monitored state on the bus will be a dominant. At that point this node loses
arbitration and immediately stops transmitting. The higher priority message will continue until
completion and the node that lost arbitration will wait for the next period of inactivity on the bus
and try to transmit its message again.
3.3 CAN - Message-Based Communication
CAN is a message-based protocol, not an address-based protocol, which means that
messages are not transmitted from one node to another node based on addresses. Embedded in
the CAN message itself are the priority (Message Identifier) and the contents of the data being
transmitted. All nodes in the system receive every message transmitted on the bus and will
acknowledge if the message was properly received. It is up to each node in the system to decide
whether the message received should be immediately discarded or kept to be processed. A single
message can be destined for one particular node or many nodes to receive based on the way the
network and system are designed.
Another useful feature built into the CAN protocol is the ability for a node to request
information from other nodes. This is called a Remote Transmission Request (RTR), which
means that instead of waiting for information to be sent by a particular node, any receiver node
may request data to be sent to it from one source node. A Remote Frame is consequently
followed by a Data Frame containing the requested data.
One additional benefit of this message-based protocol is that additional nodes can be
added to the system without the necessity to reprogram all other nodes to recognize this addition.
46

This new node will start receiving messages from the network and, based on the message ID,
decide whether to process or discard the received information.
The CAN protocol defines five different types of messages or frames to perform
communication: Data Frame, Remote Frame, Error Frame, Overload Frame, and Interframe
space. Of these frames, the data and the remote frames need to be set by the user each time data
is transmitted on the bus. The other frames are set by the hardware part of CAN. The data
and the remote frames come in two frame formats: standard and extended. The standard format
has an 11-bit Message ID (Identifier), and the extended format has a 29-bit Message ID. The
roles of each frame type are summarized and listed in Table 3.1.
Table 3.1 Frame Types and Roles of Each Frame.
Frame Roles of Frame
Data Frame
Remote Frame
Error Frame
Overload Frame
Interframe
Space
3.3.1 Data Frames
This frame is used by the transmit unit to send a
message to the receive unit.
This frame is used by the receive unit to request
transmission of a message that has the same ID from the
transmit unit.
When an error is detected, this frame is used to notify
other units of the detected error.
This frame is used by the receive unit to notify that it
has not been prepared to receive frames yet.
This frame is used to separate a data or remote frame
from a preceding frame.
47
User
Settings
Necessary
Necessary
Unnecessary
Unnecessary
Unnecessary
The Data Frame is the most common type of frame and is used when a node transmits
information to any or all other nodes in the system. Data Frames consist of seven different bit
fields that provide additional information about the message as defined by the CAN

specification: Start-Of-Frame, Arbitration Field, Control Field, Data Field, CRC Field, ACK
Field, and End-Of-Frame. Figure 3.3 shows the format for a Standard CAN Data Frame. The
bit fields are defined as follows:
1 bit
Start-Of-Frame
Start-Of-FrameA single dominant bit marks the beginning of the Data Frame. The
CAN bus is in an idle (recessive) state prior to the transmission of this bit.
11 bits
Message Identifier
Arbitration
Field
1 bit
Remote Transmission Request
1 bit
1 bit
Identifier Extension
r0
Control
Field
4 bits
Data Length Code
0 – 8 bytes
Data Field
48
15 bits
CRC Sequence
CRC Field
1 bit
1 bit
Delimiter
Acknowledgement Slot
Figure 3.3 Standard CAN Data Frame Format [18].
1 bit
Delimiter
Ack
Field
Arbitration FieldThe Arbitration Field contains the Message Identifier Field and the
RTR bit. The Arbitration Field serves a dual purpose. It is used to determine which node
has access to the bus and to identify the type of data the message contains. The Message
Identifier is 11 bits long (for standard format) meaning that 2048 (2 11 ) unique messages
are possible. The lower the value of this field, the higher the priority of the message.
7 bits
End-Of-Frame
3 bits
Interframe Space

The RTR bit indicates whether the frame is a Data Frame or a Remote Frame and must be
dominant for a Data Frame.
Control FieldThe Control Field contains the Identifier Extension (IDE) bit (in an
Extended Data Frame the IDE bit resides in the Arbitration Field), a reserved bit (r0), and
the Data Length Code (DLC) bits. If the IDE bit is dominant, then the frame is a
Standard Format Data Frame, otherwise it is an Extended Format Data Frame. The
reserved bit, r0, is not used and should always be dominant. The number of bytes is
stored in the Data Length Code Field. This field typically holds values from zero to
eight. Since the field is four bits long, values greater than eight can be indicated. If the
value of the Data Length Code is greater than eight then it is assumed that the frame
contains eight bytes. Table 3.2 shows the Data Length Code and the number of data
bytes.
Table 3.2 Data Length Code Field
Number
Data Length Code (D=Dominant level, R=Recessive level)
of data bytes DLC3 DLC2 DLC1 DLC0
0 D D D D
1 D D D R
2 D D R D
3 D D R R
4 D R D D
5 D R D R
6 D R R D
7 D R R R
8 R D or R D or R D or R
Data FieldThe Data Field is the payload of the Data Frame. It contains from 0 to 8
bytes and is transmitted most significant bit first. It is the only field in the Data Frame
that does not have a fixed length.
49

Cyclic Redundancy Check (CRC) FieldThe CRC Field is 16 bits long. It consists of a
CRC Sequence (15 bits) followed by a CRC delimiter (1 bit). The receiver uses the value
in the CRC Sequence field to check if the data bit sequence in the frame was corrupted
during delivery. The CRC delimiter is always a recessive bit.
Acknowledgement FieldThe Acknowledgement Field is two bits long. It contains the
Acknowledgement Slot bit and the Acknowledgement Delimiter Bit. The node that
transmits the Data Frame sends these two bits recessively. The transmitter expects at
least one receiver to acknowledge receipt of the transmitted message. Any node that
receives the message without error will overwrite the Acknowledgement Slot bit with a
dominant bit. The Acknowledge Delimiter bit always remains recessive to distinguish a
positive acknowledgement from the start of an Error Frame. If no receiver acknowledges
a message, the transmitter will continue to try to send the message until the sending node
turns itself off.
End-Of-Frame and Interframe SpaceEvery Data Frame ends with a seven-bit End-Of-
Frame Field and a three-bit Interframe Space. The End-Of-Frame Field must be
transmitted recessively to mark a completely error-free transmitted frame. If the
Acknowledgement Delimiter bit or any of the End-Of-Frame bits are transmitted
dominantly then this marks the beginning of an Error or Overload Frame. The Interframe
Space represents the minimum amount of spacing between adjacent Data or Remote
Frames. All three bits must be transmitted recessively. The bus may continue to remain
idle after this, or a new frame will be indicated with the dominant Start-Of-Frame bit. If
50

one of the first two bits of this field is dominant then it is assumed an Overload Frame
has begun.
The Extended Format Data Frame is nearly identical to the Standard Format Data Frame
(Figure 3.3). The only differences between these two formats are found in the IDE bit in the
Arbitration Field for an Extended Data Frame (in a Standard Data Frame the IDE bit resides in
the Control Field), and the size and arrangement of the Arbitration Field. Both the Standard Data
Frame Format and the Extended Data Frame Format can coexist in the same CAN system.
The rule is that Standard Data Frames always have priority over the Extended Data Frames.
Figure 3.4 shows the format for an Extended CAN Data Frame. The following is a description
of the Arbitration and Control Fields:
1 bit
Start-Of-Frame
11 bits
Standard Message Identifier
1 bit
Substitute Remote Request
Arbitration Field
1 bit
Identifier Extension
18 bits
Extended Message Identifier
1 bit
Remote Transmission Request
1 bit
r1
1 bit
r0
Control
Field
4 bits
Data Length Code
51
0 – 8 bytes
Data Field
15 bits
CRC Sequence
CRC Field
1 bit
Delimiter
Acknowledgement Slot
Figure 3.4 Extended CAN Data Frame Format [18].
1 bit
1 bit
Delimiter
ACK
Field
7 bits
End-Of-Frame
3 bits
Interframe Space

Arbitration FieldThe Arbitration Field in the Extended Format Data Frame is longer to
accommodate the 29-bit Message Identifier. Over 536 million (2 29 ) unique messages are
possible using the Extended Format. The Standard Message Identifier is identical to the
Message Identifier Field in the Standard Data Frame Format. It is 11 bits long and
contains the most significant bits of the 29-bit identifier. The Substitute Remote Request
Field (SRR) bit replaces the RTR bit in the Standard Data Frame. Its sole purpose is to
be a placeholder so that the Identifier Extension bit remains in the same location as it is in
the Standard Data Frame Format. This bit is always transmitted recessively. The RTR
bit for the Extended Data Frame Format has been moved to the end of the Arbitration
Field. If the IDE bit is recessive, then the frame is an Extended Data Frame Format
otherwise the frame is a Standard Data Frame Format. The Extended Message Identifier
Field adds another 18 bits on to the Standard Message Identifier. This brings the total
number of identifier bits to 29. The RTR bit in an Extended Data Frame Format is
identical to the RTR bit in the Standard Data Frame Format. It indicates whether the
frame is a Data Frame or a Remote Frame. This bit value will be a dominant (‘0’) bit for
a Data Frame and a recessive (‘1’) bit for a Remote Frame.
Control FieldThe Control Field in the Extended Data Frame Format contains two
reserved bits and the DLC bits. The reserved bits, r1 and r0, are unused and must be
transmitted dominantly. The DLC bits in an Extended Data Frame are identical to those
used in a Standard Data Frame.
52

3.3.2 Remote Frames
Remote Frames are used for receivers to request information from another node. Remote
Frames are often sent out on a regular schedule to request updates from sensors. The Remote
Frame is the same as a Data Frame with two exceptions: in a Remote Frame there is no Data
Field, and contrary to a Data Frame where the RTR bit is always transmitted dominantly (RTR =
‘0’), the RTR bit of a Remote Frame is recessive (RTR = ‘1’). The RTR bit is considered part of
the bitwise arbitration, so a Data Frame will always win arbitration in the unlikely event that
both a Data Frame and a Remote Frame with the same Message Identifier are being transmitted
at the same time. This is due to the dominant RTR bit following the Message Identifier. This is
reasonable since a request for data should not take precedence over the data being requested.
Figure 3.5 shows the structure of the Remote Frame for both Standard Data Frames and
Extended Data Frames.
53

SOF
SOF
Bit 28
Bit 27
Arbitration field Control field CRC field
(Standard) ID
DLC Sequence
…
Bit 19
Bit 18
RTR
IDE
r0
Bit 3
MSB (first bit transmitted) LSB
(Standard) ID
Bit 28
Bit 27
…
Bit 19
Bit 18
SRR
54
Bit 2
Bit 1
Arbitration field Control field CRC field
IDE
(Extended) ID
Bit 17
Bit 16
…
Bit 1
Bit 0
RTR
r1
r0
Bit 0
Bit 14
Bit 13
…
DLC Sequence
Bit 3
Bit 2
Bit 1
Bit 0
Bit 14
Bit 13
MSB (first bit transmitted)
Figure 3.5 Standard and Extended Remote Frame Structures.
3.3.3 Error Frames
…
Bit 1
Bit 0
Bit 1
Bit 0
Delimiter
Receivers send out Error Frames whenever they detect that a frame contains an error.
The Error Frame (transmitted by the hardware part of CAN) can be sent during any point of a
transmission and is always sent before a Data Frame or Remote Frame has completed
successfully. The transmitter constantly monitors the bus while it is transmitting. When the
transmitter detects the Error Frame, it aborts the current frame and prepares to resend once the
bus becomes idle again. Figure 3.6 shows the structure of the Error Frame.
Delimiter
LSB

Figure 3.6 Structure of the Error Frame [19].
From Figure 3.6, the Error Frame contains the following fields: Error Flag and Error
Delimiter Field. The Error Frame deliberately violates the bit stuffing rule (See Section 3.4
Error Detection and Handling – Stuff Error) by sending either six recessive bits or six dominant
bits in the Error Flag Field. The determination of whether the Error Flag is recessive or
dominant depends on the Error State of the node. There are two types of error flags: Active-error
and Passive-error flags. The Active-error flag consists of six consecutive ‘dominant’ bits and is
output by a node in an error-active state that detected an error. The Passive-error flag consists of
six consecutive ‘recessive’ bits unless it is overwritten by ‘dominant’ bits from other nodes. This
error flag is output by a node in an error-passive state when it detects an error. Depending on the
timing at which an error is detected by each node connected to the bus, error flags may overlap
one on top of another, up to 12 bits in total length. The Error Delimiter field is a sequence of
eight ‘recessive’ bits and indicates the end of the frame. After transmission of an Error Flag,
each node sends ‘recessive’ bits and monitors the bus until it detects a ‘recessive’ bit.
55

Afterwards it starts transmitting seven more ‘recessive’ bits. The bus will then enter an idle state
or a new Data Frame or Remote Frame will start.
3.3.4 Overload Frame
The Overload Frame can be considered a special form of the Error Frame. It is used to
ask a transmitter to delay further frames or to signal problems with the Interframe Space. The
Overload Frame has the same format as the Error Frame, but unlike the Error Frame it does not
cause the retransmission of the previous frame. If the Overload Frame is being used to delay
further transmissions on the bus, then no more than two Overload Frames can be generated
successively. Figure 3.7 shows the structure of the Overload Frame.
An Overload Frame includes a Flag Field that contains a sequence of six ‘dominant’ bits
followed by a Delimiter Field, a series of eight ‘recessive’ bits. Depending on timing of the
Error Flag, Overload Flags may overlap one on top of another up to 12 bits in total length. When
one node sends out an Overload Flag, all of the nodes on the network detect it and send out their
own Overload Flags, effectively stopping all message traffic on the CAN bus. Then, all of the
nodes listen for the sequence of eight ‘recessive’ bits. The maximum amount of time needed to
recover in a CAN network after an Overload Frame is 31 bit times (Overload Flag (6 bit times)
+ Overlapping of Overload Flag (6 bit times) + Overload Delimiter (8 bit times) + Intermission
(3 bit times) + Suspend Transmission (8 bit times) = 31 bit times max).
56

3.3.5 Interframe Space
Figure 3.7 Structure of the Overload Frame [19].
This frame is used to separate the Data and Remote Frames. The Data and the Remote
Frames, whichever frame (Data, Remote, Error, or Overload Frame) may have been transmitted
prior to them, are separated from the preceding frame by an inserted Interframe Space.
However, no Interframe Spaces are inserted preceding Overload and Error Frames. Figure 3.8
shows the structure of the Interframe Space for nodes that are not ‘error-passive’ or have been
the receiver of the previous message. For ‘error-passive’ nodes which have been the transmitter
of the previous message, there is an extra bit field called Suspend Transmission. This structure is
shown in Figure 3.9.
Figure 3.8 Structure of the Interframe Space (non error-passive nodes) [19].
57

Figure 3.9 Structure of the Interframe Space (error-passive nodes) [19].
The Intermission bit field consists of 3 ‘recessive’ bits. If a dominant level is detected
during an Intermission, an Overload Frame must be transmitted. However, if the third bit of an
Intermission is of a ‘dominant’ level, the Intermission is recognized as the Start-Of-Frame. The
Bus Idle bit field may be of arbitrary length. The bus is recognized to be free and any node
having something to transmit can access the bus and start sending a message. Similar to the
Intermission bit field, the detection of a ‘dominant’ bit on the bus is interpreted as a Start-Of-
Frame. For error-passive nodes which have been the transmitter of the previous message, there
is an extra bit field called Suspend Transmission. This field consists of eight ‘recessive’ bits
following the Intermission bit field [20]. This bit field is included in only an Interframe Space if
the immediately preceding message transmitting node was in an error-passive state.
3.4 Error Detection and Handling
Error detection and error handling are important for the performance of CAN. Because
of complementary error detection mechanisms, the probability of having an undetected error is
small. The Data Link Layer in CAN systems is very efficient in detecting errors. Every frame
is simultaneously accepted by every node in the network or rejected by every node. If a node
detects an error it transmits an error flag to every other node in the network and destroys the
transmitted frame. The CAN protocol supports five defined error conditions: Bit Error, Form
58

Error, CRC Error, Acknowledge Error, and Stuff Error. A summary of these error checking
methods is provided in Table 3.3.
Bit ErrorEvery transmitting node monitors its own messages as it transmits them
across the bus, checking the bits in each frame for errors. A transmitting node always
reads back the message as it is sending [21 – 22]. The node will detect a Bit Error if it
sends out a dominant bit when it was supposed to transmit a recessive bit, or a recessive
bit when the message called for a dominant bit. Also, if the bit is not part of the
Arbitration Field or Acknowledge Slot, a Bit Error has been detected. At this point, an
Error Frame is generated and the original message is then resent after a proper
intermission time.
Form ErrorThe first bit in every frame must always be a dominant bit. If any node in
the network detects a dominant bit in one of the following four segments of the message:
End-Of-Frame, Interframe Space, Acknowledge Delimiter, or CRC Delimiter, a Form
Error has occurred. An Error Frame is then generated and the original message is then
resent later after a proper intermission time.
CRC ErrorCyclic redundancy checking is a very effective method of looking for errors
in a network by applying a polynomial equation to a block of transmitted data. The
transmitting node calculates a 15-bit CRC value according to the polynomial Gxin Equation 3.1. The CAN bus applies a CRC-15 with a hamming distance of D 6 for
8 byte information data packets. All nodes on the network receive this message, calculate
their own CRC and verify that the CRC values match. If the values do not match, a CRC
59

error occurs, an Error Frame is generated by the receiving node, and the message is then
resent later after a proper intermission time.
15 14 10 8 7 4 3
G x x x x x x x x 1
(3.1)
Acknowledge ErrorIn the ACK bit field of a message, the transmitting node checks if
the ACK bit slot, which is sent as a ‘recessive’ bit, contains a ‘dominant’ bit. A
‘dominant’ bit implies at least one node correctly received the message. A ‘recessive’ bit
means no node received the message and an ACK Error occurs. An Error Frame is
generated by the original transmitting node, and the original message is then resent later
after a proper intermission time.
Stuff ErrorReceiving nodes check for a violation of the bit stuffing rule. The final
method of error detection uses the bit stuffing rule where after five consecutive bits of the
same logic level, if the next bit is not a complement, an error is generated. Bit stuffing by
the transmitter ensures that rising edges are available for on-going synchronization of the
network. Bit stuffing also ensures that a stream of bits is not mistaken for an error frame
or the seven-bit interframe space that signifies the end of a message. Stuffed bits are
removed by a receiving node’s controller before the data is forwarded to the application.
If there are more than five bits of the same polarity in a row, a bit of the opposite polarity
is automatically stuffed into the data stream. This will be used by the receiving nodes for
synchronization, but ignored for data purposes. If between the Start-Of-Frame and the
CRC Delimiter, six consecutive bits with the same polarity are detected, a Stuff Error has
occurred. An Error Frame is then generated by the receiving node, and the original
message is then resent later after a proper intermission time.
60

Table 3.3 Types of Errors [19].
Type of Error Content of Error Target Frame (field) in which errors detected Unit by which
errors
Bit Error This error is detected when
the output level and the data
level on the bus do not match
when they are compared.
Form Error This error is detected when an
illegal format is found in any
fixed-format bit field.
CRC Error This error is detected if the
CRC calculated from the
received message and the
value of the received CRC
sequence do not match.
ACK Error This error is detected if the
ACK slot of the transmit unit
is found recessive (i.e., the
error that is detected when
ACK is not returned from the
Stuffing
Error
receive unit).
This error is detected when
the same level of data is
detected for 6 consecutive
bits in any field that should
have been bit-stuffed.
3.4.1 Output Timing of an Error Frame
Data Frame (SOF to EOF)
Remote Frame (SOF to EOF)
Error Frame
Overload Frame
Data Frame (CRC Delimiter, ACK Delimiter,
EOF)
Remote Frame (CRC Delimiter, ACK
Delimiter, EOF)
Error Delimiter
Overload Delimiter
Data Frame (CRC sequence)
Remote Frame (CRC sequence)
Data Frame (ACK slot)
Remote Frame (ACK slot)
Data Frame (SOF to CRC sequence)
Remote Frame (SOF to CRC Sequence)
61
detected
Transmit unit
Transmit unit
Receive unit
Receive unit
Transmit unit
Receive unit
The node that detected an error condition outputs an Error Flag to notify other nodes of
the error. The Error Flag output at this time is either an Active-Error Flag or a Passive-Error
Flag depending on the node’s error status. The transmitting node resends the Data or Remote
Frame after it outputs an Error Frame. Table 3.4 shows the timing with which an Error Flag is
output.

Table 3.4 Error Flag Output Timing [19].
Type of Error Output Timing
Bit Error The Error Flag is output beginning with the bit that immediately follows the
Stuffing Error one in which an error was detected
Form Error
ACK Error
CRC Error The Error Flag is output beginning with the bit immediately following the
CRC field (ACK slot bit).
3.5 Fault Confinement and Error States
A major risk with any serial bus system is that a single defective node can shut down the
entire network. To deal with this, the CAN protocol is designed to automatically detect a
faulty node and disconnect it from the network. CAN requires two error counters for every
node, one to keep track of transmit errors and the other to keep track of receive errors. When a
transmission or reception error occurs, the respective counter is increased by a weighted value
depending upon the type of error and which node caused the error. For every successful
transmission or reception, the respective counter is decremented by one. Generally, if a node
recognizes that it is the source of the error then the counter is incremented by nine for receive
errors and eight for transmission errors. Otherwise, each counter is increased by one [18].
Detected errors are made public to all other nodes via Error Frames or Error Flags. The
transmission of an erroneous message is aborted and the frame is repeated as soon as the
message can again win arbitration on the network. Also, each node is in one of three error states,
Error-Active, Error-Passive or Bus-Off. Figure 3.10 shows a graphical representation of these
three error states.
62

3.5.1 Error-Active
Figure 3.10 CAN Bus Error States
An Error-Active node can actively take part in bus communication, including sending an
active-error flag, which consists of six consecutive dominant bits. The Error Flag actively
violates the bit stuffing rule and causes all other nodes to send an Error Flag, called the Error
Echo Flag, in response. An Active-Error Flag, and the subsequent Error Echo Flag may cause as
many as twelve consecutive dominant bits on the bus; six from the Active Error Flag, and zero
up to six more from the Error Echo Flag depending upon when each node detects an error on the
bus. A node is Error-Active when both the TEC and the REC are below 127. Error-Active is the
normal operational mode, allowing the node to transmit and receive without restrictions.
63

3.5.2 Error-Passive
A node becomes Error-Passive when either the TEC or REC is equal to or greater than
127. Error-Passive nodes are not permitted to transmit Active-Error Flags on the bus, but
instead, transmit Passive-Error Flags which consist of six recessive bits. If the Error-Passive
node is currently the only transmitter on the bus, then the passive error flag will violate the bit
stuffing rule and the receiving node(s) will respond with Error Flags of their own (either active
or passive depending upon their own error state). If the Error-Passive node in question is not the
only transmitter (i.e. during arbitration) or is a receiver, then the Passive-Error Flag will have no
effect on the bus due to the recessive nature of the error flag. When an Error-Passive node
transmits a Passive-Error Flag and detects a dominant bit, it must see the bus as being idle for
eight additional bit times after an intermission before recognizing the bus as available. After this
time, it will attempt to retransmit. These measures restrict nodes that have a higher than average
error rate so that they can’t interfere with communication across the bus.
3.5.3 Bus-Off
A node goes into the Bus-Off state when the TEC is greater than 255 (receive errors
cannot cause a node to go Bus-Off). This means that a faulty node will be turned off if it
transmits 32 consecutive messages with errors. In this mode, the node cannot send or receive
messages, acknowledge messages, or transmit Error Frames of any kind. This is how Fault
Confinement is achieved. There is a bus recovery sequence that is defined by the CAN
protocol that allows a node in a Bus-Off state to recover, return to Error-Active, and begin
64

transmitting again if the fault condition is removed [21]. The rest of the network will continue to
work even if a node is set to Bus-Off.
3.6 CAN Bit Timing Requirements
One beneficial feature of the CAN protocol is that the bit rate, bit sample point and
number of samples per bit are completely programmable by the system designer. This provides
the opportunity to optimize the performance of the network for a given application. Even if
minor errors in the configuration of the CAN bit timing do not result in immediate failure, the
performance of a CAN network can be reduced significantly if not properly tuned.
In many cases, the CAN bit synchronization will amend a faulty configuration of the
CAN bit timing to such a degree that only occasionally an Error Frame is generated. In the
case of arbitration however, when two or more CAN nodes simultaneously try to transmit a
frame, a misplaced sample point may cause one of the transmitters to become Error-Passive.
The analysis of such sporadic errors requires a detailed knowledge of the CAN bit
synchronization inside a CAN node and of the CAN nodes’ interaction on the CAN bus
[19].
3.6.1 CAN Bit Structure
The Nominal Bit Rate of any CAN network is uniform throughout and is given by:
f
NBT
65
1
(3.2)
t
NBT

where tNBT is the Nominal Bit Time (NBT). A bit is divided into four separate non-overlapping
time segments called SYNC_SEG, PROP_SEG, PHASE_SEG1, and PHASE_SEG2. These are
illustrated in Figure 3.11.
Figure 3.11 CAN Bit Segments [20] [23].
The sample point indicated in Figure 3.11 is the position of the actual sample point if a
single point per bit is selected. However, some CAN Controllers can also sample each bit
three times. In this case, the bit will be sampled three quanta in a row, with the last sample being
taken at the sample point indicated in Figure 3.11. The period of the NBT is the sum of the
segment durations:
t t t t t
(3.3)
NBT SYNC _ SEG PROP _ SEG PHASE _ SEG1 PHASE _ SEG2
Each of these segments is an integer multiple of a unit of time called a time quantum, t Q . The
duration of a time quantum is equal to the period of the CAN system clock, which is derived
from the microcontroller (MCU) system clock or oscillator by way of a programmable prescaler,
called the Baud Rate Prescaler (BRP).
The duration of the synchronization segment, SYNC_SEG, is not programmable and is
fixed at one time quantum. The duration of the other segments are programmable, either
individually or with two values, tSEG1 and SEG2
t where:
66

t t t
(3.4)
SEG1 PROP _ SEG PHASE _ SEG1
t t
(3.5)
SEG2 PHASE _ SEG2
The duration of the propagation time segment PROP_SEG may be between 1 and 8 time
quanta. The duration of the segment PHASE_SEG1 may be between 1 and 8 time quanta if one
sample per bit is selected and may be between 2 and 8 time quanta if three samples per bit are
selected. If three samples per bit are chosen, the most frequently sampled value is taken as the
bit value. The duration of segment PHASE_SEG2 must be equal to PHASE_SEG1, unless
PHASE_SEG1 is less than the Information Processing Time (IPT), in which case PHASE_SEG2
must be equal to the IPT. Table 3.5 summarizes the roles of each segment and the number of tQ
’s.
3.6.2 Synchronization Segment
For each CAN node, the nominal start of each bit is the beginning of the SYNC_SEG
segment. For nodes that are transmitting, the new bit value is transmitted from the beginning of
the SYNC_SEG segment. For receiving nodes, the start of the received bit is expected to occur
during the SYNC_SEG segment. Due to the propagation delay of the transmitted signal through
the physical interface to the bus and along the bus itself, the SYNC_SEG segment of receiving
nodes will be delayed with respect to the SYNC_SEG segment of the transmitting node(s). This
is illustrated in Figure 3.12. The actual delay will vary depending on the distance between the
transmitting and receiving nodes being considered.
67

Figure 3.12 Propagation Delay Between Nodes [23].
Segment Name
Table 3.5 Types of Segments and Their Roles [19].
Roles of Segment Number of t Q ’s
Synchronization Segment
(SYNC_SEG)
Propagation Time Segment
(PROP_SEG)
Phase Buffer Segment1
(PHASE_SEG1)
Phase Buffer Segment2
(PHASE_SEG2)
Resynchronization Jump
Width (RJW) (See Section
3.6.5)
Multiple units connected to the bus are timed
to be coincident during the interval of this
segment as they send or receive a frame. A
recessive to dominant or a dominant to
recessive transition edge is expected to exist in
this segment.
This segment absorbs physical delays on the
network, which include an output delay of the
transmit unit, a propagation delay of signal on
the bus, and an input delay of the receive unit.
The duration of this segment is twice the sum
of each delay time.
This segment is used to correct for errors when
signal edges do occur within SYNC_SEG.
This segment is used to correct for errors when
signal edges do occur within SYNC_SEG.
Since each unit is operating with their own
clock, even a minute clock error in each node
will accumulate. This segment absorbs such
an error. To absorb a clock error, add or
subtract within the Resynchronization Jump
Width (RJW) setup range for PHASE_SEG1
and PHASE_SEG2. The larger the values of
PHASE_SEG1 and PHASE_SEG2, the greater
the tolerance, but the communication speed
slows down.
Some units may get out of sync for reasons of
a drift in clock frequency or a delay in
transmission path. RJW is the maximum
width for which this out-of-sync is corrected.
68
1
1 – 8
1 – 8
PHASE_SEG1 or
IPT, whichever is
larger.
1 – 4 and
≤PHASE_SEG1
8-25 t Q ’s

3.6.3 Propagation Segment
The existence of the propagation delay segment, PROP_SEG, is due to the fact that the
CAN protocol allows for non-destructive arbitration between nodes contending for access to
the bus, and the requirement for in-frame acknowledgement. In the case of non-destructive
arbitration, more than one node may be transmitting during the arbitration field. Each
transmitting node samples data from the bus in order to determine whether it has won the
arbitration, and also to receive the arbitration field in case it loses arbitration. When each node
samples each bit, the value sampled must be the logical superposition of the bit values
transmitted by each of the nodes arbitrating for bus access. In the case of the Acknowledge
Field, the transmitting node transmits a recessive bit but expects to receive a dominant bit (i.e., a
dominant value must be sampled at the sample point(s)). The propagation delay segment,
PROP_SEG, exists to delay the earliest possible sample of the bit by a node until the transmitted
bit values from all the transmitting nodes have reached all of the nodes.
Figure 3.10 shows the propagation delay between two nodes, and shows that the bit value
transmitted by Node A is received by Node B after a time t Prop(A,B) , and the bit value transmitted
by Node B is received by Node A after a time t Prop(B,A) , before the end of Node A’s propagation
segment. This ensures that Node A will correctly sample the bit value. Node B will also
correctly sample the bit value, even although Node B’s sample point lies beyond the end of Node
A’s bit time, because of the propagation delay between Node A and Node B. Time t Prop(A,B)
consists of the sum of the propagation delay through Node A’s bus driver plus the propagation
delay along the bus from Node A to Node B plus the propagation delay through Node B’s bus
receiver:
69

3.6.4 Synchronization
t t t t
(3.6)
Prop A,B Tx A Bus A,B Rx B
All CAN nodes on a network must be synchronized while receiving a transmission
(i.e., the beginning of each received bit must occur during each nodes SYNC_SEG segment).
This is achieved by means of synchronization. Synchronization is required due to phase errors
between nodes which may arise due to nodes having slightly different oscillator frequencies or
due to changes in propagation delay when a different node starts transmitting. Two types of
synchronization are defined, hard synchronization and re-synchronization. Hard synchronization
is performed only at the beginning of a message frame, when every CAN node aligns the
SYNC_SEG of its current bit time to the recessive to dominant edge of the transmitted Start-Of-
Frame bit. Re-synchronization is subsequently performed during the remainder of the message
frame, whenever a change of bit value from recessive to dominant occurs outside of the expected
SYNC_SEG segment.
For CAN nodes which are transmitting, the value of a bit is transmitted on the CAN
bus at the start of the transmitting nodes SYNC_SEG segment, and the bit value is transmitted
until the end of the PHASE_SEG2 segment. All nodes which are active receive the data on the
bus (including transmitting nodes) and any changes in bit value are expected to occur during the
SYNC_SEG segment. If a recessive to dominant bit value transition is detected outside of a
receiving nodes SYNC_SEG segment, then that node will re-synchronize to the edge. If a
recessive to dominant bit value transition is detected after the SYNC_SEG segment, but before
the sample point, then this is interpreted as a late edge. The node will attempt to re-synchronize
70

to the bit stream by increasing the duration of its PHASE_SEG1 segment of the current bit by the
number of time quanta by which the edge was late, up to the re-synchronization jump width
limit. The effect of this is that the next sample point is delayed until it is the programmed
number of time quanta after the actual edge (if the required delay does not exceed the re-
synchronization jump width limit). Conversely, if a recessive to dominant bit value transition is
detected after the sample point but before the SYNC_SEG segment of the next bit, then this is
interpreted as an early bit. The node will now attempt to re-synchronize to the bit stream by
decreasing the duration of its PHASE_SEG2 segment of the current bit by the number of time
quanta by which the edge was early, by up to the re-synchronization jump width limit.
Effectively, the SYNC_SEG segment of the next bit begins immediately (if the edge is early by
no more than the re-synchronization jump width limit).
3.6.5 Re-Synchronization
The number of time quanta by which a bit period may be extended or shortened due to re-
synchronization is limited by a programmable value called the re-synchronization jump width
(RJW). The RJW must be programmed to a valid value. The RJW cannot exceed four time
quanta and it also must not exceed the number of time quanta in the PHASE_SEG1 segment.
The minimum value for the RJW is one time quantum.
In order to minimize the maximum time between recessive to dominant edges, and
maximize the number of opportunities for re-synchronization, the CAN protocol uses bit
stuffing. After every occurrence of five consecutive bits of equal value, an extra stuff bit of
71

opposite value is inserted into the bit stream. Bit stuffing is implemented in Data Frames and
Remote Frames, from the Start-Of-Frame bit to the end of the CRC field.
3.7 Oscillator Tolerance
Typically, the CAN system clock for each CAN node will be derived from a
different oscillator. The actual CAN system clock frequency for each node, and hence the
actual bit time, will be subject to a tolerance. Ageing and variations in ambient temperature will
also affect the initial tolerance. The CAN system clock tolerance is defined as a relative
tolerance:
f f
where f is the actual frequency and f N is the nominal frequency.
N
f (3.7)
f
N
To ensure effective communication, the minimum requirement for a CAN network is
that two nodes, each at opposite ends of the network with the largest propagation delay between
them, and each having a CAN system clock frequency at the opposite limits of the specified
frequency tolerance, must be able to correctly receive and decode every message transmitted on
the network. This requires that all nodes sample the correct value for each bit.
3.8 Propagation Delay
The minimum time for the propagation delay segment to ensure correct sampling of bit
values is given by:
tPROP_SEG tProp(A,B) tProp(B,A)
(3.8)
72

where nodes A and B are at opposite ends of the network (i.e. the propagation delay is a
maximum between nodes A and B). From Equation 3.6, this gives:
t 2 t t t
(3.9)
PROP_SEG Bus Tx Rx
where tBus is the propagation delay of the signal along the longest length of the bus between two
nodes, t Tx is the propagation delay of the transmitter part of the physical interface and tRx is the
propagation delay of the receiver part of the physical interface. If the propagation delay of the
transmitters and receivers on a network is not uniform, the maximum delay values should be
used in Equation 3.9.
The minimum number of time quantum that must be allocated to the PROP_SEG
segment is therefore:
PROP_SEG
PROP_SEG=ROUND_UP t
t
73
Q
(3.10)
where the function ROUND_UP() returns the argument rounded up to the next integer value [24
– 26].
3.9 Selection of Bit Timing Values
The selection of bit timing values involves consideration of various fundamental system
parameters. The requirement of the PROP_SEG value imposes a trade-off between the
maximum achievable bit rate and the maximum propagation delay, due to the bus length and the
characteristics of the bus driver circuit. The maximum achievable bit rate is also influenced by
the tolerance of the CAN clock source. The highest bit rate can only be achieved with a short
bus length, a fast bus driver circuit and a high frequency tolerance CAN clock source. In

many systems, the bus length will be the least variable system parameter which will impose the
fundamental limit on bit rate. However, the actual bit rate chosen may involve a trade-off with
other system constraints, such as cost [23].
3.9.1 Step-by-Step Calculation of Bit Timing Parameters
The following steps provide a method for determining the optimum bit timing parameters
which satisfy the requirements for proper bit sampling.
Step 1: Determine the minimum permissible time for the PROP_SEG segment. Obtain the
maximum propagation delay of the physical interface for both the transmitter and the
receiver from the manufacturer’s data sheet. Calculate the propagation delay of the bus
by multiplying the maximum length of the bus by the signal propagation delay of the
bus cable. Use these values to calculate t PROP_SEG using Equation 3.9.
Step 2: Choose the CAN System Clock Frequency. As the CAN system clock is derived
from the MCU system clock or oscillator, the possible CAN system clock
frequencies will be limited to whole fractions of the MCU system clock or oscillator by
the prescaler. The CAN system clock is chosen so that the desired CAN bus NBT
is an integer number of time quanta (CAN system clock periods) from 8 - 25.
Step 3: Calculate the PROP_SEG duration. From equation 3.10, the number of time quanta
required for the PROP_SEG segment is calculated. If the result is greater than eight, go
back to Step 2 and choose a lower CAN system clock frequency.
Step 4: Determine the Phase-Buffer-Segment quantities PHASE_SEG1 and PHASE_SEG2.
From the number of time quanta per bit obtained in Step 2, subtract the PROP_SEG
74

value calculated in Step 3 and subtract one tQ for SYNC_SEG. If the remaining
number is less than three then go back to Step 2 and select a higher CAN system
clock frequency. If the remaining number is an odd number greater than three then add
one to the PROP_SEG value and recalculate. If the remaining number is equal to three
then PHASE_SEG1 = 1 and PHASE_SEG2 = 2 and only one sample per bit may be
chosen. Otherwise divide the remaining number by two and assign the result to
PHASE_SEG1 and PHASE_SEG2.
Step 5: Determine the value of RJW. RJW is chosen as the smaller of four and PHASE_SEG1.
Step 6: Calculate the required oscillator tolerance from Equations 3.11 and 3.12.
2 f 10 tNBT tRJW
(3.11)
2 f 13 tNBT tPHASE_SEG2 MIN tPHASE_SEG1, tPHASE_SEG2
(3.12)
In the case of PHASE_SEG1 > 4 t Q , it is recommended to repeat Steps 2 through 6 with
a larger value for the prescaler (i.e. smaller tQ period, as this may result in a reduced
oscillator tolerance requirement). Conversely, if PHASE_SEG1 < 4 t Q , it is
recommended to repeat Steps 2 through 6 with a smaller value for the prescaler, as long
as PROP_SEG < 8, as this may result in a reduced oscillator tolerance requirement. If
the prescaler is already equal to one and a reduced oscillator tolerance is required, the
only option is to consider using a higher frequency for the prescaler clock source [27 –
29].
75

CHAPTER 4
THE CHALLENGES OF INTERFACING CAN AND 1 – WIRE® COMMUNICATION
4.1 The Need for the Interface
PROTOCOLS
With each passing year, an increasing number of electronic devices need to be
interconnected with an end goal of providing better system accuracy and added functionality
such as remote management and remote diagnostic and maintenance capabilities. At the
backbone of these automated and interconnected systems, there needs to be robust and reliable
communications. Both CAN and 1 – Wire® are serial bus protocols allowing the transfer of
data between master and slave devices. Having a transparent interface between the two
protocols would allow a system designer to take full advantage of the robustness and flexibility
of both technologies. Additionally, by combining the simplicity and cost of CAN-enabling a
device with the multitude of 1 – Wire® devices commercially available, the savings to a system
designer becomes two-fold: reduced complexity of wiring harnesses and increased features and
functionality of the overall system.
Just as CAN is emerging for use in medical equipment, 1 – Wire® devices are also
being used for medical consumable IDs such as medical sensors (ID and calibration), blood
glucose strips (calibration and authentication), and reagent bottles (ID). 1 – Wire® devices are
also ideally suited for use in test equipment and mobile machines. Examples include: PCB
76

Identification and Authentication and Accessory/Peripheral Identification and Control (See
Section 2.4.2 for more details). Again, combining CAN and 1 – Wire® would increase the
features and functionality of the overall system.
Although CAN is the dominant serial communication protocol preferred in the
automotive industry, 1 – Wire® devices are gaining popularity, especially with the emergence of
hybrid and all-electric vehicles and technologies. As the result of new developments on
experimental battery-powered electric vehicles, the need for fast information related to different
components and equipment emerges, especially data related to battery life and knowledge about
the overall system efficiency [30]. Battery monitoring systems for electric vehicles is one of the
biggest uses of 1 – Wire® devices in the automotive industry. Most applications use the
DS2436, a battery ID and monitor chip, to allow voltage and temperature monitoring of all
batteries. This allows early detection of problems or failures in individual batteries. Another
application of iButtons in the automotive industry is the vehicle black box. Like that found in
commercial airliners, the Road Safety On-Board Computer System is a new car device that
monitors speed, braking, turns, and just about everything else. It is designed to show you just
what kind of driver you are. Before the engine will start, you have to log on with an iButton
that tells the car who you are and from that point on, every move you make is strictly on the
record. Combining the simplicity of CAN-enabling a device and application-specific 1 –
Wire® devices such as the DS2436 and other function-specific 1 – Wire® devices, a system
designer will be able to design a reliable, rugged, and functionally diverse network for almost
any application.
77

In June 2004, Maxim Integrated Products introduced the DS2482-X00 I 2 C-to-1 – Wire®
interface devices, bridging a multi-master communication protocol with a single master
communication protocol. The DS2482-X00 is an I 2 C-to-1 – Wire® line driver with one
(DS2482-100) or eight (DS2482-800) channels of independently operated 1 – Wire® I/O ports.
The DS2482 is an I 2 C-to-1 – Wire® bridge device that interfaces directly to standard (100 kHz
max) or fast (400 kHz max) I 2 C masters to perform bidirectional protocol conversion between
the I 2 C master and any downstream 1 – Wire® slave devices. Relative to any attached 1 –
Wire® slave device, the DS2482 is a 1 – Wire® Master. I 2 C is appropriate for peripherals where
simplicity and low manufacturing cost are more important than speed. Some common
applications include: reading hardware monitors and diagnostic sensors, like a CPU thermostat
and fan speed; reading real-time clocks; and turning on and turning off the power supply of
system components. Peripherals can also be added or removed from the I 2 C bus while the
system is running, just like 1 – Wire® devices, which makes it ideal for applications that require
hot swapping of components [13 – 15]. Combining the diverse functionality of 1 – Wire®
devices with the simplicity and low manufacturing cost of I 2 C, reduces the wiring complexity of
any system down to just two wires and gives the system designer greater application diversity.
4.2 Applications
Of the many commercial markets that could potentially benefit from the interfacing of
CAN and 1 – Wire® technologies, two of the most rapidly emerging markets, wearable sensor
technology and automotive electronics and sensors would benefit the most. Other applications
and markets that could benefit include hybrid mining and construction equipment, mobile and
78

stationary agricultural equipment, nautical machinery, textile machines, and other special-
purpose machinery such as production lines and machine tools.
Paralleling the growth in automobile electronics is the increasing number of electronic
control systems being used in vehicles with each new production year. This growth is partly due
to the customer’s wish for better safety and greater comfort and also partly due to the
government’s requirements for improved emission control and reduced fuel consumption. The
complexity of the functions implemented in these systems necessitates an exchange of data
between them. With conventional systems, data is exchanged by means of dedicated signal
lines, but this is becoming increasingly difficult and expensive as control functions become ever
more complex, and the use of dedicated connections does not scale as the number of electronic
control systems in each vehicle continues to increase. In the case of complex control systems
(such as Motronic) in particular, the number of connections cannot be increased much further.
To consider future developments aimed at overall vehicle optimization, it becomes
necessary to overcome the limitations of conventional control device linkage. This can only be
done by networking the system components using a serial data bus system. In the near future,
serial communication will also be used in mobile communication in order to link components
such as car radios, car telephones, navigation aids etc. to a central, ergonomically designed
control panel. The functions defined in the Prometheus project [31], such as vehicle-to-vehicle
and vehicle-to-infrastructure communication will depend largely on serial communication.
Whereas some of these devices and functions can only be implemented via CAN, the vast
majority can be accomplished with the use of both CAN and 1 – Wire® inter-communications.
79

Wearable sensor technology is a new application emerging recently in the medical field
that would benefit from a merger of CAN and 1 – Wire® protocols. Wearable devices can be
widely used in clinical care, home health care, hospice, special people monitoring, elderly care
and assistance, psychological evaluation, physical training and many other medical areas.
Wearable technology may provide an integral part of the solution for providing healthcare to a
growing world population that will be strained by a ballooning ageing population. By providing
a means to conduct telemedicine – the monitoring, recording, and transmission of physiological
signals from outside of the hospital – wearable technology solutions could ease the burden on
health-care personnel and use hospital space for more emergent or responsive care. In addition,
employing wearable technology in professions where workers are exposed to dangers or hazards
could help save their lives and protect health-care personnel [32]. In addition to providing a
rugged, reliable communications backbone, combining the ability and ease of CAN-enabling
an electrical device or component with the variety of 1 – Wire® devices used for medical
consumable IDs would provide an almost unlimited type and number of body measurements,
movements, and functions that could be monitored by wearable sensor technology and medical
devices.
4.3 Challenging Problems
In designing a custom interface merging two communication protocols, a number of
potentially challenging, technical problems had to be addressed such as combining a multi-
master and a single-master protocol, messages by IDs and messages by addressing, event-
80

triggered and time-triggered control paradigms, timing performance in relation to potential
latencies, and possible communication speed differences.
4.3.1 Multi-Master to Single Master
Bridging a multi-master and a single-master communication protocol might seem a bit
daunting at first to a systems design engineer. However, communication protocols supporting
more than one master have an arbitration scheme in place that is either controlled in hardware or
by software. Examples of communication protocols that contain provisions for multiple masters
include: I 2 C, SPI [33 – 35], and CAN. Communication protocols such as Local
Interconnect Network (LIN), 1 – Wire®, and Joint Test Action Group (JTAG) support only a
single master and therefore need no arbitrator or bus arbitration scheme to help with
communication conflicts.
Bus arbitration provides a method for resolving bus control conflicts and assigning
priorities to the requests for control of the bus. It is needed to resolve conflicts when two or
more devices want to become the bus master at the same time. In short, arbitration is the process
of selecting the next bus master from among multiple candidates. Traditionally, a single
arbitrator schedules communication between one or more bus masters and bus slaves. If multiple
masters attempt to access the bus, the arbitrator allocates bus resources to a single master based
on a fixed set of arbitration rules [36]. Although there are many different types of arbitration
schemes employed in both hardware and software, conflicts can be resolved based on fairness or
priority in centralized or distributed mechanisms.
81

In traditional bus architectures, one or more bus masters and bus slaves connect to a
shared bus, and when multiple masters attempt to access the bus at the same time, the arbiter
allocates the bus resources to a single master, forcing all other masters to wait. One shortcoming
of this method is that access to the shared system bus becomes the bottleneck for data
throughput. Since only one master has access to the bus at a time, this means that other masters
are forced to wait and only one slave can transfer data at a time [37].
In centralized arbitration schemes, a single arbiter is used to select the next master. A
simple form of centralized arbitration uses a bus request line, a bus grant line, and a bus busy
line. Each of these lines is shared by potential masters, which are daisy-chained in a cascade as
shown in Figure 4.1 [38].
Figure 4.1 Centralized arbiter in a daisy-chain scheme [38].
In Figure 4.1, each of the potential masters can submit a bus request at any time. A fixed
priority is set among the masters from left to right. When a bus request is received at the central
bus arbiter, it issues a bus grant by asserting the bus grant line. When the potential master that is
closest to the arbiter (Potential Master 1) sees the bus grant signal, it checks to see if it had made
a bus request. If yes, it takes over the bus and stops propagation of the bus grant signal any
further [38]. If it has not made a request, it will simply pass the bus grant signal to the next
82

master to the right (Potential Master 2), and so on. When the transaction is complete, the busy
line is deasserted.
Instead of using shared request and grant lines, multiple bus request and bus grant lines
can be used. In one scheme, each master will have its own independent request and grant line as
shown in Figure 4.2. The central arbiter can employ any priority-based or fairness-based
tiebreaker. Another scheme allows the masters to have multiple priority levels. For each priority
level, there is a bus request and a bus grant line. In this scheme, each device is attached to the
daisy chain of one priority level. If the arbiter receives multiple bus requests from different
levels, it grants the bus to the level with the highest priority. Daisy chaining is used among the
devices of that level. Figure 4.3 shows an example of four devices included in two priority
levels. Potential Master 1 and Potential Master 3 are daisy-chained in level 1 and Potential
Master 2 and Potential Master 4 are daisy-chained in level 2.
Figure 4.2 Centralized arbiter with independent request and grant lines [38].
83

Figure 4.3 Centralized arbiter with two priority levels (four devices) [38].
In decentralized arbitration schemes, priority-based arbitration is usually used in a
distributed fashion without the need of a central arbiter as shown in Figure 4.4. Each potential
master has a unique arbitration number, which is used in resolving conflicts when multiple
requests are submitted [38]. A device that wants to become a bus master first asserts the bus
Request Level line, and then it checks if the bus is busy. If the Bus Busy line is not asserted,
then the device sends a “0” to the next higher numbered device on the daisy chain, asserts the
Bus Busy line, and de-asserts the Request Level line. If the bus is busy, or if a device does not
want the bus, then it simply propagates the bus grant to the next device.
Figure 4.4 Decentralized bus arbitration [38].
84

CAN is a serial bus protocol with multi-master capabilities allowing all nodes to
transmit data and multiple nodes to request access to the bus simultaneously. Arbitration is
required if more than one node is accessing the bus. The bus arbitration method used in CAN
is called Carrier Sense Multiple Access with Collision Detection and Arbitration on Message
Priority (CSMA/CD + AMP), and works as follows. While the bus is idle, a “hard
synchronization” on the Start-Of-Frame (SOF) bits transmitted by those nodes attempting to
write to the bus occurs, after which each of these nodes sends the bits of its message identifier
and monitors the bus level. Per definition, bits with a dominant value (zero) overwrite those with
a recessive value (one). If, at some point, node i sends a recessive bit but reads back a dominant
bit, then the message identifier of some other transmitting node has a lower binary value and
therefore a higher priority than node i’s message. Node i therefore loses the arbitration and
switches to listening-only mode. At the conclusion of this process, the node with the highest-
priority message wins the arbitration and this message has been broadcast to the other nodes
[39].
Slave-side arbitration moves the arbitration logic close to the slave, such that the
algorithm determines which master gains access to a specific slave in the event that multiple
masters attempt to access the same slave at the same time. Some of the benefits associated with
this arbitration scheme include: eliminating the need to create arbitration hardware manually,
allowing multiple masters to transfer data simultaneously to different slaves, and providing
configurable arbitration settings thus allowing arbitration for each slave to be specified
independently.
85

For the initial prototype design presented here, the CAN bus arbitration method will be
used to resolve multi-master conflicts on the bus and also provide bidirectional protocol
conversion between CAN and 1 – Wire® devices. For a larger system, having more CAN
nodes and 1 – Wire® devices, other arbitration schemes such as slave-side arbitration would
merit further exploration. This would especially be true for systems where safety-critical and
real-time data throughput is a requirement and also when large amounts of data needs to be
transferred among many CAN nodes and 1 – Wire® devices.
4.3.2 Message IDs vs. Addresses
In bridging two different communication protocols such as CAN and 1 – Wire®, how
to handle converting between message IDs (CAN) and message addresses (1 – Wire®) is a
problem that must be addressed. In a system based upon message IDs, masters broadcast
messages with IDs. All slaves are required to decode the message ID to determine if it is the
intended recipient. For an address-based system, each slave has a unique address, and every
transfer includes the specific address of a slave. Generally, the address is decoded by all slaves
and the intended slave accepts the message and all others reject the message.
One possible way to bridge these two types of systems would be the addition of a simple
PIC® microcontroller to each CAN node. Another way of addressing this problem would be
to use message acceptance filters and masks (typically built-in on CAN Controllers) on each
individual CAN node. A third possible solution would be to use the reserved bits of the
CAN extended identifier field (r0 and r1) as part of an initial address assignment process [40].
86

A final proposed method is based upon an automatic node discovery process to identify
nonconfigured CAN nodes directly in a CANopen® system [41].
Every CAN node in the prototype system described in this dissertation consists of the
following components: Microchip PIC12CE674 [42] microcontroller, Microchip MCP2515
stand-alone CAN Controller [43 – 44], and a Microchip MCP2551 high-speed CAN
transceiver [45]. A simplified block diagram of the CAN components on each node is shown
in Figure 4.5. The use of the PIC® microcontroller allows each node to have a unique address,
stored in EEPROM, so a number of different devices can coexist on the same network. This
would allow communication from a 1 – Wire® device (message by address) to a specific CAN
node which would have a unique address on the CAN network. By storing the node address in
EEPROM, this allows the node to not only be re-addressed if the addition of more nodes on the
CAN bus is required, but also ensures that the node address value is retained in the event of
power loss.
Message IDs must be unique on a single CAN bus, otherwise two nodes would
continue transmission beyond the end of their arbitration field (ID) causing an error (see Figures
3.3 and 3.4). The choice of IDs for messages is often done simply on the basis of identifying the
type of data and the sending node; however, as the message ID is also used as the message
priority, this can lead to poor real-time performance. For example, consider an 11-bit ID CAN
network, with two nodes with IDs of 31 (binary representation, 00000011111) and 32 (binary
representation, 00000100000). If these two nodes transmit at the same time, each will transmit
the first five zeros of their ID with no arbitration decision being made. When the sixth bit is
transmitted, the node with the ID of 32 transmits a ‘1’ (recessive) for its ID, and the node with
87

the ID of 31 transmits a ‘0’ (dominant) for its ID. When this happens, the node with the ID of 32
will realize that it lost its arbitration, and allow the node with ID of 31 to continue its
transmission. This ensures that the node with the lower bit value will always win the arbitration.
So to summarize, with properly configured message acceptance filters and masks, messages sent
from the 1 – Wire® Master will be properly directed to the appropriate CAN node.
Figure 4.5 CAN node components simplified block diagram [45 – 47].
By configuring hardware acceptance filters in the CAN Controller on each node, this
reduces the probability of data overrun conditions on any one CAN node. The number of
acceptance filters varies with different CAN Controllers and manufacturers. If properly
configured for each CAN node, the acceptance filters could be used as a method of allowing
only certain types of messages to be accepted by each individual CAN node. While receiving
a CAN message, the identifier (and sometimes even the data) can be compared to a configured
filter. Only if the incoming message matches the filter does the message get stored into a receive
buffer on that particular CAN node. Thus it is possible to reduce the processing load of the
host controller. Typically on a CAN Controller the message acceptance filter is controlled by
two 8 – bit wide registers: usually named Acceptance Code Register (ACR) and Acceptance
Mask Register (AMR). The eight most significant bits of the identifier of the CAN message
88

are compared to the values contained in these registers; see example below and also Figure 4.6.
Thus always groups of eight identifiers can be defined to be accepted for any node.
Example: MSB LSB
The Acceptance Code Register (ACR) contains: 0 1 1 1 0 0 1 0
The Acceptance Mask Register (AMR) contains: 0 0 1 1 1 0 0 0
Messages with the following 11 – bit identifiers are accepted 0 1 x x x 0 1 0 x x x
(x = don’t care) ID.10 ID.0
Figure 4.6 CAN Node Message Acceptance Filtering [48].
At the bit positions containing a “1” in the AMR, any value is allowed in the composition
of the identifier. The AMR defines the bit positions, which are relevant for the comparison (0 =
relevant, 1 = not relevant). The same is valid for the three least significant bits. Thus 64
different identifiers are accepted in this example. The other bit positions must be equal to the
values in the ACR. For accepting a message all relevant received bits have to match the
respective bits in the ACR. Although using acceptance filters and acceptance masks does not
provide a CAN node with a physical address, it does however provide a means to limit what
types of messages and how many will be received into an individual CAN node’s receive
buffers.
89

Recently, a technique has been proposed to use two reserved bits of the CAN extended
data frame identifier field as part of an initial address assignment process [40]. The CAN
protocol has two reserved bits in the Control Field for future expansion and/or modifications to
the existing protocol. CAN 2.0B specification requires a transmitting node to transmit these
reserved bits as zeros (dominant state). However, when a receiving unit receives the message, it
will ignore the state of these two bits. The method proposed in [40] is to use these reserved bits
to represent the address claim status of a CAN node as shown in Table 4.1.
Table 4.1 Address claim status and reserved bits [40].
Reserved bits Meaning
00 Address Acquired (Normal Tx)
01 Address Assignment Pending
10 Address Claim Override
11 Reserved
Additionally, the CAN Controller for each node should be modified as shown in Figure
4.7 to include an additional unit for address claim. This unit should include special registers
which will contain the highest priority of the message that will be transmitted from the node and
node address. A timing control unit is also required for monitoring the address claim timeout
and a priority resolving unit will resolve address claim contentions.
Figure 4.7 Address Claim Unit [40].
90

Whenever a new CAN node is added to the network and powered up, it should wait for
a random amount of time and transmit a message with an address assignment pending status
(Reserved bits = 01). The CAN Controller should start claiming addresses from zero and the
message transmitted should have the highest priority CAN message ID which is stored in the
Highest Priority ID register.
The Address Claim Unit should monitor the CAN bus for the successful transmission
of an address claim message. If there is a bus error which prevents this message from being
successfully transmitted then the node should wait for a random amount of time before
attempting retransmission (i.e., automatic retransmission disabled). After a successful
transmission of an address claim message, the CAN node should monitor the bus for the
response from other CAN nodes possibly having the same source address. If the CAN node
does not receive a response within a specified amount of time, it can assume that it has
successfully claimed the address. If it receives a message from another CAN node with the
same source address, then the address status bits are checked. If the status bits indicate an
address claim override and the newly received CAN ID has an equal or higher priority than the
new CAN node, then the new node will try to claim the next available valid address. If the
override/normal Tx message comes from a lower priority CAN ID, then the address claim
message is retransmitted with override information so the other CAN node will release its
address. The CAN node should continuously monitor the data bus to check for address claim
messages and if any CAN node has the same address as its own, take appropriate action.
The above procedure will result in a sequential address assignment to networked CAN
nodes. For example, if there are 25 CAN nodes at the start of the first address claim
91

procedure, then the address claim process will result in addresses being assigned from zero to 24.
If a new higher priority node is added to the CAN bus at a later time, all of the existing 25
CAN nodes will be bumped off to a lower priority address resulting in a complete
reassignment of CAN node addresses. This problem can be avoided by reserving some
addresses at regular intervals. These addresses can be claimed by the CAN nodes only if they
are being bumped out of a valid address claimed status and cannot be claimed during the initial
configuration [40]. The reader is referred to [40] for a complete state machine diagram of the
address claim process.
The last proposed method to solve the issue of bridging message ID-based and address-
based protocols such as CAN and 1 – Wire® would require that the PIC® microcontroller and
CAN Controller used in the prototype system be CANopen® compliant. One of the biggest
challenges in developing the hardware for a CANopen® compliant node can be selecting the
right part, as some 20 chip manufacturers produce microcontrollers with CANopen® compliant
CAN interfaces.
CANopen® is a CAN - based higher layer application protocol conceived for process
control and automated manufacturing environments that, at present, is knowing widespread
diffusion all over the world and, in particular, in the European countries. CANopen® requires
that each device in the network be assigned a unique node address (Node – ID) before the normal
operations are started. To this extent, the CANopen® specifications provide a means to remotely
configure the addresses of the slave devices attached to the CAN bus. This technique,
however, requires that each device has to be connected separately to a configuration tool.
CANopen®, in fact, does not have a mechanism to identify, in an efficient and reliable way, the
92

nodes that do not have an associated address when they have already been connected to the
network [41].
The Automatic Node Discovery (AND) protocol [41] introduces a technique that enables
nodes in a CANopen® network to be dynamically identified, so that their addresses can be
assigned correctly. The overall configuration mechanism consists of two separate phases: node
identification and address assignment. In the node identification phase the Layer Setting
Services (LSS) master, one of two protocols included with CANopen®, discovers the different
nodes in the network. Once this task is finished, the address assignment phase is started. Since
the address assignment scheme for the slaves affects the precedence of the messages they
transmit, the timing requirements of the different data exchanges have to be somehow known in
this phase. This aspect is covered in more detail in [49] and [50].
The AND algorithm enables slave devices to be discovered quickly when they are
already connected to the final system. This is achieved by adding some communication services
to the basic LSS protocol, so that the nonconfigured nodes can be identified. In [41] two
versions of the discovery algorithm are described, that are nonrecursive and recursive,
respectively. The former facilitates implementations, while the latter runs faster. The AND
protocol is efficient and requires few changes to the firmware of the slave devices and provides a
good degree of compatibility with the devices currently available off the shelf [41].
4.3.3 Event-Triggered vs. Time-Triggered Control Paradigms
One of the elementary requirements of all real-time systems is the ability to react to an
asynchronous event within a predefined period of time. At present, two different control
93

paradigms are prevalent in the design of real-time architectures, and it has been recognized that
communication protocols fall into two general categories with corresponding strengths and
deficiencies: event-triggered and time-triggered control [51 – 53]. Event-triggered protocols
(e.g., TCP/IP, CAN, Ethernet, 1 – Wire®, ARINC629) offer flexibility and resource
efficiency. Time-triggered protocols (e.g., TTP, SafeBus, FlexRay [54], Spider) excel with
respect to temporal predictability, composability, error detection and error containment.
In event-triggered architectures, the system activities, such as sending a message or
starting computational activities, are triggered by the occurrence of events in the environment or
the computer system. In time-triggered architectures (e.g., Time – Triggered Architecture (TTA)
[55], FlexRay [54]), activities are triggered by the progression of global time. The major
contrast between event-triggered and time-triggered approaches lies in the location of control.
Time-triggered systems exhibit autonomous control and interact with the environment according
to an internal predefined schedule, whereas event-triggered systems are under the control of the
environment and must respond to stimuli as they occur [51]. Table 4.2 summarizes the
comparisons between event-triggered and time-triggered systems.
Table 4.2 Time-Triggered vs. Event-Triggered.
Time-Triggered Event-Triggered
Periodic Messages Yes
Sporadic Messages Yes
Predictability Yes
Flexibility Yes
The time-triggered approach is generally preferred for safety-critical systems [51 – 53].
For example, in the automotive industry a time-triggered architecture will provide the ability to
handle the communication needs of by-wire cars [56]. In addition to hard real-time performance,
94

time-triggered architectures help in managing the complexity of fault-tolerance and
corresponding formal dependability models, as required for the establishment of ultra-high
reliability (failure rates in the order of 10 -9 failures/hour) [51]. The predetermined points in time
of periodic message transmissions allow error detection and redundancy to be integrated
transparently into applications without any modification of the function and timing of the system.
A time-triggered system also supports replica determinism, which is essential for establishing
fault-tolerance through active redundancy. The communication controller in a time-triggered
system decides autonomously when a message is transmitted.
One drawback, however, of time-triggered bus concepts is the lack of flexibility and the
restrictive design process. All processes and their time specifications must be known in advance.
Otherwise, an efficient implementation is not possible. Furthermore, the communication and the
task scheduling on the control units have to be synchronized during operation in order to ensure
the strict timing specifications of the system design [57].
In non safety-critical (soft real-time) applications, however, the event-triggered control
paradigm may be preferred due to higher flexibility and resource efficiency. Event-triggered
architectures support dynamic resource allocation strategies and resource sharing. In event-
triggered systems, the provision of resources can be biased towards average demands, thus
allowing timing failures to occur during worst-case scenarios in favor of more cost-effective
solutions [58]. The main advantage of event-triggered systems is their ability to quickly react to
asynchronous external events which are not known in advance [59]. Thus, they show a better
real-time performance in comparison with time-triggered systems. In addition, event-triggered
95

systems possess a higher flexibility and allow, in many cases, the adaptation to the actual
demand without a redesign of the complete system [57].
Both CAN and 1 – Wire® are event-triggered (asynchronous) in the sense that all
activities are carried out in response to relevant events external to the system. In terms of real-
time, a system is said to be real-time if the total correctness of an operation depends not only
upon its logical correctness, but also upon the time in which it is performed [60]. Real-time
systems, as well as their deadlines, are classified by the consequence of missing a deadline (See
Table 4.3).
Table 4.3 Categorization of Real-Time Systems [60].
Category Definition
Hard Missing a deadline is a total system failure.
Firm
Infrequent deadline misses are tolerable, but may degrade the system’s quality of service. The
usefulness of a result is zero after its deadline.
Soft
The usefulness of a result degrades after its deadline, thereby degrading the system’s quality of
service.
In terms of real-time, neither protocol, by definition, can be classified as such. Without
adding a higher layer protocol on top of the data layer (i.e., TTCAN [61 – 62]), neither protocol
can guarantee a response within strict time constraints. However, both serial protocols can be
sub-classified as soft real-time protocols. By definition, a soft real-time system is one, which
tolerates lateness and may respond with decreased service quality.
Overall, the CAN protocol is going to be more responsive to external demands. This is
due to a number of factors including: a non-destructive bus arbitration scheme in place to handle
message collisions; multiple data rates that include some slower and many much faster than the
communication speeds at which 1 – Wire® can operate; CAN also has a number of fault
tolerance mechanisms (the inclusion of a 2 – bit acknowledgement field and when the bus speed
96

is kept below 125 kbps, the bus can function if one of the two data wires is cut), whereas 1 –
Wire® has only a 16 – bit CRC; with CAN information being carried on the bus as a voltage
difference, this also gives the CAN bus a high immunity to electromagnetic interference,
whereas 1 – Wire® has data and power residing on the same line;
4.3.4 Timing Performance
One of the key elements related to the performance of any embedded system is message
latency. By definition, message latency is the time needed for an electronic message to travel
across a communications system and for the remote system to respond [63]. Message latency in
a packet-switched network is measured either one-way (the time from the source sending a
packet to the destination receiving it), or round-trip (the one-way message latency from source to
destination plus the one-way latency from the destination back to the source). Round-trip
message latency is more often quoted, because it can be measured from a single point. Where
precision is important, one-way message latency can be more strictly defined as the time from
the start of packet transmission to the start of packet reception [64]. This section presents an
analysis of the message latencies attributed with both communication protocols and possible
ways to minimize them.
Under CAN, a given message is assumed to be invoked by some event, and is then
given a bounded time for queueing of this message [65 – 66]. Because this time is bounded
instead of fixed, there is some variability, or jitter, between subsequent queuings of the message.
This is known as queuing jitter. It is assumed for the sake of analysis that there is a minimum
time between invocations of a given message (i.e. period). Since a given message is assigned a
97

fixed identifier and hence a fixed priority, it can be assumed that each given message must
contain a bounded number of bytes. Given a bounded size, and a bounded rate at which the
message is sent, this effectively bounds the peak load on the bus. This allows scheduling
analysis to be applied to obtain a latency bound for each message on the bus [67].
The queuing of a hard real-time message can occur with jitter (variability in queuing
times) as shown in Figure 4.8. The shaded boxes in Figure 4.8 represent the ‘windows’ in which
a node can queue a message. Jitter is important because to ignore it would lead to insufficient
analysis. For example, ignoring jitter would lead to the assumption that message m could be
queued at most once in an interval of duration (b – a). In fact, during the interval (a … b] the
message could be queued twice: once at a (as late as possible in the first queuing window), and
once at b (as early as possible in the next queuing window). Queuing jitter can be defined as the
difference between the earliest and latest possible times a given message can be queued [67].
Figure 4.8 Message Queuing Jitter [67].
98

The analysis to bind the worst-case latency of a given hard real-time message is an
almost direct application of processor scheduling theory [68 – 70]. However, there are some
assumptions made by this analysis: first, the deadline of a given message m (denoted Dm) must
not be more than the period of the message (denoted Tm), and second, the bus controller must not
release the bus to lower priority messages if there are higher priority messages pending (i.e. the
controller cannot release the bus between sending one message and entering any pending
message into the arbitration phase).
The worst-case response time of a given message m is denoted by Rm, and is defined as
the longest time between the start of a node queuing m and the latest time that the message
arrives at the destination nodes. From this, the worst-case response time of a given hard real-
time message m can be bound by equation 4.1.
Rm Jm wm Cm
(4.1)
The term Jm is the queuing jitter of message m, and gives the latest queuing time of the message,
relative to the start of the transmitting node. The term wm represents the worst-case queuing
delay of message m (due to both higher priority messages pre-empting message m, and a lower
priority message that has already obtained the bus). The term Cm represents the longest time
taken to physically send message m on the bus. This time includes the time taken by the frame
overheads, the data contents, and extra stuff bits (the CAN protocol specifies that the message
contents and 34 bits of the overhead are subject to bit stuffing with a stuff width of 4 – worst
case of 1 stuff bit for every 4 message bits). The stuff bit counts as the first bit in a new stuffing
sequence. For an 11-bit identifier (slightly different formula below for 29-bit header), only 34 of
the overhead bits are subject to stuffing; others aren’t subject to stuffing. Equation 4.2 gives Cm:
99

348sm
Cm 47 8 smbit
11-bit header
4
100
548sm
Cm 67 8 smbit
29-bit header
4
The term sm denotes the bounded size of message m in bytes. The term bit is the bit time of the
bus (on a bus running at 1 Mbps this is 1µs). The 34 (11-bit) term in the numerator comes from
the sum of the SOF, Arbitration, ACK, CRC, and Interframe Space bit fields whose values are 1,
12, 2, 16, and 3 respectively. For a 29-bit header, this value is 54 (sum of 1, 32, 2, 16, and 3).
The value of 47 (11-bit) in Equation 4.2 comes from the previous sum of 34 and the Control and
EOF bit fields whose values are 6 and 7 respectively. For a 29-bit header, the value is 67 (the
sum of 54 and the Control and EOF bit fields).
Equation 4.3 represents the queuing delay and is given by:
(4.2)
wm J j
bit
wm Bm Cj
(4.3)
j hpm Tj
The set hp(m) is the set of messages in the system of higher priority than m. Tj is the period of a
given message j, and Jj is the queuing jitter of the message. Bm is the longest time that the given
message m can be delayed by lower priority messages (this is equal to the time taken to transmit
the largest lower priority message), and can be defined by:
max B C
(4.4)
m k
k lp m
where lp(m) is the set of lower priority messages.
In Equation 4.3, the term wm appears on both sides of the equation, thus the equation
cannot be rewritten in terms of wm. A simple solution is possible by forming a recurrence
relationship:

n w 1
m J n
j
bit
wm Bm Cj
(4.5)
j hpm Tj
A value of zero for w can be used. The iteration process proceeds until convergence (i.e.
n 1 n
m m
0
m
w w ). Equations 4.1 through 4.5 do not assume anything about how identifiers and hence
priorities are chosen [67].
From analysis of Equations 4.1 through 4.5, the minimal latency time occurs when the
CAN bus is running at its maximum speed of 1 Mbps and when a frame consisting of zero
data bytes is transmitted (i.e. sm 0 and bit 1μs ). Solving Equation 4.2 for a value of Cm
yields:
C
C
m
m
34
47 8.5 47 55.5 μsec 11-bit header
4
101
54
67 13.5 67 80.5 μsec 29-bit header
4
The maximum latency time occurs when the bus is running at its slowest speed of 10 kbps and
when a frame consisting of eight data bytes is transmitted (i.e. sm 8and
bit 100μs ).
Resolving Equation 4.2 for Cm yields:
C
C
m
m
(4.6)
34 88 98
47 8 8 10μs 111 10μs 1.355msec=1355μsec (11-bit)
4
4
(4.7)
54 88 118
67 88 10μs 13110μs1.605msec=1605μsec (29-bit)
4
4
From this analysis, the worst-case latency value comes from the bus operating at the
slowest speed of 10 kbps when each message contains the maximum amount of data at eight
bytes and the values for the queuing jitter (Jm) and worst-case queuing delay (wm) are zero. The

est-case latency occurs when the bus is operated at it maximum speed of 1 Mbps and each data
frame contains no data. Again for this case it is assumed that the values for queuing jitter (Jm)
and worst-case queuing delay (wm) are zero. Therefore operating the bus at the highest speed
possible and keeping the amount of data in each data frame as small as possible would allow
minimal latency times on the CAN bus.
In many iButton and 1 – Wire® applications, cable length and loading often preclude
the use of the overdrive mode. Cable length and loading are the two biggest factors that
contribute to message latency on 1 – Wire® networks. In those applications where the
embedded electronics are in close proximity to the slave devices, the high-speed overdrive
communication mode can greatly reduce transaction times [71]. Table 4.4 shows a comparison
of typical 1 – Wire® command transactions using both standard and overdrive speeds.
There are two ways to get an overdrive-capable slave device into overdrive mode. One
way uses the Overdrive Skip command, which puts all devices on the bus into overdrive. The
other way uses the Overdrive Match command, which only puts the device with the matching
identification number into overdrive. The device remains in overdrive mode until it gets a 1 –
Wire® reset at standard speed, or it is disconnected from the bus. Any 1 – Wire® device that is
either hot swapped (plug-and-play) or is already on the bus at power always starts at standard
speed [71].
The example in Table 4.4 shows that despite the extra command and reset cycle of
getting to overdrive speed, using overdrive obtains the device identification number in 2152µs
compared to 5640µs at standard speed. The more communication that occurs at overdrive, the
more substantial is the time savings. The downside to using overdrive speed is the additional
102

caution required after a short or loss of electrical contact or when hot-swapping slave devices.
Electrical shorts typically occur when an iButton is placed on an iButton probe and the data
contact of the iButton bridges the probe’s DATA and GND contacts. The duration of such a
short can vary from a few milliseconds up to a second or even more. Although a short does not
damage 1 – Wire® devices on the bus, it causes a communication bus reset which, in turn, resets
the 1 – Wire® data rate to standard speed. If the bus master were using overdrive speed and was
unaware of the short, subsequent communication attempts at overdrive speed would fail. From
an iButton’s perspective, loss of contact is equivalent to a short; in either case there is no
voltage between DATA and GND. Consequently, the reset to standard speed also occurs if the
connection between the iButton and probe is lost [71].
Table 4.4 Time Savings for a Read ROM Function [71].
Step Time Slots STD Speed Time OD Speed Time
1 – Wire® Reset/Presence Detect Cycle at
Standard Speed
N/A 960µs 960µs
Command Overdrive Skip ROM 8 N/A 8 x 65µs
1 – Wire® Reset/Presence Detect Cycle at
N/A N/A 96µs
Overdrive Speed
Command Read ROM 8 8 x 65µs 8 x 8µs
Read Device Identification Number 64 64 x 65µs 64 x 8µs
Total Time 5640µs 2152µs
From the above discussion with overdrive and standard speeds it is easy to see that there
is a savings factor greater than 2.5 when using overdrive speed. The main disadvantages are:
loss of bus power forcing a reset and loss of device contact. Although not really a disadvantage,
using overdrive speed on a 1 – Wire® network does require additional programming to be done
for the 1 – Wire® Master if both standard and overdrive capable devices reside on the same
branch of a network. Ideally, if both speeds are desired on the same network, it is recommended
103

to break the 1 – Wire® network into separate branches or trunks having only overdrive capable
devices on one branch and only standard speed capable devices on the other.
Another key parameter affecting message latency times on the 1 – Wire® bus, other than
cable length and loading, is the recovery time, tREC. The majority of 1 – Wire® devices is
parasitically powered, meaning that the 1 – Wire® line serves as power line and bidirectional
data line. The 1 – Wire® protocol is designed to have idle times without communication,
precisely so power can be transmitted to the 1 – Wire® slave devices on the line. The critical
parameter that limits the amount of power available for the 1 – Wire® slaves is the recovery
time, tREC. The tREC value specified in product data sheets and read/write waveforms is valid for
only 1 – Wire® networks of a single slave. An analysis is presented here to identify the power-
critical events and provide an algorithm to calculate the necessary recovery time for varying
number of 1 – Wire® slaves, different operating voltage, and temperature. The algorithm
presented here explains how to set tREC in Write-Zero Time Slots, and, as a derived value, tSLOT
(time to communicate one bit excluding recovery time), to ensure adequate power supply in 1 –
Wire® networks with multiple slaves. The resulting tSLOT, if also applied to Read-Data and
Write-One Time Slots, defines the maximum data rate for reliable communication in a given 1 –
Wire® network.
Figure 4.9 shows the reset/presence detect cycle for a DS2411 (Silicon Serial Number
with VCC Input) 1 – Wire® device. The recovery time begins after the presence pulse and ends
with the falling edge of the next time slot. Typically, tRSTL (Reset low time) and tRSTH (Reset
high time) are chosen to have the same duration. At standard speed, tRSTL is 480µs. Under
worst-case conditions, tPDH (Presence-detect high time) + tPDL (Presence-detect low time) are
104

300µs, leaving 180µs for tREC. At overdrive speed, these numbers are ten times shorter, reducing
tREC to 18µs. Compared to the minimum data sheet specification of tREC, plenty of time remains
for the parasitic power supply (a capacitor inside the slave) to recharge. Therefore, the
reset/presence detect cycle is not critical for power considerations, as long as tRSTL does not
exceed the data sheet’s maximum limit and the parasitic power supply is sufficiently charged
before tRSTL begins. At overdrive speed an extended recovery time of 2.5 times the minimum
value prior to a reset pulse provides this extra charge. At standard speed the extended recovery
time prior to a reset pulse is optional.
Figure 4.9 Initialization Procedure: Reset and Presence Pulse [72 – 73].
The read/write timing diagram below consists of three waveforms: Write-One Time Slot-
to write a logical ‘1’ (Figure 4.10); Write Zero Time Slot-to write a logical ‘0’ (Figure 4.11); and
Read Data Time Slot-to read a bit from a 1 – Wire® slave (Figure 4.12). As can easily be seen
from Figure 4.10, a Write-One Time Slot is not critical for power delivery. The window for
power delivery, tSLOT – tW1L (Write-one low time), is at least 50µs at standard speed and 6µs at
overdrive speed. The 6µs at overdrive speed, however, are barely more than the minimum
specification of tREC. The Write-Zero Time Slot, especially when there are multiple zeros in a
105

ow, is most critical for power delivery due to the long low-time compared to the recovery time.
It is important to understand that the tREC specification in the product data sheets for 1 – Wire®
devices applies for a single slave on a 1 – Wire® line with a 2.2kΩ pullup resistor to 2.8V. A
Read-Data Time Slot, when reading a zero, is also critical for power delivery. It is, however,
more benign since a slave typically pulls the 1 – Wire® line low for less than the permissible
60µs (standard speed) or 6µs (overdrive speed).
Figure 4.10 Write-One Time Slot [72 – 73].
Figure 4.11 Write-Zero Time Slot [72 – 73].
106

Figure 4.12 Read-Data Time Slot [72 – 73].
When analyzing the recovery time with respect to power delivery, several primary and
secondary parameters are considered. These parameters are defined and described in Table 4.5.
Table 4.5 Parameters of Impact [72].
Primary
Number of Slaves The demand for power increases with the number of consumers.
Pullup Voltage The higher the voltage, the more energy can be delivered.
Communication Speed At overdrive speed, the duty cycle of a Write-Zero Time Slot is higher.
Type of 1 – Wire® Driver An ‘intelligent’ driver can pump more energy.
Secondary
Operating Temperature A cold 1 – Wire® device needs more energy.
Cable Length The capacitance of the cable needs to be charged too.
1 – Wire® Device Type Some devices need slightly more or less energy than others.
In the first example, only typical data sheet conditions are used: a driver consisting of a
2.2kΩ pullup resistor to 2.8V, the worst-case temperature, a single 1 – Wire® slave on the bus,
and negligible cable capacitance. This example uses the number of 1 – Wire® slaves as the main
parameter and provides answers for varying operating voltage, speed, and temperature. If the
cable between 1 – Wire® driver and slaves becomes significant, it can be represented in the
calculation as an additional slave for every 15 meters of length. The results shown in Table 4.6
apply for typical 1 – Wire® slaves for ROM function commands, general memory read functions
and SRAM write functions. Writing to EEPROMS, temperature conversion and SHA – 1
107

computations have device-specific power delivery requirements, such as a strong pullup, which
do not affect the validity of the method presented here. As far as ROM functions and memory
are concerned, 1 – Wire® EPROM devices can also be considered as typical; for programming
purposes, only a single EPROM device is permitted on the network.
Table 4.6 Results Matrix [72].
Operating Voltage (V) Temperature (°C) Standard Speed (µs) Overdrive Speed (µs)
-40 tREC = 2.12 x N +1.0 tREC = 1.43 x N +0.5
4.5 and higher
-5
+25
tREC = 1.99 x N +1.0
tREC = 1.83 x N +1.0
tREC = 1.37 x N +0.5
tREC = 1.30 x N +0.5
+85 tREC = 1.54 x N +1.0 tREC = 1.18 x N +0.5
-40 tREC = 3.52 x N +1.0 tREC = 1.82 x N +0.5
2.8 (minimum)
-5
+25
tREC = 3.30 x N +1.0
tREC = 3.17 x N +1.0
tREC = 1.80 x N +0.5
tREC = 1.74 x N +0.5
+85 tREC = 2.70 x N +1.0 tREC = 1.63 x N +0.5
The recovery time can be calculated using a linear equation as shown in equation 4.8.
t REC
a N b
(4.8)
N is the number of parasitically powered slave devices on the network, assuming that all slaves
are connected in parallel from the 1 – Wire® line to the ground reference. 1 – Wire® devices
that get their power through a VCC pin do not significantly load the 1 – Wire® line; they should
be counted as one-tenth of a device. The slope ‘ a ’ varies with temperature, operating (pullup)
voltage, and 1 – Wire® speed. For this analysis, it is sufficient to let the offset ‘ b ’ vary with
speed only. Table 4.6 shows the equation with slope and offset inserted. The numerical values
are obtained through manual curve fitting; the results closely match those obtained through an
iterative process based on scientific models. For N 1,
the results matrix does not generate
exactly the same number as published in most device data sheets. This different value is a side
effect of the curve fitting, and should not be regarded as in conflict with the specification.
108

The recovery time is longest for low operating voltage and low temperature. If the
application requires operation at very low temperatures, the -40°C entry should be used. For
room-temperature environments, it is acceptable to use the +25°C entry, which also allows safe
operation at higher temperatures. The +85°C entry yields a result that only applies at that
temperature; it should be regarded as a reference, not as a design value for other temperatures.
The recovery is shortest for high operating voltages. The 4.5V entries apply for pullup
voltages of 4.5V or higher. A recovery time based on 2.8V entries also works for higher
voltages, but unnecessarily slows the data rate. For an operating voltage, say Vx, between 2.8V
and 4.5V, a new slope value can be obtained through linear interpolation using equation 4.9 [72].
Slope@2.8V Vx 2.8V
Slope@Vx Slope@2.8V Slope@4.5V
(4.9)
1.7V
As a second example, assume that an application requires a network of twenty 1 – Wire®
devices N 20
, with tW0L = 60µs at standard speed and 6µs at overdrive (from DS2411 data
sheet). The network is supposed to operate from 0°C to 70°C. The operating voltage is not
unknown. The applicable entry for this temperature range is that of -5°C, because it is the
nearest value below the minimum operating temperature. Since the slope for higher
temperatures is lower than that of the -5°C entry, the result is valid for all temperatures above -
5°C. Table 4.7 shows the tREC results for this example and the maximum data rate with this
recovery time.
109

Table 4.7 Example results with N 20 .
Operating Voltage (V) Standard Speed Overdrive Speed
t 1.99 N 1.0
s
t 1.37 N 0.5 s
4.5 and higher
2.8 (minimum)
REC
data rate
REC
1.99 20 1.0
40.8s
data rate
1
t t
W 0L
REC
1
60s40.8s 9.92 kbps
3.30 1.0
3.30 20 1.0
1
t t
W 0L
REC
1
60s67s 7.87 kbps
110
s
t N s
67s
s
REC
data rate
REC
1.37 20 0.5
27.9s
data rate
1
t t
W 0L
REC
1
6s27.9s 29.5 kbps
1.80 0.5
1.80 20 0.5
1
t t
W 0L
REC
1
6s36.5s 23.5 kbps
s
t N s
36.5s
At standard speed, the data rate is reduced to approximately 65% of the 15.3 kbps for an
operating voltage of 4.5V and is reduced to approximately 51% when the minimum 2.8V
operating voltage is used. At overdrive speed, the data rate is less than 25% of the 125 kbps
reference for operating voltages of 4.5V and higher. When operating at the minimum operating
voltage of 2.8V, the data rate is less than 20% of the 125 kbps reference. If any of the data rates
in Table 4.7 is acceptable for the application, the choice of operating voltage is not critical.
However, if an operating voltage of approximately 5V is available, it should be preferred
because of better noise immunity.
s

If the recovery time resulting from Table 4.7 is not acceptable, there are several ways to
increase the data rate:
Reduce the pullup resistor from 2.2kΩ to e.g., 1kΩ. The lower resistor doubles the
recharge current for the 1 – Wire® network, which in turn reduces the recovery time by
50%. With this approach, it is important to verify whether each of the slave devices can
handle the increased current, VPUP/RPUP (1 – Wire® pullup voltage/Pullup resistor), when
pulling the 1 – Wire® line low during a Read-Data Time Slot.
Change the network topology. Instead of one network, use two or more smaller networks
or use the DS2409 1 – Wire® coupler to disconnect some slave devices from the active
part of the network.
Consider using an active 1 – Wire® driver. An active driver uses transistors to
temporarily bypass the pullup resistor. This allows a faster recharge of the 1 – Wire®
network and, in turn, reduces the necessary recovery time [72].
The most flexibility, in particular for driving a physically large 1 – Wire® network, is
achieved with a microcontroller that operates as an intelligent 1 – Wire® driver. Depending on
the characteristics of the microcontroller, such a driver can also operate at 3.3V or 5V.
Calculating the necessary recovery time of 1 – Wire® applications with multiple slaves is a
simple and straightforward process. A 5V environment is generally the preferred choice for any
1 – Wire® network. For most applications, a 1 – Wire® driver with a resistive pullup is
sufficient. For larger networks, a driver with active pullup capabilities may be required.
111

4.3.5 Communication Speed Differential
Since the communication speeds supported under the CAN protocol specification are
well above and below those supported by the 1 – Wire® protocol, an additional buffer is needed
to handle any underflow or overflow of messages from one bus to the other. For CAN, the bit
rates are inversely proportional to the bus lengths and can range from 10 kbps up to 1000 kbps.
As stated in section 2.2, most 1 – Wire devices support two data rates. The lower (standard) data
rate is about 14 kbps and the higher (overdrive) data rate is about 140 kbps. Best suited to solve
any communication speed differential, would be the use of either a First-In-First-Out (FIFO) or a
prioritized FIFO buffer.
112

CHAPTER 5
THE INTERFACE OF CAN AND 1 – WIRE® COMMUNICATION PROTOCOLS
5.1 Interface Overview
In many situations, especially those involving cutting-edge technology, new designs have
unanticipated problems that are difficult to predict by modeling or simulations. When the
performance of a new device is uncertain, an early development of a prototype can be useful for
testing the key features of the design, exploring design alternatives, testing theories, and
confirming performance prior to starting production [74]. Since prototyping is an iterative
process, a series of products will be designed, constructed, and tested to refine the final design.
The prototype design presented here consists of a 1 – Wire® Bus Master and a CAN
Transceiver. Both components in the prototype system have been designed in Verilog®, so they
can be targeted to different implementation technologies. To implement all of the prototype
design components, the DE2 Development and Education Board, equipped with a Cyclone II
(2C35) FPGA, manufactured by Altera was used for all design synthesis and simulations.
5.2 1 – Wire® FPGA Implementation
As more 1 – Wire® devices become available, more and more users have to deal with the
demands of generating 1 – Wire® signals to communicate to them. This usually requires “bit-
113

anging” a port pin on a microprocessor, and having the microprocessor perform the timing
functions required for the 1 – Wire® protocol. Even though 1 – Wire® transmissions can be
interrupted mid-byte, they cannot be interrupted during the “low” time of a bit time slot; this
means that a CPU will be idle for up to 60 microseconds for each bit sent and at least 480
microseconds when performing a 1 – Wire® reset [75].
5.2.1 1 – Wire® Master Overview
The synthesizable 1 – Wire® Master implemented here, termed one_wm, was created to
facilitate host CPU communication with devices over a 1 – Wire® bus without concern for bit
timing and without tying up valuable CPU cycles. Some of the features incorporated into the
design include:
Support for long line conditions.
Support for single bit transmissions.
Memory maps into any standard byte-wide data bus.
Search ROM accelerator relieves the CPU from any single bit operations on the 1 –
Wire® bus.
Generates interrupts to provide for more efficient programming.
Eliminates CPU “bit-banging” by internally generating all 1 – Wire® timing and control
signals.
Supports standard and overdrive communication speeds.
Capable of running off any system clock from 4 MHz up to 128 MHz.
Supports strong pull-up specifications as defined by the 1 – Wire® protocol standards.
114

Applications include any circuit containing a 1 – Wire® communication bus.
The synthesizable 1 – Wire® Bus Master as shown in Figure 5.1 is designed to be
memory-mapped into any system and provides complete control of the 1 – Wire® bus through
single-bit or 8-bit commands. The host CPU loads commands, reads and writes data, and sets
interrupt control through seven individual registers. All of the timing and control of the 1 –
Wire® bus are generated within. The host merely needs to load a command or data and then
may go on about other business. When bus activity has generated a response that the CPU needs
to receive, the 1 – Wire® Master sets a status bit and, if enabled, generates an interrupt to the
CPU. In addition to read and write simplification, the 1 – Wire® Master also provides a Search
ROM Accelerator function relieving the CPU from having to perform the complex single-bit
operations on the 1 – Wire® bus.
Figure 5.1 one_wm Synthesizable 1 – Wire® Bus Master Block Diagram.
115

From Figure 5.1, the block I/O pins are defined as follows with ‘0’ representing a logic
level “low” and ‘1’ representing a logic level “high”:
A0, A1, A2Register Select: Address signals connected to these three inputs select a
register for the CPU to read from or write to during data transfer. A table of registers and
their addresses is shown below in Table 5.1.
Table 5.1. 1 – Wire® Register Addresses.
Register Addresses
A2 A1 A0 Register
0 0 0 Command Register (read/write)
0 0 1 Transmit Buffer (write), Receive Buffer (read)
0 1 0 Interrupt Register (read)
0 1 1 Interrupt Enable Register (read/write)
1 0 0 Clock Divisor Register (read/write)
1 0 1 Control Register (read/write)
ADS Address Strobe: The positive edge of an active Address Strobe ( ADS ) signal
latches the Register Select (A0, A1, A2) into an internal latch. Provided that setup and
hold timings are observed, ADS may be tied low making the latch transparent.
CLKClock Input: This is a (preferably) 50% duty cycle clock that can range from 4
MHz to 128 MHz. This clock provides the timing for the 1 – Wire® bus.
D0 – D7Data Bus: This bus comprises eight input/output lines. The bus provides bi-
directional communications between the 1 – Wire® Master and the CPU. Data, control
words, and status information are transferred via this D0 – D7 Data Bus.
DQ1 – Wire® Data Line: This open-drain line is the 1 – Wire® bi-directional data bus.
1 – Wire® slave devices are connected to this pin. This pin must be pulled high by an
external resistor, nominally 5kΩ.
116

EN Enable: When EN is low, the 1 – Wire® Master is enabled; this signal acts as
the device chip enable. This enables communication between the 1 – Wire® Master and
the CPU.
INTR Interrupt: This line goes to its active state whenever any one of the interrupt
types has an active high condition and is enabled via the Interrupt Enable Register. The
INTR signal is reset to an inactive state when the Interrupt Register is read.
MRMaster Reset: When this input is high, it clears all the registers and the control
logic of the 1 – Wire® Master, and sets INTR to its default inactive state, which is HIGH.
RD Read: This pin drives the bus during a read cycle. When the circuit is enabled,
the CPU can read status information or data from the selected register by driving RD
low. RD and WR should never be low simultaneously; if they are WR takes
precedence.
STPZ Strong Pull-up Enable: This pin drives the gate of the p-channel transistor that
bypasses the weak pull-up resistor in order to provide the slave device with a strong
power supply for high current applications.
WR Write: This pin drives the bus during a write cycle. When WR is low while
the circuit is enabled, the CPU can write control words or data into the selected register.
RD and WR should never be low simultaneously; if they are WR takes
precedence.
117

5.2.2 Command Register
In addition to reading and writing the 1 – Wire® Master can generate two special
commands on the bus. The first is a 1 – Wire® reset, which must precede any command given
on the 1 – Wire® bus. Secondly, the 1 – Wire® Master can be placed into Search ROM
Accelerator mode to prevent the host from having to perform single bit manipulations of the bus
during a Search ROM operation (command 0xF0h). For more details on the Reset or Search
ROM command, the reader is referred to [75]. In addition to these two functions, the Command
Register contains two bits to bypass the 1 – Wire® Master features and control the 1 – Wire®
bus directly (See Figure 5.2).
Figure 5.2 Command Register Bits.
Bit 3 – OW_IN: OW Input. This bit always reflects the current state of the 1 – Wire®
line.
Bit 2 – FOW: Force One Wire. This bit can be used to bypass 1 – Wire® Master
operations and drive the bus directly if needed. Setting this bit high will drive the bus
low until it is cleared or a bus reset occurs. While the 1 – Wire® bus is held low, no
other 1 – Wire® Master operations will function. By controlling the length of time this
bit is set and the point when the line is sampled, any 1 – Wire® communication can be
generated by the host controller. To prevent accidental writes to the bus, the EN bit in
the CONTROL register must be set to a 1 before the FOW bit will function. The FOW
bit is cleared to a 0 on a power-up or master reset.
118

Bit 1 – SRA: Search ROM Accelerator. When this bit is set, the 1 – Wire® Master will
switch to Search ROM Accelerator mode. When this bit is set to 0, the master will
function in its normal mode. The SRA bit is cleared to 0 on a power-up or master reset.
Bit 0 – 1WR: 1 – Wire® Reset. If this bit is set, a reset will be generated on the 1 –
Wire® bus. Setting this bit automatically clears the SRA bit. The 1WR bit will be
automatically cleared as soon as the 1 – Wire® reset completes. The 1 – Wire® Master
will set the Presence Detect interrupt flag (PD) when the reset is complete and sufficient
time for a presence detect to occur has passed. The result of the presence detect will be
placed in the interrupt register bit PDR. If a presence detect pulse was received, PDR
will be cleared, otherwise it will be set.
5.2.3 Search ROM Accelerator Description
The search ROM Accelerator Mode presupposes that a Reset followed by the Search
ROM command (0xF0h) has already been issued on the 1 – Wire® bus. For details on how the
Search ROM is actually done in a 1 – Wire® system, the reader is referred to [7]. The algorithm
specifies that the bus master reads two bits (a bit and its complement), then writes a bit to specify
which devices should remain on the bus for further processing.
After the 1 – Wire® Master is placed in Search ROM Accelerator Mode, the CPU must
send 16 bytes to complete a single Search ROM pass on the 1 – Wire® bus. These bytes are
constructed as shown in Figure 5.3. In this scheme, the index (values from 0 to 63, “n”)
designates the position of the bit in the ROM ID of a 1 – Wire® device. The character “x” marks
bits that act as a filler and do not require a specific value (i.e., don’t care bits). The character “r”
119

specifies the selected bit value to write at that particular bit in case of a conflict during the
execution of the ROM search.
Figure 5.3 Search ROM Accelerator Mode Send Bytes.
For each bit position n (values from 0 to 63), the 1 – Wire® Master will generate three
time slots on the 1 – Wire® bus. These are referenced as follows:
b0for the first time slot (read data)
b1for the second time slot (read data) and
b2for the third time slot (write data).
The 1 – Wire® Master determines the type of time slot b2 (write 1 or write 0) as follows:
b2 = rn if conflict (as chosen by the host)
= b0 if no conflict (there is no alternative)
= 1 if error (there is no response)
The response bytes that will be in the data register for the CPU to read during a complete pass
through a Search ROM function using the Search ROM Accelerator consists of 16 bytes as
shown in Figure 5.4.
120

Figure 5.4 Search ROM Accelerator Mode Response Bytes.
As before, the index designates the position of the bit in the ROM ID of a 1 – Wire®
device. The character “d” marks the discrepancy flag in that particular bit position. The
discrepancy flag will be “1” if there is a conflict or no response in that particular bit position and
“0” otherwise. The character “r” marks the actual chosen path at that particular bit position. The
chosen path is identical to b2 for the particular bit position of the ROM ID.
To perform a Search ROM sequence, one starts with all bits rn being zero. In the case of
a bus error, all subsequent response bits r’n are 1’s until the Search Accelerator is deactivated by
writing 0 to bit 1 (SRA bit) of the Command register. Thus, if r’63 and d63 are both 1, an error
has occurred during the search procedure and the last sequence has to be repeated. Otherwise, r’n
(n=0…63) is the ROM code of the device that has been found and addressed. When the Search
ROM process is complete, the SRA bit should be cleared in order to release the 1 – Wire®
Master from Search ROM Accelerator Mode.
For the next Search ROM sequence, one reuses the previous set rn (n=0…63) but sets rm
to 1 with “m” being the index number of the highest discrepancy flag that is 1 and sets all ri to 0
121

with i > m. This process is repeated until the highest discrepancy occurs in the same bit position
for two consecutive passes.
5.2.4 Transmit/Receive Buffer Register
Data sent and received from the 1 – Wire® Master passes through the transmit/receive
buffer location (See Figure 5.5). The 1 – Wire® Master is actually double buffered with separate
transmit and receive buffers. Writing to this location connects the Transmit Buffer to the data
bus, while reading connects the Receive Buffer to the data bus.
Figure 5.5 Transmit/Receive Buffer Register.
To send a byte on the 1 – Wire® bus, the user writes the desired data to the Transmit
Buffer. The data is then moved to the Transmit Shift Register where it is shifted serially onto the
bus LSB first. A new byte of data can then be written to the Transmit Buffer. As soon as the
Transmit Shift Register is empty, the data will be transferred from the Transmit Buffer and the
process repeats. Each of these registers has a flag that may be used as an interrupt source. The
Transmit Buffer Empty (TBE) flag is set when the Transmit Buffer is empty and ready to accept
a new byte. As soon as a byte is written into the Transmit Buffer, TBE is cleared. The Transmit
Shift Register Empty (TEMT) flag is set when the shift register has no data in it and is ready to
accept a new byte. As soon as a byte of data is transferred from the Transmit Buffer, TEMT is
cleared and TBE is set.
122

To read data from a slave device, the device must first be ready to transmit data
depending on commands already received from the CPU. Data is retrieved from the bus in a
similar fashion to a write operation. The host initiates a read by writing to the Transmit Buffer.
The data that is then shifted into the Receive Shift Register is the wired-AND of the written data
and the data from the slave device. Therefore, in order to read a byte from a slave device, the
host must write 0xFFh. When the Receive Shift Register is full, the data is transferred to the
Receive Buffer where it can be accessed by the host. Additional bytes can now be read by
sending 0xFFh again. If the slave device is not ready to transmit, the data received will be
identical to that which was transmitted. The Receive Buffer Register can also generate
interrupts. The Receive Buffer flag (RBF) is set when data is transferred from the Receive Shift
Register and cleared when the host reads the register. If RBF is set, no further transmissions
should be made on the 1 – Wire® bus or else data may be lost, as the byte in the Receive Buffer
will be overwritten by the next received byte.
5.2.5 Interrupt & Interrupt Enable Registers
Flags from current status, transmit, receive, and 1 – Wire® reset operations are located in
the Interrupt Register (See Figure 5.6). The Presence Detect flag (PD), OW_LOW, and
OW_SHORT are cleared when the Interrupt Register is read. The other flags are cleared
automatically when the Transmit and Receive Buffers are written or read. All of these flags can
generate an interrupt on the INTR pin if the corresponding enable bit is set in the Interrupt
Enable Register. To clear the INTR signal, the Interrupt Register must be read. Reading the
Interrupt Register always sets the INTR pin inactive even if all flags are not cleared.
123

Figure 5.6 Interrupt Register.
OW_LOW – One Wire Low. This flag will be set to ‘1’ when the 1 – Wire® line is low
while the master is in idle signaling that a slave device has issued a presence pulse on the
1 – Wire® (DQ) line. A read to the Interrupt Register will clear this bit.
OW_SHORT – One Wire Short. This flag will be set to a ‘1’ when the 1 – Wire® line
was low before the master was able to send out the beginning of a reset or a time slot.
When this flag is ‘0’, it indicates that the 1 – Wire® line was high as expected prior to all
resets and time slots. Reading the Interrupt Register will clear this bit.
RSRF – Receive Shift Register Full. This flag will be set to ‘1’ when there is a byte of
data waiting in the Receive Shift Register. When this bit is ‘0’, it indicates that the
Receive Shift Register is either empty or currently receiving data. This bit will be cleared
by the hardware when data in the Receive Shift Register is transferred to the Receive
Buffer. Reading the Interrupt Register will have no effect on this bit.
RBF – Receive Buffer Full. This flag will be set to ‘1’ when there is a byte of data
waiting to be read in the Receive Buffer. When this bit is ‘0’, it indicates that the
Receive Buffer has no new data to be read. This bit will be cleared when the byte is read
from the Receive Buffer. Reading the Interrupt Flag Register will have no effect on this
bit. However, following a read of the Interrupt Register, while the Enable Receive Buffer
Full Interrupt (ERBF) bit is set to ‘1’, if the ERBF is not cleared and the value is not read
from the Receive Buffer, another instance of this interrupt will occur.
124

TEMT – Transmit Shift Register Empty. This flag will be set to ‘1’ when there is
nothing in the Transmit Shift Register and it is ready to receive the next byte of data to be
transmitted from the Transmit Buffer. When this bit is ‘0’, it indicates that the Transmit
Shift Register is busy transferring data. This bit is cleared when data is transferred from
the Transmit Buffer to the Transmit Shift Register. Read the Interrupt Register will have
no effect on this bit.
TBE – Transmit Buffer Empty. This flag will be set to ‘1’ when there is nothing in the
Transmit Buffer and it is ready to receive the next byte of data. When it is ‘0’, the
Transmit Buffer is waiting for the Transmit Shift Register to finish sending its current
data. This bit is cleared when data is written to the Transmit Buffer. Read the Interrupt
Register will have no effect on this bit.
PDR – Presence Detect Result. When a Presence Detect interrupt occurs, this bit will
reflect the result of the presence detect read – it will be ‘0’ if a slave was found, or ‘1’ if
no device was found. Reading the Interrupt Register will have no effect on this bit.
PD – Presence Detect. After a 1 – Wire® Reset has been issued, this flag will be set to
‘1’ after the appropriate amount of time has expired for a presence detect pulse to occur.
This flag will be ‘0’ when the master has not issued a 1 – Wire® Reset since the previous
read of the Interrupt Register. This bit is cleared when the Interrupt Register is read.
The Interrupt Enable Register (See Figure 5.7) allows the system programmer to specify
the source of interrupts which will cause the INTR pin to be active, and to define the active state
for the INTR pin. When a Master Reset is received all bits in this register are cleared to ‘0’
disabling all interrupt sources and setting the active state of the INTR pin to LOW. This means
125

the INTR pin will be pulled high since all interrupts are disabled. The INTR pin is reset to an
inactive state by reading the Interrupt Register.
Figure 5.7 Interrupt Enable Register.
EOWL – Enable One Wire Low Interrupt. Setting this bit to a ‘1’ enables the One Wire
Low Interrupt. If set, INTR will be asserted when the OW_LOW flag is set. Clearing
this bit disables OW_LOW as an active interrupt source.
EOWSH – Enable One Wire Short Interrupt. Setting this bit to a ‘1’ enables the One
Wire Short Interrupt. If set, INTR will be asserted when the OW_SHORT flag is set.
Clearing this bit disables OW_SHORT as an active interrupt source.
ERSF – Enable Receive Shift Register Full Interrupt. Setting this bit to a ‘1’ enables the
Receive Shift Register Full Interrupt. If set, INTR will be asserted when the RSRF flag is
set. Clearing this bit disables RSRF as an active interrupt source.
ERBF – Enable Receive Buffer Full Interrupt. Setting this bit to a ‘1’ enables the
Receive Buffer Full Interrupt. If set, INTR will be asserted when the RBF flag is set.
Clearing this bit disables RBF as an active interrupt source.
ETMT – Enable Transmit Shift Register Empty Interrupt. Setting this bit to a ‘1’ enables
the Transmit Shift Register Empty Interrupt. If set, INTR will be asserted when the
TEMT flag is set. Clearing this bit disables TEMT as an active interrupt source.
126

ETBE – Enable Transmit Buffer Empty Interrupt. Setting this bit to a ‘1’ enables the
Transmit Buffer Empty Interrupt. If set, INTR will be asserted when the TBE flag is set.
Clearing this bit disables TBE as an active interrupt source.
IAS – INTR Active State. This bit determines the active state for the INTR pin. If this
bit is a ‘1’, the INTR pin is active high; if it is a ‘0’, the INTR pin is active low.
EPD – Enable Presence Detect Interrupt. Setting this bit to a ‘1’ enables the Presence
Detect Interrupt. If set, INTR will be asserted when the PD flag is set. Clearing this bit
disables PD as an active interrupt source.
5.2.6 Clock Divisor Register
All 1 – Wire® timing patterns are generated using a base clock of 1.0 MHz. The 1 –
Wire® Master will generate this clock frequency internally given an external reference on the
CLK pin. The external clock must have a frequency from 4 to 128 MHz and a 50% duty cycle is
preferred. The Clock Divisor Register controls the internal clock divider and provides the
desired reference frequency. This is done in two stages: first, a prescaler divides by 1, 3, 5, or 7,
and then the remaining circuitry divides by 2, 4, 8, 16, 32, 64, or 128. Figure 5.8 shows the
Clock Divisor Register.
Figure 5.8 Clock Divisor Register.
The clock divisor must be configured before any communication on the 1 – Wire® bus
can take place as well as setting the CLK_EN bit to a 1. This register is set to 0x00h when a
127

master reset occurs. Table 5.2 shows how to find the proper register value based on the CLK
reference frequency (i.e., if using a 40 MHz CLK reference frequency, write a value of 0x8Eh to
this location).
Table 5.2. Clock Divisor Register Settings for Input Clock Rates.
Min CLK
Frequency
(MHz)
5.2.7 Control Register
Max CLK
Frequency
(MHz)
Divider
Ratio
DIV2
128
DIV1
DIV0
PRE1
PRE0
4.0 < 5.0 4 0 1 0 0 0
5.0 < 6.0 5 0 0 0 1 0
6.0 < 7.0 6 0 0 1 0 1
7.0 < 8.0 7 0 0 0 1 1
8.0 < 10.0 8 0 1 1 0 0
10.0 < 12.0 10 0 0 1 1 0
12.0 < 14.0 12 0 1 0 0 1
14.0 < 16.0 14 0 0 1 1 1
16.0 < 20.0 16 1 0 0 0 0
20.0 < 24.0 20 0 1 0 1 0
24.0 < 28.0 24 0 1 1 0 1
28.0 < 32.0 28 0 1 0 1 1
32.0 < 40.0 32 1 0 1 0 0
40.0 < 48.0 40 0 1 1 1 0
48.0 < 56.0 48 1 0 0 0 1
56.0 < 64.0 56 0 1 1 1 1
64.0 < 80.0 64 1 1 0 0 0
80.0 < 96.0 80 1 0 0 1 0
96.0 < 112.0 96 1 0 1 0 1
112.0 < 128.0 112 1 0 0 1 1
Various 1 – Wire® devices utilize different communication protocols in order to properly
function and report back to the master in an efficient manner. The Control Register, shown in
Figure 5.9, adds the robustness needed to handle all of the major conditions expected from each
iButton and 1 – Wire® chip family device.

Figure 5.9 Control Register.
OD: Overdrive. Setting this bit to a ‘1’ will place the master into Overdrive mode that
effectively changes the master’s 1 – Wire® timings to match those outlined for Overdrive
in [75]. Clearing this bit to a ‘0’ leaves the master operating in standard mode speed.
BIT_CTL: Bit Control. Setting this bit to a ‘1’ will place the master into its “Bit
Banging” mode of operation. In this mode, only the least significant bit of the
Transmit/Receive register will be sent or received before enabling the interrupt flags that
signal the end of the transmission. Clearing this bit to ‘0’ leaves the master operating
using full byte boundaries.
STP_SPLY: Strong Pull-up Supply. Setting this bit to a ‘1’ while STPEN is also set to a
‘1’ will enable the STPZ output while the master is in an IDLE state. This will provide a
stiff supply to devices requiring high current during operations. Clearing this bit to a ‘0’
disables the STPZ output while the master is in an IDLE state. The STP_SPLY bit is a
don’t care bit if STPEN is set to a ‘0’.
STPEN: Strong Pull-up Enable. Setting this bit to a ‘1’ enables the strong pull-up output
enable (STPZ) pin’s functionality which allows this output pin to enable an external
strong pull-up any time the master is not pulling the line low or waiting to read a value
from a slave device. This functionality is used for meeting the recovery time requirement
in Overdrive mode and long-line standard communications. Clearing this bit to a ‘0’ will
disable the STPZ output pin.
129

EN_FOW: Enable Force One Wire. Setting this bit to a ‘1’ will enable the functionality
of the Force One Wire (FOW) register bit in the Command Register. Clearing this bit
will disable the functionality of the FOW bit.
PPM: Presence Pulse Masking Mode. Setting this bit to a ‘1’ will enable Presence Pulse
Masking Mode. This mode causes the master to initiate the falling edge of a presence
pulse during a 1 – Wire® Reset before the fastest slave would initiate one. This enables
the master to prevent the larger amount of ringing caused by the slave devices when
initiating a low on the DQ line. If the PPM bit is set, the PDR result bit in the Interrupt
Register will always be set to a ‘0’ showing that a slave device was on the line even if
there were none. Clearing this bit to a ‘0’ disables the Presence Pulse Masking Mode.
LLM: Long Line Mode. Setting this bit to a ‘1’ will enable Long Line Mode timings on
the 1 – Wire® line during standard mode communications. This mode effectively moves
the write one release, the data sampling, and the time slot recovery times out to roughly
8µs, 22µs, and 14µs respectively. This provides a less strict environment for long line
transmissions. Clearing this bit to a ‘0’ leaves the write one release, the data sampling,
and the time slot recovery times at roughly 5µs, 15µs, and 7µs respectively [76].
5.2.8 Verification of 1 – Wire® Module
To verify proper operation of the synthesizable 1 – Wire® Master, four test cases were
executed: Single One-Wire Network (single_search_rom), Multiple One-Wire Network
(multi_ow_network), Scratchpad Memory (scratchpad_integrity), and a Command Recognition
test (cmd_recognition). All tests were compiled and simulated using Altera Quartus II 9.1 (32-
130

it) and ModelSim Altera Starter Edition 6.6c software on a PC executing Windows XP Service
Pack 3. All tests performed were performed extensively while trying to cover all possible
combinations of inputs and outputs for the 1 – Wire® Master. No failures were observed for any
of the four tests described below. The source code for all modules, testbench code, and
simulation results are located on the DVD included with this work. Table 5.3 shows FPGA
resource utilization for the Altera DE2 Development and Education board.
Table 5.3 Resource Utilization.
Revision Name one_wm
Family Cyclone II
Device EP2C35F672C6
Timing Models Final
Met timing requirements Yes
Total logic elements 435 / 33,216 ( 1 % )
Total combinational functions 425 / 33,216 ( 1 % )
Dedicated logic registers 145 / 33,216 ( < 1 % )
Total registers 145
Total pins 20 / 475 ( 4 % )
Total virtual pins 0
Total memory bits 0 / 483,840 ( 0 % )
Embedded Multiplier 9-bit element 0 / 70 ( 0 % )
Total PLLs 0 / 4 ( 0 % )
Each one_wm transaction consists of the following instruction sequence: 1 – Wire®
Reset, a device addressing instruction, and a data access instruction. A 1 – Wire® Reset consists
of generating a 1 – Wire® Reset/Presence Detect pulse on the 1 – Wire® bus. The state of the 1
– Wire® bus is then sampled and a value of ‘1’ is returned if no Presence Detect pulse was found
and a value of ‘0’ is returned otherwise (i.e. slave device(s) found).
A device addressing instruction may be one of the following: READ_ROM (0x33),
MATCH_ROM (0x55), SKIP_ROM (0xCC), OD_SKIP_ROM (0x3C), or OD_MATCH_ROM
(0x69).
131

READ_ROM – Used to read the 64-bit ROM ID directly. It can only be used on a 1 –
Wire® network where there is only one device attached. If there are several slave
devices connected to the bus, the result of this command will be the AND result of all
slave device identifiers. Assuming that communication is flawless, the presence of
several slaves is indicated by a failed CRC.
MATCH_ROM – Used to address individual slave devices on the bus. After this
command is issued, the complete 64-bit identifier is transmitted on the bus. When this is
done, only the device with exactly this identifier is allowed to answer until the next reset
pulse is received.
SKIP_ROM – Used when no specific slave is targeted. On a one-slave bus, this
command is sufficient for addressing. On a multiple-slave bus, this command can be
used to address all devices at once. This is only useful when sending commands to slave
devices, e.g. to start temperature conversions on several temperature sensors at once. It is
not possible to use the SKIP_ROM command when reading from slave devices on a
multiple-slave bus.
OD_SKIP_ROM – This command is similar to the SKIP_ROM command but it not only
selects devices, it also sets those devices to the Overdrive communication rate. This is
most often used to set all capable 1 – Wire® slave devices to Overdrive speed. After the
devices are communicating in Overdrive, the ROM IDs can be discovered using the
conventional Search Rom sequence.
OD_MATCH_ROM – This command is identical to the MATCH_ROM command but it
also switches the device to the Overdrive communication speed.
132

A data access instruction may be one of the following: WRITE_SP (0x0F), READ_SP
(0xAA), COPY_SP (0x55), and READ_MEM (0xF0).
WRITE_SP – The Write Scratchpad command applies to the data memory and the
writeable addresses in the register page of 1 – Wire® slave devices. After issuing the
Write Scratchpad command, the bus master must provide a 2-byte target address
followed by the data to be written to the scratchpad.
READ_SP – The Read Scratchpad command allows the 1 – Wire® Master to read the
contents of the scratchpad. The data transfer starts with the least significant bit of byte 0
and continues through the scratchpad until the ninth byte (byte 8 – CRC) is read. The 1 –
Wire® Master may issue a reset to terminate at any time if only part of the scratchpad
data is needed.
COPY_SP – The Copy Scratchpad command is used to copy data from the scratchpad of
the slave device to the memory of the slave device. After issuing the copy scratchpad
command, the master must provide a 3-byte authorization pattern which is obtained by
reading the scratchpad for verification.
READ_MEM – The Read Memory command is used to read data from 1 – Wire® slave
devices that support EEPROM. The bus master follows the command byte with a two
byte address that indicates a starting byte location within the EEPROM data field. With
every subsequent read data time slot, the bus master receives data starting at the initial
address and continuing until the end of the EEPROM data field is reached or until a Reset
Pulse is issued.
133

5.2.8.1 Single Search ROM (single_search_rom) Test
This test checks the Search ROM Accelerator algorithm described in section 2.3.6 and
also proper operation of the device addressing instruction READ_ROM (0x33). For this test
configuration there is a single 1 – Wire® slave device on the network with an Altera DE2
Development and Education board serving as the 1 – Wire® Master. Figure 5.10 shows the
setup configuration used to conduct this test. Any configurable FPGA I/O pin on the DE2 board
can serve as the 1 – Wire® Master I/O pin. Multiple iButton Probe Cables were used to test
connectivity of a variety of 1 – Wire® slave devices (both single and multi-function), including
parasitically and non-parasitically powered slaves. Additionally, while conducting the test, the 1
– Wire® devices listed in Table 5.4 were hot swapped to ensure reliability and integrity in the
design of the 1 – Wire® network. The test results, summarized in Table 5.4, verified that the
correct single ROM_ID was found by the Search ROM Accelerator algorithm.
Figure 5.10 Single Search ROM Test Setup.
Table 5.4 Single Search ROM (single_search_rom) Test Results.
1 – Wire® Device Type 1 – Wire Probe Cables Length of test Hot Swapped Failures
DS1990A[77]/DS1990R[78] DS9092L[79], DS1402-
Yes None
DS1994[82] BR8+[80] with DS1401-4[81],
Yes None
DS1996[83] DS1402D-DR8+[80],
30 min
Yes None
DS1904[84] DS1402-RP8+[80], DS1402-
Yes None
DS1972[85] RP3+[80]
Yes None
DS1822-PAR 1 [86]/ DS2431 1 [87] See Note 1 30 min Yes None
1
This device is a 3-pin TO-92 Package and was interfaced utilizing a breadboard.
134

5.2.8.2 Multiple One-Wire Network (multi_ow_network) Test
The multi_ow_network test is an extension of the single_search_rom test conducted in
section 5.2.8.1. To perform this test, three 1 – Wire® slave devices, each from a different family
code, were connected in the test configuration shown in Figure 5.11. Again for this test
configuration, the Altera DE2 Development and Education board serves as the 1 – Wire®
Master. Any configurable I/O pin on the DE2 board can serve as the 1 – Wire® Master I/O pin.
The three slave devices were connected to the 1 – Wire Master using a DS1402-BR8+ 1 –
Wire® network cable [80] in conjunction with a DS1401-4 front panel iButton holder [81].
While conducting the test, the 1 – Wire® devices listed in Table 5.5 were hot swapped (one, two,
and three at a time) to ensure proper operation of the 1 – Wire® network and that no additional
pull-up or drive circuitry was needed. The test results, summarized in Table 5.5, verified that the
correct ROM_IDs were found by the Search ROM Accelerator algorithm.
Figure 5.11 Multiple One-Wire Network Test Setup.
Table 5.5 Multiple One-Wire Network (multi_ow_network) Test Results.
1 – Wire® Device Type 1 – Wire Probe Cables Length of test Hot Swapped Failures
DS1990A[77]/DS1990R[78]
Yes None
DS1994[82]
DS1996[83]
DS1904[84]
DS1402-BR8+[80] with
DS1401-4[81]
60 min
Yes
Yes
Yes
None
None
None
DS1972[85] Yes None
135

5.2.8.3 Scratchpad Memory (scratchpad_integrity) Test
The scratchpad memory in a 1 – Wire® slave device is written to and read from using the
WRITE_SP (0x0Fh) and READ_SP (0xAAh) commands. The eight bytes of data being written
are random and are stored at the bus functional model (i.e. Verilog® code software) while also
being written to the one_wm block and sent across to the 1 – Wire® slave device. The data
written to the slave device is then read back and compared to the previously stored value in the
bus functional model. This test also verifies proper operation of the device addressing
instruction SKIP_ROM (0xCC).
For the eight bytes of random data the Verilog® statistical function $random() was used.
The $random() function returns a new 32-bit random number each time it is called. The return
type is a signed integer. An optional seed_expression can be used to control the random number
generation and must be a signed integer value, a register, or a time variable. Additionally the
modulus operator % can be used to restrict the return value (i.e. for b > 0,
$random(seed_expression) %b will restrict the random number returned to (-b + 1) : (b – 1) [88].
For this test only a single 1 – Wire® slave exists on the 1 – Wire® network. Figure 5.12
shows the setup configuration used to conduct this test. Just like the previous test cases, any
configurable FPGA I/O pin on the Altera DE2 Development and Education board can serve as
the 1 – Wire Master I/O pin. Only 1 – Wire® devices having an internal scratchpad area in
memory were used to conduct this test (See Table 5.6). As was done in the previous tests, the 1
– Wire® devices listed in Table 5.6 were hot swapped during execution of the test to check for
data integrity and failures in the design of the 1 – Wire® network. The test results, summarized
in Table 5.6, verified that the correct single ROM_ID was found by the Search ROM Accelerator
136

algorithm. In addition to this, correct operation was also tested for the WRITE_SP (0x0Fh),
READ_SP (0xAAh), and SKIP_ROM (0xCC) commands.
Figure 5.12 Scratchpad Memory Test Setup.
Table 5.6 Scratchpad Memory (scratchpad_integrity) Test Results.
1 – Wire® Device Type 1 – Wire Probe Cables Length of test Hot Swapped Failures
DS1963S[89]
Yes No
DS1994[82] Yes No
DS1996[83] DS1402-RP8+[80] 60 min
Yes No
DS1995[90] Yes No
DS1972[85] Yes No
Not to be misleading, the absence of failures in Table 5.6 is only due to the fact that a
single 1 – Wire® device exists and the SKIP_ROM (0xCC) command was used instead of the
READ_ROM (0x33) command. The SKIP_ROM (0xCC) command can save time in a single
slave system by allowing the 1 – Wire® Master to access the memory functions without
providing the 64-bit ROM_ID code. So in this case hot swapping would be successful since the
1 – Wire® Master would not care about the 1 – Wire® slave device ROM_ID code it was
addressing. If more than a single 1 – Wire® slave device had been present on the 1 – Wire®
network, it is possible that failures could have occurred. Since the SKIP_ROM (0xCC)
command is typically used to select all devices regardless of their ROM_ID, more testing under
circumstances with multiple 1 – Wire® slave devices is needed for conclusive evidence on
failure rates in this case.
137

5.2.8.4 Command Recognition (cmd_recognition) Test
This test checks all of the basic commands shared by almost every family of 1 – Wire®
devices available on the commercial market today. These commands include: READ_ROM
(0x33), SKIP_ROM (0xCC), MATCH_ROM (0x55), SEARCH_ROM (0xF0), WRITE_SP
(0x0F), READ_SP (0xAA), OD_SKIP_ROM (0x3C), OD_MATCH_ROM (0x69), COPY_SP
(0x55), and READ_MEM (0xF0). The command recognition test also checks 1 – Wire® reset,
overdrive reset, strong pullup enable, active high and low interrupts and some of the divisor
clock frequencies from 4 MHz up to 112 MHz (see Table 5.2).
Due to the amount of time required to run a complete test with all commands and full
range of clock frequencies, there is only a single 1 – Wire® slave device on the network. Only 1
– Wire® devices capable of supporting overdrive speeds and having an internal scratchpad area
in memory were used to conduct this test (See Table 5.7). The setup configuration, shown in
Figure 5.12, uses any configurable I/O pin on the Altera DE2 Development and Education board
to serve as the 1 – Wire® Master. Unlike the other tests run in sections 5.2.8.1 – 5.2.8.3, hot
swapping of 1 – Wire® slave devices was not performed while running this test. The main goals
of this test were to check the functionality and reliability of the different 1 – Wire® commands,
as listed above, and the commands required to have a reliable 1 – Wire® Master capable of
driving long 1 – Wire® networks. The test results, summarized in Table 5.7, verified correct
operation.
Table 5.7 Command Recognition (cmd_recognition) Test Results.
1 – Wire® Device Type 1 – Wire Probe Cables Length of test Hot Swapped Failures
DS1963L[91]
~120 min No No
DS1921G[92] ~120 min No No
DS1996[83]
DS1995[90]
DS1402-RP8+[80]
~120 min
~120 min
No
No
No
No
DS1977[93] ~120 min No No
DS1922L[94] ~120 min No No
138

5.3 CAN (Controller Area Network) FPGA Implementation
For the FPGA implementation of the CAN Controller, the Bosch VHDL Reference System
was used as a guide and verification test tool. Some of the features incorporated into the design
are:
Implementation of the Basic CAN specification.
Receiving and transmitting of 11 and 29-bit identifiers.
Programmable baud rate prescaler (up to 1/256).
Up to 1 Mbit/sec speeds of operation.
Message based filtering and addressing.
Non-Destructive bitwise arbitration (CSMA/CA).
Readable Error Counters.
Maskable Error and Status Interrupts.
Figure 5.13 contains a block diagram of a CAN Controller showing only the major
blocks. It is designed to be memory-mapped into any system and is based on the Motorola
CAN (MCAN) Module [95 – 97]. All hardware modules necessary to implement the CAN
Transfer Layer (Bit Stream Processor and Bit Timing Logic) are included, representing the
kernel of the CAN bus protocol as defined by Bosch GmbH, the originators of the CAN
specification. From Figure 5.13, the hardware modules are defined as follows:
IML – The Interface Management Logic unit interprets the commands from the CPU,
controls allocation of both transmit and receive buffers, and supplies interrupts and status
information to the CPU via the Controller Interface Logic (CIL) Unit (See Figure 5.14).
139

TBF – The Transmit Buffer provides an interface between the CPU and the Bit Stream
Processor (BSP) and is able to store a complete message. The buffer is written by the
Figure 5.13 CAN Controller Block Diagram [98].
CPU and read by the BSP. The TBF is 10 bytes long and holds the identifier (1 byte), the
Control Field (1 byte) and the Data Field (maximum length of 8 bytes) (i.e., a complete
message and identifier).
RBF – The Receive Buffer is an interface between the BSP and the CPU and stores a
message received from the CAN bus line. Once filled by the BSP and allocated to the
CPU by the IML, the Receive Buffer cannot be used to store subsequent received
messages until the CPU has acknowledged the reading of the buffer’s contents. Thus,
unless the CPU releases an RBF within a protocol-defined time frame, future messages to
140

e received may be lost. To reduce the requirements on the CPU, two receive buffers
(RBF0 and RBF1) are implemented. While one receive buffer is allocated to the CPU,
the BSP may write to the other buffer. RBF0 and RBF1 are each 10 bytes long and hold
the Identifier (1 byte), the Control Field (1 byte) and the Data Field (maximum length of
8 bytes). The BSP only writes into a receive buffer when the message being received or
transmitted has an Identifier which passes the Acceptance Filter.
BSP – This is a sequencer controlling the data stream between the Transmit and Receive
Buffers (parallel data) and the CAN (serial data). The BSP also controls the
Transceive Logic (TCL) and the Error Management Logic (EML) such that the processes
of reception, arbitration, transmission and error signaling are performed according to the
protocol and the bus rules. The BSP also provides signals to the IML indicating when a
Receive Buffer contains a valid message and when the Transmit Buffer is no longer
required after a successful transmission. The automatic retransmission of messages,
which have been corrupted by noise or other external conditions on the bus line, is
effectively handled by the BSP.
BTL – The Bit Timing Logic block monitors the CAN bus line using an input
comparator and handles the CAN bus line related bit timing. The BTL synchronizes
on a recessive-to-dominant bus line transition at the Start of Frame (hard
synchronization), and resynchronizes on further transitions during reception of a frame
(soft synchronization). A programmable control bit in the CPU determines which edges
are used for resynchronization. The BTL also provides programmable time segments to
141

compensate for the propagation delay times and phase shifts and to define the sampling
time and the number of samples (1 or 3) within the bus time slot.
TCL – The Transceive Logic unit is a generic term for a group of logic elements
consisting of a programmable output driver, bit stuff logic, CRC logic and the transmit
shift register. The coordination of these components is controlled by the BSP.
EML – The Error Management Logic unit is responsible for the error confinement of the
CAN module. It receives notification of errors from the BSP and then informs the
BSP, TCL, and IML about error statistics [98].
Up to the message level, the CAN module presented here is totally compatible with
CAN Specification 2.0 Part A. The functional differences are related to the object layer only.
Whereas a full CAN Controller provides dedicated hardware for handling a set of messages,
the implementation presented here is restricted to receiving and/or transmitting messages on a
message by message basis. Also, the controller presented here will never initiate an Overload
Frame. If the module starts to receive a valid message (i.e., one that passes the Acceptance
Filter) and there is no receive buffer available for it, then the Overrun Flag in the CPU Status
Register will be set. The module, will however, respond to Overload Frames generated by other
CAN nodes, as required by the CAN protocol specifications.
To be able to function as a serial communication interface, the CAN Controller
Module, shown in Figure 5.13, itself has to be supplemented by an additional module, the
Controller Interface Logic Unit (CIL). The CIL is an integral part of any CAN system or
stand-alone CAN Controller. The CIL, shown in Figure 5.14, links the CAN Module to the
142

CPU or external microcontroller and connects the CPU busses to the CAN busses. It also
generates internal control signals from internal CPU signals.
Figure 5.14 Controller Interface Logic Unit (CIL) [95 – 96].
The control lines are comprised of a reset input line and an interrupt line. In addition to
the control lines are the 8-bit multiplexed address/data bus lines. Together these lines, which are
tied back to the IML Unit of the CAN Controller Module, aid in the interpretation of
commands from the CPU, help control the allocation of the message buffers (both Tx and Rx),
and supply interrupt and status information to the CPU via the CIL.
5.3.1 Register Map and Address Allocation
The CAN Controller Module memory map is shown in Figure 5.15. There are three
main register blocks discussed here: control registers (10 bytes), transmit buffer (10 bytes), and
receive buffer (10 bytes). The individual registers in each of these blocks will be described in
the sections to follow.
143

Figure 5.15 CAN Module memory map [95 – 96].
5.3.2 CAN Module Control Registers Overview
The interchange of commands, status and control signals between the microprocessor and
the CAN Module takes place via the control registers. The layout of these registers is shown
in Table 5.8.
144

Table 5.8 Control Registers [95 – 96].
Register Address Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Control (CCNTRL) 10h X SPD X OIE EIE TIE RIE RR
Command (CCOM) 11h RX0 RX1 COMP-SEL SLEEP COS RRB AT TR
Status (CSTAT) 12h BS ES TS RS TCS TBA DO RBS
Interrupt (CINT) 13h X X X WIF OIF EIF TIF RIF
Acceptance code (CACC) 14h AC7 AC6 AC5 AC4 AC3 AC2 AC1 AC0
Acceptance mask (CACM) 15h AM7 AM6 AM5 AM4 AM3 AM2 AM1 AM0
Bus timing 0 (CBT0) 16h SJW1 SJW0 BRP5 BRP4 BRP3 BRP2 BRP1 BRP0
Bus timing 1 (CBT1) 17h SAMP TSEG-22 TSEG-21 TSEG-20 TSEG-13 TSEG-12 TSEG-11 TSEG-10
Output Control (COCNTRL) 18h OCT-P1 OCT-N1 OCPOL1 OCT-P0 OCT-N0 OCPL0 OCM1 OCM0
Test Register 19h X X X X X X X X
Note: The acceptance code register, acceptance mask register, bus timing register 0, bus timing
register 1 and the output control register are only accessible when the RESET REQUEST
(RR) bit in the CAN control register (CCNTRL) is set. It is not foreseen that these
registers will be referenced again after the initial reset sequence [95].
5.3.3 CAN Module Control Register (CCNTRL)
The Control Register, shown in Figure 5.16, provides the local mask bits for the CAN
Module interrupts. In addition, it contains the Reset Request (RR) bit, which is set to disable the
CAN Module operation and allow access to the message filtering, bus timing and output
control registers [96]. This register may be read or written by the microprocessor; only the RR
bit is affected by the CAN Module.
Figure 5.16 CAN Control Register.
SPD: Speed Mode. When this bit is set to ‘1’, slow speed mode will be used for
resynchronization. Bus line transitions from both recessive to dominant and from
dominant to recessive will be used for resynchronization. When this bit is cleared, set to
145

‘0’, fast speed mode will be used for resynchronization. Only transitions from recessive
to dominant will be used for resynchronization.
OIE: Overrun Interrupt Enable. Setting this bit to a ‘1’ enables the CPU to get an
interrupt request whenever the Overrun Status bit gets set. Setting this bit to a ‘0’ will
prevent the CPU from getting an overrun interrupt request.
EIE: Error Interrupt Enable. Setting this bit to a ‘1’ enables the CPU to get an interrupt
request whenever the error status or bus status bits in the CSTAT register change. Setting
this bit to a ‘0’ disables the CPU from receiving error interrupt requests.
TIE: Transmit Interrupt Enable. If enabled (set to a ‘1’), the CPU will get an interrupt
request whenever a message has been successfully transmitted, or when the transmit
buffer is accessible again following an ABORT command. If disabled (set to a ‘0’), the
CPU will not get a transmit interrupt request.
RIE: Receive Interrupt Enable. Setting this bit to a ‘1’ will enable the CPU to get an
interrupt request whenever a message has been received free of errors. If set to a ‘0’, the
CPU will not get a receive interrupt request.
RR: Reset Request. If the RR bit is set, the CAN Module aborts the current
transmission or reception of a message and enters the reset state. A reset request may be
generated by an external reset, by the CPU, or by the CAN Module itself. The RR bit
can only be cleared by the CPU. After the RR bit has been cleared, the CAN Module
will begin normal operation in one of two ways. If RR was generated by an external reset
or by the CPU, then the CAN Module starts normal operation after the first occurrence
of 11 recessive bits. If, however, the RR was generated by the CAN Module due to the
146

BS (CAN Status Register (CSTAT) Bus Status bit) bit being set, the CAN Module
waits for 128 occurrences of 11 recessive bits before starting normal operation.
5.3.4 CAN Module Command Register (CCOM)
The Command Register, shown in Figure 5.17, is a write only register which contains the
Release Receive Buffer (RRB) and Transmit Request (TR) bits. Bits RX0, RX1, and COMP-
SEL are used to control the input comparator configuration, allowing it to operate correctly for
single-wire (not implemented yet) and differential modes of operation [96]. A read of this
register location will always return a value of $FF. This register may be written only when the
RR bit in CCNTRL is clear.
Figure 5.17 CAN Command Register.
RX0: Receive Pin 0. When this bit is set to a ‘1’, VDD/2 will be connected to the input
comparator. The RX0 pin is disconnected. When this bit is set to a ‘0’, the RX0 pin will
be connected to the input comparator. VDD/2 is then disconnected.
RX1: Receive Pin 1. Setting this bit to a ‘1’ will connect VDD/2 to the input comparator
and disconnect the RX1 pin. Setting this bit to a ‘0’ will connect the RX1 pin to the input
comparator and disconnect VDD/2. If, however, both RX0 and RX1 are set, or both are
clear, then neither of the RX pins will be disconnected.
147

COMP-SEL: Comparator Select. When this bit is set to a ‘1’, RX0 and RX1 will be
compared with VDD/2 during sleep mode. Setting this bit to a ‘0’ will cause RX0 to be
compared with RX1 during sleep mode.
SLEEP: Sleep Mode. Setting this bit to a ‘1’ will cause the CAN Module to enter
sleep mode, as long as there are no interrupts pending and there is no activity on the bus.
Otherwise, the CAN Module will issue a wake-up interrupt. Setting this bit to a ‘0’
will cause the CAN Module to function normally. If the SLEEP bit is cleared by the
CPU, then the CAN Module will wake up, but will not issue a wake-up interrupt. If
the SLEEP bit gets set during the reception or transmission of a message, the CAN
Module will generate an immediate wake-up interrupt. This will have no effect on the
transfer layer (i.e., no message will be lost or get corrupted). Any node that was sleeping
and has been awakened by bus activity will not be able to receive any messages until its
oscillator has started and it has found a valid end of frame sequence (11 recessive bits).
COS: Clear Overrun Status. Setting this bit to a ‘1’ clears the read-only overrun status
bit in the CSTAT (CAN Status Register) register. It may be written at the same time as
the Release Receive Buffer (RRB) bit. Setting this bit to a ‘0’ causes no action to be
performed.
RRB: Release Receive Buffer. When set to a ‘1’, this bit releases the receive buffer
attached to the CPU, allowing the buffer to be reused by the CAN Module. This may
result in another message being received, which could cause another receive interrupt
request (if RIE is set). This bit is cleared automatically when a message is received, i.e.
148

when the RS bit (see CSTAT register – Section 5.3.5) becomes set. Setting this bit to a
‘0’ causes no action to be performed.
AT: Abort Transmission. When this bit is set to a ‘1’, a pending message transmission
will be cancelled if it is not already in progress. This allows the transmit buffer to be
loaded with a new, higher priority message when the buffer is released. If the CPU tries
to write to the buffer when it is locked, the information will be lost without being
signaled. The status register can be checked to see if transmission was aborted or is still
in progress. Setting this bit to a ‘0’ has no effect.
TR: Transmission Request. When this bit is set to a ‘1’, a data frame or a remote frame
will be transmitted depending on the transmission buffer’s contents. Setting this bit to a
‘0’ has no effect. It will not cancel a previously requested transmission; the abort
transmission request bit must be used to do this.
5.3.5 CAN Module Status Register (CSTAT)
The Status Register, shown in Figure 5.18, provides information on a number of
conditions which can occur in the CAN Module. This includes information on the status of
the last requested transmission, incoming messages and the availability of the Transmit Buffer
for acceptance of new messages for transmission. It also provides a flag to indicate the module
‘off bus’ state and provides limited information on the status of the error counters [96]. This
register is a read only register and only the CAN Module can change its contents.
149

Figure 5.18 CAN Status Register.
BS: Bus Status. This bit is set to a ‘1’ (off-bus) by the CAN Module when the transmit
error counter reaches 256. The CAN Module will then set the RR bit (CCNTRL
Register) and will remain off-bus until the CPU clears RR again. At this point the
CAN Module will wait for 128 successive occurrences of a sequence of 11 recessive
bits before clearing the BS bit and resetting the read and write error counters. While in
the off-bus state, the CAN Module does not take part in bus activities. A value of ‘0’
means the CAN Module is operating normally.
ES: Error Status. This bit is set automatically to a ‘1’ when either the read or the write
error counter has reached the predefined CPU warning limit of 127. A value of ‘0’
indicates that neither of the error counters has reached the predefined warning limit.
TS: Transmit Status. The CAN Module will set this bit to a ‘1’ when it has started to
transmit a message. If, in addition to this bit having a value of ‘0’, the Receive Status bit
(RS) is also clear, then the CAN Module is idle; otherwise it is in receive mode.
RS: Receive Status. This bit is set to a ‘1’ when the CAN Module has entered the
receive mode from idle, or by losing arbitration during message transmission. If the
Transmit Status bit (TS) is also clear, then the CAN Module is idle; otherwise it is in
transmit mode.
TCS: Transmit Complete Status. This bit is cleared by the CAN Module when the TR
bit is set (bit 0 CCOM register). When TCS is set to a ‘1’, it indicates that the last
150

equested transmission was successfully completed. If, after TCS is cleared, but before
transmission begins, an abort transmission command is issued then the transmit buffer
will be released and TCS will remain clear. TCS will then only be set after a further
transmission is both requested and successfully completed.
TBA: Transmit Buffer Access. When clear, the transmit buffer is locked and cannot be
accessed by the CPU. This indicates that either a message is being transmitted or is
awaiting transmission. If the CPU writes to the transmit buffer while it is locked, then
the data will be lost without this being signaled. While set to a ‘1’, the transmit buffer
may be written to by the CPU.
DO: Data Overrun. While clear, this bit indicates normal operation. This bit is set when
both receive buffers are full and there is a further message to be stored. In this case the
new message is dropped, but the internal logic maintains the correct protocol. The
CAN Module does not receive the message, but no warning is sent to the transmitting
node. The CAN Module clears the DO bit when the CPU sets the COS bit in the
CCOM register. Data overrun can also be caused by a transmission, since the CAN
Module will temporarily store an outgoing frame in a receive buffer in case arbitration is
lost during transmission.
RBS: Receive Buffer Status. This bit is set to a ‘1’ by the CAN Module when a new
message is available. When clear this indicates that no message has become available
since the last RRB (bit 2 of the CCOM register) command. The bit is cleared when RRB
is set. However, if the second receive buffer already contains a message, then control of
151

that buffer is given to the CPU and RBS is immediately set again. The first receive
buffer is then available for the next incoming message from the CAN Module.
5.3.6 CAN Module Interrupt Register (CINT)
The CAN Module has only one interrupt vector assigned to it. The Interrupt Register,
shown in Figure 5.19, can be read to determine the source of a CAN interrupt. The five
interrupt sources include: Wake Up, Data Overrun (a third message being received before either
of the Receive Buffers have been released), Error (either read or write error counter reaching a
pre-determined level), Transmission Complete, and Receive Interrupt [96]. All bits of this
register are read only; all are cleared by a read of this register. However, this register must be
read in the interrupt handling routine in order to enable further interrupts.
Figure 5.19 CAN Interrupt Register.
WIF: Wake-Up Interrupt Flag. If the CAN module detects bus activity while it is in
the SLEEP state, it clears the SLEEP in the CCOM register; the WIF bit will then be set.
WIF is cleared by reading the CAN Interrupt Register (CINT), or by an external reset.
OIF: Overrun Interrupt Flag. When OIE (bit 4 of CCNTRL register) is set this bit will
be set when a data overrun condition is detected. Like all the bits in this register, OIF is
cleared by reading the register, or when an external reset request is set.
EIF: Error Interrupt Flag. When EIE (bit 3 of CCNTRL register) is set then this bit will
be set by a change in the error or bus status bits in the CAN module status register.
152

Like all the bits in this register, EIF is cleared by reading the register, or by an external
reset.
TIF: Transmit Interrupt Flag. The TIF bit is set at the end of a transmission whenever
both the TBA (bit 2 of CSTAT register) and TIE (bit 2 of CCNTRL register) bits are set.
Like all the bits in this register, TIF is cleared by reading the register, or when reset
request is set.
RIF: Receive Interrupt Flag. The RIF bit is set by the CAN Module when a new
message is available in the receive buffer, and the RIE bit in CCNTRL is set. At the
same time the RBS bit in the CSTAT register also gets set, indicating a new message is
available. Like all the bits in this register, RIF is cleared by reading the register, or when
reset request is set.
5.3.7 CAN Module Acceptance Code Register (CACC)
The Acceptance Code and Acceptance Mask Registers are used to provide limited
message filtering on the eight most significant bits of the identifier. The Acceptance Mask
Register defines which bits of the Acceptance Code Register are compared with the identifier of
the incoming message. If the CAN Module receives a message with an identifier which does
not meet its acceptance criterion, then it will respond by transmitting a dominant bit in the
correct position of the ACK field, but will not transfer the message to the receive buffers or
indicate to the CPU that a new message has been received [96].
On reception each message is written into the current receive buffer. The CPU is only
signaled to read the message however, if it passes the criteria in the Acceptance Code and
153

Acceptance Mask Registers (accepted); otherwise, the message will be overwritten by the next
message (dropped). Shown in Figure 5.20, this register can only be accessed when the RR bit in
the CCNTRL register is set.
Figure 5.20 CAN Acceptance Code Register.
AC7 – AC0: Acceptance Code Bits. These bits comprise a user defined sequence of bits
with which the 8 most significant bits of the message identifier (ID10 – ID3) are
compared. The result of this comparison is then masked with the Acceptance Mask
Register. Once a message has passed the acceptance criterion the respective identifier,
data length code and data are sequentially stored in a receive buffer, providing there is
one free. If there is no free buffer, the data overrun condition will be signaled. On
acceptance the receive buffer status bit is set to full and the receive interrupt bit is set
(provided RIE=enabled).
5.3.8 CAN Module Acceptance Mask Register (CACM)
The Acceptance Mask Register, shown in Figure 5.21, specifies which of the
corresponding bits in the Acceptance Code Register are relevant for acceptance filtering. This
register can only be accessed when the RR bit in the CCNTRL register is set. When a particular
bit in this register is clear, this indicates that the corresponding bit in the Acceptance Code
Register must be the same as its corresponding identifier bit, before a match will be detected.
The message will be accepted if all such bits match. When a bit is set, it indicates that the state
154

of the corresponding bit in the Acceptance Code Register will not affect whether or not the
message is accepted.
Figure 5.21 CAN Acceptance Mask Register.
5.3.9 CAN Module Bus Timing Register 0 (CBT0)
The CAN Bus Timing Registers are used to select a suitable baud rate prescaler value
to provide an appropriate system clock cycle time (tSCL) value, which is then used to derive the
bit time and position of the sample point within the bit. Figure 3.11 (See Section 3.6.1) shows
the components of the CAN Bit Time Segments. The Bus Timing Registers allow the two
values, TSEG1 and TSEG2, to be defined. TSEG1 is the sum of PHASE_SEG1 and the
PROP_SEG (See Equation 3.4). TSEG2 is equal to PHASE_SEG2 (See Equation 3.5). The Bus
Timing Registers also define the size of the RESYNCHRONIZATION JUMP WIDTH (See
Section 3.6.5). This is the amount by which a bit can be lengthened or shortened during the
resynchronization process.
register is set.
Shown in Figure 5.22, this register can only be accessed when the RR bit in the CCNTRL
Figure 5.22 CAN Bus Timing Register 0.
155

SJW1, SJW0: Synchronization Jump Width Bits. The synchronization jump width
defines the maximum number of system clock cycles (tSCL) by which a bit may be
shortened, or lengthened, to achieve resynchronization on data transitions on the bus (See
Table 5.9).
Table 5.9 Synchronization Jump Width (SJW) [95].
SJW1 SJW0 Synchronization Jump Width
0 0 1 tSCL cycle
0 1 2 tSCL cycles
1 0 3 tSCL cycles
1 1 4 tSCL cycles
BRP5 – BRP0: Baud Rate Prescaler Bits. These bits determine the CAN system clock
cycle time (tSCL), which is used to build up the individual bit timing. This is shown in
Table 5.10 and Figure 5.23.
Table 5.10 Baud Rate Prescaler.
BRP5 BRP4 BRP3 BRP2 BRP1 BRP0 Prescaler Value (P)
0 0 0 0 0 0 1
0 0 0 0 0 1 2
0 0 0 0 1 0 3
0 0 0 0 1 1 4
: : : : : : :
: : : : : : :
1 1 1 1 1 1 64
156

Figure 5.23 CAN Module Oscillator Block Diagram [95].
5.3.10 CAN Module Bus Timing Register 1 (CBT1)
This register, shown in Figure 5.24, can only be accessed when the RR bit in the
CCNTRL register is set.
Figure 5.24 CAN Bus Timing Register 1.
SAMP: Sampling. This bit determines the number of samples of the bus to be taken per
bit time. When set to a ‘1’, three samples per bit are taken. This sample rate gives better
rejection of noise on the bus, but introduces a one bit delay to the bus sampling. For
higher bit rates SAMP should be cleared, which means that only one sample will be taken
per bit.
157

TSEG22 – TSEG10: Time Segment Bits. Time segments within the bit time fix the
number of clock cycles per bit time and the location of the sample point. Time Segment
TSEG1 and Time Segment TSEG2 are programmable as shown in Table 5.11.
Table 5.11 Time Segment Values.
TSEG13 TSEG12 TSEG11 TSEG10 Time Segment 1 TSEG22 TSEG21 TSEG20 Time Segment 2
0 0 0 1 2 tSCL cycles 0 0 1 2 tSCL cycles
0 0 1 0 3 tSCL cycles : : :
0 0 1 1 4 tSCL cycles : : :
: : : : : 1 1 1 8 tSCL cycles
: : : : :
1 1 1 1 16 tSCL cycles
The bit time is determined by the oscillator frequency, the baud rate prescaler, and the
number of bus clock cycles (tSCL) per bit. From Section 3.6.1, the bit time is calculated as shown
in Equation 5.1:
BIT _TIME SYNC _ SEG TSEG1 TSEG2
(5.1)
TSEG2 must be at least 2*tSCL, i.e. the configuration bits must not be 000. (If three samples per
bit mode is selected then TSEG2 must be at least 3*tSCL.) TSEG1 must be at least as long as
TSEG2. The Synchronization Jump Width (SJW) may not exceed TSEG2, and must be at least
tSCL shorter than TSEG1 to allow for physical propagation delays.
i.e. in terms of tSCL:
SYNC _SEG1 TSEG1SJW1 TSEG1TSEG2 TSEG2 SJW
and TSEG2 2 SAMP 0
or TSEG2 3 SAMP 1
These boundary conditions result in minimum bit times of 5*tSCL, for one sample per bit, and
7*tSCL, for three samples per bit.
158

5.3.11 CAN Module Output Control Register (COCNTRL)
The Output Control Register (COCNTRL), shown in Figure 5.25, is used to determine
the configuration of the output drivers on the CAN transmit pins. The Output Control Mode
bits allow normal differential operation, bi-phase operation, or a special test mode to be selected
(not fully implemented yet). The output drivers can be selected for pull up, pull down, or push-
pull operation by selectively enabling or disabling P type and N type transistors in the output
driver circuits via the OCTN0/1 and OCTP0/1 bits. The COCNTRL register also allows the data
output to be inverted if required. Normal configuration is for complementary levels to be
transmitted on the TX0 and TX1 pins (two-wire differential operation). The bus termination
network should ensure that the bus reverts to its recessive state when the driver transistors are
switched off [96].
Figure 5.25 CAN Output Control Register.
OCM1 – OCM0: Output Control Mode Bits. The values of these two bits determine the
output mode, as shown in Table 5.12.
Table 5.12 Output Control Modes.
OCM1 OCM0 Function
0 0 Bi-phase operation mode
0 1 Test mode (not fully implemented)
1 0
Normal mode 1
1 1
Bit stream transmitted on both TX0 and TX1
Normal mode 2
TX0 – bit sequence
TX1 – bus clock (ttxclk)
159

The transmit clock (ttxclk) is used to indicate the end of the bit time and will be high
during SYNC_SEG. For all the following modes of operation, a dominant bit is
internally coded as a zero, a recessive as a one. The other output control bits are used to
determine the actual voltage levels transmitted to the CAN bus for dominant and
recessive bits.
Bi-phase mode: If the CAN Module is isolated from the bus lines by a transformer
then the bit stream has to be coded so that there is no resulting dc component. There is a
flip-flop (Toggle) within the CAN Module that keeps the last dominant configuration;
its direct output goes to TX0 and its complement to TX1. The flip-flop is toggled for
each dominant bit; dominant bits are thus sent alternately on TX0 and TX1 (i.e. the first
dominant bit is sent on TX0, the second on TX1, the third on TX0, and so on). During
recessive bits, all output drivers are deactivated (i.e. high impedance).
Normal Mode 1: In contrast to bi-phase mode, the bit representation is time invariant and
not toggled.
Normal Mode 2: For the TX0 pin this is the same as Normal Mode 1, however, the data
stream to TX1 is replaced by the transmit clock. The rising edge of the transmit clock
marks the beginning of a bit time. The clock pulse will be tSCL long [95].
Other Output Control Bits: The other six bits in this register, shown in Table 5.13,
control the output driver configurations, to determine the format of the output signal for a
given data value.
160

Table 5.13 Output Control Bits.
Bit Name Description
OCTP0/1 These two bits control whether the P-type output control transistors are enabled.
OCTN0/1 These two bits control whether the N-type output control transistors are enabled.
OCPOL0/1 These two bits determine the driver output polarity for each of the CAN bus lines (TX0, TX1).
TP0/1 These are the resulting states of the output transistors.
TD
This is the internal value of the data bit to be transferred across the CAN bus.
(A zero corresponds to a dominant bit, a one to a recessive.)
The actions of these bits in the Output Control Register are summarized in Table 5.14.
Table 5.14 CAN driver output levels [95].
Mode TD OCPOLi OCTPi OCTNi TPi TNi TXi Output Level
Float
Pull-down
Pull-up
Push-pull
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
0
1
1
0
0
1
1
0
0
1
1
0
0
1
1
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
161
0
0
0
0
1
1
1
1
0
0
0
0
1
1
1
1
Off
Off
Off
Off
Off
Off
Off
Off
Off
On
On
Off
Off
On
On
Off
5.3.12 CAN Module Transmit Buffer Registers Overview
Off
Off
Off
Off
On
Off
Off
On
Off
Off
Off
Off
On
Off
Off
On
Float
Float
Float
Float
Low
Float
Float
Low
Float
High
High
Float
Low
High
High
Low
The Transmit Buffer acts as interface between the CPU and the Bit Stream Processor
(BSP). It is ten bytes long and is capable of storing a complete message plus message identifier.
The layout of these registers is shown in Table 5.15.
Table 5.15 Transmit Buffer Registers.
Register Address Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Identifier (TBI) 20h ID10 ID9 ID8 ID7 ID6 ID5 ID4 ID3
RTR/DLC (TRTDL) 21h ID2 ID1 ID0 RTR DLC3 DLC2 DLC1 DLC0
DSB1 (TDS1) 22h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
DSB2 (TDS2) 23h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
DSB3 (TDS3) 24h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
DSB4 (TDS4) 25h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
DSB5 (TDS5) 26h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
DSB6 (TDS6) 27h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
DSB7 (TDS7) 28h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
DSB8 (TDS8) 29h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0

5.3.13 CAN Module Transmit Buffer Identifier Register (TBI)
The message ID’s must be unique on a CAN bus, otherwise two nodes would continue
transmission beyond the end of the arbitration field (ID), causing an error. Figure 5.26 shows the
CAN Transmit Buffer Identifier Register (TBI).
Figure 5.26 CAN Transmit Buffer Identifier Register.
ID10 – ID3: Identifier Bits. The identifier consists of 11 bits (ID10 – ID0). ID10 is the
most significant bit and is transmitted first on the bus during the arbitration procedure.
The priority of an identifier is defined to be highest for the smallest binary number. The
three least significant bits are contained in the TRTDL register (See Section 5.3.14). The
seven most significant bits must not all be recessive.
5.3.14 CAN Module Remote Transmission Request/Data Length Code Register (TRTDL)
The Remote Transmission Request and Data Length Code Register, shown in Figure
5.27, contains the bits responsible for setting the number of bytes or data byte count of the
respective CAN message and dictating to the CAN bus whether a remote frame or a data
frame will be transmitted.
Figure 5.27 CAN Remote Transmission Request/Data Length Code Register.
162

ID2 – ID0: Identifier Bits. These bits contain the three least significant bits of the
Transmit Buffer Identifier (TBI).
RTR: Remote Transmission Request. When set to a ‘1’, a remote frame will be
transmitted. When set to a ‘0’, a data frame will be transmitted.
DLC3 – DLC0: Data Length Code Bits. The Data Length Code contains the number of
bytes (data byte count) of the respective message. Upon transmission of a remote frame,
the Data Length Code is ignored, forcing the number of bytes to be zero. The data byte
count ranges from 0 – 8 for a data frame. Table 5.16 shows the effect of setting the DLC
bits.
Table 5.16 Data Length Code Bits.
Data Length Code Bits Data Byte
DLC3 DLC2 DLC1 DLC0 Count
0 0 0 0 0
0 0 0 1 1
0 0 1 0 2
0 0 1 1 3
0 1 0 0 4
0 1 0 1 5
0 1 1 0 6
0 1 1 1 7
1 0 0 0 8
5.3.15 CAN Module Transmit Data Segment Registers (TDS) 1 – 8
Depending upon the Data Length Code there may be up to eight data bytes transmitted as
part of a data frame. Figure 5.28 shows the register bit definitions for the Transmit Data
Segment Registers (TDS).
163

Figure 5.28 CAN Transmit Data Segment Registers.
DB7 – DB0: Data Bits. These data bits in the eight data segment registers make up the
bytes of data to be transmitted. The number of bytes to be transmitted is determined by
the Data Length Code bits (bits 3 – 0) as defined in the TRTDL Register (See Section
5.3.14).
5.3.16 CAN Module Receive Buffer Registers Overview
There are two full Receive Buffers (each ten bytes in length) used to handle all incoming
messages being passed from the BSP to the CPU. Each Receive Buffer is capable of storing an
entire message and has a layout identical to that of the Transmit Buffer. They are arranged in a
double buffered configuration, with each buffer occupying the same area of the memory map.
When the first buffer is filled it can be read by the CPU as a second incoming message is being
transferred by the BSP into the second buffer. After the CPU has read a message from the
Receive Buffer it can release that buffer, making it available for storing the next incoming
message and allowing the second buffer to be read once it contains a complete message. The
layout of these registers is shown in Table 5.17.
Table 5.17 Receive Buffer Registers.
Register Address Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Identifier (RBI) 30h ID10 ID9 ID8 ID7 ID6 ID5 ID4 ID3
RTR/DLC (RRTDL) 31h ID2 ID1 ID0 RTR DLC3 DLC2 DLC1 DLC0
DSB1 (RDS1) 32h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
DSB2 (RDS2) 33h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
DSB3 (RDS3) 34h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
DSB4 (RDS4) 35h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
DSB5 (RDS5) 36h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
DSB6 (RDS6) 37h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
DSB7 (RDS7) 38h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
DSB8 (RDS8) 39h DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
164

5.3.17 CAN Module Receive Buffer Identifier Register (RBI)
The layout and bit definitions for the Receive Buffer Identifier Register, shown in Figure
5.29, are identical to the TBI register (See Section 5.3.13).
Figure 5.29 CAN Receive Buffer Identifier Register.
5.3.18 CAN Module Remote Transmission Request/Data Length Code Register
(RRTDL)
The layout of this register, shown in Figure 5.30, along with the bit names and meanings
are identical to the TRTDL register as discussed in Section 5.3.14.
Figure 5.30 CAN Remote Transmission Request/Data Length Code Register.
5.3.19 CAN Module Receive Data Segment Registers (RDS) 1 – 8
The layout and bit definitions of these registers, shown in Figure 5.31, are identical to the
TDSx registers discussed in Section 5.3.15.
Figure 5.31 CAN Receive Data Segment Registers.
165

5.3.20 CAN Node Overview
As stated in Section 4.3.2, each individual CAN node is comprised of an 8-pin
Microchip PIC12CE674 microcontroller [42], an 18-pin Microchip MCP2515 Stand-Alone
CAN Controller [46], and an 8-pin Microchip MCP2551 High-Speed CAN transceiver [45].
Together these create a fully autonomous CAN node, which supports both “time-based” (in
the sense that messages are automatically transmitted from each CAN node every 500 ms) and
“event-driven” message transmission. Each individual node is interrupt driven and capable of
monitoring five external inputs (two analog and three digital) and automatically generating
messages based upon their value. The node also controls two digital outputs, responding to
message requests via the CAN network and generating a repeating, time-based message. Each
node is configured for a maximum CAN bus speed of 125 kbps, which is closest to the
overdrive speed of 1 – Wire® devices, and is capable of handling standard or extended frames.
Figure 5.32 shows the block diagram of one CAN node. There are two function
blocks. The first is the Control Logic block. This function is performed by the PIC12CE674
microcontroller. The PIC12CE674 was chosen because of the low pin count and powerful
feature set, including an internal oscillator; on-board, multi-channel, 8-bit analog-to-digital
converter (ADC); multiple interrupt sources; and low-power sleep mode. The second is the
CAN Interface block. This block is comprised of the MCP2515 CAN Controller and the
MCP2551 transceiver. The MCP2515 provides a full CAN 2.0 implementation with message
filtering, which relieves the host microcontroller from having to perform any CAN bus related
overhead. This is a key feature given the limited available code space of the PIC12CE674.
166

Figure 5.32 CAN Node Block Diagram.
Communication between the Control Logic block and the CAN Interface block makes
use of the MCP2515 device’s built-in support for the SPI protocol. The PIC12CE674 does not
have a hardware SPI interface, so the necessary functions are implemented in firmware.
Two external analog signals are tied directly to the analog input pins of the PIC12CE674.
An analog-to-digital (A/D) conversion is performed automatically for the Analog Channel 0
(AN0) based upon the internal timer setup, and the value is automatically transmitted over the
CAN bus when the conversion is completed.
The nodes also utilize the MCP2515 device’s multiple filters to respond to six additional
CAN Message Identifiers received via the CAN bus. The masks and filters are set to accept
messages into Receive Buffer 1 only. The identifiers are interpreted as one of the following,
depending upon which filter is matched:
Read Analog Channel 1Perform A/D conversion for Analog Channel 1 (AN1) and
initiate transmission of the value (ADRES) back to the requesting node.
167

Read Digital InputsRead the value of the MCP2515 input pins and transmit the value
back to the requesting node.
Update Digital Output 1Write the received value to the MCP2515 Digital Output 1.
Update Digital Output 2Write the received value to the MCP2515 Digital Output 2.
Check I/O StatusChange a CAN node unit’s address.
Change Unit AddressTurns off Digital Outputs 1 and 2. This can be done in case of an
emergency.
Since only Receive Buffer 1 is to be used, in order to take advantage of the greater number of
filters associated with that receive buffer, the Mask registers for Receive Buffer 0 must all be set
to a ‘1’. The filter bits must then be set to match an unused message identifier (typically all ‘0’
or all ‘1’).
As presented, the system requires that the messages intended for any of the CAN nodes
on the CAN bus have a standard identifier, which has a value of 0x3F0 – 0x3F5, with each of
the six filters configured to accept one of these messages. For the messages that the node
transmits back, it uses the same identifier as the received message, with the exception that the
ID3 bit is set to a ‘1’. Therefore, for example, when the ‘Read Analog Channel 1’ message is
received (ID = 0x3F0), the node transmits the data back using a message ID of 0x3F8. The time-
based message for the value of Analog Channel 0 is transmitted with an identifier of 0x3FE,
every 500 ms. In the event of a system error being detected, the system error message uses the
identifier, 0x3FF. Table 5.18 summarizes the various transmit and receive message identifiers
used. All transmitted messages use data byte 1 of the CAN message to hold the data to be
sent.
168

Table 5.18 CAN Node Message Identifiers.
ID Tx/Rx Description
3F0 Rx Read Analog Channel 1
3F1 Rx Read Digital Inputs
3F2 Rx Change Digital Output 1
3F3 Rx Change Digital Output 2
3F4 Rx Change Unit Address
3F5 Rx Turn Off Outputs
3F8 Tx Analog Channel 1 Value
3F9 Tx Current Values of Digital Inputs
3FA Tx 3F2 Command Acknowledgement
3FB Tx 3F3 Command Acknowledgement
3FC Tx 3F4 Command Acknowledgement
3FD Tx 3F5 Command Acknowledgement
3FE Tx Analog Channel 0 Value
3FF Tx System Error
The PIC12CE674 only has six available I/O pins, and all of these are used, two for analog
inputs and four (three SPIs and one INT ) to interface to the MCP2515. This requires the
system to take advantage of the internal RC oscillator of the PIC12CE674. The internal RC
oscillator provides a 4 MHz system clock to the microcontroller, which translates to a 1 µs
instruction cycle. The instruction cycle time directly affects the achievable speed of the SPI bus.
This, in turn, determines the interrupt latency time as the SPI communication makes up the
majority of the time required for the Interrupt Service Routine (ISR).
The standard SPI interface has been modified in this application to use a common signal
line for both Serial In (SI) and Serial Out (SO) lines, isolated from each other via a resistor. This
method requires only three I/O pins to implement the SPI interface, instead of the usual four.
Using this configuration does not support the Full-Duplex mode of SPI communications, which
is not an issue in this application. The system achieves an overall SPI bus rate of slightly more
than 80 kbps. The raw SPI clock rate averages 95 kbps. The clock low time is a fixed 5 µs, and
169

the clock high time is either 5 µs or 6 µs, depending upon whether a ‘0’ or a ‘1’ is being
sent/received, which gives a worst case (sending the value 0xFF) raw clock rate of 90.0 kbps
[47]. The overall effective speed achieved includes the additional software overhead of ‘bit-
banging’ the SPI protocol.
There are two interrupt sources in this CAN node system. The first is the PIC12CE674
Timer0 interrupt. This interrupt occurs approximately every 500 ms. The second interrupt
source is the INT pin of the PIC12CE674. This pin is connected to the INT output of the
MCP2515. This interrupt occurs any time a valid message is received or if the MCP2515 detects
a CAN bus related error. This external interrupt is completely asynchronous with respect to
the rest of the system.
It is necessary to carefully consider the interrupt latency requirements during the system
design/development phase. This CAN node system has two interrupt sources: the internal
timer interrupt, which occurs approximately every 500 ms, and the external INT pin interrupt,
which is generated by the MCP2515 CAN Controller and may occur at any time. The latency
time for the timer ISR is essentially fixed. This parameter is a function of the time it takes for
the ADC to perform a conversion on both channels, write the values to the transmit buffer, and
issue a Request To Send (RTS) command to the MCP2515, via the SPI interface. This takes
approximately 428 µs to complete.
The MCP2515 has three pins that are configured as general purpose inputs and two pins
that are configured as digital outputs. The inputs for each CAN node system are connected to
switch contacts and the outputs are connected to LED indicators. The MCP2515 inputs have
internal pull-up resistors and will read high when the attached switch is open and low when it is
170

closed. The MCP2515 also has two I/O pins ( RX0BF and RX1BF ) that can be configured as
general purpose outputs. These pins are configured as outputs, and are connected to LEDs to
function as indicator lights that are controlled via the CAN bus.
The CAN bus is configured to run at two distinct speeds; 10 kbps and 125 kbps. These
two speeds were chosen since they most closely mimic the speeds capable of 1 – Wire®
networks. The clock source for the MCP2515 is a standard, 8 MHz crystal connected to the
OSC1 and OSC2 inputs. The CAN physical layer is implemented using an industry standard
transceiver chip (e.g., Microchip MCP2551 [45]). This device supports CAN bus rates of up
to 1 Mbps and is more than adequate for the CAN node system presented here.
5.3.20.1 Firmware Description
The firmware is written in PIC® Microcontroller (MCU) assembly code. The relative
simplicity and small size of the CAN node system makes assembly language more than a
suitable choice. Figure 5.33 shows the top level flowchart for the overall CAN node system
operation. The PIC® MCU after going through self-initialization and initializing the MCP2515
goes to sleep and waits for an interrupt to occur. The following sections provide a more detailed
discussion of the operation of each of the major blocks in the firmware.
171

Yes
Perform A/D
Conversion on AN0
Write A/D Value to
MCP2515 Transmit
Buffer
Send Request to
Send Command to
MCP2515
Clear Interrupt Flags
in PIC12CE674
System POR
Initialize PIC MCU
and MCP2515
Sleep
Interrupt
Occurred?
Yes
Timer0
Interrupt?
172
No
Read MCP2515
Interrupt Flags
Error Interrupt?
No
Read MCP2515 Rx
Filters
Filter Match?
Yes
Process Request
Clear Interrupt Flags
in PIC12CE674 and
MCP2515
Figure 5.33 CAN Node Operation Flowchart [47].
No
Yes
No
Error Handler
Routine
System Error
(InvMsg)

5.3.20.2 PIC® MCU Initialization
Initialization of the PIC12CE674 is straightforward. There are three major functions that
need to be properly configured within the PIC12CE674:
General Purpose I/O (GPIO) pins
Timer0 module
A/D Converter module
Figure 5.34 shows the pin diagram and names for the PIC12CE674.
Figure 5.34 PIC12CE674 Pin Names [42].
The GPIO pins are the six I/O pins that are used to interface the PIC12CE674 to the
MCP2515 and sample the analog signals. The PIC® MCU OPTION, TRIS and INTCON
registers are used to control the setup of the GPIO pins. For the CAN nodes used in the
prototype system, the OPTION register is programmed to disable the internal pull-up resistors on
GP0/GP1/GP3. It also configures GP2 to generate an interrupt on the negative edge (to match
the MCP2515 device’s active low INT output). The TRIS register, which controls whether
each I/O pin is configured as an input or an output, is configured to set GP0/GP1/GP3 as inputs,
173

and GP2 and GP5 as outputs. With the exception of GP4, all of the GPIO pins remain in their
initially configured state. GP4 is changed between Input and Output mode, depending upon
whether an SPI read or write operation is being performed by the PIC12CE674. The final step of
configuring the port pins is to program the INTCON register to enable the interrupt-on-change
feature for GP2. This allows the MCP2515 to generate an interrupt to the PIC12CE674.
The Timer0 module operation is controlled by the OPTION register and the TMR0
register. The OPTION register contains the control bits for the Timer0 prescaler. The TMR0
register is the counting register for Timer0 and generates an interrupt when it rolls over from
0xFF to 0x00. This register must be reloaded as part of the ISR in order to correctly control the
time period between Timer0 interrupts. Initially for each CAN node the timer is set to rollover
every 62 ms. This is further expanded to every 500 ms by using a counter. This will reduce the
amount of traffic on the CAN bus, but on the down side will reduce the response time to a
change in the input.
The A/D conversion takes approximately 19 µs for the SPI communication to write the
A/D result to the MCP2515 transmit buffer. Then, the conversion sends the RTS command,
which requires approximately 409 µs to complete for a total of approximately 428 µs for the ISR
to execute. The Timer0 module is configured to use the FOSC/8 option for the conversion clock,
which gives a TAD value of 2 µs and an overall conversion time of 19 µs (TAD * 9.5). This is
more than fast enough compared to the amount of time spent on SPI communications during the
ISR.
174

5.3.20.3 MCP2515 Initialization
Before the system can communicate on the CAN bus, the MCP2515 must be properly
configured. The configuration of the MCP2515 is accomplished by loading the various control
registers with the desired values. The firmware is written to take advantage of the table read
functionality of the PIC® MCU. The values for each register are stored at the top of the PIC®
ROM memory. During the MCP2515 initialization, the values are sequentially read by the table
read function and then written to the MCP2515, via the SPI interface.
The CAN bit rate configuration is controlled by the CNF1, CNF2 and CNF3 registers.
The MCP2515 for each CAN node is configured to operate at a bus rate of 125 kbps using the
following parameters:
8 MHz oscillator
Baud rate prescaler equivalent to divide-by-4
8 TQ per bit time
Sync segment: 1 TQ
Prop segment: 1 TQ
Phase segment 1: 3 TQ
Phase segment 2: 3 TQ
Sync Jump Width: 1 TQ
5.3.20.4 Interrupt Service Routine
When an interrupt occurs, the PIC® MCU begins executing the ISR routine. Figure 5.35
shows the flowchart for the ISR. The ISR first determines the source of the interrupt, Timer0 or
175

external INT pin, and then branches to the appropriate section of code to process the interrupt.
Figures 5.36 and 5.37 show the program flow for the Timer0 and CAN message received
through interrupts, respectively.
Read MCP2515
CANINTF Register
___
Msg Rx INT?
No
CAN Bus Error?
No
Yes
System Error ___ (Invalid
INT)
Yes
Yes
ISR
___
INT Pin
Interrupt
Occurred?
CAN Msg Received
System Error (CANErr)
No
176
Timer0
Interrupt?
Yes
Timer0 Time-out
No
System Error ___ (Invalid
INT)
Figure 5.35 CAN Node Interrupt Service Routine Flowchart [47].
When the Timer0 interrupt occurs, as shown in Figure 5.3, the PIC® MCU initiates an
A/D conversion on AN0 constantly polling the ADDONE bit until the conversion process is
complete. Once the conversion is complete, the ADRES value is loaded into the MCP2515
Transmit Buffer 0, Data Byte 0, and an RTS command is issued for Buffer 0. The TMR0
register is then reloaded and the interrupt flag is cleared. The interrupts are then re-enabled by
the execution of the RETIE command at the end of the Timer0 ISR (See Figure 5.36).

When an interrupt is generated by the MCP2515, the PIC12CE674 reads the CANINTF
register of the MCP2515 to determine the source of the interrupt. If a valid message has been
received, then the MsgRcvd subroutine is executed (See Figure 5.37), and if an error has
occurred, the error handling subroutine is executed (See Figure 5.38).
Timer0 Time-out
Start Conversion on
AN0
Interrupt
Occurred?
Yes
Store AN0 Value into
RAM Variable
Load AN0 Value into
MCP2515 TxMsg
Buffer
Send RTS Command
to MCP2515
Clear Interrupt Flag
Reload Timer0
Re-enable Interrupts
(RETIE Command)
Exit ISR
Figure 5.36 Timer0 Interrupt Service Routine Flowchart [47].
177
No

Read MCP2515 Rx
Buffer for Digital
Output 1 Data
Update MCP2515
Digital Output
Control Register
Yes
Read MCP2515 Rx
Buffer for Digital
Output 2 Data
Store New Unit
Address in EEDATA
Register and Write
to EEPROM
Turn off Digital
Outputs 1 and 2
Yes
Yes
___
INT Pin
(CAN Msg Rx)
Read MCP2515 Rx
Filter
Filter Match = 1?
No
Filter Match = 2?
No
Filter Match = 3?
No
Filter Match = 4?
No
Filter Match = 5?
No
Filter Match = 6?
No
System Error
(InvMsg)
Clear Interrupt Flags
in PIC12CE674 and
MCP2515
Exit ISR
178
Yes
Yes
Read Value of Three
MCP2515 Digital
Inputs
Send RTS Command
to MCP2515
Figure 5.37 CAN Node Message Received Flowchart [47].
Perform A/D
Conversion on AN1
Write A/D Value to
MCP2515 Transmit
Buffer
Send RTS Command
to MCP2515

Error Handler
Read ERRIF Register
RxB1 Overflow?
No
Error Warning
Flag Set?
No
Rx Error
Passive Flag
Set?
No
Tx Error
Passive Flag
Set?
No
Bus-Off Flag
Set?
No
Send Error Message
0x3FF, Error Code =
0x13
Done
Yes
Yes
Yes
Yes
Yes
Yes
Send Error Message
0x3FF, Error Code =
0x11
Rx Warning
Flag Set?
Yes
Send Error Message
0x3FF, Error Code =
0x01
Send Error Message
0x3FF, Error Code =
0x03
Send Error Message
0x3FF, Error Code =
0x04
1 st Bus-Off
Occurrence?
Yes
Set Bus-Off Flag and
Re-Initialize
MCP2515
Send Error Message
0x3FF, Error Code =
0x12
Message
Transmitted
Successfully
Send Error Message
0x3FF, Error Code =
0x02
Figure 5.38 Error Handler Routine Flowchart [47].
179
No
No
No
Enter Idle State;
MCU must Reset
System Node

When a valid message is received, the FILHIT bits of the RXB1CTRL register are
read to determine which message has been received. Depending on the filter match number, they
are described as follows:
Filter 1The PIC® MCU initiates an A/D conversion on AN1, waits for the conversion
to complete, loads the ADRES register value into the MCP2515 Transmit Buffer 0 and
Data Byte 0, and sends the RTS command.
Filter 2The PIC® MCU reads the TXRTSCTRL register for the value of the three
input pins, loads this value into the MCP2515 transmit buffer and sends the RTS
command.
Filter 3 or 4The PIC® MCU reads the first byte of the received message and writes it
to the appropriate output pin via the MCP2515 BFPCTRL register.
Filter 5The PIC® MCU reads the first byte of the received message and stores the new
units address into the EEDATA register and write the new unit address into the
EEPROM.
Filter 6The PIC® MCU turns off Digital Outputs 1 and 2.
The system also provides for error detection for a number of different types of errors that
may occur, including CAN bus errors detected by the MCP2515, as well as invalid system
state errors (See Figure 5.38). When any of these errors are detected, the system transmits a
message with the ID of 0x3FF. This message contains one data byte which is a code used to
represent the type of error that occurred. The one exception to this is the Bus-Off condition that
the MCP2515 may enter if a large number of transmit errors are detected. If the Bus-Off
180

condition is detected, the PIC® MCU performs a re-initialization of the MCP2515 and then
attempts to transmit the error message (ID = 0x3FF) with an error code of 0x12. After initiating
a request to send for the error message, the PIC® MCU checks to ensure that the message was
transmitted successfully. If it was successfully transmitted, the PIC® MCU sets an internal flag
to indicate that a Bus-Off condition occurred and then resumes normal operation. If the error
message fails to transmit correctly, of if the Bus-Off condition is detected a second time, the
PIC® MCU automatically enters an Idle loop and remains there until a system Reset occurs via
power-on.
5.3.21 Verification of CAN Module
To verify the proper operation of the synthesizable CAN Controller, five test cases
were executed: Synchronization (test_synchronization), Bus Off (bus_off_test), Error Test
(error_test), Send Basic Frame Test (send_frame_basic), and Send Extended Frame Test
(send_frame_extended). All tests were compiled and simulated using Altera Quartus II 9.1 (32-
bit) and ModelSim Altera Starter Edition 6.6c software on a PC executing Windows XP Service
Pack 3. All tests were performed extensively while trying to cover all possible combinations of
data and I/O values for the CAN Controller. Only a few failures (most were attributed to the
addition and removal of nodes while tests were being conducted) were observed for any of the
five tests described below. The source code for all modules, testbench code, and simulation
results are located on the DVD included with this work. Table 5.19 shows the FPGA resource
utilization for the Altera DE2 Development and Education Board.
181

Table 5.19 Resource Utilization.
Revision Name CAN_Controller
Family Cyclone II
Device EP2C35F672C6
Timing Models Final
Met timing requirements Yes
Total logic elements 1560 / 33,216 ( 1 % )
Total combinational functions 1462 / 33,216 ( 1 % )
Dedicated logic registers 625 / 33,216 ( < 1 % )
Total registers 625
Total pins 19 / 475 ( 4 % )
Total virtual pins 0
Total memory bits 832 / 483,840 ( 0 % )
Embedded Multiplier 9-bit element 0 / 70 ( 0 % )
Total PLLs 0 / 4 ( 0 % )
5.3.21.1 Synchronization Test (test_synchronization)
All nodes on a CAN bus must have the same NBT. Since the CAN protocol is an
asynchronous serial bus with Non-Return to Zero (NRZ) bit coding; a clock is not encoded into
each message. The receivers must synchronize to the transmitted data stream to insure messages
are properly decoded. There are two methods used for achieving and maintaining
synchronization: hard synchronization and re-synchronization (Sections 3.6.4 – 3.6.5).
When synchronizing, there are five basic rules to follow to synchronize the receivers with
the transmitted data:
Only recessive-to-dominant edges will be used for synchronization.
Only one synchronization within one bit time is allowed.
An edge will be used for synchronization only if the value at the previous sample
point differs from the bus value immediately after the edge.
182

A transmitting node will not resynchronize due to propagation delays of its own
transmitted message. The receivers will synchronize normally.
If the absolute magnitude of the phase error is greater than the SJW, then the
appropriate phase segment will be adjusted by an amount equal to the SJW.
The synchronization test performs a hard synchronization by transitioning the rx line
from recessive to dominant (logic “1” to logic “0”) and then waits for ten bit times before
transitioning from dominant to recessive (logic “0” to logic “1”). Ten more bit times pass before
another transition occurs. This simulates a resynchronization on time. This test also simulates
early (two frames early) and late resynchronization (two frames and one frame late) before
finally performing another resynchronization on time. For this test, no physical CAN nodes
were connected to the Altera DE2 Development and Education Board. This test was performed
and verified using ModelSim to prove validity and integrity of the synthesizable CAN
Controller and Verilog® code modules.
5.3.21.2 Bus-Off Test (bus_off_test)
This test simulates a CAN node being in the Bus-Off state (See Figure 3.10). For this
to happen, a value of 256 is placed in the TEC, since receive errors cannot cause a CAN node
to go Bus-Off. While in this state, the CAN node cannot send or receive messages,
acknowledge messages, or transmit Error Frames of any kind. At the present, the only way for a
CAN node to leave this state is by a software reset.
183

For this test, only one CAN node was utilized. The test setup configuration is shown
in Figure 5.39. The node is comprised of the components discussed in Section 4.3.2. With only
one node on the bus, message filtering is not configured on the CAN node for this test. After
power-up, a value of 256 is written to the TEC for CAN node 1. CAN messages having
either an 11-bit ID or a 29-bit ID are written to CAN node 1 in an attempt to get a response
back from the node. Both ID sizes are used to ensure compliance with the CAN 2.0B
standard in which the CAN Module must be capable of receiving and transmitting extended
message frames, which use a 29-bit message identifier. Only two configurable pins are required
on the Altera DE2 board to perform this test. The test results are summarized in Table 5.20 and
verify proper operation of this test.
Figure 5.39 Bus-Off Test Setup.
184

Table 5.20 Bus-Off Test (bus_off_test) Results.
Speed(kbps) Data Bytes Length of test Messages Sent Messages Rec’d
10
60 min 226,718 0
20 60 min 457,433 0
62.5 60 min 1,413,317 0
125
250
8
60 min
60 min
2,817,783
5,628,518
0
0
500 60 min 11,249,982 0
800 60 min 17,977,528 0
1000 60 min 22,401,991 0
5.3.21.3 Error Test (error_test)
CAN nodes have the ability to determine fault conditions and transition to different
modes based on the severity of problems being encountered. They also have the ability to
differentiate between short disturbances and permanent failures and modify their functionality
accordingly. CAN nodes can transition from functioning like a normal node (being able to
transmit and receive messages normally), to shutting down completely (Bus-Off) based on the
severity of the errors detected. There are five error conditions (Section 3.4) and three error states
(Section 3.5) defined in the CAN protocol that a node can be in, based upon the type and
number of error conditions detected [21 – 22]. The errors simulated in this test are as follows:
CRC Error, Acknowledge Error, Form Error, Bit Error, and Stuff Error. The error states
simulated in this test are as follows: Error-Active, Error-Passive, and Bus-Off.
CRC Error Test – For this test the Altera DE2 board is configured as the transmitting
node while all 30 other nodes act as receivers. A 15-bit CRC value is calculated
according to the following formula: 15 14 10 8 7 4 3 1
X X X X X X X
. All other
nodes on the network receive this message, calculate a CRC and verify that the CRC
values match. For test purposes, bit 8 was complemented in the receiving nodes to cause
185

an Error Frame to be generated. After ten bit time slots, the message is resent with the
proper CRC value to simulate whether all nodes received the message properly.
Acknowledge Error – For this test, the Altera DE2 board checks if the Acknowledge Bit
(which it has sent as a recessive bit) contains a dominant bit. The purpose of this
dominant bit is to acknowledge that at least one node correctly received the message. If
this bit is recessive, then no node received the message properly and an Acknowledge
Error will occur. Both scenarios, recessive and dominant states, are tested to ensure
proper message reception by all CAN nodes. For the recessive state, an Acknowledge
Error occurs and an Error Frame is generated. After ten bit time slots the original
message is resent with a dominant bit in the Acknowledge Field to verify the successful
retransmission of the message.
Form Error – If any node detects a dominant bit in the End of Frame, Interframe Space,
Acknowledge Delimiter or CRC Delimiter, the CAN protocol defines this to be a form
violation and a Form Error is generated. For this test, a dominant bit is placed in each of
the bit positions to cause a Form Error to be generated for each of these conditions. After
waiting for ten bit times, the original message is then resent to all 30 CAN nodes
verifying proper operation.
Bit Error – This situation arises if a transmitter sends a dominant bit and detects a
recessive bit, or if it sends a recessive bit and detects a dominant bit when monitoring the
actual bus level and comparing it to the bit that it has just sent. If a Bit Error is detected,
an Error Frame is generated. To verify this, the actual bit sent is complemented from the
receiver nodes and after ten bit times the bit is sent again in its uncomplemented form.
186

Stuff Error – To verify a Stuff Error, six consecutive bits with the same polarity are
inserted in a CAN message between the Start of Frame and the CRC Delimiter. This
causes a Stuff Error to occur and after ten bit time slots the message is resent with
random dominant and recessive bits between the two delimiters.
Error – Active Error State – Since this is normal operation as long as the Transmit Error
Counter (TEC) and Receive Error Counter (REC) are below 128, no test is necessary to
prove proper operation. If the TEC or REC exceeds 127, the nodes become either Error –
Passive or go in to the Bus – Off state.
Error – Passive Error State – A node becomes Error – Passive when either the TEC or
REC exceeds 127. Error – Passive nodes are not permitted to transmit Active Error Flags
on the bus, but instead, transmit Passive Error Flags, which consist of six recessive bits.
To verify this state, the REC and TEC are set to random values above 127 but less than
255. This forces the nodes to enter the Error-Passive state and transmit a Passive Error
Flag (six recessive bits). At this point a dominant bit is sent on the bus, which is seen by
the Error – Passive nodes, and forces these nodes to see the bus as being idle for eight
additional bit times after an intermission frame before recognizing the bus as available.
After this time, the nodes begin retransmitting normally and return to the Error-Active
state.
Bus – Off – This test is an extension of the test performed in Section 5.3.21.1. To verify
nodes being in the Bus-Off state, a value of 256 is placed in the TEC, since receive errors
cannot cause nodes to go Bus-Off. While in this mode the nodes cannot send or receive
187

messages, acknowledge messages, or transmit Error Frames of any kind. The only way
for nodes to leave this state is by a software reset.
For these tests, 30 CAN are nodes connected to the Altera DE2 board. The test setup
configuration is shown in Figure 5.40. Only two configurable pins are required on the Altera
DE2 board to perform this test. Eight tests in all are performed, one for each of the five error
types and one for each of the three error states that a CAN node can assume. These tests are
only run at speeds of 10 kbps and 125 kbps, for the reason that these two speeds are closest to the
normal and overdrive speeds of 1 – Wire® networks.
Figure 5.40 Error Test Setup.
188

In addition to being conducted at two different speeds, the tests are also conducted using
both 11-bit and 29-bit message identifier fields. Without hot swapping, no failures are noted
while running any of the tests but a considerable degradation in the performance is noticed in the
bandwidth when using the extended 29-bit message identifiers at the 125 kbps speeds. When
making an attempt to perform hot swapping on any individual node (regardless of any of the
eight tests being conducted or bus speeds), it is noticed that all communications on the CAN
bus come to a halt and the only way to restore communications is to perform a hard reset,
powering down the Altera DE2 board and all CAN nodes.
It is clear that more extensive testing is needed to find a solution for this problem. It is
common that adding additional components to a network most often requires shutting down the
entire network to prevent costly system errors, as was evident in this case. The ability to plug-in
or remove a CAN node from the system would be a valued asset for many CAN
applications.
At this time, it is believed that the transceivers on each CAN node are the root cause of
the failure, since hot swapping CAN nodes requires that the transceiver output remain stable
during the unpowered to power-up transition without disturbing ongoing CAN network
communications. Since many CAN transceivers on the market today have very low output
impedance when unpowered, this causes the device to sink any signal present on the bus and
would effectively shut down all bus communication. Clearly, further research and testing is
needed in this area along with CAN transceivers from different manufacturers being replaced
on individual CAN nodes.
189

5.3.21.4 Send Basic Frame Test (send_frame_basic)
For this test, messages are placed on the CAN bus for reception by all nodes using only
the 11-bit message identifier (CAN 2.0A). The Altera DE2 Development and Education board
is connected with 30 CAN nodes on the network. The test setup is the same as that shown
previously in Figure 5.40. Again only two data rates are tested, 10 kbps and 125 kbps, since
these two data rates are closest to those data rates supported by most 1 – Wire® devices. Table
5.21 shows the results for this test.
Table 5.21 Send Basic Frame (send_frame_basic) Test Results.
Data Rate Messages Sent Data Bytes Length of test Hot Swapped Failures
10 kbps 225,419 8 60 min No None
10 kbps 253 8 60 min Yes Yes
125 kbps 2,748,624 8 60 min No None
125 kbps 119 8 60 min Yes Yes
Again, while attempting to hot swap CAN nodes on the network, communication on
the bus is halted and the only way to restore communications is to perform a hard reset, powering
down the Altera DE2 board and all CAN nodes. This is clearly an issue that merits further
research and exploration to fully understand the nature and root cause of the failure when
attempting to hot swap nodes on the CAN bus. For both data rates, the total messages sent is
representative of the total number of messages sent up to the point that hot swapping of a node is
attempted. When hot swapping of nodes is not attempted, no failures are noted.
For the data rate of 10 kbps and 30 CAN nodes, no significant degradation in
bandwidth or reduction in total messages transferred is realized. However, while conducting this
test at 125 kbps with 30 CAN nodes, a slight degradation in bandwidth is noticed as can be
seen by the lower amount of messages transferred within the same amount of time from the test
conducted here versus the test conducted in Section 5.3.21.2 (compared to data in Table 5.20
190

which is in section 5.3.21.2). While this is only a 2.45% reduction in total messages transferred
in going from one node to thirty nodes, this issue could become critical as more nodes are added
to the system.
5.3.21.5 Send Extended Frame Test (send_frame_extended)
In conducting this test, messages are placed on the CAN bus using the extended 29-bit
message identifier field. The Altera DE2 board is connected with 30 CAN nodes on the
network. The test setup is the same as that shown previously in Figure 5.40. Only two data rates
are used in conducting this test: 10 kbps and 125 kbps. Again, these values were selected
because they most closely match those speeds supported by 1 – Wire® devices. The results for
this test are shown in Table 5.22.
Table 5.22 Send Extended Frame (send_frame_extended) Test Results.
Data Rate Messages Sent Data Bytes Length of test Hot Swapped Failures
10 kbps 208,615 8 60 min No None
10 kbps 1,548 8 60 min Yes Yes
125 kbps 2,531,027 8 60 min No None
125 kbps 5,483 8 60 min Yes Yes
For this test, no failures are noted when hot swapping nodes is not attempted. But when
attempting to hot swap nodes, communication on the bus is again halted and the only way to
restore communications is to perform a hard reset, powering down the Altera DE2 board and all
CAN nodes. For both data rates, the total messages sent is representative of the total number
of messages sent up to the point that hot swapping of a node is attempted. As stated previously,
this is an issue that merits further investigation and research.
While conducting this test with 30 CAN nodes, degradation in bandwidth is realized
even at the slower speed of 10 kbps. While only a 7.98% reduction in total messages transferred,
191

going from one node to 30 nodes (see test results presented in Table 5.20), this is still a
significant reduction. At the higher data rate of 125 kbps, the reduction in total messages
transferred is even more apparent, having a reduction in value of 10.18% for 30 CAN nodes.
This reduction in total messages transferred could become a larger issue as more CAN nodes
are added to the system. Clearly, more research and testing are needed to conclusively identify
the source of this reduction in total messages transferred.
192

CHAPTER 6
1 – WIRE® AND CAN COMBINED SYSTEM PROTOTYPE IMPLEMENTATION
6.1 Overview of Integrated System
The fully integrated prototype system presented here consists of the following: a
synthesizable 1 – Wire® Bus Master and a synthesizable CAN Controller implemented on the
Altera DE2 board; multiple CAN nodes using the design specified in Section 5.3.20; and
multiple 1 – Wire® slave devices. The complete prototype system is shown in Figure 6.1. The 1
– Wire® slave devices shown in Figure 6.1 are samples obtained through Maxim
Semiconductor. The CAN nodes shown in Figure 6.1 are based on Microchip application note
AN215 [47]. Table 6.1 shows FPGA resource utilization by the Altera DE2 Development and
Education board for the prototype CAN Controller and 1 – Wire® Master.
Figure 6.1 Combined CAN & 1 – Wire® Prototype System.
193

Table 6.1 Resource Utilization.
Revision Name one_wm_CAN_Controller
Family Cyclone II
Device EP2C35F672C6
Timing Models Final
Met timing requirements Yes
Total logic elements 4248 / 33,216 ( 13 % )
Total combinational functions 3626 / 33,216 ( 11 % )
Dedicated logic registers 1167 / 33,216 ( 3.5 % )
Total registers 1167
Total pins 44 / 475 ( 9 % )
Total virtual pins 0
Total memory bits 3538 / 483,840 (

6.2 Verification of Combined Prototype System
To verify proper operation of the 1 – Wire® and CAN combined prototype system,
several test cases are executed, utilizing both regular and overdrive 1 – Wire® communication
speeds. For all tests, the hardware used, shown in Figure 6.2, includes the following
components: three DS1996 – 64Kb Memory iButtons [83], DS1402-BR8+ 1 – Wire®
Network Cable [80], DS1401-4 Front-Panel iButton Holder [81], and two CAN nodes as
described in Section 5.3.20. The reason for using the DS1996 64Kb Memory iButtons is that
the DS1996 is the largest memory iButton currently in production, and provides 65,536 bits of
read/write nonvolatile memory partitioned into 256-bit pages for packetizing data. The
equivalent EPROM, DS1986 [99], could just as easily have been used as a suitable replacement
except the product is no longer available and therefore is not recommended for new designs.
However, the DS1977 [93] could be used as a substitute, especially if security were an issue and
password protection were required. Both tests are compiled and simulated using Altera Quartus
II 9.1 (32-bit) and ModelSim Altera Starter Edition 6.6c software on a PC executing Windows
XP Service Pack 3. All tests are performed extensively while trying to cover all possible
combinations of inputs and outputs. The source code for all modules, testbench code, and
simulation results are located on the DVD included with this work.
Figure 6.2 1 – Wire® & CAN Combined Prototype System.
195

6.2.1 Test Verification and Overview
For the tests presented here, all 1 – Wire® devices and CAN nodes are tested at regular
speeds (approximately 14 kbps for all 1 – Wire® devices and 10 kbps for all CAN nodes) and
overdrive speeds (approximately 140 kbps for all 1 – Wire® devices and 125 kbps for all
CAN nodes). Also for this test only two CAN nodes and three DS1996 1 – Wire® devices
are used. This was done for easier troubleshooting in case of a catastrophic failure and would
make analysis of the data bytes transferred simpler with fewer CAN nodes and 1 – Wire®
devices on the bus. Since this was the first time testing the combined system, there was some
degree of uncertainty concerning functionality after combining the Verilog® source code of the 1
– Wire® Master and the CAN Module. Combining the source code for the CAN Module
and 1 – Wire® Master required additional lines of code to take into account the additional logic
registers and logic elements required.
For both tests in described Sections 6.2.1.2 and 6.2.1.3, the 1 – Wire Search Algorithm
(see Section 2.3.6) is used to discover the 64-bit identification numbers of the DS1996 1 –
Wire® devices. Once the identification numbers are known and stored in memory on the 1 –
Wire Master, the order in which the numbers are obtained is the order in which the devices are
written to. With the DS1996, the offset data byte is used to determine the next byte of memory
to which data will be written. When the device memory is full, the next available DS1996
discovered by the 1 – Wire® Search Algorithm is used. This process is repeated for all three
DS1996 1 – Wire® devices until the memory of all three devices is full. Then the process is
repeated all over again with the next byte of data being written to the first DS1996 1 – Wire®
device, overwriting old data as necessary.
196

6.2.1.1 DS1996 Addressing and Memory Layout
Properly communicating with the DS1996 [83] 1 – Wire® devices used in these tests
requires an understanding and explanation of how the memory is organized and how to address
individual pages within the memory. The memory map for a DS1996 [83] is shown in Figure
6.3. At the top of the memory map is a 32-byte page, called the scratchpad. The scratchpad is an
additional page that acts as a buffer when writing to memory. Beneath this are the additional 32-
byte pages of memory. The DS1996 contains 256 pages which comprise the 65,536 bits of
read/write nonvolatile memory.
Figure 6.3 DS1996 iButton Memory Map.
Because of the serial data transfer, the DS1996 employs three address registers, called
TA1, TA2, and E/S as shown in Figure 6.4. Registers TA1 and TA2 must be loaded with the
target address to which the data will be written or from which data will be sent to the 1 – Wire®
Master upon a Read command. Register E/S acts like a byte counter and Transfer Status register.
It is used to verify data integrity with Write commands. Therefore, the 1 – Wire® Master only
197

has read access to this register. The lower five bits of the E/S register indicate the address of the
last byte that has been written to the scratchpad. This address is called the Ending Offset bit. Bit
5 of the E/S register, called PF or “partial-byte flag,” is set if the number of data bits sent by the
1 – Wire® Master is not an integer multiple of 8. Bit 6, OF or “Overflow,” is set if more bits are
sent by the 1 – Wire® Master than can be stored in the scratchpad area. Note that the lowest five
bits of the target address also determine the address within the scratchpad, where intermediate
storage of data will begin. This address is called the byte offset. For best economy of speed and
efficiency, the target address for writing should point to the beginning of a new page, i.e., the
byte offset will be zero. Thus, the full 32-byte capacity of the scratchpad is available, resulting
also in the ending offset of 0x001F. However, it is possible to write one or several contiguous
bytes somewhere within a page. The ending offset together with the Partial and Overflow Flag is
mainly a means to support the 1 – Wire® Master checking the data integrity after a Write
command. The highest valued bit of the E/S register, called AA or Authorization Accepted, acts
as a flag to indicate that the data stored in the scratchpad area has already been copied to the
target memory address. Writing data to the scratchpad clears this flag.
Figure 6.4 DS1996 Address Registers.
198

To write data to the DS1996, the scratchpad has to be used as an intermediate storage
area. First, the 1 – Wire® Master issues the Write Scratchpad command (0xF0) to specify the
desired target address, followed by the data to be written to the scratchpad. In the next step, the
1 – Wire® Master sends the Read Scratchpad command (0xAA) to read the scratchpad and to
verify data integrity. As preamble to the scratchpad data, the DS1996 sends the requested target
address TA1 and TA2 and the contents of the E/S register. If one of the flags OF or PF is set,
data did not arrive correctly in the scratchpad. The master does not need to continue reading; it
can start a new trial to write data to the scratchpad. Similarly, a set AA flag indicates that the
Write command was not recognized by the DS1996. If everything works correctly, all three
flags are cleared and the ending offset indicates the address of the last byte written to the
scratchpad. Now the 1 – Wire® Master can continue verifying every data bit. After the 1 –
Wire® Master has verified the data it has to send the Copy Scratchpad command (0x55). This
command must be followed exactly by the data of the three address registers TA1, TA2, and E/S
as the 1 – Wire® Master has read them verifying the scratchpad contents. As soon as the slave
has received these bytes, it will copy the data to the requested location beginning at the target
address. The communication between the 1 – Wire® Master and the DS1996 takes place either
at regular speed or at overdrive speed. If not explicitly set into the Overdrive Mode, the DS1996
assumes regular speed.
6.2.1.2 Test Results – Transferring CAN data bytes to 1 – Wire® devices
To conduct this test, three DS1996 1 – Wire® slaves are present on the 1 – Wire®
network, providing a total of 196,608 bits (24,576 bytes) of memory. Figure 6.2 shows the
199

system configuration used for this test. In addition two CAN nodes are utilized, whose
addresses are set to 1 and 2, respectively. The custom interface on the FPGA handles all
conversions from CAN messages to 1 – Wire® commands. Each CAN node is
automatically performing an A/D conversion (voltage divider circuit from a potentiometer)
approximately every 500 ms and transmitting this data on the CAN bus to the DS1996 1 –
Wire® devices. In addition to the data byte containing the A/D conversion result, both CAN
nodes are programmed to also send an I/O status byte, which includes the status of both the
Digital Inputs and Digital Outputs. So to summarize, approximately every 500 ms, eight data
bytes are being transmitted on the CAN bus to the DS1996 1 – Wire® devices. Two of these
data bytes represent the transmitting node number and the other two represent the A/D
conversion result and Digital I/O status bytes, respectively (i.e., node number + A/D conversion
result and node number + Digital I/O status). The results of this test are presented in Table 6.2.
Table 6.2 Test Results.
1 – Wire®
Devices
Type #
# of CAN
Nodes
CAN Bus
Speed (kbps)
1 – Wire® Bus
Speed (kbps)
Hot-Swapped
(1 – Wire®)
Length of Test
(min)
Failures
DS1996 3 2 10 14 Yes 60 No
DS1996 3 2 10 140 Yes 18 Yes 1
DS1996 3 2 125 14 Yes 60 No
DS1996 3 2 125 140 Yes 14 Yes 1
1
This failure resulted in loss of messages to 1 – Wire® devices from the CAN bus.
From Table 6.2, lost CAN bus messages are noted when running the 1 – Wire® bus in
overdrive speed. After many hours of repeating these two tests and many lines of debug code, it
was found that if a CAN bus message came in while running the 1 – Wire® bus in overdrive
and the devices were not all operating in overdrive speed yet, the present CAN bus message
was dropped. Although, technically this is not a failure in the sense of a catastrophic event, it is
200

a problem in that important CAN messages can be lost with no indication of a lost message or
need for retransmission.
As discussed in Section 4.3.4, there are two ways to get an overdrive-capable slave
device into overdrive mode: Overdrive Skip command, and Overdrive Match command. Also,
despite the extra command and reset cycle necessary to get 1 – Wire® devices into overdrive
mode, using overdrive obtains the device identification number in less than half the time required
at standard speed.
One possible solution to this problem is to implement either a FIFO or prioritized FIFO
buffer to possibly prevent CAN bus messages from being discarded and retain them until all 1
– Wire® devices are operating at overdrive speed. Another possible solution is to implement
some type of handshaking or acknowledgement when CAN bus messages are transmitted for 1
– Wire® devices.
6.2.1.3 Test Results – 1 – Wire® Master requests data from CAN Nodes
Again for this test, three DS1996 1 – Wire® devices and two CAN nodes are present
on the network. The 1 – Wire® devices and CAN bus nodes are connected as shown in Figure
6.2. The CAN node addresses remain set at 1 and 2 respectively. Unlike the test conducted in
Section 6.2.1.2, the CAN nodes utilized for this test have been modified to prevent the
automatic transmission of the A/D conversion result every 500 ms. Also, the 1 – Wire® Master
was modified to have the capability to send a command to any one particular node or all of the
CAN nodes. Additional Verilog® code in the form of a For loop was added to simulate a
broadcast command being sent from the 1 – Wire® Master. Whether this command is executed
201

or not depends on the number of receiving CAN nodes. The command sent depends on the
data written to the FILHIT bits of the RXB1CTRL register of the MCP2515. The
meaning of these filter bits is described in Section 5.3.20.4 and a program execution flowchart is
shown in Figure 5.37. Figure 6.5 shows the contents of this MCP2515 register.
Figure 6.5 RXB1CTRL – Receive Buffer 1 Control Register Bit Definitions [44].
The $random() function is used to determine which command is going to be sent to the
CAN nodes. Details of the $random() function are covered in Section 5.2.8.3. To generate a
random value to represent the command to send to the CAN node(s), the following block of
code was executed:
integer seed_value, random_value;
random_value = $random(seed_value) % 7;
random_value = abs(random_value);
This block of code returns a value between 0 and 6 which corresponds to the list of commands
summarized in Table 6.3. This random value is then sent out to one or both CAN nodes as a
command setting the appropriate bits in the FILHITx registers on the node(s). The receiving
CAN node(s) then perform the required command and send the resulting data back to the 1 –
Wire® Master which then stores the data contiguously in the DS1996 1 – Wire® slave devices.
The results of this test are presented in Table 6.4.
202

1 – Wire®
Devices
Type #
Table 6.3 FILHITx Bit Definitions.
FILHIT2 FILHIT1 FILHIT0 Description
0 0 0 Perform A/D conversion on AN1.
0 0 1 Read Digital Input pins.
0 1 0 Write Value to Digital Output 1.
0 1 1 Write Value to Digital Output 2.
1 0 0 Change Node Address.
1 0 1 Turn off Digital Outputs 1 and 2.
1 1 1 Not Used
# of
CAN
Nodes
# of
Receiving
CAN
Nodes
Table 6.4 Test Results.
CAN Bus
Speed (kbps)
203
1 – Wire®
Bus Speed
(kbps)
Hot-
Swapped
(1 – Wire®)
Length of
Test
(min)
Failures
DS1996 3 2 1 10 14 Yes 60 No
DS1996 3 2 2 10 14 Yes 60 Yes 2
DS1996 3 2 1 10 140 Yes 18 Yes 1
DS1996 3 2 2 10 140 Yes 11 Yes 1
DS1996 3 2 1 125 14 Yes 60 No
DS1996 3 2 2 125 14 Yes 60 Yes 2
DS1996 3 2 1 125 140 Yes 14 Yes 1
DS1996 3 2 2 125 140 Yes 24 Yes 1
1 This failure resulted in loss of messages to the 1 – Wire® devices from the CAN bus.
2 This failure resulted in loss of messages to the 1 – Wire® devices, but did not require a hard reset.
From Table 6.4, lost CAN bus messages are noted in all cases where running the 1 –
Wire® bus in overdrive speed. As was the case with the test performed in Section 6.2.1.2,
debugging the system found that if a CAN bus message came in while running the 1 – Wire®
bus in overdrive and the 1 – Wire® devices were not all operating in overdrive speed yet, the
present CAN bus message got dropped. Although, technically this is still not a failure in the
sense of a catastrophic failure, it is still a problem in that if this had been a safety-critical system,
any loss of data or messages could be catastrophic.
When sending a 1 – Wire® command to multiple CAN nodes it was sometimes noted
that the data received from the CAN nodes was not the data requested by the 1 – Wire®
Master and stored by the 1 – Wire® slaves. For instance, consider the second test case in Table

6.4. There are two receiving CAN nodes and both the CAN bus and 1 – Wire® bus are
operating at their slower speeds of 10 kbps and 14 kbps, respectively. Only in certain instances
is data lost when it is requested from the CAN nodes. After inserting lines of debug code and
recording the commands sent to the CAN nodes from the 1 – Wire® Master, no correlation is
found between one particular command being sent to the CAN nodes from Table 6.4 and data
loss. It was discovered, however, that in certain cases if both CAN nodes send their data
before it can be fully processed by the 1 – Wire® Bus Master, data loss to the 1 – Wire® slaves
occurs. This results in the first byte of requested data being overwritten by the second byte of
data. The CAN node that transmits its byte of data first determines which byte of data is
actually stored to the 1 – Wire® slaves. It is also discovered that there is no loss of data in the
commands being send from the 1 – Wire® Master to the receiving CAN nodes.
Again, a possible solution to this problem is to implement either a FIFO or a prioritized
FIFO buffer to possibly prevent the data requested from the CAN nodes from being
overwritten. As was mentioned in Section 6.2.1.2, another possible solution is to implement
some type of handshaking or acknowledgement when the data byte requested from the CAN
nodes are actually successfully stored in the memory of the DS1996 1 – Wire® devices. Even
though this would impact the speed of the bus, the reliability gained by preventing data loss
would greatly outweigh the reduction in data throughput.
Finally, no conclusion is reached regarding the loss of data in the test cases (tests 3,4,7,
and 8) where the 1 – Wire® slaves are operating at overdrive speed. It is unknown as to whether
the data loss to the 1 – Wire® slaves is a result of all devices not operating in overdrive speed or
if data loss is a result of both CAN nodes transmitting the requested data before the 1 – Wire®
204

Master could successfully process the requested data. Clearly, further research and testing is
needed to determine the root cause of data loss and to implement a viable solution. One simple
solution might be to place a delay timer when trying to communicate with 1 – Wire® slaves at
overdrive speed. This should give all 1 – Wire® slaves enough time to successfully be ready to
accept data at overdrive speeds.
205

CHAPTER 7
CONCLUSIONS AND FUTURE WORK
Many of today’s digital designs are implemented using custom ASICs or gate arrays.
Quite often, entire systems can be implemented with only a few ASICs. The use of FPGAs is
also increasing, providing lower cost ASIC-based alternatives to limited production designs. In
general, the proliferation of ASICs and gate arrays in contemporary digital designs is increasing
at a rapid rate. The research encompassed by this work presented a VLSI (Very Large Scale
Integration) design and simulation of a custom ASIC incorporating two communication
protocols, CAN (Controller Area Network) and 1 – Wire®, targeting wearable medical
technology and devices and hybrid-electric vehicle technology applications.
The synthesizable 1 – Wire® Master presented in Chapter 5 is based on the 1 – Wire®
communications protocol by Maxim Semiconductor. The design is written in Verilog® and
tested on an Altera DE2 Development and Education Board using the Quartus II software
package. From the four tests executed (single_search_rom, multi_ow_network,
scratchpad_integrity, and cmd_recognition), no failures were observed even during hot-swapping
of both parasitically and non-parasitically powered slave device. With this being the case, more
testing is needed using standard and overdrive speeds as well as parasitically and non-
parasitically powered devices before finalizing the prototype 1 – Wire® Master.
206

As stated in section 5.2.8.3, scratchpad_integrity test, more testing is needed for
conclusive evidence on failure rates. In particular more tests need to be performed using
multiple 1 – Wire® slave devices of different types. If multiple 1 – Wire® slave devices exist on
the 1 – Wire® network and a READ_ROM command (0x33) is issued immediately following
the SKIP_ROM command (0xCC), data collision is inevitable on the bus as multiple slaves will
try and transmit simultaneously. This is a direct result of open-drain pull-downs, as they will
produce a wired-AND result. This will more than likely shut the 1 – Wire® network down but
perhaps with testing on just this case, it might be possible to at least minimize the failure rate and
prevent data loss from occurring.
Another area where more testing is needed for all four test cases presented in sections
5.2.8.1 through 5.2.8.4 is the use of both standard and overdrive speed devices coexisting on the
same network. Even though the test conducted in section 5.2.8.4, cmd_recognition, used several
overdrive commands, there was only a single 1 – Wire® slave device on the network.
Additionally hot-swapping was performed and no failures were observed with a single 1 –
Wire® device; the same cannot be automatically assumed in the case for multiple 1 – Wire®
slaves. This is especially true if both standard and overdrive speed capable devices coexist on
the same network. Therefore more testing is needed to ensure reliability and data integrity on the
1 – Wire® network, in the cases of hot-swapping and coexistence of both standard and overdrive
speed devices.
Even though the time savings is nearly 2.5 times greater at overdrive speeds than at
standard speeds, extra care must be taken when hot-swapping slave devices at overdrive speeds.
Since hot-swapping slave devices causes a temporary electrical short between DATA and GND,
207

a communication bus reset will occur. This in turn will reset all slave devices operating at
overdrive speed back to standard speed. For the combined 1 – Wire® and CAN system,
failures will be imminent. More testing and debugging is needed so as to minimized the failure
rate as much as possible and also to try and mitigate data loss and/or corruption of both CAN
and 1 – Wire® data packets.
The synthesizable CAN Controller presented in Chapter 5 is based upon two different
models: the Bosch VHDL Reference System is used mostly for a verification tool and the
Motorola CAN (MCAN) Module [95 – 97] for its functional and memory map layout. The
design is written in Verilog® and tested on an Altera DE2 Development and Education Board
using the Quartus II software package. From the five tests executed (test_synchronization,
bus_off_test, error_test, send_frame_basic, and send_frame_extended), failures were only
noticed when attempting to hot swap a node. Of the three tests where hot-swapping was
attempted (error_testSection 5.3.21.3, send_frame_basicSection 5.3.21.4, and
send_frame_extendedSection 5.3.21.5), all three tests encountered failures and a hard reset had
to be performed for communication to be re-established.
For the test conducted in Section 5.3.21.3, error_test, 30 CAN nodes are utilized.
More testing and debugging is necessary to find, if one exists, a root cause for the failure of the
CAN realized when attempting hot-swapping of CAN nodes. At this time, the only
plausible explanation for the failure is believed to be in the CAN transceiver used on each
CAN node. Although the data sheet for the MCP2551 [45], used on each CAN node, states
that when the device is powered on, CAN_H and CAN_L remain in a high-impedance state until
VDD reaches the voltage-level VPORH, it does not give an exact value for this impedance. It is
208

known that many CAN transceivers on the market today have very low output impedance
when unpowered. This causes the device to sink any signal present on the bus and effectively
shuts down all data transmission. One possible solution might be to perform this exact test again
but with a different CAN transceiver on each node. Texas Instruments has a transceiver,
SN65HVD1050 [100], which according to the data sheet, should work to solve this problem.
According to the data sheet, the HVD1050’s bus pins are biased internally to a high-impedance
recessive state. This provides for a power-up into a known recessive condition without
disturbing ongoing bus communication. It also maintains the integrity of the bus when power or
ground is added to or removed from the circuit [100]. Another possible solution is to add
additional hardware to the entire CAN bus system, in the form of a bus utilization monitor and
data packet logger. Clearly, more time and testing are needed to find a viable solution to this
problem. This is important since the ability to plug directly into a currently operating system
becomes a valued asset in many CAN applications.
For the remaining two tests, send_frame_basic and send_frame_extended, failures are
again noted when hot-swapping of nodes was attempted. As previously discussed, more testing
is needed, plus the possibility of swapping out the CAN transceiver used on each node, to find
a solution and prevent having to perform a hard reset each time hot-swapping is attempted. The
prevention of such failures would be a very beneficial feature to any CAN node system,
especially for safety-critical networks. It might prove worthwhile for future modifications to
consider writing testbench code for tests such as a Reset Mode test and Bus-Off Recovery test.
Such tests might provide some insight to possible hot-swapping failures.
209

For the synthesizable CAN Controller, there was an additional test considered but
never fully implemented: self_reception_request test. In this test, there are two different modes
of operation. First, the CAN module performs an internal loop back (default), which can be
used for self-test operation. In this mode, a dummy Acknowledge bit is provided, thereby
eliminating the need for another node on the bus to provide the Acknowledge bit (i.e. the module
treats its own transmitted message as a message received from a remote node). The rx input pin
is ignored and the tx output pin goes to the recessive state (logic ‘1’). Both transmit and receive
interrupts are generated. Alternatively, if the user desires, the current message can be queued for
transmission without disabling the receiver. It will receive the message only if the Acceptance
Filter recognizes the message ID. This test was originally considered as a part of a plan to also
implement a FIFO or prioritized FIFO buffer in the synthesizable CAN Controller. But after
much time and consideration it was thought that a better approach would be to implement a FIFO
or prioritized FIFO buffer as a separate entity in the design and not integrate it as part of the
CAN Controller. So for this reason development and implementation of this test was dropped.
From the test results of those performed in Chapter 6, the combined 1 – Wire® to CAN
prototype system clearly needs more debugging and testing before becoming a fully-functional
production prototype. This is evident from the failures noted in Tables 6.2 and 6.4 as a result of
the two tests performed. Even though neither of the two tests performed had a failure from a
catastrophic point of view, both tests had failures concerning lost CAN bus messages when
trying to run 1 – Wire® devices in overdrive speed and also when trying to hot-swap 1 – Wire®
devices. As stated previously, this is primarily attributed to the extra steps required to get all 1 –
Wire® devices into overdrive mode. This is still a big problem especially if the system is going
210

to be used in any type of safety-critical application environment. A simple and obvious fix to
this problem is to run similar speeds on both buses without allowing hot-swapping: either the
CAN bus at 10 kbps and the 1 – Wire® bus at 14 kbps or the CAN bus at 125 kbps and the
1 – Wire® bus at 140 kbps. The downside to this option is the reduced flexibility placed on the
combined system which is stated as being one of the big advantages of using 1 – Wire® devices
and technology.
The other type of failure from the tests conducted on the combined prototype system
occurred when sending a 1 – Wire® command to multiple CAN nodes. It was originally
thought that the cause of data loss was from receiving the response data bytes from the CAN
nodes before the 1 – Wire® Master had time to process and write the received data bytes to the
appropriate memory locations on the DS1996 1 – Wire® devices. Another possible scenario for
the source of the data loss was that data was coming in to the 1 – Wire® Master before all of the
1 – Wire® slave devices were operating in overdrive speed. After inserting numerous traps and
inserting lines of debug code, it was determined that when requesting data from multiple CAN
nodes the first byte of received data could be overwritten by the second byte of data if the 1 –
Wire® Master had not been able to successfully process the incoming data byte. However, no
definitive conclusions were reached as to the root cause of data loss. Data loss could have been a
combination of one or both scenarios. Clearly further research and testing is needed to find a
solution to prevent data loss and the idea of inserting a delay timer for the cases when 1 – Wire®
slaves are being operated at overdrive speed certainly merits exploration. No further testing was
performed with additional nodes, since it can be assumed that if failures were seen when
requesting data from two CAN nodes that this problem would only become more apparent as
211

additional CAN nodes were added to the system. It should be noted that no failures were
observed when only requesting data from an individual CAN node.
For the vast majority of failures observed while conducting tests on the combined
prototype system, there is no doubt that the system would greatly benefit from the addition of
either a FIFO or prioritized FIFO buffer. Although not implemented as an integral part of the
final design, considerable research was done on this solution. A proposed FIFO buffer based on
a 74F433 FIFO Buffer Memory IC [101] from Fairchild Semiconductor is presented here. Its
purpose would be to provide seamless, asynchronous communication between the 1 – Wire® and
CAN networks. It might even be a possibility that the addition of a FIFO or prioritized FIFO
buffer and a delay timer would solve all of the failure rates seen in the testing of the combined
system.
The FIFO Buffer Memory is organized as 64 words by 4-bits and may be expanded to
any number of words or any number of bits in multiples of four. This allows data to be entered
or extracted asynchronously in serial form. Figure 7.1 shows a block diagram of the FIFO
Buffer Memory section and Table 7.1 gives a brief description of the pin names. It consists of
three major sections:
An Input Register with serial data inputs, as well as control inputs and outputs for input
handshaking and expansion.
A 4-bit-wide, 64-word-deep fall-through stack with self-contained control logic.
An Output Register with serial data outputs, as well as control inputs and outputs for
output handshaking and expansion.
212

Figure 7.1 FIFO Buffer Memory [101].
These three sections operate asynchronously and are virtually independent of one another:
Input Register (Data Entry) the Input Register receives data in bit-serial form and
stores this data until it is sent to the fall-through stack. It also generates the necessary
status and control signals. Data on the Serial Data line (DS) input is serially entered
into a shift register on each HIGH-TO-LOW transition of the SIC input when the
Serial Input Enable ( SIE ) signal is LOW.
213

Fall-Through Stack A LOW level on the Transfer to Stack ( TTS ) input initiates a
fall-through action; if the top location of the stack is empty, data is loaded into the
stack and the input register is reinitialized. Thus, automatic FIFO action is achieved
by connecting the IRF output to the TTS input. An RS-type flip-flop (the
initialization flip-flop) in the control section records the fact that data has been
transferred to the stack. This prevents multiple entry of the same word into the stack
even though IRF and TTS may still be LOW. Once in the stack, data falls
through automatically, pausing only when it is necessary to wait for an empty next
location.
Output Register The Output Register receives 4-bit data words from the bottom
stack location, stores them, and outputs data on a TRI-STATE serial data bus. The
output section generates and receives the necessary status and control signals. When
the FIFO is empty after a LOW is applied to the MR input, the ORE output is
LOW. After data has been entered into the FIFO and has fallen through to the bottom
stack location, it is transferred into the output register if the TOS input is LOW. As
a result of the data transfer, ORE goes HIGH, indicating that valid data is in the
register.
214

Table 7.1 FIFO Buffer Memory Pin Names and Descriptions.
Pin Name Description
SIC Serial Input Clock
SIE Serial Input Enable
TTS Transfer to Stack Input
MR Master Reset
SOE Serial Output Enable
TOS Transfer Out Serial
SOC Serial Output Clock
DS
QS
Serial Data Input
Serial Data Output
ORE Output Register Empty
IRF Input Register Full
Another option that was considered regarding the FIFO buffer was to integrate it directly
into the synthesizable CAN Controller. Even though the CAN Controller is fully functional
concerning both standard and extended data frames, it is not perfect and by no means capable of
handling hot-swapping of CAN nodes. Perhaps with more testing and debugging, especially
dealing with hot-swapping this idea might be worth returning to and trying to integrate as part of
the CAN Controller.
Although not implemented, considerable thought was also given to the idea of
implementing bi-directional (full-duplex) communication in the prototype system. This would
allow data to be transferred from the CAN network to the 1 – Wire® network and vice versa
simultaneously. This would greatly increase the throughput of the entire system and also system
marketability.
215

In conclusion, the prototype system design presented in this manuscript is comprised of a
fully-functional 1 – Wire® Bus Master and a CAN 2.0B compliant CAN Controller. It has
successfully been shown that data from a 1 – Wire® network can be sent to a CAN bus node
and that data can be requested by a 1 – Wire® Bus Master from a CAN bus node. In fact, data
has been stored on a DS1996 iButton that was received from the result of an A/D conversion
on a CAN bus node.
Minor issues that still need to be addressed are as follows: hot-swapping of CAN
Controller nodes, hot-swapping of 1 – Wire® devices in overdrive mode while receiving data
from the CAN bus, receiving requested data from multiple CAN nodes for 1 – Wire®
devices, and hot-swapping of both 1 – Wire® and CAN nodes. Given time and resources
these issues and many more can be addressed and solved to yield a fully integrated 1 – Wire®
Master/CAN, CAN/1 – Wire® Master.
The prototype system presented in this manuscript would no doubt be of great benefit to
wearable medical technology and devices and hybrid-electric vehicle technology applications.
By utilizing serial communications, the pin count for a robust, reliable communication backbone
is kept to a minimum. This would keep both the wiring cost and complexity to implement such a
system to a minimum. With the low-cost and ease of CAN-enabling almost any device, the
combinations of sensor networks that could be designed for both application markets is infinite
and is only limited by the creativity of the system designer. Combine this with the variety of
both current in-production 1 – Wire® devices and those not currently in production but still
readily available, and almost any application or system can be implemented. Taking all of this
into account and the limited FPGA resources utilized in the design presented in this manuscript,
216

an inexpensive ASIC would be capable of handling the interface and data demands of most any
application for either market.
217

REFERENCES
[1] IBM ASIC Products Application Note, “ASIC Design Methodology Primer,” Initial
Publication 05/98. Website: http://asaha.com/ebook/UODk0Njc-/ASIC-Design-
Methodology-Primer.pdf#PDF Ebook (Accessed on November 20, 2011).
[2] Application-Specific Integrated Circuits (ASIC’s). Website:
http://www.siliconfareast.com/asic.htm. (Accessed on November 20, 2011).
[3] J. Rutherford, “Wearable Technology,” in IEEE Engineering In Medicine and Biology,
Volume 29, Issue 3, 2010, Page(s): 19 – 24.
[4] Maxim Application Note 148: “Guidelines for Reliable Long Line 1 – Wire® Networks,”
September 22, 2008. Website: http://pdfserv.maxim-ic.com/en/an/AN148.pdf.
(Accessed on November 17, 2011).
[5] D. Awtrey, “Transmitting Data and Power Over a One-Wire Bus,” in Sensors – The
Journal of Applied Sensing Technology, February 1997. Website:
http://archives.sensorsmag.com/articles/0297/onewire/index.htm. (Accessed on
November 17, 2011).
[6] Dallas/Maxim Semiconductor Engineering Journals, “A layman’s overview of 1 – Wire®
technology and its use”, Volume 4, Pages 3 – 8, March 2003. Website:
http://pdfserv.maxim-ic.com/en/ej/DallasEJ4.pdf. (Accessed on November 17, 2011).
[7] Dallas/Maxim Semiconductor Engineering Journals, “Dissecting the Versatile 1 – Wire®
Network,” Volume 1, Pages 21 – 22, September 2001. Website: http://pdfserv.maximic.com/en/ej/DallasEJ1.pdf.
(Accessed on November 17, 2011).
[8] B. Linke, “Maxim Application Note 4206: Choosing the Right 1 – Wire® Master for
Embedded Applications,” March 27, 2008. Website: http://pdfserv.maximic.com/en/an/AN4206.pdf.
(Accessed on November 17, 2011).
[9] Philips Semiconductors, “The I 2 C – Bus Specification,” Version 2.1, January 2000.
Website: http://www.nxp.com/documents/other/39340011.pdf. (Accessed on November
17, 2011).
[10] B. Linke, “Maxim Application Note 1796: Overview of 1 – Wire® Technology and Its
Use,” June 19, 2008. Website: http://pdfserv.maxim-ic.com/en/an/AN1796.pdf.
(Accessed on November 17, 2011).
[11] Maxim Application Note 155: “1 – Wire® Software Resource Guide Device
Description,” July 8, 2008. Website: http://pdfserv.maxim-ic.com/en/an/AN155.pdf.
(Accessed on November 17, 2011).
218

[12] Maxim Semiconductor DS2480B – Serial to 1 – Wire® Line Driver Datasheet, 19-5047,
Revision 3, May 2010. Website: http://datasheets.maxim-ic.com/en/ds/DS2480B.pdf.
(Accessed on November 17, 2011).
[13] Maxim Semiconductor Single-Channel 1 – Wire® Master, DS2482 – 100 Product
Datasheet, 19-4930, Revision 8, November 2009. Website: http://datasheets.maximic.com/en/ds/DS2482-100.pdf.
(Accessed on November 17, 2011).
[14] Maxim Semiconductor Single-Channel 1 – Wire® Master with Sleep Mode, DS2482 –
101 Product Datasheet, 19-4931, Revision 3, November 2010. Website:
http://datasheets.maxim-ic.com/en/ds/DS2482-101.pdf. (Accessed on November 17,
2011).
[15] Maxim Semiconductor Eight-Channel 1 – Wire® Master with Sleep Mode, DS2482 –
800 Product Datasheet, 19-4932, Revision 3, November 2009. Website:
http://datasheets.maxim-ic.com/en/ds/DS2482-800.pdf. (Accessed on November 17,
2011).
[16] Maxim Application Note 187: “1 – Wire® Search Algorithm,” March 28, 2002.
Website: http://pdfserv.maxim-ic.com/en/an/AN187.pdf. (Accessed November 17,
2011).
[17] Maxim Application Note 27: “Understanding and Using Cyclic Redundancy Checks with
Maxim iButton Products,” March 29, 2001. Website: http://pdfserv.maximic.com/en/an/AN27.pdf.
(Accessed on November 17, 2011).
[18] D. Mannisto, M. Dawson (Machine Bus Technology), “An Overview of Controller Area
Network (CAN) Technology,” November 12, 2003. Website:
http://www.parallax.com/dl/docs/prod/comm/cantechovew.pdf. (Accessed on November
17, 2011).
[19] Renesas Electronics Corporation Application Note: “Introduction to CAN.” Website:
http://documentation.renesas.com/eng/products/mpumcu/apn/rej05b0804_m16cap.pdf.
(Accessed on November 17, 2011).
[20] BOSCH CAN Specification Version 2.0. Website:
http://esd.cs.ucr.edu/webres/can20.pdf. (Accessed on November 17, 2011).
[21] K. Pazul (Microchip Technology, Inc.), Microchip Application Note AN713: “Controller
Area Network (CAN) Basics,” September 16, 2005. Website:
http://ww1.microchip.com/downloads/en/AppNotes/00713a.pdf. (Accessed on
November 17, 2011).
219

[22] “CAN – a brief tutorial for Embedded Engineers,” COMSOL – Computer Solutions Ltd.
Website: http://www.computersolutions.co.uk/info/Embedded_tutorials/can_tutorial.htm.
(Accessed on November 17,
2011).
[23] S. Robb (Freescale Semiconductor), Freescale Semiconductor Application Note AN1798:
“CAN Bit Timing Requirement.” Website:
http://www.freescale.com/files/microcontrollers/doc/app_note/AN1798.pdf. (Accessed
on November 17, 2011).
[24] L. M. Pinho, F. Vasques, and E. Tovar, “Integrating Inaccessibility in Response Time
Analysis of CAN Networks,” in Proceeding of the 2000 IEEE International Workshop
on Factory Communication Systems, 2000, Page(s): 77 – 84.
[25] K. Zuberi and K. Shin, “Scheduling Messages on Controller Area Network for Real-Time
CIM Applications,, in IEEE Transactions on Robotics and Automation, Volume 13,
Number 2, Page(s): 310 – 314, 1997.
[26] Rockwell Automation, “DeviceNet Product Overview,” Publication DN – 2.5, Rockwell,
1997. Website:
http://www.pacpro.com/upload/data/Rockwell%20Networks/DeviceNET/hardware/Devic
eNet_ProdustOverview_Dn25.pdf. (Accessed on November 17, 2011).
[27] L.-B. Fredriksson, “CAN for Critical Embedded Automotive Networks,” in IEEE Micro,
Volume 22, Issue 4, 2002, Page(s): 28 – 35.
[28] H. Kopetz, “Real-Time Systems Design Principles for Distributed Embedded
Applications,” Kluwer Academic, Boston, 1997.
[29] R. Obermaisser, “Ordering Messages in Virtual CAN Networks,” in the 12 th IEEE
International Conference on Electronics, Circuits and Systems, 2005. ICECS 2005,
Page(s): 1 – 4.
[30] J. Vial and J. Dixon, “Monitoring Battery System for Electric Vehicle, Based on “One
Wire” Technology,” Website: http://web.ing.puc.cl/~power/paperspdf/dixon/64a.pdf.
(Accessed on November 17, 2011).
[31] Eureka Prometheus Project. Website:
http://en.wikipedia.org/wiki/EUREKA_Prometheus_Project. (Accessed on November
17, 2011).
[32] B. Linke, Maxim Application Note 3967: “Selecting a Serial Bus,”January 30, 2007.
Website: http://pdfserv.maxim-ic.com/en/an/AN3967.pdf. (Accessed on November 17,
2011).
220

[33] Huang, “PIC® Microcontroller: An Introduction to Software and Hardware
Interfacing,” Thomson-Delmar Learning, 2005, pg. 508, ISBN: 1-4018-3967-3.
[34] Huang, “The HCS12/9S12: An Introduction to Software and Hard Interfacing,”
Thomson-Delmar Learning, 2006, pg. 494, ISBN: 1-4018-9812-2.
[35] Xilinx LogiCORE IP XPS Serial Perpiheral Interface (SPI) (v2.02a) Product
Specification DS570, June 22, 2011. Website:
http://www.xilinx.com/support/documentation/ip_documentation/xps_spi.pdf. (Accessed
on November 17, 2011).
[36] Altera Corporation Application Note 184: “Simultaneous Multi-Mastering with the
Avalon Bus,” Version 1.1, April 2002. Website: http://www.altera.ru/Disks/Altera
Documentation Library/literature/an/an184.pdf. (Accessed on November 17, 2011).
[37] Altera Corporation, “SOPC User Builder Guide,” December 2010. Website:
http://www.altera.com/literature/ug/ug_sopc_builder.pdf. (Accessed on November 17,
2011).
[38] M. Abd-El-Barr and H. El-Rewini, “Fundamentals of Computer Organization and
Architecture,” John Wiley and Sons, 2005, pp. 179 – 180, ISBN: 0-471-46741-3.
[39] M. van Osch and S. Smolka, “Finite-State Analysis of the CAN Bus Protocol,” in
Proceedings of the 6 th IEEE International Symposium on High Assurance Systems
Engineering (HASE ’01), 22 – 24 October 2001, Page(s): 42 – 52.
[40] Y. Yellambalase and M. Choi, “Automatic Node Discovery in CAN (Controller Area
Network) Controllers Using Reserved Identifier Bits,” IMTC 2007 – Instrumentation and
Measurement Technology Conference, May 1 – 3, 2007.
[41] G. Cena and A. Valenzano, “A Protocol for Automatic Node Discovery in CANOpen
Networks,” in IEEE Transactions on Industrial Electronics, Volume 50, Number 3, June
2003, Page(s): 419 – 430.
[42] Microchip PIC12C67X – 8 – Pin, 8 – Bit CMOS Microcontroller with A/D Converter
and EEPROM Data Memory Datasheet. Website:
http://ww1.microchip.com/downloads/en/DeviceDoc/30561b.pdf. (Accessed on
November 17, 2011).
[43] O. Pfeiffer, “Selecting a CAN Controller”. Website:
http://www.esacademy.com/en/library/technical-articles-and-documents/can-andcanopen/selecting-a-can-controller.html.
(Accessed on November 17, 2011).
221

[44] Microchip MCP2515 – Stand-Alone CAN Controller With SPI Interface Datasheet.
Website: http://ww1.microchip.com/downloads/en/devicedoc/21801e.pdf. (Accessed on
November 29, 2011).
[45] Microchip MCP 2551 – High-Speed CAN Transceiver Datasheet. Website:
http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf. (Accessed on
November 17, 2011).
[46] Microchip MCP 2515 – Stand-Alone CAN Controller with SPI Interface Datasheet.
Website: http://ww1.microchip.com/downloads/en/DeviceDoc/21801F.pdf. (Accessed
on November 17, 2011).
[47] Microchip Application Note AN215: “A Simple CAN Node using the MCP2515 and
PIC12C67X,” November 8, 2010. Website:
http://ww1.microchip.com/downloads/en/AppNotes/00215c.pdf. (Accessed on
November 17, 2011).
[48] P. Hank and E. Jӧhnk, Philips Semiconductors Application Note AN97067: “SJA 1000
Stand – Alone CAN Controller,” December 15, 1997. Website:
http://www.nxp.com/documents/application_note/AN97076.pdf. (Accessed on
November 17, 2011).
[49] K. W. Tindell, A. Burns, and A. J. Wellings, “Calculating Controller Area Network
(CAN) Messages Response Times,” in Control Engineering Practice, Colume 3,
Number 8, pp. 1163 – 1169, 1995.
[50] K. W. Tindell, H. Hansson, and A. J. Wellings, “Analysing Real-Time Communications:
Controller Area Network (CAN),” in Proceedings Real-Time Systems Symposium,
1994, pp. 259 – 263.
[51] R. Obermaisser and D. Riezler, “HIS/Vector CAN Driver API on Top of a Time-
Triggered Communication Protocol”, 07AE – 290, in SAE International, 2007.
[52] J. Rushby, “Bus Architectures for Safety-Critical Embedded Systems,” in Proceedings of
the 1 st Workshop on Embedded Software, October 2001.
[53] H. Kopetz, “Why Time-Triggered Architectures will Succeed in Large Hard Real-Time
Systems,” in Proceedings of the Fifth IEEE Computer Society Workshop on Future
Trands of Distributed Computing systems, 1995, Page(s): 2 – 9.
[54] FlexRay Consortium. BMW AG, DaimlerChrysler AG, General Motors Corporation,
Freescale GmbH, Philips GmbH, Robert Bosch GmbH, and Volkswagen AG. FlexRay
Requirements Specification Version 2.1, December 2005.
222

[55] H. Kopetz and G. Bauer, “The Time-Triggered Architecture,” in Proceedings of the
IEEE, Volume 91, Issue 1, 2003, Page(s): 112 – 126.
[56] E. A. Bretz, “By – Wire Cars Turn the Corner,” in IEEE Spectrum, Volume 38, Issue 4,
2001, Page(s): 68 – 73.
[57] A. Albert, “Comparison of Event-Triggered and Time-Triggered Concepts with Regard
to Distributed Control systems,” in Embedded World 2004, Nürnberg, February 17 – 19,
2004, Page(s): 235 – 252.
[58] R. Obermaisser, “Event-Triggered and Time-Triggered Control Paradigms,” Springer
Science and Business Media, 2005, ISBN: 0-387-23043-2.
[59] A. Albert and W. Gerth, “Evaluation and Comparison of the Real-Time Performance of
CAN and TTCAN,” 9th international CAN in Automation Conference, iCC, Munich,
pages 05/01–05/08, 2003.
[60] Wikipedia – Defintion of Real-Time Computing. Website:
http://en.wikipedia.org/wiki/Real-time_computing. (Accessed on November 17, 2011).
[61] S. Zug, M. Schulze, and J. Kaiser, “Latency Analysis for the Cooperation of Event and
Time-Triggered Networks,” in IEEE International Workshop on Factory Communication
Systems, WCFS 2008, Page(s): 3 – 9.
[62] T. Führer, B. Müller, W. Dieterle, F. Hartwich, R. Hugel, and M. Walther, “Time-
Triggered Communication on CAN (Time-Triggered CAN – TTCAN).” Website:
http://www.can-cia.de/fileadmin/cia/pdfs/technology/fuehrer.pdf. (Accessed on
November 17, 2011).
[63] Latency Defintion. Website: http://www.linfo.org/latency.html. (Accessed on November
17, 2011).
[64] Wikipedia – Definition of Latency (Engineering). Website:
http://en.wikipedia.org/wiki/Latency_(engineering). (Accessed on November 17, 2011).
[65] Rainbow Layers – Jaco Swart’s website and blog, “Can the CAN bus solve your design
problems?” Website: http://www.rainbowlayers.co.nz/portfolio/CAN-bus. (Accessed on
February 11, 2010).
[66] J.P. Acle, M.S. Reorda, and M. Violante, “Early, Accurate Dependability Analysis of
CAN-Based Networked Systems,” in IEEE Design & Test of Computers, Volume 23,
Issue 1, Jan. – Feb. 2006, Page(s): 38 – 45.
223

[67] K. Tindell and A. Burns, “Guaranteeing Message Latencies on Control Area Network
(CAN),” Department of Computer Science, University of York.
[68] K. Tindell, “Fixed Priority Scheduling of Hard Real-Time Systems,” YCST 94/03, DPhil
Thesis, Department of Computer Science, University of York (1993).
[69] N. Audsley, A. Burns,M. Richardson, K. Tindell, and A. Wellings, “Applying New
Scheduling Theory to Static Priority Pre-emptive Scheduling,” Software Engineering
Journal 8(5) pp. 284-292 (September 1993).
[70] A. Burns, M. Nicholson, K. Tindell, and Zhang, “Allocating and Scheduling Hard Real-
Time Tasks on a Point-to-Point Distributed System,” in Proceedings of the The
Workshop on Parallel and Distributed Real-Time Systems, pp. 11-20, Newport Beach,
California (April 13-15 1993).
[71] Maxim Application Note 159: “Software Methods to Achieve Robust 1 – Wire®
Communication in iButton Applications,” September 22, 2008. Website:
http://pdfserv.maxim-ic.com/en/an/AN159.pdf. (Accessed November 17, 2011).
[72] B. Linke, “Maxim Application Note 3829: Determining the Recovery Time for Multiple
Slave 1 – Wire® Networks,” June 21, 2006. Website: http://pdfserv.maximic.com/en/an/AN3829.pdf.
(Accessed on November 17, 2011).
[73] Maxim Semiconductor DS2411 – Silicon Serial Number with Vcc Input Datasheet,
Revision 2, December 21, 2006. Website: http://datasheets.maximic.com/en/ds/DS2411.pdf.
(Accessed on November 17, 2011).
[74] H. Nguyen and M. Vai, “RAPID Prototyping Technology,” in Lincoln Laboratory
Journal, Volume 18, Number 2, 2010, Pages 17 – 27.
[75] B. Linke, “Dallas – Maxim Semiconductor Application Note 937: Book of iButton
Standards,” January 16, 2002. Website: http://pdfserv.maxim-ic.com/en/an/AN937.pdf.
(Accessed on November 17, 2011).
[76] Maxim Application Note: “DS1WM – Synthesizable 1 – Wire® Bus Master,” Revision 3,
September 17, 2007. Website: http://datasheets.maxim-ic.com/en/ds/DS1WM.pdf.
(Accessed on November 17, 2011).
[77] Maxim Integrated Products Serial Number iButton DS1990A Datasheet, Revision 3,
October 2008. Website: http://datasheets.maxim-ic.com/en/ds/DS1990A.pdf. (Accessed
on November 17, 2011).
224

[78] Maxim Integrated Products Serial Number iButton DS1990R, DS1990R – F3,
DS1990R – F5 Datasheet, 19-4894, Revision 4, August 2010. Website:
http://datasheets.maxim-ic.com/en/ds/DS1990R-DS1990R-F5.pdf. (Accessed on
November 17, 2011).
[79] Maxim Integrated Products DS9092L – iButton Probe with LED Datasheet, 19-4868,
Revision 3, August 2009. Website: http://datasheets.maxim-ic.com/en/ds/DS9092L.pdf.
(Accessed on November 17, 2011).
[80] Maxim Integrated Products DS1402X – 1 – Wire® Network Cables Datasheet, 19-4684,
June 2009. Website: http://datasheets.maxim-ic.com/en/ds/DS1402-BP8-DS1402D-
DR8.pdf. (Accessed on November 17, 2011).
[81] Maxim Integrated Products DS1401, DS1401-4 – Front Panel iButton Holder
Datasheet, 19-4860, Revision 2, August 2009. Website: http://datasheets.maximic.com/en/ds/DS1401-DS1401-4.pdf.
(Accessed on November 17, 2011).
[82] Maxim Integrated Products DS1994 – 4Kb Plus Time Memory iButton Datasheet, 19-
5049, Revision 4, November 2009. Website: http://datasheets.maximic.com/en/ds/DS1994.pdf.
(Access on November 17, 2011).
[83] Maxim Integrated Products DS1996 – 64Kb Memory iButton Datasheet, 19-4896,
Revision 3, August 2009. Website: http://datasheets.maxim-ic.com/en/ds/DS1996.pdf.
(Accessed on November 17, 2011).
[84] Maxim Integrates Products DS1904 – RTC iButton Datasheet, 19-4864, Revision 3,
April 2011. Website: http://datasheets.maxim-ic.com/en/ds/DS1904.pdf. (Accessed on
November 17, 2011).
[85] Maxim Integrated Products DS1972 – 1024-bit EEPROM iButton Datasheet, 19-4888,
Revision 3, April 2010. Website: http://datasheets.maxim-ic.com/en/ds/DS1972.pdf.
(Accessed on November 17, 2011).
[86] Maxim Integrated Products DS1822-PAR – Econo 1 – Wire® Parasite-Power Digital
Thermometer Datasheet, Revision 1. Website: http://datasheets.maximic.com/en/ds/DS1822-PAR.pdf.
(Accessed on November 17, 2011).
[87] Maxim Integrated Products DS2431 – 1024-Bit 1 – Wire® EEPROM Datasheet, 19-
4675, Revision 10, March 2011. Website: http://datasheets.maximic.com/en/ds/DS2431.pdf.
(Accessed on November 17, 2011).
225

[88] “Verilog – A Language Reference Manual (Analog Extensions to Verilog HDL),”
Version 1.0, August 1, 1996, Open Verilog International. Website:
http://www.vhdl.org/verilog-ams/htmlpages/public-docs/lrm/VerilogA/verilog-a-lrm-1-
0.pdf. (Accessed on November 17, 2011).
[89] Maxim Integrated Products DS1963S – SHA iButton Datasheet. Website:
http://www.maxim-ic.com/datasheet/index.mvp/id/2822. (Accessed on November 17,
2011).
[90] Maxim Integrated Products DS1995 – 16Kb Memory iButton Datasheet, 19-4895,
Revision 3, August 2009. Website: http://datasheets.maxim-ic.com/en/ds/DS1995.pdf.
(Accessed on November 17, 2011).
[91] Maxim Integrated Products DS1963L – 4Kb Monetary iButton Datasheet, Revision 2.
Website: http://datasheets.maxim-ic.com/en/ds/DS1963L.pdf. (Accessed on November
17, 2011).
[92] Maxim Integrated Products DS1921G – Thermochron iButton Datasheet, 19-5101,
Revision 5, September 2011. Website: http://datasheets.maximic.com/en/ds/DS1921G.pdf.
(Accessed on November 17, 2011).
[93] Maxim Integrated Products DS1977 – Password-Protected 32Kb EEPROM iButton
Datasheet, 19-4890, Revision 4, November 2009. Website: http://datasheets.maximic.com/en/ds/DS1977.pdf.
(Accessed on November 17, 2011).
[94] Maxim Integrated Products DS1922L, DS1922T – Temperature Logger iButton with 8Kb
Datalog Memory Datasheet, 19-4990, Revision 10, April 2011. Website:
http://datasheets.maxim-ic.com/en/ds/DS1922L-DS1922T.pdf. (Accessed on November
17, 2011).
[95] Freescale Semiconductor, Inc., “Bosch Controller Area Network (CAN) Version 2.0
Protocol Standard”, BCANPSV2.0/D, Revision 3. Website:
http://cache.freescale.com/files/microcontrollers/doc/data_sheet/BCANPSV2.pdf?fsrch=
1&sr=10. (Accessed on November 17, 2011).
[96] K. Terry, Motorola Freescale Semiconductor, Inc., Semiconductor Engineering Bulletin,
“The Motorola MCAN Module,” EB421/D, July 1996. Website:
http://cache.freescale.com/files/microcontrollers/doc/eng_bulletin/EB421.pdf. (Accessed
on November 17, 2011).
226

[97] Freescale Semiconductor, Inc., Motorola Semiconductor Engineering Bulletin,
“Frequently Asked Questions and Answers – M68HC05 Family MCAN Module,”
EB181/D. Website:
http://cache.freescale.com/files/microcontrollers/doc/eng_bulletin/EB181.pdf?fsrch=1&sr
=2. (Accessed on November 17, 2011).
[98] CAN Bosch Controller Area Network Version 2.0 Protocol Standard by Motorola,
BCANPSV2.0/D Rev. 3. Website: http://cst.mi.fuberlin.de/projects/ScatterWeb/moduleComponents/CanBus_CANbook.pdf.
(Accessed on
November 17, 2011).
[99] Maxim Integrated Products DS1986 – 64Kb Add-Only iButton Datasheet, 19-4893,
Revision August 2009. Website: http://datasheets.maxim-ic.com/en/ds/DS1986.pdf.
(Accessed on December 4, 2011).
[100] S. Corrigan, “Improved CAN network security with TI’s SN65HVD1050 transceiver,”
Texas Instruments Incorporated Analog Applications Journal, 3 rd Quarter 2006, page(s):
17 – 19.
[101] Fairchild Semiconductor 54/74F433 – First-In First-Out (FIFO) Buffer Memory
Datasheet, DS009544, Revised August 1999. Website:
http://pdf1.alldatasheet.com/datasheet-pdf/view/50350/FAIRCHILD/74F433.html
(Accessed on February 11, 2012).
227