EMBEDDED TECHNOLOGY
TM
CD-ROM
INCLUDED
CONTAINING
Code model
toolkits in C
and assembl
language
Using the Microchip dsPIC
*■
•
Intelligent Sensor Design
Using the Microchip dsPIC®
This Page Intentionally Left Blank
Intelligent Sensor Design
Using the Microchip dsPIC®
by Creed Huddleston
ELSEVIER
AMSTERDAM • BOSTON • HEIDELBERG • LONDON
NEW YORK • OXFORD • PARIS • SAN DIEGO
SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO
Newnes is an imprint of Elsevier
Newnes
Newnes is an imprint of Elsevier
30 Corporate Drive, Suite 400, Burlington, MA 01803, USA
Linacre House, Jordan Hill, Oxford OX2 8DP, UK
Copyright © 2007, Elsevier Inc. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted
in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise,
without the prior written permission of the publisher.
Permissions may be sought directly from Elsevier's Science & Technology Rights
Department in Oxford, UK: phone: (+44) 1865 843830, fax: (+44) 1865 853333,
e-mail: permissions@elsevier.com.uk. You may also complete your request on-line via the
Elsevier homepage (http://elsevier.com), by selecting "Support & Contact," then
"Copyright and Permission" and then "Obtaining Permissions."
Recognizing the importance of preserving what has been written,
Elsevier prints its books on acid-free paper whenever possible.
Library of Congress Cataloging-in-Publication Data
Application submitted
British Library Cataloguing-in-Publication Data
A catalogue record for this book is available from the British Library.
ISBN-13: 978-0-7506-7755-4
ISBN-10: 0-7506-7755-4
For information on all Newnes publications
visit our website at www.books.elsevier.com
06 07 08 09 10 10 9 8 7 6 5 4 3 2 1
Printed in the United States of America
Working together to grow
libraries in developing countries
www.elsevier.com | www.bookaid.org | www.sabre.org
ELSEVIER
BOOK AID
International
Sabre Foundation
Certain materials contained herein are reprinted with the permission of Microchip Technology, Inc.
No further reprints or reproductions may be made of said materials without Microchip Technology Inc. s
prior written consent.
dsPIC, MPLAB, Microchip, dsPICDEM, and dsPICworks are trademarks or registered trademarks of
Microchip Technology, Inc. "Implementing Intelligent Sensors Using the Microchip dsPIC" is an inde-
pendent book and is not affiliated with, nor has it been authorized, sponsored, or otherwise approved by
Microchip.
This book is lovingly dedicated to my incredible wife Lisa
and my three wonderful children, Kate, Beth, and Dan.
We are truly blessed to be a family, a fact I reflect upon often.
The book is also dedicated to my sister Sarah, whose tremendous
laugh Til always remember and who probably would have been
stunned (but hopefully pleased) to see her name here.
This Page Intentionally Left Blank
Contents
Introduction xi
Acknowledgments xv
About the Author xvii
What's on the CD-ROM? xix
Chapter 1: What Are Intelligent Sensors, and
Why Should I Care about Them? 1
1.1 Conventional Sensors Arent Perfect 3
1.2 First Things First — Digitizing the Sensor Signal. 7
1.3 Next Step — Add Some Intelligence 8
1.4 Finish Up with Quick and Reliable Communications 8
1.5 Put It All Together, and Youve Got an Intelligent Sensor 9
1.6 Why Dorit We Make Everything Intelligent? 11
1.7 Real-world Examples of Intelligent Sensors 13
1.8 Outline of the Remainder of the Book 16
Chapter 2: Intuitive Digital Signal Processing 21
2.1 Foundational Concepts for Signal Processing 21
2.2 Issues Related to Signal Sampling 44
2.3 How to Analyze a Sensor Signal Application 47
2.4 A General Sensor Signal-processing Framework 48
2.5 Summary 51
Chapter 3: Underneath the Hood of the dsPIC DSC 53
3.1 The dsPICDSCs Data Processing Architecture 55
3.2 Interrupt Structure 69
VII
viii Contents
3.3 The On-chip Peripherals 71
3.4 Summary 96
Chapter 4: Learning to be a Good Communicator 99
4.1 Types of Communications 99
4.2 Communication Options Available on the dsPIC30F 106
4.3 High-level Protocols 126
4.4 Summary 134
Chapter 5: A Basic Toolkit for the dsPIC DSC 137
5. 1 The Application Test Bed 137
5.2 Overview of the Firmware Framework 138
5.3 Implementation of the Framework Modules 149
5.4 Summary 159
Chapter 6: Sensor Application — Temperature Sensor 161
6.1 Types of Temperature Sensors 762
6.2 Key Aspects of Temperature Measurement 167
6.3 Application Design 185
6.4 Hardware Implementation 197
6.5 Firmware Implementation 200
6. 6 Summary 205
Chapter 7: Sensor Application — Pressure and Load Sensors . . 209
7.1 Types of Load and Pressure Sensors 209
7.2 Key Aspects of Load Measurement 212
7.3 Application Design 216
7.4 Firmware Lmplementation 219
7.5 Summary
Chapter 8: Sensor Application — Flow Sensors 229
8. 1 Types of Flow Sensors 229
8.2 Key Aspects of Flow Measurement
8.3 Application Design 236
8.4 Hardware Lmplementation
8.5 Firmware Lmplementation
8. 6 Summary 250
Contents ix
Chapter 9: Where Are We Headed?
9. 1 Technology Trends
9.2 Economic Trends 260
93 Summary 261
Appendix A: Software on the Included CD-ROM 265
A. 1 On-disk Website of Resources 265
A. 2 Source Code for the Three Applications 266
Appendix B: Initialization of the dsPIC DSC
and the System Start-up Code 267
Appendix C: Buffered, Interrupt-driven Serial I/O 271
C. 1 Pseudo-code for the Framework
C.2 System Initialization
C.3 Reading Data From the Interface
C.4 Writing Data to the Interface
Index 275
This Page Intentionally Left Blank
Introduction
Just as no book covers all subjects, neither is a single book appropriate for all readers.
As much as I wish it were otherwise, Intelligent Sensor Design Using the Microchip
dsPICis no exception. The book primarily targets three groups of readers:
1 . the experienced embedded system designer who is trying to get up to speed
on the Microchip dsPIC DSC relatively quickly and doesn't have time to
wade through a huge amount of detailed documentation in order to get a
system up and running,
2. the engineering student who is new to embedded systems and needs extra
guidance on how all the development pieces fit together, and
3. anyone with a programming or engineering background who is interested in
learning more about the fascinating field of intelligent sensing.
To get the most out of the material presented here, the reader should be familiar
with the basics of the C programming language. While none of the examples use
esoteric C statement constructions, the focus in the text is on applications, specifi-
cally on the design of sensing systems, not on the programming language per se. If
the reader does not have a background in C, there are a number of excellent books
that teach the language well, and the reader is advised to consult those first.
Neither is the book a primer on digital signal processing (DSP). Although it offers
a quick (one chapter) overview of the basic concepts of DSP, this is not a rigorous
academic treatment of the subject. That's not meant in any way to be dismissive
of such texts; they are extremely valuable, and over the years I've bought a lot of
them! Nonetheless, in the book we use DSP as a tool and assume that the reader
either already has some facility with the tool or can acquire it through other means.
Since the goal of the material is to develop an intuitive understanding of the DSP
principles that we might want to use, a deeply detailed exegesis of the subject would
XI
xii Introduction
simply waste time. There are others far more qualified than the author to write such
a book, and the accompanying CD offers some suggested reading.
Finally, the book is not a hardware design manual; although we discuss some
circuitry in the examples, the focus is really more on establishing a basic signal-con-
ditioning platform and then using the software capabilities of the dsPIC DSC to
extract useful information from the systems we're monitoring. As with programming
and DSP, there are a great many excellent treatises on the intricacies of analog and
digital circuit design that are written by masters in the field.
Having said what the book is not, we're now ready to look at what the book
is. The goal of the material is to enable readers to quickly assemble a software and
hardware development platform and to assimilate the knowledge that allows them
to easily experiment with various approaches to the design of intelligent sensors.
This new class of sensing device is rapidly displacing traditional sensors by offering
improved measurement capabilities, the ability to easily interface to a wide variety
of monitoring and control systems, and other features that simply aren't available
through standard sensors. To that end, the book develops three complete intelligent
sensor applications in the area of temperature measurement, load cell monitoring,
and flow sensing. Well-commented source code for all three applications is included
in the accompanying CD, as well as links to a variety of valuable Internet-based
resources.
One issue that's important is that, in the book, I use a variety of Microchip
hardware and software development components, and at first blush it may appear
that the book is a thinly disguised marketing effort by Microchip. Nothing could be
further from the truth. Microchip has offered no financial support for this project,
and while my company, Omnisys Corporation, is an authorized Microchip con-
sultant, we are also authorized consultants for a number of other semiconductor
companies, including Cypress, Freescale, and Lattice.
The primary reason for using Microchip development components is that they
are readily available, inexpensive (often free), and there are user forums available
to get help when the inevitable questions or problems arise. For instance, the
Microchip C compiler (student edition) and its MPLAB Integrated Development
Environment (IDE) are available for download for free from the company website,
as is the Filter Lab 2.0 software for designing analog anti-aliasing filters (more on
this later). In addition, Microchip offers dsPICWorks (a DSP analysis tool) for free
and its dsPIC Filter Design Software for a very reasonable price. Most developers I
know don't want to have to spend huge amounts of money just to get to the point
Introduction xiii
where they can test out a few concepts. Microchip does a great job of providing
low-cost and free tools. These are tools that I use in my daily development work,
so I'm familiar with them.
I hope that you enjoy this book as much as I have enjoyed writing it. My experi-
ence with embedded systems, particularly hard real-time control and communication
systems stretches back over 20 years, and during that time I've been fortunate to be
involved with a number of very intelligent, insightful individuals working on some
very difficult problems. If I've done my job well, you'll take away some of those
insights as well.
This Page Intentionally Left Blank
Acknowledgments
The genesis of this book was an article I wrote that appeared in the January 2003
issue of Sensors Magazine. Titled Digital Signal Processing Turns Thermocouples Into
Superstars, the article caught the eye of Carol Lewis, then an acquisitions editor for
Butterworth-Heinemann/Newnes, a division of Elsevier Press. She graciously asked
whether I would be interested in writing a book-length treatment of dsPIC-based
intelligent sensors. Although Carol subsequently retired before I completed the
manuscript, in one of those pleasant twists of fate, she was available to copyedit
the final draft. For Carol's initial belief in my writing skills and for her subsequent
efforts in shaping the final draft, I am extremely grateful.
I was also very fortunate in the form of my new editor, Tiffany Gasbarrini, who
assumed the role of mentor, friend, shield, and occasionally goad (but only when
absolutely necessary). Without her skill in all four roles, this book would never have
seen the light of day, as both she and my wife can attest. Tiffany was ably assisted by
Michele Cronin, who joined the team about six months before completion of the
manuscript. Michele s attention to detail and her pleasant personality contributed
both to the technical quality of the book and to the enjoyment I got out of writing it.
Over the years, I've been privileged to work with a number of outstanding engi-
neers who helped shape my understanding of the practice of engineering design,
particularly for hard real-time systems. Four in particular stand out, and you the
reader will benefit directly because of what I've learned from them. Dale DuVall,
John Bateson, and Dale Redford, whom I first met at Scantek Corporation in the
late 1980s taught me the value of thoroughly understanding the physical processes
underpinning any electronic system. While all three were the best pure engineers
that I've worked with, each had his own area of expertise and provided different
insights into the design process.
xv
xvi Acknowledgments
Dale DuVall was a physicist by training, and his understanding of how things
worked down to the most detailed level was nothing short of phenomenal. Through
his uncanny ability to relate similar effects in different areas of study, I learned the
importance of keeping one's eyes open and not ignoring anomalies. In John, I met
absolutely the best analog designer I've ever known, and one of the most intelligent
and most enjoyable people as well. John's attention to detail, to doing things the
right way, is still the gold standard in my eyes. Last but certainly not least is Dale
Redford, a brilliant digital designer who will not settle for anything less than the
best when it comes to circuit or system design. All three of these guys are special,
and I remember my time at Scantek fondly.
The fourth engineer also happens to be a close personal friend, my business
partner at Omnisys Corporation for the past eleven years, and hockey linemate:
Fred Frantz. Together we have been fortunate to design control and communication
systems that are used to manufacture products that run the gamut from neonatal
heart monitors, to car bumpers, to products that steer high-end yachts electroni-
cally. Through all of it, I've learned a lot from Fred and have very much enjoyed the
many hours we've spent together.
Of course, all that design work at Omnisys didn't get done by just two folks, and
I'd like to thank Parry Admire, John Brashier, and Mary Frantz (yes, that's Fred's
wife and an excellent engineer to boot), and Steve Gibson in particular, for both
the friendship and great engineering skills they bring to the table.
Finally, though, my greatest acknowledgements of thanks have to go to those
who mean the most to me: my family. Only as a parent have I come to realize just
how much time and love Mother and Dad gave me growing up, and how much my
sisters Susan and Sarah put up with having me as a brother. When Susan married
James Belote, I finally got the brother I never had growing up; he (and now their
children) always brings great light to any family gathering. When I married Lisa,
my family expanded with the addition of a great mother-in-law and a great father-
in-law, Johnie and Gerhard Schulz, who are truly a second mom and dad to me as
well. Marrying Lisa, however, was far and away the most intelligent decision I've
ever made, and I'm grateful every day that she's my partner in life. As for our three
children, Katie, Beth, and Dan, they are truly the lights of our lives, and proof (if
any was needed) of just how fortunate I am.
About the Author
With over twenty years of experience designing real-time embedded systems, Creed
Huddleston is Vice President of Omnisys Corporation, a new product development
company based in Raleigh, NC that specializes in the creation of hard real-time
instrumentation, control, and communication systems. One of the company's found-
ers, he is responsible for new product design and for the development of Omnisys'
authorized consultant relationships with companies such as Microchip Technologies,
Freescale Semiconductor, Lattice Semiconductor, and TrollTech.
In addition to his duties with Omnisys, Creed also serves on the Advisory Board
of Quickfilter Technologies Inc., a Texas-based company producing mixed-signal
integrated circuits that provide high-speed analog signal conditioning and digital
signal processing in a single package.
A graduate of Rice University in Houston, TX with a BSEE degree, Creed per-
formed extensive graduate work in digital signal processing at the University of Texas
at Arlington before heading east to Raleigh, NC to start Omnisys Corporation. To
her great credit and his great fortune, Creed and his wife Lisa have been married for
23 years and have three wonderful children: Katie, Beth, and Dan.
Creed's technical interests focus on the development and application of intel-
ligent sensing systems, particularly in the areas of precision instrumentation, sensor
networking, and high-reliability communications in low-power, long-life embedded
systems. He can be reached at creedh@intelligentsensordesign.com.
XVII
This Page Intentionally Left Blank
What's on the CD-ROM?
The software on the included CD consists of an on-disk website with links to valuable
resources on the Internet and the source code and project files for the three applica-
tions developed in the book. To view the website, either use Windows Explorer™
(the file management program, not to be confused with Internet Explorer, which
is a web browser) to find the file index . htm in the root directory of the CD and
double-click on the file. That should start your web browser and load the first page
of the site. Alternatively, you can enter:
D : \index.htm
in the address bar of your web browser and press the "Go" button in the browser to
load the first page. Note that this assumes that your CD drive is drive D; if this is
not the case, simply substitute the appropriate letter in the path.
Appendix A provides more information about the software included on the CD-ROM.
XIX
What Are Intelligent Sensors,
and Why Should I Care about Them:
?
We took what was a luxury and turned it into a neccesity.
— Henry Ford
In today's instant-access world, people want and expect to be able to get information
when they want it, in the form they need, and at a price they can afford (preferably
free). As Peter Drucker, the greatest management mind of the past 100 years, points
out, unlike physical products, information doesn't operate under the scarcity theory
of economics (in which an item becomes more valuable the less there is of it); on
the contrary, information becomes more useful (and valuable) the more there is
of it and the more broadly it is disseminated. 1 Individuals and organizations that
understand this concept have begun to unlock the tremendous value that has lain
fallow in commercial, academic, and nonprofit enterprises throughout the globe by
digitizing their mountains of raw data, analyzing it to create meaningful information,
and then sending that information via standardized communication links to others
within and outside their organizations to accomplish meaningful work.
It would be difficult to overstate the effects that this new paradigm has wrought
in society economically, intellectually, and in everyday life. People now speak about
working in Internet time, a frame of reference in which both space and time are greatly
compressed. Information from anywhere on the globe can be distributed to virtually
anywhere else quickly and reliably, and Bangalore is now as close to New York City
as Boston. In this new world, people work differently than before; individuals or
groups can easily team with others from around the corner or around the globe to
produce new ideas, new products, or new services, creating fabulous new wealth for
some and destroying ways of life for others. Truly, the new paradigm, which author
Thomas Friedman refers to as the "flattening" of the globe, represents a tectonic
shift in the way people view their world and interact within it.
Interestingly, a nearly identical though largely unnoticed sea change is occurring
in the rather mundane world of sensors. For the uninitiated, sensors (or sensing ele-
2 Chapter 1
merits as they're sometimes called) are devices that allow a user to measure the value
of some physical condition of interest using the inherent physical properties of the
sensor. That's quite a mouthful for a pretty simple concept, namely monitoring the
behavior of one (relatively) easy-to-observe parameter to deduce the value of another
difficult-to-observe parameter.
An example of a very familiar nonelectronic temperature sensor is the mercury
bulb thermometer, in which a column of mercury contracts or expands in response
to the temperature of the material to which it's exposed. In this case, the physical
condition that we're measuring is the temperature of the material in which the
thermometer is inserted, and the inherent physical property of the sensor that we
use for measurement is the height of the mercury in the thermometer.
Water at Freezing Point
(0 °C = 32 °F)
Water at Boiling Point
(100°C = 212°F)
Figure 1. 1. Two Mercury Bulb Thermometers Showing the Temperature of a Material
(Ice and Boiling Water) under Two Different Conditions
So what kinds of parameters can we measure with sensors? The answer is quite
a lot, actually, with the limiting factor generally being our imaginations. Probably
the most widely measured parameter is temperature, but other applications include
pressure, acceleration, humidity, position, pH, and literally thousands more. What
makes sensors so useful, though, is not just their ability to accurately measure a
wide range of parameters but that the sensors can perform those measurements
What Are Intelligent Sensors, and Why Should I Care about Them? 3
under environmental conditions in which human involvement is simply impos-
sible. Whether it's measuring the temperature of molten steel at the center of a
blast furnace or monitoring the ocean current thousands of feet below the surface,
sensors provide the accurate information that allows us to monitor and control all
sorts of important processes.
At first glance, it might seem that sensors fall in the same category as a comfort-
able sweatshirt, nice to have but not particularly exciting. In this case, such a first
impression would be dead wrong. To put things in perspective, in 2005 there were
an estimated 6.4 billion people living on the planet. 2 Coincidentally, the market
for industrial sensors in the United States alone in 2005 was estimated to be $6.4
billion, 3 and $40 billion worldwide. There are far more sensors in the world than
humans, they're called upon to do tasks that range from the mundane to the cutting
edges of science, and people are willing to pay for the value that sensors bring to the
table. That's a powerful and profitable confluence of need, technical challenge, and
economic opportunity, and into the fray has stepped a new class of devices that is
bringing disruptive change to the sensing world: intelligent sensors.
Just what are these intelligent sensors? Conceptually, they're a new class of elec-
tronic sensing device that's literally revolutionizing the way we gather data from the
world around us, how we extract useful information from that data and, finally, how
we use our newfound information to perform all sorts of operations faster, more
accurately, safer, and less expensively than ever before. Even better, we can leverage
the power of individual intelligent sensors by communicating their information to
other intelligent sensors or to other systems, allowing us to accomplish tasks that
weren't possible before and creating incredible advancements in a wide variety of
applications. Sound familiar?
1.1 Conventional Sensors Aren't Perfect
Before we delve into a discussion of intelligent sensors, we first need to examine
regular sensors a bit more closely so that we have a solid foundation upon which
to develop our understanding of intelligent sensors. For all that they do well, most
sensors have a few shortcomings, both technically and economically. To be effective,
a sensor usually must be calibrated — that is, its output must be made to match some
predetermined standard so that its reported values correctly reflect the parameter
being measured. In the case of a bulb thermometer, the gradations next to the
mercury column must be positioned so that they accurately correspond to the level
of the mercury for a given temperature. If the sensor's not calibrated, the informa-
tion that it reports won't be accurate, which can be a big problem for the systems
4 Chapter 1
that use the reported information. Now, not all situations require the same level
of accuracy. For instance, if the thermostat in your house is off by a degree or two,
it doesn't really make much difference; you'll simply adjust the temperature up or
down to suit your comfort. In a chemical reaction, however, that same difference of
a degree or two might literally mean the difference between a valuable compound,
a useless batch of goop, or an explosion! We'll discuss the issue of calibration in
greater depth later, but for now the key concept to understand is that the ability to
calibrate a sensor accurately is a good, often necessary, feature. It's also important
to understand that, as important as it is to calibrate a sensor, often it's extremely
difficult if not impossible to get to a sensor in order to calibrate it manually once
it's been deployed in the field.
The second concern one has when dealing with sensors is that their properties
usually change over time, a phenomenon known as drift. For instance, suppose we're
measuring a DC current in a particular part of a circuit by monitoring the voltage
across a resistor in that circuit (Figure 1.2).
»o
Voltmeter
R
SENSE
Current
o +
To
Circuit
o -
Figure 1.2. Example of a Resistive Sensing Element Used to Measure Current
In this case, the sensor is the resistor and the physical property that we're measur-
ing is the voltage across it, which, as we know from Ohm's Law, 4 will vary directly
What Are Intelligent Sensors, and Why Should I Care about Them? 5
with the amount of current flowing through the resistor. As the resistor ages, its
chemical properties will change, thus altering its resistance. If, for example, we mea-
sured a voltage of 2.7V across the resistor for a current of 100 mA when the system
was new, we might measure a voltage of 2.76V across it for the same current five
years later. While 0.06V may not seem like much, depending upon the application
it may be significant. As with the issue of calibration, some situations require much
stricter drift tolerances than others; the point is that sensor properties will change
with time unless we compensate for the drift in some fashion, and these changes
are usually undesirable.
By the way, are you wondering why in the previous example I referred to the
resistor as the sensing element and not the voltmeter used to measure the voltage?
The distinction is a bit pedantic but important. In the example, I said that we were
monitoring the current in the circuit by measuring the voltage across the resistor.
That made the resistor the primary sensor and the voltage across it the property
that changes in response to a change in the parameter of interest. The voltmeter is
a secondary sensing device that we use to measure the primary parameter. As one
might guess, the voltmeter itself has its own issues with calibration and drift as
well. The reason that the distinction between the primary and secondary sensors is
important is that it's critical to know precisely what you're measuring. Without a
clear understanding of the parameter(s) of interest, it's possible to create a system
that doesn't really measure what you want or that introduces excessive problems with
accuracy. We'll devote more attention to that particular aspect later.
A third problem is that not only do sensors themselves change with time, but
so, too, does the environment in which they operate. An excellent example of that
would be the electronic ignition for an internal combustion engine. Immediately
after a tune-up, all the belts are tight, the spark plugs are new, the fuel injectors are
clean, and the air filter is pristine. From that moment on, things go downhill; the
belts loosen, deposits build up on the spark plugs and fuel injectors, and the air
filter becomes clogged with ever-increasing amounts of dirt and dust. Unless the
electronic ignition can measure how things are changing and make adjustments,
the settings and timing sequence that it uses to fire the spark plugs will become
progressively mismatched for the engine conditions, resulting in poorer performance
and reduced fuel efficiency. That might not strike you as particularly important if
you're zipping around town and have a gas station on most corners, but you prob-
ably wouldn't be quite so sanguine if you were flying across the ocean and had to
make it without refueling! The ability to compensate for often extreme changes in
6 Chapter 1
the operating environment makes a huge difference in a sensor s value to a particular
application.
Yet a fourth problem is that most sensors require some sort of specialized hardware
called signal-conditioning circuitry in order to be of use in monitoring or control
applications. The signal-conditioning circuitry is what transforms the physical sen-
sor property that we're monitoring (often an analog electrical voltage that varies in
some systematic way with the parameter being measured) into a measurement that
can be used by the rest of the system. Depending upon the application, the signal
conditioning may be as simple as a basic amplifier that boosts the sensor signal to
a usable level or it may entail complex circuitry that cleans up the sensor signal
and compensates for environmental conditions, too. Frequently, the conditioning
circuitry itself has to be tuned for the specific sensor being used, and for analog
signals that often means physically adjusting a potentiometer or other such trim-
ming device. In addition, the configuration of the signal-conditioning circuitry
tends to be unique to both the specific type of sensor and to the application itself,
which means that different types of sensors or different applications frequently need
customized circuitry.
Finally, standard sensors usually need to be physically close to the control and
monitoring systems that receive their measurements. In general, the farther a sensor
is from the system using its measurements, the less useful the measurements are. This
is due primarily to the fact that sensor signals that are run long distances are suscep-
tible to electronic noise, thus degrading the quality of the readings at the receiving
end. In many cases, sensors are connected to the monitoring and control systems
using specialized (and expensive) cabling; the longer this cabling is, the more costly
the installation, which is never popular with end users. A related problem is that
sharing sensor outputs among multiple systems becomes very difficult, particularly if
those systems are physically separated. This inability to share outputs may not seem
important, but it severely limits the ability to scale systems to large installations,
resulting in much higher costs to install and support multiple redundant sensors.
What we really need to do is to develop some technique by which we can solve
or at least greatly alleviate these problems of calibration, drift, and signal condition-
ing. If we could find some way to share the sensor outputs easily, we'd be able to
solve the issue of scaling, too. Let's turn now to how that's being accomplished, and
examine the effects the new approach has on the sensor world.
What Are Intelligent Sensors, and Why Should I Care about Them?
1.2
While sensors come in a variety of flavors (electronic, mechanical chemi-
cal, optical, etc.), we'll focus in this book on electronic sensor devices, for
the simple but powerful reason that we can interface their outputs to a
computing element (usually a micro)
processor) easily. It's tF
le computing
element that allows us
to add intelligence to the
sensor
and
I, as
► we 5
II
see, that s a
very valuab
le addition.
First Things First — Digitizing the Sensor Signal
When engineers design a system that employs sensors, they mathematically model the
response of the sensor to the physical parameter being sensed, they mathematically
model the desired response of the signal-conditioning circuitry to the sensor output,
and they then implement those mathematical models in electronic circuitry. All that
modeling is good, but it's important to remember that the models are approxima-
tions (albeit usually fairly accurate approximations) to the real-world response of
the implementation. It would be far better to keep as much of the system as possible
actually in the mathematical realm; numbers, after all, don't drift with time and can
be manipulated precisely and easily. In fact, the discipline of digital signal processing
or DSP, in which signals are manipulated mathematically rather than with electronic
circuitry, is well established and widely practiced. Standard transformations, such
as filtering to remove unwanted noise or frequency mappings to identify particular
signal components, are easily handled using DSP. Furthermore, using DSP principles
we can perform operations that would be impossible using even the most advanced
electronic circuitry.
For that very reason, today's designers also include a stage in the signal-condi-
tioning circuitry in which the analog electrical signal is converted into a digitized
numeric value. This step, called analog-to-digital conversion, AID conversion, or ADC,
is vitally important, because as soon as we can transform the sensor signal into a
numeric value, we can manipulate it using software running on a microprocessor.
Analog-to-digital converters, or ADCs as they're referred to, are usually single-chip
semiconductor devices that can be made to be highly accurate and highly stable
under varying environmental conditions. The required signal-conditioning circuitry
can often be significantly reduced, since much of the environmental compensation
circuitry can be made a part of the ADC and filtering can be performed in software.
As we'll see shortly, this combination of reduced electronic hardware and the ability
to operate almost exclusively in the mathematical world provides tremendous benefits
from both a system-performance standpoint and from a business perspective.
8 Chapter 1
1.3 Next Step — Add Some Intelligence
Once the sensor signal has been digitized, there are two primary options in how
we handle those numeric values and the algorithms that manipulate them. We can
either choose to implement custom digital hardware that essentially "hard-wires"
our processing algorithm, or we can use a microprocessor to provide the necessary
computational power. In general, custom hardware can run faster than microproces-
sor-driven systems, but usually at the price of increased production costs and limited
flexibility. Microprocessors, while not necessarily as fast as a custom hardware solu-
tion, offer the great advantage of design flexibility and tend to be lower-priced since
they can be applied to a variety of situations rather than a single application.
Once we have on-board intelligence, we're able to solve several of the problems
that we noted earlier. Calibration can be automated, component drift can be virtually
eliminated through the use of purely mathematical processing algorithms, and we
can compensate for environmental changes by monitoring conditions on a periodic
basis and making the appropriate adjustments automatically. Adding a brain makes
the designer's life much easier.
As we'll see in Chapter 3, a relatively new class of microprocessor, known as a
digital signal controller or DSC, is rapidly finding favor in products that require low
cost, a high degree of integration (i.e., a great deal of functionality combined into
a single semiconductor chip), and the ability to run both branch-intensive 5 and
computationally intensive software efficiently. Although usually not as fast as custom
digital hardware, in many cases DSCs are fast enough to implement the necessary
algorithms. At the end of the day, that's all that really matters.
1.4 Finish Up with Quick and Reliable
Communications
That leaves just one unresolved issue: sharing sensor values so systems that have
to share sensor outputs can scale easily. Once again, the fact that the sensor data
is numeric allows us to meet this requirement reliably. Just as sharing information
adds to its value in the human world, so too the sharing of measurements with other
components within the system or with other systems adds to the value of these mea-
surements. To do this, we need to equip our intelligent sensor with a standardized
means to communicate its information to other elements. By using standardized
methods of communication, we ensure that the sensor's information can be shared
as broadly, as easily, and as reliably as possible, thus maximizing the usefulness of
the sensor and the information it produces.
What Are Intelligent Sensors, and Why Should I Care about Them? 9
1.5 Put It All Together, and You've Got an
Intelligent Sensor
At this point, we've outlined the three characteristics that most engineers consider
to be mandatory for an intelligent sensor (sometimes called a smart sensor):
1 . a sensing element that measures one or more physical parameters (essentially
the traditional sensor we've been discussing),
2. a computational element that analyzes the measurements made by the sensing
element, and
3. a communication interface to the outside world that allows the device to
exchange information with other components in a larger system.
It's the last two elements that really distinguish intelligent sensors from their
more common standard sensor relatives (see Figure 1.3), because they provide the
abilities to turn data directly into information, to use that information locally, and
to communicate it to other elements in the system.
Essentially, intelligent sensors "flatten" the sensor world, allowing sensors to
connect to other sensors nearby or around the globe and to accomplish tasks that
simply weren't possible prior to their development. Just as importantly, because so
much of their functionality comes from the software that controls them, companies
can differentiate their products merely by changing the configuration of the software
that runs in them.
This has two very important consequences for suppliers of intelligent sensors.
First, it essentially moves the supplier from a hardware-based product to a soft-
ware-based product. While it's certainly true that there has to be a basic hardware
platform for the sensor (this is, after all, a physical device), the hardware is no longer
the primary vehicle for adding (or capturing) value; the software that controls the
intelligent sensor is. Because the manufacturer can add or delete features by flipping
a configuration bit in software, it can alter its product mix almost instantaneously,
and the specific product configuration doesn't have to be finalized until just before
final test and shipment. One hardware platform can be used on multiple products
targeted for different market segments at different price points; and, once new fea-
tures have been developed, no additional production costs are required in order to
include them in the product, so marginal profit soars.
The second consequence is that, because the intelligent sensor is connected to
the outside world, the supplier now has the ability to gather information on the
operation of its sensors in the field under real- wo rid conditions and to update the
software running the sensors after they leave the factory. Not only does the infor-
10 Chapter 1
Sensing Element
Analog Signal
Conditioning
Circuitry
>► Analog Output Signal
Sensing Element
Analog Signal
Conditioning
Circuitry
Digitization
Circuitry
Computational
Element
Communication
Interface
Often a Single
Processor
Other
Systems
Figure 1.3. Block Diagrams of a Standard Sensor (above) and of an Intelligent Sensor (below)
mation from the field offer the sensor manufacturer unparalleled insight into the
needs and concerns of its customers, but it also provides the hard data required to
determine the issues that are most important to those customers (and hence are
the ones that the customers are most likely to value). Armed with this information,
sensor manufacturers can quickly add new features, offer certain configurations on
an as-needed basis, or perform maintenance, all without having to touch the sensor
What Are Intelligent Sensors, and Why Should I Care about Them? 1 1
itself. Services can now be delivered cost-effectively from central locations, providing
yet another opportunity for the supplier to capture additional value and profits. An
example of this is reported in the Harvard Business Review:
Most manufacturers cannot charge more than $90 to $110 per hour
for their technical support because of price and benefit pressures from
local competitors. But GE Energy, because of its efficient network-
enabled remote servicing, can charge $500 to $600 per hour for the
same technician. Even more important, the information generated by
its continual monitoring allows GE to take on additional tasks, such as
managing a customer s spare parts inventory or providing the customer s
and GE s service and support personnel with complete access to unified
data and knowledge about the status of the equipment. 6
1.6 Why Don't We Make Everything Intelligent?
With all of the benefits that come from turning a standard, stand-alone sensor
into a connected, intelligent sensor, are there any reasons why we wouldn't want to
make all sensors intelligent? The answer is "yes," and it's important to understand
the situations for which it's not appropriate to add the type of intelligence and con-
nectivity that we've been discussing. In general, adding intelligence may not make
sense under one or more of the following conditions:
• the additional product development and manufacturing costs cannot be
recouped from the customers within a reasonable time frame,
• the end user is either unable or unwilling to supply the infrastructure required
to power and/or communicate with the intelligent device, or
• the physical constraints of a particular application preclude adding the
additional circuitry required to implement the intelligence and
connectivity.
Development and Production Costs Exceed
Customer-valued Benefits
In order for any product to remain viable over the long term, customers must be
willing to pay enough for the device to cover the cost to develop and manufacture
it. That principle holds just as true for leading-edge technical products such as intel-
ligent sensors as it does for more prosaic products like paper towels; no company
can long afford to make a product for which it receives less money than it costs to
make. Before investing the time and resources to add intelligence to its devices, a
sensor manufacturer needs to determine whether its customers will be willing to pay
12 Chapter 1
enough of a differential in price or services to cover at least the cost of development
and any increased production expenses (less any savings the manufacturer may enjoy
based on the new design) . Unless customers sufficiently value the benefits that an
intelligent device offers, the manufacturer is better off sticking to nonintelligent
products.
At first, it might seem that customers would clearly see the benefits of adding intel-
ligence, but some applications are so cost-driven and have such razor-thin margins
that customers are completely unwilling to invest in new technology. An example
of this would be low-end disposable plastic cutlery, a commodity for which manu-
facturers receive a fraction of a cent of profit per finished item. With such miniscule
profit margins, producers of this type of product simply will not spend much money
on equipment; their buying decisions are focused on the bottom-line purchase price,
and anything that even appears to be optional holds no value at all.
Lack of Necessary Infrastructure
A second major condition under which intelligent sensors should not (or cannot) be
used occurs when a customer lacks the minimum level of infrastructure required to
support both the sensors' power requirements and their communication channels.
Closely related to the previous condition, in which the sensor manufacturer couldn't
cost-justify building the products, this condition is one in which the customer is
unable to economically justify adding the additional infrastructure needed in order
for the sensors to work. Both power and communication channels are mandatory
for intelligent connected sensors; without power, the sensors can't even turn on, and
without communication channels they are unable to report their information.
This aspect of implementing intelligent sensor systems should not be underes-
timated. Although more and more manufacturing plants are becoming wired for
digital data networks, it still represents a significant cost to the customer, one that
many find to be a deal killer. Some of the new networking protocols provide power
along with the wires used for communications (for example, Power-over-Ethernet
(PoE)), but older plants in particular can be very expensive to wire. Newer low-
power wireless sensors are coming into the market to help address these twin issues,
but such solutions tend to be more expensive to purchase (although their long-term
total cost of ownership may be lower) .
What Are Intelligent Sensors, and Why Should I Care about Them? 13
1.7
Environmental Conditions Preclude Additional
Electronic Circuitry
The final, and least common barrier to the use of intelligent sensors occurs when
the environmental conditions of a particular application preclude the use of any
additional electronic circuitry. Such conditions might be size, operating tempera-
tures, severe vibration, or exposure to caustic chemicals. In these cases, a hardened
standard sensor may be the only option, although the sensors performance can
often be significantly improved by converting the measured parameter to a digital
value as soon as possible.
Real-world Examples of Intelligent Sensors
Before wrapping up this chapter, let's look at three examples of intelligent sensors in
the real world, two that come from the industrial process-control market and one
from the vehicular-control market.
Multichannel Digital Temperature Sensor
Temperature is a widely used parameter in the control of various industrial processes,
and one of the most common temperature sensors is the thermocouple. In some
ways, a thermocouple is an extremely simple sensing element; it consists of two
dissimilar metals joined together at a single point and, due to what's known as the
Seebeck effect, the junction of these two metals produces a voltage that varies with
the temperature of the junction (see Figure 1.4).
J Type Thermocouple
(Iron-Constantan )
Ji
Fe ^J
I
I
Thermocouple |
Cu
Cu
Thermocouple
Interface
PCB
Note that there are actually three junctions of dissimilar metals
and thus effectively three thermocouples in the circuit:
^ - sense thermocouple (the only intentional thermocouple)
J 2 -junction of Iron lead with copper PCB trace
J 3 - junction of Constantan lead with copper PCB trace
Figure 1.4. Diagram of a Basic Thermocouple
14 Chapter 1
We'll examine thermocouples in detail in a later chapter, but for now the impor-
tant concept to understand is that the voltage it produces is very small, on the
order of millivolts, and is frequently measured in the presence of significant levels
of electronic noise, which may be on the order of hundreds of volts. Complicating
matters is the fact that the temperature response of thermocouples is nonlinear, so
a linearization operation usually must be performed before the temperature reading
can be used. There are other serious challenges in using thermocouples, but these two
are sufficient to illustrate how intelligent sensors can overcome these issues to provide
accurate readings in an extreme environment: an injection-molding machine.
For those readers unfamiliar with injection molding, it is a manufacturing process
in which solid plastic pellets are heated to between 300°F and 900°F to melt them.
The melted plastic is then injected into a mold under high pressure (on the order
of 10,000-30,000 psi), and the plastic is then allowed to cool back to a solid in the
shape of the mold. This process is repeated rapidly so that the manufacturer can
make parts as quickly as possible. The key to running a successful injection-molding
operation is to keep cycle times (the time it takes to open and close the mold once)
short and scrap rates low. So long as a molder can produce good quality parts at a
profit per part, he essentially has the ability to "print money" based on the speed
at which he can run his cycle. An important aspect is the proper regulation of the
temperature of the plastic at various points throughout the molding machine, which
requires the distribution of temperature sensors (thermocouples) at key points in
the process.
Unfortunately, one of the drawbacks to using thermocouples is that the wire used
to create them is expensive. Molding machines in general are not particularly small,
and the machines employ multiple zones of temperature monitoring and control
(250 zones or more in the larger systems). The thermocouple wires thus must be
run long distances to their associated temperature controllers, resulting in the worst
of all possible worlds: multiple strands of expensive wire that have to be run long
distances. One pioneering company in the temperature-control field realized that
they could save their customers a tremendous amount of money by digitizing the
temperature readings at the mold itself and then shipping the digitized readings to
the controller via standard (and inexpensive) copper cables. Furthermore, they could
do this for many channels of thermocouple readings and, since the thermocouple
readings changed relatively slowly, the digitized readings could be time-multiplexed
when sent to the controller. In the end, up to 96 channels of thermocouple data
could be reported for each device, thus turning a costly, noise-prone system of long
thermocouple wires into an easily managed single pair of copper wires.
What Are Intelligent Sensors, and Why Should I Care about Them? 15
Flow Sensors
While the plastic must be kept in a molten state until it gets to the mold, once there
the goal is to solidify the molten plastic in the desired shape. To do this, cooling
channels are built into the molds that circulate cool water or other fluids to remove
the heat from the plastic quickly. If the flow of the coolant fluid is impeded, the
coolant will warm up because it is staying in contact with the hot mold longer.
This in turn reduces the cooling efficiency of the coolant and lengthens the time it
takes for the part to solidify, thus lengthening the injection cycle time and killing
profitability. Since this is obviously not something any rational molder wants to
happen, smart molders include flow sensors in the coolant systems to ensure that the
coolant is flowing within a desired range. If one knows some of the characteristics
of the cooling fluid itself, can measure the temperature of the fluid at two different
points, and knows the rate of flow, it is also possible to calculate the number of
BTUs transferred from one point to the other in the cooling system.
Flow sensors come in a variety of configurations, but one of the most popular
types is what's known as the in-line flow sensor. In this type of sensor, a propeller-
like device is inserted in-line with the coolant flow, with the speed of the propeller
indicating the flow of the fluid through the sensor. Over time, the bearing on which
the propeller is situated will wear, resulting in an eccentric motion of the propeller
that significantly degrades the quality of flow reading. One leading company devel-
oped a handheld portable unit that used special filtering algorithms to compensate
for propeller bearing wear, which allowed accurate flow readings to be maintained
longer and significantly extended the life of the sensor.
Steer-by-Wire Steering-position Sensor
The final example of a real- world intelligent sensor comes from the vehicular control
market, specifically the steer-by- wire market for marine vehicles (boats) . In a normal
mechanical steering system, there is a physical link between the steering wheel and
the steering-control surface (the wheels of a car, for instance, or the rudder of a
boat) . When the driver turns the wheel one way, the motion is translated through a
series of mechanical linkages into the corresponding change in the steering control
surface. Depending upon how the system is configured, the driver gets feedback
from the steering system (either from the road or the water), which helps the driver
adjust his actions accordingly. Although reliable, mechanical steering systems suffer
from the inability to have more than one steering wheel without extremely complex
(and expensive) mechanical fixtures. That's not such a big deal in a car, where only
one steering wheel is normally needed, but it can be a problem for large boats, in
16 Chapter 1
which it would be very helpful to be able to have one steering wheel at the front
(bow) of the boat when docking and one at the rear (stern) of the boat during
normal cruising.
In a steer-by-wire system, by contrast, most of the mechanical linkages are
replaced by electronic controls; although the driver may turn a steering wheel, that
wheel is linked electronically, not mechanically, to the control surfaces. This offers
several immediate advantages, not the least of which is a significant reduction in
the size and weight required for the steering system. In addition, one can more
easily accommodate two or more steering wheels since they can be linked by an
electronic cable without requiring additional mechanical linkages. One drawback
to steer-by-wire, however, is that until recently the driver had no feedback from the
control surfaces, which could cause a disconcerting feeling of disconnection between
the driver's actions and the resulting response of the vehicle. With the advent of a
special material that changes its properties based on the strength of a magnetic field
passed through it, that lack of feedback has changed. Using a steering sensor that
measures the position of the wheel many times a second, a unique steer-by-wire
system developed by a global innovator adjusts the feedback to the driver by adjust-
ing the density of the special material based on a number of factors, including how
quickly the driver is turning the wheel. In addition, the feedback to the driver can
be changed based on conditions on the control surface, giving the driver not only
a more enjoyable driving experience, but also a safer one.
1.8 Outline of the Remainder of the Book
Now that we have a basic understanding of what intelligent sensors are, have looked
at how they're changing our world, and have seen some real-world examples of intel-
ligent sensors in action, we'll conclude this chapter with a look at what's coming in
the rest of the book.
Although most chapters of the book can be read in isolation, it's recommended
that Chapter 2, Intuitive Digital Signal Processing, be read before Chapter 3, Under-
neath the Hood of the dsPIC DSC, because several of the concepts discussed in
Chapter 2 are needed to fully understand the value of certain functionality in the
dsPIC DSC. In Chapter 2, we develop an intuitive understanding of the digital
signal processing (DSP) principles that we'll need to implement the three types of
intelligent sensors that we'll explore in depth later in the book. The goal is not to turn
the reader into a DSP guru; there are plenty of excellent books out there that treat
the subject far more thoroughly than we do here. Instead, the intent is to develop
What Are Intelligent Sensors, and Why Should I Care about Them? 17
in the reader an understanding of why we apply certain DSP principles so that the
reader gains a firm grasp of when to use a particular approach and the conditions
under which another is likely to be more successful.
Building on the DSP foundation developed in Chapter 2, Chapter 3, Underneath
the Hood of the dsPIC DSC, examines in detail the dsPIC DSC, a family of digital
signal controllers that is remarkably well-suited to the implementation of intelligent
sensors. We will focus our attention on a particular part, the dsPIC30F60l4A, which
contains many features common to all dsPIC chips. Of necessity, we'll also look at
the software development environment for the dsPIC DSC, as well as a number of
software tools and libraries that Microchip provides to speed product development
when using the dsPIC chips. At the conclusion of Chapter 3, we'll explore a basic
sensor software framework that we'll use to build specific intelligent sensors in later
chapters.
Chapter 4, Learning to Be a Good Communicator, furthers our understanding of
the dsPIC device by examining the important subject of communication between the
processor and other devices. These devices may be off-chip but on-board peripheral
components that enhance system functionality, or they may be entire other systems
that are physically distant from the sensor unit itself. As one might expect, the dis-
parate natures of these two situations require differing communication techniques.
Fortunately, the dsPIC device is well-endowed with a variety of communication
interfaces that meet these challenges well. In particular, we'll look at the commu-
nications using the RS232/485 protocol, the Serial Peripheral Interface (SPI), and
the Control Area Network (CAN). These are all industry-standard communica-
tion interfaces, and the ability to use them allows dsPIC-based devices to converse
with a wide variety of systems in a broad universe of operating environments. In
particular, CAN provides robust medium-speed (up to 1 Mbps) communications
between multiple nodes on a network and is found in a huge number of industrial
and vehicular products. As with many communication protocols, having a guide
to sort out what's important and what's not will save the reader significant time,
effort, and frustration.
Chapter 5, A Basic DSP Toolkit for the dsPIC DSC, continues the work begun in
Chapters 3 and 4 by assembling a toolkit of modular software components that we'll
use to perform specific tasks on the dsPIC processor. Once we've put together our
toolkit, we'll conclude the chapter by implementing a multichannel filter bank on
top of the sensor software framework introduced in Chapter 3, which will allow us to
filter (remove the noise) from several channels of signal data reliably and quickly.
18 Chapter 1
Moving into Chapters 6 through 8, we'll explore in depth three specific appli-
cations of intelligent sensors: temperature, pressure, and flow. These chapters will
continue to build on the sensor software framework developed in Chapters 3 and
4 and the DSP building blocks developed in Chapter 5 to implement robust intel-
ligent sensors for each particular application. By the time we've finished Chapter 8,
we will have a thorough grounding in the design of intelligent sensors and how to
implement them using the dsPIC DSC.
The main section of the book concludes with Chapter 9, Where Are We Headed?,
which looks at the future of intelligent sensors and the application of digital signal
controllers. Including a discussion of the merits of open vs. proprietary protocols
and of the trend toward ubiquitous networking of devices, the chapter is intended
to make readers aware of the key issues they should consider when designing prod-
ucts for the future.
In addition to the main portion of the book, there are three appendices that
contain information that seems to stand best on its own, leaving to the reader the
decision whether to wade through it for greater insight or to simply leave it until
required. Appendix A describes the software that is provided on the CD accompany-
ing the book, while Appendix B is devoted to the initialization of the dsPIC device
and the associated system start-up code. In Appendix C, we address the challenging
but oft-ignored aspects of system operation, namely interrupt-driven buffered serial
I/O, which can be used for debugging or regular communications. Since no single
book can rightfully claim to be the ^//-encompassing book on either intelligent sen-
sors or the dsPIC DSC, this book includes an HTML file on the CD that contains
a list of other sources the reader can use to learn more about these subjects.
Finally, for the most up-to-date information on this book, as well as additional sample
programs and resources, please go the website www.intelligentsensordesign.com.
What Are Intelligent Sensors, and Why Should I Care about Them? 19
Endnotes
1 . Management Challenges for the 21 st Century, by Peter F. Drucker. Collins,
2001.
2. According to the CIA World Factbook, the estimated total world population
as of July 2005 was 6,446,131,400. http://www.cia.gov/cia/publications/fact-
book/rankorder/2 1 19rank.html
3. Based on a study (GB-200N Industrial Sensor Technologies and Markets)
by B. L. Gupta for Business Communications Company, Inc. in which the
2004 industrial sensor market size in the United States was $6.1 B, with
an anticipated annual growth rate of 4.6%. http://www.bccresearch.com/
instrum/GB200N.html
4. Ohm's Law isV = I* R, whereV is the voltage measured across a resistance
(in volts), I is the current through the resistance (in amps), and R is the value
of the resistance itself (in ohms). Ohm's Law holds true for a purely resistive
element, which is all we're worried about in this example.
5. Branch intensive software is software that makes frequent changes, known
as branches, in the processing of its program instructions. Computationally
intensive software is software in which a significant portion of the processing
time is devoted to performing mathematical computations.
6. Four Strategies for the Age of Smart Devices, by Glen Allmendinger and Ralph
Lombreglia. Harvard Business Review, October, 2005. Reprint R0510J.
This Page Intentionally Left Blank
Intuitive Digital Signal Processing
If you have an idea, that is good. If you also have ideas as to how
to work it out y that is better.
— Henry Ford
To this point, we've seen how valuable intelligent sensors can be to both end users
and those who manufacture and sell them. It's now time to delve more deeply into
what it takes to make intelligent sensors work. The first step in that journey is to
develop a solid, intuitive understanding of the principles of digital signal processing,
or DSP. Unlike many introductory DSP texts, the focus here will be on presenting
and using the important concepts rather than deriving them, for the simple reason
that addressing the subject in depth is a book-sized, not a chapter-sized, project.
Other authors have already done an excellent job of addressing the topic in a more
rigorous manner, 1 and our goal here is not to try to condense their work to meaning-
less bullet points but rather to understand how to use certain key concepts to turn
raw sensor data into meaningful sensor information. By the end of this chapter, the
reader should be comfortable identifying the key signal processing requirements for
typical applications and be able to determine the appropriate process for extracting
the desired measurements.
2.1 Foundational Concepts for Signal Processing
Although this discussion of DSP isn't as rigorous as most academic treatments of the
subject, it's essential that we establish a clear understanding of several key concepts
that form its foundation. Beginning with precise definitions of what we mean when
we refer to "signals" and "noise," the discussion moves into the analysis of signals
in both the time and frequency domains and concludes with an introduction to
filtering, a technique that is commonly used to extract the desired information from
noisy data. Section 2.2, Applications of DSP Theory, builds on this foundation as
we begin to create a generalized framework that we can apply to a wide variety of
intelligent sensing applications.
21
22 Chapter 2
Getting Specific — What We Mean by Signals and Noise
The dictionary defines the term "signal" as "an impulse or fluctuating electric quan-
tity, as voltage or current, whose variations represent coded information," 2 and this
definition serves well as a starting point. One interesting characteristic of electronic
signals is that they operate under the principle of superposition. This principle
states that the value of two or more signals passing through the same point in the
same medium at a particular point in time is simply the sum of the values of the
individual signals at that point in time. For example, if we had TV different signals
denoted V (t), V x {t), ..., V N _ x {x), the resulting signal V s (t) that is the superposition
of the N signals would be represented mathematically as:
V s (t) = V (t) + V x {t) + ... + V N _ x {t)
Equation 2.1
It turns out that the principle of superposition is a very powerful tool; using it,
we can often deconstruct complex sensor signals into separate, more basic compo-
nents, which may simplify the analysis of the problem and the design of the resulting
system. The real-world sensor examples developed later in this book make extensive
use of this principle in the creation of the appropriate signal-processing techniques
for each specific application, but first let's examine one way in which superposition
leads to a better understanding of all sensor signals.
Consider the circuit shown in Figure 2.1a, which contains a thermocouple con-
nected to a voltmeter in an idealized environment. As discussed in Chapter 1 , the
thermocouple produces an analog output voltage V T (t) that varies over time t with
the temperature of the thermocouple junction. In this case, the measured signal V M {t)
is simply the "true" signal V T (t), and the information coded in it is the temperature
of the thermocouple junction.
Voltmeter
Thermocouple |
Fe
+
I
V M (t)
c j
b
v T (t)
Figure 2. la. Basic Idealized Thermocouple Circuit
Unfortunately, such an idealized environment exists only in our imaginations,
much like a perfectly silent library exists only in a librarian's fantasy. Just as even
Intuitive Digital Signal Processing 23
2.5
1.5
0.5
J Type Thermocouple Readings without Noise
Thermocouple
Voltage (mV)
10
15
20
Figure 2.1b. Example of an Idealized Thermocouple Signal
the quietest library has some audible noise, real-world circuitry contains electronic
noise that comes from both the surrounding environment and the components
used to create the circuit. Thus, a more accurate representation of the basic ther-
mocouple circuit would include an electrical noise generator that produces a noise
voltage component V N {i) superimposed on the "true" thermocouple signal V T (t), as
is shown in Figure 2.3a.
Voltmeter
Figure 2.2a. More Realistic Thermocouple Circuit Model with Noise
24 Chapter 2
3.5
2.5
2 -
1.5
0.5
-0.5
Sample Electronic Noise Signal
Figure 2.2b. Example of an Electronic Noise Signal
J Type Thermocouple with Noise
Electronic
Noise (mV)
4.5
3.5
2.5
1.5
0.5
10
15
Figure 2.2c. Example of a Noisy Thermocouple Signal
20
Thermocouple
Voltage (mV)
Intuitive Digital Signal Processing 25
To an outside observer, this distinction is not actually discernible; they simply
see the measured voltage V M {t) that contains both components and is equal to:
V M (t) = Vj{i) + V N (t) Equation 2.2
Of course, the end user generally doesn't want the noise component to be a part of
the measured signal; after all, he's interested in the "true" thermocouple signal that
has the information of interest, not a corrupted signal that distorts that informa-
tion. Depending upon the characteristics of the signal of interest and of the noise,
it can be possible to accurately extract the signal of interest even in the presence of
significant levels of noise using the techniques to which we will now turn.
Viewing Signals in the Frequency Domain
Any real analog 3 signal can be represented in the frequency domain via a mathematical
operation known as the Fourier transform, and the proper choice of domain (either
the time domain, which is what we measure using an oscilloscope or voltmeter, or
the frequency domain) can greatly simplify the analysis of a particular signal-process-
ing situation. The basic premise of the Fourier transform is that continuous, linear 4
time-domain signals (like the voltages we're measuring in the examples above) can
be accurately represented by the superposition of orthogonal sinusoidal signals of
varying frequencies. That's a tremendous amount of fairly technical mathematical
jargon, but what's valuable about this operation is that it allows us to fairly easily
determine the frequencies in which most of the energy of the signal occurs, which
is essentially telling us what the most important parts of the signal are.
An example may help clarify the point. Consider the purely sinusoidal signal in
Figure 2.3a, and its frequency-domain counterpart in Figure 2.3b. Note the very inter-
esting relationship between the two domains: a continuous signal in the time domain
actually maps to two spikes in the frequency domain symmetrically distributed along
the frequency axis! Although the graph in Figure 2.3b shows two peaks, the spread of
the frequency spectrum is due to limitations of the discrete mathematics used by the
program that generated the image. Mathematically, in the frequency domain there
are two spikes located exactly on the sinusoid's frequency. If we construct a more
complex signal by adding a second sinusoid to the first, the principle of superposition
tells us that we might get a new signal that looks like that shown in Figures 2.4a and
2.4b. Here we see a standard DTMF (dual tone multifrequency) signal, just as you
might get if you punched a digit on your touchtone phone. The addition of a single
extra frequency has caused the signal to lose much of its sinusoidal appearance in
the time domain, but the same signal in the frequency domain is simply four spikes,
with the two additional spikes corresponding to the new frequency.
26 Chapter 2
Example Sinusoidal Signal
Signal
Value
Figure 2.3a. Time-Domain Sinusoidal Signal
Magnitude of Sinusoidal Signal's Frequency Domain Representation
■&*
•%■
Magnitude
-30 -20 -10 10
Figure 2.3b. Frequency-Domain Representation of the Same Signal
20
30
Intuitive Digital Signal Processing 27
1.00 i
0.50
0.00
-0.50
-1.00
DTMF Signal for the "5" Key
Time
Figure 2.4a. DTMF Time-domain Signal
Magnitude of DTMF Frequency Component:
CD
CO
-4000 -3500 -3000 -2500 -2000 -1500 -1000 -500
500 1000 1500 2000 2500 3000 3500 4000
Frequency (Hz)
Figure 2.4b. DTMF Frequency-domain Representation
28 Chapter 2
Figures 2.4a and 2.4b demonstrate a very powerful aspect of the Fourier trans-
form: the superposition principle holds in both the time and the frequency domains.
Signals that are added together in the time domain have a frequency spectrum that
is the sum of the spectra 5 of the individual signal components. Simply by viewing
this signal in the frequency domain, the designer can rapidly identify its constituent
parts, which will be of great use in analyzing and designing the processing required
to extract the information of interest. This concept of spectral analysis, the analysis
of the frequency domain representation of a signal, is a powerful one that we will
apply in the real-world examples in later chapters.
Two terms that often arise when performing spectral analysis are frequency band,
which simply means a continuous range of frequencies, and bandwidth, which gen-
erally refers to the highest frequency component in a signal. For example, in Figure
2.4b, the designer might be interested in the frequency band from 770 Hz to 1477
Hz, which contains the two frequencies that make up that particular DTMF signal.
Since 1477 Hz is the highest frequency signal component, the theoretical bandwidth
for the DTMF signal is 1477 Hz.
There is one additional aspect to the time-domain— frequency-domain representa-
tion issue that is important to understand, and that is the fact that rapidly changing
signals in the time domain generate a broader corresponding spectrum in the frequency
domain, while slowly changing signals produce a narrower overall frequency spectrum
limited to lower frequencies. As we'll see in the next section, sensor designers can use
this fact to determine the optimal approaches to removing noise from the signals
of interest. Figures 2.5a, 2.5b, and 2.5c show frequency domain representations of
low-frequency (slowly changing) , high-frequency (rapidly changing) , and broadband
(low- and high-frequency) signals. In practice, signal distortion will spread the actual
DTMF bandwidth somewhat beyond the 1477 Hz theoretical value.
Magnitude of Signal Frequency Components
Frequency
Figure 2.5a. Low-frequency Content Signal in the Frequency Domain
Intuitive Digital Signal Processing 29
Magnitude of Signal Frequency Components
Frequency
F c
Figure 2.5b. High-frequency Content Signal in the Frequency Domain
Magnitude of Signal Frequency Components
Frequency
F c
Figure 2.5 c. Combination of Low- and High-frequency Content Signal in the Frequency Domain
Cleaning Up the Signal — Introducing Filters
We're all familiar with the general idea of a filter: it removes something that we don't
want from something we do want. Coffee filters that pass the liquid coffee but retain
the grounds or air filters that pass clean air but trap the dust and other pollutants
are two common examples of mechanical filters in everyday life. That same concept
can be applied to noisy electrical signals to pass through the "true" signal of interest
while blocking the undesirable noise signal.
30 Chapter 2
Looking at Figure 2.5c, imagine for a moment that the signal of interest is in the
lower-frequency region and that the noise signal is in the higher-frequency region.
Ideally, we'd like to be able to get rid of that high-frequency noise, leaving just the
signal component that we want. We can picture the process that we'd like to per-
form as one in which we apply a mask in the frequency domain that passes all of
the low-frequency signal components without affecting them at all but that zeros
out all of the high-frequency noise components. Graphically, such a mask might
look like the frequency spectrum shown in Figure 2.6a. If we multiply each point
in the graph of Figure 2.5c by the corresponding point in the graph of the mask in
Figure 2.6a, we get the resulting frequency spectrum shown in Figure 2.6b, which
is precisely what we want.
Low-Pass Filter Frequency Mask
1
Frequency
Figure 2. 6a. Example Frequency Mask
Magnitude of Filtered Signal Frequency Components
Frequency
Figure 2.6b. Result of Multiplying Mask in 2.6a with Spectrum in 2.5c
Intuitive Digital Signal Processing 31
Thought experiments like these are helpful, but is it possible to implement this
in the real world? The answer is "yes," albeit with some important qualifications that
arise from deviations between real-world and idealized system behavior. Before we
get into those qualifications, though, let's take a look at an important foundational
concept: sampling.
Sampling the Analog Signal
Sensor signals are inherently analog signals, which is to say that they are continuous
in time and continuous in their value. Unfortunately, processing analog signals as
analog signals requires special electronic circuitry that is often difficult to design,
expensive, and prone to operational drift over time as the components age and their
properties change. A far better approach is to convert the input analog signals to a
digital value that then can be manipulated by a microprocessor. This technique is
known as analog-to-digital conversion, or sampling.
Figure 2.7a shows an example of a continuous time voltage signal, and Figure
2.7b shows the sampled version of that signal. One key concept that can sometimes
be confusing to those who are new to sampled signals is that the sampled signal is
simply a sequence of numeric values, with each numeric value corresponding to the
level of the continuous signal at a specific time. For a sampled signal such as that
shown in Figure 2.7b, the signal is only valid at the sample time. It is not zero-valued
Example Continuous-time Voltage Signal
1.50
0.008
-1.00
-1.50
Time (seconds)
Figure 2. 7a. Example of a Continuous-time Voltage Signal
32 Chapter 2
Sampled Signal Data
1.50
1.00-
0.50
CD
i 0.00
E
CO
CO
-0.50
-1.00-
-1.50
T
*T
I
1
♦-
±-1
20
T
4
I
^
T
3
r
]
Sample Index
Figure 2. 7b. Corresponding Sampled Version of the Signal in Figure 2. 7a
between samples, but the convention for presenting sampled data graphically is to
display the sample values on a line (or grid), with the X-axis denoting the parameter
used to determine when the data is sampled (typically time or a spatial distance).
Another convention is to associate sampled signal values in a sequence using an
index notation. In this scheme, the first sample of the signal x(t) would be x , the
second sample would be x v and so on. If we add two signals x and y, then the result-
ing signal z is simply the sample-by-sample addition of the two signals:
z = x + y
z l =x l +y l
z N - x N + y N
Sampling has two important effects on the signal. The first of these effects is what's
known as spectral replication, which simply means that a sampled signal's frequency
spectrum is repeated in the frequency domain on a periodic basis, with the period
being equal to the sampling frequency. Figures 2.8a and 2.8b show an example of
the frequency spectrum of an example signal and the resulting frequency spectrum
of the sampled version of the signal.
Intuitive Digital Signal Processing 33
Example Analog Signal Spectrum
-F,
Frequency
-F«
Figure 2. 8a. Example Analog Signal Frequency Spectrum
Sampled Signal Frequency Spectra
-Fc - Fn "Fc + F
-R
-F,
F c -F
Frequency
F. + F,
Figure 2. 8b. Corresponding Frequency Spectrum of the Sampled Signal
As one can easily see, a problem arises when the highest frequency component
in the original signal is greater than twice the sampling frequency, a sample rate
known as the Nyquist rate. In this case, frequency components from the replicated
spectra overlap, a condition known as aliasing since some of the higher frequency
components in one spectrum are indistinguishable from some of the lower frequency
components in the next higher replicated spectrum. Aliasing is generally a bad
34 Chapter 2
condition to have in a system and, although the real world precludes eliminating it
entirely, it is certainly possible to reduce its effects to a negligible level.
Let's look at a simple example to illustrate how aliasing can fool us into thinking
that a signal behaves in one way when in reality it behaves totally differently. Imagine
that we are sampling the position of the sun at various times during the day over an
extended period of time. Being good scientists, we want to verify that our sampling
rate really does make a difference, so we decide to take two sets of measurements
using two different sampling rates. The results from the first set of measurements,
which employ a sampling rate of once every 1.5 hours, are shown in Figure 2.9a.
As we would expect, the measurements show that the sun proceeded from east to
west during the course of the experiment.
East
Apparent motion
West
East
Sample 2
1:30 p.m.
Apparent motion
West
East
Sample 3
3:00 p.m.
Apparent motion
West
East
Sample 4
4:30 p.m.
Apparent motion
West
When the sun's position is sampled every 1.5 hours,
it is seen to move from east to west
Figure 2.9a. Suns Position Sampled Every 1.5 Hours
Intuitive Digital Signal Processing 35
Now take a look at the results from the second set of measurements, which have
a sampling rate of once every 22.5 hours. From the data, we can see that the sun
appears to move from west to east, just the opposite of what we know to be true!
This is exactly the type of error one would expect with aliasing, namely that the
signal characteristics appear to be something other than what they really are (hence
the term aliasing).
Apparent motion
East — ( ] ( ) — West
Apparent motion
Sample 2
10:30 a.m.
East — ( ) ( V- East
Apparent motion
Sample 3
9:00 a.m.
East —i ) ( V- West
Apparent motion
Sample 4
7:30 a.m.
East — ( ) ( V- West
When the sun's position is sampled every 22.5 hours, it appears
to travel in reverse, from west to east . Because we're not
sampling quickly enough, our perception does not match the
reality of the situation.
Figure 2.9b. Suns Position Sampled Every 22.5 Hours
Low-pass Filters
We've seen an example of the first type of filter, the low-pass filter, which passes low-
frequency components and blocks high-frequency signal components. An idealized
example of a low-pass filter is shown in Figure 2.10, in which the passband, the
36 Chapter 2
frequency range of the signal components that are passed, is 1500 Hz wide. Note
that the bandwidth in this case is also 1500 Hz, since that's the highest frequency
component of the filter.
Ideal Low-pass Filter Spectrum
Frequency
-1500
1500
Figure 2. 1 0. Idealized Low-pass Filter with a Bandwidth of 1500 Hz
Low-pass filters are probably the most widely used type of filter for the simple
reason that, in the real world, we don't deal with signals of infinite bandwidth. At
some point, the frequency content of a signal drops off to insignificance, so one of
the most common approaches to noise reduction is to establish some limit for the
frequency components that are considered to be valid and to cut off any frequen-
cies above that limit. For example, when we are using thermocouples to measure
temperature, the thermocouple voltage can change only so quickly and no faster
because the temperature of the physical body that is being monitored has a finite
rate at which it can change (i.e., the temperature can't change discontinuously). In
practice, this means that the frequency components of the temperature signal have
an upper bound, beyond which there is no significant energy in the signal. If we
design a low-pass filter that will cancel all frequencies higher than the upper bound,
we know that it must be killing only noise since there are no valid temperature signal
components above that cutoff frequency.
High-pass Filters
A complement to the low-pass filter is the high-pass filter, which passes only high-
frequency signal components and blocks the low- frequency ones. In the idealized
high-pass filter of Figure 2.1 1, the passband starts at 1500 Hz and continues to all
higher frequencies. Note that the bandwidth in this case is infinite since all frequen-
cies starting with the passband are included in the filter.
Intuitive Digital Signal Processing 37
Ideal High-pass Filter Spectrum
1
Frequency
-1500 1500
Figure 2.11. Idealized High-pass Filter with Pass band Starting at 1500 Hz
Since we just stated that no real-world signal has infinite bandwidth, why would
we want to use a filter that seems to assume that condition? In some cases, the signal
we're measuring is an inherently AC signal; by the nature of the system anything
below a certain frequency is obviously noise because no valid signal components
exist below that frequency. An example of this might be the auditory response of
the human ear, which is sensitive only to frequencies in the range of 20 Hz to about
20 kHz. Anything below 20 Hz is of no practical value and can be treated as
noise.
Bandpass Filters
A bandpass filter is essentially the combination of a high-pass filter and a low-pass
filter in which the passband of the high-pass filter starts at a lower frequency than the
bandwidth of the low-pass filter, as shown in Figure 2. 12. Here we see that the filter
will pass frequencies between 750 Hz and 1500 Hz while blocking all others.
Bandpass filters are used whenever the designer wants to look at only a particular
frequency range. A very common example of this is the tuner in a radio, in which
the tuner uses a bandpass filter with a very narrow passband to isolate the signal
from an individual radio station. With the tuner, the goal is to pass the signal from
the station of interest as clearly as possible while simultaneously attenuating the
signals of all other stations (presumably at lower or higher frequencies) to the point
where they are inaudible.
Bandpass filters are also commonly used to look at the strength of the signal
in certain passbands of interest. DTMF detectors use this principle to determine
what key a person has pressed on their touchtone phone. In a DTMF system, each
38 Chapter 2
Ideal Bandpass Filter Spectrum
1
Frequency
-1500 -750
750 1 500
Figure 2. 12. Idealized Bandpass Filter
key is represented by a combination of two and only two frequencies that have no
common harmonics. These two frequencies always have one component from a
group of four low- frequency values and a second component from a group of four
high-frequency values, as is shown in Table 2.1.
1209 Hz
1336 Hz
1477 Hz
1633 Hz
697 Hz
1
2
3
A
770 Hz
4
5
6
B
852 Hz
7
8
9
C
941 Hz
*
#
D
Table 2.1. DTMF Tone Combinations
Basically to be a valid DTMF tone, each of the two frequency components needs
to be within about 1.5% of their nominal value, and the difference in signal strength
between the two components (known as "twist") must be less than 3 dB. Using a
bandpass filter for each of the eight frequency components plus one for the overall
signal bandwidth, a detector can examine the outputs of each filter to determine
that only two frequency components are active at any given time, that the two com-
ponents are a valid combination (one from the low-frequency group and one from
the high-frequency group), and that their relative strength is acceptable.
Intuitive Digital Signal Processing 39
Bandstop Filters
The bandstop, or notch, filter can be viewed as the complement to the bandpass filter
in much the same way that the high-pass filter is the complement of the low-pass
filter. Whereas bandpass filters allow only a relatively narrow band of frequencies to
pass, bandstop filters sharply attenuate a narrow band of frequencies and leave the
rest relatively untouched. Figure 2.13 shows an example of a bandstop filters.
Ideal Bandpass Filter Spectrum
Frequency
-1500 -750
Figure 2. 13. Idealized Bandstop Filter
750 1 500
By far the greatest application of bandstop filters is in the reduction of powerline
noise centered around 50 Hz or 60 Hz (depending on location). In many applica-
tions, the 50-Hz or 60-Hz power signal will couple into the sensing circuitry and,
unfortunately, the power signal's frequency often is in the midst of the frequency
spectrum for the signal of interest. A simple low-pass or high-pass filter that would
exclude all frequencies above or below the power frequency would attenuate the
desired signal too much in such cases, so designers try to remove only the frequency
components right around that of the power.
Digital Filter Implementations
To this point, our exploration of filters has been strictly along conceptual lines; we
turn now to the actual mathematical implementation of these filters. In general,
digital filters are created by applying weighting factors to one or more values of the
sampled data and then summing the weighted values. For instance, if we have a
sampled input signal x i for i = 0, 1, ..., N— 1, we can generate a filtered output y i
that is given by:
y : — CLr\iK a CL i J\ i
+ ^N-\ X N-\
Equation 2.3
40 Chapter 2
where the a i terms are constant weighting values that are applied to the correspond-
ing x i sampled input signal value. An example of a low-pass filter is an averaging
filter, whose output is simply the average of a given number of samples. This
smooths out the signal because noise is averaged over the entire group of samples.
If we choose to average four samples to get our filtered output, the corresponding
equation would be:
y i = V4x + l A x x + X A x 2 + X A x 3
Equation 2.4
By adjusting the weights of the individual taps of the filter (the sampled data
values), we can adjust the filter's response. To make things easier for designers, a
number of companies make digital filter design and analysis software, and free ver-
sions are available on the Internet as well. In our designs, we will use Microchip's
dsPIC Filter Design™ software to create and analyze the digital filters we need.
The preceding example illustrates what is known as a finite impulse response or FIR
filter structure. Filters constructed using this approach always have a fixed number
of taps, and thus their output response depends only upon a limited number of
input samples. If we pass the impulse signal shown in Figure 2.14 through a filter
of length TV taps, we know that the filter's output to the input will die out after TV
samples, since all subsequent input values will be zero.
Unit Impulse Signal
o
o
8
Figure 2. 14. Unit Impulse Signal
Intuitive Digital Signal Processing 41
Another filter structure is the infinite impulse response or IIR filter. IIR filters use
both weighted input signal samples and weighted output signal samples to create
the final output signal:
Ji = Vm + tyi-i + • • • + KiS>+-k-\ + a x + ... + a N _ x x N _ x Equation 2.5
where the b i terms are constant weighting terms that are applied to the correspond-
ing Ji-x ^rms.
At first glance, it would appear that we've made the filter much more complex,
but that's not necessarily the case. Looking at the four-tap averaging filter that we
examined for the FIR filter, we could implement the same function as:
y. = y._ Y + 14 x — l A x 4 Equation 2.6
While reducing the computational requirements by a single tap may not seem
particularly important, more complicated filters can see a significant reduction
in computational and memory requirements using an IIR implementation. This
reduction comes at a cost, however; unlike FIR filters, IIR filters can theoretically
respond to inputs forever (hence the name of the structure), which may not be at
all desirable. Designers also have to be careful to ensure that errors don't accumulate
or else performance can degrade to the point where the filter is unusable.
Median Filters
All of the filters that we've discussed so far are based on simple mathematical equa-
tions, so their behavior is easily analyzed using well-known and well-understood
techniques. These filters tend to work best with noise that is contained to specific
spectra, which is often an appropriate design model. Sometimes, however, systems
are susceptible to what is called shot or burst noise, in which the measured signal has
bursts of noise rather than a continuous noise signal. To counteract this, systems
may employ another form of filtering known as median filtering that is somewhat
more heuristic but does an excellent job of reducing shot noise.
In a median filter, the signal is sampled as in the other forms of filtering, but
rather than performing a simple mathematical operation on the samples, the samples
are ordered highest to lowest (or vice versa, it doesn't really matter which), and then
the middle or median sample is selected. If the length of the median filter is greater
than the length of the noise burst, the noisy signals should be completely eliminated.
An example of a length-7 median filter and its effect upon a signal corrupted with
shot noise whose burst is a maximum of three samples is shown in Figures 2.15a
through 2.15d.
42 Chapter 2
Sample Signal without Noise
14 ■
12 ■
1 n -
a.
I u ■
f- A -A.
♦ ♦
■A- ^
o ■
6 ■
4 ■
2 ■
■
4
►
♦
' 1
8
10
12
14
Figure 2.15a. Sample "True" Signal
Sample Shot Noise with Burst Length of 3
14 ■
12 ■
10 ■
8 ■
6 ■
8
10
12
14
Figure 2. 15b. Sample Shot Noise with a Burst Length of Three Samples
Intuitive Digital Signal Processing 43
Sample Signal with Noise
1 A -
I 4 1
♦
12 ■
10 ■
fi -
i
►
o ■
r ^
4
►
♦
6 ■
4 ■
2 ■
■
8
10
12
14
Figure 2. 15c. Measured "True" Signal with Shot Noise
Signal Filtered with Length-7 Median Filter
14-
12-
10-
4
► 4
>.
► 4
► <
► 4
►
k ^
o ■
6 -
4 -
2 ■
■
' 1
4
►
i
p v
6
8
10
Figure 2. 15d. Resulting Signal after Processing with Length-7 Median Filter
12
14
44 Chapter 2
2.2
Issues Related to Signal Sampling
We've already touched on one problem that can arise when sampling an analog signal,
namely the problem of aliasing. There are three other issues with signal sampling
to which we now turn our attention: digitization effects, finite register length effects,
and over sampling.
The Effect of Digitization on the Sampled Signal
So far, we've assumed that all of the signals we're measuring are continuous analog
values — i.e., our measurements are completely accurate. Even in the cases in which
we have noise, the underlying assumption is that the measurement itself, for example
the noisy sensor output voltage, is known precisely. In reality, at least for a system that
employs digital signal processing, that's not really true because the measured analog
signals go through a process known as digitization that converts the analog signal to a
corresponding numeric value that can be manipulated mathematically by a processor.
Figure 2.16 shows this process (signal value is sampled at the points shown).
Original Analog Signal
10
Time
Ti
T
T
T.
10
Digi
tized Sij
gnal
R
\J
n
Time
Ti
T.
T
T.
Figure 2.16. Signal Digitization Process Showing Four Successive Samples
Intuitive Digital Signal Processing 45
The issue that we face with digitization is that within any processing unit we
have only a finite number of bits with which to represent the measured signal. For
instance, let's assume that we want to sample a signal that varies between OV and
5 V. If we try to represent the measurement with one bit, we'll have exactly two pos-
sible values (0 and 1) that we can use. Designating the measured signal voltage as
V s , we might choose to map the lower half of the signal range (0 < V^ < 2.5 V) to
and to map the upper half (2.5V < V s < 5V) to 1. Unfortunately, that's pretty poor
resolution! While we can obviously improve the resolution significantly by using
more bits to represent our numeric values, we will always map a range of input
values to a particular output value, which means that almost all measured signal
values within that range will be in error (the lone exception being the signal value
that corresponds exactly to the numeric value).
This digitization error can be viewed as a noise signal that is superimposed on
the true value of the measured signal as shown in Figures 2.17 and Figures 2.18.
Note that, depending upon whether we perform the digitization by rounding the
measured value (as in Figure 2. 17) or by truncating the measured value (as in Figure
2. 1 8), we will essentially have either a triangular noise signal (rounding) or a sawtooth
noise signal (truncation). Although we can never completely eliminate the issue, we
can reduce its significance by ensuring that we use a relatively large number of bits
(say 16 to 32, depending on the application) to represent the numeric values in our
algorithms. For instance, if we use 16-bit values, we can represent our signals with an
Error When Digitized
Measurement is Rounded
Error When Digitized
Measurement is Truncated
Digitized value
V
A
Analog value
k
i
-+/
Analog value
<-
uiyiiizeu
\/ali io
^
^
^
w
/
T
/
i
When the digitized signal is rounded, the
error is evenly distributed about the "true"
analog value, with a maximum absolute
error of V2 of a single digitization interval
Figure 2. 17. Digitization Error
Introduced by Rounding
When the digitized signal is truncated, the
error has the same stairstep effect, but its
absolute value is now between and a
single digitization level
Figure 2. 18. Digitization Error
Introduced by Truncation
46 Chapter 2
accuracy of 0.001 5 % (assuming no other sources of digitization noise); using 32-bit
values, that resolution improves to 2.3 x 10" 8 % (since there are 2 32 discrete levels).
Finite Register Length Effects
Closely related to digitization effects, which deal with the inaccuracy introduced by
having a finite number of values available to represent a continuous signal, finite
register length effects refer to the issues caused by performing repeated mathematical
operations on values that are represented by a finite number of bits. The problem
is that, because we have a limited number of bits with which to work, repeated
mathematical operations can cause the accumulator in the processor to overflow. A
simple example will illustrate the effect.
Suppose our application digitizes the input signal into a 16-bit value (0-FFFFh)
and further suppose that we're using a processor with a 1 6-bit accumulator. If we try
to average two samples that are at % of the digitization range (BFFFh), we would
get a value of BFFFh if we had infinite precision in the accumulator (Vi (BFFFh +
BFFFh) = BFFFh). However, if we add the two samples together in a 16-bit accu-
mulator, the sum is not 17FFEh but 7FFEh since the most significant bit would be
truncated (we don't have space in the accumulator for it) . If we then take one-half
of the sum, the average becomes 3FFFh, not the BFFFh we want.
Although we can use larger accumulators (i.e., accumulators with more bits), the
problem is inherent to the system and is exacerbated when multiplication opera-
tions are included. By choosing appropriate ways to represent the numeric values
internally and by carefully handling cases of overflow and underflow, designers can
mitigate the effects of having finite register lengths, but the issue must always be
addressed to avoid catastrophic system failures. We'll see how the dsPIC processor
handles these issues in the next chapter.
Oversampling
As mentioned previously, designers have to ensure that systems that use DSP sample
the input signals faster than the Nyquist rate (twice the highest frequency in the input
signal) to avoid aliasing. In reality, input signals should be sampled at least four to
five times the highest frequency content in the input signal to account for the dif-
ferences between real-world A/D performance and the ideal. Doing so spreads the
sampled spectrums further apart, minimizing bleed-over from one to the next.
Another issue with any filter is the delay between the time the input signal enters
the filter and the time the filtered version leaves the filter, and this is true for digital
as well as analog filters. Generally, the more heavily filtered the input signal, the
Intuitive Digital Signal Processing 47
greater the delay is through the system. If the delay becomes excessive (something
that's application dependent), the filtered output can be worthless since it arrives
too late to be of use by the rest of the system.
Over sampling, the practice of sampling the signal much faster than strictly nec-
essary, can be employed to allow strong filtering of signals without introducing an
excessive delay through the system. The oversampled signal can be heavily filtered,
but since the delay is relative and the sampling rate is much higher than necessary,
the filtered signal is available for use by other system components in a timely man-
ner. The downside of this approach is that it requires greater processing power to
handle the higher data rate, which generally adds to the cost of the system and its
power consumption.
2.3 How to Analyze a Sensor Signal Application
When analyzing a specific sensor signal-processing application, designers need to
understand the following aspects of the system:
1 . the physical property to be measured,
2. the relationship between the physical property being measured and the cor-
responding parameter value to be reported,
3. the expected frequency spectrum of the signal of interest and of any noise
sources in the environment,
4. the physical characteristics of the operating environment,
5 . any error conditions that may arise and the proper technique for handling them,
6. calibration requirements,
7. user and/or system interface requirements, and
8. maintenance requirements.
Often, the natures of the physical parameter being measured and of the operating
environment will help guide the designer in the selection of appropriate signal-pro-
cessing capabilities to include in the sensor system. For instance, if one is measuring
the temperature of a large metallic mass heated by a relatively small heating element,
it's safe to assume that the frequency content of the signal of interest is minimal
since the temperature can change only gradually. This means that the sensor can
employ heavy filtering of the input to reduce noise. In contrast, a temperature sen-
sor monitoring a small device being heated by a laser must be capable of reacting
to intense changes in temperature that can occur very quickly. In such a situation,
48 Chapter 2
noise filtering must be lighter and other processing may be required to address noise
that gets through the initial filters.
Its also critical to understand the relationship between the physical property being
measured and the corresponding parameter being reported to the user or to the rest
of the system. Does the reported parameter vary linearly with the physical property
(as is the case with RTD temperature sensors), or does it have a nonlinear relation-
ship (as do many thermocouples) ? If the relationship is nonlinear, is it possible to
segment the relationship into piecewise linear regions to simplify computation? A
poor or incorrect understanding of the relationship between physical property and
reported parameter can render a sensor system useless.
Finally, designers must always consider that sensor systems are going into the
real world, where problems are guaranteed to arise at the worst times. The system
must be designed to detect common errors, and the more robust its error detection
and handling scheme, the better. The loss of a sensor on the production floor may
stop production for an entire line, so any features that allow quick troubleshooting
and easy repair are greatly appreciated by end users. Of even more importance than
maintenance, however, is the ability of the sensor system to detect dangerous condi-
tions that may lead to unsafe operation unless corrected. Sensors that operate in a
fail-safe environment must be designed with rigorous attention to fault detection,
reporting, and correction.
2.4 A General Sensor Signal-processing
Framework
We're now ready to set up a general sensor signal-processing framework that we'll
use in each of our in-depth applications in Chapters 4—7. Like all good designs,
the framework is deceptively simple; the key is to implement it reliably so that it
performs all of its required tasks accurately, on time, every time. The framework is
shown in Figure 2.19.
The framework must be constructed as a hard real-time system; i.e., its response
to system inputs and events must be deterministic (occur within a fixed time) and
all processing for a given input or event must be finished before the next input or
event occurs, at least for the critical processing sections. Less critical sections, such
as the communication protocol handler, are important, but they can occur in soft
real-time; they must be capable of processing all inputs or events eventually, but
they can queue up those inputs or events for processing at a time that's convenient
for the application.
Intuitive Digital Signal Processing 49
Initialize System
Hardware and
Software
I
Start Sensor Signal
Sampling
Sample Set
Ready?
Yes
1
Filter Sample Set
I
Analyze Filtered Data
Check for System
Error Conditions
No
Yes
Data or Errors
to Report?
1
Read Pending Rx Data
from Communication
Port
I
Parse Received Data
Received
Complete
.Command?
Yes
Process Command
I
Send Response
I
Yes
No
1
Format Report
Message
I
Transmit Report
Message
Figure 2. 19. General Sensor Signal-processing Framework
50 Chapter 2
Signal Conditioning and Acquisition
The signal conditioning and acquisition section is responsible for performing any
required conditioning of the analog input signal to limit the frequency spectrum to a
band that can be successfully processed, to amplify the signal level to an appropriate
range for digitization, and to digitize the resulting analog input signal. The output
of this section is a stream of sampled data that can then be processed numerically
by the rest of the system.
Pre-analysis Filtering
Once the raw physical property signal has been sampled, it's often necessary to apply
application-specific filtering to the signal to remove unwanted noise or to some-
how shape the signal into a more useful form. The filtering is typically performed
immediately after acquisition so that processing algorithms later in the signal chain
are able to use relatively clean data, hopefully yielding better results.
Signal Linearization
Sometimes the parameter of interest does not vary linearly with the physical property
being measured. A common example is a thermocouple signal, which has a complex
polynomial relationship between its voltage and the corresponding temperature.
In such cases, the signal often needs to be linearized so that it can be dealt with
more easily by the parameter analysis section. The specific linearization technique
employed will vary by the type of property being measured.
Parameter Analysis
The parameter analysis is also highly application-specific. Although limited only by
the designer's imagination, some typical operations are parameter transformation
(in which the measured signal is converted to the desired corresponding parameter
value mathematically), frequency analysis, and limit comparison. Frequently, this is
the most complex aspect of the sensor system and the area in which the most value
can be added to the product.
Post-analysis Filtering
Once a parameter value has been computed, it's not uncommon to filter those
values to smooth the data for use by other components in the system. As with the
pre-analysis filtering, the particular type of filter employed is application-specific.
Error Detection and Handling
While the parameter analysis section is generally where the most unique value is
added to the sensor system, the error detection and handling section can make or
Intuitive Digital Signal Processing 51
break the viability of the system. The ability to detect and to recover from errors
can separate a product from its competition, particularly in situations in which the
penalty for failure can be catastrophic. Simple error detection might include checking
for the presence of the sensor element and verifying that extracted parameter values
are in a reasonable range. More advanced error detection might include diagnostics
to alert the user before an actual failure occurs.
Communication
The final element in the framework is the communication section. It is this section
that reports all of the information gathered by an intelligent sensor and that allows
the user to configure it for operation, so it is absolutely critical that this interface be
robust and reliable. A wide variety of communication interfaces are available, from
RS-232 to Control Area Network (CAN) to Ethernet to wireless, though not all
systems support all interfaces. The designer must select an interface that provides the
easiest integration of the product with other elements of the system while staying
within the cost and reliability constraints necessary for a particular application.
2.5 Summary
In this chapter, we've introduced the basic concepts of digital signal processing on
a conceptual level. The reader should recognize that a thorough knowledge of DSP
is invaluable to the development of robust sensor systems, and this treatment has
been meant to instill an intuitive, not exhaustive, understanding. Nevertheless, with
this understanding we have been able to develop a general framework for the digital
analysis and reporting of sensor information, one that will be used in subsequent
chapters to design sensor systems for specific applications.
52 Chapter 2
Endnotes
1 . Two outstanding books on DSP are Digital Signal Processing: A Practical
Guide for Engineers and Scientists, by Steven Smith and Understanding Digital
Signal Processing, 2 nd edition, by Richard Lyons.
2. Webster's II New Riverside Dictionary, 1984, Houghton Mifflin Company.
3. For our purposes, an analog signal is a continuous-time signal, i.e., one that
is not sampled.
4. In this case, linear refers not to a straight-line function but rather to a func-
tion that obeys the principle of superposition. Mathematically, if the function
is a transformation H[], and y (t) represents the response of the function to
the input x (t) while y x (i) is the response of the function to the input x Y (t),
then H [] is linear if and only if
H[ax (t) + bx x (i)\ = aH[x (t)] + bHlx^t)] = ay (t) + by x {t).
5 The plural of spectrum is spectra, although you may also see the term written
as spectrums.
Underneath the Hood of the dsPIC DSC
Success is the sum of detail. It might perhaps be pleasing to imagine ones self beyond
detail and engaged only in great things, but. . . if one attends only to great things and
lets the little things pass, the great things become little — that is, the business shrinks.
— Henry Firestone
When one goes on a trip, the choice of transportation depends primarily on the
purpose of the excursion and what's required to accomplish that purpose. While
theoretically one could use a sports car to deliver thousands of computers to a Wal-
Mart distribution center, it would be far more efficient to use a tractor-trailer to
accomplish the task. The same holds true when it comes to implementing intelligent
sensors; we're far more likely to achieve the required performance if we use a hardware
platform that's specifically designed to support the tasks that we need to accomplish.
Such a platform must offer deterministic 1 acquisition, filtering, and analysis of the
signals being monitored as well as reliably handling all communications with the
outside world. In many applications, the system is required to do this for multiple
signals and possibly several communication channels, further increasing the needed
platform processing performance.
Fortunately, a new class of processor known as the digital signal controller or DSC
has been developed recently that marries the powerful mathematical processing per-
formance of a pure digital signal processor with the highly deterministic behavior
of standard microcontrollers. One such DSC is the dsPIC® DSC from Microchip,
which integrates a tremendous amount of functionality into a single chip, allowing
designers to create robust sensing and control solutions in a very small package. We'll
use the dsPIC DSC in subsequent chapters to craft solutions to a variety of common
intelligent-sensing applications, but first we'll examine the resources available to users
of the chip. Throughout the exploration, the goal is twofold: to learn what's available
and to understand why the dsPIC designers made the implementation choices that
they did so that we can optimize our system to best use the chip's resources.
The dsPIC DSC can be viewed in a number of different ways, but three
particularly useful perspectives are an examination of the chip's data-processing
architecture, a study of the mathematical representations and operations that the
chip supports, and an analysis of the various on-chip peripheral components. A
53
54 Chapter 3
thorough understanding of these three subjects will serve as a solid foundation for
creating meaningful systems using the chip.
It's somewhat incorrect to talk about "the" dsPIC chip, since the dsPIC DSC
is actually two related families of chips with a variety of configurations that allow
the designer to select the combination of peripherals that best suits the particular
application. To ground the discussion in the real world, therefore, we will focus
on one specific chip, the dsPIC30F60l4A, which has virtually all of the available
peripherals. Although we'll go into detail on the important aspects of the chip, there
are literally thousands of pages of documentation on it (the Microchip Programmer's
Reference Manual alone is over 350 pages), so we are in a sense only scratching the
surface. By necessity, all of what we'll look at here can be found in the standard
Microchip documentation; however, the information is not always easy to find for
those unfamiliar with the Microchip approach to documentation (and sometimes
not even for those of us who are) . The value of this chapter is not that it reveals new
information (it doesn't) but rather that it organizes the relevant data in an easily
assimilated format. With this knowledge, we will be in a position to use the chip
wisely and will have a solid base from which to delve more deeply into the chip's
features when and as we need to do so.
In the discussions that follow, we will occasionally get a cold dash of reality
in the form of deviations from what the dsPIC DSC is supposed to do and what
the silicon as implemented actually does. These deviations, known as errata 2 , can
drive a developer to levels of frustration usually reserved for the damned, because
they cause the chip to behave in ways that differ from the documentation. From a
designer's perspective there are two types of errata: those with work-arounds (that's
the technical term) and those without. Errata that have work-arounds (coding or
hardware design techniques that alleviate the problem) are inconvenient but not
fatal; those that don't have work-arounds, particularly in an area required by an
application, can cause the project to be significantly delayed, to be more expensive,
or in the worst case, to fail.
That being the case, the smart designer always checks for any errata that are
posted for the specific chip that is being used or for the family as a whole. Individual
semiconductor companies handle the distribution of errata information differently,
but Microchip is generally pretty good about assembling all known problems in
errata sheets that accompany the corresponding part's data sheet or programming
reference guide. These errata are posted on their website at www.microchip.com
along with the data sheets. By checking for any errata before performing a design
and during the debugging phase, the developer can save herself, her company, and
her customers much frustration, delay, and expense. While it's always a good idea to
assume, at least initially, that any problems lie in the developer's code or hardware
Underneath the Hood of the dsPIC DSC 55
design, its also wise to check the errata sheet or with the factory if one has worked
diligently on a problem and it appears that the chip simply isn't acting correctly.
You might just be correct!
3.1 The dsPIC DSC's Data Processing Architecture
The dsPIC family of products is designed specifically for the high-speed processing of
mathematically intensive operations, with dedicated hardware elements that handle
time-intensive processes with minimal loading of the core processor. But just as the
components of a mechanical engine must work together in a prescribed manner to
generate power, so too must the operation of the individual elements of the dsPIC
DSC be coordinated, or the chip's performance will fall far short of its capabilities.
To create the necessary harmony, though, the designer must thoroughly understand
the architecture of the chip and the various elements available in it.
The dsPIC DSC Memory
An understanding of the dsPIC DSC begins with its memory architecture, since it is
one of those elements specifically designed to address the data- throughput require-
ments of a digital signal processing system. The dsPIC DSC employs a modified
Harvard architecture that has separate program memory and data memory busses,
allowing the processor to simultaneously fetch both an instruction and the data
upon which that instruction will operate.
In a pure Harvard architecture, these two busses are completely separate, with
no way to pass data between them. Although an entirely logical approach, the pure
Harvard architecture is inadequate for the needs of many digital signal processing
applications because it means that only a single data value can be retrieved in one
cycle. Frequently, what's really required are two data values, the sampled data and a
coefficient by which it will be multiplied, and in the pure Harvard architecture this
requires two separate instruction cycles. To surmount this constraint, the modified
Harvard architecture actually supports three busses: one to fetch the instructions
(the program memory bus) and two to fetch associated data values (often referred
to in the literature as the X- and the Y-memory busses). This allows true single-
cycle operation, effectively doubling system throughput when compared to a pure
Harvard architecture running at the same speed. Figures 3. la and 3. lb illustrate the
difference between a pure Harvard memory architecture and a modified Harvard
architecture.
As we mentioned in the chapter's introduction, digital signal controllers marry
some of the mathematical processing power of a true DSP with the deterministic
behavior of a microcontroller, and this marriage is reflected in the dsPIC DSC's
use of slightly different memory models when executing mathematically intensive
56 Chapter 3
Pure Harvard Architecture
Instruction
Instruction Address
Data
Data Address
Figure 3. la. Pure Harvard Architecture
Modified Harvard Architecture
Program
Memory
K
Processor
Data
Memory
^ Y-Memory Data
Instruction y
Y-Memory Address y
y X-Memory Data
y Instruction Address
X-Memory Address y
Figure 3.1b. Modified Harvard Architecture
instructions (known as multiply -accumulate or MAC class instructions) and when
executing all other types of instructions (sometimes referred to as microcontroller
class instructions). By doing so, the dsPIC DSC is able to employ the memory struc-
ture best suited to a particular type of instruction; those that require multiple data
sources for the mathematical engine gain the performance advantage of having two
data busses, while the instructions that don't have that need can view the processor as
having a single unified data space. The discussion at the end of Section 3. 1 on Address-
ing Modes and the Address Generation Units describes the hardware components used
to access memory using the two structures.
The dsPIC DSC does lack one aspect commonly found in pure DSPs and other
high-performance microprocessors: a multistage instruction pipeline. The purpose
of an instruction pipeline is to maintain an internal queue of commands to the
processor that can be pre-decoded to speed execution. While this approach can be
and is applied successfully in a number of different applications in which the data
is processed continually as a constant stream without interruption, pipelining can
actually hurt processor throughput when the system must change its instruction-
processing flow frequently (as occurs with interrupt-driven systems). When the
Underneath the Hood of the dsPIC DSC 57
processing sequence changes significantly (for instance, when the processor has to
branch to a location outside of the pipeline), the pipeline has to be emptied of its
existing contents and loaded with the new, correct instructions before it can continue
execution. Resorting to a transportation analogy again, its similar to driving a car
on the highway; as long as one stays on the highway and goes the speed limit, one
can cover a lot of ground quickly. If the driver has to constantly exit and reenter the
highway, it takes much longer to travel the same distance.
Although the dsPIC DSC lacks a multistage instruction pipeline, it does utilize
a single-stage instruction prefetch mechanism that reads and partially decodes
instructions one cycle before they are to be executed. This allows most instructions
to execute in a single cycle while significantly enhancing the deterministic timing
characteristics of the system, because it is much faster to reload should the anticipated
instruction not be the one to execute.
Data Space Memory Map
Data memory in the dsPIC device consists of three broad classes of memory: Special
Function Registers, static RAM (SRAM), and program memory that is mapped to
the data memory space.
Special Function Registers
The dsPIC DSC employs memory-mapped registers to configure, control, and moni-
tor various aspects of the device's operation. Known as Special Function Registers,
or SFRs, these registers reside in the lower 2 KB of the data space memory map.
Unlike standard data space memory locations that are used for general storage, the
data in the SFRs are bit-mapped, so that writing to or even reading from certain
locations will cause the DSC to take a particular action.
For example, as we'll see later, transmitting a byte of data through the chip's serial
port requires that the application configure the serial port's operating parameters by
writing the appropriate data to the serial port's SFRs in a specific sequence. Similarly,
the application can check whether new data has been received by querying the serial
port's Status Register, one of the peripheral's SFRs.
The key point of dealing with SFRs is that one must be very careful when
accessing the memory location because reading from or writing to any of the SFRs
will affect the operation of the dsPIC device hardware and may have unintended
consequences if performed improperly.
Static RAM (SRAM)
In the dsPIC30F60l4A, the static RAM section extends from 0x0800 to 0x27FF,
for a total of 8 KB of random access memory. Unlike SFRs, reading and writing
to this memory section does not affect any aspect of the dsPIC chip's operation
58 Chapter 3
other than the contents of the data stored in a particular location. Applications
use the SRAM section to store data that will change during the execution of the
application, for instance, variables used for filtering or buffers that hold received
communication data.
Under certain conditions that we'll discuss later, the SRAM can be split into two
independent sections, an X-data section and a Y-data section, for improved data
throughput. The starting and ending addresses of these two sections are fixed in
hardware for each dsPIC device, with the X-data section encompassing the memory
from 0x0800 to 0xl7FF and the Y-data section running from 0x1800 to 0x27FF
in the dsPIC30F60l4A chip.
Program Space Memory Mapped as Data Space Memory
In some algorithms, particularly those used for digital signal processing, it's often
necessary to multiply fixed coefficients by variable data. Since the coefficient data
is not changing, it would save precious SRAM space if the fixed coefficient could be
stored in program memory but still be accessible to the data processing hardware.
Conveniently, the dsPIC architecture supports this feature, which will be described
in greater detail in the Program Memory Space section.
Program Space Memory Map
Because the memory configurations for devices in the dsPIC family vary according
to the specific resources available on the individual device, the designer has to refer
to the corresponding data sheet for the chip's exact memory map. The memory map
described here applies to the dsPIC30F60l4, although most aspects of the map apply
to the entire family with minor differences in specific memory address locations.
As noted previously, the dsPIC DSC supports both a program address space and
a data address space, with the data space being split into an X- and a Y-data space for
certain instructions. Program space memory consists of up to 4M of 24-bit instruc-
tion words, though not all of this address space is available to the user. The program
memory itself is divided into the User Memory space (000000H-7FFFFEH) and
the Configuration Memory space (800000H-FFFFFEH) as shown in Figure 3.2.
In operation, the application may access only the User Memory space except
when using the Table Read (TBLRD) and Table Write (TBLWT) instructions to
read and write the Device ID, the User ID, and certain device configuration bits
found in the Configuration Memory. The Configuration Memory space is primarily
reserved for use by Microchip for testing purposes and to store certain useful device
identification information. To maintain compatibility with the data space address-
ing, which will be discussed shortly, the program space addresses are incremented
by two between successive program words.
Underneath the Hood of the dsPIC DSC 59
Program Memory Space Map
For dsPIC 30F601 2A/601 4A
i
k
Reset - GOTO Instruction
000000H
Reset -Target Address
000002H
Interrupt Vector Table
00007EH
Reserved
000080H
Reserved
000082H
O
CO
000084H
Q.
CO
Alternate Vector Table
>>
0000FEH
O
E
0001 00H
User Flash
CO
Program Memory
(48K instructions )
D
017FFEH
018000H
Reserved
(Read 0)
1
h
7FEFFEH
i
Data EEPROM
7FF000H
(4 Kbytes )
7FFFFEH
Reserved
800000H
8005BEH
UNITID (32 instructions )
8005C0H
8005FEH
03
o
800600H
CO
Memory
Reserved
F7FFFEH
o
2
Device Configuration Registers
F80000H
F8000EH
D)
F80010H
O
o
Reserved
FEFFFEH
1
^
DEVID(2)
FFOOOOH
FFFFFEH
Figure 3.2. dsPIC 30F6014A Program Space Memory Map
60 Chapter 3
The base of memory (address 0) holds a GOTO instruction followed by the
address of the application's startup code entry point (at address 2). This two-word
sequence is executed whenever the processor is reset, and it basically tells the pro-
cessor to jump to the beginning of the startup code to launch the application. The
Interrupt Vector Table containing the addresses of the routines that service the
interrupt conditions comes next and resides in the space from address 4 to address
7EH. Following two reserved instruction words at 80H and 82H, the memory
map continues with the Alternate Vector Table from 84H-FEH, the use of which
is described in Section 3.2, Interrupt Structure.
The block of program memory from 100H-17FFEH holds the User Flash
Program Memory, which supports up to 48K instructions (144 KB). This is fol-
lowed by a large section of reserved memory (18000H-7FEFFEH) which is read as
all 0s, and the Data EEPROM occupies the final 4K words at the top of the User
Memory Space.
Accessing Configuration Memory from the User Memory Space
Normally, the application should work exclusively with memory in the User Memory
space; however, as mentioned above, the application program can access certain areas
of the Configuration Memory space in order to retrieve the Unit ID (32 words), the
Device ID (2 words), and to retrieve or set the device configuration registers (16
words). To do this, the application must set bit 7 of the Table Page (TBLPAG) SFR
to 1 and then either read or write the desired address using a Table Read (TBLRD)
instruction (to read the data from the Configuration Memory) or a Table Write
(TBLWT) instruction (to write the data to the Configuration Memory).
Mapping Program Memory to the Data Space
Frequently, DSP applications will store constant data in the nonvolatile program
space memory to free up precious RAM locations in the normal data space. The
dsPIC DSC s modified Harvard architecture supports the ability to use program
memory in this way either by using the TBLRD /TBLWT instructions mentioned
earlier or by mapping a 16 Kword (32 KB) program space page into the upper
half of the data space using the Program Space Visibility Page (PSVPAG) register.
Because the dsPIC DSC s architecture employs 24-bit (3-byte) instruction words but
16-bit (2-byte) data words, the application must account for the difference in byte
alignment, and the methods employed differ based on whether TBLRD /TBLWT
instructions are employed or the Program Space Visibility Page register is used to
remap the memory. Although the description of the mechanics of how the application
uses the two approaches is deferred to Addressing Modes and the Address Generation
Units at the end of Section 3.1, it's important to understand the conditions under
which each is best employed.
Underneath the Hood of the dsPIC DSC 61
If the data being accessed must be both read and written, the application must
use the Table Read/Write method; Program Space Visibility (PSV) permits only
data reads. However, PSV data access is faster than the Table Read/ Write method,
and it is ideally suited for situations in which a constant value is being used to scale
a dynamic value, as is the case when implementing a digital filter or performing
a fast Fourier transform (FFT). Another limitation of PSV access is that it can be
read only from the X-data space, but in practice this is not much of a constraint,
since we can place the dynamic data in the Y-data space for use with the MAC
class of instructions described in the next section. The Table Read/Write method is
particularly useful, indeed required, when accessing locations in the Configuration
Memory Space.
The DSP Engine
The dsPIC DSC incorporates a powerful DSP engine for performing the multiply-
accumulate (MAC) operations that are the foundation of many signal-processing
algorithms. Only certain instructions can make use of the DSP engine, and those
execute with restrictions on the sources of the data they process, but the restric-
tions are minimal and permit the engine to read two operands, perform a MAC
operation on them, and then store them back to memory, usually in a single cycle.
To obtain this type of throughput, the dsPIC s designers incorporated dedicated
hardware, including:
• a 1 7-bit x 1 7-bit fractional/integer multiplier,
• two 40-bit accumulators,
• a 40-stage barrel shifter that can shift up to 16 bits left or right in single
instruction, and
• dual address generation units (AGUs) that can calculate modulo address-
ing (both AGUs) and bit-reversed addressing (one AGU).
Properly employed, these dedicated hardware subsystems significantly reduce the
processing required to implement complex signal-processing algorithms. A block
diagram of the DSP engine components is shown in Figure 3.3. Before discussing
the hardware components, however, we need to examine the way in which numerical
data is represented in the dsPIC DSC.
62 Chapter 3
DSP Engine Block Diagram
40
I
4
+
Carry/Borrow Out
Carry/Borrow In
to
CO
CO
CO
Q
* To/From W Array U
Figure 3.3. dsPIC30F DSP Engine Block Diagram
17-bit
Multiplier/Sealer
Numeric Data Representation
The dsPIC DSC can operate on signed data that uses either a fractional or integer
representation. Signed integer data uses the standard two's complement format, in
which the most significant bit (MSB) is the sign bit and each subsequent bit is a
power of two, as shown in Figure 3.4.
-2 15
2 14
2 13
2 12
2 11
2 w
2 9
2 8
2 7
2 6
2 5
2*
2 2
2 2
2 1
2°
Figure 3.4. 16-bit Signed Two's Complement Integer Representation
An TV-bit two's complement integer can represent values between —2 N ~ l and
2 N ~ l — 1 . A 16-bit two's complement integer number can take on any value between
-32,768 (0x8000) to 32,767 (0x7FFF), while a 32-bit number can range from
-2,147,483,648 (0x80000000) to 2,147,43,647 (0x7FFFFFFF).
Underneath the Hood of the dsPIC DSC 63
When working with two's complement integer data, it's important to make
sure that the sign bit is properly handled when performing addition or subtraction
operations on numbers with different bit widths, or computation errors may occur.
For example, if we were to add the 8-bit two's complement value of —4 (OxFC) to
the 16-bit value of 20 (0x0014) without sign-extending the 8-bit value, we'd get a
result of OxOOFC + 0x0014 = 0x01 10 or 272 decimal, a far cry from the 16 (0x0010)
we expected. If, however, we sign-extend 3 the 8-bit value before the addition, we
get a result of OxFFFC + 0x0014 = 0x10010 or 0x0010 if we maintain our 16-bit
representation length (which would cut off the MSB of the result). The rule for
adding two different-sized two's complement values is to sign-extend the length of
the shorter representation to match the length of the longer representation. Note
that what we're interested in is the length of the representation, not the length of the
specific value we're using. For instance, if we are adding an 8-bit value to a 16-bit
value, we need to sign-extend the 8-bit value to sixteen bits, regardless of the actual
values contained in either the 8-bit or the 16-bit representations.
Although integer data is very fast, it suffers from the tendency for multiplica-
tions to overflow fairly easily, which normally requires that the application include
additional software to check for and to handle the overflow to prevent erroneous
results. Multiplying an M-bit integer by an N-bit integer yields an (N + M)-bit
value. It doesn't take too many multiplications to overflow even a large multiplier.
One way to avoid the overflow problem is to use fractional arithmetic, in which
all values are constrained to the range —1 to +1. In this case, multiplications are
guaranteed to stay within the same range, eliminating the problem of overflow
(at least for the multiplication portion of a mathematical operation). Because this
approach is quite common, the dsPIC DSC can be configured to perform signed
fractional arithmetic operations using the QN format. In the QN format, the data
is represented as a two's complement fraction in which the MSB is defined as the
sign bit and the radix point (the decimal point when using a base-ten system) is
implied to be immediately after the sign bit. The "N" in the QN notation simply
specifies the total number of bits in the number. A Ql 6 number uses 1 6 bits to
represent values, while a Q32 number uses 32 bits. The literature also refers to this
format as l.(N-l) format, with the "(N-l)" term representing the number of bits
used to represent the mantissa (the fractional portion of the number). Using this
notation, a Ql 6 number would be referred to as having a 1 . 1 5 representation, and
a Q32 number would use a 1.31 representation. Figure 3.5 shows an example of a
Q16 or 1.15 fractional representation.
-2°
2 1
2 2
2 3
2 4
2 5
2 6
2 7
2 8
2 9
2 w
2 11
2 12
2 13
2 14
2 15
Figure 3.5. Signed Q16 or 1. 15 Fractional Representation
64 Chapter 3
A signed QN value can represent numbers in the range — 1 to 1 — 2 l ~ N . Q16
numbers, then, can represent values between -1 and 0.999969482421875, while
Q32 numbers can represent values between -1 and (1 - 4.66 x 10" 10 ), essentially
— 1 and 1 for all practical purposes.
As with two's complement integer values, addition or subtraction using QN
fractional numbers requires that the data be properly extended before performing
the operation. In this case, however, the extension is handled by zero-padding to the
right of the LSB in the mantissa of the smaller representation rather than by sign
extending, as is the case for integer arithmetic. For example, to add a Q8 number
to a Ql 6 number, one first pads the right of the Q8 value with 8 additional zero
bits to form the corresponding Q16 value.
Multiplication of an M.N fraction by an R.S fraction produces an (M + R).(N + S)
result. When two 1.15 values are multiplied together, then, the result is a 2.30 number.
This is analogous to the situation for multiplying a decimal fraction with N digits to
the right of the decimal point by a second decimal fraction with S digits to the right
of the decimal point, with the result having N + S digits to the right of the decimal
point. In fractional multiplication, however, the multiplicands are sign-extended prior
to multiplication (i.e., negative values have a "1" prepended to the most significant
bit, positive values have a "0" prepended), and the result is left-shifted by a single bit
position to correctly handle the sign and fractional bit alignments. An example will
illustrate this more concretely.
Example 3. 1:
To correctly multiply —0.25 by 0.25 using Q8 (1. 7) notation y the steps are:
1 . Sign-extend the two values to be multiplied:
-0.25: 1.110 0000b -^ 1 1.110 0000b
0.25: 0.010 0000b -^ 0.010 0000b
2. Multiply the two values together:
1 1.110 0000b
x 0.010 0000b
11 1100 0000 0000b
000 0000 0000 0000b
0000 0000 0000 0000b
0000 0000 0000 0000b
0001 1110 0000 0000b
Underneath the Hood of the dsPIC DSC 65
3. Left-shift the result by 1 position:
0011 1100 0000 0000b
4. Place the implied decimal point prior to the
13 th least significant bit:
001.1 1100 0000 0000b = -0.0625 decimal
Hardware Multiplier
The 17-bit x 17-bit hardware multiplier allows the dsPIC DSC to multiply two
signed 1 6-bit values together using either fractional or integer arithmetic. It should
be noted that, with the exception of multiplication, the operations for integer and
fractional data are identical; the only difference is how they are interpreted. For
example, if two 16-bit two's complement integer values, say 0x2001 and 0x1 7F0
are added together, the result will be 0x37Fl. If the same two signed Q16 values
(0x2001 and 0x1 7F0) are added together, the result is also 0x37Fl. The difference is
that 0x37Fl as a 16-bit twos complement integer represents 14,321 decimal, while
that same value as a signed Q16 number represents approximately 0.437042236.
As noted above, multiplication of signed fractional two's complement numbers
requires the sign-extension of those values by one bit, hence the need for a 1 7-bit x
17-bit hardware multiplier for multiplying two Q16 values. To handle the special
case where two Q16 inputs with a value of 0x8000 (—1) are multiplied together, the
hardware multiplier automatically corrects the resulting value to be 0x7FFFFFFF,
the closest value to + 1 . If the hardware did not handle the error in this way, the
resulting overflow would produce the incorrect value of— 1 x — 1 = 0. Although the
correction introduces a small error, that error is much less significant than allowing
the multiplier to overflow.
Because the DSP engine handles integer and fractional multiplication differently,
the application must specify which numerical notation is being employed. It does so
by configuring the IF bit in the CORCON (Core Configuration) SFR; when the flag
is cleared (set to "0"), multiplications are handled using fractional notation, and when
the flag is set (equal to " 1 "), the multiplier performs standard integer multiplication.
When in fractional mode, the multiplier automatically includes sign-extension and
the requisite left-shift to maintain proper radix point alignment. If the application
performs either a MAC or a MPY instruction (the two DSP multiply instructions)
using fractional data without first clearing the IF flag, the application must explicitly
perform the left shift or the resulting value will be incorrect.
The same multiplier is used for the standard MCU multiply instructions (varia-
tions of the MUL command), which are either 8-bit or 16-bit integer operations
(both signed and unsigned). When both operands are 8 bits, the result is a 16-bit
value, while 16-bit operands produce a 32-bit result.
66 Chapter 3
Dual 40-bit Accumulators
The output of the multiplier is routed to the data accumulator, a subsystem consisting
of a 40-bit adder/sub tractor with sign extension logic and two 40-bit accumulators
(creatively designated as "A" and "B") that can serve as both source and destination for
the accumulation operation. For certain instructions, the ADD (add accumulators)
and LAC (load accumulators) commands, the data can also be scaled by the barrel
shifter before performing the accumulation operation, which can be a convenient
way to normalize the data. The provision for two accumulators is particularly useful
when performing complex number arithmetic, a common DSP requirement.
One might reasonably ask why the data accumulator is 40 bits wide when the output
of the multiplier is a 32-bit value. The answer is that the wider accumulator provides
some additional computational "room" to avoid problems with overflowing the accu-
mulator when performing multiple accumulations, such as might be encountered with a
multitap filter. Recall that the reason we often use fractional arithmetic is to avoid prob-
lems with overflow when multiplying; by limiting the range of input operand values to be
between —1 and + 1 , we're able to ensure that any output result is also between - 1 and + 1 .
Unfortunately, we have no corresponding way to limit the output value of an addition or
subtraction operation; summing two fractional values together always has the potential to
create a result that is outside our -1 to + 1 range. The only way to prevent overflow is to
provide "guard" bits to the left of the radix point, with the more guard bits the better. In
the case of the dsPIC DSC, the chips designers have provided 8 guard bits (the difference
between the size of the 40-bit accumulator and the 32-bit inputs), which allows up to
256 consecutive additions of full-scale values at either end of the input range (i.e., either
adding two — 1 values or two + 1 values) before the data accumulator will overflow. In
practice, depending on the values actually being accumulated, these 8 guard bits may
allow far more operations before overflowing, or the accumulator may never overflow
at all.
Because arithmetic overflow can be a huge problem, the dsPIC DSC offers two
flags per accumulator to allow the application to check for this condition. These
flags, found in the CORCON register, indicate whether either of the two following
conditions has occurred:
1. the accumulator has overflowed beyond bit 39 (indicated by the SA or
SB flag being set), and/or
2. the accumulator has overflowed into the guard bits (indicated by the OA
or OB flag being set).
The dsPIC30F Family Reference manual correctly describes the first of these
conditions as "catastrophic," because when it occurs, the sign bit for the accumulator
is destroyed. The second condition is not too serious, but it does indicate that there
is potential for subsequent accumulations to generate a catastrophic overflow.
Underneath the Hood of the dsPIC DSC 67
Catastrophic overflow can cause very serious problems when it occurs, because
outputs from such an operation will wrap either from positive to negative or from
negative to positive. This represents a mathematical discontinuity, which violates
the first tenet of most digital signal processing (and certainly the DSP we're discuss-
ing in this book), namely that the systems can be modeled mathematically as linear
systems. In most microprocessors, checking for and correcting catastrophic overflow
is difficult, time-consuming, and code-space expensive, but the dsPIC s designers
included special configurable logic that not only detects catastrophic overflows
but allows the data accumulator to handle them gracefully without any additional
software overhead. When configured to do so, the dsPIC DSC will convert what
would normally be a catastrophic overflow into either the most negative or most
positive value (depending on the direction of the overflow), a situation known as
accumulator saturation. In this respect, the dsPIC DSC mimics how an analog mul-
tiplier would handle overflow, saturating the output of the multiplier rather than
wrapping around. The dsPIC DSC's saturation behavior can be tailored to saturate
upon overflow of either its natural (32-bit) or extended (40-bit) range, depending
upon the application.
The dsPIC DSC offers considerable flexibility in the handling of the overflow
detection flags and processes the two types of flags somewhat differently. Both types
of flags (OA/OB and SA/SB) are modified each time that data passes through the
adder/subtractor, but the SA/SB flags can only be cleared by the application (the OA/
OB flags are automatically cleared by hardware when the overflow condition clears).
In addition, the setting of either type of flag can optionally generate an Arithmetic
Warning trap when the corresponding overflow trap enable bit (OVATEN/OVBTEN
for guardbit overflow or COVTE for catastrophic overflow) is set in the Interrupt
Control 1 register (INTCON1). This allows the user to handle such error conditions
immediately, for example by reducing system gain to eliminate the problem.
To further reduce the software overhead required to detect and process overflow
conditions, the dsPIC DSC also has two flags that are the logical OR of either the
OA and OB bits (the OAB flag) or the SA and SB bits (the SAB flag). These two
flags are found in the Status register (SR) and allow the application to quickly check
for overflow in either accumulator, which is helpful when performing complex
arithmetic computations.
40-bit Barrel Shifter
The 40-bit barrel shifter provides a quick (single-cycle) method to right-shift data
up to 15 bits to the right or 16 bits to the left. This feature is particularly helpful
in normalizing data to a specific range or when aligning a serial bit stream from
one of the communication ports. Data is fed into the barrel shifter from the X bus
between bits 1 6 to 3 1 for right-shift operations and between bits to 1 5 for left-
shift operations.
68 Chapter 3
Addressing Modes and the Address Generation Units
One of the key reasons for the dsPIC DSC's high data throughput is its ability to
employ a number of flexible addressing schemes to access and process data efficiently.
Not only does the chip offer numerous addressing modes, it also employs hardware-
based address generation units (AGUs) that can implement overhead-free modulo
and bit-reversed addressing that drastically reduces the software overhead associated
with complex signal-processing algorithms. Prudent use of the AGUs' features and
the various addressing modes can significantly trim the code space and execution
time required to implement such algorithms.
The dsPIC DSC supports four basic data addressing modes, some of which may
be extended by certain instructions:
1 . File Register or Memory Direct
2. Register Direct
3. Register Indirect
4. Immediate Operand
The File Register or Memory Direct addressing mode embeds the 13-bit absolute
memory address within the instruction. Since this mode only permits 13 address
bits, it can access only the first 8 KB of the data space, which is also known as the
"near" data space. Probably the most common usage of this addressing mode is to
access the Special Function Registers (SFRs) located in the lower 2 KB of the data
space. Note that near addressing cannot be used to access the upper 2 KB of the
SRAM section.
Register Direct addressing allows direct access to all of the registers in the W
register array, and the instructions that support this mode specify the operand source
or result destination register as a particular W register (e.g., Wl, W4, etc.). This
mode is particularly useful for three-operand instructions of the form Z = X + Y,
where X, Y, and Z are all W registers and the operation could be addition, subtrac-
tion, or a bit operation. Note that in the case of three-operand instructions, the two
source operands must be different registers, although the destination register may
be any of the registers.
By implementing the Register Indirect addressing mode, the dsPIC designers
made it very easy to support higher-level languages, particularly C, that employ
pointers to data. The hallmark of Register Indirect addressing is that the address
of the data to be accessed is stored in one of the 16-bit W registers. This offers two
significant advantages over the other addressing modes: it permits the application
to access a larger data space (64 KB instead of the 8 KB of File Register or the 32
bytes of Register Direct), and it allows the application to modify at run-time the
address of the data to be accessed.
Underneath the Hood of the dsPIC DSC 69
Of the basic addressing modes, Register Indirect is the most flexible, allowing the
application to increment or decrement the contents of the source operand register
and/or the destination result register as part of the single-cycle instruction execution.
The increment/decrement operation can be performed either prior to retrieving
the addressed data or after retrieving it, which allows the use of a wide variety of
powerful looping constructs. In addition, some instructions also allow the address
register contents to include either a register offset (i.e., combine the address register
contents with the contents of another register to obtain the target address) or a literal
offset (i.e., combine the address register contents with a fixed value to obtain the
target address). These last two variations allow an application to efficiently access
data from fixed tables or from structures.
Finally, Immediate Operand mode embeds the data value in the instruction itself,
with the size of the data that can be used dependent upon the specific instruction.
3.2 Interrupt Structure
Interrupts are asynchronous changes in the flow of instruction execution that are
caused either by an external event (e.g., a hardware signal changing state) or by an
internal condition (the expiration of an internal timer, for example) . Technically,
the dsPIC DSC differentiates between true interrupts, which are generated by an
anticipated event whose processing is a normal part of the application, and traps (or
processor exceptions) that handle erroneous processing conditions that should not
occur in the course of normal operation. In practice, both interrupts and traps are
processed in the same manner, so this discussion will usually lump the two under
the single banner of "interrupts."
The dsPIC DSC supports a total of 45 interrupt sources, four types of traps, and
six conditions that can reset the processor. Because most applications require the use
of only a few of these exception handlers, the dsPIC DSC s interrupts must be enabled
individually, with a Global Interrupt Enable flag that allows the program to quickly
turn off all interrupts with a single operation. When an interrupt event occurs whose
enable flag is set and as well, the Global Interrupt Enable flag is set, the processor will
store the program address from which it is currently executing on the interrupt stack
and retrieve the address of the appropriate interrupt handler function (known as the
interrupt vector) from the corresponding entry in the Interrupt Vector Table (IVT)
located between address 000004H and address 00007FH of the program space. Upon
retrieving the interrupt handler address, the dsPIC DSC jumps to that address and
begins executing code until it encounters a Return from Interrupt Enable (RTFIE)
instruction, at which point it will retrieve the address most recently stored on the
interrupt stack and resume normal processing from that point.
For simplicity, the preceding discussion leaves out a crucial aspect of the dsPIC
DSC's handling of interrupts, namely that the interrupts are prioritized into one of
70 Chapter 3
seven different levels, with level having the lowest priority and level 6 the highest.
This means that the interrupts have a built-in hierarchy, with some interrupt sources
being deemed more important that others. Interrupt sources whose vectors are located
at lower addresses in the IVT are considered to have higher priority, and the priority
order in which the vectors appear is considered to be the vectors' "natural" priority.
Because the dsPIC's designers realized that not all applications will require the same
priority for different interrupts, the priority of individual interrupts can be changed
by the application code at run-time to be either higher or lower.
One of the key aspects of interrupt processing is the amount of time it takes
from the point at which the interrupt condition becomes active and when that
condition is actually acted upon by the processor, a value known as the interrupt
latency. The goal with interrupt latency is two-fold: to minimize the time it takes
to start processing the interrupt and to keep the latency period as steady as possible
so that the processing of individual components in the application can be handled
reliably. In the dsPIC DSC, these twin goals are met superbly, with a fixed latency
of five instruction cycles from the point at which the interrupt request occurs (i.e.,
the time when the interrupt source becomes active) and the point where the inter-
rupt service routine (ISR) actually starts. It's important to note, however, that this
latency assumes that no other interrupts are being processed at the current priority
level or higher; if there are others being serviced at the same or a higher priority level,
the processing for those ISRs will complete before the new interrupt is serviced and
hence the latency can increase well beyond the five-cycle base.
Shadow Registers
The earlier discussion also left out an important performance-enhancement feature
of the dsPIC DSC: the use of shadow registers to provide quick context switching
when interrupts or other forms of exceptions occur. When an interrupt occurs, the
application can store the contents of certain flags in the Status Register as well as the
contents of theTBLPAG, PSVPAG, and W0-W14 registers to the shadow registers
with a call to a single instruction, PUSH.S. Upon completion of an interrupt that
uses the shadow registers, the ISR must call POPS to restore the standard registers
to the contents stored in the shadow registers.
Because the shadow registers are only one level deep, it is critically important that
the application never attempts to make two consecutive calls to PUSH.S or POPS
without an intervening call to its complement or the original register contents will
be lost. This means that ISRs for lower priority interrupts cannot use the shadow
registers if ISRs for higher priority interrupts also use those registers, since the occur-
rence of one of the higher priority interrupts during processing of a lower priority
interrupt would result in the shadow register contents being overwritten.
Underneath the Hood of the dsPIC DSC 71
3.3 The On-chip Peripherals
One of the dsPIC DSCs greatest strengths is the level of system integration that it
brings to sensor applications. Depending on the particular version, a single dsPIC
DSC can incorporate on-board peripheral modules that directly digitize analog input
signals or read digitized data from external A/D converters, that implement multiple
free-running and/or event-based timers, and that support several industry-standard
communication protocols. Since the dsPICs architecture allows the designer to
specify the processing priority of the individual peripherals at run time, they are able
to optimize the chip's operation and throughput for the specific application.
In the following discussions of the various peripheral modules, the intent is to
clarify the information found in the dsPIC data sheets and to establish checklists that
the designer can employ to ensure that each module is used properly. The discussions
also incorporate insights available from other Microchip sources such as tutorials
and application notes, with the goal of creating a coherent body of knowledge out
of the wealth (one might easily say glut) of raw information about the chip.
Data Acquisition Peripherals
In any intelligent sensor system, the "digital" part of the DSP signal chain 4 starts
when the input analog signal is digitized by a device called, imaginatively, an analog-
to-digital converter (also known as an AID or an ADC). The dsPIC DSC supports
a number of different ways to perform signal digitization:
• through an on-board multichannel ADC,
• by using an external audio coder/decoder (codec) whose output is then
read through the dsPICs Data Converter Interface (DCI),
• via an external ADC controlled through either the Serial Peripheral Inter-
face (SPI) port or the Inter-Integrated Circuit (PC) ports.
In this book, we will focus on the first method, the use of the on-board ADC.
Analog-to-Digital Converters
Probably the most common and certainly the most cost-effective method of digitizing
the input signal is the use of the dsPIC DSC s internal ADC. As of this writing, all
dsPIC30F series devices support between 6 and 16 channels of ADC inputs with
either 10-bit or 12-bit resolution, depending upon the particular chip. Devices that
offer 1 0-bit resolution are generally targeted for motor control or video-processing
applications that can tolerate the reduced resolution (only 1024 unique levels vs.
the 4096 levels provided by a 12-bit ADC), while those with 12-bit resolution are
intended to service the general sensor market. The dsPIC30F60l4A, the device that
72 Chapter 3
we'll use in the applications we develop throughout this book, supports 1 6 channels
of 12-bit conversion.
To get a feel for what sort of ramifications these different resolutions might
have in real-world applications, consider the two separate cases of monitoring the
rotational position of a steering wheel in a steer-by-wire system and of measuring
the pressure inside the mold of an injection molding machine. In the case of the
steering wheel, let's assume that we're able to determine the rotational position of
the wheel using the full resolution of the ADC to measure 360° of rotation. Under
those conditions, a 10-bit ADC would allow us to measure the steering wheel's posi-
tion to within approximately one-third of a degree (360° / 2 10 levels = 360° / 1024
= 0.35°/level), while a 12-bit ADC would be able to resolve the rotational position
to within less than a tenth of a degree. Either of these would be perfectly adequate
for most steer-by-wire systems, being well within the limits of human perception
(assuming, of course, that we're using a human driver) .
The situation is not nearly so clear-cut when monitoring a large-ranged signal
such as pressure inside a molding machine, which usually varies between and
perhaps 30,000 psi. 5 In this case, each level in the 10-bit ADC corresponds to just
under 30 psi, while each level in the 12-bit ADC corresponds to just over 7 psi.
That may not seem particularly significant, but if the molder is using the pressure
at a particular point in the mold to open a gate to allow more plastic into the mold,
the difference in resolution can mean the difference between a stable, profitable
molding process with low scrap rates and an unstable, unprofitable process with
unacceptably high scrap rates.
As Richard Fischer of Microchip points out in his excellent webinar on the dsPIC's
ADC module, 6 the ADC performs two major operations every time it converts an
input analog signal to the corresponding digital value. First, the ADC samples the
analog input and stores the analog sample in its sample-and-hold amplifier, a process
known as acquisition. As Richard notes, capturing the analog sample is analogous to
taking a photograph of the analog waveform, with the acquisition time being similar
to the exposure time of a photograph. The application determines how much time
each acquisition is allowed, but it must ensure that the acquisition time is sufficient
to accurately capture the signal, just as the photographer must ensure that the shutter
speed of his camera allows sufficient light to reach the film (or CCD array in this
era of digital cameras) for a good picture.
Once the signal has been captured, the ADC performs the second major opera-
tion: it converts the sampled analog signal into the corresponding numeric digital
value, a process generally referred to as conversion. 7 Figure 3.6 shows the relation-
ship between sampling time (acquisition time), A/D conversion time, and the
complete conversion cycle time. Depending upon how the module is configured,
Underneath the Hood of the dsPIC DSC 73
Total A/D Conversion Time
H
Sample Time
Digitization Time
(also referred to as the A/D
conversion time by Microchip)
t
A/D conversion finished, and result loaded into
the A/D result buffer. A/D interrupt will be
generated if enabled.
S/H amplifier disconnected from the
input signal after storing the input
signal level. Conversion trigger source
starts digitization of the analog signal
level (referred to in the literature as the
A/D conversion).
Sampling starts with the connection
of the S/H amplifier to the analog
input pin.
Figure 3. 6. AID Conversion Timing
the converted digital number can be in one of four different integer or fractional
formats, allowing the application to use the representation that works best with its
particular algorithms.
A dsPIC application can sample data using either spoiled (or manual) approach
in which the code explicitly initiates each sampling operation, or it can perform
auto conversion sampling in which the ADC module is configured initially and then
the hardware repeatedly performs the acquisition and conversion, only interrupting
the processor when the specified number of channels have been converted. In most
applications, interrupt-driven operation is preferred because it ensures that the data
is sampled with temporal stability — i.e., the time between subsequent samples is very
stable. This temporal stability is very important since most DSP algorithms assume
that sampling frequency remains constant; an excess amount of jitter 8 can cause
erroneous results that would not be seen if the sampling periods were more tightly
controlled. Polled operation is usually used either to debug the hardware interface,
when the value being measured can be "spot checked" in a nonsynchronous manner
(for instance, checking the level of the oil in a car in a background "check engine"
operation), or when the desired sampling frequency is too slow to be handled by
the ADC module's hardware.
The dsPIC DSC uses a single successive approximation A/D multiplexed between all
of its input channels to perform the digitization. Depending on the ADC's resolution
and the specific device, the input channels are multiplexed through either one, two,
or four sample-and-hold (S/H) amplifiers before being converted to a digital value,
as shown in Figure 3.7. Only the 10-bit ADCs support multiple S/H amplifiers; the
74 Chapter 3
AV
DD
AV
ss
V
REF+
V
REF-
ANO
AN1
AN2
AN3
AN4
AN5
AN6
AN7
AN8
AN9
AN 10
AN 11
AN 12
AN 13
AN 14
AN 15
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111
12-bit High Speed A/D Block Diagram
■3
>
CHO
DAC
I
12-bit SAR
1
Conversion
Logic
16-word , 12- bit
Dual Port RAM
(DPRAM)
Sample
I
Sample/Sequence
Control
Input
Switches
o
CD
*^
CD
Figure 3.7. dsPIC Analog-to-Digital Conversion Circuitry
12-bit ADCs are limited to a single S/H circuit. At first blush, the ability to use mul-
tiple S/H amplifiers might not seem that important since their outputs still must be
converted by a single conversion circuit, but they do offer an important feature: the
ability to make truly simultaneous samples. Often, this feature is nice to have but not
strictly necessary for a particular design, but in applications where it is required, the
dsPIC DSC s on-board multiple S/H amplifiers are a tremendous advantage.
The internal A/D can sample a maximum of just under 200 Ksps (200,000
samples per second) across the full supply voltage, but that sampling bandwidth
is spread over all of the channels, so each channel can digitize at a maximum of
12,500 sps (200,000 sps / 16 channels = 12,500 sps/channel) when all channels
are used. In practice, of course, this sample rate may have to be reduced to allow
sufficient processing time for any conditioning and analysis algorithms required by
the application. The sampling rate is also dependent upon the supply voltage that
powers the chip; the device is capable of a rate just under 200 Ksps when the chip
operates with a supply voltage between 4.5V and 5.5V. If the chip is run at a lower
voltage, the maximum sampling rate drops to 100 Ksps.
As Figure 3.7 shows, the ADC circuitry offers a great deal of flexibility, but this
flexibility requires significant run- time configuration on the part of the application in
order to function properly. The ADC module employs six 16-bit status and control
Underneath the Hood of the dsPIC DSC 75
registers and an additional 16-word dual port read-only buffer (ADCBUFO through
ADCBUFF) that contains the results of the conversions.
In this discussion, we will attack the configuration issue by sequentially exploring
the tasks we need to accomplish in the order in which they need to be performed
rather than by simply listing which bits do what in each register. This approach will
hopefully give the reader a better understanding of the overall process than might
be obtained with a checklist of register bit assignments, though we'll conclude with
just such a checklist for the sake of completeness.
Before configuring the ADC module, we first need to determine the following
information:
1 . Which I/O port pins are to be analog inputs, which are to be digital inputs,
and which are to be digital outputs?
2. How fast do we need to sample the analog inputs?
3. Do we need to use interleaved sampling, or can we simply generate a
single interrupt after converting all of the signals during a given sampling
period? Does our processing throughput require that we multiplex the results
buffer?
4. In what format to we want the converted data?
Once we've answered those questions, we can proceed to the actual module
configuration.
Step 1 — Signal Path Configuration
Not surprisingly, the first step in configuring the ADC module is the identification
of the specific pins that are to be treated as analog inputs, digital inputs, and digital
outputs. Although it's possible to change this configuration at any point during run-
time, for simplicity this discussion will assume that we're configuring the I/O signal
types and directions only once at the beginning of program execution. Should the
application require that the signal types and/or directions be changed later in the
processing, we can do so by applying the steps discussed here but only after interrupts
have been disabled. It's an extremely bad idea to change either the type or direction
of I/O signals if there's a possibility that code may be executed that assumes that
the signals are configured differently.
Step 1A — Configuring the II O Port Pins
As is standard with Microchip products, the application specifies an I/O port signal's
direction through theTRISx register, where the "x" refers to the specific port (TRISA
for PORTA, TRISB for PORTB, etc.). Bit assignments for the 1 6-bit TRISx registers
correspond one-to-one with the bits in the corresponding 16-bit PORTx register.
To configure a signal as an input (whether digital or analog), the application sets
76 Chapter 3
the corresponding TRISx bit to a "1", or to configure the signal as an output, the
application clears the TRISx bit to a "0". An easy way to remember this convention
is to think of the "0" as standing for "Output" and the "1" as standing for "Input". 9
Figure 3.8 shows the bit mapping for a generic TRISx register.
TRISx Register Control of Port Pin
Signal Direction
Bit
TRISx
Register
o
o
O
Bit
PORTx
Register
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
LO
^f
CO
CM
T-
o
o>
CO
1^
CO
LO
<tf
CO
CNJ
o
X
0)
X
CO
X
en
X
C/3
X
C/3
X
03
X
CO
X
CO
X
CO
X
CO
X
CO
X
CO
X
CO
X
CO
X
CO
X
CO
rr
rr
rr
rr
rr
rr
DC
DC
DC
DC
DC
DC
DC
DC
DC
DC
h-
h-
h-
h-
h-
h-
h-
h-
h-
h-
h-
h-
h-
h-
h-
H
UllllHUnilH
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
LO
^-
CO
C\J
■^
o
O)
CO
r^
CD
LO
^1-
CO
CNJ
o
X
X
X
X
X
X
X
X
X
X
X
I-
X
I-
X
I-
X
I-
cc
X
I-
X
I-
DC
DC
DC
DC
DC
DC
DC
DC
DC
DC
o
Q_
o
Q_
o
Q_
o
Q_
o
Q_
o
Q_
O
Q_
O
Q_
o
Q_
O
Q_
O
Q_
O
O
0_
o
Q_
O
O
Setting a TRISx bit to '0' configures the corresponding PORTx pin as
an output; setting a TRISx bit to '1' configures the corresponding
PORTx pin as an input .
Figure 3. 8. Generic TRISx Register Bit Mapping
On the dsPIC30F60l4A, all of the analog inputs (denoted as ANO to AN 15 on
the data sheet) are located on Port B, so for the purposes of configuring the analog
inputs, we're concerned with the register TRISB. If we want to digitize the signal
on a particular Port B line, we have to set the corresponding bit in TRISB to a value
of "1". For example, if we want to digitize the signals on ANO, AN1, and AN8,
to use Port B<4> and Port B<6> as digital inputs, and to employ the remainder as
digital outputs, we would write a value of 0x0153 to the TRISB register (0x0103
(the analog inputs) ORed with 0x0050 (the digital inputs)).
Once we've set the signal direction, we then need to specify whether a particular
input is an analog or a digital signal, a task we accomplish by configuring the 1 6-bit
A/D Pin Configuration register (ADPCFG) appropriately. Each bit in the register
corresponds to one of the analog inputs (ANO to AN15); setting a bit to a "1"
configures the corresponding signal to be a digital input, and clearing a bit to "0"
configures the corresponding signal as an analog input. The register's bit-mapping
is shown in Figure 3.9.
Continuing the previous example, we would need to set the value of the ADPCFG
register to OxFEFC, leaving the bits for ANO, AN1, and AN8 as the only cleared
bits (and hence ANO, AN1, and AN8 as the only analog inputs).
Underneath the Hood of the dsPIC DSC 77
Bit
ADPCFG
Register
o
-I—'
o
O
Bit
Analog
Input
A/D Pin Configuration Register
Bit Mapping
15 14 13 12 11 10
8
7
ill llll
LO
5
LL
O
Q_
Q
<
^1-
5
LL
O
Q_
Q
<
CO
5
LL
O
Q_
Q
<
C\J
5
LL
O
Q_
Q
<
5
LL
O
Q_
Q
<
O
5
LL
O
Q_
Q
<
CD
CD
LL
o
Q_
Q
<
CO
CD
LL
O
Q_
Q
<
O
LL
o
Q_
Q
<
CO
CD
LL
O
Q_
Q
<
LO
CD
LL
o
Q_
Q
<
CD
LL
o
Q_
Q
<
CO
O
LL
O
Q_
Q
<
C\J
CD
LL
O
Q_
Q
<
5
LL
O
Q_
Q
<
O
CD
LL
o
Q_
Q
<
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
LO
■*■
CO
C\J
o
CD
CO
r^
CO
LO
^r
CO
CM
o
z
<
Z
<
z
<
Z
<
z
<
z
<
z
<
z
<
z
<
z
<
z
<
z
<
z
<
Z
<
z
<
z
<
Setting an APCFG bit to '0' configures the corresponding port (AN) pin
as an analog input; setting an APCFG bit to '1' configures the
corresponding port (AN) pin as a digital input.
Figure 3.9. AD Pin Configuration Register Bit-mapping
What would happen if the application configured a signal as a digital output in
TRISB but as an analog input in ADPCFG? In that case, the port pin would indeed
operate as a digital output, but in addition we would be able to digitize the voltage
level on the pin and read it in through the ADC module. That feature might be
useful in a safety-critical application so that the program can determine whether a
particular digital output is actually in the correct state, and not, for instance, short-
ing to ground or VDD.
Although this discussion will continue with the configuration of the ADC
module itself, in most applications the designer would want to finish configuring
the rest of the I/O port signal directions and states (i.e., those for Ports A, C, etc.).
first so that the hardware would be put in a known-safe state as quickly as possible.
One important aspect to note is that analog voltage levels on a pin configured as
a digital input may cause the input buffer to consume more current than that for
which the device is rated (that's the technical way of saying that we might destroy
the chip itself).
Step IB — Selecting the Reference Voltage Sources
With the signal directions and types configured, we move next to selecting the volt-
age references that we'll use for digitization. For simplicity of design, conversions
are often made over the full range of the supply voltage (AV SS to AV DD ) ; however,
to improve the resolution of the measurements, the conversion reference voltages
can be limited to the range V REF _ to V REF+ . This can significantly improve the chip's
78 Chapter 3
ability to measure limited- range input signals since the conversion is performed only
over the voltage range of interest, not the full supply voltage range. For instance, if
the designer knows that the input signal will range from 0.5 to 1.5 V, setting the
lower and upper reference voltages to those two values allows the ADC to produce
conversions in 0.24 mV increments ((V REF+ - V REF _) / 2 12 levels = (1.5V - 0.5 V) /
4096 levels = 0.24 mV/level). If the conversion were performed using V^p. of 0V and
V REF+ of 5 V, as might be the case for a standard 5 V system, the resolution would be
5 times worse, or 1 .2 mV / level. That might not sound so bad, but for low- voltage
inputs such as that generated by a thermocouple, the difference might be huge.
It's also possible to configure the module so that one input voltage is converted
relative to another input voltage, effectively producing a differential measurement.
This mode is limited, however, in that the conversion is unipolar; i.e., the reference
input voltage must always be less than or equal to the voltage on the nonreference
input. Even with this restriction, however, the ability to operate differentially can
be a useful way to reduce common-mode noise 10 on the inputs.
Recall that the upper and lower reference voltages represent the range of analog
input voltages that are then mapped to the 10-bit or 12-bit ADC output values.
The goal is to use a reference voltage range that most closely matches that of the
input signal so that we get the most resolution in the converted digital values. With
the dsPIC DSC, we have four possible combinations of upper and lower reference
voltages since we can select either AV SS or V REFL for the lower reference voltage and
either AV DD or V REFH for the upper reference voltage.
Setting the reference voltage sources is very straightforward; the application sim-
ply sets the Voltage Configuration bits (VCFG<2:0>) in the A/D Control Register
2 (ADCON2). Although there are three bits in VCFG and thus theoretically eight
possible reference voltage configurations, setting the upper bit (VCFG<2>) to a
"1" always selects an upper reference voltage of AV DD and a lower reference voltage
of AV SS . The table in Figure 3.10 shows the reference voltage configurations that
correspond to the various VCFG values, and Figure 3.1 1 shows the bit assignment
of VCFG in the ADCON2 register.
Step 1C— Selecting the Analog Inputs to Digitize
To reduce unnecessary processing overhead, the application can specify which specific
analog input channels are to be converted, the order in which they are to be converted
(to a degree, at least), and the number of conversions that are to take place before
interrupting the processor. This frees up a significant amount of processing time in
applications in which only a subset of the available ADC input channels are needed,
since the firmware doesn't have to spend time handling converted data for channels
whose values will never be required. In all sampling modes, digitized data is stored
in the 16-word ADCBUF buffer in the order in which it is sampled, starting with
Underneath the Hood of the dsPIC DSC 79
ADC Reference Voltage Selection
Using the VCFG Bits in ADCON2
VCFG<2:0>
Vrefh
Vrefl
000
AV DD
AVss
001
V REF+
AV SS
010
AV DD
Vref-
011
Vref+
Vref-
1xx
AV DD
AVss
V REF h = Upper reference voltage to A/D
Vrefl = Lower reference voltage to A/D
Vref+= External upper reference voltage
Vref-= External lower reference voltage
AV DD = Analog positive power rail
AV S s= Analog negative power rail (ground)
Figure 3.10. ADC Reference Voltage Configuration Values
VCFG Bit Mapping In ADCON 2
Bit
ADCON2
Register
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
C\J
O
LL
o
>
5
LL
O
>
o
O
LL
O
>
'
'
<
z
o
CO
o
'
'
CO
LL
CO
'
CO
Q_
CO
Q_
CO
CO
o
Q_
CO
LL
=>
CD
CO
h-
_l
<
Figure 3. 1 1. VCFG Bit-mapping in the ADCON2 Register
location ADCBUF0 and continuing until the number of samples specified in the
Samples Per Interrupt (SMPI) value in ADCON2 have been digitized, at which
point the next sample is stored again at ADCBUF0. Because of this behavior, the
application's ADC interrupt handler must ensure that it can unload and process
all of the samples it needs from the ADCBUF buffer in a single sampling time,
since failure to meet this timing requirement will mean that the sample stored at
ADCBUF0 will be lost (overwritten by the next sample stored there).
The ADC module can convert signals in one of two user-configurable channel
patterns, and it can even combine the two approaches for more flexibility. The first
technique, known as interleaved or alternate channel sampling, digitizes a specified
input channel (this is imaginatively denoted in the documentation as the Mux A
input), stores the digitized A value in ADCBUF0, then digitizes a second, usually
different, input channel (denoted as the Mux B input) and stores it in ADCBUF 1.
80 Chapter 3
Sampling continues in an alternating fashion (first the Mux A input, then the Mux B
input) until SMPI conversions have been stored in ADCBUF, at which point the ADC
module generates an interrupt (assuming its interrupt is enabled) . The next sample
collected after the interrupt is stored in ADCBUFO, and the process repeats.
To enable basic interleaved sampling (i.e., alternating between two inputs), the
application must set the Alternate Sampling (ALTS) bit in ADCON2 to a value of
"1 ". It must then designate the specific channels to sample as the Mux A and the Mux
B inputs by setting the 4-bit Channel Select A (CHOSA) field and the Channel
Select B field of the A/D Channel Select Register (ADCHS) to the 0-based index of
the desired Mux A and Mux B inputs, respectively. In the same write to ADCHS,
the application should also select the negative input for the S/H circuit for the Mux
A and the Mux B inputs by writing to the Channel Negative Input Mux A flag
(CHONA) and the Channel Negative Input Mux B flag (CHONB). Clearing the
CHONA or CHONB flag selects V REF _ as the negative input for the corresponding
Mux input, while setting the flag selects the voltage on the AN 1 input as the negative
input. In this way, the ADC module can support unipolar differential mode, with
the important requirement that the voltage on AN 1 always be less than or equal to
the selected Mux A or Mux B voltage.
The second technique, known as channel scanning, involves sampling data from a
group of semisequential channels with the module generating an interrupt after the
appropriate number of samples has been converted. We use the term semisequential
to indicate that while the channels are converted in a fixed sequential order (from
lowest-indexed channel to highest), individual channels may be eliminated from the
sampling sequence if their value is not needed. As with interleaved sampling, digitized
values are stored in ADCBUF as they are converted, beginning with ADCBUFO.
After SMPI samples have been stored to ADCBUF, the processor generates an inter-
rupt so that the data can be transferred from the buffer to the application. New
samples following the interrupt are stored in ADCBUF, starting at ADCBUFO even
if ADCBUF was not completely filled originally.
Finally, the dsPIC DSC supports a combination of interleaved sampling and chan-
nel scanning, with the constraint that the channel scanning can only be performed
during the Mux A portion of the sampling (i.e., Mux B is always a single input).
This might be useful when scanning a series of dynamic inputs and a reference input
such as a cold-junction compensation temperature. 11
Three simple examples may help clarify the concept of interleaved sampling, chan-
nel scanning, and the combination of interleaved sampling and channel scanning.
Example 1: Basic Interleaved Sampling
Assume that we would like to alternately sample first channel 2 (i.e., AN2) and
then channel 14 (AN 14), that the channel 2 input is to be referenced to V REF _,
Underneath the Hood of the dsPIC DSC 81
that the channel 14 input is to be referenced to AN1 (unipolar differential mode),
and that we would like to have the ADC module generate an interrupt after three
samples of each channel have been captured (a total of six samples per interrupt).
The conversions are to be made over the full input voltage range — i.e., using AV SS
and AV DD as the lower and upper reference voltages for the converter circuitry
(as opposed to the reference voltage for the S/H circuitry). In that case,
CHOSA = 0x02
CHONA =
CHOSB = OxOE
CHONB = 1
ADCHS = 0xlE02
ALTS = 1
BUFM =
SMPI = 5
CSCNA =
VCFG =
ADCON2 = 0x0019
(Mux A = channel 2)
(Mux A is referenced to V^p.)
(Mux B = channel 14)
(Mux B is referenced to AN 1 )
(CHONB in Bit 12, CHOSB in <11:8>,
CHONA in Bit 4, CHOSA in <3:0>)
(Enable alternate sampling)
(Don't split ADCBUF)
(Number of samples per interrupt = 6)
(Don't scan inputs)
(ADV RRFH = AV DD , ADV RFF t = AVcc)
ADCSSL = 0x0000
(VCFG in <15:13>, CSCNA in Bit 13,
SMPI in <5:2>, BUFM in Bit 1, ALTS in Bit 0)
Not scanning, so this is really a "don't care" value
Example 2: Channel Scanning
Assume that we want to scan channels 1—3, 6, 8, 10, 12, and that we want to
generate an interrupt after capturing two samples of each channel (i.e., after a
total of 14 samples). Data will be converted over the range V REF _
this scenario, we configure the ADC module as follows:
to Vrj^. For
CHOSA =
CHONA =
CHOSB =
CHONB =
ADCHS = 0x0000
ALTS =
(Mux A = 0, although this is really a "don't care" value)
(Mux A is referenced to V^ev- ~ "don't care" value)
(Mux B = - "don't care" value)
(Mux B is referenced to V REF _ — "don't care" value)
(CHONB in Bit 12, CHOSB in <11:8>,
CHONA in Bit 4, CHOSA in <3:0> - all are
"don't care" values)
(Disable alternate sampling)
82 Chapter 3
BUFM =
SMPI = 13
CSCNA = 1
VCFG = 3
(Don't split ADCBUF)
(Number of samples per interrupt = 14)
(Enable channel scanning)
(ADV^ph = V REF+ , ADV REFL = V REF J
ADCON2 = 0xC434 (VCFG in <15:13>, CSCNA in Bit 10, SMPI
in <5:2>, BUFM in Bit 1, ALTS in Bit 0)
ADCSSL = 0x1 54E Enable <12>, <10>, <8>, <6>, <3:1> to sample
channels 1-3, 6, 8, 10, and 12
Example 3: Combined Interleaved Sampling and Channel Scanning
Now assume that we want to scan channels 2, 5, and 7, alternate that group with
sampling channel 4, and that we want to generate an interrupt after capturing four
samples of each channel (i.e., after a total of 16 samples). Data will be converted
over the range V REF _ to V REF+ , and the negative input to the S/H circuit will be
set to Vr^. For this scenario, we configure the ADC module as follows:
(Mux A = 0, although this is really a "don't care" value)
CH0SA =
CH0NA =
CH0SB = 4
CH0NB =
ADCHS = 0x0400
(Mux A is referenced to V RFF _)
ALTS = 1
BUFM =
SMPI = 15
CSCNA = 1
VCFG = 3
ADCON2 = 0xC43D
(Mux B = - "don't care" value)
(Mux B is referenced to V REF _)
(CH0NB in Bit 12, CH0SB in <11:8>,
CH0NA in Bit 4, CH0SA in <3:0>)
(Enable alternate sampling)
(Don't split ADCBUF)
(Number of samples per interrupt =16)
Enable channel scanning
(ADV REFH = V REF+ , ADVj^pl = V REF J
ADCSSL = 0x00A4
(VCFG in <15:13>, CSCNA in Bit 10, SMPI in
<5:2>, BUFM in Bit 1, ALTS in Bit 0)
Enable <7>, <5>, and <2> to sample channels
2, 5, and 7
To recap, at this point we've configured the I/O pins for our application's par-
ticular requirements, selected the voltage reference sources, and identified the ADC
input channels that are to be converted. We have two more steps left in configuring
the signal chain: specifying the ADC conversion clock and selecting the conversion
trigger.
Underneath the Hood of the dsPIC DSC 83
Step ID — Specifying the ADC Conversion Clock
Each complete digitization cycle (the acquisition and conversion of a single channel)
requires one cycle of the ADC clock (whose period is designated 7^ D ) for acquisition
of the analog signal level, an additional ADC clock for each bit of the conversion, and
one more cycle of the ADC clock to transfer the digitized value to the ADCBUFx
location and set up for the next digitization. This means that 10-bit ADCs require
13 T AD and 12-bit ADCs need 15 T AD to digitize a single channel. As with so
much of the dsPIC DSC, the clock source and period is software configurable, but
the chips hardware requires that T AD be at least 333.3 ns 12 when operating with a
supply voltage V DD of at least 4.5V or at least 666.7 ns when operating V DD below
4.5V. Failure to meet this timing requirement will result in ADC readings that are
significantly lower than they should be because the sample-and-hold amplifier will
not have sufficient time to charge between channels.
T AD is derived from T CY , the system clock period, using the equation:
T AD = ^cy * (0.5 * (ADCS<5:0> + 1)) Equation 3.1
where
T AD is the ADC clock period,
T CY is the system clock cycle period, and
ADCS<5:0> is the numeric value of the 6-bit ADC Clock Select
register ADCS.
From this, we can calculate that the maximum sampling rate at a V DD of 4.5V
or above is:
f max = 1/(15* T ADmin ) = 1 / (15 * 333.3 ns) = 200,020 sps
Operating at a V DD of less than 4.5 V>f smax is half that value or 100,010 sps.
To determine the correct value to program into the ADCS register, we simply
solve for ADCS in the equation above, which yields:
ADCS<5:0> = 2 * (T AD I T CY ) - 1
For example, if we wanted to sample all 1 6 channels at 1 Ksps per channel
(a cumulative sampling rate of 16 x 10 Ksps or 160 Ksps), we will require a total
of 160 Ksps x 15 = 2,400,000 ADC clock cycles / sec. This equates to a T AD of
1 / (2,400,000 cycles/sec) = 416.7 nsec. Assuming that the dsPIC DSC is operating
at its maximum 30 MIPS speed, the instruction cycle time is T CY =1/30 MIPS =
33.33 ns. We would then calculate the ADCS value as:
ADCS = 2 * (416.7 ns / 33.3 ns) - 1 = 24
It's important to note that, since the ADCS register supports only six bits, it is
limited to a maximum value of 63. Thus, for a dsPIC DSC running at 30 MIPS
performing 12-bit conversions, the maximum value for T AD is:
84 Chapter 3
r ADmax = 33.33 ns * 0.5 * (63 + 1) = 1.07 us
which corresponds to a minimum sampling frequency of:
f smin = 1 / (15 * T ADm J = 1 / (15 * 1.07 F sec) = 62,507 sps
If the algorithms used by the application require a slower sampling rate, the
application must either decimate the sampled values 13 or it must use a combination
of polled and interrupt-driven operation to initiate a single group of digitizations for
all channels that are performed individually at the higher rate but that stop after all
channels have been sampled once. Some other mechanism, perhaps a software timer,
is used to generate the next batch of digitizations at the desired slower rate.
This last approach is not quite as bad as it might first appear because, although
it incurs additional software overhead, this method allows us to sample all of the
channels relatively simultaneously, a feature that is of great benefit to systems in
which signals on one channel may be related to another channel. For instance,
robotic arms frequently have what's known as an end-of-arm force I torque sensor that
measures the force and torque experienced by the object at the end of the robotic
arm. This allows the robot to safely move the object without either flinging it off
into space (if the robot doesn't apply enough holding force) or crushing it (if the
robot applies too much force), and the force and torque are usually measured in
three dimensions. A very common type of force/ torque sensor is one in which the
loads on three precisely positioned physical beams on the sensor are measured, so
the signals from all three beams are related. If the signals are measured with too
much of a time difference between the samples from each channel, the system loses
information because samples from one signal apply to the state of the system at one
point in time while the samples from another signal apply to its state at a slightly
different time. The goal is to measure all signals as simultaneously as possible in
order to get the most accurate reading. By reducing the interchannel sampling time,
we can significantly improve the system's performance because the samples within
a group become "more simultaneous."
Step IE — Selecting the Sampling and Conversion Triggers
The final step in configuring the ADC Module is the selection of the sampling and
conversion triggers. As we discussed previously, each digitization cycle consists of
a sampling phase in which the S/H amplifier charges to the current analog signal
level on its input and of a conversion phase in which the A/D converter circuitry
converts the S/H amplifiers analog signal level to a numeric value. At the conclusion
of the conversion phase, the digitized value is stored to the appropriate ADCBUF
entry. The dsPIC DSC allows the user to determine how each of the two phases will
start (known as the sample trigger and the conversion trigger), giving the designer a
great deal of flexibility.
Underneath the Hood of the dsPIC DSC 85
There are two options for the sample trigger: manual triggering, in which the
application sets the sampling flag every time it wants to convert an input signal,
and automatic trigger, in which sampling of the next channel is started as soon as
the conversion for the current channel completes. Manual triggering is appropri-
ate when the signal being monitored can be checked on a nonperiodic basis (for
instance, background monitoring of a fluid level to make sure it doesn't overflow)
or when samples need to be taken at a slower rate than can be supported in auto
conversion mode. An example of the latter case would be sampling the temperature
of a device with a large thermal mass; 14 because the temperature can change only
relatively slowly, the application may sample it infrequently to reduce the associated
software overhead. Although the sampling rate is low, it still needs to be periodic in
order to correctly implement DSP algorithms. To sample periodically but slowly,
the application may perform the digitization within the interrupt service routine
for a timer with the desired period.
The application selects the desired sampling trigger through the A/D Sample
Auto-Start (ASAM) bit in ADCON1 (ADCONl<2>). Clearing ASAM configures
the ADC module to use a manual sampling trigger, in which the application must
explicitly set the A/D Sample Enable (SAMP) bit in ADCON 1 (ADCON 1 < 1 >) to a
value of" 1 " every time it wants to sample the input signal. Conversely, setting ASAM
configures the module for automatic sampling in which sampling of the current
signal level is automatically begun as soon as the previous conversion completes, with
the SAMP bit being set by the module's hardware without application intervention.
In either manual or automatic sampling, the S/H amplifier will continue to sample
the input signal until the conversion phase begins, based on the occurrence of the
conversion trigger.
The application identifies the method by which the conversion phase will start
(and hence the sampling phase will end) through the Conversion Trigger Source
Select (SSRC<2:0>) bits in the ADCON1 register (ADCONl<7:5>). Although
there are three SSRC bits and therefore eight possible conversion trigger sources,
three of those combinations are reserved:
SSRC<2:0>
Conversion Trigger Source
000
Clearing SAMP bit ends sampling and starts conversion
001
Active transition on INTO pin ends sampling and starts conversion
010
Timer 3 compare event ends sampling and starts conversion
011
Expiration of the motor control PWM interval ends sampling and starts con-
version
100
Reserved
101
Reserved
86 Chapter 3
no
in
Reserved
Internal counter ends sampling and starts conversion (auto convert)
Table 3.1. Conversion Trigger Source Bit Mapping for ADCON1 SFR
Note that once the SSRC bits have been set, they remain in effect until the chip
either powers down or they are overwritten by a subsequent write to ADCON1.
When using manual conversion, the application is responsible for terminating
the sampling phase and starting the conversion phase by simply first setting SSRC
to 000b and then clearing the SAMP bit. The application waits for the conversion
to complete by either delaying for an appropriate length of time or by monitoring
the A/D Conversion Status flag (DONE) in the ADCON1 register (ADCON1<0>),
which will be set once the conversion has finished. Subsequent samples are taken
by repeating the SAMP strobe/DONE monitor sequence.
The designer can also start the conversion phase through the occurrence of one
(and only one) of three events: an active transition on the INTO signal (an external
source), the expiration of the dsPIC DSC s Timer 3 (an internal source), or the
conclusion of the chip's motor control PWM interval (also an internal source). In
order to use this mode, the application must set the SSRC field to the desired trig-
ger source (either 001b, 010b, or 01 lb) and configure the corresponding resource
(external interrupt, timer, or PWM) appropriately. Once the selected event occurs,
the module stops the current signal sampling and begins the conversion phase.
Finally, the application can use the auto convert mode, in which the dsPIC DSC
automatically starts the conversion phase a specified number of A/D clock cycles
(between 1 and 32) after the start of the sampling phase. In this mode, the module
uses an internal counter to monitor the length of the sampling phase and then starts
the conversion phase once the specified length of time (expressed in 7^ D ) has elapsed.
By combining automatic sampling with automatic conversion, the application can
run the system in a fully automatic mode that requires no user intervention once
it starts.
Checklist for Using the ADC Module
To perform a conversion using the ADC module, the application must perform the
following seven basic operations:
1. Configure the ADC module for the applications specific signal path
requirements, including:
• configuring the associated I/O pins as analog inputs, selecting the
appropriate voltage reference signals, and configuring any of the
other I/O port signals as digital inputs or outputs;
Underneath the Hood of the dsPIC DSC 87
• selecting the ADC input channels that are to be converted;
• selecting the desired ADC conversion clock and trigger; and
• enabling the ADC.
2. Configure the ADC interrupt, if the application is performing interrupt
driven data acquisition, by
• clearing the A/D Interrupt Flag (ADIF) and
• setting the ADC interrupt priority.
3. Begin sampling the analog data.
4. Wait for the necessary data acquisition time.
5. Trigger the end of the data acquisition and start the data
conversion.
6. Wait for the data conversion to finish by either:
• waiting for the ADC interrupt, or
• monitoring the ADC Done flag to see when it is set.
7. Read the converted value(s) from the ADC Result Buffer (ADCBUFO:
ADCBUF15) and clear the ADIF flag if performing interrupt-driven
acquisition.
Timer/Counter Module
The timer/counter module allows the dsPIC DSC to generate accurate internal
clocks that can be used to maintain a real-time clock (RTC), to track elapsed time
for application-specific events, to schedule time-critical events such as ADC sampling
triggers, or to count transitions on certain external hardware signals. Depending on
the model of dsPIC DSC used, the module supports either three or five individual
timer/counters that can operate independently or in specific predefined combinations
to offer a tremendous amount of flexible timing and event counting power.
There are three basic timer/counter configurations that may be present in a
particular dsPIC timer module, denoted in the documentation as Type A, Type B,
and Type C timer/counters. All of these three types share certain common charac-
teristics, but they each also have unique features that allow them to perform certain
specific tasks very well. In our examination of the module, we'll first look at the
aspects common to all dsPIC timer/counters and then explore the distinctive features
of each type to understand how and why a designer would want to incorporate a
particular configuration into an application. Note that in the following discussion
we'll frequently refer to register or pin names such as PRx, TMRx, TxCON, etc.
88 Chapter 3
In these cases, simply substitute the desired timer index (1-5) for the "x" to get the
actual name of the register or pin. For example, the registers for Timer 1 are PR1,
TMR1, T1CON, while those for Timer 2 are PR2, TMR2, andT2CON.
Common Timer/Counter Features
Every timer/counter has the following minimum set of features:
1. a 16-bit Period register (PRx),
2. a 16-bit counter (TMRx),
3. a 16-bit comparator that compares the value in the counter to the value in
the Period register on every clock cycle,
4. a clock prescaler to control the frequency at which the timer/counter is
updated,
5. two or more timer/counter clocking options, one of which is always the
instruction cycle clock (T CY ),
6. a Gated Timer Accumulate option that allows the application to measure the
length of time that the associated Timer Clock input pin was pulsed high or
low,
7. the ability to set an interrupt flag and to generate an interrupt when the
comparator detects that the counter value matches the value stored in the
Period register, and
8. a Timer Configuration (TxCON) register that allows the application to
configure the operation of the specific timer.
The basic operation of a timer is really very simple: the application clears the
timer's counter register (TMRx), loads a target value in the timer's Period register
(PRx), and then enables the timer by setting the Timer On (TON) flag in the timer's
control register (TxCON). Once enabled, the timer increments its Counter register
on each rising edge of the selected clock source, and when the Counter register value
matches the Period register value, the timer sets its interrupt flag and generates an
interrupt (assuming the interrupt is enabled). Setting the interrupt flag also resets
the Counter register to without software intervention, and the process repeats
until the user disables the timer by clearing its TON flag.
Although correct insofar as it goes, the preceding summary of the basic timer
operation glosses over several important concepts that one needs to understand in
order to configure the timer properly. The first of these two concepts is the selection
of an appropriate clock source for the timer/counter, the second is the operation of
the clock prescaler, and the third is the calculation of the desired value to load into
the Period register, which depends upon both the selected clock source and the clock
prescaler. We'll turn our attention to these three related subjects now.
Underneath the Hood of the dsPIC DSC 89
The application can configure each timer to use either an internally generated
clock based on the instruction cycle clock (with a period of T CY ) or an external clock
signal (with a period of T XCK ) that is applied to the TxCK pin. In either case, the
selected clock signal passes through a prescaler that divides it by a factor of either
1, 8, 64, or 256 (i.e., the clock period is multiplied by a factor of 1, 8, 64, or 256,
respectively) prior to its use by the associated counter register. This gives the designer
the ability to track longer time periods at the expense of a lower time resolution, as
we can readily see from a simple example. If we choose to use the internal instruc-
tion cycle clock of a dsPIC DSC running at 30 MIPS (T CY = 33.33 ns) as our clock
source and a prescale factor (PSF) of 1, we can achieve a timer resolution of:
T RES = T CY * PSF = 33.33 ns * 1 = 33.33 ns,
and our 16-bit Counter register will support any period up to:
T M ax = 65,536 * 33.33 ns ~ 2.18 ms.
If, on the other hand, we use the same clock source but employ a prescale factor
of 256, our timer resolution is reduced to:
T RES = T CY * PSF = 33.33 ns * 256 = 8.5325 us,
but the 16-bit Counter register can now support an period up to:
T M ax = 65,536 * 8.5325 us - 559.18 ms.
Once the clock source and prescaler values have been chosen, the value to load
into the period register is easily computed as:
1 -tv — 1 DCDirin / 1
PERIOD ' x RES
where
PR is the 1 6-bit value to load into the Period register (PRx)
Tperiod is tne desired period in seconds
Tres is the timer resolution in seconds
Of course, T PERIOD and T RES must be such that the Period register value fits into
a 16-bit register — i.e., PR must be less than or equal to 65,535. In many applica-
tions, it's the need to meet this register-length requirement that drives the choice of
the clock source and the prescaler value.
Now that we've looked at the traits that all three timer/counter types share, let's
examine the ways in which they differ and why we would want to use one type of
timer/counter over another in particular situations.
Type A Timer/Counters
Type A timer/counters can be used either as a 16-bit timer (as we've already dis-
cussed), as a 16-bit synchronous counter, or as a 16-bit asynchronous counter. When
90 Chapter 3
operating as a 1 6-bit synchronous counter, the timer/counter behaves in much the
same way as when it serves as a 1 6-bit timer; the only real difference is that, whereas
in timer mode one expects the clock to be stable and periodic, in counter mode the
input signal to be counted (which comes in on the associated external clock pin)
may occur on an aperiodic basis. The timer's hardware synchronizes the count signal
to the internal phase clocks before feeding the synchronized clock to the counter,
which is incremented on each rising edge of the external count signal. As in timer
mode, when the TMR1 register value equals the value of the Period register PR1,
the TMR1 register is reset to and the module generates an interrupt.
The asynchronous counter mode is unique to Type A timer/counters, as is the
ability to use a 32-kHz low-power oscillator for its external clock signal, and these
two features make it ideal for use as a real-time clock (RTC) for dsPIC applications
because they permit the timer to operate even when the system clock is inactive. This
means that timer will still work when the chip is in Sleep mode, a critical require-
ment for a true RTC. In any dsPIC DSC, there is only one Type A timer, Timer 1 .
Figure 3.12 shows the block diagram for the Type A timer/counter.
PRx Register
(16- bits)
TxlF
Event Flag
Iz
Comparator
(16- bits)
— zs —
TMRx Register
(16- bits)
TGATE
Sync
TSYNC
TGATE
LPOSCEN
Gate Sync
TON
1X
Prescaler
Figure 3. 12. Type A Timer/ Counter Block Diagram
There are several important points to note in the block diagram. First, because
Timer 1 has special circuitry across its Timer 1 Clock Input (T1CKI) and its Second-
ary Oscillator Input (SOS CI) signals, an application can use an external low-power
32-kHz crystal to generate the clock for the timer. Second, whatever clock source is
used, the clock signal passes through the prescaler before being optionally synchro-
nized to the internal instruction cycle clock, so that input clocks with frequencies
Underneath the Hood of the dsPIC DSC 91
that are at least 0.5 * (F CY * PSF) can be used (i.e., input clocks can be faster than
the instruction cycle clock by a factor o(Vi * PSF). However, because of the timing
constraints of the combinatorial logic used to implement the asynchronous exter-
nal clock input, external clock signals to a Type A timer/counter always must be
less than 25 MHz for proper operation, even if this limits the frequency range that
might be expected by applying the prescaler factor. Of course, as with all types of
dsPIC timer/counters, the external clock must meet the required rise and fall times,
which are a maximum of 10 ns.
Now that we know what a Type A timer/counter can do, what are the specific
steps that we need to take to configure it for operation? First, we have to determine
the mode in which we wish to operate the timer/counter: timer, synchronous counter,
or asynchronous counter (the mode used to implement a real-time clock) . Having
established the operational mode, we then need to determine when (or even if) we
want the timer/counter to generate an interrupt (i.e., on which counter value should
the timer/ counter interrupt the chip?).
Timer Mode Initialization
To initialize Timer 1 for operation in Timer mode,
1 . Stop the timer during initialization by clearing the Timer On (TON) con-
trol bit in T ICON (TlCON<15>). Also, clear the Timer 1 Interrupt Flag
(T1IF) in IFSO and the Timer 1 Interrupt Enable (THE) flag in IECO to
clear out any pending Timer 1 interrupt conditions. This ensures that the
initialization sequence can complete without interruption.
2. Clear the Timer Clock Select (TCS) flag inTlCON (TlCON<l>) to select
the internal instruction cycle clock for the input to the timer's prescaler.
3. Set the clock prescaler to the desired value by configuring the Timer Clock
Prescale (TCKPS) bits inTlCON (TlCON<5:4>):
TCKPS = 00b use 1 : 1 clock prescaler (effectively no prescaling)
TCKPS = 01b use 1:8 clock prescaler
TCKPS = 10b use 1:64 clock prescaler
TCKPS = 1 lb use 1:256 clock prescaler
4. Clear the Timer External Clock Input Synchronization Select (TSYNC)
flag in T1CON (TlCON<2>), since we are using the internal clock and
thus don't need to synchronize the external clock signal.
5. Set the Timer Stop in Idle (TSIDL) flag inTlCON (TlCON<13>) based
on whether the application wants the timer to stop in Idle mode or to run
in Idle mode:
92 Chapter 3
TSIDL = allow the timer to run in Idle mode
TSIDL = 1 stop the timer when the chip enters Idle mode
6. Set the Timer Gated Time Accumulation Enable (TGATE) flag value in
T1CON (TlCON<6) based on whether the application is using the gated
time accumulation mode:
TGATE = disable gated time accumulation mode
TGATE = 1 enable gated time accumulation mode (must also
use the internal clock source in this mode, so TCS
must be cleared if TGATE =1)
7. Set the Period register (PR1) to the value that corresponds to the desired
elapsed time between interrupts, as previously calculated in the Common
Timer I Counter Features section.
8. If the application needs to be interrupted upon expiration of the timer (i.e.,
when the TMR1 value equals the value of PR1 set in step 7 or on the falling
edge of the gating signal if gated time accumulation mode is enabled), then
set the Timer 1 Interrupt Enable flag (THE) in IECO to enable the inter-
rupts. Also enable global interrupts, if that has not already been done.
9. Start the timer by setting TON in T1CON.
Note that in the initialization, steps 2 through 6 are usually combined into a
single write to the T ICON register; they are broken out in the initialization sequence
only for clarity.
Synchronous Counter Mode Initialization
The synchronous counter mode is similar to the timer mode except that the signal
to be counted is applied on the external clock input and is synchronized to the inter-
nal clock. In this mode, the gated time accumulation concept does not apply. The
initialization sequence, therefore, is very similar to that for timer mode operation.
1 . Same as step 1 in the Timer Mode Initialization section.
2. Set the Timer Clock Select flag in T1CON to a value of 1 to select the
external clock input.
3. Same as step 3 in the Timer Mode Initialization section.
4. Set the Timer External Clock Input Synchronization Select (TSYNC) flag
in T ICON to 1 to synchronize the external clock input to the instruction
cycle clock.
5. Same as step 5 in the Timer Mode Initialization section.
Underneath the Hood of the dsPIC DSC 93
6. Clear the Timer Gated Time Accumulation Enable (TGATE) flag value
in T1CON since we are not using the gated time accumulation mode.
7. Same as step 7 in the Timer Mode Initialization section.
8. Same as step 8 in the Timer Mode Initialization section.
9. Same as step 9 in the Timer Mode Initialization section.
As with the timer mode initialization, steps 2 through 6 are usually combined
into a single write operation to the T1CON register.
Asynchronous Counter Mode
Asynchronous counter mode is identical to synchronous counter mode except that
the counter will continue to operate in Sleep mode and the input can be a low-power
32-kHz crystal oscillator. If a crystal oscillator is used as the input, one side of the
oscillator is connected to the external clock input signal and the other side is con-
nected to the Secondary Oscillator Input pin (SOSCI). In addition, the Low-Power
Oscillator Enable (LPOSCEN) flag in the Oscillator Control (OSCCON) register
has to be set to a "1" to enable the crystal oscillator support circuitry required to
drive the crystal.
As would be expected, the initialization sequence is very similar to that for the
synchronous counter.
1—3. Same as steps 1 through 3 in the Synchronous Counter Initialization
section.
4. Clear the Timer External Clock Input Synchronization Select (TSYNC)
flag in T1CON (TlCON<2>) to operate the external clock signal
asynchronously.
5-9. Same as steps 5 through 9 in the Synchronous Counter Initialization
section.
As with the other initializations, steps 2 through 6 are usually combined into a
single write operation to the T1CON register.
Type B Timer/Counters
Like their Type A counterparts, Type B timer/counters may serve as 16-bit timers
or 16-bit synchronous counters; however, they also have the ability to be combined
with a Type C timer/counter to form a 32-bit timer or a 32-bit synchronous counter.
When combined in this manner, the Type B timer/ counter forms the lower 1 6 bits
of the 32-bit value, and the Type C timer/counter forms the upper 16 bits. This
added flexibility comes at a small price, though, because Type B timer/counters can-
not function asynchronously in any capacity, nor can they accept a crystal oscillator
input. In most applications, these are not serious constraints.
94 Chapter 3
On devices that support Type B timer/counters, Timers 2 and 4 (if present) are
always of this type. In addition, when pairing Type B and Type C timer/counters,
only certain combinations are permitted. Timer 2 is always combined with Timer 3,
and Timer 4 is always combined with Timer 5. When combined as a 32-bit unit, the
Timer Control register (TxCON) for the Type B timer/counter serves as the control
register for the entire 32-bit timer/counter. Since the dsPIC DSC cannot read/write
a single 32-bit value directly from/to the combined TMR3/TMR2 or TMR5/TMR4
registers, the chip uses a holding register (TMRxHLD) for values in the upper word
of the timer/counter register. To write a 32-bit value to the combined timer/counter
register, the application first writes the upper 16 bits to the TMRxHLD register and
then writes the lower 1 6 bits to TMRx for the Type B timer/counter. Upon receiving
the write to TMRx, the dsPIC DSC simultaneously loads the value of TMRxHLD
into the TMRx register for the corresponding Type C timer/counter. Reading the
32-bit value from the combined counter register is reversed; when the application
reads the lower word from the Type B counter register, the dsPIC DSC automati-
cally loads the upper word into the TMRxHLD register. The application can then
read the TMRxHLD register to get the upper word value.
Figure 3.13 shows the block diagram for a Type B timer/counter. The only signifi-
cant differences between this block diagram and that for the Type A timer/counter
is the absence in the Type B block diagram of the signal-conditioning circuitry that
supports crystal oscillator input and the lack of an asynchronous clock path from the
output of the prescaler into the counter circuitry. As with the Type A timer/ counter,
the prescaler for the Type B timer/counter precedes the synchronization circuitry,
so Type B timer/counters can accept external clock signals up to 0.5 * F CY * PSF.
Because there is no asynchronous combinatorial logic on the external clock signal
input, Type B timer/counter clock signals are not limited to the 2 5 -MHz maximum
frequency required by Type A circuits.
Type B timer/ counters have one additional flag defined in their TxCON reg-
ister that doesn't appear in the corresponding register for either Type A or Type C
timer/counters. The application should set the 32-bit Timer Mode Select (T32) bit
to combine a Type B timer/counter with the corresponding Type C timer/counter
or clear the flag to operate the two timer/counters as independent 16-bit units.
Because Type B timer/ counters always operate synchronously, there is no need for
the TSYNC bit in their TxCON registers, so that flag is not defined.
16-bit Timer and 16-bit Synchronous Counter Initialization
Initialization of a Type B timer/counter for operation either as a 16-bit timer or as a
1 6-bit synchronous counter is identical to the corresponding initialization sequence
for a Type A timer/ counter except that T32 must be cleared in TxCON and TSYNC
is not initialized (since it doesn't exist for Type B units).
Underneath the Hood of the dsPIC DSC 95
PRx Register
(16- bits)
TxlF
Event Flag
1Z
Comparator
(16- bits)
— zs —
TMRx Register
(16- bits)
Sync
TGATE
TxCKI
TCKPS<1:0>
i
Prescaler
Figure 3. 13. Block Diagram of a Type B Timer I Counter
32-bit Timer or Synchronous Counter Initialization
Initialization of a Type B timer/counter for 32-bit operation is identical to that for
operation as a 16-bit timer, except thatT32 must be set inTxCON, and the inter-
rupt enable flag that must be used is that for the Type B timer/counter. Note that the
PR register for both the Type B timer/counter and its paired Type C timer/counter
must be written.
Type C Timer/Counters
Type C timer/counters are similar to Type B timer/ counters and have the same
basic operational modes, but as the block diagram in Figure 3.14 shows, the exter-
nal clock synchronization circuitry is placed before the prescaler rather than after,
so the maximum external clock frequency for a Type C timer/counter is 0.5 * F CY
rather than the potentially higher 0.5 * F CY * PFS of Type B timers. Like Type B
timer/counters, the lack of asynchronous combinatorial logic on the external clock
input eliminates the 25-MHz clock frequency limitation of Type A units.
Initialization of the Type C timer/counters is nearly identical to that for the Type
B timer/counters in each of the four different operating modes, with one important
difference. When operating a Type C timer/counter in 16-bit mode, the T32 flag
in its paired Type B timer/ counter control register must be cleared to place both
timer/counters in 16-bit mode.
96 Chapter 3
ADC Event
Trigger
TxlF
Event Flag
TxCK
TGATE
PRx Register
(16-bits)
1Z
Comparator
(16-bits)
— zs —
TMRx Register
(16-bits)
TGATE
TON
TCKPS<1:0>
i
Prescaler
Figure 3.14. Block Diagram of a Type C Timer I Counter
3.4 Summary
This chapter has presented quite a bit of detailed information about the dsPIC DSC s
architecture, although it has certainly not explored all there is to understand about
the chip. Additional detailed information can be found in three other Microchip
documents: the dsPIC30F Family Reference Manual, the dsPIC30F Programmer's
Reference Manual, and the data sheet for the application's specific dsPIC device. All
of these can be found on the official Microchip website {www.microchip.com) , as can
numerous application notes, design tips, and web seminars that describe and analyze
particular system components and their application to real- wo rid problems.
In the next chapter, we'll continue our exploration of the peripheral modules
available on the dsPIC DSC by delving into the chip's communication resources.
Endnotes
1 . The requirement for deterministic system behavior simply means that the
design must guarantee that the system will respond to an event within a
specified time period, with the further implied constraint that the response
time is suitable for the tasks that we're trying to accomplish. It does no
good to ensure that the system responds to an event within three seconds
if new events occur every three milliseconds.
Underneath the Hood of the dsPIC DSC 97
2. Errata is the plural form of the Latin word erratum, which is the term
used in the Latin formula for the assignment of mistakes in a court case.
In our case (no pun intended), one gathers a bit more insight from the
verb errare (to stray) from which "erratum" is derived. The errata are a list
of the conditions under which the chip's implementation strays from its
intended design. Definitions come from The American Heritage Dictionary
entry and the Thompson-Gale Legal Encyclopedia entry found on the URL
http'.llwww. answers, com/ topic/ erratum.
3. When we sign-extend a two's complement value, we replicate the sign bit
as necessary to reach the desired representation length. For example, if
we wanted to sign-extend an 8-bit value to 16 bits, we would replicate
the sign bit (the MSB) 8 times to the left of the number. Sign-extending
the 8-bit value OxFC to 16 bits would result in the value OxFFFC; sign-
extending the 8-bit value 0x7F would result in the value 0x007F
4. The signal chain refers to the processing stages that a signal goes through
from input to output. This chain usually consists of both analog and
digital components, at least in systems that employ digital signal process-
ing techniques.
5. psi = pounds per square inch.
6. dsPIC30F 12-bit ADC Module, Part 1 of 2, page 6. The webinar is avail-
able from the Microchip website.
7. Actually, the term conversion is one that is used for not only the act of
converting the analog signal level of the sample-and-hold amplifier (the
manner in which we use it in this section) but also for the overall acquisi-
tion/conversion cycle. In most cases, the intended meaning is fairly obvious
from the context, but it's an example of how sloppy terminology can work
its way into the engineering lexicon.
8. Jitter refers to the deviation about a nominal value of the sampling period.
For instance, if the nominal sampling period for the system is 2 ms and
the actual sampling period varies between 1.8 ms and 2.1 ms, the jitter
for the system would be 0.3 ms or 15%, which is not too good.
9. Yes, those really are numeric digits at the front of the two "words," if one
can call an amalgamation of digits and letters a word. The key is to remem-
ber the convention, not to get hung up on the rules of English. Although
this semi-mnemonic is not original with the author, it has proven useful
over the years.
98 Chapter 3
10. Common-mode noise is electrical noise that appears on both inputs of a dif-
ferential signal. This commonly appears on twisted-pair cables in which both
conductors are intertwined and thus any radiated noise that is coupled into
one wire will be coupled into the other as well. Theoretically the differen-
tial signal is immune to this type of noise because the receiver looks at just
the difference between the voltages on the two conductors, so any voltage
(including noise voltage) that appears on both conductors is subtracted out.
In practice, this is not always the case, but it is still a very useful technique
for significantly reducing the effects of unwanted noise.
1 1 . Cold-junction compensation is a technique used to account for the tempera-
ture-dependent voltage differential that develops at the junction of any two
dissimilar metals. We'll examine the topic in detail in the multichannel
temperature-monitoring application developed later in the book.
12. 1 ns = 1 nanosecond = 10" 9 seconds, which the reader already knew. Hav-
ing just ranted about sloppy terminology, however, it seemed wise to leave
nothing to chance.
1 3 . Decimation is the process by which data sampled at one frequency is con-
verted to a sampling rate at a lower frequency. When the higher sampling
rate is an integer multiple of the lower frequency, this can be easily accom-
plished by simply ignoring samples in the higher-rate data stream whose
sample index is not an integer multiple of the lower-rate stream. If the
higher sampling rate is not an integer multiple of the lower rate, however,
we must first interpolate the higher frequency data to generate a third data
stream whose sample rate is the least common multiple of the original high
sample frequency and the desired lower sample rate. We can then safely
decimate this third data stream to extract the desired lower-rate data.
14. Thermal mass is a concept in thermal management that is similar to physical
mass in mechanics. The greater a body's thermal mass, the more difficult it
is to change its temperature. An example of an object with a high thermal
mass would be a large plate of steel, which requires a great deal of energy
to heat but that stays warm for a long time once it is hot. A thin needle is
an object with a relatively low thermal mass; it can be heated and cooled
quickly.
Learning to be a Good Communicator
The higher you go, the wider spreads the network of communication
that will make or break you.
— Donald Walton
One aspect that permeates everything we do with intelligent sensors, indeed one
of the defining qualities of an intelligent sensor, is its ability to communicate with
other components both within its local environment and remotely. As we'll see,
the dsPIC DSC offers an extensive array of communication options, with the
appropriate method dependent upon the nature of the data to be communicated,
the speed at which the data must be transferred, and the physical medium over
which the communications must take place. The chapter is divided into two main
sections, the first of which provides background on the types of communication
requirements that frequently arise in intelligent-sensing applications. The remainder
of the chapter explores the communication options available for the dsPIC family
of devices, identifies the situations for which each option is most appropriate, and
explains specifically how to use the associated hardware modules.
4.1 Types of Communications
As we examine the issue of communication, it's important to understand that there
is no one "right" form of communication for intelligent sensors any more than there
is a single best form of communication for people. When we want to get a point
across to someone else, we instinctively adjust the volume of our voice, the speed
of our speech, and the amount of information we're trying to convey based on the
environment, the importance of what we have to say, and the person to whom we're
speaking. If one were wandering the halls of the Louvre with a four-year-old niece,
the phrase "pretty picture" might be all the commentary required; the same excur-
sion with a fellow painter might elicit exhaustive debate on brush stroke, color, and
style. In both cases, the conversation is shaped by the capabilities of the speaker and
the audience, both in terms of the amount of information that is communicated
and its level of detail.
99
100 Chapter 4
The situation is no different with intelligent sensors; the methods of commu-
nication we use depend upon the type of data that we want to communicate, its
urgency, and the physical medium it must traverse between the source and destina-
tion. Configuration commands, for instance, usually are sent from the host system
to the sensor system before the sensor starts reporting parameter measurements.
Unless the quantity of command data is extremely large, the speed at which that
data is transferred is not particularly important, and other than the requirement
that commands arrive at the sensor in the order in which they were transmitted,
the communications are not particularly time-critical. At the opposite end of the
spectrum would be alarm conditions detected by the sensor; these must reach their
destination reliably and quickly enough that the host system can act upon the received
information to avert undesirable, possibly dangerous, operational conditions. We
would expect the latter situation to demand a communication technique that is more
robust and timely than the former. Fortunately, the dsPIC DSC offers a number of
options that meet the needs of a wide variety of communication situations.
Defining Characteristics of a Communication Channel
While we've touched upon some of the important characteristics of a communica-
tion channel, it's time that we become more explicit. Doing so allows us to better
categorize different approaches and gives us some benchmarks with which to assess
alternative communication options. In our discussion, we're making the assump-
tion that we'll be using wired electronic communication channels (as opposed to
optical, wireless, or some other media). Before you dismiss this as an "of course"
kind of assumption, be aware that there are plenty of systems that use either optical
or wireless communications; we make the assumption here simply because we're
exploring the options available on the dsPIC DSC.
The key criteria that we'll use when making our communication decisions are:
1 . the required sustained (as opposed to burst) channel throughput, expressed
in bits per second;
2. whether the link is point-to-point (i.e., between only two devices) or whether
it is a multidrop link (i.e., more than two devices on the same link);
3. the physical length and the electrical noise level of the communication
link;
4. whether the communication link needs to be synchronous, asynchronous,
or can be either;
5. the need for hardware-based error detection.
Learning to be a Good Communicator 101
Let's look at each of these criteria in detail before exploring the communication
options available to us on the dsPIC DSC.
Channel Data Throughput
One of the most important communication-channel characteristics is the channel's
data throughput — i.e., the amount of data that it can transfer in a given period of
time. There are two principal types of data throughput, burst throughput and sustained
throughput, and it's important both to understand the difference between the two
terms and to know which one is the constraining factor for a particular application.
Burst throughput is the fastest data rate that the channel can support for small quan-
tities (bursts) of data. Knowing the burst throughput rate by itself is insufficient;
the designer must also know the maximum amount of data that can be transmitted
at that rate. While a channel's burst throughput may be exceptional, that mode of
operation may not be an option if it can't transfer large enough packets of data to
meet the needs of the specific situation. In contrast, the sustained throughput is the
maximum data rate at which the channel can communicate data continuously. This is
generally a better measure of the channel's data-carrying capacity, although it may be
significantly lower than the burst throughput rate because the sustained rate reflects
a guaranteed transfer speed that is independent of the amount of data to be sent.
In our sensor designs, we will focus on a channel's sustained data throughput,
although we will note cases in which burst-mode operation may be appropriate.
Point-to-Point vs. Multinode Networks
Communication systems fall into one of two categories. Systems that employ a
point-to-point topology 1 have essentially two nodes that transfer data between each
other, as shown in Figure 4.1. Although it is possible to have in-line repeaters that
receive from one node and transmit to another, the key is that for each link there
is only one transmitter/receiver pair for each direction of transmission. This makes
life relatively easy for the designer because she does not have to be concerned with
scheduling data transmission access to the link since there is only one transmitter.
In addition, using a point-to-point topology greatly simplifies the termination of
data cables, a requirement for long links.
The primary disadvantage of point-to-point systems is their limited ability to
share data with other systems. It's hard to get the word out when you're talking to just
one other person, which is one reason that many systems use a multidrop topology
in which more than two nodes are connected together via a single communication
channel, as shown in Figure 4.2. With this approach, it's possible to talk to all of
the nodes at once from a single node, or to establish communications between two
or more nodes. Note, however, that although we can have many nodes listening
102 Chapter 4
at one time, only a single node can actually transmit data, which raises one of the
topology's biggest challenges: how to schedule transmissions from individual nodes
so that two or more nodes don't try to send data at the same time.
Point -to-Point Network
These two channels
together form one comm
ink
r
Node 1
><
Data from Nodel to Node 2
r
Data from Node2 to Node 1
"\
Node 2
These two channels
together form a
second comm link
Node 3
Figure 4. 1. Point-to-Point Communication Network
Multi-drop Network
These two channels
together form a third
comm link
r
■\
Node 1
V
"\
Node 2
r
Node 3
V
Transmit
A
*
Receive
Transmit
A
i
Receive
Transmit
A
i
Receive
Data Bus
Data bus provides a single
communication link between
all nodes
Figure 4.2. Example Multidrop Network
One of two approaches is commonly taken to overcome the difficulty of trans-
mission collisions — i.e., those occasions when more than one transmitter is trying
to send data at the same time. The first approach tries to avoid collisions altogether
by passing around a software or a hardware token that tells an individual transmitter
Learning to be a Good Communicator 103
when it is safe to send data. When a transmitter has the token, it may transmit any
data it has and then passes the token to the next node in the network. Should a node
receive the token but have no data to transmit, it simply passes the token to the next
node without taking any other action. Although this method avoids collisions, it does
so at the expense of the additional software and/or hardware required to sequence
the token through the network, and there may be (relatively) long periods of time
in which the token is being passed among nodes with no data to send while a node
that does have data to transmit waits to receive the token.
The second approach uses a somewhat different technique. Rather than trying
to avoid collisions, it allows collisions to occur but detects them quickly and reli-
ably and then tries to reschedule at least one of the offending transmitters to send
its data later, presumably after the dominant transmitter (i.e., the one that gets to
transmit) has finished sending its data. This can substantially improve throughput
in networks in which individual nodes need to transmit data on a nonperiodic basis
since it allows the nodes to attempt to transmit immediately rather than having to
wait their turn. Of course, the rescheduling algorithm in the second approach needs
to ensure that all nodes eventually get transmission access to avoid the possibility
that a node is perpetually held off from sending its data.
Physical Properties of the Data Link
Physical properties of the data link, such as its length and the electrical noise level
of the environment in which it operates, limit the maximum transfer speed and
may mandate the use of special circuitry to adequately drive the electronic signals,
to detect error conditions, or both. We can overcome these problems to a certain
extent by using high-drive capability differential signals, but the additional power
requirements and financial costs may be more than a particular application can sup-
port. As one might expect, the longer the link or the noisier the environment, the
more slowly the data must be transmitted in order to be received reliably.
Asynchronous vs. Synchronous Data Transfer
In general, data can be transmitted either synchronously with an accompanying clock
signal or asynchronously, without an accompanying clock signal. As always, there
are trade-offs to either technique; the choice of the appropriate method is situa-
tion-dependent.
The advantage of synchronous data transfer is that the transmitter can generate
a clock signal that tells the receiver precisely when to sample the incoming data in
order to determine whether that data is a logical "0" or a logical "1" (assuming, of
course, that we're dealing with binary data). This greatly simplifies accurate data
104 Chapter 4
detection at the receiving end and ensures that communications are always sequenced
properly, but it comes at a heavy cost. Not only must the data link support an addi-
tional clock signal (or two, if the clock is sent differentially), but it becomes critical
that the clock signal be kept very clean since any significant "glitch" on it may be
interpreted erroneously as a clock transition. Even worse, the clock signal usually
must have sharp edges in order to clearly identify the associated data-bit value, which
generates high-frequency noise that may exceed legal limits. An example of a simple
synchronous signaling scheme is shown in Figure 4.3.
Sample Synchronous Data Transfer
Activation of /SELECT
starts the data transfer
Deactivation of /SELECT
ends the data transfer
/SELECT
CLOCK
Each data bit is
transferred on the rising
edge of the clock
ru 7 u^u 7 u^YJ 7 u T u^\
DATA Don't Care Y D7 Y D6 Y D5 Y D4 Y D3 Y D2 Y D1 Y DO Y Don't Care
A A A A A A A A A
Key Points
1 . The CLOCK signal synchronizes the transfer of data by ensuring
that the data is clocked out of the transmitter and into the receiver
by the same signal.
2. The /SELECT signal is used to qualify data transfers , i.e., to
identify legitimate data transfers. Without this transfer qualifier,
glitches on the CLOCK signal could initiate an erroneous transfer
of data.
3. The clock polarity and phase in the diagram are for illustrative
purposes and may be different in actual implementations. In
addition, the signaling scheme may be more complex than
indicated here. For example, many synchronous data transfer
standards employ separate Data Receive and Data Transmit
signals to allow the simultaneous transfer of data in both directions
Figure 4.3. Sample Synchronous Signaling Scheme
Given all of these problems, one might be tempted to assume that asynchronous
transfer is a superior approach, and often that is true. The great advantage of an
asynchronous link is that it requires no external clock signal; the clock required to
decode the incoming bits is contained in the data itself, neatly eliminating both the
troublesome problems associated with an external clock and the cabling required
for that signal. By now the reader is fully aware that such great good fortune usually
Learning to be a Good Communicator 105
comes at a price, and this is no exception. Accurate recovery of the clock embed-
ded in the data stream requires the synchronization of a high-speed clock at the
receiver (on the order of four to sixteen times that used to generate the data) with
the incoming data stream, mandating special hardware and effectively restricting
the upper limit of the transfer speed to a value less (often substantially less) than
that achievable in a synchronous system. Figure 4.4 illustrates what an asynchronous
signaling scheme might look like.
Sample Asynchronous Data Transfer
Transition of the DATA line from
the Idle State (high) to the Active
State (low) for one bit period
(known as the Start bit) begins
the data transfer
After all bits have been sent,
the DATA line returns to the
Idle State for at least one bit
period (known as the Stop bit)
to conclude the transfer
Internal timer in the transmitter controls the
bit period. Receiver's internal timer recovers
the bit value based on the start of the data
transfer.
DATA Idle State \ Start / D7 Y D6 Y D5 Y D4 Y D3 Y D2 Y D1 Y DO
\ A A A A_ A A A A
Y Stop I Idle State
Key Points
Both the transmitter and the receiver maintain closely matched
internal clocks that are synchronized by the falling edge of the Start
bit. If the frequencies of the two clocks are too different, the
receiver will sample the data line at incorrect times and will report
erroneous data .
Synchronization of the data stream is further enhanced by requiring
that the DATA line have known starting and ending states (denoted
here by the Start and Stop bits ). Any transfer that doesn't meet
these minimal requirements can be flagged as invalid.
Further error detection and possibly error correction capabilities
can be included by the addition of extra data bits in the stream
whose states are determined by the value of the specific data
being transferred. If the receiver determines that the extra bit
values it read do not match those expected for the given data, the
receiver can flag the transfer as invalid. When used for error
detection, such extra bits are commonly referred to as parity bits.
Specific aspects of the example, including the levels of the DATA
line used to identify particular states and the order of data bits, are
for illustrative purposes and may differ in actual implementations.
In addition, the signaling scheme may be more complex than
indicated here. For example, many asynchronous data transfer
standards employ separate Data Receive and Data Transmit
signals to allow the simultaneous transfer of data in both directions.
Figure 4.4. Sample Asynchronous Signaling Scheme
106 Chapter 4
Hardware Error Detection
In any communication system, it is a given that errors will occur no matter what
precautions are taken to avoid them. That being the case, it is incumbent upon the
designer to build into the system ways in which such errors at least can be detected,
if not corrected, so that erroneous data doesn't cause undesirable system operation.
Depending upon the speed of the data link, it may be possible to perform this error
detection in software, albeit at the expense of added processing overhead.
In some cases, however, the link speed or reliability requirements may require the
use of hardware-based error detection to ensure proper communications between
transmitter and receiver. Unfortunately, such hardware-based solutions tend to be both
complex and expensive in terms of board space and cost unless they are incorporated
into standard communication devices that can be produced in quantities high enough
to amortize the development and production costs associated with the specialized
circuitry. As we'll soon see, the dsPIC DSC includes at least one communication inter-
face, the Control Area Network, that meets these criteria and offers the high degree of
communication link reliability that hardware error detection can provide.
4.2 Communication Options Available
on the dsPIC30F
The dsPIC DSC offers a broad variety of interfaces that allow it to communicate
with other devices on the same printed circuit board or with remote systems. These
interfaces include:
1. the Synchronous Peripheral Interface (SPI),
2. the Inter-Integrated Circuit (PC) interface,
3. the Universal Asynchronous Receiver/Transmitter (UART),
4. the Controller Area Network (CAN) interface.
We will look at the SPI, the UART, and the CAN interfaces in detail. The PC
interface uses many of the same principles as the SPI, so it is not addressed here.
The Serial Peripheral Interface (SPI) Port
The Serial Peripheral Interface, or SPI as it is more commonly called, is a synchro-
nous serial interface that is designed primarily to transfer data between devices that
are all located on a single printed circuit board (PCB), although it can be used to
communicate between PCBs as well. The interface is fairly simple, consisting of a
Serial Data Out (SDO) signal, a Serial Data In (SDI) signal, a Serial Clock signal
(SCK), a Chip Select (CS) signal, and a Slave Select (SS) signal. All of these signals
are single-ended digital signals, one of the reasons that the SPI is not well-suited
Learning to be a Good Communicator 107
to long data links or noisy environments. Because it is so easy to implement and
troubleshoot, many devices, both microprocessors and peripheral chips, employ
the SPI. For example, the dsPICDEM board uses one of its two SPI ports to com-
municate with the on-board temperature sensor, sending configuration data to the
sensor and reading temperature and status values from it.
Over the years, the SPI has evolved to support four basic modes of operation
(imaginatively denoted Mode 1 , Mode 2, Mode 3, and Mode 4), that operate in basi-
cally the same manner but which employ different timing relationships between the
SCK clock edge and the SDO and SDI data signals to determine when to transmit
data and when data is valid at the receiver. Most devices support only a subset of
these modes, so it's important to make sure that both the transmitting and receiving
device are able to support at least one common operating mode. Figure 4.5 shows
the four possible SPI operating mode combinations. In our examples, we will use
Mode since it is one of the more common configurations.
CKP
CKE
1
1
1
1
SCK
SDO
SCK
SDO
SCK
SDO
SCK
SDO
SPI Mode Combinations
Bit 7
Bit 6
Bit 5
Bit 4
Bit 7
Bit 7
Bit 7
Bit 6
Bit 5
Bit 6
Bit 5
Bit 6
Bit 5
Bit 4
Bit 4
Bit 4
Bit 3
Bit 3
Bit 3
Bit 3
Bit 2
Bit 2
Bit 2
Bit 2
Bit 1
Bit 1
Bit 1
Bit 1
BitO
BitO
BitO
BitO
SPI Mode
SPI Mode 1
SPI Mode 2
SPI Mode 3
Figure 4.5. The Four SPI Operating Mode Combinations
The Microchip 16-bit Peripheral Library does a good job of implementing a use-
ful framework of functions to control and access the SPI ports on the dsPIC DSC.
Unlike the interfaces for the UART and the CAN bus that we'll look at shortly,
the SPI is usually used to transfer small, often byte-size or word-size chunks of
data. Because its transfer rate is so high, this means that we can essentially treat the
transfers as in-line operations that are completed in real-time as the code that uses
108 Chapter 4
them executes. For instance, if we're reading two bytes of temperature data from a
sensor connected via the SPI, often we can afford to issue the request and wait for
the response since the data transfer will not significantly slow our operation. This is
not the case when transferring large amounts of data through other communication
ports (or even through the SPI); generally, we have to implement a buffered, inter-
rupt-driven framework to deal with that situation. Fortunately, the Microchip 1 6-bit
Peripheral Library already has all of the functionality we need to use the SPI port.
To use the SPI port, we first have to configure the associated dsPIC module,
setting the data transfer rate, the clock polarity, the clock phase (these last two
essentially set the operating mode), and the interrupt priority.
The Universal Asynchronous Receiver-Transmitter (UART)
While the SPI and the PC interfaces are both synchronous interfaces, the Universal
Asynchronous Receiver-Transmitter, or UART, not surprisingly uses an asynchro-
nous link. The UART is probably the most ubiquitous means of communication,
at least between computers, with the best example being the trusty RS-232 serial
port that until recently was a standard part of any personal computer. It turns out
that RS-232 serial ports are also widely used in industrial systems as well and were
one of the earliest widely-used standard interfaces, along with their close cousins,
the RS-422 and the RS-485 interfaces, which are essentially differential versions of
the same basic interface. In fact, the "U" in UART reflects the "universal" nature
of this form of communication.
UART-based devices can operate in either point-to-point topologies or in
multinode topologies provided that additional driver circuitry is included that
can disable each node s transmitter. The minimum number of signals required for
UART communications is about as simple as it gets: a Receive Data (RxD) signal,
a Transmit Data (TxD) signal, and a ground signal to which to reference the other
two lines. In practice, the RxD signal at one node is connected to the TxD signal
at the other node, and vice versa. As we've already discussed, asynchronous links
embed the clock signal in the transmitted data, or they at least offer some way in
which the receiver can synchronize its high-speed internal clock with the incoming
data stream so it can extract the correct data bit values. For a UART-based interface,
this synchronization is performed by insertion of a Start bit value at the beginning of
each data byte value. The data itself follows next, starting with the least significant
bit (LSB) and finishing with the most significant bit (MSB). Following the data is
an optional parity bit, and a stop period that is 1, 1.5, or 2 bit periods long. Figure
4.6 illustrates a sample data transmission.
Learning to be a Good Communicator 109
Sample UART Data Transfer
Stop bit may be 1, 1 .5, or 2 standard bit periods in length
Parity bit is optional
Data bits proceed from least significant bit
(LSB) to most significant bit (MSB)
DATA Idle State \ Start / DO Y D1 V D2 Y D3 Y D4 Y D5 Y D6 ]f
\ A A A A A A A A.
D7
Parity
Y Stop
Idle State
I
Key Points
1 . UART data transfers are characterized by
A. Bit rate- number of bits per second
B. Parity type- the manner in which the parity bit is generated
C. Data size - number of data bits per transfer
D. Number of stop bits
2. The bit rate, sometime erroneously referred to as the baud rate,
determines the width of each data bit and is specified as the
number of bits per second that the channel can transfer. Some
common bit rates are 9600, 19.2K, 38.4K, 57. 6K, and 115.2K bps.
Although there is no requirement to use these transfer speeds (as
long as both the receiver and the transmitter employ identical bit
rates), failure to do so may prevent a system from communicating
with other systems.
3. There are three types of parity: even, odd, and none. Even parity
will set the Parity bit to1 if the data itself (not including overhead
bits such as the start or stop bits) contains an even number of bits
that are set and clears the Parity bit to if the data contains an odd
number of bits that are set.
Odd parity sets the Parity bit to 1 if the data contains an odd
number of bits that are set and clears it to if there are an even
number of bits set.
If a parity type of None is selected, the parity bit is not included in
the data stream.
4. The data size may be either 8 bits or 9 bits, but the use of 9-bit
data requires additional software overhead to generate and
process.
5. The length of the Stop period , commonly referred to as the number
of Stop bits, may be either 1 , 1.5, or 2 standard bit periods.
Although low -speed data transmissions in which individual data
transfers are sent infrequently may tolerate a mismatch in the
number of data bits configured in the transmitter and in the
receiver, at higher rates the mismatch will cause data transfer
errors .
Figure 4.6. Sample UART Data Transmission
Note that the idle state for the RxD line is high; the Start bit takes the line from
its idle state to ground to signal the receiver that data will follow. This causes the
UART to start its internal bit timing clock and the hardware state machine that
identifies the time at which to sample the incoming data stream for each bit. Obvi-
ously, both ends of the link must be configured to run at the same transfer speed or
110 Chapter 4
the receiver's sampling circuitry will attempt to read the individual bit values at an
incorrect time, producing invalid data at the receiver.
The optional parity bit can be used for basic transmission error detection,
although many applications choose to ignore it. When it is employed, the value of
the parity bit is set by the transmitter, and the receiver should verify that the parity
bit value it detects is appropriate for the data sent. There are three parity configura-
tion options:
1 . None — no parity value is generated by the transmitter nor is that bit period
used;
2. Even — when set, the number of " 1 " bits in the data itself is even, and when
cleared, the number of " 1 " bits in the data is odd; and
3. Odd - when set, the number of "1" bits in the data itself is odd, and when
cleared, the number of " 1 " bits in the data is even (essentially the opposite
of even parity).
Because its usage imposes additional software overhead on the system, parity
should only be employed when it will be verified at the receiving end. This can be
particularly useful in high-noise environments in which there is a likelihood that
data may be corrupted.
Finally, the stop bits at the end of the data byte are important because they ensure
that the line goes to the idle state for a sufficient length of time for the receiver's
synchronization hardware to reset. Typically, data links try to operate with as few stop
bits as possible to increase throughput, but noisy environments or nodes that require
a little extra time to process the received data may require additional stop bits.
UARTs work particularly well in links that need run longer distances than just
between two PCBs, although they work well for that purpose, too. Typical maxi-
mum lengths for single-ended RS-232 links are around 15 meters, but differential
RS-422 and RS-485 links are rated up to 4,000 meters. Speeds for UART interfaces
are typically between 300 bps and 115 Kbps.
A Basic UART Interface Framework
The code for the UART interface is found in the file CommlF . c, with prototypes
and associated definitions given in CommlFDef . h. Implemented as a buffered,
interrupt-driven framework, the interface supports the transmission and reception
of data from circular receive and transmit buffers maintained by the application.
By using a buffered interface, the framework frees the application from the need to
block on the transmission or reception of messages that are longer than the UART's
Learning to be a Good Communicator 111
internal 4-byte receive and transmit buffers, a feature that is mandatory in time-
critical systems. In addition, the interface allows the designer to use either UART 1
or UART 2 when operating on a dsPIC DSC that supports two UART ports.
To use the interface, the application must first initialize the desired communica-
tion port by calling the routine Commlni t ( ) with parameters specifying the port to
initialize and its associated operating parameters (speed, type of parity, and number
of stop bits). Since the function initializes the global state variables used to control
the interface as well as configuring the UART hardware, failure to invoke the routine
before using the other UART interface functions will cause erratic behavior. The
code for Commlni t ( ) is shown in Example 4.1.
Code Example 4.1. The Commlni t ( ) Function
I
**********************^
FUNCTION
Commlnit (Uint8 ui8Port, Uintl6 uil6BaudRate,
Uintl6 ui 16 Parity, Uintl6 uil6StopBits)
DESCRIPTION
*
*
*
*
*
This function configures the system's communication
channel (s). It must be customized for the specific
communication modules and channel parameters used
for the particular application.
■k
■k
■k
The function uses the global system communication *
configuration parameters; if any of these parameters *
are invalid, it uses the default channel parameters *
to ensure that the communication channel is at least *
operational . *
*
*
-k
NOTE: Although the dsPIC hardware allows 9-bit
data, this routine only supports 8-bit data
since that is more commonly used and is
easier to manipulate.
■k
-k
•k
-k
-k
PARAMETERS
ui8Port
uil6BaudRate
uil6Parity
- index of UART port to configure *
(MUST be either UART_1 or UART_2 ) *
- communication baud rate in bits/sec *
- type of parity to use (MUST be one *
of PARITY_*) *
uil6StopBits - number of stop bits (MUST be either *
ST0P_BITS_1 or ST0P_BITS_2 ) *
RETURNS :
The function returns one of the following status
112 Chapter 4
code values
ST OK
ST INV PARM
ST COMM INIT
- operation successful
- invalid communication parameter
detected, default channel
parameters used
- failed to initialize the requested
communication channel (s)
REVISION:
vl.O
Original release
DATE: 18 May 2006
**********************
/
Uintl6
Commlnit (Uint8 ui8Port, Uintl6 uil6BaudRate, Uintl6 uil6Parity,
Uintl6 uil6StopBits)
{
// Local Variables
Uintl6
uil6BRGValue,
uil6Mode,
uil6Status;
// Baud Rate Generator value
// Configuration data for UxMODE register
// Configuration data for UxSTA register
// Log the UART that we're using
// for the communication port
g_ui8CommPort = ui8Port;
// Turn off the specified UART module and
// disable the associated interrupt so we
// can complete the initialization without
// interruption
if (ui8Port == UART_2 )
CloseUART2 () ;
// Close UART 2
else
CloseUARTl ( ) ;
// Close UART 1
// Compute the Baud Rate Generator value based
// on the system instruction cycle frequency
// and the desired baud rate. From the 3 0F6014A
// data sheet, the BRG value is computed as
Learning to be a Good Communicator 113
// BRG = ( (FCY / baud rate) / 16) - 1
/ / where
// FCY = instruction cycle frequency in Hz
// baud rate = desired baud rate in bits/sec
uil6BRGValue = ((FCY / uil6BaudRate) / 16) - 1;
// Setup the UxMODE register value to specify
// whether the UART is enabled, how it will handle
// the IDLE state, and other configuration data
uil6Mode = UART_EN & // Enable the UART
UART_IDLE_CON & // Stop the UART when in the IDLE state
UART_DIS_WAKE & // Don't enable UART Wake on Start
UART_DIS_LOOPBACK & // Disable loopback mode
UART_DIS_ABAUD; // Don't use Auto-baud mode
// Add the appropriate configuration information
// for the number of data bits and parity to employ
switch (uil6Parity)
{
case PARITY_EVEN:
uil6Mode &= UART_EVEN_PAR_8BIT; // Even parity, 8 data bits
break;
case PARITY_ODD:
uil6Mode &= UART_0DD_PAR_8BIT; // Odd parity, 8 data bits
break;
default :
uil6Mode &= UART_N0_PAR_8BIT; //No parity, 8 data bits
break;
}
// Add the appropriate configuration information
// for the number of stop bits to use
if (uil6StopBits == ST0P_BITS_2)
uil6Mode &= UART_2ST0PBITS; // Use 2 stop bits
else
uil6Mode &= UART_1ST0PBIT; // Use 1 stop bit
114 Chapter 4
II Setup the UxSTA register value to specify
// how the transmit and receive interrupts
// will be generated and other processing
// control configuration
uil6Status = UART INT TX
&
UART TX PIN NORMAL &
UART TX DISABLE
UART INT RX CHAR
&
&
UART ADR DETECT DIS &
UART_RX_OVERRUN_CLEAR ;
// Interrupt on Tx register
// Use normal Tx pin state (not
//
transmitting a break)
// Disable the transmitter for now
// Interrupt on character reception
// Don't use Address Detect mode
// Clear the UART Rx Overrun flag
// Initialize the global state variables
// associated with the communication channel
g_uil6CommRxAppIndex = ;
g_uil6CommRxISRIndex = 0;
// Initialize the app-side Rx buffer index
// Initialize the ISR-side Rx buffer index
memset (g_ui8CommRxData, 0, COMM_RX_BUFF_SZ) ; // Initialize Rx buffer data
g_uil6CommTxAppIndex = 0;
g_uil6CommTxISRIndex = 0;
// Initialize the app-side Tx buffer index
// Initialize the ISR-side Tx buffer index
memset (g_ui8CommTxData / 0, COMM_TX_BUFF_SZ) ; // Initialize Tx buffer data
// Actually initialize the appropriate UART
if (ui8Port == UART_2 )
{
Conf igIntUART2 (UART_RX_INT_EN & UART_RX_INT_PR6 & // Enable Rx interrupt
UART_TX_INT_DIS & UART_TX_INT_PR3 ) ; // and disable Tx int
OpenUART2 (uil6Mode, uil6Status, uil6BRGValue) ; // Open UART 2
}
else
{
Conf iglntUARTl (UART_RX_INT_EN & UART_RX_INT_PR6 & // Enable Rx interrupt
UART_TX_INT_DIS & UART_TX_INT_PR3 ) ; // and disable Tx int
OpenUARTl (uil6Mode, uil6Status, uil6BRGValue) ;
}
// Open UART 1
return uil6Status;
}
Learning to be a Good Communicator 115
Once the communication interface has been initialized by Commlnit ( ) and
the interrupt level on the dsPIC DSC has been set low enough to allow interrupts
from the serial port (interrupt level 6), the application can write and read data
to and from the selected UART. To read data from the initialized serial port, the
application first checks to see whether there is data pending in the global Receive
Data queue by calling CommGetRxPendingCount ( ) , which returns the number
of unread received data bytes pending in the Receive Data queue. If this value is
nonzero, indicating that there is data available to read, the application then reads the
next pending character from the queue by calling the function CommGetRxChar ( ) .
Figure 4.7 shows the flow chart illustrating this sequence.
Yes
CommGetRxChar(&ui8NewData)
No
End
Figure 4.7. Flow Chart for Reading UART Data in the Application
Assuming that the CommGetRxChar ( ) routine returns a status code value of
ST_OK, the application can safely use the data read from the UART. If, however,
the status code value is not ST_OK, the application should not use the data in
ui8NewData, since it will not be valid.
Transmitting data is also a simple matter. Assuming that the communication
interface has been initialized by calling CommInit(), the application uses Com-
mPutChar ( ) and CommPutBuf f ( ) to transmit either a single byte of data or
multiple bytes of data, respectively. A quick look at the code shows that Com-
mPutBuf f ( ) simply calls CommPutChar ( ) repeatedly to load the entire source
data contents into the circular transmit buffer, but an examination of the code for
CommPutChar ( ) (shown in Code Example 4.2) is instructive.
116 Chapter 4
Code Example 4.2. The CommPutChar ( ) Function
I
********************************
FUNCTION:
CommPutChar (Uint 8 ui8Data)
DESCRIPTION: This function adds a character to the global
Transmit Data buffer for subsequent transmission
by the UART's Transmit Data interrupt handler.
If the buffer is full, the character is not added
to the buffer, and the function returns an error
status .
PARAMETERS
ui8Data - data to be added to the transmit data
buffer for transmission by the USART
RETURNS :
The function returns one of the following status
code values :
ST OK
- operation successful
ST_BUFFER_FULL - transmit buffer full, data not
added for transmission
REVISION:
vl.O
DATE: 18 May 2006
Original release.
**************************************************************************
/
Uintl6
CommPutChar (Uint8 ui8Data)
{
// Local Variables
Uintl6
ui 1 6AppIndex ,
uil6DataCount ,
uil6Status;
// Temporary buffer for processing the
// application index for the transmit
//
data buffer
// Number of characters currently in
//
the transmit data buffer
// Function execution status
// Check whether there is room in the
// transmit data buffer for the new data
uil6Status
= ST_BUFFER_FULL ; // Assume the transmit buffer is full
uil6DataCount = CommGetTxBuff Count () ;
//
/ / Get the number of characters already
in the transmit data buffer
Learning to be a Good Communicator 117
if (uil6DataCount < (COMM_TX_BUFF_SZ - 1))
{
// We do have room in the buffer,
// so add the new character to it
g_ui8CommTxData [g_uil6CommTxAppIndex] = ui8Data; // Add the new
character
// Modify the application-side index to point
// to the next character in the transmit buffer.
// Use a local variable to do the manipulations
// and then transfer value to the global state
// variable in one operation to prevent coherency
// problems with the ISR.
uil6App!ndex = g_ui 16 CommTxApp Index ;
uil6App!ndex++ ;
// Get the current
application index
// Move to the next slot
uil6App!ndex &= (COMM_TX_BUFF_SZ - 1) ; // Perform a rapid modulo-
//
//
//
COMM_TX_BUFF_S Z
calculation
(assumes that COMM_TX_
BUFF_SZ
is a power of 2)
// Update the state variable that controls
// access to the global Transmit Data queue
g_ui 16 CommTxApp Index = ui 16 App Index;
// Make sure that the hardware can and will send
// the data. Since the data is actually loaded
// into the UART's Transmit Buffer in the ISR,
// we need to make sure that the ISR is called
// if the Transmit Buffer has room. If there is
// no room in the UART's Transmit Buffer, we don't
// need to generate an interrupt at this time (the
// new data has already been added to the global
// Transmit Data queue and will be loaded into the
// UART's Transmit Buffer at a later interrupt,)
CommEnableTransmitter ( ) ;
// Make sure the transmitter is enabled -
//
must occur FIRST
118 Chapter 4
if (CommTxBuff Avail ( ) )
CommForceTxInt ( ) ;
// UART's Transmit Buffer has room so
//
//
//
//
//
force a Transmit interrupt. This
must be performed BEFORE making sure
that the UART's Transmit interrupt
is enabled to avoid a race condition
with the Transmit Data ISR.
CommEnableTxInt ( ) ;
// Finally, ensure that the UART's
//
Transmit
interrupt is enabled
// Flag that the operation was successful
uil6Status = ST_OK;
}
return uil6Status;
}
The Controller Area Network (CAN)
The Controller Area Network is the probably the most sophisticated of the serial
interfaces offered on the dsPIC DSC. It incorporates a very advanced internal hard-
ware controller that supports moderate speed (up to 1 Mbps) data transfers with
built-in hardware error detection, a sophisticated message prioritization scheme,
and the ability to set filters that allow only messages of interest to be received, all
with very little processor overhead. Widely used in the automotive and industrial-
processing world, the CAN architecture offers a robust way to link together multiple
nodes on a single network.
With all of these positives, why would anyone not use the CAN interface? There
are two main reasons: complexity and cost. One big advantage of CAN is that it's
highly configurable, but one big disadvantage is that CAN is so highly configurable.
Because it's so flexible, a CAN topology can be used in a wide variety of applica-
tions using basically the same hardware. Unfortunately, that flexibility must be
configured fairly precisely or the channel will be either unreliable or completely
unusable, and debugging problems with the channel can be both time-consuming
and frustrating.
Learning to be a Good Communicator 119
Basic CAN Architecture
Developed by Bosch in the early 1980s, the CAN architecture is pretty simple.
Although the CAN standard itself is intentionally media-neutral, 2 one of the most
common implementations uses a single differential serial bus running at 1 Mbps 3
or less to connect two or more nodes together. Along with the associated ground
signal, a reliable interface can consist of only three wires!
The CAN's communication protocol is a member of the CSMA/CD family, a
cryptic acronym that stands for Carrier Sense Multiple Access/Collision Detection.
Although the family name is long, the concepts behind it are easy. In a carrier sense
system, all nodes have to monitor the network for a period of inactivity before they
can attempt to send a message. Once this inactive period has elapsed, however, any
of the nodes in the network can transmit data, hence the term multiple access. As
one would expect, there will be times when two or more nodes try to send data at
the same time, a condition known as collision, so the network has to have some way
to perform collision detection. Individual members of the CSMA/CD family handle
these tasks differently, but all members of a given type (such as CAN) do so in the
same manner.
Of these tasks (carrier sensing and collision detection), the more difficult by far
is collision detection. The CAN designers came up with an ingenious solution to
this problem, one that allows the system designer to prioritize message traffic so
that more important messages are always able to gain access to the bus ahead of
less important messages (in much the same way that interrupts are prioritized by
the dsPIC DSC). Not only does the CAN allow message prioritization, its network
arbitration* scheme is nondestructive 5 to the higher priority message and ensures
that the higher priority message experiences no transmission delay. Since message
arbitration is so important, we'll look at that in detail after we first get some more
background information under our belt.
Another of the CAN's key features is its built-in error-detection circuitry that
flags problems with the bus and that will gradually remove an individual network
node from the bus should the node generate too many errors. Although the protocol
does not support error correction, its error-detection feature helps avoid the serious
problem of a single erroring node bringing down the entire network. Unfortunately,
because errors can accumulate quickly when there is a problem, tracking down the
source of the problem can be difficult since it may go away once the node stops
trying to transmit.
120 Chapter 4
If all of this functionality sounds as though it imposes a severe load on the
processor, you can relax; because of its complexity the vast majority of the CAN
interface is contained in two hardware components: a CAN controller state machine
that handles all of the arbitration and error detection and a CAN bus driver that
drives and monitors the CAN bus physical medium. In most systems, these two
hardware components are housed in individual integrated circuit (IC) packages. 6
This is the case with the dsPIC DSC, which contains either one or two CAN con-
troller modules on-chip (depending upon the dsPIC device) and which requires an
external CAN driver chip to connect to the bus. Once the CAN interface circuitry
has been configured, it simply presents fully formed data messages and status bits
to the receiver and transmits complete data messages to other nodes. Since all error
detection and handling is performed in hardware, the processor overhead associated
with the CAN interface is minimal.
One last high-level consideration is just how far one can run a CAN bus, and
the answer is that the maximum bus length depends upon the data rate that the
bus must support. Table 4.1 shows the recommended maximum bus lengths for a
variety of bit rates. 7
Bit Rate (Kbps)
Bus Length (m)
1,000
30
500
100
250
250
125
500
62.5
1,000
Table 4.1. Recommended Maximum CAN Bus Lengths
As the table clearly demonstrates, the maximum bus length drops off rapidly
with increasing data rates, but even at 1 Mbps (1,000 Kbps), the maximum bus
length is reasonably robust.
CAN Data Formats
According to the CAN 2.0 specification, 8 data sent over the CAN bus is in one of
four basic data formats, called frames:
1 . the Data frame, which transmits data from one node to all other nodes on
the bus,
2. the Remote Transfer frame, which requests data from another node on the
bus,
Learning to be a Good Communicator 121
3. the Error frame, which reports that a communication error has been detected,
and
4. the Overload frame, which reports that the transmitting node is busy pro-
cessing a previous message and cannot accept more data at this time.
In our example, we will be interested primarily in the most commonly used
format, the Data Frame, which comes in two flavors: the standard frame and the
extended frame. The two data frame formats, illustrated in Figures 4.8a and 4.8b,
are essentially identical, with the only real difference being the shorter arbitration ID
of the standard frame. All data frame formats have the following basic elements:
1 . an Arbitration ID field whose size varies with the frame type,
2. a 6-bit Control Field,
3. a Data Field of to 8 bytes in length,
4. a 2-byte CRC Field,
5. a 2-bit Acknowledge Field, and
6. a 1-bit End of Frame marker.
Of these fields, the user has control over the arbitration ID, the Control, and the
Data fields, while the CAN controller hardware automatically generates and validates
the CRC Field, the Acknowledge Field, and the End of Frame marker. Let's delve a
little deeper into the fields before examining the CAN arbitration technique.
In a standard data frame, the Arbitration ID field consists of an 1 1-bit identifier
and a 1-bit Remote Transmission Request (RTR) flag. The extended data frame
format is slightly different, but it is designed so that if there is a collision between
a standard frame and an extended frame, the standard frame has priority. For an
extended frame, the identifier is 29 bits, with the 1 1 most significant bits being
transmitted after the Start of Frame, followed by a 1-bit Substitute Remote Request
(SRR) flag, a 1-bit Identifier Extension (IDE) flag, and then the remaining 18 bits
of the identifier, with the 1 -bit RTR flag completing the field.
There are also slight differences in the Control Field layout for the two data frame
formats, although it is 6 bits wide in both cases. In the standard frame, the leading
bit of the Control Field is the IDE flag, which is followed by a single reserve bit
denoted as "rO" in the CAN specification. The final four bits of the field comprise
the Data Length Code (DLC), which specifies the number of data bytes that will
follow in the message. Although the DLC is four bits wide, it can only assume a
value of to 8, since the protocol supports a maximum of 8 data bytes per message.
122 Chapter 4
Standard (11 -bit ID) CAN Data Frame Format
(44+ 8N)-bit Data Frame
CD
E
U-
■■*—
O
■e
03
CO
12-bit Arbitration ID Field
6-bit
Control Field
8N-bit Data Field (0? N<8)
16-bit CRC Field
2-bit
Acknowledge Field
7-bit End of
> f Frame
11-bit ID
tr
F
LT
9 a:
4-bit
DLC
8-bit Data Byte
4 // fc
8-bit Data Byte
15-bit CRC
to
-i— ■
"E
ACK Slot bit a
ACK Delimiter i
■^ w
ID10 a
IDO i
DLC3 A
DLCO i
^ w
^ // ^
//
Q
O
VA
1
1
1
1
1
1
1
1
1
Key Points
1 . Each message consists of four main fields and some framing bits:
A. 12-bit Arbitration ID Field
B. 6-bit Control Field
C. 8N-bit Data Field of N data bytes
D. 16-bit CRC Field
The user has control of the first three fields only; the CAN controller
hardware sets the data in the CRC field and the framing bits.
2. A bit value of 1 is considered to be the recessive state, and a bit
value of is considered to be the dominant state.
3. Bus arbitration to determine which node can transmit its message
is based on the value of the Arbitration ID field , with the message
that has the first dominant bit value in the field having priority and
thus being allowed to transmit on the bus. In practice, this means
that the lower the value of the field , the higher the message priority.
4. Standard -format data frames have priority over extended -format
data frames .
Figure 4.8a. Standard CAN Data Frame Format
Extended (29-bit ID) CAN Data Frame Format
(64+ 8N)-bit Data Frame
32-bit Arbitration ID Field
6-bit
Control Field
8N-bit Data Field (0? N < 8)
16-bit CRC Field
2-bit
Acknowledge Field
7-bit End of
y Frame
<->< ►
11-bit ID
co 9
18-bit Extended ID
T- O
CO CO
a: cl
4-bit
DLC
4 ►
8-bit Data Byte
4 ►
«-//-►
-//-
-//-
8-bit Data Byte
< ►
15-bit CRC
CD
■° E
■*— • —
CO Q
o o
< <
Key Points
1. Each message consists of four main fields and some framing bits:
A. 32-bit Arbitration ID Field
B. 6-bit Control Field
C. 8N-bit Data Field of N data bytes
D. 16-bit CRC Field
The user has control of the first three fields only; the CAN controller
hardware sets the data in the CRC field and the framing bits.
2. A bit value of 1 is considered to be the recessive state, and a bit
value of is considered to be the dominant state.
3. Bus arbitration to determine which node can transmit its message
is based on the value of the Arbitration ID field , with the message
that has the first dominant bit value in the field having priority and
thus being allowed to transmit on the bus. In practice , this means
that the lower the value of the field, the higher the message priority .
4. Because of the bus arbitration scheme and the fact that the 0-
valued (dominant) RTR bit of a standard data frame is aligned with
the 1 -valued (recessive) SRR bit of an extended data frame,
standard data frames always have priority over extended data
frames.
Figure 4.8b. Extended CAN Data Frame Format
Learning to be a Good Communicator 123
Because the extended frame includes the IDE flag as part of the Arbitration ID field,
it has two reserved bits in the Control Field, "rl" and "rO". The DLC is the same as
in the standard data frame and labors under the same restrictions.
The Cyclic Redundancy Code (CRC) field is not of much interest to us as
designers, since it is handled exclusively in hardware and is therefore transparent
to the programmer. For sake of completeness, let us note that the CRC itself is a
15 -bit value, and the CRC field is composed of the CRC value and a 1-bit CRC
delimiter bit.
The final field in a CAN message is the 2-bit Acknowledgement (ACK) Field,
which consists of a leading ACK Slot bit that is set to the recessive state (which
will be defined in the next paragraph) by the transmitting node and then set to
the dominant state by all nodes that receive the message successfully, whether they
actually use the message or not. The final bit in the ACK Field (and the message) is
the ACK delimiter bit, which simply returns the bus to the recessive state to signal
that the transmission is complete.
Although we won't use Remote Transfer frames, Error frames, or Overload frames
in our example, the dsPIC DSC's CAN interface is fully capable of handling these.
Remote Transfer frames are used to request the automatic transmission of data from
a node (the data having been already loaded into the CAN module in anticipation
of the request), and Error frames are generated by a node when it detects an error
condition on the bus. Because Error frames intentionally violate the timing param-
eters of the CAN bus, they cause all of the nodes that were transmitting data to
stop, reset the transmission, and start their transmissions again.
Bus Arbitration
As we've already noted, since data transfers are asynchronous, some sort of access
arbitration is required to determine which node may transmit if two attempt to
send data simultaneously. The CAN designers came up with an ingenious solution
to this problem, creating a nondestructive arbitration scheme that uses the value
of the arbitration IDs of the colliding messages to decide which node has priority.
To understand how this scheme works, we first need to learn two terms that apply
to CAN-based systems. Data on the CAN bus is said to be in either a dominant
state (a logical 0) or a recessive state (logical 1 ) . When two bits of different state are
transmitted at the same time, the dominant state "wins," — i.e., that is the resulting
state on the bus.
The CAN uses this fact for its transmission access arbitration. Whenever two or
more nodes try to transmit a message simultaneously, the dominant bit state is the
124 Chapter 4
one that is present on the bus. As each node transmits data onto the bus one bit
at a time, it checks to see whether the data on the bus reflects the state of the most
recently transmitted bit. If a transmitting node sends a recessive bit but detects that
the bus is in the dominant state, the node knows that there is another node that is
also transmitting, and the node whose data was recessive knows to get off of the line.
The recessive node immediately disables its transmitter and waits until the end of
the current transmission before attempting to transmit its own data again.
By handling the arbitration in this manner, the CAN assures both that there is
a structured approach to transmission access and that collisions don't result in lost
data that forces all nodes to retransmit their messages. Since the dominant state is
0, designers of CAN-based systems select arbitration IDs such that the most impor-
tant messages have low ID values and thus the highest priorities. For instance, by
choosing arbitration ID values of 000H-01FH for alarm conditions and ID values
of 020H-7FFH for normal operating messages, the designer ensures that alarm
messages always have priority over normal operating messages. The example shown
in Figure 4.9, in which an alarm message with an arbitration ID value of 01 OH is
sent at the same time as a normal operating message with an arbitration ID value of
040H, illustrates this. In addition, the scheme allows both standard and extended
data frames to reside on the bus, with the standard frame messages having priority
over the extended data frames.
CAN Message Bus Arbitration
Message 1
Message 2
CD
E
CO
o
■e
CO
CO
1 2-bit Arbitration ID Field
W M
11-bit ID
o
Q
o
Q
DC
I-
CL
First non -matching Arbitration Field bit. Since
message 1 has the dominant value in that bit
position, it has priority.
o
o
Figure 4.9. Example Arbitration of Two Simultaneous Messages
Learning to be a Good Communicator 125
Acceptance Filters
One optional aspect of the CAN protocol that all CAN controllers implement is mes-
sage filtering, which allows the controller to accept only messages whose Arbitration
ID fields match a programmable bit-mapped filter value. In this case, when we refer
to a filter, we're not talking about a digital filter that processes the digitized signal;
rather, we're referring to the process by which only a limited group of messages that
meet certain criteria are selected for processing by the CAN controller. Note that,
even when the controller chooses to ignore the message, it always responds with the
ACK Slot bit set appropriately. Filtering is a midlevel technique by which we can
reduce the overhead on the processor by limiting the types of messages we choose to
handle, while the acknowledgement process is a low-level requirement for ensuring
the accurate delivery of the network traffic to all nodes.
Filtering the CAN messages consists of two steps, both of which are configurable by
the designer but which are executed by the CAN controller hardware. First, we need to
set the acceptance filter values (the dsPIC DSC supports up to six different filters), which
are logically ANDed with the Arbitration ID of each received message on a per-bit basis.
The resulting value is then compared to an acceptance mask on a per-bit basis, and if
the result of applying the filter matches the acceptance mask, the incoming message is
added to the CAN receive buffer (assuming there's room in the buffer) .
This can be a point of significant confusion for new (and sometimes more expe-
rienced) CAN designers, so an example is appropriate. Let's assume that we want to
accept any standard CAN data frame whose Arbitration ID field is in the range of
300H to 3FFH. In that case, the acceptance filter is simply FOOH and the acceptance
mask is also 300H, since ANDing the acceptance filter with the 12-bit Arbitration
ID field of any received message will make the lower byte of the Arbitration ID field
a don't care condition (since the entire lower byte will be ANDed with 0), and the
filter will pass through the upper nibble. Only Arbitration ID fields whose upper
nibbles are equal to 3 will match with the acceptance mask and thus be accepted.
Basic CAN Interface Framework
The Microchip 16-bit peripheral libraries do an excellent job of providing the tools
a programmer needs to interface to the dsPIC DSC's CAN controller (s), but as
in the case of the UART interface, they don't directly implement interrupt-driven
buffered message (not character, since the CAN is a message-based protocol) I/O.
Fortunately, we can simply tweak the code that we developed for the UART, and we
have a similar framework for the CAN interface. This is an excellent example of the
value of writing code that is somewhat generic; since the same basic principles apply
126 Chapter 4
to both the UART and the CAN interfaces, we're able to reuse the same basic code
in the CAN that we developed for the UART (after making the requisite modifica-
tions to account for the differences in the two modules, of course).
4.3 High-level Protocols
So far we've looked at the basic communication channels essentially as I/O mecha-
nisms that transfer data between the dsPIC DSC and other devices, and our focus
has been on the bit- or the byte-level. Even when we talk about the CAN proto-
col, what we're really examining is the low-level hardware interface and the set-up
information required to properly configure it. All of this is necessary, but it's not
sufficient; we also need to define what the data that is transferred actually means,
and thus we turn now to the issue of high-level protocols, or HLPs.
In earlier chapters, we've discussed the need to turn data into information, and
the structure imposed by a high-level protocol allows us to do precisely that. The
situation is analogous to sending a letter from one person to another. In order for
the letter to reach its destination, we have to specify certain information (the recip-
ient's address) and we may add optional information (such as the recipient's name)
depending on the circumstances. Since there may be a problem with the delivery, it's
also a good idea to include information that can be used to report or recover from
the problem (for example, the sender's name and address). This is exactly what we
have to do with the data that we send between nodes in the system, whether those
transmissions are between individual devices like the dsPIC DSC and an external
DAC or whether they are between the dsPIC DSC and remote systems. By imposing
a structure on the data that we transfer, we allow that data to be understood clearly
and processed efficiently.
A number of popular standard protocols are available for serial data and, depend-
ing upon the type of equipment with which the sensor must communicate, the
designer may have no alternative but to implement a particular protocol for the
application. If the protocol is widely used, this approach offers the likelihood (or
at least the possibility) of having available third-party software implementations
that can be dropped into the application and/or tools that can be used to test the
resulting code. The downside occurs when the application only requires a subset
of functionality to accomplish its task, because then the full functionality of the
standard protocol wastes precious processor resources. Sometimes this is the only
option — for example, when one is communicating with another chip via the SPI.
Usually, individual devices have a specific protocol that must be used to communicate
with them, leaving the designer with little or no flexibility.
Learning to be a Good Communicator 127
An alternative approach, and the one employed in this example for communicat-
ing between a host system and the dsPIC DSC, is to create a proprietary protocol
that is tailored to the specific application. Designed appropriately and properly
implemented, a proprietary protocol can offer the required functionality without
wasting resources on features that will never be used by the application; however, it's
always a good idea for the designer to ensure that the application actually requires
(and the development team can afford) the time and resources required to develop
a proprietary solution. 9
If, after looking at the situation objectively, the designer decides that a proprietary
protocol is necessary, one should always try to make it as lightweight, as reliable, and
as extensible as possible. By light-weight, we mean that the protocol should add as
little data and processing overhead as possible while still accomplishing the task in
a reliable manner. Although the concept of reliability is self-explanatory, we also
include error detection as a desirable goal as well. Finally, a protocol's extensibility
refers to the ability to add new message types easily and in a manner that has mini-
mal impact on existing code.
The protocol used in the examples demonstrates one such implementation (there
are others) that balances the need for low processing overhead, error detection, and
extensibility. The reader should understand that this is not the only way, nor perhaps
even the best way, for a specific application; it does, however, work well in a variety
of circumstances. In actuality, there are two protocols at work in these examples: one
protocol that encapsulates the general message and a second that is message-type
specific. Let's start by examining the general message protocol first.
General Message Protocol
The general message protocol is a simple command/ response protocol that has one
primary goal: to deliver variable-length command messages to the target system
and to process the returned variable-length response message. The simple protocol
illustrated in Figures 4.1 1 and 4.12 handles this goal nicely.
Start Token
(1 byte)
Command ID
(1 byte)
Data Length
(1 byte)
Data
(N bytes)
Checksum
(1 byte)
0x01 (SOH)
-
N
-
Calculated
Figure 4. 1 0. General Message Protocol Command Format
128 Chapter 4
For a command,
Start Token
Command ID
Data Length
Data
Checksum
start of command token (ASCII Start of Header, 0x01)
the ID of the command being sent (MSB set to denote a
command)
length of the data associated with the command (N bytes,
where 0<N< 255
N bytes of command data (not used if N== 0)
checksum computed from the Command ID, Data
Length, and all Data bytes
The format for a command response message is shown in Figure 4.12.
Start Token
(1 byte)
Response ID
(1 byte)
Status
(1 byte)
Data Length
(1 byte)
Data
(M bytes)
Checksum
(1 byte)
0x01 (SOH)
-
-
M
-
Calculated
Figure 4.11. General Message Protocol Response Format
where,
Start Token
Response ID
Data Length
start of command token (ASCII Start of Header, 0x01)
the ID of the response being returned (equal to the
corresponding Command ID value but with the MSB
cleared to denote a response)
length of the data associated with the response (M bytes,
where < M < 255, and A^ and M may not be the same)
M bytes of response data (not used if M equals 0)
checksum computed from the Response ID, Data Length,
and all Data bytes
Since one can (and should) assume that errors will occur at some point in the
communication process, the protocol employs a start character to signal the start of
a new transmission and a checksum 10 value to verify that the data received was, in
fact, the same as the data transmitted. This not only offers a degree of error detec-
tion but also the ability to resynchronize the data between the transmitter and the
receiver should an error occur, since the receiver can be looking for the start character.
Although there are many different ways to compute a checksum, the method used
Data
Checksum
Learning to be a Good Communicator 129
in these examples is to add all of the data bytes between (but not including) the start
character and the transmitted checksum value itself, and then to perform a bit-wise
inversion of the summed value. The advantage of inverting the sum rather than
simply using the sum itself is that a long string of Os produces a checksum value of
FFH rather than a checksum of 00H, which forces a differentiation between the
checksum and the data. If there were no differentiation, a signal stuck at would
not be detected since both the data and the checksum values would be as well.
To further identify the commands, the command ID values all have the most
significant bit (MSB) set to 1, and the corresponding responses have the response
ID identical to the command ID but with the MSB cleared. This makes debugging
the communications just a bit easier for the designer, since she can pick out the
command and response messages easily on a data analyzer. It also provides another
way to validate a command message when it is received.
As we've discussed previously, it's important to implement the protocol parser as
a state machine so that we never get into a state from which we cannot recover. This
also keeps us from making too many foolish assumptions, such as "the message will
always be a certain length." While it may be true that the message is supposed to be
a certain length, it's also equally true that there will be times that for some reason
the received data is not the anticipated length, and we can't allow that to then stop
future communications. Figure 4. 13 shows a flow chart of the protocol parsing state
machine that we'll use.
Command-specific Protocols
Each command has its own set of data that it sends to the receiver, and the response
that the receiver reports after processing the command message is command-
dependent as well. Although the specific commands and responses are somewhat
application-dependent, those common to all three applications are shown here to
give the reader examples of such an implementation. Note that the command-specific
protocol does not perform any error checking. It is the responsibility of the general
message protocol to ensure that accurate data is delivered to the receiver; once that
data has arrived, it is assumed to be accurate. Functions that use the parsed data
should, of course, verify that the data is valid in the sense of being appropriate for
the specific task. As an example, if the host sent a temperature setpoint of 1500 °F,
but the maximum allowed setpoint was only 1000 °F, the received value of 1500
°F would be accurate (i.e., would be the value actually transmitted by the sender)
but invalid (not an allowed value for this parameter). Table 4.2 lists the command
message data formats for those messages that are common across of the example
applications, while Table 4.3 lists the corresponding response message formats.
130 Chapter 4
Figure 4. 12. State Machine to Process Protocol
Learning to be a Good Communicator 131
Command ID
Data Length
Parameter Values
0x80
Report release information
0x81
5
Log lower calibration measurement
Parm — 8-bit 0-based sensor index
Parm 1 - 32-bit defined lower calibration
value
0x82
5
Log upper calibration measurement
Parm - 8-bit 0-based sensor index
Parm 1 — 32-bit defined upper calibration
value
0x83
1
Compute calibration gain and offset
Parm - 8-bit 0-based sensor index
0x84
1
Report calibration gain
Parm — 8-bit 0-based sensor index
0x85
1
Report calibration offset
Parm — 8-bit 0-based sensor index
0x86
6
Configure lower limit alarm
Parm — 8-bt 0-based sensor index
Parm 1 — 32-bit alarm limit
Parm 2 - 8-bit alarm enable flag
0x87
6
Configure upper limit alarm
Parm — 8-bt 0-based sensor index
Parm 1 — 32-bit alarm limit
Parm 2 - 8-bit alarm enable flag
0x88
1
Reset alarms
Parm - 8-bit 0-based sensor index
0x89
1
Report alarm states
Parm - 8-bit 0-based sensor index
0x8A
1
Report lower alarm limit
Parm — 8-bit 0-based sensor index
0x8B
1
Report upper alarm limit
Parm - 8-bit 0-based sensor index
0x8C
1
Report sensor value
Parm - 8-bit 0-based sensor index
0x8D
1
Set digital potentiometer value
Parm — 8-bit digital potentiometer value
Table 4.2. Command Message Data Formats
132 Chapter 4
Response ID
Data Length
Parameter Values
0x00
6
Report release information
Parm - 8 -bit release date month
Parm 1 - 8 -bit release date day
Parm 2 - 8-bit upper two digits of release date year
Parm 3 - 8 -bit lower two digits of release date year
Parm 4 — 8-bit major release version ID
Parm 5 — 8-bit minor release version ID
0x01
3
Log lower calibration measurement
Parm - 8-bit 0-based sensor index
Parm 1 — MSB of 2-byte fractional value measured
at calibration point
Parm 2 — LSB of 2-byte fractional value measured at
calibration point
0x02
3
Log upper calibration measurement
Parm - 8-bit 0-based sensor index
Parm 1 - MSB of 2-byte fractional value measured
at calibration point
Parm 2 - LSB of 2-byte fractional value measured at
calibration point
0x03
3
Compute calibration gain and offset
Parm - 8-bit 0-based sensor index
0x04
5
Report calibration gain
Parm - 8-bit 0-based sensor index
Parm 1 - MSB of MSW of 4-byte IEEE-754
floating point gain value
Parm 2 - LSB of MSW of 4-byte IEEE-754 floating
point gain value
Parm 3 - MSB of LSW of 4-byte IEEE-754 floating
point gain value
Parm 4 - LSB of LSW of 4-byte IEEE-754 floating
point gain value
0x05
5
Report calibration offset
Parm - 8-bit 0-based sensor index
Parm 1 - MSB of MSW of 4-byte IEEE-754
floating point offset value
Parm 2 - LSB of MSW of 4-byte IEEE-754 floating
point offset value
Parm 3 - MSB of LSW of 4-byte IEEE-754 floating
point offset value
Parm 4 - LSB of LSW of 4-byte IEEE-754 floating
point offset value
0x06
3
Configure lower limit alarm
Parm - 8-bt 0-based sensor index
Parm 1 - 32-bit alarm limit
Parm 2 - 8 -bit alarm enable flag
Learning to be a Good Communicator 133
Response ID
Data Length
Parameter Values
0x07
6
Configure upper limit alarm
Parm - 8-bt 0-based sensor index
Parm 1 - MSB of MSW of 4-byte IEEE-754
floating point alarm limit value
Parm 2 - LSB of MSW of 4-byte IEEE-754 floating
point alarm limit value
Parm 3 - MSB of LSW of 4-byte IEEE-754 floating
point alarm limit value
Parm 4 - LSB of LSW of 4-byte IEEE-754 floating
point alarm limit value
Parm 5 - 8 -bit alarm enable flag
0x08
1
Reset alarms
Parm - 8-bit 0-based sensor index
0x09
3
Report alarm states
Parm - 8-bit 0-based sensor index
Parm 1 - MSB of 2-byte bit-mapped alarm flags
Parm 2 - LSB of 2-byte bit-mapped alarm flags
OxOA
6
Report lower alarm limit
Parm - 8-bt 0-based sensor index
Parm 1 - MSB of MSW of 4-byte IEEE-754
floating point alarm limit value
Parm 2 - LSB of MSW of 4-byte IEEE-754 floating
point alarm limit value
Parm 3 - MSB of LSW of 4-byte IEEE-754 floating
point alarm limit value
Parm 4 - LSB of LSW of 4-byte IEEE-754 floating
point alarm limit value
Parm 5 - 8 -bit alarm enable flag
OxOB
6
Report upper alarm limit
Parm - 8-bt 0-based sensor index
Parm 1 - MSB of MSW of 4-byte IEEE-754
floating point alarm limit value
Parm 2 - LSB of MSW of 4-byte IEEE-754 floating
point alarm limit value
Parm 3 - MSB of LSW of 4-byte IEEE-754 floating
point alarm limit value
Parm 4 - LSB of LSW of 4-byte IEEE-754 floating
point alarm limit value
Parm 5 - 8 -bit alarm enable flag
OxOC
5
Report sensor value
Parm - 8-bit 0-based sensor index
Parm 1 - MSB of MSW of 4-byte IEEE-754
floating point sensor value
Parm 2 - LSB of MSW of 4-byte IEEE-754 floating
point sensor value
Parm 3 - MSB of LSW of 4-byte IEEE-754 floating
point sensor value
Parm 4 - LSB of LSW of 4-byte IEEE-754 floating
point sensor value
OxOD
1
Set digital potentiometer value
Parm - 8 -bit digital potentiometer value
Table 4.3. Response Message Data Formats
134 Chapter 4
4.4 Summary
We've covered a lot of ground in this chapter, looking at three different commu-
nication interfaces that are widely used to connect the dsPIC DSC to peripheral
devices, to networks of sensors and controllers, and to remote systems. Although it
may not seem so to the reader, we have of necessity touched rather lightly on the
CAN interface (the Family Reference devotes 73 pages to this module alone), and
we've really only hinted at the communication possibilities available to the designer
given the profusion of standard and proprietary protocols to which the sensor may
be asked to connect. Nonetheless, with these tools, the designer should have a solid
foundation upon which to build and extend the communication capabilities of
dsPIC-based systems.
Endnotes
1. In this case, topology is simply the technical term for the arrangement of
nodes in a network.
2. Media-neutral just means that the protocol does not specify the physical
medium required to implement the protocol. This was intentionally left out
of the specification so that the protocol can operate over a variety of physical
media (so long as the media supports the ability to have a dominant and a
recessive bit state) .
3. 1 Mbps = 1,000,000 bits per second
4. In this case, arbitration is the process by which one of two or more nodes
that are competing for access to the network is allowed to transmit data.
Interrupt arbitration is the process by which the dsPIC DSC's interrupt
controller determines which interrupt condition to service.
5 . Nondestructive arbitration means that the message that ultimately is transmit-
ted on the bus is left intact. Destructive arbitration would determine which
message should be allowed onto the bus, but it would corrupt the message,
meaning that the node that is allowed to transmit would have to resend the
message from the beginning, which adds to the overall transmission time
and reduces the resulting available bandwidth.
6. Integrated circuits, or ICs as they're more commonly called, are the silicon
chips that contain much of the electronic circuitry in a system.
Learning to be a Good Communicator 135
7. This table is taken from Microchip Application Note 713 - Controller Area
Network (CAN) Basics, which is available on the Microchip website (docu-
ment DS00713A).
8. CAN Specification 2.0, Robert Bosch GmbH, 1991.
9. Many engineers (and companies) have a very bad case of NIHS (Not Invented
Here Syndrome), a crippling affliction that causes its victims to reject design
solutions simply because they were not created by the engineers themselves
or by their companies. Although the topic is often addressed humorously,
the consequences are anything but funny: significant development delays,
missed market windows, and inferior products. These consequences cost
companies a tremendous amount of added expenses and lost profits, so the
decision to develop a proprietary solution should be one based on objective
facts, not emotion.
10. A checksum is a common technique for verifying that data received at the
destination is the data that was sent. The term comes from the fact that
checksums are usually computed by some variation of adding together the
individual data bytes in a transmission; the computed sum is then checked
against the transmitted value.
This Page Intentionally Left Blank
A Basic Toolkit for the dsPIC DSC
Every day you may make progress. Every step may be fruitful.
Yet there will stretch out before you an ever-lengthening, ever-
ascending, ever-imp roving path.
— Sir Winston Churchill
With the basic understanding of the dsPIC DSC s functional modules that we
developed in the previous two chapters, we're now ready to create a basic toolkit of
software modules that we can use to create a flexible generic framework for imple-
menting intelligent sensor applications. For our application development, we'll use
a number of software tools and hardware development platforms available for free
or at low cost from Microchip. Although there are certainly other good development
tools available from third party-companies, these tools pass three important tests:
they're readily available, they're inexpensive, and they work.
5.1 The Application Test Bed
One of the most frustrating aspects of real-world product development is attempt-
ing to bring up new, untested software on new, untested hardware. Errors in either
the code or the hardware can bring everything to a grinding halt, often with no
solid clues as to the source of the problem. To alleviate this issue, we'll develop
our applications using the Microchip dsPICDEM 1 . 1 General Purpose Development
Board (GPDB), 1 which conveniently uses the dsPIC30F60l4A chip. Of course, in
most circumstances the final product would use custom hardware that addresses
the cost, size, power, and feature requirements for the specific application, but early
development on a standardized, known-good hardware platform allows coding to
begin prior to having the final system hardware, and it eliminates one major source
of error (the hardware) when debugging the application.
We need some way to get our code onto the GPDB for testing, and any significant
software development also requires some way to examine the operation of the appli-
cation as it's actually running. Using the Microchip ICD 2 in-circuit debugger and
Microchip's MPLAB IDE (integrated development environment), we can accomplish
137
138 Chapter 5
both those tasks. The IDE offers a convenient PC-based software development
environment that includes an editor, simulator, and assembler. Although there are
a number of good C compilers available for the dsPIC DSC, the example code is
written specifically for the Microchip C30 compiler v2.02, a student edition of which
can be downloaded free of charge from the Microchip website. 2 One advantage of
the C30 compiler is that it integrates directly with the MPLAB IDE, though there
are certainly other good compilers that have this ability, too. The ICD 2 must be
purchased, 3 but the MPLAB IDE is available as a free download from Microchip. 4
C30 Compiler v 2.02
MPLAB IDE
dsPIC Filter Design
dsPICWorks
RS232 Communication Program
RS232 Cable
USB 2.0
ICD Debug Cable
dsPICDEM v1.1
Board
9V Power
*v_
y
9V Power
Figure 5. L dsPIC Test Bed Block Diagram
5.2
Overview of the Firmware Framework
Now that we've set up a testbed, its time to create the firmware framework that
will serve as the foundation for the applications developed in the remainder of the
book. In developing the code, we will implement the following design principles to
A Basic Toolkit for the dsPIC DSC 139
ensure that the code is robust and that it anticipates and accounts for both normal
and anomalous operation:
1 . The code will use software state machines that are error-detecting and self-
recovering in the event of problems. These software state machines will be
as independent as possible and will employ simple, well-defined and well-
behaved interfaces to other software components in the application.
2. To the extent possible, the firmware uses standard code libraries available
from Microchip to trim the time required to code the application and to
debug it. This also eases the maintenance issue since we'll be using previously
tested code. 5
3. The code is written in layers, particularly that for the communication
interfaces and any that accesses the low-level hardware modules. This helps
prevent changes in one section of the code from breaking other, unrelated
sections of the code and gives the designer maximum flexibility in coding
specific areas of the application.
4. All of the code is well-documented internally, with extensive, meaningful
comments and standardized naming conventions to help developers who
have to maintain the code in the future. Although the code fragments that
are presented in the text have many of the comments stripped out for space
reasons, the actual code included on the CD-ROM that accompanies the
book has the comments restored.
Of these, the first and last design principles are extremely important, yet they
are often ignored as being too time-consuming or unnecessary. By implementing
self-correcting software state machines to handle the processing, we ensure (at least
to the best of our ability) that the code will never get into a processing state from
which it cannot recover. Doing so requires imagination and discipline since the
designer must anticipate all possible anomalous conditions and construct techniques
to both detect them and to recover from them should the conditions occur, but it
pays tremendous dividends in the robustness, flexibility, and maintainability of the
resulting code.
One of the real keys to effective software state-machine development is the proper
documentation of the state machines themselves, which leads us to the more general
topic of code documentation. Internal code documentation — i.e., documentation of
the firmware within the source code itself — is often neglected or given extremely short
shrift by programmers who feel they lack the time to include it. Inevitably, this lack
of commenting is accompanied by the promise to do it "when the project s finished,"
140 Chapter 5
a pledge that may or may not be fulfilled. Even if the comments are added after the
firmware has been completed, they often lack the insight that can be imparted at
the time the code is created, when the programmer is actually thinking about why
the code is being written a certain way. In truth, failure to document the code at
the time it is written is grossly irresponsible at best and is indicative of a program-
mer who is either too lazy or too self-serving (believing that a lack of comments
ensures job security) to be entrusted with serious product development. Proper code
documentation returns its time investment many times over by lessening the effort
required to maintain the code in the future and by reducing the chance that future
code changes will not account for assumptions implicit (but not documented) . Any
time someone tells you that commenting is unnecessary, you can be assured that
the person truly does not understand how to develop software. It is imperative that
programmers not succumb to the pressure to churn out undocumented code; it is,
after all, their reputations that will suffer when (not if) problems arise because of
poorly commented code.
With these general design principles as a foundation, we now turn our attention
to the application framework itself. To aid our understanding, the examination will
explore the framework from two different perspectives: the flow of data through
the application and the temporal relationship between the various system elements.
This gives the reader an appreciation both of the manner in which raw signal data
is transformed into meaningful information and of the step-by-step operations
required to implement that transformation. Our analysis begins with a study of the
flow of data through the application.
Application Data Flow
Data flows through the application framework in a fairly straightforward manner,
as shown in Figure 5.2. Raw analog sensor signals first pass through the sensor-
specific analog signal-conditioning circuitry to bandlimit the frequency content
of the signal to meet the Nyquist sampling criteria and to adjust the signal voltage
to an appropriate range. The ADC module then digitizes the conditioned analog
signals and stores the digitized data in a software buffer that is shared with the
data- analysis software state machines. After processing the digitized data, the data
analysis components transfer their results to a second shared buffer that serves as
input for both the control-processing state machines and the data-reporting state
machines. The control-processing modules update the control outputs according
to application-specific algorithms, and data-reporting modules send the analyzed
data to other external system components for use elsewhere.
A Basic Toolkit for the dsPIC DSC 141
r
Analog Signal
Conditioning
Circuitry
Digitization by
the
ADC Module
dsPIC Processor
Application Framework Data Flow
Raw Analog Sensor Signal
Bandlimited Analog Sensor Signal
Digital Filtering
And
Data Analysis
System Error
Condition Check
Communication
Processing
Serial Data
in Protocol -
specific
Structure
■► To Host
12-bit Digital Data in Signed
Fractional Format
Figure 5.2. Generalized Application Framework Data Flow
All of this is performed in a lockstep fashion, with data entering the system at
prescribed intervals and working its way through to the control algorithms and
reporting interfaces before the next input sample. That's not to say that the control
algorithms and reporting interfaces necessarily operate at the same sampling rate
at which input data is sampled (frequently they don't), but there is a direct, usually
constant, relationship between the input and the output rates. For example, an appli-
cation might sample the input signals 1000 times per second (1 Ksps 6 ) but produce
analyzed data at a rate of only 250 samples per second, with the control algorithms
and reporting interfaces operating at an even slower rate. The key point, though, is
that each processing stage is updated at the output rate of the previous stage, and
they must always be ready to handle the next sample as it becomes available.
There is one aspect of the data flow that is somewhat asynchronous, and that is
the reporting of error conditions. These error conditions may reflect a problem with
the input signal from the sensor (for instance, a signal value that is out of the expected
range), an error with the basic hardware, an error in the algorithm, or merely a valid
but undesired condition that is detected by the firmware (a cable is disconnected) .
Whatever the reason, the framework reports these anomalous operating conditions
142 Chapter 5
when they occur so that other elements of the system that depend upon the sensor's
data know to take appropriate corrective action. The asynchronous nature of the
error handling is indicated by the "error handler" lines emanating from each of the
major processing modules and terminating at the reporting module.
Note that the communication link between the reporting module and the external
system components may be any of the serial communication components: UART
(for standard RS-232 or RS-485 links), CAN (Control Area Network), or SPI or PC
(for extremely short distances such as board-to-board). While the actual structure of
the data reported will depend upon both the application's needs and the limitations
of the communication channel, the high-level concept of reporting system data and
anomalous conditions is the same for all communication modes.
System Task Flow
Having examined the flow of data through the framework, let's now look at the
various software tasks needed to implement that data flow and the sequencing
required for the tasks to operate properly. The implementation must carry out four
essential tasks:
1. initialize the software environment, which in our case is the C run-time
environment;
2. initialize the system hardware and software state machines to a known safe
start-up state;
3. service the various interrupts as they occur and make their information avail-
able to the rest of the system in a coherent manner; and
4. operate an event-processing loop that continually checks for specific system
events and performs the required processing when they occur.
Although specific elements of the framework may change from application to
application (in particular the system initialization and the specific interrupt sources
serviced), the general framework is a solid foundation on which to build the appli-
cation. By using a framework, we can be more productive (since the framework is
already tested), and we can devote more of our creative energy to the application
(where we add value) and less to the underlying "plumbing."
One of the major issues with any application framework is the structure of the
code, in particular ensuring that the code is easily customized for the needs of the
specific application while still maintaining the modularity that insulates the rest
of the system from those customizations. By using modular code, we can improve
the stability of the system software since changes in one part of the software won't
A Basic Toolkit for the dsPIC DSC 143
affect other areas of the code, and if (when) there are problems, the offending code
can be tested relatively easily. The code in this book takes the approach of grouping
routines that perform similar tasks (such as filtering or data analysis) and the data
that they act upon in a single C source file along with a corresponding header file
that contains the definitions and function prototypes required to use the routines.
Doing so allows the designer to think of the system as a set of functional objects
that communicate with each other through function calls and shared global data but
that are otherwise "black boxes" 7 in the sense that the code that performs the data
analysis, for instance, neither knows nor cares how the data filtering is performed;
the analysis routines simply work with the filtered data.
The framework modules consist of the following ten major modules:
1. Main.c / SystemEventDef . h
The application entry point main(), which calls the system initialization
routines and then starts the event-processing loop.
2. SystemCfg.c /SystemCfgDef . h
High-level system initialization routine that calls the low-level initialization
routines for the ADC, filtering, data analysis, and communication modules,
as well as routines to perform miscellaneous system tasks such as reading/
writing the system configuration data and resetting the watchdog timer.
3. ADCIF.c / ADCIFDef.h
The analog-to-digital interface initialization, processing, and interrupt service
routines that sample the sensor data.
4. Filter. c / FilterDef.h
The filter initialization and high-level data-filtering routines.
5. Analysis. c / AnalysisDef . h
The data- analysis routines that process the filtered sensor data to extract the
desired information and that report it via the communication channels.
6. CommlF.C / CommlFDef.h
The high-level wrapper routines that initialize the application-specific com-
munication channels and control the flow of data through the channels.
7. Timer. C / TimerDef.h
The timer initialization and interrupt service routines that perform time-
critical processing tasks, that schedule data sampling, and that track elapsed
system time.
144 Chapter 5
8. Protocol . c / Protocol . c
The high-level protocol handling routines that lie between the application
and the communication routines in CommlF.c.
9. Sensor. h / SensorDef.h
Routines for storing, retrieving, and applying sensor configuration informa-
tion to the sampled data.
10. dsPICDEMIF.c / dsPICDEMIF.h
Wrapper routines to easily access hardware resources on the dsPICDEM 1 . 1
General Purpose Development Board.
When implementing a given application, most of these modules will require
some customization to work with the specific hardware platform and to perform the
particular tasks required by that application. With this code structure, however, that
customization can be handled in an incremental fashion that allows code changes
to be tested thoroughly. For instance, the system initialization code is often the
first code to be tested when bringing up a new hardware platform; the designer can
implement the initialization code while leaving the other code stubbed out until
the initialization code has been thoroughly tested. Once that code is working, the
ADC interface can be brought to life and its operation verified, and so on until the
entire application is up and going.
Should the hardware platform change between revisions, any required code
changes would be limited to the SystemCf g . c, adcif . c, and dsPiCDEMiF . c mod-
ules; if, on the other hand, we just want to extract different parameter values from
the data, we only need to change Analysis . c to do so. Modularization as objects,
with code and its associated data grouped together, can allow the designer to reuse
significant portions of the software, reducing both development time and cost while
increasing system reliability. All three benefits increase product profitability while
making the designer's life easier, truly a win-win situation!
Initializing the Software Environment
Any program written in the C language must configure the C runtime environment
immediately upon starting up, prior to executing any of the application code that
begins with the main ( ) routine. This initialization establishes important operating
parameters such as the location of the stack and the heap 8 , sets each variable in the
various data sections generated by the compiler to its prescribed value, and then
starts the application itself by calling the function main ( ) . A list of the possible data
sections is given in Table 5.1 along with the type of data stored in the sections.
A Basic Toolkit for the dsPIC DSC 145
Section Name
Description
.text
Not actually a "data" section in the usual sense, the .text section is the section that
contains the executable code.
.data
One of the two initialized data sections that contain the information required to
set the value of global variables that are explicitly initialized to a starting value. The
.data section handles initialized data that has the far attribute and is the default
section for all initialized data when the application uses the large memory model.
.ndata
The second of the two initialized data sections, .ndata is reserved for initialized
data that has the near attribute and is the default section for initialized data when
the application uses the small memory model.
.const
The .const section holds constant- valued data such as text strings or numeric data
that has the const qualifier. Usually the section should reside in program memory
and generally is accessed using the PSV window.
.dconst
Similar to the .const section in its contents, the .dconst section is created by the
compiler under certain conditions when the application uses the large memory
model.
.nconst
Also similar to the .const section in its contents, the .nconst section is created
by the compiler under certain conditions when the application uses the small
memory model.
.bss
The first of three sections that hold uninitialized data (global variables that are
not initialized), .bss contains variables that have the far qualifier and is the default
section for uninitialized data for applications that are built using the large memory
model. Data in this section is cleared to as part of the C runtime environment
initialization.
.nbss
The second of three sections that hold uninitialized data, .nbss holds variables that
have the near qualifier and is the default section for uninitialized data for applica-
tions that are built using the small memory model. As with the .bss section, this
section is also cleared to as part of the C runtime environment initialization.
.pbss
The final of the three sections that hold uninitialized data, .pbss is intended for
RAM-based variables whose value should not be affected by a device reset (i.e., by
the dsPIC DSC resetting). Unlike data in both the .bss and the .nbss sections, data
in .pbss is not cleared to or set to any other value during initialization. The .pbss
section is located in near data memory.
Table 5. L C30 Compiler-generated Code and Data Sections
Usually, the C runtime environment initialization code or start-up code is trans-
parent to the application programmer, being incorporated in the software module
crt . o in the C30 compiler library file libpic3 . a. If, for some reason, the designer
would like to avoid initializing any of the initialized data sections (.data, .ndata,
.const, .dconst, and .nconst), he can link in the file crtl.o instead of crto.
o; the only difference between the two is that crti . o leaves out the data initializa-
tion step. Furthermore, if the designer requires any additional initialization that
simply cannot wait until the application starts, he can edit the assembly-language
file for either of the two start-up code modules (crto . s and crti . s, found in the
146 Chapter 5
src\pic3 subdirectory in the C30 compiler's directory) and include the requisite
additions by simply linking in the new module.
It's important to note that the sample crto . s and crti . s source files supplied
with the compiler are written specifically for the dsPIC30F2010, as indicated by
the first two lines following the introductory comments:
equ 30F2010, 1
include u p30f 2010 . inc
//
To ensure that the code is portable among the various devices in the dsPIC line,
the Microchip C30 uses processor-specific include files that define the register address
and bit assignments that are unique to each particular processor. As verification that
the programmer is including the correct file for the desired processor, each include
file has an assembler directive at the beginning of the definitions that checks whether
the corresponding device ID has been defined and reports an error if it has not. In
the sample code above, the first statement defines the device ID, and the second
statement includes the processor-specific header file.
If the application targets a device other than the dsPIC30F2010, then the
programmer has to indicate to the assembler the correct device for which the code
is to be created. This task can be handled in any one of the following three ways,
depending upon the designer's preference:
1 . through a command-line switch when the assembler is invoked (if the pro-
grammer is using the command-line assembler), for example:
C:\> AS -p30F6014A
2. by placing a .equ directive followed by the include file, as in:
.equ 30F6014A, 1
.include "p30f 6014a. inc
//
3 . or by setting the processor in the MPLAB Configure — > Select Device . . . dialog
(the easiest way) as shown in Figure 5.3.
The final action of the C runtime initialization is to start the user's application
code by calling the function main ( ) , and it is to that routine that we now turn.
A Basic Toolkit for the dsPIC DSC 147
Select Device
Device;
Device Earnily;
dsPIC30F601
4.*
3Cboooc
Microchip Programmer Tool Support
£ PICSTARTPIUS O MPLABICD2
PRO MATE II Q PICkit 1
O UPLABPM3
Microchip Language Tool Support
-OOD.IBLER
vl32
Microchip Debugger Tool Support
COMPILER
V1.32
O MPLABSIM
MPLAB ICE 2000
dNo Module
O MPLABICD2
MPLAB ICE 4000
GPMF30XA1
1 OK
£
Cancel
Help
Figure 53. MPLAB Configure — > Select Device Dialog
Initializing the System Hardware and Software State Machines
The start-up code intentionally performs the minimum initialization required to get
the software environment up and running but does not do any application-specific
configuration. Handling the initialization in this manner allows the C environment
to be flexible and to be as platform-neutral as possible, but it also means that the
programmer is responsible for configuring all of the dsPIC DSC's I/O ports and the
on-chip peripherals. There is an initial, usually brief, time period during which the
I/O signals are in their default reset condition, which may or may not be appropri-
ate for the specific application. Depending upon the purpose of a particular signal,
it might be necessary for the design to implement special hardware to ensure that
the system operates safely even during the time between reset and programmatic
initialization. If, for instance, one of the signals is used to turn on a high-power
laser, we probably don't want it to pulse on start-up; even a short activation time
could cause tremendous damage. It's important, therefore, that the first thing the
application code does is to initialize the I/O ports to known-safe states.
Of course, for most systems I/O port configuration is just a small part of the
overall system initialization procedure. The best approach to initialization is to begin
with the I/O ports and then to work out in time-critical order by configuring the
system (not just the dsPIC DSC) resources in the order that they will be needed.
Depending on the specific environment, this may even mean that the application
initializes certain off-chip components before setting up some on-chip modules;
148 Chapter 5
the key is to get the system configured as quickly as possible and in the order that
resources are required. The designer must also ensure that the system doesn't start
processing system events until all of the resources required to process them have
been successfully initialized. Ignoring this very important rule can result in erratic,
even catastrophic, failure of the system.
Some designers prefer to initialize the hardware for all of the functional blocks
prior to initializing the software state machines that work with those hardware
components; others choose to initialize a software state machine immediately
after configuring its associated hardware. The nature of the application itself may
determine the choice of which approach to take; for instance, it may be critical to
get all of the hardware modules to a certain state as quickly as possible. Where pos-
sible, it's helpful if one can take the module initialization approach in which the
hardware and software for a particular functional element are initialized at the same
time because this allows the code to be more modular, and it helps to ensure that
complete system components are brought up in a well-defined order. In our case,
the framework employs the modular initialization approach both for ease of coding
and to clearly illustrate the ideas we're discussing.
dsPIC Interrupt Configuration
Configuring the interrupts is a four-step process:
1 . identifying the interrupt sources to service,
2. setting the interrupt priority level (IPL) for each interrupt,
3. enabling the individual interrupts so they can be recognized by the interrupt
controller, and
4. enabling the global interrupt so that the dsPIC DSC will process any of the
interrupt sources that are both active and enabled.
While none of these steps are particularly difficult in and of themselves, they
all three have to be performed correctly or the system won't operate reliably. The
worst-case condition is if one or more of the steps is handled almost correctly, because
that can lead to intermediate system failures that are extremely difficult to identify,
replicate, and solve.
In our applications, we'll have three consistent interrupt sources: the system tim-
ers, the ADC, and the communication channels. Of these, the system timers and
the ADC are the most critical because they sequence the flow of data through the
system. The communication channel, although important, can survive operating at
a lower priority because its functionality does not require the extremely tight time
A Basic Toolkit for the dsPIC DSC 149
windows of the other two. If we temporarily have to buffer an incoming character,
it's not too big a deal; if, on the other hand, we start to sample aperiodically, the
system performance may degrade quickly.
The interrupt sources we'll need to service, in priority order, are:
Timers 2/3 - 32-bit timer mode, variable rate - ADC sampling timer
Timer 1 — 16-bit timer mode, 10-ms interrupt rate — general system timer
ADC Sample Ready — reports when a complete data sample is ready for filtering
UART 1 Rx Data Ready — receive data pending on communication channel
UART 1 Tx Holding Register Empty - transmitter available on communication
channel
5.3
Implementation of the Framework Modules
Since we discussed the start-up code in some detail already, we'll begin our look at the
framework implementation with the application entry point, the ubiquitous main ( )
routine. As mentioned in Section 5.2, main ( ) basically initializes the system com-
ponents and then starts an event processing loop that continually checks for events
that have been generated by either the interrupt service routines or by processing
performed in the event loop itself. These system events are really just bit-mapped
flags in the global 16-bit variable g_vuii6SysEvent, 9 with the events defined in the
header file SystemEventDef .h. Setting a flag indicates that the event has occurred
and needs to be processed; clearing it shows that the event has been handled.
The following code for main ( ) shows the call to the system initialization routine:
Systemlnit ( ) :
Intl6
main (void)
{
// Local Variables
Uint8
ui8Analysiscount ,
ui8RxData,
ui8Status;
// Decimation count for scheduling data analysis
// Received communication data
// Function execution status
// Initialize the system hardware and the
// associated software state machines
Systemlnit ( ) ;
150 Chapter 5
II Process system events as they occur
while (FOREVER)
{
// Are there any pending system events? Start
// by checking for sampled data that is ready
// to be filtered
if (g_vuil6SysEvent)
{
// Yes, is sampled data ready to be filtered?
if (g_vuil6SysEvent & EVT_FILTER)
{
// Yes, data samples are ready so clear
// the event and filter the samples
g_vuil6SysEvent &= ~EVT_FILTER;
ui8Status = FilterData () ;
g_vuil6SysEvent |= EVT_ANALYZE ; // Yes, signal
// Analyze Data
// event
}
// Is there filtered data to be analyzed?
if (g_vuil6SysEvent & EVT_ANALYZE)
{
// Yes, so clear the event and
// perform the analysis
g_vuil6SysEvent &= ~EVT_ANALYZE;
ui8Status = AnalyzeData ( ) ;
// Did the analysis reveal a condition
// that should be reported?
ui8AnalysisCount++ ; // Increment the data analysis decimation count
if (ui8AnalysisCount >= ANALYSIS_TIME)
{
ui8AnalysisCount =0; // Reset the decimation count
g_vuil6SysEvent |= EVT_REPT_RESULTS; // Flag that we have results
// to report
}
A Basic Toolkit for the dsPIC DSC 1 51
// Are there analysis results to
// be reported to the host?
if (g_vuil6SysEvent & EVT_REPT_RESULTS)
{
// Yes, so clear the event and report
// the results via the communication
// channel
FormatResultsMsg (g_ui8ResultsMsg,
&g_uil6ResultsMsgLength) ;
if (g_uil6ResultsMsgLength <= CommGetTxFreeCount ( ) )
{
// Have room in the transmit queue so add
// in the results message and clear the
// event to show that we've processed it
CommPutBuf f (g_ui8ResultsMsg,
g_uil6ResultsMsgLength) ;
g_vuil6SysEvent &= ~EVT_REPT_RESULTS ;
}
}
// Has a 100 msec timer tick occurred?
if (g_vuil6SysEvent & EVT_TIMER)
{
// Yes, clear the event and perform any
// required timer tick processing
g_vuil6SysEvent &= ~EVT_TIMER;
// Insert any additional processing
// to be performed here
}
// Check whether we have received
// any data from the host
if (CommGetRxPendingCount ( ) > 0)
// Yes we do, so get the next received
// character and process it
152 Chapter 5
ui8Status = CommGetRxChar (&ui8RxData) ;
if (ui8Status == ST_OK)
CommProcRxChar (ui8RxData, &g_ui8CommParseState) ;
}
// Reset the watchdog timer
// to keep it from expiring
ResetWatchdogTimer ( ) ;
}
// We should NEVER get here if the system
// is operating normally. The routine will
// exit and the startup code will reset the
// device if we get to this point.
return ST_SYSTEM_FAIL;
}
Two things should be noted about the system initialization: it occurs before
anything other than allocating the local variables, and the details of the initialization
are wrapped in a separate function rather than included as part of main ( ) itself.
The first ensures that the hardware is initialized to a known safe state as quickly
as possible, while the second is an example of writing good, modular code that is
relatively platform neutral (at least at the high level) .
We'll look at the system initialization code in greater depth shortly but for now
let's continue with main ( ) . After the system's been initialized, the code starts a
processing loop that continually checks for and processes system events, checks for
and processes any data received over the communication channel, and resets the
watchdog. The looping continues until the processor is reset.
As implemented, the loop can check and process multiple events during a single
pass through the loop. Depending upon the worst-case time it would take to process
every possible event and to check and process any received communication data, the
loop structure may have to be changed to process only a single event for each pass
through the loop. Such a change is easily made by simply changing the series of if ( )
statements to if ( ) ...else if ( ) statements. The one criteria that must be met is that the
watchdog timer must be reset before it expires, or the entire device will reset. Usually,
we only want that to occur if the software becomes stuck in an invalid processing state,
not just because we took a bit too long to go through the main processing loop.
A Basic Toolkit for the dsPIC DSC 1 53
To get a better feel for how we'll perform the system initialization, let's examine
the Systeminit () routine more closely. The configuration code uses functions
found in the dsPIC30F DSC Peripheral Library, 10 which is included with the C30
compiler and is also available on the Microchip website. Documentation for the
library is found in the 16-Bit Language Tools Libraries document 11 located in the
mplab C3 o\Docs subdirectory of the directory in which the compiler is installed, or
in the same document on Microchip's website. Those functions are further wrapped
(albeit lightly) in code that is application specific so that, should the underlying
hardware or software platform change (for instance, should a better library become
available to implement the desired functionality), the firmware components could
be swapped out fairly easily with new code.
One other key aspect of all of our systems is their ability to perform advanced
digital filtering using the Microchip DSP Library routines, and in most cases we'll
want to use FIR filters. To perform this filtering, the application must first create
and initialize a data structure for each filter. This FiRStruct structure, whose pro-
grammatic definition is found in the compiler-supplied header file dsp . h, contains
all of the information required to maintain a filter's tapped delay line and to apply
the filter coefficients. Creation of the structure is simply a matter of allocating both
the filter coefficients vector (and initializing it with the coefficient values) and the
vector for the tapped delay line), then either declaring the FIR structure as a global
variable or alternatively declaring it as a local variable within a function whose
scope is active for as long as the filter needs to be in existence. As a rule, the author
prefers the former approach because even if the execution paths for the application
code change, the filter will always be in scope. If, on the other hand, the filter is
declared as a local variable and the execution paths are changed in a future software
version, the filter structure may temporarily go out of scope, allowing other data
to overwrite the memory structure and causing erroneous results when the filter
structure data is used again.
One of the great aspects of the dsPIC Filter Design software is that it will generate
assembly-language code that handles creation of the filter structure and its associated
tapped delay line and filter coefficients at the touch of a button. For example, to
create the filtering code for our thermocouple application, we perform the follow-
ing steps in Filter Design:
1. From the main menu toolbar, select Design^FIR Window Design... as
shown in Figure 5.4.
154 Chapter 5
W. dsPICFD
r?
a-
SPC
fite Vjew Design filter Output Cpdegcr Window
IIR Design ...
Ready
snap off Qie
Figure 5.4. FIR Filter Design Menu Selection
2. The program will then display the first filter design window, which is shown
in Figure 5.5. Select the Lowpass filter option and press the Next button.
™ FIR (Window) Design
Fitter Type
'•* [ Lowpass ] C" Bandpass
Highpass C Band stop
Next
Help
Close
Figure 5.5. FIR Filter Design Window 1 of 4
3. Enter the filter parameters as shown in Figure 5.6, and then click on the
Next button to move to the third design window.
4. Select the type of filter that you would like to use, noting the number of taps
required for each filter type in order to implement the filtering requirements
specified in the previous window. In Figure 5.7, we select the Gaussian filter
for our application, and it will require 5 1 taps. Note that we could have also
specified a particular number of taps if we so desired.
A Basic Toolkit for the dsPIC DSC 1 55
™ Lowpass Filter
Filter Specification Input
Sampling Frequency: 500
Passband Frequency: 1 5
Stopband Frequency 1 : 25
Fassband Ripple fdB): 0.1
Stopband Ripple (dEJ: 3
Next
Help
Cancel
Figure 5. 6. FIR Filter Design Window 2 of 4
™ Lowpass Filter
?
X
FIR Window Design Filter Length Estimates:
C Rectangular
47
r
4 Terni Cosine
257
C Triangular
199
r
4 Term Cosine with C5D
319
C Hanning
157
r
Minimum 4 term cosine
297
f Hamming
1 165
r
Good 4 Term Blackman
2S9
C Blackman
275
r
Ham's Rattop
337
C Exact Blackman
C 3 Term Cosine
289
267
r
r
1 Kaiser I
49
63
D o lp h -Ts chebysch eff
C 3 Term Cosine with C3D
259
r
Taylor
51
C Minimum 3 Term Cosine
** o ^
2vb
<*
Gaussian
51
Enter Desired Filter Length (optional):
Next
Prev
Help
Cancel
Figure 5. 7 FIR Filter Design Window 3 of 4
5. After pressing the Next button in the screen in Figure 5.7, the program will
generate the resulting filter response curves that are shown in Figure 5.8. At
this point, we've created the filter, but we haven't generated any code.
156 Chapter 5
Iff! dsP
ICFD
a] sa|«| Hf|E3 SB [B
w
" ■ *'B ' I KW
Ojjcj
Magnitude vs Frequency
r
D •
1
r----:-
«
i
2
•
jj 5.4
I
-_- ___! _-_l_ _i_ .
K
'": ""I **Q 200
Frequency {Hertz)
-•--
(5 Group Delay
_ n x
Croup DeSay vs Frequency
i i:a
OAil
S
1
2
a
3
© a o«o
o o?o
0096
G CCf
i i i i i
* * •
i i i
0.0 z, -J-. 1M 200
Frequency (Hertz)
*tj
m\ m
SPT.
u y
Ill
^ Log Mflgnitude(dB)
D x
Log Magnitude vs Frequency
: d
2Q.
03
T3 -*0.
a
-M.
M
■"W
\
if
KE
M
IWwm,
1 n T ■ -i 1 F <; KJQ
Frequency (Hertz)
250
™ i rnpuLse Response
n| x |
impulse Response vs Time
3 095*347
-0 0952247
! P I J
Time (Milliseconds)
■j:.
W, f
J°J.
Phase vs Frequency
Cr
CL
3141590
J ..:■'.:,!
3M3319
-3 553515
•1 f a*soo
-1.141590
J--1 1« W| 150 . 200
Frequency (Hertz)
P* Step Response
Step Response vs Time
c
c
Q.
M*
C
i
Q.
i
+->
1.j461«
■
■ — -,----- — .j -
■
•
-. , -
■ - r -
i
■ ■ ■ y"
\
0-74** 94
I
24962-1
•
.
•
r
■
/
i
, — >-=- s
•
-0.249&31
1 1
•
1
I
i
-0,?4359*
1
■
-1.24*190
,
20. 40. «. iJ
Time (Milliseconds)
■■_z
Ready
Snap- Of* Qlfi
Figure 5. 8. FIR Filter Design Window 4 of 4
6. To generate the filter code itself, select the CodeGen — > Microchip — >
dsPIC30 entry from the main menu toolbar as shown in Figure 5.9.
W dsPICFD
E*e Sew Gssqo Nw QutDu: £adeg«* Zflndow
IftJ yjs|jal«lJ c&*- JBlHl ml [d
(!! Magnitude
Efuudty
PI T
a a
£ nAT
■i^rra
J
Magnitude vs Frequency
IT
1 u
-,
0.*
t
*e
> t
!
i
0,4
1 i 1 *
1 !•■
i
i
2
•
•
00
I t 1
1
M 100 -50 SQ0
Frequency (Hertz)
-*-\
J
og MngniTuriefrlR)
- a x
m
rlW
Log Magnitude vs Frequency
-]□]_*_
CD
a
a
-iD.
-».
40
50 100 'K K0
Frequency (Hertz)
250
I
3.141590
- =*■"=: J
0.523319'
Phase vs Frequency
M 'T- IM ?00 350
Frequency (Hertz)
^5 Cjroup Detay * | DJ
Group Delay vs Frequency
K! rnpulse Response
impulse Response vs Time
O x
3 'LI
0.035
D :"D
*
Q 'J .055
3
O a 040
0.025
» » • • 1 1 1 1 1
■ i i
i
■ ■ i i
. . . . p. ^ . ........... ^.. ._>,....,._..,..*., — ^....
• i i
■ill
i I
■ i I
I I
• ■
i l
• • ■■■
'
■ ■ • ■ • i i •
■ ■ ■ * i l i i
■ • ■ ■ > a - 1 ■ i i
09S3347
5C 100 "53 _:.iu
Frequency (Hertz)
253
20. .. .::.
Time (Milliseconds)
■ QC
P^ Step Response
Step Response vs Time
~ D x
iJZ4«ieo
-1.24E-M
20. 90. SO
Time (Milliseconds)
100
-VvpiV- :-■,■
Figure 5.9. FIR Filter Code Generation Menu Selection
A Basic Toolkit for the dsPIC DSC 1 57
7. The program will display a dialog box (Figure 5.10) that allows the user to
enter the desired code-generation options. In our case, we'll use the default
selections (Use General Subroutine and X Data Space) and add one more,
the C Header File and Sample Calling Sequence (.h) option that will tell
the software to generate an associated C header file.
---
>
5! dsPIC30 Code Generation Options
m
Source File Generation
..■4.H ■■■■■MUPHIBIH KI>IIII1III.IIHI»>I<»IIIU1II •
{* j Use General Subroutine \
C Support Files
I? C Headier File and Sample Calling Sequence(.h)
Coefficient Space Selection
(* X Data Space
Program Space
Simulator Files for Impulse Response Calculation
r c
e (plots simulator output & FFT)
(? Matlab
C Octave
0<
Help
Cancel
Figure 5. 1 0. Code Generation Options Dialog
8. Pressing the OK button in the dialog box will display the dsPIC30 code base
file name dialog shown in Figure 5.11 that lets the user specify the name of
the generated code file. Because the code generator uses the file name as the
base name for the created FIR filter structure, the file name must not have
any spaces or punctuation.
Enter the file name SensorFilter and press the OK button.
9. The program generates a number of files, the most important for us being
the files SensorFilter .h (the C header file that defines our filter structure
for use by other C files) and SensorFilter . s, the assembly-language code
containing the filter structure and its associated coefficient and tapped delay-
line buffers.
To actually use the generated filter code in the application, the programmer
simply adds the filter code (in this case, the file SensorFilter. s) to the project.
Before the filter is first employed by the application, it must be initialized by calling
the function FiRDelayinit () , which initializes the filter's tapped delay line to a
known state. Note that if code generated by the Filter Design package is being used,
there is no need to call the function FiRStructinit () to initialize the associated
158 Chapter 5
dsPIC30 code base file name
Save in: £3 Filters
My Recent
Documents
Desktop
My Documents
i
My Computer
\ti] Sensor Filter, h
QSensorFilter.s
"TlSensorFilter make, bat
\c\ SensorFilter_sim*c
SiSensorFilter sim.cmd
My Network File name:
Places
Save as type:
7
"V
T] o s E$ m-
dsPIC30 code base file name {*)
3
3
Save
Caned
Figure 5.11. dsPIC30 Code Base File Name Dialog
structure; that task is handled by the generated code. Failure to initialize the tapped
delay line will cause problems with the filter's response until new data is able to work
its way through the delay line.
Once the filter has been initialized, applying it to new data is extremely easy.
When a block of new data is available to filter, the application calls the function
fir ( ) with pointers to both the new data to filter and to the destination data buffer
that will hold the resulting filtered values, as well as a pointer to the filter structure
being applied. Since fir ( ) handles updating of the associated tapped delay line,
the application does not need to concern itself with that task.
There is one final caution about using the DSP library routines, and it is an
important one. If a library routine is interrupted, the interrupting routine must
ensure that it restores the contents of the Status register and the DO and REPEAT
instruction values to the pre-interrupt state, or the DSP function may return invalid
results. The DSP routines use certain shared hardware resources, and if an interrupt
routine changes the configuration of those resources, the change will probably cause
problems with the portion of the DSP function that executes after the interrupt
completes. To make things easier for the designer, the description for each of the
DSP library routines lists the resources it uses.
A Basic Toolkit for the dsPIC DSC 1 59
5.4 Summary
This chapter has provided an overview of the software framework we'll employ in
the next three chapters, all of which are real- wo rid applications of the principles that
we've been discussing to this point. Although much of the framework is somewhat
skeletal at this point, we'll be adding flesh to those bones quickly, starting with the
temperature sensor that we'll develop in the next chapter.
Endnotes
1 . The Microchip part number for the dsPICDEM 1 . 1 General Purpose Devel-
opment Board is DM300014.
2. The Microchip website is www.microchip.com. The student edition is full-
featured for the first 60 days following installation, after which it supports
only minimal code optimization. In most cases, optimization at this level
will cause the code size to grow, but the compiler functionality is otherwise
unchanged. The part number for the full-featured version of the compiler is
SW006012.
3. The Microchip part number for the ICD2 is DV1 64005.
4. The Microchip part number for the MPLAB IDE is SW007002.
5. As with anything associated with development tools, the wise designer takes
the term "tested code" with a grain of salt. Although programmers as a class
have a tendency to immediately assume that "it's the other guy's code that has
the problem," a better approach is to presume that one's own untested code
probably is the culprit when an error occurs. If that code has been examined
thoroughly and found to be error-free, however, one then should verify that
the third-party "tested" software is indeed operating properly (after taking
the all-too-often ignored step of confirming that the parameters to the tested
code are correct). Remember, just because software is "tested" doesn't mean
that it was tested for the specific condition that causes a problem.
6. 1 Ksps = 1 kilosamples per second = 1,000 samples per second
7. The term black box refers to a system in which we know how we expect the
outputs to behave given a particular set of input values, but do not know (nor
particularly care about) the internal operation of the system. An example of a
black box system for many people would be the ignition system of their car.
160 Chapter 5
They know that if they turn the ignition key the car should start; how that
actually occurs is frequently a mystery and not something that they think
about.
8 . The stack and the heap are two areas of memory that are established at runtime
(i.e., when the program first starts. The stack is a block of memory that is
used to hold temporary variables (that is, the local variables for a function),
to store parameters passed to a function, and to hold the program address
to which to return when a function has completed. During the time the
application runs, the stack may grow and contract as necessary.
9. The variable g_vuii6SysEvent illustrates the variable-naming convention
used throughout the code. In general, variable names are prepended with
their abbreviated type; for instance, vuii6 would indicate a volatile unsigned
16-bit value. Global variables are further prepended by a g_ to indicate that
they are global, rather than local, variables.
10. The dsPIC30F DSC Peripheral Library is Microchip part number
SW300021.
11. The 16-Bit Language Tools Libraries manual is Microchip document
DS51456C.
Sensor Application — Temperature Sensor
It doesnt make a difference what temperature a room is.
It's always room temperature.
— Steven Wright
Each of the next three chapters (Chapters 6 through 8) develops a complete sensor
system that measures some common parameter and then communicates the measure-
ments to a host system. This chapter tackles temperature measurement, Chapter 7
constructs a pressure and load monitor, and Chapter 8 creates a flow sensor. By neces-
sity, each application focuses on a particular type of sensor, but the concepts apply
to a broad range of sensing elements, often with only minor adjustments needed to
address the unique requirements of the specific sensor being employed to measure
the particular parameter of interest. The reader should feel free to expand upon the
ideas presented here; one obvious extension would be to include a control algorithm
that acts upon the sensor's parameter measurements to accomplish a desired effect.
With that introduction, let's turn our attention to temperature, probably the most
widely measured physical property in the world today. l
Temperature's importance comes from its impact on so many environmental and
processing situations. We, or more accurately the equipment we employ, require accurate
temperature measurements to heat and cool our homes, to operate our car's engine, to
cook food, to process industrial materials, to monitor a patient's vital signs, and the list
goes on and on. Back in Chapter 1 , we saw an example of such a device, the mercury
bulb thermometer, in which the absolute temperature is indicated by the level of the
liquid mercury inside the thermometer. Unfortunately, the fragility of that type of sen-
sor (usually a glass tube enclosing the column of mercury) and the toxicity of its sensing
element (mercury is highly poisonous) limit the mercury thermometer's usage to certain
well-controlled environments. The sensor system we develop here employs a sensing
element that is far better suited to a wide variety of environments and applications: the
thermocouple. Before we delve too deeply into the details of thermocouples, let's first
look at the variety of temperature-sensing elements available to us.
161
162 Chapter 6
6.1 Types of Temperature Sensors
Over the years, scientists have developed a host of specialized sensing elements that
respond to absolute temperature or to changes in temperature by varying some
physical property. In this book, we're interested primarily in sensing elements that
we can monitor using electronics, for the very simple reason that doing so allows us
to easily convert the monitored physical property into a measurement that we can
manipulate using the dsPIC DSC. That's not to say that other approaches (such as
visually monitoring the mercury bulb thermometer) are invalid; it merely means
that those nonelectrical techniques are unsuitable for our purposes because of the
monitoring platform. Nails and screws can both be used to fasten two boards together,
but one is far more likely to use a nail if the tool at hand is a hammer.
Currently, there are five widely used types of sensing elements whose outputs can
be monitored electrically. Advances in technology are sure to build upon this list,
but most electrically based temperature sensors are one of the following types:
1 . thermocouples,
2. resistance temperature detectors (RTDs),
3. thermistors,
4. silicon sensors, or
5. infrared sensors.
Although we'll discuss each of these sensor types in the following sections, the
application we develop in this chapter uses the thermocouple exclusively because
thermocouples are widely used, well understood, accurate (when utilized properly)
and relatively inexpensive (which is one reason they're so widely used) .
Thermocouples
Thermocouples are two-wire sensing elements that make use of the Seebeck effect
to measure the temperature of the junction of the two wires. The Seebeck effect,
discovered by the scientist Thomas Seebeck in 1821, 2 creates a voltage across the
junction of any two dissimilar metals that correlates to the temperature of the
junction. Although this voltage is quite small, on the order of several microvolts
per degree of temperature, it's possible to create systems that are accurate over a
wide temperature range provided that proper analog and digital signal processing
techniques are used.
The caveat "that proper analog and digital signal processing techniques are used"
is a major consideration. The very small voltages produced by thermocouples (on
Sensor Ap plica tion — Tempera ture Sensor 163
the order of millivolts) require that designs employ good grounding and shielding
techniques to avoid introducing unacceptable levels of noise in the measured voltage.
In addition, because the traces on a printed circuit board are made of a metal that
differs from those of the thermocouple, the very circuitry that we use to measure
the original thermocouple voltage introduces an additional Seebeck junction whose
output varies with temperature! Finally, thermocouples can be highly nonlinear
over their range of measurement, as we can see from Figure 6.1, which shows the
response of various thermocouples with temperature.
Sample Thermocouple Response Curves
80 i
>
E
a>
D)
I
0)
Q.
O
o
o
E
CD
-400
•J Thermocouple
- K Thermocouple
N Thermocouple
1600
-20 J
Temperature (Degrees C)
Figure 6.1. Response Curves of Various Thermocouples
Given all these serious constraints, why would anybody select a thermocouple to
measure temperature? Thermocouples are popular for three reasons: they are relatively
inexpensive, they work over a wide range of temperatures, and we can compensate
for their limitations (as we'll see in the Challenges topic in Section 6.2). Even with
the additional circuitry and software needed to deal with thermocouples' deficien-
cies, they make a reliable sensor whose cost and performance characteristics satisfy
a large number of applications.
Resistance Temperature Detectors (RTDs)
Another very popular temperature sensor is the resistance temperature detector or RTD.
Usually constructed of fine (small diameter) platinum wire wound around a nonelec-
164 Chapter 6
trically conductive cylinder or mandrel with the entire assembly being coated by a
nonconductive material, the resistance of the RTD varies linearly with temperature.
By passing a known current through the device, we can generate an output voltage
that corresponds to the temperature of the RTD through the equation:
A RTD = K + OC 1 RTD
where
^rtd equals the measured resistance in ohms of the RTD at
temperature 7" RTD
R equals the resistance in ohms of the RTD at 0°C
OC equals the temperature coefficient of the RTD
Trtd equals the temperature of the RTD in °C
The temperature coefficient of an RTD depends upon the purity and composition
of the platinum used to wind it. Two standard RTDs are widely used, one having
an a value of 0.00392 and the other a slightly lower a value of 0.00385. Because
RTDs with the lower a value were initially used extensively in Europe, devices with
that value are said to have a European curve, while those with the higher value are
said to possess an American curve.
Since RTDs are far more linear, why would a designer ever choose to employ
a thermocouple instead of an RTD? There are two aspects to the answer, one
economic and the other having to do with system performance. RTDs tend to be
more expensive than their thermocouple counterparts, so the initial device cost may
be more expensive. Often, the more serious constraints arise in the area of system
performance.
We usually want to measure the temperature of the system without disturbing
the system itself. Because an RTD requires current to operate (necessary to generate
a voltage across the device), there will be some nonzero amount of sensor element
self-heating due to the current flow. This effect is particularly noticeable in applica-
tions in which there is little flow of material past the sensor because the added heat
builds up, causing a thermal error that may change over time. The thermal error
is real, in the sense that the surrounding material actually becomes warmer, but it
may not accurately reflect the temperature of the material or environment even a
short distance from the sensor. Thermocouples, which are essentially zero-current
devices, suffer from no such self-heating effect.
The other system-performance constraint has to do with the temperature range
over which RTDs operate, which is significantly narrower than the range for ther-
Sensor Application — Temperature Sensor 165
mocouples as a class (although individual thermocouple types may have a range
limitation similar to RTDs). RTDs work for temperatures between -250°C and
+850°C, whereas thermocouples have an operating range of-270°C to +2300°C.
Particularly for high-temperature applications above 850°C, thermocouples may be
the only viable choice of sensing element.
Thermistors
Like RTDs, thermistors change their device resistance with temperature, but unlike
RTDs, whose resistance rises with temperature, the resistance of a thermistor actu-
ally decreases with increased temperature. This negative temperature coefficient effect
is only one way in which the two devices differ because, unlike RTDs, thermistors
are also highly nonlinear. Fortunately, thermistors can be used in matched pairs so
that the nonlinearities of one thermistor compensates for the nonlinearities of the
second thermistor, resulting in a reasonably linear output.
Because they require a current to operate, thermistors share RTDs' self-heating
problem, and their operating range is significantly less than that for either RTDs or
thermocouples, with a typical operating range being from -40°C to + 1 50°C. Within
this range, though, properly configured thermistors can be extremely accurate. 3
Silicon Sensors
It's not at all unusual to include a temperature sensor in electronic systems that have
to operate in harsh environments. The system can use the measured temperature to
either activate climate control or to shut down if things get too hot or too cold for
it to run safely, or it can use the temperature reading to perform other application-
specific tasks. Whatever the reason, the increasing integration of system components
through the years led inexorably to the creation of first silicon-based temperature
sensors and then the integration of those sensors into other chips.
In general, silicon temperature sensors may be fairly accurate (on the order
of RTDs or thermistors), but they usually are limited to an even more restricted
range of operation than thermistors (-40°C to +125°C), and they suffer from the
same self-heating problems as any sensing element that requires power to operate.
Silicon sensor devices themselves tend to be more expensive than their nonsilicon
counterparts, but they often don't have additional wiring costs associated with them
since they frequently are collocated with the electronics they are monitoring. Even
if they are located some distance from the processing unit, the wiring required to
connect them to the main system can be standard copper wire rather than expensive
thermocouple or RTD wiring.
166 Chapter 6
Infrared Sensors
Some temperature-measurement applications preclude the use of a sensor that is in
physical contact with the material being monitored. Examples of this would include
extremely hot substances (above the 2300°C limit for thermocouples) or materials
that would be adversely affected by touch, such as a thin film or a painted surface
prior to drying. In cases like this, one approach is to measure the emitted infrared
radiation of the object and then to compute the corresponding temperature based
on the object's emitted electromagnetic energy.
While simple in concept, infrared temperature sensing can be difficult in prac-
tice for a number of reasons. The primary difficulty is that different materials have
different emissivity 4 characteristics — i.e., they emit infrared radiation with varying
efficiency. If we are to use an infrared sensor properly, we have to know the emis-
sivity characteristics of the material being measured or the temperature readings
will be inaccurate. An example of this effect in the real world can be seen when
monitoring the temperature of molten plastic in the metallic barrel that channels
the plastic into a mold. Unless the operator knows what he or she is doing, it's not
at all unusual for the measured temperature to be that of the metallic barrel rather
than the desired temperature of the plastic melt. 5
A second issue that may be either an advantage or a problem, depending upon
the circumstances, is that infrared temperature measurements are made over an area
rather than at a single point. While this is true to a certain extent with all temperature
sensors (after all, we have yet to invent a sensor that takes up zero area), the other
sensors that we've discussed tend to be treated as point-source measurements — i.e.,
they are usually small enough that we can ignore the size of the sensor itself. This
is not the case with infrared sensors, which inherently examine a projected area on
the object being measured, essentially reporting an average temperature over that
area. When using such a sensor, it's important that the operator completely fill the
sensing area with the object, or the sensor will report inaccurate readings that aver-
age in surrounding temperatures.
A third potential problem with infrared sensors is that they can pick up reflected
infrared radiation from other sources as well as that emitted from the target. Like all
electromagnetic waves, infrared radiation will reflect off of any surface with which
it comes in contact, so some of the measured infrared energy may well come from
other sources. If the reflected energy is quite small relative to the emitted energy
that's picked up by the sensor, then the effect may be negligible, but if the reflected
energy is significant, it can seriously degrade the quality of the readings.
Sensor Application — Temperature Sensor 1 67
One of the biggest issues with infrared sensing, though, is its cost. It's not
unusual for an infrared sensor to cost multiple thousands of dollars, several orders
of magnitude more than any of the other sensors discussed. With a price tag like
that, with the additional training required to use it, and with the added operational
complexities (in particular, needing to have detailed information on the infrared
radiation characteristics of the substance being monitored), infrared sensing is cur-
rently limited in its application.
6.2 Key Aspects of Temperature Measurement
In any temperature-measurement system, there are certain fundamental issues that
we have to address in order to get meaningful, accurate results. Failure to consider
any of these issues can lead to inaccurate measurements. Depending on the par-
ticular situation, these inaccuracies may range from the inconsequential (if your air
conditioning thermostat is off, you'll simply adjust it to get the desired conditions),
to the frustrating (try baking a cake at what you think is 400°F when the oven is
actually 250°F 6 ), to the catastrophic (imagine a hydrogen gas production line that
becomes overheated).
For the rest of this chapter, when we discuss a particular issue, we'll concentrate
on how that issue affects thermocouple sensors, but the subjects we'll explore must
be addressed in any temperature-measurement system regardless of the type of sen-
sor used. To ensure that our system works properly, we'll consider the following
important topics:
1 . the types of temperature sensors available,
2. the required measurement range,
3. the resolution and accuracy we need (the two are not equivalent),
4. the characteristics of the thermocouple signal, and
5. the sources of noise in the measured signal.
Range of Measurement
In any measurement system, we first must identify the range of values that we need
to be able to process, because that frequently determines the type of sensor that we
can use. Although thermocouples as a class can be used to measure temperatures
from — 270°C to +1760°C, individual thermocouple types cover only a portion of
that range, as shown in Table 6.1, which is taken from the National Institute of
Standards and Technology table of thermoelectric voltages and coefficients. 7
168 Chapter 6
Type
Range (°C)
B
0-1820
E
-270-1000
J
-210-1200
K
-270-1370
N
-270-1300
R
-50-1760
S
-50-1760
T
-270 - 400
Table 6. 1. Thermocouple Measurement Ranges
The measurement ranges given in the table are really just a starting point, how-
ever, because they represent the maximum conditions under which a particular
thermocouple type can be used. A thermocouple's actual operating range is then
derated based on its wire diameter (the smaller the wire, the more restricted its
temperature range) and the temperature rating of the protective sheathing material
around it (if any). As an example of how severe these derating effects can be, the
upper limit for a J thermocouple in the table is given as 1200°C, but checking the
reference table for a commercially available protected bare-wire J thermocouple 8
shows that an 8 AWG (0.128" diameter) thermocouple is rated to only 760°C. If
the thermocouple is constructed of 36 AWG (0.005" diameter) wire, the maximum
thermocouple temperature drops to only 3 1 5°C, a loss of nearly 75% of the expected
temperature range.
One other real-world factor may affect the selection of the thermocouple type,
namely that the designer may not have a "choice" at all. It s not at all uncommon for
an end-user to already have a standard thermocouple specified, and changing that
standard may not be an option. In North America, for instance, most injection-mold-
ing operations use J-type thermocouples while European and Asian customers tend to
use K-type thermocouples for the exact same applications. The wise system designer
makes provisions for supporting more than one type of thermocouple if at all possible;
it saves both the end-user and the product manufacturer time and trouble.
Resolution of Measurement
The required measurement range not only determines the type of thermocouple
we need to use, it also affects the resolution we can expect to get in our measure-
Sensor Ap plica tion — Tempera ture Sensor 169
ments. Resolution refers to how finely we perform our measurements and is usually
expressed in terms of degrees. A fairly common requirement is to be able to resolve
our temperature measurements to a half a degree C or perhaps a degree F, but we are
able to do so only if our ADC can digitize the corresponding analog sensor signal
with sufficient resolution. In order for that to happen, two conditions must hold:
1 . we must be able to transform the analog output signal range from the ther-
mocouple into an analog voltage range that can be digitized by the ADC,
and
2. the ADC must be able to digitize the transformed signal range with the
desired resolution.
While we've extolled the benefits of processing the sensor signal in software, the
first condition is one that we can satisfy only through electronic hardware, usually
by placing amplification and level-shifting circuitry between the sensor output and
the input to the dsPICs ADC. If we fail to properly map the sensor output signal
levels to a suitable voltage range for the ADC, the digitized signal might clip 9 and
might even destroy the dsPIC DSC if the input exceeds the absolute voltage input
range specified by the chip's data sheet. Adding an amplification stage also allows
us to buffer the sensor's output signal, which typically has a fairly limited drive
capability, from the dsPIC DSC's relatively low-impedance input to the ADC. By
inserting the buffer, we keep the dsPICs ADC from introducing unwanted signal
distortion due to excessive loading of the sensor output signal. 1
o
How, then, does the designer accomplish this transformation? The procedure is
simple and involves just three very basic calculations. Before making these computa-
tions, though, we need to know the voltage range for the sensor's output signal (at
least for the measured parameter values of interest) and we need to know the ADC's
input voltage range. Armed with this knowledge, we then perform the following
three calculations:
1 . Express both the sensor's output signal and the ADC's input voltage ranges
in terms of their spans and offsets:
M AJN SENSOR = V o MAX — V o MlN
(Jrrohl SENSOR = V^min
SPAN ADC - VA MAX - VA MIN
OFFSET ADC = VA MIN
170 Chapter 6
w
here
SPAN SENSOR is the sensor output voltage span
VS MAX is the maximum sensor output voltage
VS MIN is the minimum sensor output voltage
OFFSET SENSOR is the sensor output voltage offset
SPAN ADC is the ADC input voltage span
VA MAX is the maximum ADC input voltage
VA MAX is the minimum ADC input voltage
OFFSET ADC is the ADC input voltage span
2. Compute the amplification gain required to map the sensor output voltage
span to the ADC's input voltage span:
GAIN = SPAN... / SPAN
ADC ' ^- LjtiJ - "SENSOR
where GAIN is the required amplification gain. If the gain is greater than 1,
the sensor output signal is amplified in the traditional sense (i.e., it's made
larger); if the gain is less than 1, the sensor's output is attenuated.
3. Compute the level shifting required to map the sensor's voltage offset to the
ADC's required minimum voltage:
SHIFT = OFFSET ADC - OFFSET SENSOR
where SHIFT is the voltage that must be added to the sensor output voltage
after amplification.
Having satisfied the first of our two conditions (mapping the output sensor volt-
age range to an appropriate ADC input voltage range), we must now examine the
steps required to fulfill the second condition (verifying that the ADC can digitize
the transformed voltage range with sufficient precision). This, too, is quite straight-
forward and is another three-step process:
1 . Compute the range of the measured parameter values that correspond to the
sensor output voltage range from the previous set of calculations:
PARJvWe = PARM MAX - PARM MIN
w
here
PARMranqe is the range of parameter values that correspond to the sensor
output voltage range, expressed in units of measurement
Sensor Ap plica tion — Tempera ture Sensor 1 7 1
PARM
MAX
appropriate for the parameter and not in terms of the
corresponding voltage itself
is the parameter value that corresponds to the maximum
sensor output voltage (note that this is not the maximum
sensor output voltage but rather the parameter value that
corresponds to that voltage)
is the parameter value that corresponds to the minimum
sensor output voltage (as with PARMmax, this is the parameter
value, not the sensor output voltage value)
2. Compute the resolution of the ADC in counts — i.e., determine the total
number of levels into which the ADC input voltage range can be divided
given the bit-resolution of the ADC:
PARM
MIN
RES ADC = 2 NumBits
where
RES
ADC
3.
is the resolution of the ADC expressed as the number of
counts, or levels, into which the ADC can divide its input
voltage range
is the number of bits that the ADC uses for digitization (either
10 or 12, depending upon the type of dsPIC DSC)
Calculate the resolution in terms of the measured parameter, expressed as
the parameter units per ADC count or level:
NumBits
PARM RES = PARMr^ge
/RES
ADC
where
PARM
RES
is the parameter resolution, expressed as the parameter
units per ADC count or level
A simple example should help clarify these concepts. Suppose that we want to use a
J-type thermocouple to measure temperatures in the range 0°C to 750°C, and further
assume that we select a thermocouple constructed to handle the required temperature
range so we can concentrate on just the signal-processing needs here. From the ITS-90
table of thermoelectric voltages for a J-type thermocouple, we can see that a J thermo-
couple produces a voltage of 0.0 mV at 0°C and a voltage of 42.28 1 mV at 750°C. For
ease of scaling, let's assume an input voltage range of mV to 50 mV (approximately
870°C) and assume that we're running our dsPIC ADC with an input range of 5V.
The gain and level shift required for our amplification stage are found by:
172 Chapter 6
1 . Computing the span and offset of the sensor output voltage and the ADC
input voltage:
SPAN SENSOR = 0.050V- 0.000V = 0.050V
OFFSET SENSOR = 0.000V
SPAN ADC = 5V-O.OV=5V
OFFSET ADC = 0.0V
2. Calculating the amplification gain required to map the output sensor voltage
span to the ADC's input voltage span:
GAIN = 5V / 0.050V = 100
3. Calculating the level shift required to map the minimum output sensor volt-
age to the corresponding minimum ADC input voltage:
SHIFT = 0.0V - 0.000V = 0.0V
In this case, since the analog input voltage range and the analog output voltage
range both have a lower limit of V, no voltage offset is requred in the analog ampli-
fier stage. In the general case, however, the amplifier stage requires a level-shifting
component as well to map the lower limit of the input voltage range to the desired
lower limit of the output voltage range.
With the input voltage range mapped, we're ready to verify that the second
condition is valid. If our dsPIC DSC uses a 12-bit ADC, each bit of the ADC
output represents 1/4096 of the ADC input voltage range (1 / 2 12 = 1 / 4096). In
our example, this means that we're able to digitize the amplified temperature signal
with a resolution of:
I RES = I RANGE ' -^-^ADC
T RES = (870°C - 0°C) / (4096)
T D .c = 0.2124°C
RES
where
Tres is the temperature resolution of the system in °C
Trange is tne temperature input range of the system in °C
RES ADC is the resolution of the ADC in counts
A quick calculation shows that if we used a dsPIC DSC with a 10-bit ADC
(which has a resolution of 2 10 = 1024 counts), our temperature resolution for this
example would degrade to:
Sensor Application — Temperature Sensor 1 73
T RES = (870°C - 0°C) / (1024)
T^ = 0.8496°C
If we want to maintain a temperature resolution of 1°F (0.56°C), we would be
able to do so with the 12-bit ADC, but the 10-bit ADC would fail to meet our
system requirements.
Accuracy of Measurement
Frequently users, and sometimes designers as well, confuse a systems resolution with
its accuracy, which is a totally different beast. While resolution tells us the degree of
granularity to which we can compute our measurements, accuracy tells how correct
those reading actually are. Both concepts are important, but its critical to under-
stand that one does not necessarily imply the other. For instance, our system may be
capable of resolving down to 0.5°F, but that may not be of much use if these highly
specific measurements are off by 10°F because of problems in the system.
Where might such egregious errors arise? The first place to look is in the sensing
element itself, since an inaccurate sensor will introduce imprecision that may or may
not be repeatable (the former being more desirable since it can be compensated).
Indeed, different types of thermocouples have differing degrees of accuracy over their
operational range, with J-type thermocouples being the most accurate (±0.1 °C); E,
R, andT thermocouples good to ±0.5°C; K thermocouples accurate to ±0.7°C; and
S thermocouples accurate to ±1.0°C.
Other problems in the signal chain can cause incorrect results as well, including
a lack of or insufficient cold-junction compensation (discussed in the section titled
Cold-junction Compensation), failure to ensure proper common-mode noise rejec-
tion, or the introduction of non-common-mode noise into the circuit. Usually, we
can compensate for inaccuracies due to the sensor itself or due to other elements
in the circuit, provided those problems are not time- or temperature-dependent,
through proper calibration and linearization. The key points to remember are that
resolution is not equivalent to accuracy and that we need to have both in order to
have a robust, reliable system.
Challenges
We now shift our focus from the general to the particular, from the aspects of system
design that apply to all sensor systems to those that we face specifically because we're
using thermocouples as our sensing element.
174 Chapter 6
Signal Characteristics
The starting point for any sensor system is to determine the characteristics of the
signal output by the sensor over the range of interest. These characteristics include
the voltage levels of the signal, the sensor's output drive capabilities, and the antici-
pated frequency content of the signal.
Signal Level
As a quick check of the NIST thermoelectric tables shows, thermocouples produce
a very small output voltage, on the order of a few millivolts. Complicating our
use of the thermocouple signal is the fact that it's essentially a zero-current signal,
meaning that it's only able to drive very high-impedance loads. Unfortunately, the
dsPIC's ADC input impedance of about 20 KQ doesn't meet that criterion. Finally,
depending upon the temperature range that we want to measure, the thermocouple's
output voltage can be negative, which violates the input signal requirements for the
dsPIC's ADC. Even if the thermocouple normally produces a positive voltage for all
of the temperatures of interest, should the thermocouple's leads become reversed (a
condition that occurs in practice more frequently than one might imagine) , the input
voltage to the digitization circuitry still may be negative. Clearly, a thermocouple-
based system requires a high-impedance amplifier between the sensor output and
the ADC input to buffer, amplify, and level-shift the signal.
By choosing the amplifier's gain and offset appropriately, we can design a system
that works when the thermocouple is wired correctly or when it is reversed. At first
blush, this capability may not seem to be particularly important; after all, couldn't
the user simply swap the thermocouple wires to correct the problem? Sometimes
this is a viable option, but there are circumstances in which it is not. On one injec-
tion-molding project with which the author was involved, the cost to remove the
mold (where the thermocouples were installed) and to make any change to it started
at $50,000, and the cost to run the machine was $20,000 per day. The complete
system supported over a hundred sensors of various types, and Murphy's Law 11
dictated that at least one of the thermocouples would be miswired (which actually
happened). In this environment, the ability to operate with minor wiring problems
saved a great deal of money and aggravation for the customer.
Frequency Content
If we intend to filter the sensor inputs to reduce electrical noise, we need to identify
the frequency content of the sensor signal so that we know the frequencies that we can
safely attenuate without excessively degrading the sensor signal itself. To determine
the spectral content of the temperature signal, we need to understand something of
Sensor Ap plica tion — Tempera ture Sensor 175
the thermal characteristics of the system that we're monitoring, namely how quickly
the temperature can change over time. Some systems can change temperature very
quickly while others may fluctuate relatively slowly Although the designer frequently
doesn't have a hard specification for this in advance, he often has a good feel for the
maximum rate of temperature change that can be expected. As an example, in a heat-
ing application, based on the maximum power we can apply to the heating element
and the thermal dissipation properties of medium being heated, we should have a
good idea of the maximum expected rate of temperature change. When we turn on
an oven to heat a pizza, we don't expect it to instantly heat to 400°F; it should take
maybe three minutes. Using this admittedly crude approach, we would estimate that
our system has a maximum temperature velocity 12 of approximately:
ATww = 400 °F / 180 seconds = 2.22 °F/sec
MAX
If we continue with the 12-bit J thermocouple example that we developed in the
Resolution of Measurement section, and remembering that 1°C = 1.8°F, we can see
that this maximum rate of temperature change corresponds to an ADC count of:
ACount MAX = AT MAX / T^
ACount MAX = (2.22°F/sec) / (0.2124°C/count * (1.8°F /°Q)
ACount MAX =5.8 counts/sec ~ 6 counts/sec
Assuming that we want to be able to track temperature changes of only 1 ADC
count, this would imply that we need to sample at least 6 times per second. However,
applying the Nyquist criteria that we learned in Chapter 2, the theoretical minimum
sampling rate should be at least twice that (12 samples per second) and the practical
sampling rate should be around five times that (30 samples per second).
There are all sorts of caveats to using this approach, starting with the most obvious
one: there may be, and probably are, periods during the heating cycle in which the
temperature changes by more than the linear amount predicted using this technique.
In addition, we're assuming that the appropriate analog antialiasing filters have been
applied to the sensor signal to suppress broader-band noise; if that is not the case
or if the filter bandwidth is broader than required by the sampling rate, we need
to increase the sampling rate appropriately. Finally, thermocouples themselves have
response-time characteristics, meaning that it takes a finite amount of time for the
thermocouple output voltage to accurately reflect the temperature at its junction.
Nonetheless, in the absence of any additional information, the technique is prob-
ably a good starting point.
176 Chapter 6
Cold-junction Compensation
By far the most difficult and least understood aspect of interfacing with thermo-
couples is a concept known as cold-junction compensation or CJC. As you'll recall from
the earlier discussion of thermocouples, the Seebeck effect generates a temperature-
dependent voltage at the junction of two dissimilar metals, and it's this property
that makes thermocouples so useful to us. Unfortunately, the Seebeck effect is not
limited to the junction of the two thermocouple leads with each other (known as the
"hot" junction); it also occurs at the termination of the thermocouple leads (known
as the "cold" junction) into the copper traces on the circuit board to which they are
connected. It is this unwanted Seebeck- effect voltage that we have to remove, and
we do so using a technique known as cold-junction compensation.
The basic idea behind cold-junction compensation is to measure the temperature
at the cold junction (i.e., where the thermocouple leads enter the PCB) and to add
that temperature to the temperature calculated for the hot junction (i.e., at the sensor's
thermocouple), thus compensating for the unwanted Seebeck-effect voltage. 13 An
equivalent approach is to simply add the corresponding cold-junction voltage to
that for the hot junction. To do this properly, the design must ensure:
1. that the terminations at the cold junction for both thermocouple leads are
at the same temperature (known as an isothermal termination or isothermal
barrier), and
2. that the device used to either measure the temperature of the isothermal
barrier or to generate a corresponding voltage is located as closely as possible
to the isothermal barrier.
Failure to meet both requirements will introduce an uncorrectable error into
the temperature measurements and, even worse, this error will change with
temperature.
Linearization
Next to cold-junction compensation, the most difficult task when processing ther-
mocouple signals is the mapping of the nonlinear thermocouple voltage to a linear
temperature scale. One common way of doing this is by evaluating a high-order
polynomial expression using a recursive technique with thermocouple type-depen-
dent coefficients, but since it is a mathematically intense operation, this approach
is generally unsuitable for embedded-processor applications. Although the dsPIC
DSC can perform mathematical operations very efficiently, there's another tech-
nique known as piecewise linearization that yields excellent results while being less
complex to implement.
Sensor Application — Temperature Sensor 177
The basic idea in piecewise linearization is to divide a nonlinear curve into a series
of linear segments, as shown in Figure 6.2. Within each segment, we approximate
the value of the actual curve by the value of the line between the segment's starting
point and ending point. To compute the estimated value, we simply determine the
segment to use by finding the one containing the value we're mapping, and then
calculate the estimated value using the slope and Y-intercept of the corresponding
segment. We thus reduce a high-order polynomial computation to a search and a
linear computation.
Linear Approximation of a Curve
Using Three Segments
Segment 1
Curve to be
approximated
Between x and x-i, we approximate the value of the
actual curve by using the linear equation for Segment
1, between x 1 and x 2 by using the equation for
Segment 2, and between x 2 and x 3 by using the
equation for Segment 3.
Figure 6.2. Example of Piecewise Linearization of a Curve
Two things determine the technique's efficacy: the number of segments used
to parse the curve and the nature of the curve we're attempting to approximate.
Obviously, the more segments we use, the more accurately we can match the curve,
but also the more time required to identify the appropriate segment to use in the
linearization. This balancing act thus becomes one more tool in the designer's kit,
allowing him to trade accuracy for speed or vice versa.
Calibration
Linearization is one important part of converting the temperature voltage signal
into a value that can be used by the dsPIC firmware, but it is not the only process
required to generate a useful digitized value. The linearized signal must also be cali-
brated to a set of known temperature readings to ensure that the computed signal
value is accurate for the particular hardware. By far the most widely used technique
for calibrating thermocouples is the two-point method, in which two readings are
178 Chapter 6
taken at different temperatures (usually at points near either end of the tempera-
ture range of interest), and those points are then used to create a linear calibration
reference curve.
As an example, suppose we want to measure temperatures between 100°F and
900°E We might take as our calibration points the temperatures 150°F and 750°F,
since they are near the endpoints of our range and ensure that the linear curve we
generate is not too far off of the actual thermocouple curve. Although we could
use 100°F and 900°F as our endpoints, this would result in a linear curve that has
a greater maximum error, as shown in Figures 6.3a and 6.3b.
Calibration Curve with 150 2 F and 750 2 F as Calibration Points
Linear calibration function
that approximates the
actual thermocouple curve
Actual thermocouple
curve
4-H-
100
200
300
400
500
600
700
800
900
Note that the bow of the actual thermocouple curve is exaggerated to better illustrate the
error between the linear calibration function and the actual thermocouple curve. With
this choice of calibration points, there is less error between the two calibration points,
but the error increases outside of the two calibration points.
Figure 6.3a. Calibration Curve Using 1 50° F and 750° F
Calibration Curve with 100 g F and 900 9 F as Calibration Points
Linear calibration function
that approximates the
actual thermocouple curve
Actual thermocouple
curve
4-H-
100
200
300
400
500
600
700
800
900
Note that the bow of the actual thermocouple curve is exaggerated to better illustrate the
error between the linear calibration function and the actual thermocouple curve. This
choice of calibration points creates a significantly larger error between the two
calibration points but reduces the error at the very top end of the measurement scale
(near 900 Q F.)
Figure 6.3b. Calibration Curve Using 100° F and 900° F
Sensor Application — Temperature Sensor 1 79
To perform the calibration, we would measure the linearized voltage at the lower
calibration point, repeat the measurement at the upper calibration point, and cal-
culate the gain of the calibration curve as:
^CAL - V 1 UCP — 1 LCP/ ' V V UCP — V LCP )
G C al = (750°F - 150°F) / (V UCP - V LCP )
Gcal = 600°F / (V UCP - V LCP )
While the offset is simply:
OFF.,, =T
CAL _ * LCP
In these equations,
G CAL is the gain for the calibrated reference curve
OFF CAL is the offset for the calibrated reference curve
T UCP is the temperature of the upper calibration point (750°F)
T LCP is the temperature of the lower calibration point (150°F)
V UCP is the voltage reading at the upper calibration point
V LCP is the voltage reading at the lower calibration point
In practice, the sensor firmware would take a voltage reading, linearize it, and
then convert it to the corresponding temperature through the equation:
I CAL ~ ^CAL X (^READING — ^LCP/ + ^I^CAL
W
here
T CAL is the calibrated temperature reading
G CAL is the gain for the calibrated reference curve
OFF CAL is the offset for the calibrated reference curve
Vreading is tne linearized voltage reading
V LCP is the voltage reading at the lower calibration point
All of this discussion raises one fairly obvious question: if we're trying to calibrate
the temperature sensor, how do we "know" what the temperature is at our two
calibration points? The answer is that we have to use a calibrated source, typically
a thermocouple calibrator that injects a precision voltage based on the specified
temperature. These devices are available at relatively low cost from a number of
suppliers, although the more accurate and easier to use versions can cost several
hundred to several thousand dollars.
180 Chapter 6
Sources of Noise
That there will be sources of noise corrupting the thermocouple system is a given
and, with its the thermocouple s intrinsically low signal level, the effects of electri-
cal noise can be devastating. The good news is that we can use both the inherent
noise-cancelling characteristics of the thermocouple's differential signal and the
frequency spectra of the temperature signal and of the noise to effectively filter out
a significant portion of the unwanted signal.
AC Power
A common source of electrical noise arises from AC power-line radiation, particu-
larly in industrial or other environments in which there are cables carrying large
currents near the thermocouple. Power-line noise does have one redeeming quality:
its spectral content is extremely narrow-band and is centered about either 50 Hz
or 60 Hz (depending on location), with harmonics at multiples of those frequen-
cies. To a designer, such well-defined narrow-band noise signals are actually easier
to handle than lower-level broadband noise, provided that the bandwidth of the
noise signal does not encompass too significant a portion of the frequency band of
the sensor signal itself.
Because the thermocouple signal is so small and drives virtually no current, it's
extremely susceptible to power-line contamination. Fortunately, thermocouple
signals do have two things working in their favor: their differential nature helps
reject common-mode noise and the frequency spectrum of the power signal is often
outside of the temperature signal band. Even in those cases in which the power-
signal frequencies are within those of the temperature signal, the narrow-band
nature of the power signal usually allows the system to remove it effectively using
a band-stop filter.
Figure 6.4a shows an example of an out-of-band power-line signal's frequency
content along with a spectrum for a sample temperature signal. Using the low-pass
filter shown in Figure 6.4b, we can easily remove the spurious spectral content,
producing the resultant filtered signal shown in Figure 6.4c.
The more difficult case of in-band power-line noise is shown in Figure 6.5a, in
which the power-line signal is within the spectra of the temperature signal. In this
case, we have to employ a high-order notch filter to surgically remove the unwanted
frequencies, which leaves an improved, but clearly not perfect, filtered temperature
signal. Even with this slight degradation, the resultant signal is more accurate than
the unfiltered version.
Sensor Application — Temperature Sensor 1 81
Temperature Signal with Out-of-Band
Power-line Noise
Magnitude of Frequency Response
Spectrum of desired
temperature signal
Spectra of unwanted
power -line noise
Figure 6.4a. Sample Temperature Signal with Out-of-band Power-line Noise
Low-pass Filter to Remove
Power-line Noise
Magnitude of Frequency Response
Figure 6.4b. Low-pass Filter to Remove Out-of-band Power-line Noise
Filtered Temperature Signal with
Power-line Noise Removed
Magnitude of Frequency Response
Spectrum of desired
temperature signal
left intact
Spectra of unwanted
power -line noise have
been eliminated
Figure 6.4c. Resulting Filtered Sensor Signal
182 Chapter 6
Temperature Signal with In-Band
Power-line Noise
Magnitude of Frequency Response
Spectrum of desired
temperature signal
Spectra of unwanted
power-line noise
Figure 6.5a. Sample Temperature Signal With In- band Power- line Noise
Notch Filter to Remove In-Band
Power-line Noise
Magnitude of Frequency Response
Figure 6.5b. Notch Filter to Remove In-b and Power-line Noise
Filtered Temperature Signal with
Power-line Noise Removed
Magnitude of Frequency Response
Spectrum of desired
temperature signal
altered by filtering
► f
Spectra of unwanted
power-line noise has
been removed
Although the spectrum of the desired temperature signal has been
affected by the filtering, most of the original signals is intact so we
should be able to obtain useful results.
Figure 6.5c. Resulting Filtered Sensor Signal
Sensor Ap plica tion — Tempera ture Sensor 183
Finally, Figure 6.6 illustrates the case where the power-line noise spectrum sig-
nificantly overlaps that of the temperature signal itself. In this case, there is no good
filtering approach that will compensate for the power-line noise, and the designer is
left with the unsatisfactory alternative of trying to correlate the power-line noise on
the thermocouple with the power-line signal itself and then subtracting this from
the measured sensor signal. While technically possible, a much better approach
for such a situation is to shield the thermocouple and the power-line cables and to
route them so as to minimize the coupled radiation. In practice, it is exceptionally
unlikely that most thermocouple-based systems will ever encounter such an extreme
circumstance since there are very few materials (including those for thermocouples)
that can respond thermally at a 50-Hz or 60-Hz rate.
Temperature Signal with Significant
In-Band Power-line Noise
Magnitude of Frequency Response
Spectra of unwanted
power -line noise
Spectrum of desired
temperature signal
> f
Figure 6. 6. Sample Temperature Signal with Overlapping Power-line Noise
Error Conditions
There are two serious error conditions that can be detected fairly easily through the
judicious use of high-impedance biasing resistors attached to the thermocouple and
by paying attention to the characteristics of the measured thermocouple voltage.
Failure to check for these conditions can cause the sensor to report grossly inaccurate
measurements and, depending upon how these measurements are being used can
lead to catastrophic system failure.
Open Thermocouple
The first error condition we can check is the presence of an open thermocouple — i.e.,
a thermocouple in which the junction between the two thermocouple leads has been
broken. This can occur fairly frequently in systems that experience severe mechani-
cal or thermal stress, particularly if that stress is repeated over time. Detection is
184 Chapter 6
straightforward provided that two matched high-impedance resistors are added to
the thermocouple input connection (one per lead) as shown in Figure 6.7. Should
the junction break, the leads will be biased to the extreme of the input voltage range,
a condition that is easily detected by the dsPIC DSC.
Sense Resistors Added to
Thermocouple
Inputs to Detect Error Conditions
+3.3 V
R
+
TC+ Input
TC- Input
R
-3.3 V
Figure 6. 7. Sense Resistors Added to Thermocouple Inputs
In selecting the bias resistor value, the designer does not want to swamp the signal
produced by the thermocouple itself under normal circumstances. Something on
the order of 100 kQ generally works quite well, but its important to match the two
resistors as closely as possible to maintain the differential nature of the signal.
Reversed Thermocouple
Since the thermocouple leads are polarized, it's possible to reverse them. Although
this won't damage the input circuitry because the signal is of such a low level, if
undetected, the condition will read erroneous results. When a thermocouple is
reversed, the measured signal voltage decreases as the temperature increases, but since
we don't usually know whether the temperature is actually increasing or decreasing,
the only way to be confident that the thermocouple is reversed is to detect a voltage
that is below the expected lower range of the signal. For instance, a J thermocouple
produces negative voltages when exposed to temperatures below 0°C, so if the range
of interest is between 0°C and 500°C (32°F and 932°F), then any negative voltages
would indicate that the thermocouples were reversed.
Because we want to be able to discern when the thermocouple output drops
below a certain minimum value and since we want to be able to determine when
the thermocouple itself is open, it's important to allow a little headroom at either
end of the digitization range. By doing so, we can assure that we measure the entire
temperature range of interest while still being able to correctly identify faults with
the thermocouple.
Sensor Application — Temperature Sensor 1 85
6.3 Application Design
With all of that background information under our belt, we're now ready to design a
real-world intelligent temperature sensor (at least as real-world as one can get using
a demo board as the hardware platform). Although a basic design, the application
described here can be extended easily to perform more complex tasks, such as tem-
perature control as well as sensing.
As with any application, the first step is to specify the required system functional-
ity, which we'll do in the section titled System Specification. With the system specs
in hand, the next steps are to design the sensor-specific signal conditioning circuitry,
to determine the digital-filtering requirements, and to define the data-analysis algo-
rithms that need to be performed, all of which sections Sensor Signal Conditioning,
Digital Filtering Analysis, and Data Analysis Algorithms cover. Finally, the sensor
has to communicate its results to the rest of the system using a predefined protocol,
which is discussed in the section Communication Protocol.
System Specification
Our goal is to develop a generic temperature sensor hardware and software plat-
form, so the specifications are not particularly detailed because we don't want to get
bogged down in minutiae that are applicable only to a few select situations. Be aware,
though, that often the specifications for a sensor system are extremely detailed, and
the engineer needs to review them carefully prior to performing any detailed design
to ensure that they are achievable.
The temperature sensor developed here will meet the following functional
requirements:
1. Sample one thermocouple and one cold-junction compensation channel.
2. Sample each channel 500 times per second, assuming a maximum tempera-
ture signal frequency content of 15 Hz (approximately 33 x oversampling) .
3. Support J- and K-type thermocouples.
4. Perform required cold-junction compensation for both types of thermo-
couples.
5. Screen for open and reversed thermocouple conditions.
6. Filter the sampled data to remove power-line noise.
7. Allow the user to perform the following functions via the RS-232 serial
port running at 38.4 Kbps, 8 data bits, 1 stop bit, no parity, and no flow
control:
186 Chapter 6
a. perform calibration of each channel, and
b. specify a lower and an upper temperature alarm limit for each channel.
8. Report the measured temperatures for all channels every second via the serial
port. If the system detects an error condition for a particular thermocouple,
that error condition will be reported instead of the temperature reading.
Temperature and error reports are to be in text.
9. Report out-of-limit alarm conditions by displaying a sensor value of" — "
and lighting LED 1 on the demo board if the measured temperature is less
than the lower limit and by displaying "++++" and lighting LED2 if the
temperature exceeds the upper alarm limit.
This application monitors only two signal channels to reduce the amount of circuitry
that the reader has to implement; there is nothing from a performance standpoint that
would prevent the system from monitoring any number of channels up to the full 1 6
supported by the dsPIC30F60l4A chip. While the sample rate may seem a bit high
in absolute terms, it is one that allows us to easily remove power-line noise without
significant signal delay through the system. As with the number of supported channels,
the sampling rate can be increased if necessary; the dsPIC DSC has plenty of process-
ing power to do so. Also note that the reporting rate of the measured temperatures is
so low because the reported data is intended to be read by humans. If the data is to
be read by other electronic components in the system, a much faster binary-oriented
protocol would be appropriate, code for which is also supplied in the books CD.
Sensor Signal Conditioning
As described earlier in the chapter, the thermocouple sensor interface needs to
1 . buffer and amplify the thermocouple output signal,
2. perform cold-junction compensation, and
3. detect sensor error conditions.
In addition, we also need to include an analog antialiasing filter that effectively
eliminates frequencies above 250 Hz (since the sampling rate of 500 Hz has to be
at least twice the highest frequency content of the temperature signal). Since the
temperature signal that we're sampling is assumed to have a maximum bandwidth
of 15 Hz (meaning that we're sampling 33 times faster than is theoretically neces-
sary), we should use this information to further tighten the antialiasing filter cutoff
frequency to 15 Hz as well. The circuitry shown in Figure 6.8 does all of this for a
single channel. Let's examine each portion of the circuitry to gain a better under-
standing of what's included and why. "Note that the schematic is configured for
Sensor Ap plica tion — Tempera ture Sensor 187
operation at 3.3V. If the circuit is implemented on the dsPICDEM 1.1 GPDB
(which uses 5V supplies), change all references to 3.3V to 5V, all —3.3V references
to -5V, and change 1.65V to 2.5V
Thermocouple Interface Circuitry
,F R
G
c
+3.3 V
+
v +
RGt
OUT
RG 2
Vref
-
V.
-3.3 V
C*= =
I R
R
4
r J W\r"- J W\r-f—
C 4
+1 .65 V
Primary Signal Gain and Level Shifting
l
2 nd -Order Anti -Aliasing
Filter with Unity Gain
J '_
C
6
nd
2" -Order Anti -Aliasing Filter
and Secondary Gain
OUT
NOTES:
1 . R-i and R 2 provide both an input common-mode current path and a way to determine whether the
thermocouple is actually connected to the circuit Resistor values should be identical and be between 10 KQ
and approximately 100 KQ to avoid loading the input signal with too low an input impedance while still
providing an input common-mode current path that has a low enough impedance to be effective.
2. Gain through the instrumentation amplifier is controlled by Rq according to the equation
Gam1 + (50 KQ / R G )
3. Ci and C2 remove high-frequency input noise. Capacitors are placed on both input signals to maintain a
balanced differential input impedance.
4. Anti-aliasing filters have a Butterworth filter frequency response . Gain is included in the final filter stage to
compensate for the instrumentation amplifier's inability to produce output voltages that are near either power
supply rail. The gain in the final stage is given by the equation
Gainl + (R 8 /R 7 )
Figure 6. 8. Schematic of Thermocouple Interface (Single Channel)
Differential Amplifier
The INA326 instrumentation amplifier provides buffering and amplification of
the differential thermocouple signal. Instrumentation amplifiers are perfect for this
type of application since they have very high input impedance and are inherently
differential. Note the biasing resistors that are connected to each side of the ther-
mocouple signal to provide open thermocouple detection and that provide a DC
bias path required by the instrumentation amplifier for proper operation.
Antialiasing Filter
The antialiasing filter has one primary task: to keep frequencies higher than half the
sampling frequency from contaminating the sampled signal. At first glance, it might
seem that we would want to use a high-order analog filter for this task so that we
188 Chapter 6
could get extremely strong filtering, but in many cases this approach is not the best.
In a previous chapter, we've alluded to the shortcomings associated with analog filters
(drift, cost, board space), and these problems are exacerbated the more complex the
filter becomes. Instead, we'll go with a pair of cascaded second-order Butterworth
analog filter up front and then do the heavy lifting with our DSP filters. This filter
structure is optimally flat through the passband and has a fairly sharp rolloff of 20
dB/decade/pole, 14 as can be seen in Figure 6.9.
dsPIC I D - {Magnitude]
- n>
W £Je View Qesipn Filter Qutput £edegen ^/kIqw
-Iffl x
3PC
1?
a| m\m\ \m u 3 51 [h H[M| ffl] W
y a
■tPT. FIT
r. I hat
. 1
Magnitude vs Frequency
9
C
m
1.U
1 | 1 ! ; ! !
i i i
• ■ i i §
i i
i i i
i ■)■
ca
i i i
■ > i
ii * » i
i i
: 1 i i
■ I i i
!• i i
i • » i
i i
• -ii
06
y
i iii
i ■ ■ i
■ i •■■
i • •
i • i ■ i
■ i i
: :
i i
■ i ■ i
Di
'l
ii i i i i
■ i i i
• i
ii i
•
i i ii
: \
■ i ii
: : : : :
■ I > i i
■ i i
ii iii
; i
■ I i i
i iii
U.2
■ i*i
• ■ i
ii i i
i . . .
ii i ■
0.0
i iii'
■ I i » i
; ;
D
50
^-r
IM
230
2f-3
Frequency (Hertz)
Sampling Frequency 500
Passband Frequenc/ 10
Stop band Frequency 30
passband rip dig 0.01 c as ;•
Stop band Ripple 3 (-dB)
All Frequencies in Hertz
16 Bit Fixed Point
Lowpass Filter
IIR Design - Bilinear Transformation
Buflerworth - Cascaded Second Order Sections
Filter order 4
dsFIC FD Version 1.0.0 Build i - 09:05:15 Aug 23 200'3
Creed Hudd lesion
Ready
Simp Off Qtfi
Figure 6.9. Frequency Response of Butterworth Filter
Digital Filtering Analysis
In this example, the power signal is considered to be out-of-band noise, allowing
us to use a sharp low-pass digital filter to reduce noise on the temperature signal.
If our temperature signal were more broadband, we would need to include a notch
filter also, as we'll see in the next chapter.
There are a number of packages available with which to design digital filters, but
the one used for this book is the Microchip Digital Filter Design System, vl.0.0.
As with the other development software discussed here, the filter design package is
available through Microchip. 15 One of the nice aspects of using a software package
Sensor Ap plica tion — Tempera ture Sensor 189
to design the filter is that its easy and quick to get graphical feedback on the filter's
characteristics. For instance, Figures 6.10 and 6.1 1 show the effects of specifying a
looser (Figure 6. 10) and a tighter (Figure 6. 1 1) stopband ripple requirement. As we
can see, tightening the ripple specification also affects the passband ripple and the
width of the passband window, introducing more ripple into the passband while
both broadening the passband a bit and creating a sharper transition between the
passband and the stopband.
P^ dsPIC J L) - [Magnitude!
r?
KJj gle *ftett Qesign F|ter Qutput £odegen Window
[
L«^rV
■>:
m\m\ DBlsiiniiD Blmlfflj □
Bl Q
SPC FIT
DAT
y //wjj
ia
Magnitude vs Frequency
i
1.0
A ! 1
1 i f
• 1 »
■ ' 1
R
1 > 1
1
» ■
na
\ 1 : 1
•
R fc 1
1 k »
R k
• »
A i i i I
■ 1 ■ ¥ R
1 i i i r k
I'll »
o.e
R 1 R
■
• 1 fc
i
I R R
» '
■ f »
R *
«
•
■ k
■ k k
k k
D.i
1 ■
i ■ k i
k k
k ►
•
R R 1
R » 1
1 1 1
R
1
■ '
a i ■
■ . i
R 1 1
R *
R R >
I 1
R ' 1
«
•
1
■ . ■
■
..
fl (1
'■■.
R
k fc
k k
k
k I r
o hi iag tso 7on
Frequency (Hertz)
Sampling Frequency 500
Passband Frequency 15
Stopband I requenqy 25
Passband Rjppte 0.1 ( ■ dB)
Stopband RippJe 10 (-dB)
All Frequencies in Hertz
15 Bit Fixed Point
Lowpass Filter
FIR (Window) Design
Gaussian Window
Filter Length: 51
dsPIC FD Version 1 0.0 Build 1 - 03:22:00 Aug 28 2006
Imp I erne nil ng intelligent Sensors
Thermocouple interface
Rcody
Figure 6.10. Filter Response for Loose Stopband Ripple Specification
Although the filter with the looser stopband ripple requirement initially might
look like a better filter since its passband is flatter, as we can see from the upper left
corner of its Magnitude vs. Frequency graph in Figure 6.10, the filter passes just
over 78% of the input signal at 6 Hz. In contrast, while the filter with the tighter
stopband ripple requirements obviously has more ripple in both the passband and
the stopband (not what we'd necessarily expect, but still within spec), it also passes
more of the signal at 6 Hz (82%) and has a sharper transition between the passband
and the stopband. All of this demonstrates that filter design is a game of compromise,
with the designer having (or getting, depending on one s perspective) to trade off
better performance in one area for worse performance in another.
190 Chapter 6
W dsPIC FD - IMagnitude]
W Ble jAew £esicn Filter Qutput £odegen ^Kndaw
! M l\ m \ MM ■ & 35 |H B| Ml ffli □ IS
B.£tt37Qfl
y
XPT.
y
FIT
Q □
r. hat
^ISlii
9
3
Z
-
Ready
Sampling Frequent 500
Passband Frequency 15
Stopband Frequency 25
paGSDsno Rippico 1 ( aB)
Stopband Ripple 3 (-dB)
All Frequencies in Hertz
16 Bit Fixed Point
TS
Magnitude vs Frequency
1.U
\
\ * i i i
V 4 1 1 1
\
I 4 1 1 1
1 4 li i 1
\ i 1(1
\ « 1 1
1 ' • 1
, -
06
II ■ |
'i i l k i
1 4 k 1 i i i
1 4 • 1 I k 1
\ 4 i 1 i i
1 ' '
\ • '
■ i •
4i k I
III • 1
\ I ll
III I i
III ll
4 111 J 1 1
'| . , , ...
Ill 1
1 • 1
[
■ 1
L . ■ . ■
1 4 k I i
i . ■■
\ • ■ i i
I i ■ i i tit
|ii
14 i iii
0.2
ft
I . . iii
iii .i
A p l l i»i
II p [ i • i
41 p i i iii
M p 1 iii
* | ■ i i iii
4 1 1 1 l ill
' 1 i » I
• \ I i i
.... ...
1 \ |
Q
50 in: 150 230 25
Frequency (Herti)
••-
Lowpsss Filter
FIR (Window) Design
Gaussian Window
Filter Length: 51
dsPIC FD Version 1 .0.0 Build 1 - 03:1 5:16 Aug 28 200G
Implementing Intelligent Sensors
Thermocouple interface
Snap Off Q'f.
Figure 6.11. Filter Response for Tighter Ripple Specification
For this application, we'll go with the somewhat looser filtering requirements since
they meet our needs and don't affect the signal quite as adversely. The principle of
filtering as lightly as necessary (but still enough to get the job done) is a sound one
to follow in general, since it avoids excessive modification of the original signal. In
this regard, the principle is not too far from the injunction to physicians to "first,
do no harm." 16
One other aspect of the digital filter should be noted. In both cases, the filter has
51 taps. While we could certainly improve the performance of the filter by adding
more taps, doing so would add to the delay the signal experiences going through
the filter. For this application, we intentionally selected a relatively short filter to
allow the system to be more responsive.
Data Analysis Algorithms
The data analysis needs for this application are pretty simple, basically requiring
that we check each filtered temperature sample against a lower and an upper alarm
limit that's been set by the user, and lighting an alarm whenever one or the other has
been exceeded. A flow chart illustrating this rather limited data analysis is shown in
Sensor Application — Temperature Sensor 1 91
Figure 6.12. Although the analysis presented here is admittedly simple, notice how
easy it would be to extend it to include more complex analysis or perhaps to add
an output-control algorithm. This is the type of structure that designers should try
to employ whenever possible: simple, clean, and easily extensible. Not only is such
a framework more reliable, it also is easier to add in new features as the product
matures.
AnalyzeChannelQ
Clear Open
Thermocouple Flag
Clear Reversed
Thermocouple Flag
YES
Set Open
Thermocouple Flag
YES
Set Reversed
Thermocouple Flag
Sample < Alarm
Lower Limit?
Clear Low Alarm Flag
i
Set Low Alarm Flag
Turn on LED 1
i
Turn on LED 1
YES
Clear High Alarm Flag
i
Set High Alarm Flag
Turn on LED 2
I
Turn on LED 2
return
Figure 6. 12. Data Analysis Flow Chart for Thermocouple Sensor
192 Chapter 6
Communication Protocol
Application developers sometimes mistakenly equate a communication interface
that works under nominal conditions with one that works under all conditions,
including errors in the physical medium used by the communication interface. A
good designer takes into account all situations that are likely to arise and develops
a way for the system to degrade gracefully when it encounters unanticipated condi-
tions as well. This "graceful degradation" is extremely important; even if the system
can't correct an error, it should alert its host and then take any actions required to
ensure that it is in a state in which the system can operate safely. Implementing
a state-based communication interface that automatically resets itself whenever it
encounters an unexpected input goes a long way toward that goal.
This first application will use a simple (there's a theme here), human-readable
protocol over a standard RS-232 serial port. Not only does this approach allow the
user to actually interact with the system, it also allows us to wade, not plunge, into
the world of state-based communication handlers. It's the latter aspect that's the
more important of the two, because a surprisingly large number of products are
deployed with weak, unreliable communication interface implementation. There
are few things more frustrating from a user's perspective than to experience unex-
plained system failures (often with the appearance that the system has "locked up").
When such failures arise because of poorly implemented communications, they are
simply inexcusable.
Having extolled the benefits of state-based communication handling, let's now
take a closer look at what we mean by that term and how we design using state-
based approach. In a state-based handler, the actions that the application takes are
dependent upon both the current state of the handler (a value that is stored in a
global variable) and the data value being processed. Depending upon the action
taken, the state value may change or it may stay the same. An example should help
clarify the concept.
Figure 6.13 shows a state diagram for a simple communication handler. Each
circle in the diagram represents an individual processing state, and the lines extending
from a particular processing state are transition conditions, the conditions required
to change from one state to another. If no condition is given for a particular transi-
tion line, then the state machine automatically moves from the originating state to
the terminating state once all of the processing for the originating state has been
performed. For instance, looking at the Initialize state, we see one transition line
extending from it to the Accept Input state, and that transition line has no associ-
ated conditions, meaning that the state machine will cycle from the Initialize state
Sensor Ap plica tion — Tempera ture Sensor 193
Error Detected
Successful
Parse
Figure 6. 13. Simple Communication Handler State Machine
to the Accept Input state as soon as all of the processing for the Initialize state has
completed.
Once the state machine enters the Accept Input state, it remains there until it
receives an ASCII carriage return character as input. This is indicated on the diagram
by two transition lines, one with a transition condition of Data ^ CR that simply
loops back to the Accept Input state and the second with a transition condition of
Data = CR that points to the Parse Input state. Whenever the state machine receives
new data, it processes it in the Accept Input state and then either stays in that state
(if the data is not a carriage return) or transitions to the Parse Input state (if the data
is a carriage return) . Typically, the processing performed in the Accept Input state
would be something along the lines of adding the new data to a buffer, assuming
that there is room in the buffer, although it could be more sophisticated than that if
required by the specific application. In any event, receipt of a carriage return signals
the state machine that it should parse the received data to identify the action that
the user would like the system to perform.
If the Parse Input processing is able to successfully extract the user's command
from the input data buffer, the state machine transitions to the Execute Command
state, which performs the task specified by the user's command input. If, on the
other hand, the parsing detects an error in the command input, it will cycle the state
194 Chapter 6
machine back to the Initialize state, resetting the state machine to a known good
state to await the user's next input. By handling the processing like this, the system's
operation is insulated from errors in the user's input. Users can (and probably will)
make errors, but those errors will not affect the safe operation of the system.
The processing performed in the Execute Command state simply performs the
task associated with the specified command and command parameters. Once the
task has completed, the state machine moves to the next state, Transmit Response, to
report the results of the command execution. Finally, after transmitting the command
response back to the host, the state machine cycles to the Initialize state to reinitialize
the machine's state variables in preparation for reception of the next command.
Although it's certainly possible to implement the state machine in hardware, for
example in a programmable logic chip, it's far more convenient, flexible, and less
expensive to implement the state machine in software (assuming, of course, that the
processor can cycle through the states quickly enough to meet all timing require-
ments). Doing so is straightforward, but some guidance may be helpful for those
who have never designed a software state machine.
When implementing a software state machine, the application uses global state
variables to track both the specific operational state of the machine and any infor-
mation that has to be preserved when cycling to another state. The state machine
itself, at least at the highest levels, is usually implemented as a single function that
is called repeatedly with new input data to cycle the machine through the desired
sequence. If the application is using the C language, this function often takes the
form of a switch statement, with the parameter for the statement being the current
processing state. Using the example that we've been developing, the code would look
something like the following.
Code Example 6.1. Implementation of Simple Communication State Machine
II Communication State Definitions
#define COMM_ST_INIT // Initialize state machine
#define COMM_ST_ACCEPT_INPUT 1 // Accept input data
#define COMM_ST_PARSE_INPUT 2 // Parse complete line of input
data
#define COMM_ST_EXEC_CMD 3 // Execute the parsed command
#define COMM_ST_TX_RESPONSE 4 // Transmit the command response
// State Variables
Sensor Application — Temperature Sensor 195
Uint8
g_ui8CommState = COMM_ST_INIT; // Global communication processing state
/
*******************************
FUNCTION:
CommProcRxData (Uint8 ui8NewData)
*
*
*
*
*
*
DESCRIPTION: This function implements the high-level software
state machine for communication processing. It is
called by the main processing loop whenever the
processor receives new input data, and the function
cycles through the appropriate states based on the
current processing state and the new input data.
PARAMETERS :
ui8NewData - new input data to process
*
*
*
*
*
RETURNS :
The function returns the new communication processing *
state. *
REVISION:
vl.O
DATE: 12 June 2 006
Original release.
**************************************************************************
/
Uint8
CommProcRxData (Uint8 ui8NewData)
{
// Local Variables
Bool
bProcessingState = TRUE;
// Continue processing state flag (set to
//
//
//
continue processing states, cleared
to stop processing after the current
state)
// Identify the current communication state
// and process the new data accordingly
while (bProcessingState)
{
switch (g_ui8CommState)
{
case COMM_ST_INIT :
// Initialize the comm state machine
// Perform state-specific processing
bProcessingState = FALSE; // Finished processing for this cycle
// Cycle to next state
g_ui8CommState = COMM_ST_ACCEPT_INPUT;
196 Chapter 6
break;
case COMM_ST_ACCEPT_INPUT :
// Accepting new input data
// Perform state-specific processing
// Cycle to next state
if (ui8NewData == x \r')
g_ui8CommState = COMM_ST_PARSE_INPUT; // Parse the
//
//
//
//
data if
we ' ve
received
the entire
line
else
bProcessingState = FALSE; // Finished processing for this
// cycle
break;
case COMM ST PARSE INPUT:
// Parse the complete input data buffer
// Perform state-specific processing that
// returns a value of bError to indicate
// whether the parsing was successful
// Cycle to next state based on
// the success of the parsing
if (bError)
g_ui8CommState = COMM_ST_INIT; // Error detected so
// reset
// the state machine and
// wait for next command
else
g_ui8CommState = COMM_ST_EXEC_CMD ;
//No error so
// execute the
// command
break;
case COMM_ST_EXEC_CMD :
// Execute the parsed command
// Perform state-specific processing
// Cycle to next state
g_ui8CommState = COMM_ST_TX_RESPONSE;
break;
case COMM_ST_TX_RESPONSE:
// Transmit the command response
Sensor Application — Temperature Sensor 1 97
// Perform state-specific processing
// Cycle to next state
g_ui8CommState = COMM_ST_INIT;
break;
default :
// Should NEVER get here so reset
// the state machine
g_ui8CommState = COMM_ST_INIT; // Cycle to next state
break;
}
}
return g_ui8CommState;
}
There are a number of points to note about the software state-machine code.
In it, we use a global variable (g_ui8CommState) to maintain the processing state
of the machine. The code initializes the value of g_ui8CoiranState in the variable's
declaration to ensure that the state machine starts in a known state (the initialization
state), and the function updates the value of g_ui8CommState whenever the state
machine needs to change to a new state. The function returns the final state of the
machine after the routine has performed all processing for the current state, but
since the current state value is stored in a global variable already, the return value is
really for informational purposes only. To ensure proper operation, only ConimPro-
cRxDataO should modify g_ui8ConunState. Even if other routines monitor the
state by examining the value returned by CommProcRxData ( ) , they should not set
its value because this can cause deeply hidden software interactions that may cause
problems should the state-machine implementation change in future releases.
The state diagram in Figure 6.13 shows that some states require input or the
occurrence of a specific condition in order to cycle to the next state. As structured
here, the function cycles between states that don't require any user input in a single
call to CommProcRxData ( ) . Depending upon the amount of processing that must
be done and the length of time that processing takes, this approach might need to
be modified.
6.4 Hardware Implementation
The hardware block diagram shown in Figure 6. 14 shows the major hardware build-
ing blocks that will be discussed in the following sections. Note that this is one way
of designing the circuitry, not the only way, and those with greater analog design
skills should feel free to improve upon the circuitry presented here.
198 Chapter 6
Thermocouple
Conditioning
Cold -Junction
Compensation
L JsoJhejrnal_Blpc_k
Anti -Aliasing
Filter
dsPIC
ADC Module
Figure 6.14. Hardware Block Diagram
Analog Amplifier and Antialiasing Filter
A schematic for the analog amplifier and anti-aliasing filter sections is shown in
Figure 6.8. In it, we see that the amplifier has been implemented using a single-chip
instrumentation amplifier, with the output of the instrumentation amp feeding into
a fourth-order Butterworth low-pass antialiasing filter constructed of two rail-to-rail
op-amps and a few passive components. There are three key design considerations
in this section:
1. minimization of power consumption to reduce self-heating effects,
2. clean, compact printed circuit board layout to minimize crosstalk and noise,
and
3. good power-supply bypassing to reduce noise.
Low power consumption is achieved primarily through the use of low-power
ICs, a good many of which are available from a variety of suppliers. Because ther-
mocouple outputs are low-drive and low-level signals, the circuit layout is critical.
Traces to the thermocouple terminations should be as short as possible, and those
for a given thermocouple should be side-by-side and close together, if possible, to
improve common-mode immunity (this ensures that thermal and electrical noise
is coupled onto both leads equally) . Finally, using a good solid power supply with
minimal ripple and drift is extremely important, or noise from the power supply
itself (as opposed to noise on the thermocouple output) will be introduced into the
system, too.
Cold-junction Compensation
While there are a number of ways to implement cold-junction compensation, the
circuitry here uses a cold-junction compensation chip, the Linear Technologies LT-
1025, to perform that function in hardware as shown in the schematic in Figure
6.15. Selection of either J or K thermocouple compensation is hardware selectable
by moving the position of jumper Jl.
Sensor Ap plica tion — Tempera ture Sensor 199
Cold-Junction Compensation Interface
+3.3 V
C a = =
R
+3.3 V
R 4
C 4 = =
+ 1.65 V
-3.3 V
NOTES:
1 . Resistor and capacitor values should match those used for the thermocouple signal processing channels.
2. Jumper J 1 should be set to connect the "J" pin to the instrumentation amplifier if compensating for a J
thermocouple or set to connect the "K" pin to the instrumentation amplifier when compensating for a K
thermocouple.
Figure 6. 15. Cold-Junction Compensation Schematic
OUT
Here the LT1025 s voltage output is buffered and then measured by the dsPIC
DSC, which then uses a software algorithm to remove the corresponding cold-junc-
tion voltage from that measured for the thermocouples. For the greatest accuracy,
one LT1025 can be used per thermocouple input, but in practice it is usually fine to
share a single LT1025 for two thermocouples if the LT1025 is placed between the
pairs for each thermocouple (i.e., locating the pair of leads for one thermocouple
on one side of the LT1025 and the leads for the other thermocouple on the other
side of the chip). It's also possible to share one LT1025 among more than two ther-
mocouples, but the farther the cold-junction compensation chip is located from
the actual thermocouple termination, the less effective is its ability to compensate
properly.
Signal Isolation
The level of signal isolation required depends upon the environment in which the
sensor will be deployed. In many situations, the isolation requirements are relatively
minimal since the sensor is not exposed to either a harsh or a particularly sensitive
environment. In others, such as when thermocouples are placed near electrically
driven heating elements or are used to measure the temperatures of humans, the
application mandates a much higher level of isolation to protect either the sensing
circuitry or the system being measured.
200 Chapter 6
As one might expect, there are a variety of ways to isolate the thermocouple signals,
with varying levels of cost, complexity, and signal degradation. The least expensive
technique is to simply employ very high impedances between the powered sensing
circuitry and the item being monitored. The low end from a cost perspective for
this approach would be a simple op-amp buffer with high resistive inputs, which
might offer an input impedance of several MQ up to hundreds of MQ. Taking it
a step further in both price and performance, an instrumentation amplifier such
as the TI (formerly Burr-Brown) INA1 18 has an input impedance of 10 10 Q, and
it can also withstand up to 40V of common-mode voltage on its inputs, which is
extremely useful if the sensor has to operate in an environment in which there is the
possibility that a common-mode voltage may be coupled onto the thermocouple
signal. 17 As we've discussed before, this can occur if the thermocouple gets shorted
to a power line (or other nonzero voltage); if the input circuitry can't handle the
extra voltage, the sensor will be destroyed. By incorporating the over-voltage pro-
tection on the chip itself, the designer can reduce board space, assembly cost, and
parts cost. Note, however, that 40V of common-mode protection is insufficient
protection for most AC power signals, which may be 110 VAC-480 VAC in an
industrial setting. If the system must protect against those voltage levels, additional
protection circuitry is needed to knock the maximum input voltages down to levels
that the chip can handle.
Finally, at the upper end of the price and performance spectrum are techniques
that optically isolate the thermocouple signal from the rest of the system. This can
be handled using either optically isolated analog amplifiers (very expensive) or by
digitizing the nonisolated amplified thermocouple signal using an external ADC and
then employing an optically isolated digital interface to transfer the digitized data
to the processor (less expensive). Although optically isolating just the digital ADC
interface is less costly, it may not be acceptable in situations in which the sensor
must limit the currents and/or voltages to which the monitored system is exposed
(for instance, in medical applications) .
In this application, we've used the instrumentation amplifier isolation approach
since it is easily constructed, relatively inexpensive, and provides excellent perfor-
mance. Figure 6.8 shows the schematic for one channel of signal isolation using an
INA326 instrumentation amplifier.
6.5 Firmware Implementation
To simplify the firmware development, the application makes extensive use of the
Microchip 16-bit Language Tool libraries to access the dsPIC DSC's peripherals and
Sensor Application — Temperature Sensor 201
to perform DSP functions such as filtering. The following sections describe individual
elements of the firmware in greater detail to give the user a better understanding of
what's involved in using the libraries and how their use affects the coding structure.
Signal Sampling
In this application, we are using the dsPIC DSC s internal 12-bit ADC to sample the
thermocouple data. As you'll recall from Chapter 3, to configure the ADC module
we need to know the following information:
1 . the I/O port pins to use as analog inputs
2. the sampling rate
3. whether to use interleaved sampling or to generate a single interrupt after
converting all of the signals during a given sampling period
4. whether we need to multiplex the results buffer
5 . the format of the converted data
Since we're using the dsPICDEM, some of our hardware decisions have been
made for us. The dsPICDEM board uses a 5 V on-board regulator for V DD and AV DD ,
and it employs a 7.3728-MHz crystal operating in the XT with 4x PLL to clock the
dsPIC device (essentially 29.4912 MHz). In addition, several of the analog inputs
are dedicated to functions on the dsPICDEM board, namely:
Signal
Dedicated
Description
ANO/RBO
Yes
Programming Data (PGD) signal from ICD2
AN1/RB1
Yes
Programming Clock (PGC) signal from ICD2
AN2/RB2
No
Available for user
AN3/RB3
Yes
Digital potentiometer that has been low-pass filtered
AN4/RB4
Yes
Analog potentiometer RP2 - to AV DD
AN5/RB5
Yes
Analog potentiometer RP3 - to AV DD
AN6/RB6
Yes
Analog potentiometer RP1 - to AV DD
AN7/RB7
No
Available for user
AN8/RB8
Yes
Temperature sensor that has been low-pass filtered
AN9/RB9
No
Available for user
AN10/RB10
No
Available for user
AN11/RB11
No
Available for user
AN12/RB12
No
Available for user
202 Chapter 6
Signal
Dedicated
Description
AN13/RB13
No
Available for user
AN14/RB14
No
Available for user
AN15/RB15
No
Available for user
Table 6.2. Analog Input Signal Assignments
Note that ANO and AN1 are dedicated to PGD and PGC, respectively, only if
the corresponding jumpers in jumper block J8 are installed. If those jumpers are
left out, the application can use ANO/RBO and AN 1 /RBI as either analog inputs
or digital I/O pins.
This application will use AN1 1 for the cold-junction compensation input and
AN7 for the thermocouple input. The inputs are all single-ended signals referenced
to ground (the instrumentation amplifiers having already taken care of the conver-
sion from differential to single-ended signals), and they are scaled to use the full
range of the analog supply voltage (AV SS to AV DD ) .
Digital Filter Implementation
Thanks to Microchip s DSP library and its dsPIC Filter Design™ software, the simple
digital filtering that we'll be doing in this application basically becomes a matter
of generating the correct filter coefficients in Filter Design and then implement-
ing the FIR digital filter structure using the functions included in the DSP library.
First, though, we need to look at the basic structure the library uses to process data,
and we need to understand the limitations that using the library impose upon our
application. These limitations include restrictions that apply to the library in general
and those that are specific to its filtering routines.
The DSP library uses fractional vectors to store the data upon which it operates.
Although it may sound impressive, a fractional vector is simply an array of two-byte
data elements that use the 1.15 data format to represent each element s numeric value.
The library has two requirements for a fractional vector: the array elements must
be contiguous (i.e., linked lists are not permitted), and because they are 16-bit data
values, the array must start on an even memory address. These minor restrictions
are a direct consequence of the underlying dsPIC hardware and allow the library to
employ the processor's specialized DSP engine to optimize mathematical operations.
It's also important to note that, in general, the library functions are designed to
operate on fractional vectors that have been allocated in the default RAM memory
spaces (X-Data or Y-Data memory). 18 The filtering routines further restrict where
Sensor Application — Temperature Sensor 203
certain data can be placed in memory; input and output data samples may reside
in the default RAM memory spaces (X-Data or Y-Data), but filter coefficients can
be in only X-Data or program memory, and the filter delay values must reside in
Y-Data. 19
Of course, all of the normal mathematical rules for handling vectors apply, as
do common-sense programming policies such as having destination vector buffers
that are large enough to handle the results of the specific mathematical operation.
The reader should note that, for purposes of speed, the DSP libraries perform no
checking of inputs or outputs for validity, and while the libraries do set the saturation
and overflow flags, their functions do not make use of them. Unless the applications
data specifically precludes this from happening, the programmer should check these
flags following the conclusion of each call to the library.
For this application, we'll use the following parameters:
Sampling Frequency: 500 Hz
Passband Frequency: 1 5 Hz
Stopband Frequency: 25 Hz
Passband Ripple: 0.1 dB
Stopband Ripple: 3 dB
Filter Type: Gaussian
Entering these parameters into the dsPIC Filter Design program and generating
code for the resulting filter (stored in SensorFilter . s) provides us with the filter-
ing data structure we need.
Data Analysis Implementation
The data analysis for this application is extremely straightforward: convert the filtered
data to the corresponding temperature and then compare that temperature against
an upper and a lower limit. While the processing is basic, these operations form the
elements of not just a temperature monitoring system but also of any temperature
control system. Never underestimate the power of simplicity...
Error-handling Implementation
As with the data analysis, we'll keep the error handling pretty simple in this appli-
cation. Note that when we talk about error handling in this context, we mean
unexpected conditions that adversely affect system operation, not the temperature
out-of-range condition checked by the data analysis routines. The difference is subtle,
204 Chapter 6
but important. While an out-of-limits temperature condition may not be desired,
it's perfectly valid for the system, and its occurrence doesn't prevent the system from
operating properly. The error conditions that we discuss here are fundamentally
different, however, because if they're not detected, the system will report invalid
information and act upon it, possibly with disastrous consequences.
We'll check for two basic error conditions that commonly occur in temperature
measurement systems: an open (broken) thermocouple and a reversed thermocouple.
Each of the two conditions manifests itself slightly differently, and each affects the
system operation to varying degree. For instance, an open thermocouple is basically
a catastrophic failure that the application can detect but can't correct. In contrast,
the system can compensate for a reversed thermocouple. Although, or perhaps
because, an open thermocouple is a catastrophic failure, it's a relatively easy condi-
tion to identify; we're able to identify an open thermocouple simply by checking
the raw input signal level against a threshold. Because we've attached pull-up and
pull-down resistors to the thermocouple inputs, a broken thermocouple allows the
input signal level to rise to near full-scale, which is clearly well outside the range of
any valid thermocouple signal output.
Detecting a reversed thermocouple is more challenging because there are tem-
perature ranges that produce a "valid" thermocouple output signal when the leads
are reversed — i.e., temperatures whose corresponding outputs are within the voltage
levels expected for the overall temperature range. The only way to know for certain
whether the thermocouple leads are reversed is to look at the output voltage when
the temperature changes. On a normal thermocouple signal that has been linearized,
the output voltage increases (becomes more positive) as the temperature increases;
if the thermocouple leads are reversed, the output voltage decreases (becomes more
negative) with increasing temperature. If one has a thermal source available — for
instance, when a heating element is paired with a thermocouple, the system can
turn on the heater for a short period of time and check for a rise in the correspond-
ing thermocouple's output voltage. If the voltage goes up when heat is added to
the system, the wiring is correct (at least from a polarity perspective); if the voltage
decreases, however, then the thermocouples are reversed. Obviously, if one had a
cooling source (for example, in a refrigeration application), the same test could be
applied, with the understanding that one would expect the voltage to decrease when
the cooling element was activated.
The more difficult case occurs when no heat or cooling source is available, because
then the only approach is to wait for the thermocouple output signal level to exceed
the expected voltage limits in a negative direction (assuming we're applying heat to
Sensor Application — Temperature Sensor 205
a system) or in a positive direction (in a cooling application). Once that condition
has occurred, though, the firmware can flag the error and report it to the user.
Communication Protocol Implementation
The communication protocol used in all three sample applications was discussed in
Chapter 4. We use UART 1 to transfer data via a standard RS-232 interface to the
host system, and since the protocol's basic command structure supports everything
we need for this particular application, we don't need to extend it at this point. To
illustrate the way communications could be implemented using either a human-read-
able text protocol or a machine-readable binary protocol, the example code allows
the designer to use either technique by simply uncommenting the appropriate line
in the header file ProtocolDef .h.
The basic approach to processing data is to check for received data in the main
processing loop using the function CommisRxPendingO and, if new serial data
is available, to read it in with CommGetRxData ( ) and then to process it by calling
ProtocolProcRxData ( ) with the newly received character. This function parses the
data, and when a complete command message has been received, it calls the proper
command handler through ProtocolProcMsg ( ) . After identifying the command,
ProtocolProcMsg( ) calls the corresponding low-level command-handler routine
and transmits the appropriate response back to the host using the command-specific
response routine. Once the response has been sent, ProtocolProcRxData ( ) resets
its parsing state machine to await the next message.
6.6 Summary
In this chapter, we've gotten our design feet wet with a brief dip in the sensor design
pool. We're now able to digitize an analog sensor signal, filter it to remove unwanted
noise, analyze the filtered data to extract some useful information, and communicate
that information to other components in our system. As we develop more complex
systems, we'll continue to use our framework as the foundation upon which we
build. Let's now turn our attention to extending our framework a bit in the next
chapter with our second design, a pressure/load sensor system.
206 Chapter 6
Endnotes
1 . Temperature Technology Claimed to Eliminate Ambient Variations, InTech
magazine, December 1998.
2. Information on the Seebeck effect is widely available. One such resource is
Electromagnetic & Electrmechanical Machines, 2nd Edition, by Leander W.
Matsch. Copyright 1977 by Thomas Y. Crowell Company Inc.
3. The reference information for both RTDs and thermistors is taken from
http://www.omega.com/techref/measureguide.html and from http://rdfcorp.
com/anotes/pa-r/pa-r_0 1 .shtml.
4. Emissivity is usually denoted as a percentage between 0% and 100% or as a
fraction between and 1 . In both cases, lower numbers represent less efficient
emission of infrared radiation. The discussion of the relative emissivity values
comes from http://www.omega.com/techref/measureguide.html.
5. In injection molding, molten plastic is usually referred to as melt, and the
leading edge of the molten plastic is called the melt front.
6. For those of you who, like me, are not chefs, just picture a warm soggy
mess.
7. The ITS-90 Tables of Thermoelectric Voltages and Coefficients can be
downloaded from the NIST website at http://srdata.nist.gov/its90/down-
load/download.html.
8. Data taken from the Omega Engineering, Inc. table found at http://www.
omega.com/temperature/z/tcref.html.
9 . Clipping occurs when the theoretical value of an analog output signal exceeds
the actual output signal level because the circuit is incapable of delivery the
desired output voltage. An example of this would be an amplifier circuit
with power rails of ground and +5V and a nominal gain of 10. Any input
signal between OV and 0.5V will be amplified correctly, but input signals
greater than 0.5V will have an output voltage of only 5V, since the circuit
can only produce a maximum voltage equal to (or at least near) its power
supply voltage.
10. A good indication that the ADC circuitry is excessively loading the sensor
output is that the sensor output signal looks normal when viewed on an
oscilloscope but then changes significantly when connected to the ADC
input. Such changes may be in the form of reduced signal swing when the
Sensor Application — Temperature Sensor 207
sensor's input is varied or in the form of the sensor signal appearing to go to
one of the two power voltages for the ADC.
1 1 . Murphy 's Law basically states that whatever can go wrong, will go wrong, and
that given the choice between two items having a problem, the more critical
of the two will be the one that fails.
12. Temperature velocity is simply the temperature change versus time and is
analogous to the standard concept of velocity, which is simply the distance
change versus time.
13. Circuit Provides Cold-Junction Compensation, by Mark Maddox and John
Wynne. EDN Magazine, November 11, 2002, http://www.edn.com/article/
CA260064.html.
14. The website http://www.daytronic.com/reference/aliasing.htm has a brief
but informative discussion of the use of the Butterworth structure as an
antialiasing filter.
15. The full version of the Digital Filter Design software is Microchip's part
number SW300001. A reduced- feature version of the package also is avail-
able for significantly less, the key differences being that the less expensive
version does not support as many FIR and IIR filter taps nor does it offer
MATLAB support. In many cases, the "light" version of the software is
completely adequate. The part number for the reduced-feature version is
SW300001-LT
16. Although the quotation "first, do no harm" is often mistakenly credited to
Hippocrates, it is not found in the Hippocratic Oath. One possible source
is from his work Epidemics, in which he states that physicians must "... have
two special objects in view with regard to disease, namely, to do good or to
do no harm" according to http://ancienthistory.about.com/od/greekmedi-
cine/f/HippocraticOath.htm.
1 7. There are a great many instrumentation amplifiers from a variety of manufac-
turers that work well in this capacity. The TI part is simply one with which
the author is well acquainted.
18. This note appears in the section, User Considerations, of the 1 6-Bit Language
Tools Libraries user's guide.
19. The requirements for memory space usage by the DSP filtering routines are
found in the section, Fractional Filter Operations, of the 16-Bit Language
Tools Libraries user's guide.
This Page Intentionally Left Blank
Sensor Application —
Pressure and Load Sensors
No pressure, no diamonds.
— Mary Case
With the temperature-sensing application we developed in the previous chapter,
we gained a level of practical experience in the design of a sensor system. We now
build upon that experience by extending the basic sensor framework to support load
sensors and pressure sensors weight. It turns out that load sensors, which measure
weight, and pressure sensors, which measure weight over a given area, have wide
application in a tremendous number of diverse fields. Whether it's to count the
number of tiny electronic parts by weight, to measure a patient's blood pressure, or
to control the pressure exerted on a diamond-tip drill, load and pressure sensors are
an integral part of our everyday life, whether we realize it or not.
7.1 Types of Load and Pressure Sensors
Before getting into the subject too deeply, it's important to realize that load sensors
and pressure sensors are essentially identical. They both measure the load (or weight)
on the sensor; the only difference is that a pressure sensor's output is scaled to divide
that weight by the area of the sensor. For instance, one commonly available type of
pressure sensor comes in an armored cylindrical package for use inside high-pres-
sure environments that would otherwise destroy the sensing element. When the
pressure sensor is monitored, its output signal reflects the force exerted upon the
flat portion of the cylinder (assuming that it was installed properly) . Knowing the
diameter of the sensor, the application can then scale the measurement to compute
the corresponding pressure.
An example may help. Assume that we're employing a cylindrical sensor like the
one mentioned above, and further assume that the cylinder has a diameter of 0.125
inches (1/8 inch). If the sensor measures a force of 100 lbs on it, the corresponding
pressure is given by the equation:
209
210 Chapter 7
Pressure = Load / Area
= Load / (K r 2 )
= 100 lbs. / ((3.14)(0.125 inch) 2 )
= 2,038 psi 1
If that same 100-lb force were exerted on a sensor with only half the diameter
of the first sensor (i.e., a diameter of 0.0625 or 1/16 inch), the corresponding pres-
sure would be
Pressure = 100 lbs / ((3.14)(0.0625 inch) 2 )
= 8,153 psi
There are two types of sensors that are most commonly used to measure load
and/or pressure in monitoring and control applications today: the strain gage and
the piezoelectric sensor. While the discussion that follows is not an exhaustive treatise
on the two sensor types, it should give us the information we require in order to
interface to them and to get a feel for their application.
Strain Gages
In a nutshell, a strain gage is a device that changes its resistance in response to the
force exerted upon it. This effect was first reported in 1856 by Lord Kelvin, but
it wasn't until 1938 that it was put to practical use, since the change in resistance
tends to be very small even for large changes in load. Interestingly, it was a circuit
perfected way back in 1 843 by the English physicist Sir Charles Wheatstone that
allows us to measure those small changes accurately (see Figure 7.1).
I
Ex +
Ra ^Rsg
SG + 1_SG +
Rb >r
t
Ex-
Figure 7.1. Schematic of a Wheatstone Bridge Strain Gage
In the circuit, Ex+ and Ex— are connections to an external excitation voltage that
powers the circuit, and SG+ and SG- are the outputs whose differential voltage we
measure. This arrangement of resistors produces an output voltage that is ratio-
metrically related to the values of the resistors in each leg of the bridge. If we match
the resistances in the SG— leg (Rl and R3) to the corresponding resistances in the
Sensor Application — Pressure and Load Sensors 21 1
SG+ leg (R SG and R4), we'll get a zero output voltage. That may not seem to be a
particularly startling fact, but it allows us to easily track changes in the resistance of
a particular element because those changes show up in the form of a nonzero output
voltage. As the reader has probably already anticipated, by placing the strain gage
element as one of the resistors, we can measure accurately the changes in resistance
caused by a force applied to the strain gage.
Load cells employ strain gages arranged in a bridge configuration to measure the
force exerted upon a particular mechanical axis. The thermocouples we examined
in the previous chapter are known as passive sensing elements because the change in
the sensed parameter (in this case temperature) produces the sensor's output signal
energy. In contrast, load cells are active sensing elements in which the change in the
sensed parameter modulates an externally supplied excitation voltage. This gives
the designer an additional degree of freedom since he can select excitation voltage
characteristics that optimize parameter measurement, but it also requires additional
circuitry to supply the excitation voltage and adds heat to the system that can degrade
the sensor readings.
Like thermocouples, strain-gage load cells produce a small output voltage, usu-
ally expressed in terms of millivolts per volt of excitation voltage. This requires
careful signal conditioning, but we can use the ratiometric characteristics of the
bridge output to enhance our ability to measure these small signals. Because they
are fairly easy to use and relatively inexpensive, strain-gage load cells are the most
commonly used type, and it is that type of load cell that we will use in the applica-
tion we develop in this chapter.
Piezoelectric Sensors
A second popular type of load sensor is the piezoelectric sensor, which is based upon
the property of certain materials that produce a tiny electrical charge when a force
is applied to them. 2 This output is extremely small, on the order of nanocoulombs, 3
and special circuitry known as a charge amplifier is required to convert these small
changes in charge output to a voltage that can be measured by an external system.
Piezoelectric sensors are generally used in applications in which the load is
dynamic — i.e., changing on a regular basis — because the response of the sensors to a
rapidly changing load can be better than strain-gage load cells. That advantage may not
necessarily translate into better readings, however, if the response of the system being
measured is much less than that of the sensor itself. In addition, piezoelectric sensors are
generally not as accurate in situations in which the load is relatively constant because
the charge output tends to die out over time when presented with a constant force.
212 Chapter 7
Unfortunately, charge amplifiers are expensive to purchase and difficult to build,
which reduces the number of applications in which piezoelectric sensors can be used.
However, in situations demanding the greatest frequency response, the additional
cost for piezoelectric sensors may be mandated by the application requirements.
7.2 Key Aspects of Load Measurement
In general, the key aspects of load measurement are the same as those for any sensor
system, namely range, resolution, and accuracy of measurement. While some of the
challenges faced in load measurement as well as the signal characteristics are unique
to this application, other considerations such as linearization and calibration are
common sensor issues.
Range of Measurement
Because load-sensing applications cover such a broad range of load values, from
micrograms to kilotons, the designer needs to determine the appropriate load range
that the specific application will support. One key point that many engineers over-
look (at least the first time) is the need to specify both the normal operating range
and the worst-case dynamic range. A package- weighing system that is intended to
handle a range of, say, to 200 pounds may see an instantaneous force of several
times that if a package is accidentally dropped from a height of a couple of feet. Not
only is this a mechanical consideration (the system needs to be able to withstand
the blow without being physically damaged), but it also requires that the signal-
conditioning circuitry be such that the resultant instantaneous voltage signal does
not damage any of the electronics.
As an example, we might design a pressure-sensing system with a normal operat-
ing range of 0-20,000 psi and a maximum range of 30,000 psi. This would be a
reasonable range for measuring the cavity pressure (the pressure inside the mold) of
an injection-molding machine. By choosing an operating range of 0-20,000 psi,
we're basically saying that we want to maintain the greatest accuracy over that range,
so we'll use those two points as our calibration points.
Resolution of Measurement
Assuming that we amplify the input signal so that the minimum and maximum
parameter values correspond to AV SS and AV DD , respectively, the measurement reso-
lution is obtained by dividing the maximum range by the number of ADC levels
available to us (1,024 levels for a 10-bit ADC, 4,096 levels for a 12-bit ADC, or
65,536 levels for a 16-bit ADC). In this case, we're going to use the dsPIC30F60l4A's
Sensor Application — Pressure and Load Sensors 213
on-chip 12-bit ADC, so we'll have 4,096 levels with which to work. Given the
30,000 psi range (remember, we have to use the maximum range we want to measure,
not just the operating range), that translates to a measurement resolution of about
7.3 psi/level (30,000 psi/4,096 levels = 7.32 psi/level).
If we require additional accuracy, we would need to employ a higher resolution
external ADC. For most injection-molding applications, however, this resolution
is perfectly adequate.
Accuracy of Measurement
Another consideration is the accuracy of the measurement. This depends upon the
entire signal chain from sensor through the ADC and requires careful attention to
the analog signal-conditioning circuitry, the excitation voltage generator, the accu-
racy of the ADC, and any signal degradation due to thermal changes. Inaccuracy in
the signal chain is cumulative, so each link in the chain is important. As a starting
point, bridge- type load cells can be accurate to approximately 0.1%, though that
depends upon the specific model selected.
Challenges
The challenges with bridge-type load cells are similar to those facing thermocouple
signals, primarily the very low- voltage nature of the output signal (at least at low
loads) and the degradation of the sensor's accuracy with changes in temperature.
Signal Characteristics
We've already touched on the load-cell signal characteristics a bit, namely that they
are relatively low-voltage, on the order of a few millivolts to a few hundred mil-
livolts. The signal range is affected by the excitation voltage level, but the designer
usually has to balance the advantages of using a higher excitation voltage (which
generates a greater output signal range) with the disadvantages of the associated
self-heating effects.
While the frequency response of load-cell sensors are sensor-specific, in general they
can be used to measure signals with frequency contents of tens of hertz up to hundreds
of hertz. Using the conservative approach of a five-to-one ratio of sampling rate to
frequency content, the designer should expect to sample at rates of 100 Hz to 1 kHz
or more, depending upon the application. Obviously, applications in which the load
is not changing during the measurement period can be sampled at far lower rates.
214 Chapter 7
Thermal Compensation
The self-heating effect is most pronounced in applications that employ a large
excitation voltage and that have limited thermal dissipation paths (such as in a
hermetically sealed enclosure). Since we are using a low excitation voltage (5V) in
our application, self-heating is not a concern; however, in situations that do have
to worry about self-heating, the effect can be minimized by pulsing the excitation
voltage using a low duty cycle. In such circumstances, the signal sampling must be
synchronized with the duty cycle of the excitation voltage so that sampling only
occurs when the excitation voltage is "on." This technique can also be employed to
allow the use of a larger excitation voltage (say 10V), but care must be taken to ensure
that the excitation voltage cannot damage any other circuitry. For instance, since
this application uses the excitation voltage as the reference voltage, for the dsPIC's
ADC, the excitation voltage is limited by the dsPIC DSC s electrical specifications
for the reference voltage, even though the sensor output signal itself would be well
within the valid input range for the ADC, even with a higher excitation voltage.
Linearization
Unlike thermocouple sensors, linearization is not a particularly significant issue for
strain gage-based load cells, since the bridge's output is pretty linear over the load
cell's operating range. This greatly simplifies the designer's task, since he can dispense
with any special linearization hardware or software.
Calibration
Calibrating a strain gage-based load cell can be physically difficult depending upon
the application. In some situations, particularly those for weighing, the designer
can assume that the force exerted by the load will be perpendicular to the ground.
Assuming that the maximum load is "reasonable" (an admittedly loose definition),
the user may be able to calibrate the sensor system by simply using two standard
weights near the upper and lower ends of the expected operating range. The system
would log the measured value of the sensor output voltage at each calibration point
and then compute a straight-line calibration gain and offset value as we did for the
thermocouple-based system.
Unfortunately, we're often not in a position to calibrate the system so easily,
either because the loads are not "reasonable" (e.g., it's not particular feasible in most
circumstances to swap out a 100-pound load and a 50,000-pound load as calibra-
tion points) or because the physical characteristics of the system being measured
preclude the use of calibrated physical loads. An example of the latter condition
occurs in injection-molding machines, which often have vertically mounted sensors
that measure the pressure of the plastic melt inside the mold. It's not possible (or
Sensor Application — Pressure and Load Sensors 215
at least feasible) to somehow apply a calibrated 20,000-psi physical load to such a
sensor, so we have to find an alternative approach.
In these situations, a fairly common technique is to apply a known resistance
across the load cell output and then to use the resulting output voltage as the upper
calibration point (the lower calibration point being the unloaded sensor output
signal). Although this may sound crude, it works fairly well in practice and often is
the best option available, whether we like it or not.
Sources of Noise
Noise can get onto the load-cell output signal through a number of different sources.
AC power noise can be coupled onto the excitation voltage leads going into the sen-
sor, onto the output signal leads coming from the bridge, or both. Assuming that the
leads are close to one another (and ideally constructed as twisted pairs), the coupled
noise is common-mode in nature and thus can be removed for the most part by a
differential amplifier for the signal input and by the ratiometric nature of the ADC
measurement. That's important, because a 50 Hz or 60 Hz power signal can be right
in the middle of the valid frequency content of the signal we're measuring.
If the inherent noise-rejection characteristics of the circuitry don't remove the
AC noise sufficiently, the designer can always employ a digital narrow-band notch
filter with the notch centered at either 50-Hz or 60-Hz (depending on the power
frequency) . Although this adds to the complexity of the software and degrades the
measured signal somewhat, such a filtering arrangement may be necessary depend-
ing upon the application and the electrical environment.
Error Conditions
Load cells are subject to several possible error conditions, including:
1 . a broken lead to/from the sensor,
2. a damaged bridge element in the sensor,
3. reversed excitation voltage leads, and
4. reversed output voltage leads.
All of these conditions can be detected by measuring the resistance across the
various sensor leads, but allowing the system itself to do so requires some additional
circuitry and reduces the number of ADC channels available for load-cell output
signals, since some of those channels must be used for diagnostics. Of these condi-
tions, the first three are "fatal" in the sense that the system cannot operate if they
exist. It's possible to recover from the fourth condition (reversed output voltage
leads) if it has been detected.
216 Chapter 7
7.3 Application Design
The application design is a fairly simple weighing device that uses a load cell to
accurately measure the weight of an item between and 50 pounds. To simplify the
calibration, we'll use the known load resistance approach, switching in a resistor of
a known value to serve as the upper calibration point.
System Specification
The system uses the Microchip dsPICDEM vl.l board as the hardware platform
and performs the following tasks:
1. Measure a load of between and 50 pounds, with a resolution of 0.25
ounce.
2. Maximum load of 64 pounds.
3. Sample a single load channel at a rate of 1 kHz (assumes a maximum fre-
quency content of 200 Hz).
4. Filter the sampled data to remove 60-Hz power-line noise.
5. Allow the user to perform the following functions via the RS-232 serial
port running at 38.4 Kbps, 8 data bits, 1 stop bit, no parity, and no flow
control:
a. perform calibration of the unit,
b. specify an upper and a lower limit for the measured weight.
6. Report the measured load every second via the serial port. Load reports are
to be in text.
7. Report out-of-limit alarm conditions by lighting LED 1 on the demo board if
the measured temperature is less than the lower limit and by lighting LED2
if the temperature exceeds the upper alarm limit.
As with the temperature-monitoring system, if the information is to be read by
other electronic components in the system rather than by humans, a faster binary
data protocol would be appropriate, and as with the thermocouple example, one is
provided in the sample code.
Sensor Application — Pressure and Load Sensors 217
Sensor Signal Conditioning
The block diagram for the load-cell interface is shown in Figure 7.2, and it consists
primarily of an instrumentation amplifier with gain to condition the load cell's
output signal, the excitation voltage source, which in this case is the system's 5V
power, and a pair of cascaded second-order Butterworth antialiasing filter to limit
the frequency content of the amplified signal prior to sampling by the ADC. In
addition, the interface includes a relay that allows the processor to switch in a resis-
tor of a known value as the calibration shunt.
Strain Gage
Signal
Conditioning
Anti -Aliasing
Filter
Calibration
Circuitry
ADC Module
Digital I /O
dsPIC DSC
Figure 7.2. Block Diagram of Load-cell Interface (Single Channel)
Note that we're able to use the same differential amplification circuitry (albeit
with a different gain) and the same Butterworth filter topology (though with dif-
ferent component values to accommodate the broader bandwidth) that we used to
condition the thermocouple signals. The schematic for the actual circuitry is shown
in Figure 7.3. As with the temperature measurement example, the schematic is for
a 3.3V system; when running on the dsPICDEM 1.1. GPDB, change all references
for 3.3V to 5V, all those for -3.3V to -5V, and that for 1.65V to 2.5V
Digital Filter Analysis
Because the AC power noise is considered to be in-band with the signal we're mea-
suring, we need to use a sharp notch filter to remove it. The frequency response of
the filter we'll use is shown in Figure 7.4.
Data Analysis Algorithms
The data analysis algorithms are extremely simple and basically consist of the same
analysis algorithms employed by the temperature monitor with minor changes. The
algorithms simply check each filtered sample to determine whether the sample value
is outside either the upper or the lower alarm limits and then lights the appropriate
LED if that is indeed the case.
218 Chapter 7
Load Cell Interface Circuitry
Calibration
CALENBL
+3.3 V
R
+3.3 V
R
G
+ V
OUT
RG 2 Vref
V.
R 2
-3.3 V
-3.3 V
Primary Signal Gain and Level
Shifting
NOTES :
1 . R-i and R 2 provide an input common-mode current path
and a way to determine whether the strain gage is
actually connected to the circuit. Resistor values should
be identical and be approximately 1 MQ to avoid loading
the input signal with too low an input impedance
(particularly during calibration).
2. Gain through the instrumentation amplifier is controlled by
Rg according to the equation
Gain = 1 + (50 KQ. /R G )
3. Anti-aliasing filters have a Butterworth filter frequency
response. Gain is included in the final filter stage to
compensate for the instrumentation amplifier's inability to
produce output voltages that are near either power supply
rail. The gain in the final stage is given by the equation
Gain = 1 + (R 8 /R 7 )
OUT
2 -Order Anti -Aliasing Filter
and Secondary Gain
Figure 73. Schematic of Load-cell Interface
Sensor Application — Pressure and Load Sensors 219
W dsPIC l U - [Magnitude]
PP gle KJew Qesign Fjter Output £pdegen ^tndow
x
SPC
n ss n nans Bin
h i y i b
SPC PIT C
y
DAT
1
Magnitude vs Frequency
. ->v\A
os
o.c
0*
Q_2
J
U/yyvww^
--__---._._.
.._ — _.-.
.^/VVVv/s v ny^
-------
- in
-- -- -- -- — - -
--------------
/■•^ .■---..--. .---.I
.._._.-
r - -. .-•-. .--.V r % J r~H.^'%, W'^. f-u.
■ - - -
3QD 300
Frequency (Hertz)
--n
-n
Ready
Sampling Frequency 1000
Passband Frequencies 55 65
Staph and F requenaes 5961
Passband Ripple 0.5 ( dB>
Stspband Ripple 3 i-dB}
H\ Frequencies in Hertz
16 Bit Fixed .Point
33ndstop Filter
FIR (Window) Design
Kaiser Window
Filter Length: 233
dsPIC FD Version 1.0.0 Build 1 - 10:44:19 Aug 23 2006
Creed Huddleston
Load Cell Interface
Figure 7.4. Response of Notch Filter for AC Power Noise Removal
1A Firmware Implementation
As with the temperature-monitoring system, the firmware that implements the
signal sampling, filtering, analysis, and error handling for the weigh scale relies on
Microchips 16-bit Peripheral Library and its DSP Library to encapsulate many of
the hardware interface functionality and to provide a consistent, tested set of digital
signal processing routines for filtering.
Signal Sampling
The load-cell signal on analog input pin AN7 is sampled every millisecond using the
autosample mode and the dsPIC s Timer 3 to trigger the conversions. To maximize
the resolution for this application, we'll assume that the input signal is unipolar (i.e.,
we'll require that the user ensure that the excitation voltage cant get reversed) with
an input range of to 5V, so we can use the unsigned 1Q15 format for the data
from the ADC. Also, to reduce the overhead associated with a fairly quick sampling
220 Chapter 7
rate, we'll interrupt only after every eight samples have been added to the buffer.
This number can be adjusted down to increase the system response or up to further
reduce the interrupt-associated processor overhead.
The code that configures the ADC sampling parameters is found in the function
ADClnit ( ) in the module ADCIF . c. It uses the OpenADC12 ( ) and the OpenTimer3 ( )
routines from the 16-bit Peripheral Library to set up both the ADC and Timer 3 as
shown in the following code fragments from adcif . c and Timer . c.
Code Example 7.1. Signal Sampling Configuration Code
From adcif. c:
Uint8
ADClnit (void)
{
// Local Variables
Uintl6
uil6ADCONl,
uil6ADCON2,
uil6ADCON3,
uil6ADPinConf ig,
uil6ScanSelect ;
// Configuration data for ADCON1 register
// Configuration data for ADCON2 register
// Configuration data for ADCON3 register
// Configuration data for ADPCFG (pin
// configuration)
// Configuration data for ADCSSL (channel
// scan selection)
// Turn off the ADC module and disable the ADC
// interrupt to ensure that the configuration
// completes without interruption
CloseADC12 () ;
// Setup the ADC0N1 register configuration
// data, of which the most important is the
// data format, the clock source, and the
// Auto Sampling mode
uil6ADC0Nl = ADC MODULE ON
& // Enable the ADC module
ADC_IDLE_STOP & // Stop conversions during IDLE state
ADC_FORMAT_FRACT & // Generate unsigned fractional data
ADC_CLK_TMR & // Use Timer 3 to trigger conversions
ADC AUTO SAMPLING ON; // Enable the Auto Sampling mode
Sensor Application — Pressure and Load Sensors 221
// Setup the ADC0N2 register configuration
// data, which includes the ADC reference
// voltages, the number of samples between
// interrupts, and the buffer data order
// specification.
uil6ADCON2 = ADC_VREF_AVDD_AVSS & // Use AVdd and AVss as ADC reference
ADC_SCAN_ON & // Enable channel scan mode
ADC_SAMPLES_PER_INT_8 & // Gather 8 samples before interrupting
ADC_ALT_BUF_OFF & // Don't alternate the sample buffer
ADC ALT INPUT OFF; & // Don't interleave the input
// Setup the ADC0N3 register configuration
// data, which includes
uil6ADCON3 = ADC_SAMPLE_TIME_31 & // Sample for 31 Tad
ADC_CONV_CLK_SYSTEM & // Use system clock for conversions
ADC CONV CLK 32Tcy; // Allow 32 Tcy for conversion
// Setup the ADCSSL register configuration
// data, which specifies which channels are to
// be scanned by the ADC. Note that the way
// the library is implemented, we specify the
// ANx signals that we do NOT want to scan in
// this list. In this case, we leave out AN7
// since that's the only one we want to sample
uil6ScanSelect = SKIP_SCAN_ANO & SKIP_SCAN_AN1 & SKIP_SCAN_AN2 &
SKIP_SCAN_AN3 & SKIP_SCAN_AN4 & SKIP_SCAN_AN5 &
SKIP_SCAN_AN6 & SKIP_SCAN_AN8 & SKIP_SCAN_AN9 &
SKIP_SCAN_AN10 & SKIP_SCAN_AN11 & SKIP_SCAN_AN12 &
SKIP SCAN AN13 & SKIP SCAN AN14 & SKIP SCAN AN15;
// Make sure that the pins associated with
// the analog channel (s) we're using have
// been configured as analog inputs. This
// application uses AN7 as the signal input,
// and the dsPICDEM board dedicates ANO and
// AN1 to the ICD2 interface, AN3 to the
// digital potentiometer input, AN4-AN6 to
// the analog potentiometer inputs, and AN8
// to the temperature sensor input.
222 Chapter 7
uil6ADPinConfig = ENABLE_AN3_ANA & ENABLE_AN4_ANA & ENABLE_AN5_ANA &
ENABLE AN6 ANA & ENABLE AN8 ANA;
// Actually configure the ADC module. Note
// that this will enable the ADC module, but
// the associated interrupt must be enabled
// by a call to EnablelntADC ( ) after the rest
// of the system has been initialized
0penADC12 (uil6ADC0Nl, uil6ADCON2, uil6ADCON3, uil6ADPinConf ig,
ui!6ScanSelect) ;
// Initialize Timer 3 to generate a 1 msec
// interrupt to trigger the ADC sampling
Timer3Init (ADC SAMPLE RATE);
return ST_OK;
}
From Timer . c:
void
Timer3Init (Uintl6 uil6SampleRate)
{
// Local Variables
Uintl6
uil6Period,
ui!6TimerCfg;
// Timer period in counts
// Timer module configuration data
// First, turn off Timer 3 and its associated
// interrupt so we can complete the initialization
// without being interrupted
CloseTimer3 ( ) ;
// Compute the timer period in counts based
// on the instruction clock frequency. The
// instruction clock frequency is computed
// by multiplying the crystal frequency FOSC
// by the phase- locked loop scaler PLL and
// then dividing by 4 since each instruction
// takes four system clock cycles.
Sensor Application — Pressure and Load Sensors 223
uil6Period = (Uintl6) ( ( (FOSC * PLL / 4) / uil6SampleRate) + 1) ;
// Configure the timer itself
ui!6TimerCfg = T3 ON
& // Enable Timer 3
T3 IDLE STOP & // Turn off Timer 3 in IDLE state
T3_GATE_0FF &
T3_PS_1_1 &
T3 SOURCE INT;
// Not gating the timer
// Set the prescaler to 1:1
// Use internal clock for timer
0penTimer3 (ui!6TimerCfg, uil6Period) ; // Configure the timer
return;
}
The interrupt handler is the routine adcisr ( ) , also found in the adcif . c mod-
ule. The handler clears the ADC interrupt flag. Failure to clear the ADC interrupt
flag will cause the processor to vector back into the handler as soon as the function
returns, essentially dooming the application to a death spiral of constantly servicing
the interrupt.
Code Example 7.2. ADC Inter rupt-handler Code
From adcif. c:
void attribute (( interrupt ))
ADCISR (void)
{
// Local Variables
fractional volatile
*pfrADCBuff ,
*pf rlnputSignal ;
// Pointer to ADC data buffer
// Pointer to global input signal data
// buffer
Uint8
ui8DataCount ;
// ADC data index
// Clear the ADC interrupt flag and
IFSObitS.ADIF = 0;
// Clear the ADC interrupt flag
// Copy the A/D conversion results to the buffer
224 Chapter 7
II g_f rSensorSignal [] . Note that the samples
// from each channel are contiguous, so they will
// have to be placed into separate signal arrays
// the samples are to be filtered. We don't do
// that here in order to minimize the time spent
// in the ISR.
pfrADCBuff = &ADCBUF0; // Point to the first entry in the ADC
// data buffer
pf rlnputSignal = g_f rlnputSignal ; // Point to the first entry in the input
// signal data buffer
for (ui8DataCount = 0; ui8DataCount < ADC_SAMPLE_COUNT ; ui8DataCount++)
*pf rInputSignal + + = *pf rADCBuf f + +; // Copy the next ADC sample to the
// global input signal buffer
// Set the Filter Event to signal the main
// processing loop that we have new data to
// filter
g_vuil6SysEvent |= EVT_FILTER;
}
Digital Filter Implementation
The digital filter implementation is nearly identical to that for the temperature
sensor discussed in Chapter 6, the only difference being the filter coefficients. As in
that case, the filter used here is an FIR filter that requires the application to create
and initialize an FiRStruct data structure to maintain the filter's associated state
variables. Filtering of new data is simply a matter of calling the DSP library routine
fir ( ) with the new data samples.
For this application, we'll use a bandstop filter with the following parameters:
Sampling Frequency: 1000 Hz
Passband Frequencies: 55, 65 Hz
Stopband Frequencies: 59, 61 Hz
Passband Ripple: 0.5 dB
Stopband Ripple: 3 dB
Filter Type: Kaiser
Sensor Application — Pressure and Load Sensors 225
Entering these parameters into the dsPIC Filter Design program and generating
code for the resulting filter (stored in SensorFilter . s) provides us with the filtering
data structure we need. Note that the filter length is much longer than that for the
thermocouple application (233 taps vs. 5 1 taps) because the filtering requirements
are much more stringent.
Data Analysis Implementation
The data analysis algorithm is handled by the routine AnalyzeData () in the
Analysis . c module. This admittedly simple function merely examines the filtered
data on a sample-by-sample basis and turns the lower and upper limit LED's on or
off whenever the samples are beyond the specified limits.
Code Example 73. Data Analysis Code
From Analysis . c:
Uintl6
AnalyzeData (void)
{
// Local Variables
float
f SensorValue ;
// Current scaled sensor value
PSensorCfg
psenSensorCf g ;
// Pointer to sensor configuration
Uintl6
ui 16 Sensor Index;
// 0-based sensor index
// Check the sensors one at a time to see
// whether the sensors' current values
// exceed any enabled alarm limits
psenSensorCf g = g senSensorCfg;
// Point to first sensor configuration
for (uil6SensorIndex = 0; uil6SensorIndex < MAX_CAL_SENSORS;
uil6SensorIndex++ , psenSensorCf g++)
{
// Convert the current filtered sensor
// reading into its corresponding parameter
226 Chapter 7
II data value
fSensorValue = ScaleData (g_f rFilteredSensor [uil6SensorIndex] ,
psenSensorCf g- >f Gain,
psenSensorCfg->fOf f set + 0.0005);
g fSensorValue [ui!6Sensor!ndex] = fSensorValue;
// Are we checking the lower alarm limit
// and, if so, is the sensor's filtered
// data value less than the lower limit?
if ( (psenSensorCf g->uil6Flags & SENFLG_ENBL_LOW_ALM) &&
(fSensorValue < psenSensorCf g->f AlarmLevel [ALARM_LOWER] ) )
psenSensorCf g->uil6Flags |= SENFLG_LOW_ALM_ST;
// Alarm limit exceeded
// so set its flag
// Are we checking the upper alarm limit
// and, if so, is the sensor's filtered
// data value greater than the upper limit?
if ( (psenSensorCf g->uil6Flags & SENFLG_ENBL_HI_ALM) &&
(fSensorValue > psenSensorCf g->f AlarmLevel [ALARM_UPPER] ) )
psenSensorCf g->uil6Flags |= SENFLG_HI_ALM_ST;
// Alarm limit exceeded
}
// so set its flag
return ST OK;
}
Error-handling Implementation
Error handling for the application can be relatively simple or it can be more complex,
particularly if the application calls for testing the resistance of each leg of the bridge.
Doing so requires pinning out the load-cell bridge connections to individual analog
input lines, significantly increasing the complexity of the circuitry and diminishing
the number of load-cell channels that can be monitored by a single dsPIC DSC
using the processor's internal resources.
The error-handling code is located in the routine CheckForErrors ( ) in Analysis . c,
and it consists of checking for a shorted or an open bridge connection, conditions
Sensor Application — Pressure and Load Sensors 227
that are indicated by an extremely low or a nearly full-scale value, respectively. If
either condition is detected, the code sets a flag that blinks the alarm LED (LED 2) .
Once the condition has been cleared, the application turns the alarm LED off.
7.5 Summary
Now that we've completed two applications using the dsPIC's ADC and digital
filtering, we'll tackle a third application that acquires data using an entirely differ-
ent approach: counting the number of transitions on a timer/counter external clock
input to determine fluid flow through a turbine.
Endnotes
1 . psi = pounds per square inch.
2. This property is known as the piezoelectric effect
3. 1 nanocoulomb = 10" 9 coulombs.
This Page Intentionally Left Blank
Sensor Application — Flow Sensors
A process cannot be understood by stopping it. Understanding must move
with the flow of the process, must join it, and must flow with it.
— Frank Herbert, Dune (First Law ofMentat)
Rounding out our discussion of interfaces to popular sensors is an examination of
flow sensors, those devices that allow us to measure the flow of a substance, usually
a liquid, through a system. Although there are a number of ways to define flow,
including mass flow, volume flow, laminar flow, and turbulent flow , the key point is
that we want to measure the amount of the substance that is flowing to accomplish
a particular purpose. 1 This usually means that system designers are interested in
mass flow (the mass per unit time that passes a particular point in the system), but
if the substance is a liquid whose density is essentially constant (at least through
the point or points of interest in the system), the designer can substitute a measure-
ment of volume flow (the volume per unit time) for mass flow with little effect on
system performance. This occurs in many situations and is the subject of this final
design example.
Where might we find applications of flow measurement? For most people, the
two most prolific and prosaic examples are in the form of their electricity and water
bills, which are based on the flow of those two substances into their home or office.
Huge systems such as oil pipelines and small systems for monitoring the breath-
ing of infants in neonatal intensive-care units employ flow sensors to monitor and
control critical operational parameters. It is no exaggeration to state that commerce
itself relies on reliable flow-measurement systems to ensure the accurate delivery of
thousands of types of fuels, foods, and other substances worldwide.
8.1 Types of Flow Sensors
Although we'll describe two common types of flow sensors, the turbine sensor (which
measures volume flow) and the gravimetric sensor (which measures mass flow), our
230 Chapter 8
application will focus on the turbine sensor for two reasons. The first is that in-line
turbine sensors are widely used, so an understanding of them is extremely helpful
to the designer. The second, and perhaps the more important, reason is that turbine
sensors offer a type of sensor output that we have not used in the previous two
applications, namely & frequency-based output signal whose frequency increases with
increasing flow. As we'll see, this new output signal type has both advantages and
disadvantages, and knowing how to deal with frequency-based sensors is a valuable
tool to have in the designer's kit.
Turbine Sensors
Typically used with fluids or gases, the turbine sensor looks like a little fan or pro-
peller, with the axis of the fan aligned with the direction of flow and the blades of
the fan covering the entire cross-section of the flow path as shown in Figure 8.1.
Not only does this blade arrangement allow the flow to exert as much pressure as
possible on the sensor (very helpful in low- flow conditions), it also ensures that
the flowing substance sees a constant pressure as it passes the sensor, which guards
against possible material breakdown under high-flow conditions.
Direction of
turbine rotation
Top View
X
Flow of fluid is
into the page
Side View
Axis of rotation
Single turbine blade
Turbine bearing
Direction of fluid flow
Figure 8.1. Example of a Turbine Flow Sensor
Sensor Applica tion — Flo w Sensors 231
Because the fan axis is in-line with the material flow, it can be difficult to mea-
sure the axial rotation directly, so turbine sensors often have windows that allow
the blades to be observed from the side. By counting the number of times a blade
passes a fixed point on the window in a given period of time and knowing both the
density of the material and the cross-sectional area of the flow path, the sensor can
determine the volume of fluid that has passed through the sensor.
At first, monitoring the blade rotation might seem to be a daunting task, given the
electrical isolation of the blade from the rest of the system. Fortunately, in many cases
we can simply illuminate the window with a source that emits light at a frequency
which the blade (but not the flowing material nor the sensor window) reflects well
and then measure the reflected signal to get an output that rises and falls as the blade
passes the point of illumination. A sample of such a reflectance signal is shown in
Figure 8.2, and by counting the peaks of the signal in a given time period, we can
determine how fast the sensor blades are rotating. We'll examine the issues we face
with this arrangement in the section, Challenges of Flow Measurement.
Example Turbine Flow Sensor Output
c/)
O
>
CD
O)
I
Time (hundredths of seconds)
Figure 8.2. Example Turbine-flow Sensor Output Signal
Unlike temperature sensors and load-cell sensors, which are primarily electrical
in nature, good turbine-flow sensor design requires a high degree of mechanical as
well as electrical skills to obtain optimum results. While we'll focus on the electrical
aspects of the sensor interface here, the reader should be aware that the mechani-
cal aspects of flow are important as well, and instrumentation of a system should
include an understanding of the effect that the insertion of the sensor(s) will have
on the system being monitored.
232 Chapter 8
Gravimetric Sensors
Unlike turbine-flow sensors, which measure the volume of material that passes a
cross-section of area during a given time, gravimetric sensors measure the actual
mass of material that passes a cross-section during a given time. Although sometimes
more accurate than a corresponding volume flow measurement, gravimetric flow
sensors tend to be significantly more expensive than their turbine flow brethren (by
as much as an order of magnitude), so their use tends to be limited to applications
that require an extremely high level of accuracy and that can afford the added cost,
such as in a calibration laboratory.
8.2 Key Aspects of Flow Measurement
Many of the key aspects of flow measurement are shared by all sensor systems, such
as the range and resolution of measurement, while others are unique to flow sensors
themselves, such as the challenges faced in low-flow and high-flow environments.
Range of Measurement
The range of measurement is dependent upon the physical characteristics of the
material being monitored, the properties of the turbine being used to perform the
measurement, and the nature of the system in which the material is flowing. Above
a certain flow, the material under observation can be damaged as the shear forces
literally begin to tear the material apart. In addition, the nature of the material can
seriously affect the life of the sensor itself, particularly the blades, since abrasive
materials under high flow can quickly wear away the blades. This adversely affects
the quality of the sensor measurements, because the reduced blade area allows addi-
tional material to flow past the sensor without being measured and also decreases
the ability of the sensor to operate in low-flow conditions due to the reduced surface
area of the blades (which reduces the rotational pressure on the sensor) .
The characteristics of the turbine determine both the lower and the upper limits
of flow that can be measured, since too low a flow will prevent the turbine from
moving (the pressure of the flow being insufficient to overcome the friction of the
blades against its axis of rotation), while too high a flow can physically deform the
blades, generating measurement errors and creating wear in the blade-axis junction,
which produces blade "wobble" that degrades the resultant measurements. This lat-
ter problem is so pervasive that we'll deal with it in the section, Challenges of Flow
Measurement, and specifically in the subsection, Sources of Noise.
Sensor Application — Flow Sensors 233
Finally, the system itself will determine the range requirements for the flow mea-
surements. In situations that require measurements of flow levels that exceed the
capabilities of the sensor being used, a "sampling" tube of known size that diverts
a portion of the flow for measurement purposes can be employed, with the mea-
sured flow through the sampling tube correlated to a corresponding flow through
the main system.
All that being said, some typical turbine-flow sensor families support measure-
ment ranges of 0.2 gallons per minute (GPM) up to 60 GPM. 2 Specialized sensors
can extend this range to much larger flows.
Resolution of Measurement
Unlike the previous two sensor systems we've studied, which both generate a voltage
signal that is directly correlated to the value level of the parameter of interest, the
turbine flow sensor generates a signal whose frequency, not its voltage, correlates to
the parameter being measured. To acquire the signal, we'll use a slightly different
analog front end to convert the analog reflectance signal to a digital frequency signal
and use that signal to drive one of the dsPIC DSC's Timer/Counter modules. This
module counts the number of transitions on its clock input signal and, combined
with a second timer module that has a resolution of the system-clock period (33.9
ns for the dsPICDEM vl.l configuration), we will be able to make measurements
well within the requirements of any real-world turbine-flow sensor.
Accuracy of Measurement
Turbine-flow sensors are capable of an accuracy within 2% or better of the full-scale
reading, and their measurements are highly repeatable, provided that the turbine's
rotational path is clear and that the turbine itself is undamaged by wear or age.
Usually, the accuracy of the measurements degrades near the extremes — i.e., under
extremely low flow or very high flow conditions — and this degradation worsens
rapidly if the sensor's turbine assembly develops significant wear, particularly in the
bearing that mounts the turbine to the axis about which it rotates. Fortunately, there
are techniques we can employ that can ameliorate this loss of accuracy to an extent,
and while the methods can't actually prevent the underlying causes of the problem,
they can at least allow the system's performance to degrade gracefully. Often this gives
the user an opportunity to monitor the system and to schedule required maintenance
in advance rather than having to react to the problem on short notice.
234 Chapter 8
Challenges of Flow Measurement
Turbine-flow sensors face the most serious problems at the lower and upper limits
of flow. Low- flow conditions present a challenge because, below a certain level, the
pressure of the flowing material on the turbine blades is insufficient to overcome
the friction of the blades on the axis about which they're rotating. In this situation,
the material can ooze around the nonrotating blades, allowing flow even though the
sensor reads no flow. This condition can be alleviated by adding more blades to the
turbine, since the additional force experienced by the added blades further reduces
the flow level that can be measured, but doing so also increases the frequency output
of the sensor (since more blades means more blade transitions per rotation), which
increases the overhead required to acquire the data.
At the other end of the spectrum is that, under high-flow conditions, the reflec-
tance signal tends to flatten out, with the peaks and valleys decreasing significantly
in amplitude. This requires that the comparator circuitry used to convert the analog
reflectance signal to a digital value support dynamic adjustment of the comparison
threshold, and the firmware must be able to monitor the extremes of the analog
signal in order to set that threshold correctly.
Over time, the bearing that mounts the sensor blades about the axis of rotation
will tend to wear, enlarging the mounting hole about the axis. The enlarged mount-
ing hole allows the blades to wobble around the axis and to ride up and down on it,
which means that the blades passing the illuminated reference point may tilt between
successive rotations, causing the reflectance peaks to shift back and forth somewhat
about the "true" period. Depending on the type of material used and the flow level,
bearing wear can arise fairly quickly and is a serious problem when it occurs.
Signal Characteristics
The analog reflectance signal is relatively large, on the order of hundreds of milli-
volts to volts, so amplification is not really an issue, although loading of the sensor
signal and the need to remove common-mode noise may recommend the use of an
instrumentation amplifier to buffer the sensor signal before further processing.
The frequency content of the turbine signal is easily computed as the number
of blades times the maximum rotational speed supported by the sensor, and the
minimum sampling frequency is twice that to meet the Nyquist criterion, add "Note
that in this application, we're sampling the signal only to identify it minimum and
maximum signal levels and not to extract parameter information from the sampled
voltage signal. The task of parameter value extraction is handled by the counter we'll
Sensor Ap plica tion — Flo w Sensors 235
use, and our main consideration for the counter is to ensure that it can't overflow
during the data acquisition period.
Material Density Compensation
To convert the flow-volume measurement to a mass-volume measurement, the sen-
sor has to apply a material density factor. This factor is simply a material-dependent
value that is multiplied by the volume-flow measurement to obtain the correspond-
ing mass flow, with the basic assumption being that the density of the material is
constant over the range of flow being measured. If that is not the case, the material
density compensation factor can be applied in a piecewise-linear fashion similar to
that which was used with the thermocouple measurements.
Linearization
In most cases, no special linearization algorithm is required since the frequency usu-
ally increases linearly with flow. The linearity tends to be somewhat worse at the two
extremes of low flow and high flow, and it may be necessary in some circumstances
to perform a simple three-part piecewise linearization to maintain accuracy near
the limits of the sensor.
Calibration
The calibration needs of a turbine-flow sensor are fairly minimal, since the output
signal characteristics of the sensor are dictated by the sensor's mechanics rather than
its electrical response. Generally, the calibration curve for a sensor is fixed for a given
sensor model and does not require any calibration in the field.
Sources of Noise
There are three primary sources of signal degradation with a turbine-flow sensor:
bearing wear, turbidity of the material, and electronic noise in the analog portion of
the sensor interface. The cause and effects of bearing wear have already been discussed
in detail, and the main problem with material turbidity is that it can significantly
reduce the reflected signal from the turbine blades, which adversely affects the ability
of the sensor system to discern valid blade transitions through the reference zone.
Electrical noise is also a problem, although generally not to the extent seen in
the previous two applications. The primary area affected by electrical noise is the
comparator input, where noise can generate false comparator output transitions that
result in a measured flow value that's higher than the true flow.
We'll explore the techniques to address the problems caused by these noise sources
in the section, Signal Conditioning, but within limits, all three of these conditions
can be handled satisfactorily.
236 Chapter 8
Error Conditions
About the only hardware-error condition that can be detected for a turbine-flow
sensor is a broken sensor lead, and that only under certain circumstances. Additional
system problems such as excessive flow can be detected, but those reflect an actual,
valid system condition (although they may be beyond the capabilities of the sensor)
and thus are treated under the data analysis section rather than here.
The best way to detect a broken sensor lead is to place a sense resistor from
the sensor output to ground and then to periodically monitor the voltage across
the sense resistors to verify that it meets a minimum level consistent with what is
expected out of the sensor. Depending upon the output level of the turbine sensor
itself, a high-impedance amplifier may be required between the sense resistor and
the ADC input.
8.3 Application Design
As with the previous applications we've developed, the flow-sensor system will be
fairly simple but will illustrate the issues important to flow measurement. Our system
will measure flows of between 0.2 GPM (roughly 0.8 liters per minute or LPM) and
8 GPM using a turbine flow sensor. Measurements above or below a set of limits
will light a corresponding Alarm Limit LED, and a broken or disconnected signal
lead will blink a Hardware Error LED.
System Specification
The system uses the Microchip dsPICDEM vl.l board as the hardware platform
and performs the following tasks:
1. Measures a flow rate between 0.2 GPM and 8 GPM with an accuracy of
0.01 GPM.
2. Allows the user to perform the following functions via the RS-232 serial
port running at 38.4 Kbps, 8 data bits, 1 stop bit, no parity, and no flow
control:
a. set the flow factor value for any sensor or material,
b. specify an upper and a lower limit for the measured weight.
3. Report the measured flow every second via the serial port. Flow reports are
to be in text.
Sensor Ap plica tion — Flo w Sensors 237
4. Report out-of-limit alarm conditions by displaying a sensor value of " — "
and lighting LED 1 on the demo board if the measured flow is less than the
lower limit and by displaying "++++" and lighting LED2 if the flow exceeds
the upper alarm limit.
5. Report hardware-error conditions (broken sensor lead) by blinking LED3
on the demo board.
As with the previous two applications, if the information is to be read by other
electronic components in the system rather than by humans, a faster binary data
protocol would be appropriate, and one is included in the example software.
Sensor Signal Conditioning
Because of the nature of the sensor signal, the signal conditioning is somewhat
different from that performed in the two previous applications. In particular, the
sensor output signal is buffered and passed through a comparator to generate the
corresponding binary digital signal that can be measured using the dsPIC DSC s
external counter function. To ameliorate problems with electrical noise, the com-
parator can use hysteresis and an adjustable thresholding mechanism that allows the
dsPIC DSC to compensate for low-level sensor signals at higher flow rates. A block
diagram of the analog signal-conditioning circuitry is shown in Figure 8.3.
Turbine Sensor
Signal Conditioning
Signal Detection
Level Generator
Timer /Counter
Module
ADC Module
SPI Port
dsPIC
Figure 8.3. Block Diagram of Flow Sensor Signal Conditioning
Digital Filtering Analysis
The system employs a low-pass filter to smooth the raw voltage signal from the sensor
before analyzing the signal to determine its minimum and maximum values. Unlike
the previous two applications, we do not need a notch filter to remove power-line
noise because we can add hysteresis to the comparator circuit to mitigate its effects.
238 Chapter 8
Although the use of a frequency-based sensor signal complicates the system some-
what, it does have some advantages, and this is one of them.
It turns out that the undesirable signal artifacts created by bearing wear are
removed rather effectively by the inherent averaging function performed by accu-
mulating the blade counts over time. While the periods between individual blade
transitions past the reference point may vary due to blade wobble, by counting the
total number of transitions over a span of time, those period fluctuations tend to
average out. We can improve this averaging by allowing a longer period of time for
accumulating blade transitions, but we do so at the expense of system response. Of
course, its certainly possible to make the count accumulation time user configurable,
probably by providing a limited offering of settings since the user will usually be
unfamiliar with the nuances of filtering. Figure 8.4 shows an example of a "normal"
flow signal with relatively constant times between blade transition peaks, while Figure
8.5 is an example of the signal from the same sensor after it has experienced bearing
wear. Note that, although the interpeak times in the second figure vary significantly
more than their counterparts in the first figure, the average inter-peak time is very
similar for both signals.
At this point, the reader may be wondering why we'll be using the counter func-
tion of the dsPIC DSC timer module to gather a set of blade transition times and
Normal Steady-state Flow Signal from Turbine Sensor
c/)
-i— »
O
>
CD
U)
Ctf
-*— »
o
>
Time (hundredths of seconds)
A normal steady -state flow through a turbine with no
bearing wear should exhibit a very periodic signal
Figure 8.4. Nominal Flow Signal with No Wobble
Sensor Application — Flow Sensors 239
Normal Steady-state Turbine Flow Sensor Signal
(/)
o
>
CD
O)
o
>
0.200
^
^
1 1 1
«—
0.0175
— ►
^
0.025
^
*-
0.0175
fe,
-^
0.025
^
•4-
0.015
-►
I I I
^ ^
W "^
P
—
Time (hundredths of seconds)
If the turbine bearing is worn, a normal steady -state flow wi
exhibit a nonperiodic signal as the turbine blades wobble
about the shaft. Although this example shows the overall
period averaging out exactly after six blade transitions, the
signal may not necessarily recover that quickly.
Figure 8.5. Example Flow Signal with Signs of Wobble
then compute the average transition time rather than using the dsPIC DSC's input
capture features, which allow us to measure the time between individual signal
transitions. The primary reason is that such a fine degree of resolution produces a
great deal of jitter in the measurements, and this jitter becomes steadily worse as
the turbine bearing wears. In addition, computing flow rates based on individual
blade transition times tends to consume a huge portion of the available processing
bandwidth at high flow rates since there is so little time between blade transitions.
By gathering a large number of transitions and then averaging them, we get better
results than gathering a large number of calculated flow rates and averaging those.
Data Analysis Algorithms
The data analysis algorithms for the flow sensor are somewhat more complicated
than those for the temperature-monitoring and load-cell monitoring applications
developed in the previous two chapters, but not much. As with those other systems,
the flow-measurement system needs to check its filtered output values against upper
and lower alarm limits, but periodically it also needs to read the level of the raw analog
signal from the turbine sensor to determine where to adjust the biasing voltage for
the peak-detection comparator circuitry. Recall that the raw signal level decreases in
240 Chapter 8
amplitude as the blade transition rate increases (i.e., as flow increases). Ideally, the
processor should set this comparison voltage level to the same relative point in the
sensor output signal even as the amplitude of the sensor output changes, so that the
interpeak times don't shift simply because the sensor output level has changed. An
example of the phenomenon that we would like to avoid is shown in Figure 8.6.
The algorithm for monitoring the raw sensor output and setting the comparator
threshold is shown in Figure 8.7. It basically samples the sensor signal, performs
some light filtering to clean up the data, and then checks whether any of the samples
are outside of the previously recorded extrema values. Whenever the algorithm
finds a sample whose value is either less than the current minimum value or greater
than the current maximum value, it replaces the corresponding extremum with the
new sample value. Once the desired number of samples have been processed, the
algorithm calculates the midpoint of the minimum and maximum values detected,
outputs that as the new comparator level, and then resets the recorded minimum
and maximum values before acquiring and processing a new block of samples.
When determining how often to adjust the comparator level, the designer should
consider the maximum rate of flow change — i.e., how quickly the flow rate can
fluctuate. This is particularly important when going from a low-flow condition
to a high-flow condition, because the sensor output will change from a relatively
large-amplitude signal to a small-amplitude signal. If the comparator level is not
adjusted quickly enough, the maximum level of the sensor output may drop below
the comparator level, resulting in no comparator output transitions. This condition
looks to the dsPIC DSC like a no-flow condition when, in fact, just the opposite
is true! While it might at first seem that we would want to update the comparator
level as fast as possible, doing so too quickly causes problems in low-flow conditions,
because the update period may be shorter than the time between blade transitions.
In this case, the detected extrema may not reflect the actual minimum and maxi-
mum values of the sensor output, since the update period may not be long enough
to gather a full blade transition.
Sensor Application — Flow Sensors 241
Effect of Comparator Level on Position and Validity
of Detected Peaks
Peak Detection with Constant Comparator Level
Comparator
level is 60% of
maximum
signal level
Comparator JeyeJ
Sensor signal
25%
Comparator
level is 80% of
maximum
signal level
34%
Comparator level
is 1 00% of
maximum signal
level
50%
Comparator level
is above
maximum signal
level so no peak
detected
Comparator output
Peak Detection with Adjustable Comparator Level
Comparator
level is 60% of
maximum
signal level
Comparator
level is 60% of
maximum
signal level
Comparator
level is 60% of
maximum
signal level
Comparator level
is 60% of
maximum signal
level so peak is
detected
Comparator output
Time
Unless the comparator level is adjusted to maintain it at a constant percentage of the
sensor signal output , the distance between the leading edges of the peak detector
comparator output will change with flow (since the heights of the peaks change with
frequency.) The worst possible condition is one in which valid peaks are not detected,
which results in reported flow values significantly lower than actual flow values.
Note that in reality, we will not know in advance the correct comparator level for the
first peak that is significantly different from the preceding peak, so the first peak
detection may exhibit some variance from the optimal timing. This usually is
insignificant when averaged over the entire group of detected peaks.
Figure 8. 6. Example of Erroneous Interpeak Period Change
242 Chapter 8
c
Enter
)
Done
Yes
Log new sample as current minimum
value
Yes
Log new sample as current maximum
value
Yes
Compute midpoint of minimum and
maximum sample values
i
Output midpoint value to comparator
level DAC
i
Minimum sample value= OxFFFF
Maximum sample value= 0x0000
i
Reset level monitoring timer
Figure 8.7. Comparator Threshold Level Computation Algorithm
Sensor Ap plica tion — Flo w Sensors 243
Communication Protocol
The application uses the same basic communication protocol as the previous
applications.
8.4 Hardware Implementation
The hardware implementation of the flow sensor is straightforward, and a block
diagram of the required circuitry is shown in Figure 8.8.
Turbine Sensor
Signal Conditioning
Signal Detection
Level Generator
Timer /Counter
Module
ADC Module
SPI Port
dsPIC
Figure 8. 8. Hardware Block Diagram
Turbine Sensor Interface Circuitry
The turbine sensor interface circuitry shown in Figure 8.9 provides the sensor with
power and conditions the sensor's output signal for processing by the dsPIC DSC. As
with the previous applications, an instrumentation amplifier buffers the signal output
by the sensor, but the gain factor is 1 since the turbine sensor produces sufficient
signal amplitude on its own; the instrumentation amplifier acts as a buffer between
the sensor and the rest of the system. The output of the instrumentation amplifier
is filtered by a cascaded pair of second-order Butterworth filters before being fed to
both the comparator that produces the digital frequency signal we'll analyze and the
ADC channel that monitors the sensor signal level. Note that as with the other two
examples, the schematic is for a 3.3V system, and the appropriate changes to voltage
levels must be made in order to run it on the 5V dsPICDEM 1.1 GPDB.
To implement the adjustable comparator threshold, the schematic shows a
Microchip 4921 digital-to-analog converter (DAC), a device that is essentially the
complement to the ADC in that the DAC takes a digital input and converts that
input value to an output analog voltage level. Like the ADC, the DAC is ratiometric;
the output is equal to the output voltage range times the ratio of the digital value
244 Chapter 8
Turbine Flow Interface Circuitry
Detected Peak Data
To Timer /Counter
Comparator Level Generator
NOTES :
1 . R 1 and R 2 provide an input common-mode current path
and a way to determine whether the sensor is actually
connected to the circuit. Resistor values should be
identical and be approximately 100 KQ to avoid loading
the input signal with too low an input impedance.
2. Gain through the instrumentation amplifier is controlled by
Rg according to the equation
Gain = 1 + (50 KQ / R G )
3. Antialiasing filters have a Butterworth filter frequency
response. Gain is included in the final filter stage to
compensate for the instrumentation amplifier's inability to
produce output voltages that are near either power supply
rail. The gain in the final stage is given by the equation
Gain = 1 + (R 8 /R 7 )
Figure 8.9. Turbine Sensor Interface Circuitry
Sensor Application — Flow Sensors 245
written to the DAC and the maximum possible digital value. For a 12-bit DAC
operating at 5V, this means that the output voltage can range from to 4.9988V
for input values from to OxOFFF (0 to 4095). While a 12-bit DAC works well
in this application, we could easily increase the DAC's resolution by using a 1 4-bit
(16,384 levels) or even a 16-bit (65,536 levels) device. Since the dsPIC DSC inter-
faces to the DAC via an SPI channel, increasing the DAC resolution would demand
no additional hardware but would require a slight modification of the command
data written to the DAC to support the additional data bits of the higher resolu-
tion parts. To simplify circuitry design when using the dsPICDEM 1 . 1 GPDB, the
example software actually uses the on-board SPI digital potentiometer to set the
comparator level.
Because we want to monitor the sensor signal level as it appears to the compara-
tor, the antialiasing filter must maintain a unity gain response for frequencies in
the range of interest. With its optimally flat gain response through the passband,
the Butterworth filter is ideal for this purpose, and by ensuring that the stopband
begins well beyond the highest valid frequency content of the sensor signal, we can
effectively remove any undesired frequency components without adversely affecting
the relevant spectral content of the sensor signal.
8.5 Firmware Implementation
The flow-measurement firmware uses basically the same structure as the two previ-
ous examples. The main components are:
1. the data acquisition module consisting of the blade transition accumula-
tion routine, the ADC sample timer interrupt-service routine, and the ADC
interrupt-service routine,
2. the data filtering module,
3. the data analysis module, consisting of the blade-count analysis and compara-
tor level-adjustment routines,
4. the hardware error-detection module, and
5. the communication module.
246 Chapter 8
Data-acquisition Module
The data- acquisition module is responsible for counting the blade transitions in a
given time period and for adjusting the comparator threshold signal level to optimally
detect those transitions. To do the latter, the dsPIC DSC samples the sensor signal
level going to the comparator, determines an appropriate comparator threshold volt-
age, and outputs that value via the SPI to the digital potentiometer that generates
the analog threshold voltage.
Sensor Signal Level Monitor
As in the temperature and load-cell sensing system, the application employs Timer
3 to create the 1-kHz ADC sample clock. Because we're just trying to find the
extremes of the sensor signal during a given time period, the ADC is configured to
acquire 8 samples before interrupting. The flow sensor data is unipolar, so we use
unsigned fractional mode for the data. When the ADC interrupt is called, the ISR
simply unloads the sample buffer into the g_f rSensorSignal filter buffer and sets
the evt_filter event, which causes the main processing loop to filter the sensor
level data and update the DAC s output voltage.
Blade Transition Counter
The dsPIC DSC's timer module can be configured to count the number of rising
edges on a timer s external clock input pin, which in this case will be connected to
the output of the comparator. By using a second timer to generate an accurate time
base, we can determine the number of blade transitions that occurred during a given
time period and thus determine the corresponding flow level.
This application uses Timer 5 to create a 1 6-bit synchronous counter, allowing us
to measure blade transitions that are spaced fairly far apart and extending the lower
end of the flow levels we can measure. The data-acquisition module also uses Timer 3
to generate the 500-ms timebase used to accumulate the blade counts, simply reading
and resetting the accumulated Timer 5 counter value every 500 times through the
1 msec Timer 3 interrupt. For the flow sensors with which the author has experience
(4- and 6-blade models), a blade count accumulation time of 500 ms seems to work
well, but the optimal time period depends upon the responsiveness required by the
specific application as well as the anticipated flow rates. An accumulation time of
500 ms produces an update rate for the computed flow rate of 2 updates per second
(1/500 ms per update), which may or may not be appropriate for a given situation.
If greater responsiveness is required, the accumulation time can be decreased (thus
updating the threshold more often), but doing so decreases the inherent averaging
Sensor Application — Flow Sensors 247
properties of the algorithm and also raises the minimum detectable flow rate, since
the system must see at least one blade transition per accumulation period in order
to see a nonzero flow.
Upon expiration of the 500 ms timer, the Timer 3 ISR logs the current 16-bit
value of Timer 5 (which contains the blade transition count) to the global variable
g_ui 16 Sensor Count and sets the evt_analyze event to signal the main processing
loop that it needs to invoke the data analysis routine for the flow rate.
Data Filtering Module
Unlike the previous two examples, in which the sensor signal was filtered to improve
the parameter analysis, the filtering in this application is performed to obtain a
better reading of the signals voltage level so it can be used to set the comparator
level optimally.
Sensor Signal Level Filtering
The sensor signal level filter is a low-pass filter. Unlike the filtering scheme used in
the load-sensing applications, this system does not attempt to apply a notch filter to
remove power-line noise that's been coupled into the sensor signal, because signals
with that frequency are completely valid for this application. Removal of even a
narrow band of frequencies around 50 Hz and/or 60 Hz would result in a "dead-
band" of valid flow levels within which the comparator output level would not be
updated. Since the effect of power-line noise on the comparator signal is minimal,
we can safely ignore noise coupled from the power-line in this situation.
The filter uses a sampling rate of 1 kHz, which won't be much of a burden because
we're only going to be monitoring one channel and don't have to process the digitized
data on a sample-by-sample basis. Minimizing the processing overhead required for
digitization allows us to devote more time to filtering, so we can implement a filter
that has an extremely flat gain through the passband, as shown in Figure 8.11. This
filter is a 59-tap minimum 4-term cosine window and, as the reader will note, it
offers unity gain through the passband.
Data-analysis Module
The data-analysis module is responsible for two basic tasks:
1 . checking the latest filtered-flow rate value against the user-specified alarm
limits and setting the display states of the corresponding alarm limit LEDs
appropriately,
248 Chapter 8
2. analyzing the buffered sensor output signal level to determine
a. whether the sensor is actually connected to the system, and
b. if the sensor is attached, computing the optimal comparator threshold
voltage and outputting that value to the DAC.
W, dsPIt F D - IMngnitudeJ
-
3
Oi
Ready
PP Bte View Qesipn Nter Qutput £odegen V^ndow
gy , .ilijj ai«j m m as I n » n] jh !■
a
SPT.
a a
FIT
3 a
r RAT
Magnitude vs Frequency
10
1 1 I
•
I 1
1 « 1
i l I
\ i
* 1 1
1 1
\
l
* 1
• 1
1
•
1
j ;
Vl :
i 1
i
■
1 • •
\
3J a.
•
« '
\
1 • 1
: ; ;
■
\
...
0.0
* ■ I
' "" ' '""
« • 1
i
;
i-\
a o
--i
::r
3CO
430
SOti
Frequency (Hertz)
Sampling Frequency 1000
Passbants Frequency 350
Stop band Frequency 450
PQssban-3 Rippio 0.01 ( obj
3topband Ripple 3 (-dB)
All Frequencies in Hertz
16 Bil Fixed Point
Lowpass Filter
FIR (Window) Design
Minimum 4 term cosine Window
Filter Lcnotn; so
dsPIC FD Version 1.0.0 Build 1 - 15:33:55 Jul 2G 2006
Creed Huddleston
Flow Sensor - Srqnal Level Monitor
Amp Off (Q16
Figure 8.11. Signal Level Monitor Filter Response
Flow-rate Analysis
The data analysis of the flow-rate value is the same as the two previous applications;
it simply checks the latest filtered flow-rate value against the specified alarm limits,
sets the state of the corresponding limit LEDs appropriately, and then increments a
global counter that tracks how much time has elapsed since the previous flow rate
value was reported via the communication port. If a second has passed since the
previous report, the function sets the evt_report_results event to alert the main
processing loop that it should report the latest flow rate value via the communication
port. Finally, the routine clears the evt_analyze_data event to show that the data
analysis has been performed for the current filtered flow rate and returns.
Sensor Ap plica tion — Flo w Sensors 249
Signal-level Analysis
The sensor signal-level analysis first verifies that the sensor is indeed connected to
the system input. If the sensor is not connected properly, the pull-up resistor on
the input to the high (positive) side of the instrumentation amplifier will force the
instrumentation amp to a constant output near the positive voltage rail. In all other
cases, the signal will be below this rail, although it may temporarily approach it
when the turbine blade is passing the illumination point (since that is the time of
maximum reflected signal from the blade) . To confirm that the sensor is attached,
the application simply examines the filtered sensor signal level and declares that the
sensor is not connected if that signal level exceeds a preset value for longer than,
say, 0.5 seconds. The precise minimum detection voltage level and the time period
required to trigger a hardware- error detection can be adjusted by the designer, but
the combination should be somewhat beyond the maximum signal level and level
presence time that would occur during valid operation.
If the preceding analysis indicates that the sensor is not connected to the system,
it sets the global g_bHWError flag to indicate that fact, lights the Hardware Error
LED, and then skips the comparator threshold analysis since the sensor signal
would be invalid anyway. If the sensor is connected, however, the routine clears
g_bHWError, turns off the Hardware Error LED, and proceeds with the comparator
threshold analysis.
The comparator threshold analysis is extremely straightforward; it examines the
filtered signal level values on a sample-by-sample basis to determine the minimum
and maximum values over the preset threshold update period, computes the mid-
point of the two extrema, and outputs that midpoint value to the DAC to set the
new comparator level.
Once the comparator threshold analysis has completed (or, if the sensor is missing,
immediately after the sensor-detection analysis has finished), the main processing
loop clears the evt_analyze event.
Communication-protocol Module
Whenever the main processing loop receives an evt_report_results event, it
calls the FormatResultsMsg ( ) routine. This function formats the latest flow data,
then the main loop transmits the formatted message to the host system using the
routine TransmitResults () . Once the result message has been sent, the main
processing loop resets the evt_report_results event to show that the event has
been processed. The protocol used is the same as in the temperature and load-cell
monitoring systems, so it will not be discussed further here.
250 Chapter 8
8.6 Summary
The flow-meter application developed in this chapter introduced us to a form of data
acquisition in which the frequency and not the voltage level of the sensor output
signal contains the parameter data of interest. This is a simple, effective way to encode
sensor data, but there are caveats regarding its use in other applications. Care must
be taken to ensure that the system can process the minimum and maximum valid
signal frequencies, with special attention being devoted to very high-frequency rate
signals, since those can easily swamp a poorly designed system's ability to process.
Obviously, we could improve the applications performance through enhancements
such as flow-rate sensitive blade count accumulation (allowing longer accumulation
time for low- flow conditions to extend the lower range of measurement and shorter
accumulation times for high-flow conditions to increase responsiveness) or by add-
ing a current sense resistor to the sensors power line (to augment our diagnostic
abilities), but the focus of this chapter has been to introduce the reader to a general
sensor interface approach rather than to develop an exhaustive list of features.
In the final chapter, we'll look at where the intelligent sensor market is headed from
both technical and business perspectives.
Sensor Applica tion — Flo w Sensors 251
Endnotes
1 . Transducer Interfacing Handbook: A Guide to Analog Signal Conditioning,
Edited by Daniel H. Sheingold. Copyright 1980, 1981 by Analog Devices,
Inc., p. 24.
2. The RotoFlow™ line from CITO Products, Inc.
This Page Intentionally Left Blank
Where Are We Headed?
The best way to predict the future is to invent it.
— Alan Kay
Now that we're reasonably comfortable with intelligent sensors and the concepts
required to implement them, let's turn our attention to what the future holds for
these powerful devices. As with any new technology, today's intelligent sensors have
tremendous potential, but they also have a number of issues that must be addressed
in order for their use to become pervasive. How can we expect the field to behave in
the coming years? What are the drivers for intelligent-sensor diffusion into the mar-
ketplace, and what are the constraints upon it? Into which markets can we expect to
see significant intelligent sensor penetration, and what new capabilities are reasonable
to expect? These are the questions we'll explore in this chapter. While we may not
be able to answer them all, the reader should leave with at least an understanding
of the signposts that mark important points in the intelligent sensor's evolutionary
path and provide the reader with resources that will allow him to delve more deeply
into this fascinating subject.
9.1 Technology TV-ends
Intelligent sensors consist of three basic building blocks — sensing elements, compu-
tational elements, and communication interfaces — and the underlying technologies
of all three building blocks are evolving at a rapid pace. In the next few years, we will
witness an explosion in the capabilities of intelligent sensors, an explosion that will
improve functionality and connectivity significantly while simultaneously reducing
system cost. Let's look more closely at the developments that are occurring in each
of these three realms.
254 Chapter 9
Sensing-element Trends
One might suppose the field of transducer development to be fairly static, but that
supposition would be totally incorrect. Advances in this area have significantly
increased the sensitivity of a number of different types of sensors, particularly in
the area of chemical analysis. With this increased sensitivity, designers can create
systems that are physically smaller, that consume less power, and that require less of
the substance being analyzed in order to obtain an accurate reading.
Nowhere is this trend more pronounced than in the world of microfluidics, which
is devoted to controlling and/or analyzing extremely small quantities of a fluid. In
this case, small is very small, on the order of microliters or even nanoliters. 2 With its
concepts being applied to everything from inkjet printers to lab-on-a-chip devices
that scrutinize blood, the field of microfluidics covers a lot of ground. A subcat-
egory, known as digital microfluidics, is concerned with the precise manipulation
of fractions of a drop in order to assay the fluid's chemical makeup or to perform
some other useful task.
As one might expect, dealing reliably with such small quantities of a substance
depends upon a system's ability to accurately measure important parameters associ-
ated with the droplet. In particular, it turns out that the ability to precisely measure
and control the pressure and temperature of the substance and the pathways it must
traverse is critical; failure to maintain the proper conditions will bring a microfluidics
system to its knees. If, however, one is able to sustain the required environment, the
rewards are enormous: a reduction by several orders of magnitude in the amount of
a substance that must be tested, reporting of the results in a matter of minutes rather
than a matter of days, increased system portability, and reduced cost. Although not
the only area of significant sensor technology advancement, the field of microfluidics
is certainly one of the more obvious ones.
Designers can expect to see this trend of miniaturization and increased transducer
sensitivity to continue into the foreseeable future. Advances in complementary
fields such as nanotechnology will expand the environmental conditions in which
particular sensors can be deployed as well as creating entirely new types of sensors.
In order to effectively employ these advances, however, designers must not only
stay abreast of new developments in transducer technology; they must also learn
about the underlying physical phenomena from which the transducers derive their
functionality.
Where Are We Headed? 255
Computational Element Trends
By now, most of us have heard about Moore's Law, which is popularly taken to be
that computing power doubles about every two years. 3 While we can certainly expect
to see computational horsepower increase in the future, embedded microproces-
sor systems such as the ones that we've been exploring have other considerations
besides raw computational throughput. Power consumption, physical size, and
open hardware and software architectures are also important factors that, in certain
applications, may be more important than processing power.
Dramatically Lower Power Consumption
In many cases, the power consumption of the system is a critical factor prolonging
battery life in portable or remote applications and in reducing undesirable self-heat-
ing. Many digital electronics, including the dsPIC DSC and most processors, are
constructed in such a way that their power consumption and the heat they produce
are proportional to the speed at which they are clocked. Double the clock speed to run
the application twice as quickly, and you also double the amount of power required
by the chip. Although that's often a problem, it also offers a potential solution; by
shutting down portions of the chip when they're not needed and/or by slowing down
the clock under those conditions, we can dramatically reduce power consumption.
This is particularly important for single-use battery-operated systems that may have
to perform for weeks, months, or even years on a single set of batteries.
We are already seeing drastic reductions in the amount of power required to run
both processors and the circuitry required to condition the sensor signal, and we
can expect to see this trend accelerate in the future as the demand for much longer
battery life in mobile devices (measured in years, not days) continues unabated.
One particularly flamboyant advertising campaign by Microchip already employs
a microprocessor-based temperature-measurement system powered by a grapefruit
to demonstrate just how frugal their components are when it comes to power con-
sumption, 4 and such low-power operation will become the norm, not the exception,
in the future.
Unfortunately, nothing's free in this life; in order to cut power consumption
significantly, chip designers have had to reduce the power-supply voltages to 3.3V
and often less. That has serious repercussions, particularly in the analog signal chain.
By lowering the power-supply voltages, we effectively increase the noise level in
the analog signal chain relative to the power voltage span. For instance, if we have
256 Chapter 9
10 mV of noise in an analog signal that has a 5 V span, we've got a noise level of 2%
(10 mV / 5V = 0.02). That same 10 mV of noise in an analog signal with a 2.5V
span has essentially doubled to 4%, which can cause some pretty serious errors if
not handled properly. This effect may be exacerbated in excitation voltages that
have to be run a significant distance in an electrically noisy environment; indeed,
one of the reasons that many older sensor systems used ±10V or even ±15V as their
sensor excitation voltage is that such a large span minimizes the effect of noise on
the output signal.
The other negative aspect of reduced voltage parts is that they are more difficult
to interface to legacy 5V or higher systems. While not impossible by any means,
connecting newer low- voltage systems to older higher- voltage systems usually requires
some sort of level translation for reliable operation. Although it's not unusual for
I/O signals on newer parts to be 5V-tolerant, the output signals on the lower-volt-
age parts may not be able to actually drive the 5V system's inputs at a high enough
voltage level. This problem will fade in time as more and more systems migrate to
lower-voltage power requirements, but it is a factor that must be accounted for in
designs in the near term.
Continual Size Reduction
Hand in hand with the reduction in the power requirements for intelligent sensor
systems will be the drive to further compact the size of these systems. Small, battery-
powered sensor systems the size of an American quarter are already available, but
future systems will be even tinier. Known as motes, these completely self-contained
devices have on-board radio links that allow them to form ad hoc communication
networks (more on this in the section Communication Trends) for the exchange of
data between other motes in the network or host systems. As impressive as this may
sound, motes have been developed that are about 5 mm to a side, and the goal is to
eventually reach systems that are 1 mm 3 in volume 5 . That tiny package, about the
size of a grain of sand, will hold everything: sensor, processor, radio, and battery.
Such miniaturization brings with it a host of packaging and operational issues,
particularly finding a way to create an energy source in such a small volume that
has sufficient energy to run the system for an appreciable length of time. Commu-
nicating with such a small device is another important issue, since one would be
hard-pressed to connect to something that small with standard cables. We'll now
turn to the issue of communication, both with motes and with larger systems, in
the next section.
Where Are We Headed? 257
Communication Trends
As important as the advances in electronic circuitry will be to the future of intelligent
sensors, it will be the incredible enhancement of communication technology that will
drive dramatic growth in intelligent-sensor usage. Particularly for motes and other
very small sensor systems, this communication will be handled wirelessly through
ad hoc sensor networks that automatically form with little or no user intervention,
allowing rapid deployment. Physically larger sensor systems may still have wired
communication connections, but they will increasingly be based on high-speed
(100 Mbps and faster) networking standards to facilitate the aggregation, dissemina-
tion, and storage of the massive quantities of information these systems generate.
Let's look at some of the specific ways intelligent-sensor communication will evolve
in the future.
The Pervasive Internet
Harbor Research, Inc., a strategic consulting and research firm whose focus includes
the intelligent sensor sector, has coined the phase the "Pervasive Internet" to describe
the convergence of pervasive computing and widespread networking of devices
connected to the Internet. 6 Based on current trends, this is an apt description; the
ubiquitousness of devices of all types (cell phones, PDAs, laptop computers, etc.)
that support Internet access has mushroomed. The connection of intelligent sensor
systems to the Internet is starting up that same trajectory as well. While some may
consider this approach to be a devolution into "gadgetry," the truth is that there are
many applications that would benefit from the control such communication would
offer. For instance, it's not at all hard to imagine a car whose engine parameters
can be set by the user; extra power could be made available when the family goes
on vacation and needs to tow a boat or the top speed might be limited for a new
student driver. Although not commercially available today, such a configuration is
technologically feasible; it only awaits those astute enough to offer the service.
Before such a connected system becomes a reality, however, there are some serious
issues that must be addressed. The first such issue is rather prosaic: finding addresses
for all of those devices. The current Internet protocol, known as IPv4, supports up
to 4.3 x 10 9 unique addresses (4.3 billion), which sounds like quite a few until one
realizes that the address space works out to less than one address per person on the
planet. Given that each person is responsible for numerous items in their personal and
professional lives (automobiles, appliances, computers, and nonelectronic devices)
and given that organizations (schools, corporations, government, etc.) are stewards
258 Chapter 9
of many, many more, the current addressing scheme is completely inadequate to
the task of connecting these items together. Fortunately, the next generation of the
Internet Protocol, IPv6, supports far more addresses, 3.4 x 10 38 to be precise. That's
easily enough for our needs well into the foreseeable future. 7 Other approaches are
available as well, but none have progressed as far as IPv6.
A second issue is the matter of bandwidth; how do we efficiently transfer the
vast quantities of information that would be generated by such an interconnected
system? Although we've all seen the rapid growth of broadband Internet links (cable,
DSL, etc.), communications on the scale envisioned will require significantly greater
transmission capacity than is currently available. The Internet2 project 8 is develop-
ing a much faster Internet infrastructure that runs at 10 Gbps (10 9 bits per second),
but even this is only a start, and as of this writing (fall of 2006) is only available in
the United States. Significant work remains to be done in the area of high-speed
routing and information selection to reduce unnecessary network traffic to levels
that can be supported reliably and cost-effectively.
Wireless Communications
If all of the newly connected systems required cabling to communicate, the situation
would be hopeless; it would be cost prohibitive and too unwieldy to be feasible. For-
tunately, wireless communications are becoming widespread, easily implemented, and
very cost effective, allowing systems to "cut the cord" in many situations. Depending
upon the application, this may refer to eliminating only the communication cabling,
but increasingly it also means using battery-powered or passively powered devices
to do away with the power cabling as well.
A number of different wireless communication schemes are available that are
tailored to specific classes of applications. The relatively new ZigBee™ protocol is
particularly suited to low-power, low-data rate applications that may need to run
for years on a single battery. In these applications, communications are limited in
both duration and frequency of occurrence in order to reduce power consumption.
Other protocols, such as the popular 802. llx protocols used for wireless Local
Area Networks (LANs), are capable of continuous communication and are used for
applications such as real-time monitoring and control (with provisions for tempo-
rary interruptions, of course). Both ZigBee and 802.1 lx protocols are intended for
geographically limited areas. At the other extreme are wireless schemes that employ
cellular modems or other techniques to connect to devices across the globe. We can
expect to see much broader use of wireless technologies to reduce infrastructure
costs, to simplify installation, and to improve usability.
Where Are We Headed? 259
Security
A tremendous concern going forward is how to secure networks of connected devices
against unauthorized monitoring or worse — tampering. Depending upon the type
of information being reported by the system, this concern is no less valid for intel-
ligent sensing systems than it is for financial institutions. In particular, sensitive
information that is being used to control processes must be protected against both
intentional corruption and "snooping" to prevent outside personnel from damaging
the process or from gathering proprietary information. The need to ensure security
applies to both wired and wireless networks.
Protocol designers now recognize the importance of security to robust commu-
nications, and recently developed protocols such as ZigBee incorporate security as
a foundational element in their design rather than as something added as an after-
thought. Unfortunately, added security means added overhead to the information
bit stream, reducing data throughput and, depending upon the implementation,
increasing the hardware and/or software cost of the system. In the end, however, the
potential cost of a breach of security generally outweighs the actual costs incurred
to include it in the product.
Ad Hoc Networking
In many networking applications, one of the greatest expenses in terms of time
and money is the administration of the network. Maintaining a network of any
significant size usually requires the attention (and cost) of a highly skilled network
administrator, something that many of the applications targeted for intelligent sen-
sors simply cannot afford. What is required in order for sensor networks to thrive is
the ability for a relatively unskilled individual to quickly deploy these networks, and
for the network nodes themselves to automatically configure themselves for proper
operation. Such networks are known as ad hoc or self-organizing networks, and we are
seeing the first reliable systems emerge. ZigBee is an example of such a networking
scheme, allowing nodes to enter and leave the network without requiring a massive
reconfiguration, and there are other implementations as well, though they are often
proprietary. We can expect to see significant advances in this area in the relatively
near future (the next few years) .
Having looked at the technological trends shaping the intelligent-sensor space,
let's now look at the economic trends that will shape its acceptance.
260 Chapter 9
9.2 Economic Trends
Three key economic developments will drive the future adoption of intelligent
sensors: the demographics of an aging population, the increasing globalization of
operations, and the creation of new business opportunities. All three trends point
to strongly increased demand for intelligent-sensing systems.
Demographics of an Aging Population
In all developed countries, the birth rates have fallen below that required to sustain
their populations, and this has been the case for some time. The resulting aging of
the population, and in particular of the labor pool, has been recognized for quite
a while, but its effects are just now starting to make themselves felt with the retire-
ment of the baby-boom generation in the United States and their post- World War
II cohorts around the globe. In industry, medicine, and other activities, we will
shortly lose significant portions of the workforce, with no adequate replacements
immediately in sight. 9 If we are to maintain the economic engines that provide
our current level of goods and services, it follows that per-worker productivity will
need to increase dramatically in order to replace the productivity lost with retiring
workers. The most effective, indeed perhaps the only, way to accomplish that goal
is through the use of intelligent sensors that self-organize, self-diagnose, and that
on the whole require far less human interaction than current systems.
By the way, this is not just a developed-nation problem; the trend toward reduced
birth rate is true throughout most of the world, including the developing nations.
Unless reversed (something that could obviously happen, though it would take
time) , all countries will eventually face the same dilemma.
Increasing Globalization of Operations
No matter where you stand on the issue of globalization, it is a fact of life, and it
will continue for the foreseeable future as companies deploy resources to geographic
locations in which they deem the resources are employed most efficiently. While
globalization may reduce costs for the organizations, it also makes it more difficult
for those tasked with managing dispersed groups to gather and to act upon the
information they require in order to make effective decisions. To fill this gap, com-
panies will increasingly make use of intelligent-sensing systems to provide real-time
information to key decision makers and to technical personnel responsible for the
smooth operation of the organization. Because these decision makers and technical
personnel may not be — indeed often are not — physically located with the activities
Where Are We Headed? 261
for which they are responsible, the connected nature of intelligent-sensing systems
is critical to their ability to do their jobs well.
As with the issue of an aging population, globalization is not just a concern for
fully developed countries. Countries such as India and China, which are typically
perceived as the recipients of outsourced operations, now find that they themselves
must outsource work to distant areas within their own country or even to other
countries in order to remain cost competitive.
New Business Opportunities
Just as the network of railroads in the western United States in the latter part of the
nineteenth century offered enterprising organizations new business opportunities
by drastically reducing the time and cost to transport goods and people, so too will
the evolving field of intelligent sensors provide new ways for insightful businesses
to reap the benefits of pervasive computing power and globally networked devices.
Already, leading-edge companies are employing intelligent sensors in a wide vari-
ety of applications to deliver value to customers and to recover a portion of that
value in the form of revenues. In an interesting one-page display, Harbor Research
identifies nearly a hundred application segments that can benefit from networked
intelligent devices. 10
With intelligent-sensing systems, sensor providers and integrators now have the
ability to create on-going revenue streams from services related to monitoring and
using those sensors, rather than having to rely on the traditional unit-sales of indi-
vidual sensors. As mentioned in Chapter 1, this can provide tremendous benefits
to the end users while providing steady revenue to the supplier and strengthening
the relationship between the vendor and buyer. In a world increasingly dominated
by commodity-purchasing approaches by buyers, this aspect gives vendors a way
to differentiate their offerings and to avoid the perception by customers that the
vendor's products and services are just like everyone else's.
9.3 Summary
The basic premises of this book are that intelligent sensors are the future of the huge
and growing sensor market and that the dsPIC DSC provides an excellent foundation
upon which to build a wide variety of intelligent sensors. What has perhaps not come
through as clearly is that the functionality of these sensors is limited primarily by
the imagination of the designers who create them. Although the field of intelligent
sensors requires broad knowledge in a number of areas (analog signal conditioning,
262 Chapter 9
digital signal processing, and to a lesser extent digital design 11 ), it affords a canvas
upon which a creative designer can paint some incredible applications.
Ultimately, as Alan Kay notes in the chapter's opening quotation, "the best way
to predict the future is to invent it." The reader is encouraged to delve into this
realm more deeply and to bring his or her unique knowledge to bear on a particular
application or group of applications. Not only is the design of intelligent sensors a
wonderful intellectual challenge, each new sensor adds to our ability to understand
and to shape our world. It may be financially rewarding, as in the case of a system
that's widely used to manufacture billions of parts worldwide, or it may change a
person's life by making the world more accessible through the creation of a smart
prosthetic. If you apply your acumen and insight along with the information pre-
sented in this book, you can make a significant difference with your implementation
of intelligent sensors.
Where Are We Headed? 263
Endnotes
1 . Kay is a giant in the field of computer science who was one of the founders
of Xerox's famed Palo Alto Research Center (PARC). A pioneer in the devel-
opment of modern object-oriented programming and windowed graphical
user interfaces (GUIs) with his work on the computer language Smalltalk,
Kay designed a graphical, object-oriented personal computer during his
Ph.D studies at the University of Utah. While that may not seem particu-
larly impressive today, given that Kay did it in 1969, the feat is seen as truly
groundbreaking. The man knows whereof he speaks.
2. A microliter is one-millionth of a liter (10~ 6 liters), and a nanoliter is one-
billionth of a liter (10~ 9 liters). To put that in perspective, those volumes are
less than a single drop of fluid.
3. Moore's Law is named for Gordon Moore, a cofounder of the Intel Cor-
poration of PC processor fame, who made the prediction in 1965. In fact,
according to the Intel website, Moore actually stated that the number of
transistors on a chip doubles approximately every two years. Given that the
number of transistors in a microprocessor offers a rough approximation to
the chip's processing power, the "law" evolved over the years into its more
popularly known form. An in-depth look at Moore's Law can be found at
http : //www. intel. com/ technology/silicon/mooreslaw.
4. The demonstration uses a Microchip PIC microcontroller fabricated using
their nanoWatt™ technology.
5. Kristofer Pister, professor of electrical engineering at the University of
California at Berkeley, as quoted in the March 23, 2004 online version of
ComputerWorld magazine, which can be found at http: //www. computer-
world.com/mobiletopics/mobile/story/0, 10801 ,79572, 00. html.
6. The Harbor Research website (www.harborresearch.com) has a number of
insightful white papers on business opportunities in the Pervasive Internet
space, as well as on the specific strategies appropriate to capitalize on those
opportunities.
7. To put the number of IPv6 addresses in perspective, the new protocol allows
roughly 50 octillion (50 x 10 27 ) addresses for each of the approximately 6.5
billion people currently on Earth. Interestingly, IPv6 also sprang from the
fertile minds at PARC (see footnote 1).
264 Chapter 9
8. More information on the Internet2 project is available at the organization's
website, www.internet2.edu.
9. That's not to imply that younger workers are incompetent, merely that the
number of younger workers is insufficient to replace those retiring.
10. Venue Segmentation Map for Intelligent Device Networking and Management,
available for download from www.harborresearch.com.
1 1 . This statement is in no way meant to denigrate the importance of solid
digital design; it is instead an acknowledgement of the fact that so much
functionality that previously would have required separate digital circuitry is
now integrated into the dsPIC chip itself. Effective digital design techniques
are still required to use the dsPIC DSC, but the degree of system integration
reduces the demands on that skill.
Software on the Included CD-ROM
The software on the included CD consists of an on-disk website with links to valuable
resources on the Internet and the source code and project files for the three applica-
tions developed in the book. To view the website, either use Windows Explorer™
(the file management program, not to be confused with Internet Explorer, which
is a web browser) to find the file index . htm in the root directory of the CD and
double-click on the file. That should start your web browser and load the first page
of the site. Alternatively, you can enter:
D: \index.htm
in the address bar of your web browser and press the "Go" button in the browser to
load the first page. Note that this assumes that your CD drive is drive D; if this is
not the case, simply substitute the appropriate letter in the path.
A.1 On-disk Website of Resources
The links on the website provide the reader with an easy way to obtain some of
the information discussed in the book — in particular, access to reference materials
and vendors that provide useful components or equipment. As with any site that
references pages in another website, some links may become stale and no longer
work. If that happens, search on the Internet using the phrase used for the link (as
opposed to the link itself), and you should be able to find the appropriate data if
it's still available.
Please note that the links are included to help the reader find information
quickly and are not meant as an endorsement of any particular product or vendor
by Elsevier Science and Technology Books or Newnes (with the obvious exception
of their own books) .
266 Appendix A
A.2 Source Code for the Three Applications
The complete source code for all three applications, including project files for use
with the Microchip C compiler, are included in separate directories:
• \Source\Thermocouple — the thermocouple sensor system
• \Source\Load Cell — the load-cell sensor system
• \Source\Flow Meter — the flow-meter sensor system
All of these applications require the Microchip C compiler, v2.02 running under
the Microchip MPLAB v7.40 Integrated Development Environment (IDE) in
order to compile and link (later versions should work as well, but earlier versions
may not). The MPLAB IDE is available for free from the Microchip website (www.
microchip.com), and a student version of the C compiler is available for free from
the site as well.
If you would like to alter the digital filters used in any of the applications, you
will need to purchase a copy of the dsPIC Filter Design™ software, which is also
available from the Microchip website. In order to run the applications, you will need
a Microchip dsPICDEM 1.1 General Purpose Development Board and an ICD 2
in-circuit debugger to download the program file to the dsPICDEM board. Both
of these items can be obtained through the Microchip website as well.
Initialization of the dsPIC DSC
and the System Start-up Code
When the dsPIC DSC first boots out of reset, it begins running the code residing in
the Reset vector location (00000H) with all interrupts disabled. In order to operate
properly, the code must jump past the Interrupt Vector table and the Alternate Vec-
tor table to the application code space and then start running what is known as the
start-up code. A critical component of the firmware, the start-up code configures the
C runtime environment so that the application itself (written mostly, if not entirely,
in C) can execute as expected. This step must be taken before any calls to C code,
or the C code may fail, inevitably in some manner that is difficult to diagnose.
Because the start-up code initializes the C runtime environment, it is specific to
the compiler being used and is distributed as part of the compiler. For the Micro-
chip compiler, two start-up code files are provided, one (crto .o) that initializes all
initialized data to values that are read from the program memory and that clears all
uninitialized data to 0, and a second (crti . o) that does not initialize any data. Other
than that, the two modules are the same and perform the following actions: 1
1 . Initialize the Stack Pointer register (wis) and the Stack Pointer Limit register
(splim) using values generated by the linker.
2. If a .const section is defined, the start-up code maps it into the program-
space visibility window by configuring the psvpag and corcon registers
appropriately.
3. Perform data initialization (crto . o only).
4. Call the main ( ) application entry point to start the user's application.
267
268 Appendix B
Note that the standard start-up code included with the Microchip C compiler
does not perform any hardware initialization other than the registers mentioned
above; the users application code is responsible for configuring the hardware and
any required other software set-up.
Most of the time, the start-up code is transparent to the application program-
mer. Included as part of the standard linker files are instructions to place a GOTO
statement to the start-up code at the Reset vector location and further instructions
to link in the standard start-up code module crto . o, which performs the required
C system initialization and then calls the user's program. Occasionally, however, the
application may require immediate configuration of some critical system resource, in
which case the user can modify the assembly-language source file crto . s or crti . s to
implement the appropriate changes. If such a modification is required, the program-
mer must include the file crtx.s (where x is either or 1, as necessary) in the list
of project source files to ensure that it is properly linked into the final application.
Initialization of the dsPIC DSC and the System Start-up Code 269
Endnotes
1 . This information can be found in the section, Startup and Initialization, of
the MP LAB C30 C Compiler User's Guide.
This Page Intentionally Left Blank
Buffered, Interrupt- driven Serial II O
In many discussions of serial communications, the author assumes that the
reader has access to routines that reliably transmit and receive data so the subject
is addressed at a very high level. Although often treated as an exercise left to the
reader, the topic of developing a dependable low-level communication interface
is one whose solution is often far from obvious and changes from processor to
processor, even when discussing processors produced by the same manufacturer.
The key to solid serial communications in real-world conditions is to create a
buffered, interrupt-driven I/O framework. Let's examine what we mean by that
mouthful of technical jargon.
An I/O framework is simply an architecture that we use to perform all of our
input ("I") and output ("O") serial communications. By adhering to the framework,
we should be able to ensure that our device receives and transmits all of the data
that it needs to handle.
An interrupt-driven framework is one in which we allow the communication
hardware to interrupt the processor so that the processor can deal with the new
communication condition immediately and then return to what it was doing. If we
were to use the alternative, a polling framework in which the processor periodically
polls (queries) the communication hardware to see if anything needs to be done, we
would have to design the application firmware to guarantee that the processor finished
all of its other tasks in time to check for the fastest possible communication event.
Given that communication events can come fast and furiously, a polled architecture
can be severely restrictive for all but the slowest communication channels.
Finally, a buffered, interrupt-driven framework is one in which the data to be
transferred between the application and the communication channel is stored in
queues, with the underlying interrupt-service routines and the application program
271
272 Appendix C
managing access to the queues in such a way as to ensure that the queue data is
coherent (accurate, with no conflicts between access by the ISRs or the application).
This approach offers maximum flexibility for the application while ensuring highly
reliable communications with minimum processing overhead.
The heart of this type of framework is the data queue, which in practical terms
consists of a receive data queue to hold data received previously by the device from
other systems and a transmit data queue that holds data to be sent by the device
to other systems. Obviously, the amount of data that the device may be asked to
handle over time will far exceed the limited memory of any real-world processor, so
the queues are designed as circular buffers, with data being added to the buffer in a
sequential manner until the end of the buffer is reached, at which point new data
is added to the buffer starting at the beginning. Data is removed from the buffer
in a similar manner. Conventionally, the point at which data is being added to the
buffer is known as the head of the buffer, while the point from which data is being
read from the buffer is known as the tail.
To use the queues, functions at the application level and those of the inter-
rupt-service routines maintain two sets of indices to determine the buffer locations
that the corresponding functions will use next. The specific purpose of each index
depends upon the execution level (application or interrupt) of the function using
the index and the queue upon which the function is operating. For instance, when
the application wants to send data to another system, the application-level function
writes that data to the transmit data queue and updates the index the application
maintains of the next byte in the transmit data queue to which it can write. When
the interrupt service routine that handles data transmission notes that there is new
data to send, it will read the data written by the application level, update its (the
ISRs) index of the next byte to read from the queue, and then send the data to the
communication hardware. In this case, the application-level functions are responsible
for maintaining the head of the circular transmit data buffer, while the ISR func-
tions are responsible for maintaining the tail of the buffer. The situation is reversed
for the receive data queue, with the ISR being responsible for the head of the buffer
and the application-level code handling the tail.
This approach works well until something happens that prevents one or both
of the queues from emptying as quickly as they are filled. In this case, the head
eventually overtakes the tail, a condition known as buffer overflow. If the buffer is
allowed to overflow, all the data between the tail and the now rampaging head is
lost. Since some data is going to be lost under these conditions no matter what,
this implementation chooses to ignore data received after the buffer is full, rather
Buffered Interrupt-Driven Serial I/O 273
than to lose data that has already been received. Note that once the buffer empties
by one or more characters, data reception will continue again.
C.1 Pseudo-code for the Framework
The actual code for the serial interface is contained in the files CommiF . c and Com-
miFDef .h. The pseudo-code here provides a high-level reference to the tasks being
performed by the interface. To use the interface, the application must first initialize
the communication hardware and associated global state variables and enable the
corresponding processor interrupts. The application can then read data from and
write data to the serial ports using the functions shown below.
C.2 System Initialization
To initialize the communication system, the user calls the function CommInit()
with parameters specifying which UART ( l or 2) to use, along with the requisite
communication parameters (bit rate, parity type, and number of stop bits).
Calling sequence:
Uintl6 CommInit(Uint8 ui8Port #
Uintl6 uil6BaudRate,
Uintl6 uil6Parity,
Uintl6 uil6StopBits)
Example: Initialize UART l to communicate at 19.2 Kbps, using no parity and
l stop bit
CommInit(UART_l / 19200, PARITY_NONE, STOP_BITS_l) ;
C.3 Reading Data From the Interface
To read data from the communication interface, the application calls the routine
CommGetRxPending ( ) to determine whether there is any data available to read, and
if the return value (which indicates the number of pending data bytes) is greater
than 0, the program reads in the next byte of data from the receive data queue by
calling the function CommGetRxChar ( ) with a parameter that is a pointer to an 8-
bit location to hold the data read from the queue. If CommGetRxChar ( ) returns a
nonzero status value, an error has occurred (see the file statusDef . h for a complete
list of status code values), and the application should not use the data returned in
the buffer pointed to by the parameter.
274 Appendix C
Calling sequence:
Uintl6 CommGetRxPendingCount (void) ;
Uintl6 CommGetRxChar (Uint8 *pui8Data) ;
Example: Check for pending data from the communication port and read it in
Uint8 ui8Data; // Buffer to hold data from Rx queue
if (CommGetRxPendingCount () > 0)
CommGetRxChar (&ui8Data) ;
C.4 Writing Data to the Interface
To write data to the communication interface, the application calls either the rou-
tine CommPutChar ( ) to send a single byte of data or the function CommPutBuf f ( )
to transmit a buffer of data. In either case, if the function returns a nonzero status
value, an error has occurred (see the file statusDef .h for a complete list of status
code values) .
Calling sequence:
Uintl6 CommPutChar (Uint8 ui8Data) ;
Uintl6 CommPutBuf f (Uint8 *pui8Data # Uintl6 ui!6Length) ;
Example: Transmit the value "d" .
Uint8 ui8Data; // Buffer to hold data for Tx queue
ui8Data = *d' ;
CommPutChar (ui8Data) ;
Example: Transmit the string "dsPIC" (without the NUL terminator)
CommPutChar ( MsPIC" , 5 ) ;
Index
Numbers
16-bit Signed Twos Complement Integer
Representation, 61-62
16-bit Timer and 16-bit Synchronous
Counter Initialization, 94
32-bit Timer or Synchronous Counter
Initialization, 94-95
40-bit Barrel Shifter, 67
A
A/D Conversion Timing, 73
AC Power, 179-180, 200, 214-215, 217,
219
Accept Input state, 192-193
Acceptance Filters, 120-121, 123-125
Accessing Configuration Memory from the
User Memory Space, 60
Accumulator Saturation, 67
Accuracy of Measurement, 173, 212-213,
233
Acquisition Time, 72, 87
Active Sensing Elements, 211
Ad Hoc, 256-259
Ad Hoc Networking, 258-259
AD Pin Configuration Register Bit-
mapping, 77
ADC Conversion Clock, 82-83, 86-87
ADC Interrupt-handler Code, 223
ADC Reference Voltage Configuration
Values, 79
Address Generation Units, 56, 60-61, 67-68
Addressing Modes, 56, 60, 67-69
Aliasing, 33-35, 44, 46, 207
Alternate Channel Sampling, 79
American Curve, 164
Analog Amplifier and Antialiasing Filter,
197-198
Analog Input Signal Assignments, 202
Analog Sample, 72, 75
Analog Signal, 7, 29-31, 33, 44, 48, 50,
52, 71-72, 83-84, 97, 168-169, 202,
205-206, 217, 219, 233-234, 237-239,
249-251,255-256,261
Analog Signal Frequency Spectrum, 33
Analog-to-digital Conversion, 7, 3 1 , 74
Analog- to-Digital Converters, 7, 71
Antialiasing Filter, 186-187, 197-198,207,
214-217, 243, 245
276 Index
Application Data Flow, 139-140
Application Design, 271, 96, 184-185, 214-
216, 234-236
Application Framework Data Flow, 14 1
Application Test Bed, 137
Asynchronous Counter Mode, 89-90, 93
Asynchronous Signaling Scheme, 104-105
Asynchronous vs. Synchronous Data
Transfer, 103
automatic trigger, 84-85
B
Bandpass Filters, 36-37, 39
Bandwidth, 28, 35-38, 74, 134, 175, 179-
180, 186,217,237-239,258
Basic CAN Architecture, 119
Basic CAN Interface Framework, 125
Basic Idealized Thermocouple Circuit, 22
Basic Interleaved Sampling, 80
Basic Thermocouple, 13, 22-23
Basic Toolkit for the dsPIC DSC, 137
Basic UART Interface Framework, 108-1 10
Blade Transition Counter, 246
Buffer Overflow, 272
Buffered,
Interrupt-driven Framework, 271,
107-108, 110
Interrupt-driven Serial I/O, 271, 18
Burst Throughput, 100-101
Bus Arbitration, 120-121, 123
C
C30 Compiler-generated Code and Data
Sections, 144-145
Calibration, 3-8, 47, 173, 177-179, 185-
186, 212, 214-217, 231-232, 234-235
Curve, 177-179, 234-235
CAN Data Formats, 120
Carrier Sense System, 119
Challenges of Flow Measurement, 231-232,
234
Channel Data Throughput, 101
Channel Scanning, 80-82
Charge Amplifier, 211
Checklist for Using the ADC Module, 86
Circular Buffers, 272
CJC, 176
Cleaning Up the Signal, 29
Code Generation Options Dialog, 157
Cold-junction Compensation, 80, 98, 173,
175-176, 185-186, 197-199, 202, 207
Schematic, 199
Collision, 119-121
Detection, 119
Combined Interleaved Sampling and
Channel Scanning, 82
Command Message Data Formats, 129, 131
Command-specific Protocols, 129
CommInit() Function, 273, 111
Common Timer/Counter Features, 87-88,
92
CommPutCharO Function, 116
Communication Options Available on the
dsPIC30F, 106,
Communication Protocol, 48, 119, 185,
192, 204-205, 237-240, 243
Implementation, 204-205
Module, 249
Trends, 256-257
Comparator Threshold Level Computation
Algorithm, 242
Computational Element Trends, 254-255
Index 277
Concepts for Signal Processing, 21
Digital Filter Implementation, 39, 202, 224
Configuring the I/O Port Pins, 75
Digital Filtering Analysis, 185, 188,237
Continual Size Reduction, 255-256
Digital Microfluidics, 254
Continuous-time Voltage Signal, 3 1
Digital Signal Controller or DSC, 8, 53
Controller Area Network (CAN), 106, 118,
Digital Signal Processing, 7, 16, 21, 44, 51-
135
52, 55, 57-58, 67, 97, 162, 217, 219,
Conversion Trigger, 82, 84-86
261-262
Source Bit Mapping for ADCON1 SFR,
Digitization, 44-46, 48, 50, 71, 73, 76-77,
85-86
82-85, 171, 174, 184,247
Curves of Various Thermocouples, 163
Effects, 44, 46
Error, 45
D
Error Introduced by Truncation, 45
Data Acquisition Peripherals, 70-71
Sampled Signal, 44
Data Analysis Algorithms, 185, 190,217,
Digitizing the Sensor Signal, 7
237-239
Dramatically Lower Power Consumption,
Data Analysis,
255
Code, 225
DSP Engine, 60-62, 65, 202
Flow Chart for Thermocouple Sensor,
dsPIC,
191
30F6014A Program Space Memory
Implementation, 203, 225
Data Filtering Module, 243, 245, 247
Data Space Memory Map, 56-57
Data Throughput, 57-58, 67-68, 101,
258-259
Data-acquisition Module, 243, 245-246
Data-analysis Module, 247
Defining Characteristics of a
Communication Channel, 100
Demographics of an Aging Population, 260
Development and Production Costs, 1 1 ,
106
Diagram of a,
Type B Timer/Counter, 95
Type C Timer/Counter, 95-96
Differential Amplifier, 186-187, 214-215
Digital Filter Analysis, 217
Map, 59
Analog-to-Digital Conversion
Circuitry, 74
DSC, 267, 16-18, 53-58, 60-63,
65-71, 73-74, 78, 80, 83-87, 89-90,
93-96, 99-101, 106-107, 110-111,
115, 118-121, 123, 125-127, 129,
131-134, 137-138, 145-148, 162,
169, 171-172, 176, 183-184, 186,
197-201, 213-214, 225-226, 233,
237-240, 243, 245-246, 255, 261,
264
DSC Memory, 55
DSC s Data Processing Architecture,
54-55
Interrupt Configuration, 146-148
Test Bed Block Diagram, 138
278 Index
dsPIC30 Code Base File Name Dialog,
157-158
dsPIC30F DSP Engine Block Diagram,
62
DTMF,
Frequency-domain Representation, 27
Time-domain Signal, 27
Tone Combinations, 36-38
Dual 40-bit Accumulators, 65-66
Dual Tone Multifrequency, 25
Economic Trends, 259-260
Electronic Noise Signal, 24
End-of-Arm Force/Torque Sensor, 84
Errata, 54-55, 97
Erroneous Interpeak Period Change, 24 1
Error Conditions, 47, 67, 103, 141, 180,
183, 186, 203-204, 214-215, 234-236
Error Detection and Handling, 47-48, 50,
120
Error-handling Implementation, 203, 225-
226
European Curve, 164
Example Arbitration of Two Simultaneous
Messages, 124
Excitation Voltage, 210-217, 219, 255-256
Execute Command State, 193-194
Extended CAN Data Frame Format, 122
Filter Response for,
Loose Stopband Ripple Specification,
189
Tighter Ripple Specification, 190
Finite Register Length Effects, 44, 46
FIR Filter,
Code Generation Menu Selection, 1 56
Design Menu Selection, 154
Design Window, 154-156
Firmware Implementation, 200, 217, 219,
243, 245
Flow Chart for Reading UART Data in the
Application, 115
Flow Sensor Signal Conditioning, 237
Flow Sensors, 14-15, 229, 231-232,
246
Flow Signal with Signs of Wobble,
239
Flow-rate Analysis, 248
Four SPI Operating Mode Combinations,
107
Fourier transform, 25, 28, 60-61
Fractional Vectors, 202
Frequency Band, 28, 179-180
Frequency Content, 36, 46-47, 139-140,
174, 179-180, 185-186, 213-217, 234,
243, 245
Frequency Domain, 25, 28-30, 32
Representation, 26-28
Frequency Mask, 30
Frequency Response of Butterworth Filter,
188
General Message Protocol, 127-129
Command Format, 127
Response Format, 128
General Sensor Signal-processing
Framework, 47-49
Generic TRISx Register Bit Mapping, 76
Gravimetric Sensors, 229, 231-232
Index 279
H
Hard Real-time System, 48
Hardware,
Block Diagram, 197-198, 243
Error Detection, 106, 118
Implementation, 197, 237-240, 243
Multiplier, 65
Head of the Buffer, 272
High-level Protocols, 125-126
High-pass Filter, 36-37, 39
HLPs, 126
I
Idealized,
Bandstop Filter, 39
Thermocouple Signal, 23
Implementation of,
Simple Communication State Machine,
194
Framework Modules, 149
Increasing Globalization of Operations, 260
Index Notation, 32
Infrared Sensors, 162, 165-166
Initialize state, 1 92- 1 94
Initializing the,
Software Environment, 144
System Hardware and Software State
Machines, 146-147
Intelligent Sensors, 1, 3, 8-18, 15, 21, 48,
50-51, 53, 70-71, 99-100, 137, 185,
249-250, 253, 255-262
Interleaved Sampling, 75, 80, 82, 201
Internal Code Documentation, 139
Interrupt Latency, 70
Interrupt Structure, 60, 68-69
Interrupt Vector, 267, 58, 60, 69
Interrupt-driven Framework, 271, 107-108,
110
Introduced by Rounding, 45
Introducing Filters, 29
K
Key Aspects of,
Flow Measurement, 231-232
Load Measurement, 212
Temperature Measurement, 1 66- 1 67
L
Laminar Flow, 229
Linearization, 13-14, 48, 50, 173, 176-177,
212-214, 234-235
Load cells, 211-215
Load Sensors, 209
Load-cell Interface (Single Channel), 217
Low-pass Filter, 35-37, 39-40, 179-181,
188, 197-198,237,247
Remove Out-of-Band Power-line Noise,
181
M
MAC Class Instructions, 56
Mandrel, 164
Manual Triggering, 84-85
Mapping Program Memory to the Data
Space, 60
Mass Flow, 229, 234-235
Material Density Compensation, 234-235
Measured "True" Signal with Shot Noise, 43
Median Filters, 41
Mercury Bulb Thermometers, 2
Message Filtering, 125
Microchip dsPIC, 40
Modified Harvard Architecture, 55-56, 60
280 Index
Motes, 256-257
Multichannel Digital Temperature Sensor,
13
Multidrop,
Network, 102
Topology, 101
Multiple Access, 119
Multiply- accumulate, 56, 60-61
Multiplying Mask, 30
N
Negative Temperature Coefficient, 165
Noisy Thermocouple Signal, 24
Nominal Flow Signal with No Wobble, 238
Notch Filter to Remove In-band Power-line
Noise, 182
Numeric Data Representation, 6 1 -62
Nyquist rate, 33, 46
O
On-chip Peripherals, 70-71, 146-147
Open Thermocouple, 183, 186-187,203-
204
Oversampling, 44, 46-47, 185
Overview of the Firmware Framework, 138
Parameter Analysis, 48, 50, 247
Parse Input state, 193
Passive Sensing Elements, 211
Pervasive Internet, 256-257, 263
Physical Properties of the Data Link, 1 02-
103
Piecewise Linearization, 176-177, 234-235
of a Curve, 1 77
Piezoelectric Sensors, 211-212
Point-to-Point,
Communication Network, 1 02
Topology, 101
vs. Multinode Networks, 101
Post-analysis Filtering, 48, 50
Pre-analysis Filtering, 48, 50
Pressure and Load Sensors, 209
Pressure Sensors, 17-18, 209
Program Space Memory Map, 57-59
Mapped as Data Space Memory, 57-58
Pseudo-code, 273
Pseudo-code for the Framework, 273
Pure Harvard Architecture, 55-56
R
Range of Measurement, 162-163, 167, 212,
231-232,249-250
Reading Data From the Interface, 273
Realistic Thermocouple Circuit Model with
Noise, 23
Recommended Maximum CAN Bus
Lengths, 120
Resistance Temperature Detectors (RTDs),
162-163
Resistive Sensing Element Used to Measure
Current, 4
Resolution, 45-46, 71-73, 77-78, 89, 167-
169, 171-173, 175,212-217,219,
231-233,237-239,243,245
of Measurement, 168, 175, 212-213,
231-233
Response Message Data Formats, 129, 131-
133
Response of Notch Filter for AC Power
Noise Removal, 219
Resulting Filtered Sensor Signal, 181-182
Index 281
Resulting Signal after Processing with
Length-7 Median Filter, 43
Reversed Thermocouple, 184-185, 203-204
RTD, 47-48, 163-165
Sample "True" Signal, 42
Sample Temperature Signal,
with In-band Power-line Noise, 1 82
with Overlapping Power-line Noise, 183
Sample Trigger, 84-85
Sampling, 29-35, 44, 47, 72-75, 78-87,
97-98, 108-110, 139-141, 143, 148-
149, 175, 186-187, 201, 203, 213-217,
219-222, 224, 231-234, 247
Analog Signal, 29-3 1
Time, 72, 78-79, 84
Schematic of,
Load-cell Interface, 218
Thermocouple Interface (Single
Channel), 187
Wheatstone Bridge Strain Gage, 210
Security, 139-140, 258-259
Seebeck effect, 13, 162, 176, 206
Selecting the,
Analog Inputs to Digitize, 78
Reference Voltage Sources, 76-77
Sampling and Conversion Triggers, 84
Self-organizing Networks, 259
Semisequential Channels, 80
Sense Resistors Added to Thermocouple
Inputs, 184
Sensing-element Trends, 253-254
Sensor, 2-13, 15-19, 21-22, 28-31, 44, 47-
51, 70-71, 84, 99-101, 106-108, 126,
134, 137, 139-144, 158-159, 161-176,
179-183, 185-186, 191, 197-200,205-
207, 209-217, 221, 224-226, 229-240,
243-250, 253-259, 261-262, 266
Application, 47, 161, 209, 229
Information, 8-10, 21, 51, 144
Signal Application, 47
Signal Conditioning, 185-186, 214-
217, 237
Signal Level Filtering, 247
Signal Level Monitor, 243, 245-246
Signal-processing Framework ,
47-49
Sensors, 1-7, 9, 11-18, 21, 47-48, 53, 99-
100, 129, 131-134, 162, 165-167, 174,
209-214, 225, 229-234, 246, 253-254,
256-262
Serial Peripheral Interface (SPI) Port, 71,
106
Shadow Registers, 70
Shot Noise with a Burst Length of Three
Samples, 42
Shot or Burst Noise, 41
Signal,
Characteristics, 33-35, 173-174, 212-
213, 234-235
Conditioning and Acquisition, 48, 50
Digitization Process Showing Four
Successive Samples, 44
Isolation, 197-200
Level, 48, 50, 83-85, 97, 174, 179-180,
197-199, 203-204, 206, 237-239,
243, 245-249
Level Analysis, 248-249
Level Monitor Filter Response, 248
Linearization, 48, 50
Path Configuration, 75
282 Index
Sampling, 44, 47, 85-86, 201, 213-214,
217,219-220,234
Sampling Configuration Code, 220
Signals and Noise, 2 1 -22
Signals in the Frequency Domain, 25
Signed Ql 6 or 1 . 1 5 Fractional
Representation, 63
Silicon Sensors, 162, 165
Simple Communication Handler State
Machine, 193
Sources of Noise, 167, 179-180, 214-215,
231-232,234-235
Special Function Registers, 56-57, 67-68
Spectral Analysis, 28
Spectral Replication, 32
Standard CAN Data Frame Format, 122
Standard Sensor, 9-11, 13
State Machine to Process Protocol, 130
State Variables, 273, 111, 114, 194, 224
Static RAM (SRAM), 56-57
Steer-by- Wire Steering-position Sensor, 1 5
Strain Gages, 210-211
Sustained Throughput, 101
Synchronous Counter Mode Initialization,
92
Synchronous Signaling Scheme, 103-104
System Initialization, 268, 273, 142-144,
146-147, 149, 152-153, ix
System Specification, 185, 214-216, 234-
236
System Task Flow, 1 42
217,231
Sensor, 2, 13, 47, 106-107, 158-159,
161, 163, 165, 179, 185,221,224
Signal with Out-of-band Power-line
Noise, 181
Thermal Compensation, 213-214
Thermistors, 162, 165, 206
Thermocouple Measurement Ranges, 168
Thermocouples, 13-14, 36, 47-48, 161-
168, 173-177, 180, 183-185, 197-199,
203-204,211
Time-Domain Sinusoidal Signal, 26
Timer Mode Initialization, 91-93
Timer/Counter Module, 87
Transition Conditions, 192
Transmit Response, 194, 196
Turbine,
Flow Sensor, 230, 233-236
Flow Sensor Output Signal, 23 1
Sensor Interface Circuitry, 243-244
Sensors, 229-231
Turbulent Flow, 229
Type A Timer/Counters, 89-90
Type B Timer/Counters, 93-95
Type C Timer/Counters, 87, 93-95
Types of,
Communications, 99
Flow Sensors, 229
Load and Pressure Sensors, 209
Temperature Sensors, 162, 167
T
Technology Trends, 253
Temperature,
Measurement, 161, 166-167, 203-204,
U
UART Data Transmission, 109
Underneath the Hood of the dsPIC DSC,
16-17, 53
Unit Impulse Signal, 40
Index 283
Universal Asynchronous Receiver-
Transmitter (UART), 107-108
V
VCFG Bit-mapping in the ADCON2
Register, 79
Volume Flow, 229, 231-232
W
Website of Resources, 265
Wireless Communications, 100, 258
Writing Data to the Interface, 274
ZigBee, 258-259
Live Music Archive
Librivox Free Audio
Metropolitan Museum
Cleveland Museum of Art
Internet Arcade
Console Living Room
Books to Borrow
Open Library
TV News
Understanding 9/11