7
9
25274 75349
1 0>
CIRCUIT
CELLAR
®
www.circuitcellar.com
T H E M A G A Z I N E F O R C O M P U T E R A P P L I C AT I O N S
$4.95 U.S. ($5.95 Canada)
#159 October 2003
DATA ACQUISITION
Bridge to CANopen
Monitor Speed with GPS
Gather & Display Data with a Palm
Capture Repetitive Waveforms
Now with
instrumentation-quality
programmable analog.
Powerful new programmable analog and digital
blocks with memory and MCU for less than $2.
Winner of the EDN Innovation of the Year award,
our PSoC
TM
Programmable System-on-Chip
TM
device
is changing the face of embedded design.
Replace 1,000s of fixed-function devices
with a couple of keystrokes
Dynamically reconfigure a PSoC device,
changing functionality on the fly in any
application
Select from hundreds of predefined
blocks in our mixed-signal library
Already designed into 1,000s of applications;
check out our online app note library
PSoC
™
Mixed-Signal Array.
It’ll change the way you
think about embedded design.
Instrumentation Amp with Driven Shield
Front End with Adjustable Gain
Difference Amp
Instrumentation Amp 2
CYPRESS ENHANCED ANALOG
™
(CEA
™
)
•
Rail-to-rail analog
•
Instrumentation amps
•
Lower voltage offset
•
Lower input leakage currents
•
Programmable gains
•
Better stability
One of 1,000s of examples of programmable analog blocks.
PSoC Mixed-Signal Arrays with M8 Microcontroller
CY8C27X
CY8C24X
CY8C22X
126
3
8
4
4
16K
4K
2K
256
256
256
low as $1.99
low as 99¢
low as 69¢
CEA ANALOG BLOCKS
DIGITAL BLOCKS
HI REL SONOS FLASH
SRAM
COST
Reduce board size and BOM up to 80%
before
after
Check out our free online training and our 4-hour applications support:
w w w . c y p r e s s . c o m / a d / p s o c - c e a 1
$30,000
PSoC International
Design Contest
w w w. c y pr es s . c o m
/a d /p s o c - c e a1
©
Cypress
Microsystems,
Inc.
2003.
PSoC,
Programmable
System-on-Chip,
Cypress
Enhanced
Analog
and
CEA
are
trademarks
of
Cypress
Microsystems,
Inc.
All
other
trademarks
are
the
property
of
their
respective
owners.
Digital Oscilloscopes
•
2 Channel Digital Oscilloscope
•
100 MSa/s
max single shot rate
•
32K samples per channel
•
Advanced Triggering
•
Only 9 oz and 6.3” x 3.75” x 1.25”
•
Small, Lightweight, and Portable
•
Parallel Port
interface to PC
•
Advanced Math options
•
FFT Spectrum Analyzer options
DSO-2102S
$525
DSO-2102M
$650
Each includes
Oscilloscope
,
Probes, Interface Cable, Power
Adapter, and software for
Win95/98, WinNT, Win2000
and DOS.
•
40 to 160 channels
•
up to 500 MSa/s
•
Variable Threshold
•
8 External Clocks
•
16 Level Triggering
•
up to 512K samples/ch
•
Optional Parallel Interface
•
Optional 100 MSa/s Pattern Generator
LA4240-32K (200MHz, 40CH)
$1350
LA4280-32K (200MHz, 80CH)
$2000
LA4540-128K (500MHz, 40CH)
$1900
LA4580-128K (500MHz, 80CH)
$2800
LA45160-128K (500MHz, 160CH)
$7000
Logic Analyzers
• 24 Channel Logic Analyzer
• 100MSa/S max sample rate
• Variable Threshold Voltage
• Large 128k Buffer
• Small, Lightweight and Portable
• Only 4 oz and 4.75” x 2.75” x 1”
• Parallel Port Interface to PC
• Trigger Out
• Windows 95/98 Software
LA2124-128K (100MSa/s, 24CH)
Clips, Wires, Interface Cable, AC
Adapter and Software
$800
All prices include Pods and Software
W
hen you’re planning a project, for either yourself or a client, cost
is undoubtedly a factor. Staying within your budget can mean the
difference between finishing and not finishing, or getting that next
contract and watching it go to someone else. That’s why it’s no sur-
prise that cost is a significant factor in the majority of the projects
we feature.
For instance, this month, we feature Stephen Manley’s application
for data acquisition (p. 10). Stephen wanted to design a way to col-
lect and display data for his embedded projects—in particular, a unit
to sample the sensors in his car. Mindful of his budget constraints, a
PC was out of the question. So, he asked himself, what has enough
processing power and the ability to display colorful, clear graphics?
Stephen considered that Palm devices support serial communica-
tion. A PDA offers portability, low-power consumption, and ample
memory—everything he was looking for. Most importantly, PDAs are
reasonably priced and easily accessible. For the same reasons,
Stephen chose an Atmel AVR to sample data and communication
with the Palm device. The end result is a small, low-power, effective
unit that won’t break the bank.
Cost was also a significant concern for Professor Terry
Fleischman and his students at Fox Valley Technical College in
Appleton, Wisconsin. Charged with building a system to monitor vehi-
cle speed, they had to stay within a strict budget. The project was
designed for the High Mileage Vehicle Challenge, which challenges
racers to get the highest mileage from their gasoline-powered vehi-
cles. As Terry explains in his article, their plan was to create a system
to acquire each vehicle’s speed, send the data to an embedded con-
troller on the vehicle, wirelessly transmit the data to a host computer,
and then display the result (p. 20). With a GPS unit, a Motorola HC11
microcontroller, and a MaxStream RF modem, Terry and his students
were able to complete the project within their budget.
In both of these projects, careful planning and creative problem-
solving helped to get the job done. Whether you work in embedded
systems development like Stephen or academia like Terry, the ability
to develop low-cost, high-quality solutions is essential.
4
Issue 159 October 2003
www.circuitcellar.com
CIRCUIT CELLAR
®
EDITORIAL DIRECTOR/FOUNDER
Steve Ciarcia
MANAGING EDITOR
Jennifer Huber
TECHNICAL EDITOR
C.J. Abate
WEST COAST EDITOR
Tom Cantrell
CONTRIBUTING EDITORS
Ingo Cyliax
Fred Eady
George Martin
George Novacek
Jeff Bachiochi
NEW PRODUCTS EDITOR
John Gorsky
PROJECT EDITORS
Steve Bedford
Ken Davidson
David Tweed
ADVERTISING
PUBLISHER
Dan Rodrigues
E-mail: dan@circuitcellar.com
ASSOCIATE PUBLISHER/DIRECTOR OF SALES
Sean Donnelly
Fax: (860) 871-0411
(860) 872-3064
E-mail: sean@circuitcellar.com
Cell phone: (860) 930-4326
ADVERTISING COORDINATOR
Valerie Luster
Fax: (860) 871-0411
(860) 875-2199
E-mail: val.luster@circuitcellar.com
ADVERTISING ASSISTANT
Deborah Lavoie
Fax: (860) 871-0411
(860) 875-2199
E-mail: debbie.lavoie@circuitcellar.com
CONTACTING CIRCUIT CELLAR
SUBSCRIPTIONS:
INFORMATION: www.circuitcellar.com or subscribe@circuitcellar.com
To Subscribe: (800) 269-6301, www.circuitcellar.com/subscribe.htm, or
subscribe@circuitcellar.com
PROBLEMS: subscribe@circuitcellar.com
GENERAL INFORMATION:
TELEPHONE: (860) 875-2199 Fax: (860) 871-0411
INTERNET: info@circuitcellar.com, editor@circuitcellar.com, or www.circuitcellar.com
EDITORIAL OFFICES: Editor, Circuit Cellar, 4 Park St., Vernon, CT 06066
NEW PRODUCTS: New Products, Circuit Cellar, 4 Park St., Vernon, CT 06066
newproducts@circuitcellar.com
AUTHOR CONTACT:
E-MAIL: Author addresses (when available) are included at the end of each article.
CIRCUIT CELLAR®, THE MAGAZINE FOR COMPUTER APPLICATIONS (ISSN 1528-0608) and Circuit Cellar Online are pub-
lished monthly by Circuit Cellar Incorporated, 4 Park Street, Suite 20, Vernon, CT 06066 (860) 875-2751. Periodical rates paid at
Vernon, CT and additional offices. One-year (12 issues) subscription rate USA and possessions $21.95, Canada/Mexico
$31.95, all other countries $49.95. Two-year (24 issues) subscription rate USA and possessions $39.95, Canada/Mexico
$55, all other countries $85. All subscription orders payable in U.S. funds only via VISA, MasterCard, international postal money
order, or check drawn on U.S. bank.
Direct subscription orders and subscription-related questions to Circuit Cellar Subscriptions, P.O. Box 5650, Hanover, NH
03755-5650 or call (800) 269-6301.
Postmaster: Send address changes to Circuit Cellar, Circulation Dept., P.O. Box 5650, Hanover, NH 03755-5650.
For information on authorized reprints of articles,
contact Jeannette Ciarcia (860) 875-2199 or e-mail jciarcia@circuitcellar.com.
Circuit Cellar® makes no warranties and assumes no responsibility or liability of any kind for errors in these programs or schematics or for the
consequences of any such errors. Furthermore, because of possible variation in the quality and condition of materials and workmanship of read-
er-assembled projects, Circuit Cellar® disclaims any responsibility for the safe and proper function of reader-assembled projects based upon or
from plans, descriptions, or information published by Circuit Cellar®.
The information provided by Circuit Cellar® is for educational purposes. Circuit Cellar® makes no claims or warrants that readers have a right to
build things based upon these ideas under patent or other relevant intellectual property law in their jurisdiction, or that readers have a right to
construct or operate any of the devices described herein under the relevant patent or other intellectual property law of the reader’s jurisdiction.
The reader assumes any risk of infringement liability for constructing or operating such devices.
Entire contents copyright © 2001 by Circuit Cellar Incorporated. All rights reserved. Circuit Cellar and Circuit Cellar INK are registered trademarks
of Circuit Cellar Inc. Reproduction of this publication in whole or in part without written consent from Circuit Cellar Inc. is prohibited.
CHIEF FINANCIAL OFFICER
Jeannette Ciarcia
CUSTOMER SERVICE
Elaine Johnston
ACCOUNTANT
Jeff Yanco
ART DIRECTOR
KC Prescott
GRAPHIC DESIGNER
Mary Turek
STAFF ENGINEER
John Gorsky
QUIZ COORDINATOR
David Tweed
Cover photograph Chris Rakoczy—Rakoczy Photography
PRINTED IN THE UNITED STATES
Pinching Pennies
jennifer.huber@circuitcellar.com
TASK MANAGER
6
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
October 2003: Data Acquisition
Speed and Location Data Acquisition
Embedded Networking with MicroMessaging
Driving LCDs with Microchip and Atmel Micros
Fred Eady
PRIORITY INTERRUPT
Intellectual Property
FEATURES
COLUMNS
DEPARTMENTS
Check out AVR today at www.atmel.com/ad/fastavr
Introducing the Atmel AVR
®
. An 8-bit MCU that
can help you beat the pants off your competition.
AVR is a RISC CPU running single cycle instructions.
With its rich, CISC-like instruction set and 32 working registers,
it has very high code density and searingly fast execution–up to
16 MIPS. That’s 12 times faster than conventional 8-bit micros.
We like to think of it as 16-bit performance at an 8-bit price.
With up to 128 Kbytes of programmable Flash and EEPROM,
AVR is not only up to 12 times faster than the MCU you’re using
now. It’s probably 12 times smarter, too.
And when you consider that it can help slash months off your
development schedule and save thousands of dollars in project
cost, it could make you look pretty smart, too.
AVR comes in a wide range of package and performance
options covering a huge number of consumer and industrial
applications. And it’s supported by some of the best development
tools in the business.
So get your project started right. Check out AVR today at
www.atmel.com/ad/fastavr. Then register to qualify for your free
evaluation kit and bumper sticker. And get ready to take on the world.
Our AVR microcontroller is
probably 12 times faster than
the one you’re using now.
(It’s also smarter.)
AVR 8-bit RISC Microcontrollers
© 2002 Atmel Corporation. Atmel and the Atmel logo are registered trademarks of Atmel Corporation.
8
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
Edited by John Gorsky
NEW PRODUCT NEWS
ANALOG PC/104 MODULE
The AIO-104+8 is a PC/104 module that offers analog
I/O. Designed using the Maxim MAX197 successive
approximation-type A/D chip, the AIO-104+8 provides
eight single-ended, 12-bit inputs. Also included are two
12-bit D/A output channels and 16 TTL digital I/O bits,
which can be individually programmed as input or output.
The AIO-104+8 is ideal for a variety of PC/104-based data
acquisition/control and test/measurement applications.
The A/D inputs are software selectable for 0- to 5-, 0- to
10-, ±5-, and ±10-V ranges, and they can be configured via
hardware for measuring 4- to 20-mA current loops. The
inputs feature 5-MHz bandwidth track/hold and a 100-kbps
throughput rate. The two 12-bit D/A channels are jumper
selectable for 4.095 or 2.048 V full scale. Software support
is provided for easy implementation using either Win32
library calls or a drop-in ActiveX control.
The AIO-104+8 requires only 5 V, and is available in
standard or extended (–40° to
85
°
C) temperature ranges. The
AIO-104+8 costs $299 in low-
volume quantities, and the card
is available from stock.
Sealevel Systems, Inc.
(864) 843-4343
www.sealevel.com
DUAL-CHANNEL TEMPERATURE SENSOR
The ADT7461 is an enhanced digital temperature sensor
that can monitor a wide temperature range. It automatical-
ly cancels temperature errors because of resistance in series
with the remote sensor. The default temperature measure-
ment range of 0° to 127°C can be configured to a remote-
sensor extended range of –64° to 191°C, which is used to
measure temperatures from –40° to 150°C. The device auto-
matically compensates for as much as 1 k
Ω
of series para-
sitic resistance between the sensor and recording circuits.
The ADT7461 cancels thermal measurement inaccura-
cies caused by resistance in series with the thermal diode
sensor by automatically switching current sources,
comparing the resulting output voltages, and calculat-
ing the corrected temperature. Additional on-chip signal
conditioning eliminates the effects of noise in the sen-
sor circuits. The remote sensor has 0.25°C resolution
and 1°C accuracy; the local
sensor has 1°C resolution
and 3°C accuracy.
The ADT7461 costs
$1.70 per unit in 1000-piece
quantities.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
9
What’s your EQ?
—
The answers are posted at
www.circuitcellar.com/eq.htm
You may contact the quizmasters at eq@circuitcellar.com
CIRCUIT CELLAR
—
Test Y
Your E
EQ
Problem 2
—What are the advantages of using
this circuit configuration for this application?
Problem 3
—To what extent does the nonlineari-
ty of the transistor’s B-E junction contribute to
the distortion of the signal at the collector?
Problem 4
—What are the other disadvantages
of this circuit?
Contributed by David Tweed
Edited by David Tweed
Problem 1
—The following circuit was recom-
mended as a preamp for a speaker being used as
a microphone in an intercom system.
What is the configuration of the first transistor
called?
5.6 k
Ω
2.2 k
Ω
+ –
100 µF
BC109C
6–12 VDC
+
–
2.2 M
Ω
220 µF
+
–
LS
+
–
220 µF
Output
8.2
Ω
BC109C
create a platform to provide a set of
digital gauges for my car (see Photo 1).
Because the gauges are digital, I want-
ed data-logging capability. Real-time
monitoring seemed useful too.
One seemingly simple problem
arose. I wanted the project both to
look good and to be easy to conceal to
prevent theft. The Palm device fit the
bill perfectly. You can use a Palm for
display, user input, and data storage,
and then remove it from the vehicle
for security purposes. You only need
to install the data logger once. The
Palm is also easily synced to a PC.
The sensor measurements in an auto-
mobile for instrumentation are well suit-
ed to this project; obviously, the sam-
pling rate is limited because of the slow
serial connection between the microcon-
troller and Palm. Most instruments only
need relatively slow updates—several
times per second is fine.
With this article as your guide, you
can build your own inexpensive data
acquisition and monitoring applica-
tions using Palm devices. As you fol-
low along, refer to the schemat-
ic in Figure 1.
SYSTEM ARCHITECTURE
As you may expect, analog-to-
digital conversion and I/O are
handled by the AVR, which
responds to a request for infor-
mation from the Palm through
the serial interface. The program
then selects the correct ADC
channel or port and reports the
state of the register back to the
Palm. The AVR then waits for
its next request, or it can be put
into a streaming mode whereby
10
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
M
any designers these days are
faced with the problem of gathering
and displaying information from their
projects. If you have the luxury of
using a PC, there are unlimited
options available to you, depending on
your budget. Prototyping and embed-
ded projects are a different matter: dis-
playing, recording, and processing user
input in an attractive format can repre-
sent a large percentage of your budget.
What if there were a cheaper alter-
native? Well, there is. The handheld
PDA market has seen tremendous
growth over the past few years, and
the prices of these once expensive
devices have dropped precipitously. A
quick search on the ’Net yields dozens
of used Palm devices in the $50 and
under category; on the low end, new
devices cost less than $100.
The Palm platform offers you an
attractive package for presenting your
application’s data and gathering user
input. The platform is already optimized
for low-power consumption, rugged con-
struction, a capable display that’s read-
able in sunlight and dim condi-
tions, significant amounts of
memory to store data, and porta-
bility between applications. The
SDK for Palm OS development
and a GNU-based toolchain are
widely available. All you need is
a way to make use of PDAs in
your embedded project.
Enter the old standby of embed-
ded projects everywhere, the ven-
erable RS-232C port. Palm plat-
forms all share the ability to
achieve serial communication,
from the extremely high-end
Tungsten platforms, to the earli-
Palm OS Data Acquisition
It’s never been so easy and inexpensive to build data-acquisition and data-monitoring appli-
cations. For instance, Stephen recently developed a set of digital gauges for his car, and all
it took was a Palm, an ATmega163, and a little forethought.
est U.S. Robotics PalmPilots. Palm has
been good about maintaining relatively
standard connectors across platforms, so,
in many cases, you can use the same
cable with different models. It may seem
like the newer models are all USB-based,
but don’t despair, every Palm supports a
serial connection. You’ll need a cable or
a serial sync cable from a Palm.
You’ll also need a way to sample data
and communicate it to the Palm unit.
An excellent choice is Atmel’s AVR plat-
form. Like the Palm, it is inexpensive
and widely available. In addition, there’s
a community of developers supporting it
via the Internet. Like Palm OS, a GNU-
based toolchain gives you full control of
the AVR via C programming language.
Atmel’s STK500 development platform is
inexpensive and well supported. Refer to
the sidebar to learn how to get started
with GNU. Now, let’s see how to tie all
of these pieces together to create some-
thing you can use for your own projects.
HOW IT ALL BEGAN
I started this project in an effort to
FEATURE ARTICLE
by Stephen Manley
Photo 1—
The Palm device allows for an attractive way to present informa-
tion and gather input, with a clear LCD and clean appearance.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
11
The Palm software is equally sim-
ple. A pull-down menu allows you to
select a channel, which can be queried
manually via a selection button or set
the state of the selected ADC channel
is sent automatically. This arrangement
works well because the AVR can be
placed far from the actual Palm. My cir-
cuit is based on the DS275 transceiver
chip that is not optimized for range;
substituting another serial-level con-
verter removes this limitation.
GETTING STARTED WITH GNU
The C compiler toolchain available for the Palm OS
and AVR platforms is based on GNU software from the
Free Software Foundation. You can read about the foun-
dation at www.gnu.org.
AVR Development
To get started with the AVR platform, you’ll need a
development kit. Atmel’s STK500 platform is widely
available and provides a great platform to start with.
The dual serial connectors allow you to reprogram the
chip without having to disconnect cables (a real time
saver). It also has a bank of eight micro switches and
LEDs in addition to breakout headers.
Next, you’ll need to download the current distribution
of the AVRGCC package. The project is maintained at
the AVRFreaks web site (www.avrfreaks.net), which is a
tremendous resource for access to sample projects, com-
munity forums, FAQs, reference material, and installa-
tion help. The current WinAVR build comes as a single-
file installer. Download and run the binary.
The program will run and install itself in C:\WinAVR
by default. It will make some adjustments to your envi-
ronment variables to ensure that the proper commands
are in your path. If you have any problems, this is the
first place to start looking.
The following instructions will help you verify that
you can compile programs without problems. In a com-
mand window, go to the C:\WinAVR\doc\examples\demo
directory. Type “set PATH” to verify your settings, and
you should see something like:
C:\WinAVR\bin;C:\WinAVR\utils\bin; ...
Type “make” in the command window to compile the pro-
gram and generate the hex format output file to program.
For an excellent walk through of all the details
involved in this process, refer to the avr-libc reference man-
ual that is provided with the WinAVR default installation.
You’ll find it in the C:\WinAVR\doc\avr-libc directory in
a PDF. The tutorial is located under “avr-libc Page
Documentation.” It takes you step-by-step through the
process of building for your specific microcontroller.
Note that the example in the documentation uses the
AT90S2313 microcontroller. If you use another micro, you
will need to change the MCU flag in the make file. If your
STK is connected as the manual indicates, you will not see
any output from the demo program. You must move the
LED header from its default port B location to port D.
Palm OS Software
No special hardware is required for the Palm other than
the software tools. Like AVRGCC, the environment is based
on the GNU compiler. The recommended installation for
the Palm environment requires you to install Cygwin,
which is a Unix emulation layer for Windows. Palm pro-
vides an excellent resource for getting started.
PRC-Tools
In order to develop applications for Palm OS, there are sev-
eral pieces you need to download. The first is the development
tools and environment, which are provided through the Cygwin
package and its installer. Follow the instructions for down-
loading and installing the Setup.exe package. Note that it will
run and download the components you select. You need to
add the SourceForge site and manually select the PRC-
Tools. I highly recommend reading the complete documen-
tation for this step before you start installation.
To be in the Cygwin environment, you need to run a shell
program that is different than the Microsoft command tool.
This defaults to Bash, and will appear under the Cygwin folder
in your Start menu. In order for your Palm OS program to com-
pile correctly, you must run the make program from this shell.
Palm SDK and Tools
You must download the SDK to get the API and libraries for
Palm OS. The SDK is available in the Tools and Downloads
section of the Palm web site.
You should download and install the full CodeWarrior
version of the SDK that contains examples and documenta-
tion not found in the Unix download. These examples are
instructive, but note that they won’t compile with the PRC-
tools package without modification.
An invaluable tool for Palm software development is the
Palm OS emulator (POSE). You need to download it separately
from the Palm OS developer tools site (www.palmos.com/
dev/tools/emulator). ROM images are available from Palm
through the developer program. You can also download the
ROM image from the device you intend to use.
Installing the full version will report an error if you have
not installed CodeWarrior for your Palm. Ignoring this error
will not cause any problems.
To compile programs, you need the Unix-style header files.
Palm lists this as the “Unsupported Palm OS SDK 5 for PRC-
Tools” option. Download the Tar archive. You can use WinZip
to extract the files; it will expand a directory called “sdk-5.”
You should place this in your PalmDev directory mentioned
in the Cygwin installation. This defaults to C:\PalmDev.
There are several PRC-Tools samples that you can download
from the SourceForge web site. To test your installation, load
the Cygwin bash shell, change to the directory you unzipped
them in, and then type “make.” If everything is installed
correctly, you should see the .prc executable being built.
12
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
parts box. The bandwidth provided by
the circuit is sufficient for any of the sig-
nals used in these examples. One prob-
lem with using a standard op-amp is that
it requires a dual-polarity supply. More
specialized single-supply candidates such
as a MAX4256 or LT1368/1369 will
work better in the field.
The ATmega163 has an eight-chan-
nel, 10-bit ADC and is set to use the 5-
V AREF analog reference volt-
age provided by the STK500.
This allows a resolution of
approximately 0.01 V. When
the voltage being monitored is
outside this range, it needs to
be scaled. The common tech-
nique for doing this is to use a
voltage divider with precision
resistors; however, this intro-
duces error from temperature
fluctuations. Scaling the volt-
age also decreases the effective
resolution. Each 0.01-V incre-
to automatically update the informa-
tion. In the same manner, the status
of the port C switches can be read,
and the state of the port B LEDs can
be controlled (see Figure 2).
INTERFACE WITH THE WORLD
Given that the purpose of this applica-
tion is the sampling of automotive sen-
sors, design work is needed to ensure that
the circuit does not interfere with the
vehicle’s ECU. (I could write an entire
article on the methods for sampling volt-
age and current from sensors.) For this
project, I wanted to have a high-input
resistance to minimally upset the circuit
being tested and a clean output for the
ADC. To achieve this, I used an op-amp
in the voltage-follower (unity gain buffer)
configuration. Using the configuration
depicted in Figure 1, the amplifier has
a voltage gain of unity (1 V/V).
For testing and prototyping the appli-
cations, I used a 741 op-amp from my
ment on the ADC represents a 0.02-V
change from the source (see Figure 1).
Other sources of sensor data exist,
such as pulse width or pulse trains,
which are better sampled by using an
optoisolator or other techniques such
as frequency-to-voltage conversion.
After the circuit is set to talk to the
Palm, you can interface to the ADC
channels on the AVR any way you like.
CABLES AND CONNECTIVITY
You have to add a cable for communi-
cation between the AVR and Palm. A
three-wire cable is all that’s required. A
convenient alternative is to use a 3.5-mm
stereo barrel connector and cable rather
than a standard serial connector. You
can easily get shielded headphone
cables with durable connectors. For pro-
totyping, the serial breakout on the
STK500 is fine. You will need a gender-
changing (male-male) null modem
adapter if you want to directly connect
the Palm cradle to the STK (see Photo 2).
Detailed signal descriptions and infor-
mation on the older 10- and 16-pin uni-
versal connector, which was used on
later devices, is available from Palm.
An invaluable tool for debugging seri-
al applications is a dedicated machine
for running a terminal program. Old
notebooks work well—even something
with DOS is fine. This lets you monitor
your application’s output without shuf-
fling windows and cables. It’s a great
help to know that if the application
stops working, the hardware is not sus-
pect. Minicom, which is an excellent
program, is available on Linux. Linux
has the added benefit of working well
even on older hardware; it adds the
nifty trick of being able to display the
serial connection via a remote terminal
Figure 1—
In the circuit for the test application, the AVR communicates through a RS-232C link. The DS275 is
used for level conversion. R1 and R2 are used as prescalers for voltage measurement. C1 and C2 are used to sta-
bilize the output from the Lt1369 buffer.
Sensor 0
Sensor 1
Sensor 2
Analog
buffer
Atmel
ATmega163
STK500
Digital I/O
(LED, switches)
Palm
device
Port B
Port C
RS–232C
ADC
(0–3)
Figure 2—
The Atmega163 acts as an intermediary for data I/O with
the Palm. Two-way communication with the Palm is used to gather
information from the input sources (switches and ADC) and control
digital output (LEDs).
14
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
session, so you can control several proj-
ects from your main development PC!
Configuring the Palm OS emulator
(POSE) in Windows with a serial connec-
tion is straightforward. By default, the
serial port is disabled; it can be assigned
to any COM port in your PC through
the settings menu. This will
allow you to test the software
without a Palm device (see
Photo 3a).
AVR PROGRAMMING
AVR programming and pro-
totyping was carried out using
the STK500 development
platform. The ATmega163 has
an internal oscillator and four
8-bit I/O ports, which make it
a good choice for a compact
design. You’ll find it easy to
recompile or port the C
source to another AVR-series
microcontroller.
The ATmega163 that came
with the kit has a minor config-
uration snafu from the factory.
The STK500 is set up by default
to use its on-board oscillator to
provide the system clock at 3.69
MHz. The ATmega163 is set to
use its own internal 1-MHz
oscillator, which will cause odd
behavior and problems when
you attempt to program it
through the serial ISP. To cor-
rect this, change the fuse bits to
use the external oscillator using
AVR Studio; this will resolve
the communications
issues that prevent pro-
gramming.
Setting up serial com-
munication on the AVR is
easy. In the
main() sec-
tion of your program, you
will need to configure the
UCSRB register with the
serial parameters. You
then need to set the UBRR
register to contain the
appropriate value based on
your clock speed for the
serial port data rate. The
ADCSR register must be
set to contain the sam-
pling frequency and oper-
ating mode of the ADC.
Finally, the ADC needs to be enabled.
After this is done, global interrupts must
be enabled with the
sei() function.
The AVR program waits for a request
on the serial port. When a request to
read an ADC channel is received, the
AVR adjusts the value of the ADMUX
register to the requested channel and
reads the value from the ADCL and
ADCH registers. This value is then
sent back over the serial port, and rep-
resents the 10-bit value stored in the
register, 0-1023. In a similar manner,
the program can read the value cur-
rently on port C or write bits to port B.
Photo 3 depicts the Palm interface
program demonstrating control of the
ATmega163 features via the serial
link. Listing 1 includes the routines to
initialize the ADC for interrupt-driven
operation and retrieving the sample.
One technique worth mentioning
uses the AVR to preprocess information.
For instance, the engine revolutions per
minute is indicated by a pulse train of
varying frequency on my vehicle. It
would be impossible to send the pulses
via serial for measurement, but the AVR
easily handles this task and relays the
result. This is one advantage of do-it-
yourself applications with the Palm.
When data bandwidth is a limitation,
the design can be modified.
PALM SERIAL PROGRAM-
MING
To get the serial communi-
cation working via the Palm
OS API, I chose the older serial
manager API, which is docu-
mented in the second section
of the Palm OS Companion.
The API has been deprecated
in favor of the new serial link
manager API; it is required to
work on older devices and
works well on newer ones too.
When you start your applica-
tion, you have to open the seri-
al library with the
SerOpen()
command. You will receive a
handle that’s used in all subse-
quent calls to the serial manag-
er API. After the port is opened,
it must be set to a compatible
communications mode to talk
to the AVR (9600 8N1 with
no handshaking). This is
accomplished by populating a
SerSetSettingsType structure
and then calling the
SerSetSettings() function.
After setup, the serial pro-
cessing is achieved in a serial
handler function that is set up
Photo 2—
The STK500 board facilitates quick checks of the software. A
gender changer and null adapter are required to communicate with the
cradle.
Photo 3a—
POSE emulates the hardware and firmware to allow for software
testing.
b
—
The test control application for the STK500 board demonstrates
sampling and digital I/O.
c
—
Storing ADC samples in the Palm for later pro-
cessing using the database API features.
d
—
The bar graph displays sample
voltages with respect to time, using Palm OS graphics functionality.
a)
b)
c)
d)
16
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
to wait for data while no events are
occurring in the system. When data is
received, the application updates the
corresponding user interface widgets.
Listing 2 allows you to initialize the
serial port with the serial manager API
and process data from the receive buffer.
Note that processing is done only when
no system events are pending.
This may seem complicated, but the
example projects can be used as a tem-
plate for you to easily build your own
Palm OS serial applications. For clarity,
the example program uses single-byte
processing. After each byte is received,
it is checked and manually loaded into
a command buffer. The Palm OS serial
manager can do this automatically.
There are better techniques for speed-
ing up the sampling (e.g., manipulating
bits directly rather than using ASCII
to represent decimal values, or using a
serial stream to send and receive data).
To help determine if your cables and
hardware are configured properly, a
small terminal program for the Palm is
handy. With a good connection, you can
echo characters back and forth between
the Palm and your PC. Several such
applications exist. My favorite is Márcio
Migueletto de Andrade’s pTelnet.
DATABASE LAND
As with any data logger, how you store
the information is important. The Palm
OS uses a different scheme than most
desktop operating systems you may be
familiar with. Palm OS has a database
file system—meaning that each file rep-
resents a record in a database on the sys-
tem—associated with creating the appli-
cation. This prevents orphan data from
clogging up your PDA, and helps manage
the limited memory on the device.
A database must be created for the
application to store information. This
is typically done at start-up. The
application checks to see if its data-
base exists, and if not, one is created.
After a valid database handle exists,
you can add your own records with the
sensor information. When a manual
query is made, the result is stored in the
database. You can easily fill up the mem-
ory, so set limits on the size or number
of samples that are stored at a given
time. Listing 3 is a technique for creating
a database if one doesn’t exist, obtaining
a handle to access the database, and stor-
ing a C structure in a record. Space for
the record must be allocated prior to its
insertion into the database.
The speed of this technique is limit-
ed. A better approach is to buffer the
data to SRAM on the microcontroller
before sending to the Palm device. If
you need to sample in real time with-
out adding more SRAM, store the
data in memory on the Palm before
writing to the database to minimize
overhead. Remember that the serial
link has limited bandwidth compared
Listing 2—
This code initializes the serial port with the Serial Manager API and processing data from the
receive buffer. Note that processing is achieved when no system events are pending.
//Set communications parameters and open port
SerSettingsType serialSettings;
Err err;
serialSettings.baudRate = 9600;
serialSettings.flags = 0;
serialSettings.ctsTimeout = 0;
serialSettings.flags = serSettingsFlagStopBits1 |
serSettingsFlagBitsPerChar8;
err = SerSetSettings(gSerialLib, &serialSettings);
//Send string to opened serial handle
SerSend(gSerialLib, "Start", 5, &err);
//Handle receiving a byte from the serial port without blocking
do
{
SerReceiveWait(gSerialLib, sizeof(data) - 1,
sysTicksPerSecond/50);
SerReceiveCheck(gSerialLib, &numberBytesPending);
if (numberBytesPending > 0)
{
SerReceive(gSerialLib, data, numberBytesPending, 0, &err);
//Insert handler here
SerReceiveFlush(gSerialLib, 1);
SerClearErr(gSerialLib);
}
}
while (!EvtSysEventAvail(false));
Listing 1—
Use these routines to initialize the ADC for interrupt-driven operation and retrieving the sample.
Interrupt handler for ADC conversion
*****************************************************************
SIGNAL(SIG_ADC)
{
adcDataL = ADCL;
adcDataH = ADCH;
adcData = 0;
adcData = adcData | adcDataH;
adcData = adcData << 8;
adcData = adcData | adcDataL;
}
void adc_init(void)
{
//Select maximum prescale divisor
ADCSR |= ( (1<<ADPS2)|(1<<ADPS1)|(1<<ADPS0) );
//Free running mode
ADCSR |= (1<<ADFR);
//Enable interrupt driven operation
ADCSR |= (1<<ADIE);
//Sample from ADC channel 0
ADMUX = 0;
//((0<<ADLAR));
//Enable the ADC */
ADCSR |= (1<<ADEN);
//Enable the ADC
//Start the first conversion
ADCSR |= (1<<ADSC);
}
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
17
to the sampling ability of the MCU
(see Photo 3c).
DISPLAYING RESULTS
Another great advantage of the Palm
OS platform is that the API allows for
some nifty graphics tricks—something
anyone who has played games on a
Palm can attest to. There’s no reason
why your application cannot make use
of this to emulate the behavior of ana-
log gauges, bar charts, or graphs of the
information that has been logged. These
features often require special libraries
or complicated programming to make
work on a raw dot-matrix display, but,
with a Palm, these are done for you.
Graphics are drawn through the
Window functions and API. The func-
tions are documented in the System
Management section of the reference
guide. To give you an idea of what you
can accomplish, I’ve provided a simple
bar graph that shows you the relative
condition of an input voltage over time
(see Photo 3d). You can include gauge
animations, alerts, and other features.
OTHER APPLICATIONS
You may download the code for
this project from the Circuit Cellar
ftp site. The object files work with an
ATmega163 device and a Palm IIIxe
running Palm OS 3.5. Changes may
be required for older and newer Palm
devices or a different series of AVR.
As you can see, the building blocks for
a sophisticated data acquisition applica-
tion using the Palm are not difficult
to understand. For $50 or less, you can
find an RS-232 touch-sensitive display
device with several megabytes of stor-
age, seven buttons, backlighting, and a
Listing 3—
With this code, I can write a structure containing sampled data to the application’s database. If
no database exists, one is created.
//Sample structure
typedef struct
{
int sampleValue;
char date[32];
}
sample_t;
//Create a new application database to store data
g_sampleDB = DmOpenDatabaseByTypeCreator (DB_TYPE, DB_APPID,
dmModeReadWrite);
if (!g_sampleDB)
{
err = DmCreateDatabase (0, DB_NAME, DB_APPID, DB_TYPE, false);
if (!err)
g_sampleDB = DmOpenDatabaseByTypeCreator (DB_TYPE, DB_APPID,
dmModeReadWrite);
}
//Store the sample_t stucture in a database record
if (g_sampleDB)
{
currentRecord = DmNumRecords(g_sampleDB) + 1;
rec_handle = DmNewRecord (g_sampleDB, ¤tRecord, sizeof(sam-
ple_t));
new_sample = MemHandleLock (rec_handle);
//Allocate space to store the record
tempSample = MemPtrNew (sizeof (sample_t));
MemSet (tempSample, sizeof (sample_t), 0);
tempSample->sampleValue = sample;
StrCopy(tempSample->date, txt);
//Copy into the database
DmWrite (new_sample, 0, tempSample, sizeof(sample_t));
MemHandleUnlock (rec_handle);
MemPtrFree (tempSample);
DmReleaseRecord (g_sampleDB, currentRecord, true);
}
SOURCES
ATmega163 Microcontroller
Atmel Corp.
www.atmel.com
LT1368/1369 Op-amp
Linear Technology Corp.
www.linear.com
DS275 Chip, MAX4256 op-amp
Maxim Integrated Products, Inc.
www.maxim-ic.com
pTelnet 0.6
M. Migueletto de Andrade
netpage.em.com.br/mmand/ptelnet.htm
Palm IIIxe
Palm, Inc.
www.palm.com
RESOURCES
P. Horowitz and W. Hill, The Art of
Electronics
, Cambridge University
Press, Cambridge, UK, 1989.
Maxim Integrated Products, Inc.,
“Choosing the Optimum Buffer/ADC
Combination for Your Application,”
APP 702, 2000.
PRC-Tools Project, prc-tools.source-
forge.net
N. Rhodes and J. MacKeehan, Palm
Programming: The Developer’s
Guide
, O’Reilly & Associates,
Sebastopol, CA, 1999.
WinAVR and AVR GCC Documen-
tation, winavr.sourceforge.net
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2003/159.
Stephen Manley is an embedded sys-
tems developer and amateur motor-
sports enthusiast. He received a
Bachelor’s degree in Electrical
Engineering from the University of New
Brunswick, Canada. You may reach
him at smanley@nyx.net.
sophisticated operating system. By
adding a microcontroller with serial
communication capability and an
A/D converter, any number of inter-
esting applications can be built. For
more information about this project,
take a look at my web site
(www.nyx.net/~smanley/palmadc).
I
cles, and it is my experience that they
do not necessarily provide the best
protection for telemetry equipment.
Secondly, the unit weighs about 8 lbs
and is fairly large.
CONTROLLER MODEL
After some deliberation and research,
we decided to use an ETrex GPS unit to
monitor speed. The ETrex unit provides
date, time, location, and north/south,
east/west, and up/down velocity in
meters per second in serial data format
that’s updated at a rate of one time per
second. Figure 1 shows the actual data
string from the GPS unit.
The data is sent to the HC11 serial
port, parsed, manipulated, and then
transmitted to the host via a wireless
modem. I used an HC11E0CFN2 embed-
ded controller with the port replacement
unit 68HC24FN. MaxStream develops
the RF modem (X09-009PKC2N).
Photo 1 shows the embedded con-
troller box. The RF modem is the
black device on the right. The embed-
ded controller is on the left side of the
box. Batteries are held on the box’s
cover, making this a completely self-
contained unit.
If you’re familiar with this particu-
lar controller model, then you know
there is only one serial port. (Note
that there is an SPI port, but nei-
ther the GPS unit nor the RF
modem support this.) And if you
have been paying attention, you
also know that the embedded
controller on the vehicle listens
to the GPS unit and sends data
20
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
F
or the past two years, Fox Valley
Technical College in Appleton,
Wisconsin has hosted the High
Mileage Vehicle (HMV) Challenge.
The objective is to obtain the highest
possible mileage from a gasoline-pow-
ered vehicle while traversing a prede-
termined course. The the majority of
these vehicles are bicycle-wheeled go-
carts designed and built by middle and
high school students. For safety rea-
sons, the drivers must keep their vehi-
cles under 25 mph.
As co-chair of the HMV event and
chairman of the Electronics and
Electrical Engineering Technology pro-
grams at the college, I offered the serv-
ices of my students to come up with a
solution to monitor the speed of the
vehicles. The project is now an integral
part of the curriculum for my embed-
ded controller and SCADA course.
STUDENTS’ CHALLENGE
Actually, I allowed my students to
choose whether or not they wanted to
take on the project. The deal went
something like this: accept the project,
or you will code in assembly language
for the remainder of the semester. After
talking about the project and speculat-
ing about what may come, the students
eagerly accepted the challenge.
In a nutshell, the initial plan
was to sense each vehicle’s speed,
feed this information to an embed-
ded controller on the vehicle,
manipulate the data as needed,
wirelessly transmit data to a host
computer in the event control
Speed and Location Data Acquisition
As co-chair of the High Mileage Vehicle Challenge, which is a contest amongst designers to
get the most mileage from a gas-powered vehicle, Terry was looking for ways to enhance the
contest. He and his engineering students volunteered to create a way to remotely monitor
the speed and location of multiple vehicles. The project turned out to be educational and fun,
but don’t just take their word for it, try it yourself.
area, and display vehicle information
to anyone interested in seeing it.
Monitoring the vehicles for speed viola-
tions is a key element we implement-
ed. Now, violators can be docked the
appropriate number of miles per gallon.
The real challenge was figuring out
how to monitor the speed of multiple
vehicles in a moderately priced man-
ner. Various solutions were enter-
tained, including encoders, tachome-
ters, and ground-speed radar. Problems
with encoders and tachometers
became apparent because there was no
specification for vehicle tire sizes, and
we did not want to have to deal with
a conversion factor built into an
embedded controller based on a partic-
ular wheel size.
Initial tests were performed using a
ground-speed radar device, which pro-
duced a pulse train with frequency
dependent on absolute ground speed.
Signal-conditioning this pulse train
and feeding it into a pulse accumula-
tor on a Motorola HC11 embedded
controller produced promising results.
There were a couple problems though.
Recall that we needed to monitor a
number of vehicles and this unit costs
approximately $500. Also, I haven’t
mentioned that middle school and
high school students build these vehi-
FEATURE ARTICLE
by Terry Fleischman
Figure 1—
Data is received from the GPS unit. Note that the start
character, @, is followed by 12 numbers representing the year, month,
day, hour, minutes, and seconds. The E, N, and D are each followed
by four zeros—this is the velocity vector information.
@030311082412N4416911W0882751g031+0024E0000N0000D0000
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
21
multiple vehicles in a timed manner.
Recall that new GPS data is available
each second, which means the host
PC has to listen for the new data (i.e.,
the synchronizing event), and then
request, receive, manipulate, and dis-
play data for multiple vehicles every
second.
The data rate for the serial commu-
nication is 9600 bps. Using this data
rate, each GPS data download to the
embedded controller takes approxi-
mately 58 ms. This is derived from a
bit rate of approximately 104 µs ×
10 bits per character × 55 characters.
After the GPS data is downloaded,
the host PC polls the vehicles, which
involves sending 4 bytes serially to
the host PC RF modem. The bytes
include a 2-byte header, vehicle
number, and a status byte indicating
what the host PC is asking the vehi-
cles’ embedded controllers to do.
Total time is approximately 4 ms,
but it occurs for each vehicle polled
by the host.
In addition, the RF modem takes
35 ms to transition from Standby to
Transmit mode. As each vehicle is
polled, the data must be transmitted
from the embedded controller to the
RF modem. Recall that a battery volt-
age indication byte, battery voltage,
vehicle number indicator, vehicle
number, end-of-speed indicator, and
trailer byte have been added to the
original GPS data string.
This data transfer takes
approximately 64 ms plus the
35-ms transition time from
Standby mode to Transmit
mode for the modem, yielding
99 ms to get data from the
to the wireless modem. This in itself
is not bad because the GPS unit only
transmits data, so you can utilize the
receive portion of the HC11 serial
port. The transmit side of the HC11
serial port is used to send data to the
RF modem, which, in turn, relays it to
a host PC in the event-control area.
A problem occurred because I need-
ed to poll multiple vehicles from the
host PC to get their data back in a
timely, coordinated manner. What this
means is that there are two devices—
the GPS unit and RF modem—con-
tending for the single HC11 serial
receive input. Using a four-input mul-
tiplexer chip and selecting whether
the controller receives data from the
GPS unit or the RF modem under pro-
gram control by the controller solves
the problem.
I mounted the multiplexer on an
expansion board that connects via a
header to the HC11 (see Photo 2).
Everything was synchronized to the
GPS data download. By default, each
one, including the host PCs, listened
for the GPS data download. You may
ask why I needed to poll multiple cars
from a single host PC. Twenty-four
cars were entered in our last HMV
Challenge. In order to complete the
challenge in a reasonable time
frame, there were seven or eight
vehicles on the track at one
time. The vehicles had the
opportunity to make five runs,
each of which consisted of
approximately 3 miles.
I wrote the original program for the
HC11 in assembly language, but now I
use C. This isn’t a major issue for my
students because they have C++ pro-
gramming experience.
Let’s go back to the polling of multi-
ple vehicles from the host PC in a
timely, coordinated manner. After the
GPS data transfer occurs, two things
happen. First, the embedded con-
trollers have to receive the GPS data
and process it. Second, the host PC
must wait for the entire GPS data
string to download before attempting
to contact the controller in the vehi-
cles. The delay must occur because
the embedded controller can only lis-
ten to one serial device at a time.
An error message will be sent from
the controller to the host if the
embedded controller does not receive
data from the GPS unit in a timely
manner. An error message is also sent
from the controller to the host, indi-
cating that no GPS data was received
for the last 5 s (an aid in troubleshoot-
ing disconnected or powered down
GPS units). The GPS error timing is
accomplished on the embedded con-
troller using real-time interrupts and
counter variables to keep track of
elapsed time. The controller’s battery
voltage is monitored using the embed-
ded controller’s A/D port.
The data and vehicle number are
sent back to the host along with the
GPS data. Figure 2 shows an actual
data string sent from a controller. By
comparing Figures 1 and 2, you’ll see
that the leading character has been
changed to avoid confusing other
controllers into thinking that data
from the controllers is data from the
GPS unit, thereby falsely resynchro-
nizing the PCs. Also note the addi-
tion of characters indicating battery
voltage, car number, and end-of-trans-
mission markers.
HOST AND PC TIMING
The host PC requests data from
Photo 2—
The mulitplexer is mounted on the expansion
board to the left of the embedded controller board. The
serial communication cable runs from the embedded
controller to the RF modem.
Photo 1—
The RF modem is the black device labeled
Xstream-PKG. The embedded controller is on the left
side of the box.
*030311082412N4416911W08827518g03+0024E0000N0000D0000
2
n
:)
Λ
ΙΙ
Figure 2—
The embedded controller sends data to the host PC. Note that
the start character has been changed and additional characters have
been appended to indicate the battery voltage, car number, end-of-speed
data indicator, and a data trailer.
22
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
and the actual reply back from the
controller. Specifications for the
modem state that the channel data
rate is 10 or 20 kbps (it varies with
the data rate); using the lower data
rate results in approximately 13.2 ms
of wireless transmit time required
for each controller-host transaction.
Approximately 272 ms elapses from
embedded controller to
the RF modem after a
host request. The data
is transmitted wire-
lessly and received at
the host. The host RF
modem then down-
loads it serially to the
host PC, which parses
the data and updates
the appropriate data
array locations before
moving on to the next
vehicle to be polled.
Note that an addition-
al 64 ms is required
for data to transfer
from the host modem
to the host PC.
Let’s recap what I’ve covered so far.
It takes approximately 260 ms for the
host to request and receive data from
a vehicle. There is additional time
that needs to be accounted for in
each host/vehicle data exchange: the
actual time it takes to transmit the
data wirelessly, which includes the
4-byte request for data from the host
the start of a GPS
data download to
when the host
receives downloaded
serial data. Each
additional request for
data from the vehicle
by the host will
require approximate-
ly 215 ms.
With this informa-
tion, you can calcu-
late the time require-
ment to exchange
data. You have a sin-
gle time requirement
of 58 ms for an ini-
tial GPS data down-
load plus 163 ms for
the controller/host data exchange.
Multiply this number by the number
of vehicles per host plus the 39 ms it
takes the host to request data. Next,
multiply the answer by the number of
vehicles plus 13.2 ms of actual wire-
less transmission time. Finally, multi-
ply your answer by the number of
vehicles. In practice, I can support
Photo 3—
Take a look at the front panel display on the host computer. The actual vehicle position is
displayed on a satellite picture of the track.
24
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
three vehicles per host.
35 ms Host modem wake-up time
4 ms Request from PC
35 ms Controller modem wake-up time
+ 64 ms Data transfer from controller
272 ms Total data transfer time per vehicle
58 ms Initial data download from GPS
+ (272 ms × 3) Transfer time for 3 vehicles
874 ms Total cycle time < 1 s
(Note that the “transfer time for
3 vehicles” refers to the data transfer.)
HOST PC PROGRAM
Data obtained by the host is in seri-
al format and needs to be parsed and
manipulated. I used the LabVIEW
graphical programming language to
program the host PC. Each program
consists of a front panel and diagram.
The latter contains the actual pro-
gramming, and the former contains
the user interface to include data dis-
plays, selector switches, and so on.
Photo 3 shows the front panel. As
you can see, I chose to monitor two
vehicles. Each vehicle is indicated as a
number. In addition, you can see that
the students decided to go the extra
mile and monitor vehicle position
(might as well, we were receiving this
data anyway), which can be useful for
locating stalled vehicles. General loca-
tion information can be relayed to
pick-up vehicles around the course.
Photo 3 also depicts the HMV
Challenge course, which is nearly
1 mile long. GPS location data is
parsed and scaled to fit the course pic-
ture. The controller battery voltage is
also displayed. Notice that there is a
current and maximum speed indicator
for each vehicle. The maximum speed
indicator is used to notify the event
coordinators of vehicles that are
exceeding the established maximum
speed limit.
Photo 4 shows a portion of the code
for this project; it’s my intention to
show you how graphical programming
with LabVIEW works. My electronics
students learn how to use LabVIEW in
a course called “LabVIEW and DAQ.”
They also learn how to use LabVIEW in
data-acquisition applications involving
analog and digital I/O. Although I did
not use these LabVIEW features in this
particular project, other projects in the
program do incorporate them, but that’s
beyond the scope of this article.
THE BIG PICTURE
Overall, this project involves gather-
ing date, time, location, and velocity
data from a GPS unit on an extremely
structured basis. The data is then
downloaded into an embedded con-
troller where it is manipulated and
stored. The embedded controller mon-
itors the on-board batteries via an A/D
port on the controller.
A host PC routinely polls the embed-
ded controllers and receives data from
them. The data is parsed and manipu-
lated to display the current speed and
location of a vehicle along with battery
voltage on the host PC. Radio fre-
quency modems are used to transmit
data between the host PC and the
vehicle controller.
MONITOR FUEL CONSUMPTION
Fuel consumption is determined by
subtracting the initial and final
weights of the standard 500-mg capac-
ity fuel tanks used on the vehicles.
These detachable tanks are similar in
size and shape to a plastic soda bottle.
Each contestant’s full fuel tank is
weighed before each run. After the
vehicles run the course, the fuel tanks
are detached and weighed again.
Knowing these weights and the course
length allows us to calculate each
vehicle’s fuel mileage.
The first time we ran the HMV
Challenge, the weighing and calcula-
tions were done manually, which
turned out to be a time-consuming
process. This year, we incorporated an
electronic scale in the weighing
process. The electronic scale can be
prompted to send weight data serially
to a connected device. We chose to
control the scale with a laptop using
the serial port. The control program
was written in LabVIEW. Photo 5
shows the front panel of the program.
After placing the fuel tank on the
scale, a PC operator presses the
Weight button. A control signal is
sent serially from the laptop to the
scale telling the scale to take a meas-
urement and send it back to the lap-
top. The data received by the laptop is
then converted into a number, dis-
played, and saved on a disk for further
manipulation. Photo 6 shows part of
the actual scale program.
HOW DID IT GO?
Having over 20 vehicles entered in
the HMV Challenge meant that we
had to manufacture plenty of teleme-
try boxes to hold the embedded con-
trollers, RF modems, and batteries.
Photo 4
—
Graphical programming involves using symbols to perform functions. Data flow is achieved by wiring one
symbol to the next.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
25
My students manufactured nine boxes,
and we had some leftover from last
year. Each box needed a GPS unit and
each host PC needed a GPS unit. In
total, I used 17 GPS units.
Prior to the actual contest, I set up a
mock version of the event and ran
tests. I had three host computers, each
of which was talking to two vehicles.
The test allowed me to verify that the
system was working. I used nine GPS
units in the test.
The morning of the HMV
Challenge, I took the additional eight
new GPS units out of their packages,
installed batteries, and turned them on
to see if they were working. Two of
my students, Ben Gardner and Jack
Kealy, helped set up and run the show.
We had problems with 60% of the
telemetry boxes. We were receiving
“No GPS Data” and “No GPS Data In
The Last 5 Seconds” error messages.
As the vehicles came off the track, we
checked the power and communica-
tion cable connections and found no
problems. We could still monitor the
vehicles’ maximum speed because the
data was stored in the GPS unit (a fea-
ture of the GPS unit). After each vehi-
cle returned from a run, we had to
manually go through the GPS menus
to check if they had exceeded the
maximum set speed.
The process obviously created more
work for the people responsible for
determining if vehicles had exceeded
the maximum speed. Ben, Jack, and I
were the ones with this responsibility,
so, needless to say, we were busier
than we had thought we would be. We
finished the competition knowing that
40% of the devices worked. There
wasn’t enough time during the event
to figure out what was wrong with the
rest of the units.
Ben and I were extremely interested
in finding out what went wrong. After
the semester had ended, Ben worked
as a research intern at the college. One
of his first projects was to determine
what had happened. To do so, he set
up the entire project, checked the
cables, and retested everything. He
witnessed some of the same errors.
After extensive analysis, Ben discov-
ered a communication problem
between the GPS units and con-
trollers. Here’s how it happened: I was
writing this article on a computer in
our lab when Ben, deeply involved
with the project, looked up from the
bench and asked if the GPS units
needed to have their data rate and
communication protocol selected. I
immediately stopped typing, picked up
my jaw off the floor, and started
laughing—not that this was funny,
because I realized who was responsible
for the nonworking 60%. In a not-too-
happy manner, I told Ben that yes,
indeed, each and every one of the
units I removed from their original
packing the morning of the challenge
should have been, but were not, set up
to the correct data rate and communi-
cation protocol. We proceeded to set
up the GPS units in the correct fash-
ion. With that, we completed the
retesting process and verified that all
of the telemetry units were function-
ing with without any problems.
Because I did not set up the new
units prior to the event, they sent data
26
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
using the wrong data rate in the
wrong format. The embedded con-
trollers either did not get the correct
starting character from the GPS units
or, if by chance the correct starting
character was occasionally received,
it wasn’t in a timely manner. These
two situations were the cause of the
error messages.
I’m still moving around with my tail
between my legs, but I’m looking for-
ward to next year’s HMV Challenge
because I’m now wiser and better pre-
pared. I think I will appoint someone
else to be responsible for setting up the
GPS units. Lest you think I am com-
pletely incompetent, I will tell you
that I did take a new GPS out of the
box two days before the challenge and
did think to set it up prior to using it. I
will work on my memory retention.
THE FUTURE?
Because there is two-way communi-
cation between the host PC and the
controller on each vehicle, I can imple-
ment other options. One idea is to
allow the host PC to be able to shut
off a vehicle’s engine, which isn’t an
option at this time but would be easy
to implement. I could place an engine
kill button for each vehicle on the PC’s
front panel display. Clicking the button
would set a flag for a particular vehicle.
When the vehicle controller receives
the request from the host, the request
would be checked to see what the host
is asking for. If the code for killing the
engine is received, one of the digital
output ports on the controller could
disable the engine’s ignition. Proper
isolation would be required to avoid
destroying the controller port.
My students chose not to incorporate
this option because the HMV Chal-
lenge’s specifications did not require the
vehicles to handle remote-control shut-
down. The vehicles were only required
to have on-board kill switches.
Because the contest is a high-
mileage vehicle challenge, I am also
interested in monitoring the flow of
fuel. Flow meters can output a pulse
count proportional to fuel flow. Recall
that the controller can support pulse
counting. The information could be
sent back to the host PC and dis-
played. I didn’t try this because of the
overhead required to install sensors on
each vehicle. Furthermore, competi-
tors come from all
over Wisconsin, and
I was not ready to
coordinate a
statewide fuel-flow
sensor implementa-
tion program.
Temperature, sus-
pension compres-
sion, and G-force in
turns could also be
monitored. The list
goes on. Why didn’t
I choose to monitor
some of these?
Mainly for the same
reason I didn’t
implement fuel flow monitoring.
Some of us at Fox Valley Technical
College are considering building our
own vehicle. We would not officially
compete in the HMV Challenge
because we host the event, but we
would use it as a demonstration vehi-
cle, giving students a chance to fully
develop a larger data-acquisition and
telemetry system.
Over the past two years, I’ve
received extremely positive feedback
from the students involved with
developing the data-acquisition and
telemetry aspect of the HMV
Challenge. It’s been a great way to
expose students to electronics and
data acquisition, as well as to prepare
them for future projects.
I
Photo 5
—
This is the front panel for the fuel-weighing
program. The program controls the digital scale.
Photo 6
—
I’ve included only a portion of the fuel-weighing program. Note the true
case statements.
SOURCES
ETrex GPS
Garmin
www.garmin.com
LabVIEW
National Instruments Corp.
(512) 683-0100
www.ni.com
Xstream-PKG Radio modem
MaxStream, Inc.
(866) 765-9885
www.maxstream.net
68HC11E0CFN2 Microcontroller
Motorola, Inc.
(847) 576-5000
www.motorola.com
Terry Fleischman is chairman of the
Electronics and Electrical Engineering
Technology programs at Fox Valley
Technical College in Wisconsin. You
may reach him at fleischm@fvtc.edu.
PROJECT FILES
To download the code and additional
files, go to ftp.circuitcellar.com
/pub/Circuit_Cellar/2003/159.
Author’s note: I would like to credit all
of the Fox Valley Technical College stu-
dents who worked so hard on this proj-
ect. Thanks to Rick Bales, Tim Foth,
Ben Gardner, Nicholas Gutt, Jack
Kealy, Adam Schertz, and Morey
Vanden Heuvel.
Autotrax
Autotrax
TM
Electronic Design Automation
Electronic Design Automation
Why wait? Download AutoTRAX EDA NOW!
Why wait? Download AutoTRAX EDA NOW!
Full Version
$95
Schematic Capture
SPICE Simulation
PCB Layout
Auto-Layout/Router
3D PCB Visualization
Database Support
Schematic Capture
SPICE Simulation
PCB Layout
Auto-Layout/Router
3D PCB Visualization
Database Support
Only
autodesk
®
authorised developer
No Limits!
2.0
It just gets
Better!
To find out more go to
www.autotraxEDA.com
To find out more go to
www.autotraxEDA.com
Drag and drop parts onto your schematic.
Connect them together.
Add virtual instruments such as scopes and function
generators.
Use the PCB design wizard to create your PCB.
Autolayout and autoroute the board.
View the board in 3D.
Output to Gerber and AutoCAD/Solidworks.
Drag and drop parts onto your schematic.
Connect them together.
Add virtual instruments such as scopes and function
generators.
Use the PCB design wizard to create your PCB.
Autolayout and autoroute the board.
View the board in 3D.
Output to Gerber and AutoCAD/Solidworks.
Over 25,000 new users in the last 12 months
Over 25,000 new users in the last 12 months
Full version
to full time-students and schools/colleges (no limits)
FREE
Full version
to full time-students and schools/colleges (no limits)
FREE
Free version available for small scale projects. (pin limited)
some way) would do the trick. So, the
clock has four two-color LEDs, each of
which generates three distinct hues,
arranged at the corners of a rectangle.
The sides of the rectangle are a mini-
mum of 2
″
long. A blue LED is posi-
tioned near two of the corners.
It is seemingly natural (for Westerners,
at least) to read in a left-to-right manner,
so I assigned the two leftmost sites as
the hours position, putting the minutes
on the right. I had to make a few other
decisions, too. For instance, I asked
myself, where should I put the most sig-
nificant sites, the top or bottom? Is it
better to have the third color site as the
least or most significant? The answer to
the former question came easily. I fig-
ured it was more likely that I would
remember it if the lesser significant digit
were physically lower rather than higher.
As for the question regarding the
third color site, I initially went with
the red/green/yellow as the most sig-
nificant and the red/green/yellow/blue
as the least. I later reversed my deci-
sion when I realized that four groups
of three meant that the most signifi-
cant digit changes every quarter hour,
which seemed easier to learn. You
wouldn’t say, “a third past the hour,”
but you do use quarter hours.
Optical merging was easy to achieve.
The selected blue LEDs have a narrow
beam pattern, so I positioned them to
aim into the backs of the red/green
LEDs. The blue light simply conducts
through the other LED’s body, as you
can see in Photo 1.
Note that you could delete the blue
28
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
’T
was a dark and blurry night.
What’s that noise, I wondered? What
time is it anyway? Where are my glass-
es? Can’t see the clock without my
glasses! That’s no surprise because
that’s been the case since I was about
10 years old. I was able to see my clock,
but it appeared only as a green-glowing
thing on the dresser. Hmm, why don’t I
design a clock that I can read anytime?
I pondered the idea for a while.
Because I was able to see the green color
of the clock, I was sure that I could dif-
ferentiate between different colored
lights. Two-color LEDs are good for at
least three hues, and blue LEDs are rea-
sonably priced now, so I started thinking
about a simple and inexpensive design.
INITIAL STEPS
First, I conducted a few experiments.
I found that I was able to distinguish
(with or without my glasses) between
two LEDs, even when I was looking
from the other side of my room.
Interestingly, I also discovered that I
could differentiate between lights that
emitted the same color and were sepa-
rated by no more than 2
″
. Thus, I decid-
ed to use 2
″
spacing as a minimum.
Next, I realized that I would need sev-
eral colors to use one point source for,
say, the hours; it would be worse to dis-
play all of the minutes on one LED. RGB
LED manufacturers claim that their
devices can make as many as 128 colors,
but try to distinguish between four or
five from a single red/green LED, and
then try doing it from memory. It isn’t
easy, especially at four o’clock in the
LED-Based Color Clock
Keith’s LED-based “color clock” may not look like a conventional clock, but it works just as
well. Read closely as he explains how he came to create an entirely new way of displaying
and reading the time of day.
morning. So, I decided that two symbols
would do the trick. One symbol is for
the hours and the other for the minutes.
Each symbol is comprised of two LED
sites—a most significant site and least
significant site. I figured that I would
use, at most, four colors per site, so four
at one site and three at the other made
the most sense because 3 × 4 = 12. That
coding resolved 5 min., but what more
would I need in the middle of the night?
I had a quaternary digit and ternary digit.
(I knew that a binary digit is a “bit,” and
I found out that a ternary digit is called a
“trit,” but I couldn’t find out if a qua-
ternary digit is called a “quit”!)
The aforementioned three-LED RGB
units are expensive and hard to find. I
thought that simulating a three-LED
unit with a red/green LED and a sepa-
rate blue one (optically merged in
FEATURE ARTICLE
by Keith Brown
Photo 1—
The LED arrangement for the two most sig-
nificant sites consists of a blue LED tucked under a
red/green one. The two-pin socket is epoxied to the
board. The blue LED was relocated from the bottom to
the top of the display.
Tell Time Anytime
lies. I have several development setups
and a lot of experience writing Abel
code. I figured that the required logic
would fit into something like an
ispLSI1024. Lattice, however, now
calls these parts by the euphemism
“mature,” so I decided to move on.
The most intriguing option was the
CY37256 development board, which
comes with Cypress’s $99 introductory
VHDL text and software. At the time, I
didn’t have too many other reasons to
play with the CY37256, so I thought the
color clock project would be the ticket.
I also considered a number of other
factors. For ease of coding the soft-
ware, VHDL proved to be the worst
option, because it didn’t seem appro-
priate for this type of task. I also con-
sidered the ease of breadboarding. The
cost of replication was also a concern.
This factor was mostly driven by chip
prices, because the LED and FET
prices would be the same in each case.
Finally, I factored in the attraction of
a potential Circuit Cellar article. I
thought fellow Circuit Cellar readers
would find both the ’HC908 and the
Cypress cases to be interesting choices.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
29
In the end, the MC68HC908 had the
best score. So, I dusted off my former
customer’s HC908GP32 board and got
the P&E software up and running.
Then, I assigned pins and started writ-
ing the code. The P&E assembler stops
at the first error. Sometimes it can be
annoying, but usually it isn’t too bad.
In fact, it forces bottom-up coding and
testing: write a little, see if it passes
the assembler, check if it works when
it does, and then go on to the next bit.
The code proved to be remarkably
easy to write. Several sections worked
the first time. I must have been getting
better at it! The only thing I had trouble
with was understanding the timer (TIM)
module’s quirks. This was due in large
part to the Motorola manuals being long
on fluff and short on useful information.
Because I had planned to target a small-
er MC68HC908 version, I restricted the
software to use just one of the timers.
TRY IT OUT
Figure 2 is a schematic of the display
circuit. I built the LEDs and FETs on a
socket strip and wired them to the exist-
ing MC68HC908GP32 board with a
handful of wires (see Photo 3).
After the breadboard had
displayed the time in this
new manner, I started train-
ing myself to read it. The
easy part was learning the
sequence: red, green, yellow,
and blue. The highest men-
tal hurdle was remembering
that zero equals 12.
Even though my wrist-
watch was set to a 24-h for-
mat, I still had to remember
that the first (red/red) symbol
is zero (hence noon or mid-
night) and not one. Because
LEDs altogether and use red/green/yel-
low/black(off) for the quaternary digits.
At first, I had placed the combined
sources at the bottom, but I soon felt
it would be too easy to obscure one or
both of the bottom digits (e.g., a paper-
back book left on the nightstand could
result in a misreading). After I changed
the quaternary digit to the most signifi-
cant (at the top), the problem disap-
peared. Because it seemed wrong not to
have each corner constantly illumi-
nated, I modified the already-built test
PCBs to move the blue LEDs to the top.
Figure 1a shows the symbols I used.
Each pair stands for either an hour, in
the two leftmost places, or for a 5-min.
interval at the rightmost sites. Photo 2
depicts example displays.
DECISION TIME
After the basic design was in place,
I had to figure out how to build the
clock. The task proved difficult because
I had thought of many ways to approach
the design. To make things easier, I cre-
ated a decision matrix (available on
the Circuit Cellar ftp site). I had four
device/tool set candidates: the Motorola
MC68HC11E1 and MC68HC908GP32,
the Lattice 1000 and 2000 families,
and the Cypress CY37256. I assumed
any one of them could do the job.
I had used both Motorola boards in
past projects for customers. The
MC68HC11E1 board is versatile, and I
could add a small daughterboard with
LEDs and drivers. The board has an
RTC, so timekeeping wouldn’t be a
problem. This board’s main advantage
is the Dunfield C compiler, which
would reduce the time it would take to
develop the software. The
MC68HC908GP32 is a flash
memory programmable
device that contains the
hardware needed to program
the chip and debug the code
using the chip’s built-in
monitor. The P&E assem-
bler would be the software
of choice. I could breadboard
on the board and develop for
a smaller ’908, like one of
the 68HC908JK or JL series.
Usually, my weapon of
choice comes from the
Lattice 1000 and 2000 fami-
Hours
Minutes
12
1
2
3
4
5
6
7
8
9
10
11
:00
:05
:10
:15
:20
:25
:30
:35
:40
:45
:50
:55
12
1
2
3
4
5
6
7
8
9
10
11
Hours
Minutes
Figure 1a—
Take a look at my time codes. Note that there are four groups of three.
Each group is defined with a unique color at the top position.
b—
Here are the same
codes shown in a more mnemonic manner. They are mapped on an analog clock
face. Simply multiply by five for the minutes.
Photo 2a—
You’ll see this display when the circuit comes out of power-up reset. The all-red combination indicates
either noon or midnight. I intentionally took the photo with my camera out of focus to simulate my unaided vision.
b—
11:55, what do you think about the blue LEDs? The orange is the equal combination of the orange, which looks
red to me, and green LED chips in the same device.
c—
2:05, yet another example of the 144 total display codes
produced by the clock.
a)
b)
c)
a)
b)
30
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
clock.) Figure 1b shows this as a differ-
ent way of decoding.
I wasn’t too happy with the first
red/green LEDs I tried. The Panasonic
LN11WP23 didn’t merge the colors well,
even though its epoxy is the diffused
white type. And, the yellow looked too
much like the green. In fact, you can see
the green and red colors as separate
spots, with the green spot being bigger.
I found that the LN11WP38—a
green/orange combination—did a better
the meaning of all of the other symbols
tended, at first, to be mentally tied to
the sequence starting at red/red, this
was a source of error. I soon learned,
however, that all greens are 4:20, and
all yellows are 8:40. The blue/yellow
pair is the numerically last symbol.
When both symbols are blue/yellow it’s
11:55. These gave me more starting
points to work from. At times, I found
myself converting my watch-indicated
time to color time. This probably
helped me learn the new system.
Another mental technique is to use
the four quaternary colors to map to the
analog clock’s big and little hand posi-
tions. Doing so helped me realize that,
for example, if the most significant qua-
ternary digit is green, it’s the same as
having the little hand in the second
quarter of the dial. After I learned this,
it was easy to see in which third of that
quarter the hand is by looking at the
ternary digit’s color. (I suppose this
method won’t help those of the younger
generation who can’t read an analog
job even though the orange looks red, and
the yellow is a nice orange. The three
colors were much more distinguishable
with this device. The blue LEDs are also
Panasonic parts (part no. LNG901CFB).
READY, SET, GO
I don’t know about you, but I’m tired
of digital clocks that only allow you to
set them by pushing a button to
increase the time. Sometimes you have
a choice of speeds; other times you can
select whether you want to count up
or down. I wanted it all. Thus, I have
a Run/Set switch, an Up/Down switch,
and Fast and Slow push buttons. Each of
the switch inputs is wired to one of the
processor’s I/O port pins. If the Run/Set
switch is in the set position and neither
push button is pressed, the time is held.
I also decided to reuse one of the
push buttons, in conjunction with the
Up/Down switch, to adjust the relative
red/green intensity in Run mode. The
code to handle the switches is part of
the timer ISR. At each 50-ms timer
tick, read the switches and compare
their current state to two previous sam-
ples (see Listing 1). The AND of the
three samples is taken as the current
switch value; it debounces the switches
sufficiently. One annoyance is that it
can take up to 5 min. to set because the
clock’s resolution is only 5 min.!
LIGHT IN, LIGHT OUT
I wanted the ability to control, prefer-
ably automatically, the brightness of the
LEDs by tracking the ambient light level.
The PWM function of the MC68HC908’s
built-in timer, tied by software to one
of the ADC inputs, proved to be able
to handle this admirably.
The analog signal representing the
Figure 2—
Pull-ups are not needed on the minutes LED drivers because the processor provides them on the port.
They are considered optional on the hours and PWM LED drivers, because the port pins are quickly set as outputs
after power-on reset.
Listing 1—
Here’s a sweet and simple switch debounce. Because all of the switches are read into the
same port, they can be debounced together.
;** 2 ** Debounce switch inputs and copy to flags variable
LDA OLDEST
AND LAST
AND SW_PORT
STA FLAGS
;Update run/set, slow, fast, and up/down flags
;Rotate new port A into last, and last into oldest
LDA LAST
STA OLDEST
LDA SW_PORT
STA LAST
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
31
ambient light level is derived from a
light-dependent resistor. The LDR came
from the junk bin, and it doesn’t have a
part number on it. Its resistance varies
from a low (illuminated) of 100
Ω
to a
high in the megaohm range. I was able
to obtain the full range of codes—00
(the circuit under a box with the lights
off) to FF (a bright desk light right on
the sensor)—from this simple circuit.
Because the MC68HC908 family
devices used for the final circuit have
two PWM outputs, I decided to con-
trol the red LEDs separately from the
blue and green ones. This gives me
the ability to control the red-green
brightness ratio and hence the quality
of yellow. This has since proved to be
unnecessary. One control is enough.
The essentials of the PWM code are
shown in Listings 2 and 3. The first part
is in the start-up code, which sets up the
various registers. I added a note about the
importance of writing to
T1CHOH before
writing to
T1CHOL because this fact isn’t
clear in the Motorola documents.
Listing 3 is one of the two PWM
interrupt service routines. All that
happens here is that the current ambi-
ent light measurement is added to a
base brightness level, which you can
adjust and store in the PWM compare
registers. To avoid a full 16-bit calcula-
tion, I took advantage of the fact that
the maximum value occupies 9 bits
and manipulated the LSB of the higher
byte based on the carry bit. The largest
possible sum (80
16
+ FF
16
= 383
10
) is
one more than the maximum value
that can be used by the TIM to deter-
mine the timer tick, so a correction is
applied for this case.
Listing 2—
The constants,
TIMER_PRESCALE
and
TIMER_MODULUS
, are defined elsewhere as 5 and
383, respectively.
*Set up timer for 0.001-s tick, and two PWM outputs:
MOV #$30,T1SC ;Disable and reset timer
LDA #$5E
;Enable int, MS = 01 (OC/PWM), ELS = 11 (Set->L pulses), TOV
STA T1SC0
STA T1SC1
CLR T1CH0H
;NB: write order has to be H then L for this regular pair
LDA #50t
STA T1CH0L
CLR T1CH1H
STA T1CH1L
LDA #TIMER_PRESCALE
ORA #$60
STA T1SC
;Set prescaler and enable overflow interrupt
LDHX #TIMER_MODULUS
STHX T1MODH
BCLR 5,T1SC ;Start timer
32
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
ON TO THE PCB
After I had the breadboard working,
it was time to work on a PCB. As you
can see in Figure 3, I designed for the
28-pin MC68HC908JL3, which has
enough I/O ports and plenty of code
space to do the job. The board includes
the display. Note that the LEDs are
soldered on one side and the rest of the
components are on the other.
To keep the board size and cost down,
I relegated the RS-232 and monitor entry
circuitry to an external program/debug
pod. I only needed it for development,
so I hand-wired it on perf board, which
attaches to the back of the main board
via JP5. When it is connected, the PB0
line is connected to an RS-232 transceiv-
er, and the *IRQ line can be connected
to an 8-V super-voltage to initialize
Monitor mode. The super-voltage is
unnecessary if the processor is blank; it
is only needed when the device’s pro-
gram is being changed. I used an LM317
from the junk bin to derive this voltage
from the raw wall wart input, which is
brought out to the pod via JP5-1. Figure 4
is the schematic for the pod. Photo 4
shows it connected to a clock.
Note that you have the option of
using either an oscillator module (half-
size case) or the classic parallel-mode
crystal oscillator circuit from discrete
parts. The former was for the first
design. I wanted to be sure that the
clock was running. It turned out that
the first time I soldered the crystal cir-
cuit it worked, so I could have omitted
that option. There must be a corollary
to Murphy’s Law here—something like,
“if you put in an option you won’t
need it, if you don’t, you will.”
MDF AND MAHOGANY
I built two versions of the clock (see
Photos 5a and 5b). Aside from the PCB,
the common element is a 0.75
″
thick
piece of medium-density fiberboard
(MDF), which has carefully profiled holes
drilled in it. Each hole has three diame-
ters. Starting from the outside, the
largest is 0.5
″
for accepting a translucent
plastic plug. (Note that the depth is
equal to the plug’s thickness, 0.125
″
). An
LED body-diameter size of about 5 mm
and an LED flange clearing size of 0.25
″
allow the LED to be inserted in the MDF.
I used a countersink bit under the
plug’s position to provide a better view-
ing angle from the front. You can down-
load an illustration of the hole’s profile
from the Circuit Cellar ftp site. The first
case used a scrap of pine for the sides,
but the second used a mahogany frame.
CLOCKS EVERYWHERE
During the development cycle, I decid-
ed that I needed a version of the clock to
run on Windows. I dragged out an old lap-
top that had the only working Windows
C compiler around and wrote the code.
Not surprisingly, writing this code was
harder than writing the embedded code!
The result can be downloaded from
the Circuit Cellar ftp site.
After writing the code, I became
increasingly ambitious. Although I
had never written in Java, I produced
a Java applet. You can see it at
www.island.net/~kdbrown.
ADDITIONAL FEATURES
The last time we experienced day-
light saving time, I had to change
dozens of clocks here and at work. I
didn’t want to add another clock to the
list. I thought a daily pulse at midnight
Photo 3—
The initial breadboard version is displaying
9:55. The processor is not shown. Initially, the display
was wired to a board with an MC68HC908GP32 chip
on it, but I eventually plugged an MC68HC908JL3 into
the breadboard strip.
Photo 4—
The flash memory programming pod attaches
to the back of the first prototype. The detachable pod
allows firmware updates without requiring that the parts
needed to handle the RS-232 interface to be on the PCB.
Listing 3—
A PWM service routine controls the brightness of the green and blue LEDs. I’ve made several
changes to this section to provide better correspondence between ambient illumination and display bright-
ness. Having the ability to control the red separately from the blue/green does not seem important.
T1CH0int
;Red LED intensity control
PSHH
LDA T1SC0
;Read status/ctl
BCLR 7,T1SC0
;Clear flag bit
LDA LL_Rmult
;0 to 4 is range
ASLA
ASLA
ASLA
ASLA
ASLA
;00 to 80 is range now
STA TEMP1
LDA AMB_LIGHT
ADD TEMP1
BCC T1_0_01
MOV #1,T1CH0H
;carry in to 9th bit
CMP #$7F
BNE T1_0_02
DECA
;1 7F -> 1 7E as maximum (382)
BRA T1_0_02
T1_0_01 CLR T1CH0H
T1_0_02 STA T1CH0L
PULH
RTI
We’ve expanded Motorola’s family of 8-bit MCUs with new
additions that operate down to 1.8 V – without sacrificing
performance one bit. Taking advantage of multiple power
management modes, the new HCS08 MCUs are designed to
get the most out of your battery. You’ll find these and other
Motorola products in millions of places throughout the
globe. And wherever you find us, you’ll also find innovation.
Our low-cost HCS08 Demonstration Board has the tools
and information you need to put that powerful combination
to work for you today.
Learn more at motorola.com/mcu
motorola.com/mcu
HCSO8 Extends Battery Life
MC9S08GB & GT Family Key Features
Demonstration Kit
MOTOROLA and the Stylized M Logo are registered in the U.S. Patent and Trademark Office. All other product or service names are the property of their respective
owners. © Motorola, Inc. 2003. This product incorporates SuperFlash
®
technology licensed from SST.
Your Design
+
HCSO8
+
Motorola Analog Products
+
Motorola Sensor Products
=
$ Time to profit
•
High-performance 8-bit HCS08 CPU core (as fast
as 50ns minimum instruction cycle at 20 MHz bus)
•
Multiple power management modes:
20nA power down mode
Auto wake-up timer mode
• Innovative on-chip trigger and trace debug interface
• Integrated third-generation .25 micron Flash memory
• Extensive serial communication with 2 SCIs,
1 SPI, and 1 I
2
C
• 10-bit analog-to-digital converter down to 1.8 V
• Up to 8 programmable timer channels with
center- or edge-aligned PWM
• MC9S08GB60 demonstration board:
Battery-operated with dual RS232 serial
ports, switches, LEDs, small prototype area,
and demonstration code
• Modify demo code or develop new code,
program and debug using free CodeWarrior
®
Development Suite including Processor Expert
TM
auto-code generator
MOTOLONGEVITY
Now an 8-bit MCU that’s big on performance, long on batte
mance, long on battery life.
MOTOLONGEVITY
Now an 8-bit MCU that’s big on performance, long on battery life.
34
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
would ensure accuracy and take care
of the daylight saving time changes.
The pulse originates on my main PC
because it is synchronized to UTC via
the ’Net. To arrange for this, I wired
one of the push buttons with a diode.
When the Run/Set switch is on Run,
pushing it cannot pull the correspon-
ding port line low. Instead, an external
input (through an open-collector/open-
drain device) is wired to do that. This
allows a sync to 0:00 function.
I wrote the code and tested it, how-
ever, the function awaits the distribu-
tion of the midnight pulse throughout
the building. The wiring showing the
diode is depicted in Figure 3.
I included a separate diode-isolated DC
power input, which connects to a 9-V
battery. A battery won’t power up the
LEDs for long, so I added a means of
measuring the main DC power input.
The code turns off the LEDs if the main
input drops below a threshold value.
Also, you can put the processor to sleep.
It will wake up for the timer tick to
update the time variables and little else.
Because Canadians predominantly
use the Celsius scale and the display
can present 00 through 99, I added the
ability to read and display tempera-
tures. The only obstacle to showing the
normal outdoor temperature range is
the sign. Flashing the display at some
distinctive rate to indicate freezing
temperatures is the solution I adopted.
(This is a case in which one of my old
electronics professors would have said,
“If you can’t fix it, feature it.”)
To implement temperature readings, I
needed two additional port lines. One
senses a Time/Temperature switch, and
the other communicates on a Dallas
1-wire bus with a DS1820 digital ther-
mometer. Conversion to Fahrenheit
is possible, but don’t try to show
Phoenix’s August air temperatures!
YOUR TIME HAS COME
In hindsight, I was right to use a pro-
Photo 5a—
Of the two different forms of packaging, the desk version is much cruder because I built it first.
b—
You
can mount this color clock on a wall in your home or office.
b)
a)
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
35
cessor rather than a CPLD. I suspect that
if I had added a row to capture versatili-
ty in the original decision matrix, the
HC908 family would have had a bigger
victory. I did not anticipate needing any
ADC or PWM functions during the initial
design phase, but they sure were useful.
I don’t think that I’m going to cause
a worldwide revolution in the way in
which time is displayed, but my color
clock does help people with poor
vision. Another unexpected advantage
is that it only resolves 5 min. Some
people may find this is desirable, for
PROJECT FILES
To download the code and Windows
file, go to ftp.circuitcellar.com/
pub/Circuit_Cellar/2003/159.
SOURCES
DS1820 1-Wire digital thermometer,
one-wire bus
Dallas Semiconductor Corp.
www.dalsemi.com
MC68HC908JL3 Microcontroller
Motorola, Inc.
www.motorola.com
LN11WP38 and LNG901CFBW
LEDS
Panasonic
www.panasonic.com/industrial/semi
Keith Brown, P.E., lives on Vancouver
Island in British Columbia. He has
been operating PLD Designs, consult-
ing in the selection of PLDs, and
designing circuit boards for customers
(with and without PLDs) since leaving
Spar Aerospace in 1992. You may
reach him at kdbrown@island.net.
RESOURCES
Software manuals, P&E Microcom-
puter Systems, Inc. www.pemicro.
com/ics08/index.html.
Motorola, Inc., “MC68HC908JK1,
MC68HRC908JK1, MC68HC908JK3,
MC68HRC908JK3, MC68HC908JL3,
MC68HRC908L3: HCMOS Micro-
controller Unit,” MC68HC908JL3/H,
rev. 1.0, 1999.
———, TIM08: Timer Interface
Module Reference Manual
,
TIM08RM/AD, rev. 1.0, 1996.
Figure 4—
The processor’s built-in monitor/programming routines use port bit PB0 to send and receive RS-232-timed
signals. When the board is plugged into the processor/display board, JP1–6 and JP1–8 of the pod are connected.
Figure 3—
The off-board switches are shown at the top of the schematic. The power input on the lower left is sim-
ple. Note the ability of the processor to measure the voltage produced by the wall wart.
example my wife, who is not a fan of
technology for its own sake. The low
resolution caused me to suggest the
name “ish clock”—as in, “lets go to
the party at seven-ish”—but my wife
doesn’t seem to like that one.
I hope you’ll give this project a try. At
the very least, the unique clock is a great
conversation piece. You can challenge
your friends to explain how you can tell
the time without looking at a regular
clock. It’s also a great way to keep
your “mental muscles” exercised.
I
LAYER 2 DRIVER INTERFACE
What is special about the Micro-
Messaging Layer 2 driver interface is
that all functions and parameters are
carefully selected to be usable and inter-
changeable with most serial buses, espe-
cially with UARTs/RS-232/485, I
2
C, SPI,
LIN, and CAN. The communication
mode supported upwards is a “push”
and “poll” model, with the driver being
responsible for implementing a minimal
receive and transmit queue. Many CAN
interfaces have such queues in hard-
ware; however, when using other tech-
nologies, a software implementation
may be required. The lengths of the
queues are not specified and depend on
the application requirements.
In order to be compatible with the
message-oriented communication
technologies LIN and CAN, a single
MicroMessaging message consists of an
identifier, a data length counter, and
data bytes. Because both LIN and CAN
36
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
W
hen it comes to embedded net-
working, it is common practice to use
an RS-485- or I
2
C-based network to
quickly define a few messages to
exchange data. This approach is suffi-
cient for an embedded system that uses
a few microcontrollers, and it’s fairly
fixed: it always uses the same nodes
with the same software and messages.
However, as soon as the system grows
or needs added flexibility and configura-
bility, a standardized network solution
becomes more desirable. Using standard
network protocols allows you to use
development tools (e.g., network moni-
tors, analyzers, simulators, and loggers)
and to possibly integrate off-the-shelf
components in the network.
As a consultant and ESAcademy tutor
with a lot of CAN and CANopen experi-
ence, I usually recommend switching to
CANopen, one of the only embedded-
networking standards around. To help
newcomers with CANopen, ESAcademy
came up with MicroCANopen, which
is a minimal CANopen implementa-
tion that’s suitable for lower-perform-
ance microcontrollers.
Although “Use CANopen!” is still a
valid recommendation for many appli-
cations, it may not be feasible for an
upgrade or migration involving exist-
ing systems based on non-CAN net-
works. So, something else is needed
for an easy migration to a standard, or,
even better, to allow existing network
technologies like RS-485 and I
2
C to
merge with CANopen.
The idea of merging a simple serial
bus into a CAN-based system is not
exactly a new one. A similar approach
was taken by the automotive industry
Embedded Networking with MicroMessaging
Mixing technologies can get messy, so if you’re interested in providing a common network
protocol for applications incorporating different networks, MicroMessaging is the solution for
you. Allow Olaf to walk you through the MicroMessaging basics, and you’ll surely find it eas-
ier to develop your next embedded-networking project.
with the local interconnect network
(LIN). LIN is a simple network protocol
that works on almost any UART. With
the number of electronic nodes in a car
continuously rising, the idea was to
introduce several LIN subnetworks and
use the CAN bus as a backbone that
interconnects everything. A typical
example would be to have a LIN sub-
network in each of a car’s seats (con-
necting all the switches and motors)
and have one microcontroller in a seat
act as a gateway between the local LIN
subnetwork and the CAN bus.
INTRO TO MicroMessaging
To pursue the idea of building a bridge
between any serial bus and CANopen,
the tutors of ESAcademy contacted some
industry and research partners and start-
ed the MicroMessaging Initiative. The
goal was to standardize a messaging sys-
tem for serial buses including UARTs,
I
2
C, and LIN that offers enough compati-
bility to allow for the easy mix-
ing and migrating of these tech-
nologies while still offering com-
mon software interfaces.
To reach the goal, two soft-
ware interfaces are standardized
in MicroMessaging (see Figure 1).
The Layer 2 driver interface
offers the same software func-
tions to transmit and receive a
message on all the different
hardware platforms that are sup-
ported. The Layer 7 application-
programming interface provides
a set of application functions
that directly allow the sharing
of process data among the dif-
ferent network nodes.
FEATURE ARTICLE
by Olaf Pfeiffer
Figure 1—
Several hardware and software layers are involved in
a MicroMessaging implementation. The MicroMessaging standard
specifies the software interfaces to the hardware driver level
(Layer 2) and to the MicroMessaging protocol stack (Layer 7).
Generic I/O / device profile
modules or applications
End-user specific
applications
MicroMessaging Layer 7 (API)
MicroMessaging protocol stack
(Micro)CANopen-compatible
MicroMessaging Layer 2 (driver interface)
Driver
Driver
Driver
Driver
Driver
UART/
RS-
xxx
I
2
C
CAN
LIN
Other
buses
Standardized software interfaces
Software
Hardware
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
37
this message to control the operation
state of the nodes (e.g., start or stop).
The content of the message is compli-
ant to the network management (NMT)
master message in CANopen (CiA
Draft Standard 301, or CiA DS301).
Using emergencies is optional. If a
node implements the support of emer-
gency messages, the message ID it may
use for the emergency message is its
own node ID. The message IDs used by
the 31 nodes are 01h through 1Fh. The
contents of an emergency must be com-
pliant with CANopen (CiA DS301).
Nodes only need to be able to receive
and act upon the poll message if the
physical network used does not sup-
port multimaster access. Shortly, I’ll
describe how the poll message is used.
The message identifiers used for
process data messages are configurable
to allow a receive data channel to
directly listen to the transmit data
channel of another node. The message
IDs used for data channels must be in
the range of 21h to 9Fh.
Service data channels are used for
access to service and configuration
data, such as the identification record
or the heartbeat time. These channels
are used in the same way as the serv-
ice data objects (SDO) channels used
allow for a maximum of 8 data bytes per
message, this maximum message length
is adapted for MicroMessaging, too.
The length of the message identifier
varies greatly from 6 bits in LIN to
11 bits in CAN, which even allows for
an extended 29-bit ID. In order not to
loose too much flexibility, Micro-
Messaging specifies to use message
identifiers with either 6 or 8 bits. Some
functionality is lost when using a 6-bit
oriented identifier. Alternatively, 11
bits can be used when full CANopen
compatibility is required.
The minimal services required at
the Layer 2 level are functions to ini-
tialize the communication interface
including setting receive filters (only
receive messages with a certain ID),
some timer functions, and functions
reading from the receive queue and
writing to the transmit queue.
LAYER 7 API
Some networking standards, including
CANopen, do not provide an API, which
hinders portability between different
implementations. This also results in
additional software overhead if different
implementations are merged into or
exchanged with other network systems.
The MicroMessaging Layer 7 API pro-
vides a simple standardized interface
focusing on the process data exchanged.
MicroMessaging uses process data
channels for transporting process data.
On Layer 2, a data channel corresponds
to a single message. As a result, a single
data channel can have up to 8 bytes.
Each individual node can have multiple
process data channels.
An application may place multiple
variables into each process data chan-
nel. There are only three limiting
rules: a single variable must consist of
1, 2, 3, or 4 bytes; the total number of
bytes in a process data channel is lim-
ited to eight; and the numeric multi-
ple-byte variables must be transferred
in Little Endian format (lowest signifi-
cant byte comes first).
MESSAGE FORMAT
A single MicroMessaging message
consists of a message identifier (default
is 1 byte), a data length counter (values
zero through eight stored in the lower
4 bits of a byte, and the upper 4 bits
used for an optional checksum), and up
to 8 data bytes. The bits in the identifi-
er are divided into a 3-bit function code
and the 5-bit node ID (see Table 1).
A total of eight (function code) mes-
sages are assigned to each of the 31 pos-
sible nodes (node ID 0 is reserved) of a
MicroMessaging network. The eight
messages assigned to each node are
listed in Table 2.
All nodes must be able to receive the
master control message. A master sends
Function code
Message contents
Direction
Message ID
0
Master control message
Rx (to node)
00h
0
Emergency
Tx (from node)
01h–1Fh
1
Poll message
Rx (to node)
20h
1
Process data channel 1
Either
21h–3Fh
2
Process data channel 2
Either
41h–5Fh
3
Process data channel 3
Either
61h–7Fh
4
Process data channel 4
Either
81h–9Fh
5
Service data request channel
Rx (to node)
A1h–BFh
6
Service data response channel
Tx (from node)
C1h–DFh
7
Status channel
Tx (from node)
E1h–FFh
Message identifier bits
10
9
8
7
6
5
4
3
2
1
0
CANopen
Function code (0–15) CANopen node ID (1–127, 0 reserved)
MicroMessaging
Unused (8-bit only)
Function code (0–7)
MicroMessaging node ID (1–31, 0
reserved)
Table 2—
Eight function codes are available for MicroMessaging message IDs. The direction column specifies
whether this is a message coming from or going to the addressed node.
Table 1—
The message identifier used in CANopen (11 bits) and MicroMessaging (e.g., 8 bits) is divided into a
node ID field, which allows addressing a specific node, and a function code field, which specifies the contents of
the message (e.g., one code is used for service requests sent to the node).
CANopen
CANopen usage
MicroMessaging usage
MicroMessaging
function code
function code
1
Emergency
Emergency
0
3
TPDO1
Transmit process data channel 1
1
4
RPDO1
Receive process data channel 1
2
5
TPDO2
Transmit process data channel 2
3
6
RPDO2
Receive process data channel 2
4
11
SDO Response
Service data response channel
5
12
SDO Request
Service data request channel
6
14
NMT Control
Status channel
7
Table 3—
The 3-bit function code used in MicroMessaging messages corresponds to the 4-bit function code used
by CANopen.
38
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
technologies. A CANopen network can
be used as a backbone. Several subnet-
works based on other network tech-
nologies can be connected to that back-
bone via simple gateway tasks running
on some of the connected nodes.
A single MicroMessaging network,
which could be a subnetwork to a
CANopen network, may consist of up
to 31 nodes. Each node has a unique
node ID ranging from 1 to 31. Each
node can have up to four process data
channels, each capable of transporting
up to 8 bytes of process data. Each
process data channel supports all of the
common connection types offered by
CANopen: point-to-point (from one
node to one other node) or multicast
(from one node to multiple others) con-
nections. The transmission type (i.e.,
how the transmission is triggered) for
process data messages is time-driven on
a fixed time basis (e.g., every 50 ms).
SHARING NETWORK MEDIA
When it comes to
sharing a single net-
work media, a network
technology needs to
provide an arbitration
mechanism. In other
words, a method is
needed that assigns the
network media to a
specific node so that it
can transmit messages
without being interrupted by others.
The transmission types (i.e., what
triggers the transmission of a message)
supported by MicroMessaging depend
on the type of network media used. On
a network media supporting multimas-
ter access (any node can write to the
bus at any time, collisions get resolved
automatically, and it’s available with
CAN and I
2
C), nodes may write their
messages at any time (collisions get
resolved automatically).
If the network media
does not support multi-
master-access (e.g., a
UART interface shared by
multiple nodes), all trans-
missions only happen by
polling: One node in the
network becomes responsi-
ble to poll all of the nodes
connected to the network
in CANopen (CiA DS301).
STATUS CHANNEL
Each node generates one status mes-
sage that’s sent after the boot-up mes-
sage and implements the heartbeat,
which is a message sent periodically
with information about the current state
(e.g., running or stopped). The message’s
content is compliant to the NMT con-
trol message of CANopen (CiA DS301).
Photo 1 shows MicroMessaging mes-
sages produced by nodes 3 and 5. Each
node has data channel 1 (message IDs
23h and 25h) transmitting a 6-byte value
and data channel 3 transmitting (message
IDs 63h and 65h) a 2-byte value. The
heartbeats produced are messages E3h
and E5h. As you can see, I used PEAK-
System’s PCANVIEW, which is a simple
CAN monitor. The Period column dis-
plays the cycle time of each message in
milliseconds. In the MicroMessaging
nodes, the heartbeats were set to 1 s.
NETWORK STRUCTURE
Although MicroMessaging can be
used in stand-alone embedded net-
works (i.e., all nodes connected via the
same physical network technology), its
true strength lies in mixing different
cyclically. After being polled, a node
transmits all of the messages that are
due for transmission (e.g., those where
the event timer expired). The default
poll message is the one with the ID
20h; it has a length of 1 byte, and the
data byte contains the node ID of the
node that is currently polled.
GATEWAY TASKS TO CANopen
The best method to interconnect
multiple MicroMessaging networks is
to use CANopen as a backbone.
Simple gateway tasks running on
nodes that have access to both a
MicroMessaging network and a
CANopen network can provide such
an interconnection.
CANopen can handle up to 127 nodes,
and multiple MicroMessaging net-
works can share the same CANopen
backbone if the gateway task is smart
enough to use an offset for the node
ID used on CANopen. For instance, it
could have nodes 1 through 31
(01h–1Fh) on the MicroMessaging net-
work, but translate that to nodes 33
through 63 (21h–3Fh) on the
CANopen network.
A gateway task that runs on a
microcontroller with access to both
CANopen and a MicroMessaging net-
work is kept simple if both networks
use the predefined connection set,
which is the default usage scheme for
the message identifiers (11 bits on
CANopen, 8 bits on MicroMessaging).
The schemes divide the message iden-
tifiers into a function code (most sig-
nificant bits) and the node ID (least
significant bits). This allows you to
put the node ID directly in the mes-
sage ID and assign each node a num-
ber of messages using the function
code (see Table 1). Exchanging mes-
sages between MicroMessaging and
CANopen only requires a translation
Photo 2—
In this instance, the scan cycle of a network consists of two regu-
lar CANopen nodes (7 and 41) and two MicroMessaging nodes (3 and 5 with
11-bit message ID representation). All four nodes were found.
Photo 1—
The messages include the heartbeats of the
nodes (0E3h and 0E5h), which are sent within a period
of 1000 ms (every second). The first four messages in
the Receive window are process data messages.
Photo 3—
The trace display shows the regular CANopen SDO requests
and responses used to access service data in the MicroMessaging node 3.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
39
of the message identifier used on both
systems (see Table 3).
STANDARD CANopen TOOLS
After the messages on a Micro-
Messaging network are converted by a
gateway to a CANopen network, you
can use standard CANopen monitoring,
analysis, configuration, and test tools.
Photo 2 shows the Network Overview
window of PCANopen Magic. The net-
work consists of MicroMessaging
nodes 3 and 5 sharing a network with
regular CANopen nodes 7 and 65.
After the MicroMessaging traffic is
transposed to a CANopen network, the
MicroMessaging nodes look and behave
like any other minimal CANopen
nodes. Photo 3 shows the standard
CANopen service data object (SDO)
accesses made by PCANopen Magic to
read the device type information from
the error register and the identity record
from the MicroMessaging node 3.
FUTURE UPGRADE
Although MicroMessaging is primari-
ly intended to provide a common net-
work protocol for applications using dif-
ferent network types, it’s also suitable
for applications that are based on only
one network technology. Most systems
grow over time, and even though today’s
application may only use one network
technology and a limited number of
nodes, using MicroMessaging ensures
future upgradeability. More nodes are
easily added (even when using other
network technologies), and the entire
communication layout is CANopen-
compatible enough that standard
CANopen tools for monitoring, analyz-
ing, configuring, and testing are usable
with MicroMessaging. In addition, note
that the ESAcademy tutors adopted the
General Public License as specified by
GNU for MicroMessaging, so the
entry costs are extremely low.
I
Olaf Pfeiffer earned a degree in tech-
nical computer science from The Co-
Operative University, Karlsruhe,
Germany. He is a regular speaker at
the Embedded Systems Conferences,
computing shows, and international
CAN conferences. His publications
include numerous articles and a
book about CAN and CANopen. As
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2003/159.
SOURCES
CiA Draft Standard 301
CAN in Automation
www.can-cia.de
MicroMessaging protocol
www.micromessaging.com
PCANopen Magic, PCANVIEW
Software
PEAK-System Technik
+49 6151 8173 20
www.peak-system.com
one of the founders of the Embedded
Systems Academy, Olaf still regular-
ly conducts CAN and CANopen
training classes and helps clients
with their embedded-networking
requirements. You may reach him at
opfeiffer@esacademy.com.
to be longer for finer voltage resolu-
tion.
The total capture time (T
CAP
) equals:
the number of voltage levels × (trigger
latency + sample time + step settling
time). Trigger latency is the average
amount of time the controller waits
for a trigger signal. The initial PWM
settling time and the step settling
time are the times for the PWM filter
to charge to its initial value and settle
after a 1-LSB step change, respectively.
Capturing 100 samples at 1 Msps in a
circuit optimized for 6-bit resolution
(64 levels) takes approximately 69 ms;
however, it takes about 1.3 s to meas-
ure the same waveform on a circuit
optimized for 8-bit resolution.
When capturing waveforms with long
periods, the total time needed to cap-
ture the waveform is dominated by the
time it takes the waveform to make the
requisite number of repetitions. For
shorter periods, the total time is domi-
nated by the settling times for the
PWM. Thus, the higher the sampling
rate, the more you can speed up the
capture cycle by using a faster DAC.
A resistor network connected to some
40
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
I
can capture repetitive waveforms at
1 Msps using a microcontroller’s on-
chip PWM and comparator. The impe-
tus for developing this technique came
from my own need to capture repeti-
tive waveforms using the least expen-
sive and lowest part-count means pos-
sible. I wanted to be able to view the
waveforms on an LCD dedicated to the
purpose or upload the waveform to a
computer for manipulation on a spread-
sheet. This waveform capture method
adheres to the “minimum mass” prod-
uct design concept: it doesn’t use any-
thing that is not absolutely essential
to obtaining the needed function.
Implementations can be cheap
enough to allow capture and analysis
in many applications that otherwise
could not justify the cost. Such appli-
cations include calculating the RMS
values or harmonic content of wave-
forms for power management and
equipment maintenance, self-testing
audio frequency circuits, the analysis
of pulse response for self-tuning ser-
vos, signal signature analysis, and
remote diagnostics and data gathering.
The approaches using on-chip A/D
converters on AVR and PIC controllers
reach sample rates of up to nearly
60 kHz. Exotic and pricey high-speed
controllers top out around 100 kHz.
Such a sampling rate is not really high
enough for the sort of applications I had
in mind: encoded data, radio control sig-
nals, A/D converter waveforms, check-
ing the dynamic range of amplifiers and
capturing audio frequency waveforms for
filtering, and power calculations. I real-
ized that the comparators in AVR and
PIC devices have fast response times
(several hundred nanoseconds) and that
the pulse width modulation (PWM) cir-
cuit could be made fairly responsive. I
Minimum Mass Waveform Capture
In this article, Dick shows you how to capture repetitive waveforms at 1 Msps using an
AT90S2313 microcontroller’s on-chip PWM and comparator.
just needed some way to quickly com-
bine them to sample analog values.
Eventually it became apparent that
repetitive sampling was the only way to
get high enough voltage and temporal
sampling resolution using only these on-
chip components. Rather than trying to
sample and digitize the waveform in
real time as it comes in, this method
finds out a little bit about the waveform
using the relatively high-speed compara-
tor every time the waveform is repeated;
it builds a more detailed picture with
each repetition by changing the relative-
ly low-speed PWM voltage each time.
THE METHOD
To capture a waveform, the PWM
D/A converter (PWM DAC) is set to
its maximum output voltage. Then,
using timing loops to generate regular-
ly spaced sampling times (1 µs in
Figure 1), the microcontroller looks at
the output of the voltage comparator to
determine if the incoming voltage is
higher than the PWM voltage. At each
sampling time, if the PWM voltage is
at a higher voltage than that of the
incoming waveform, the PWM value
is stored in a RAM array location corre-
sponding to that sampling time.
After all of the sample times have
been tested against the PWM voltage,
the PWM voltage is decremented. The
process is then repeated until the PWM
voltage has been reduced to its mini-
mum value (0 V). Each scan of the
sample time starts by a trigger signal
that’s derived from, or in some way
related to, the incoming waveform.
The finer the voltage resolution, the
longer it takes to capture the wave-
form because the waveform has to be
sampled more times. Note that the
settling time for the PWM DAC needs
FEATURE ARTICLE
by Dick Cappels
Figure 1—
It’s all in the timing. Firmware timing loops
set the interval between samples in a burst of wave-
form samplings that starts with a trigger signal. The
green dots represent voltage levels of the sampled sig-
nal at the time of sampling.
255
254
253
252
251
Compare v
oltage
Fixed
delay
≥
1 µs
Sample
number 1
2
3
…100
Trigger
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
41
PWM LOW-PASS FILTER
The DAC uses pulse-width modula-
tion, so it is necessary to have an aver-
aging (low-pass) filter to recover the DC
component while filtering out most of
the PWM signal’s AC component. The
AC component remaining on the filter’s
output is referred to as ripple.
The filter is made up of 330- and
82-k
Ω
resistors and a 0.047-µf capaci-
tor, which forms a single-pole RC fil-
ter. The two resistors form a voltage
divider to reduce the full-scale voltage
from the DAC to 1-V full scale. If you
are worried about accuracy, you can
replace the 82-k
Ω
resistor with a fixed
resistor and a variable resistor in series
to allow for full-scale calibration.
If 5-V full scale is appropriate for your
application, you can omit the lower
resistor and save a part. The low-pass
filter for the PWM output needs to be
made with a large enough time constant
to keep the ripple to an acceptable level.
After the filter time constant is pinned
down, the controller must wait long
enough after each step change in output
voltage for the filter to settle adequately
before starting measurements.
The PWM filter can be analyzed as a
single resistor driving the capacitor
(see Figure 4). Judging from the
AT90S2313 datasheet, when operating
at 5 V, the output resistance of the
PWM output is approximately 28
Ω
; it
is safe to say that it is negligible com-
pared to the 330-k
Ω
resistor that’s in
series with it. Thus, the filter model is
plenty close by taking the value of the
resistance to be the parallel combina-
tion of the two resistors (see Figure 4).
The first step is to select the time
constant that gives an acceptably low
ripple. For my application, I consid-
port pins could suffice for low-resolu-
tion (6-bit) waveform capture. An
integrated circuit DAC would be better
for higher resolution applications.
The quality of the trigger signal is
essential to the fidelity of the cap-
tured waveform. The trigger signal
must consistently appear at the same
time with respect to the captured sig-
nal, otherwise severe distortion will
result. This means that a noisy trigger
signal, such as one derived directly
from a noisy input signal, would give
poor results. You’ll get the best results
with a digital trigger signal taken
directly from the source of the signal
if such a trigger source is available.
Unsynchronized signals (e.g., noise)
are not represented accurately; instead,
such signals are underrepresented in
the captured waveform. This quality,
which results from synchronous sam-
pling, is sometimes a good thing
because it can effectively pull a signal
out of the noise, which is an impor-
tant property in applications such as
ultra wideband and spread-spectrum
signal decoding. But, if you intend to
measure noise or jitter, this quality
makes the system inappropriate.
Another aspect of sampled data sys-
tems is their susceptibility to aliasing.
Aliasing is a phenomenon in which a
signal appears to occur at a frequency
other than that at which it actually
occurs. For instance, when a 250-kHz
square wave is viewed with a 1-µs sam-
pling interval, it shows up properly as
four samples per cycle; however, when
it is captured at a 100-µs sampling
interval, it appears as 16 samples per
cycle, or a 625-Hz signal, which is one
four-hundredth the actual frequency.
To prevent aliasing, insert an analog
filter in the signal path before the com-
parator’s input. In the example I’ve been
focusing on, the AT90S2313 samples
the signal at 1 Msps. The on-chip com-
parator has a propagation delay of 500
to 700 ns, providing inherent filtering
for components of signals above approx-
imately 800 kHz, and thus restricting
the range of frequencies above the sam-
pling rate that can be aliased down to
frequencies below the sampling rate.
To reduce the aliasing of signal com-
ponents that have a lower frequency
than the sampling rate, you’d need an
additional external analog filter.
AN IMPLEMENTATION
The simple implementation shown
in Figure 2 needs only a microcontroller
with a DAC and voltage comparator,
and some way to get control signals into
the chip and the data back out. The
demonstration system, for which
firmware is posted on the Circuit Cellar
ftp site, assumes an Atmel AT90S2313-
10 is connected to level-shifting invert-
ers for the EIA-232 interface such as a
Maxim MAX232 with its 1-µf capaci-
tors, a 10-MHz crystal with load
capacitors, a decoupling capacitor, and
the PWM low-pass filter connected to
pins 13 and 15 of the microcontroller
(see Photo 1). It can be controlled by
and dump data to an ASCII terminal
program such as HyperTerminal at
capture rates from 1 µs per sample to
10 ms per sample at 6-, 7-, and 8-bit
resolution with selectable trigger
polarity. An example of a waveform
captured with this system and plot-
ted in a spreadsheet program is
shown in Figure 3.
Figure 2—
You can work with a bare minimum of parts, because it doesn’t take much to capture repetitive wave-
forms at 1 Msps and upload them to a terminal program on a PC for display and analysis. The passive compo-
nents connected to pins 13 and 15 of the microcontroller are in the same basic configuration used for successive
approximation A/D conversion; only the firmware is different.
Photo 1—
The only components added to the operat-
ing Atmel AT90S2313 circuit needed to allow for wave-
form sampling with less than 1-µs resolution at 1-V full
scale are the capacitor and two resistors. Imagine how
small the circuit will be using surface-mount components.
)NDUSTRY
POWERFUL
DEMONSTRATE
RELEASED
h-Y
AND
$YNAMIC
)
EASY TO USE
*AN
2OYALTY FREE
4#0)0
AND
WITH
&%!452%3
%THERNET
0ROCESSOR
0OWER
-EMORY
)/
3ERIAL
*UMPSTART
)NTERNET
2#-
(URRY
2#-
%MBEDDED
+IT
4#0)0
BOARD
AND
QTY
QTY
&REE
7ITH
2#-
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
43
the voltage changed more than 0.5
LSB. Because the step size is 1 LSB, I
chose one time constant, or 3 ms.
FIRMWARE
When capturing a waveform, the
PWM circuit first generates the maxi-
mum output voltage and samples all
time intervals starting from a trigger
signal, taking care to keep the time
between samples constant. Whenever
the voltage at a sampled time exceeds
the PWM voltage, the PWM value is
stored in the RAM array location cor-
responding to that sample. In this
way, at the end of the capture cycle,
the peak value at each sampling time
is stored in the RAM array.
The sampling loop in Listing 1 is the
time-critical part of the code. It requires
10 clock cycles per sample. With a 10-
MHz clock, the sampling rate is 1 MHz.
Two clock cycles are taken up by the
indirect jump instruction (
ijmp), which
jumps either to the next instruction in
sequence (at the label
oneus:) or to a
delay routine that returns to the next
instruction in sequence. Eliminating
ered speed to be more important than
absolute accuracy, so I decided to keep
the ripple at 1 LSB.
The time constant should be figured
for the worst possible PWM signal. The
worst case for ripple is when the lowest
frequency appears at the filter’s input.
In the case of the AT90S2313, this
occurs when the PWM output runs
50% duty cycle. Under this condition,
the pulse frequency is about 19.6 kHz
and the voltage across the capacitor is
0.5 V. When the pulse is high (this
analysis is the same for the time the
pulse is low, only the signs change), the
difference between the PWM peak
voltage (1 V) and the voltage across
the capacitor is across the equivalent
resistance, and the current through the
resistance charges the capacitor.
Note that 1 LSB of an 8-bit value
based on 1-V full scale is 4 mV (1/255).
Using the formula in Figure 5, the time
constant must be approximately 3.2 ms.
I chose the resistors by first selecting
the largest capacitor and a pair of large
resistors that had the necessary 4:1
resistance ratio while simultaneously
giving nearly the correct time constant.
The resulting combination gives a
divide ratio of 1:5.02 and a time con-
stant of 3.15 ms (67 k
Ω
× 0.047 µf).
After the filter time constant is
known, the settling times can be
determined. I decided to have the con-
troller wait for the initial settling of
the filter to within 1 LSB of full scale
before starting the waveform capture
cycle using the formula in Figure 6.
For the settling time between succes-
sive steps, I wanted to wait until after
the indirect jump instruction would
decrease the sampling interval to eight
cycles. Straight line coding would be
inflexible and take a lot of program
memory, but it could reduce the sam-
pling interval to as few as three cycles
when storing the waveform in RAM.
At the beginning of a waveform col-
lection cycle, the program sits in a wait
loop and waits for a transition on the
trigger input. After the triggering edge is
detected, the sampling routine is called
and it runs through and collects a full
set of samples. Then, the PWM value is
decremented, a wait loop is executed to
allow the RC filter in the PWM DAC to
settle, and the program returns to wait
for the next triggering event. This
process continues until the lowest pos-
sible PWM value has been tested.
Timing uncertainty is introduced by
the short loop in which the controller
waits for the triggering edge. The
uncertainty translates into jitter in the
signal sampling. As long as the uncer-
tainty is small compared to the signal-
sampling interval, it should not con-
tribute much in the way of noise to
the captured waveform. In applications
that use only a few machine cycles
between samples, it pays to keep the
wait loops as short as possible.
BELOW GROUND SIGNALS
Judging from the offset-versus-input
voltage curve on the AT90S2313’s
datasheet, the comparator’s differen-
tial gain is good enough for 6-bit
waveform capture just above ground.
For linearity errors of less than 1 LSB
with 8-bit operation, the comparator
inputs need to run closer to the mid-
dle of the power supply where the
curve is nearly flat.
There is a bonus to adding offset to
Figure 4—
The PWM filter is easily analyzed as a single resistor charging the capacitor by replacing the resistors
with a single resistor equal to the parallel combination of the two, because that is what it looks like to the capacitor.
250
200
150
100
50
0
1 6 11
16
21 26
31 36
41 46 51 56 61 66 71 76 81 86 91 96
Figure 3—
This is the capture of a 31.25-kHz sawtooth waveform. The sample rate is set to 1 µs per sample and
the voltage resolution is 8 bits.
44
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
the input signal in that it can measure
input signals at and below ground
without clipping. When the input sig-
nal is level-shifted, the PWM DAC’s
output must be similarly offset. The
PWM offset circuit provides an oppor-
tunity for an adjustable vertical-cen-
tering control (to use the oscilloscope
term). Circuits that shift the input
level and allow offset adjustment are
shown in Figure 7.
Level shifting is achieved easily
enough with an op-amp if you have a
negative power supply, but my objec-
tive was to make the entire system
operate from a single 5-V regulator.
Besides, my cheap single-supply op-
amps, which also had adequate dynam-
ic range, had too poor a slew rate to
give satisfactory performance at 1 Msps.
A junction field effect transistor
(JFET) source follower is an ideal way
to offset the input signal to a more
positive voltage without much attenu-
ation or loss of bandwidth. I used an
MPF102 in my own circuit because I
had some on hand. Numerous other
small signal JFETs would work well.
Pinch-off voltage is the FET parameter
that most affects the offset because, for
most FETs, this parameter varies widely.
To obtain the approximate 2.5-V offset
(the DC voltage on the FET source when
the gate is grounded), you can hand
select an FET, adjust the source resistor
(15 k
Ω
in the circuit above), or try a
combination of the two. The higher the
value of the resistor, the higher the off-
set voltage (i.e., up to nearly the pinch-
off voltage of the FET, which is usually
specified at a low current). Be aware that
the source resistor affects the trade-off
between the bandwidth and signal loss.
As the resistor gets larger, the band-
width will decrease; as the resistor gets
smaller, the gain of the source follower
drops. For my particular circuit layout
and its parasitic capacitance, 15 k
Ω
was
about the upper limit for 1 Msps.
One way to add an adjustable DC off-
set to the output of the PWM circuit
without affecting the RC filter’s response
time is to use an adjustable constant cur-
rent source. The current source shown
in Figure 7 relies on the fact that the
2N2907’s collector current is nearly equal
to the emitter current. (The collector cur-
rent equals the emitter current times
Alpha, which is nearly unity and pretty
stable.) Emitter current is determined by
the voltage across the 8.2-k
Ω
emitter
resistor, which follows the base voltage
and is temperature-compensated by the
diode in series with the potentiometer.
SIMPLE, ECONOMICAL, FLEXIBLE
Among the variations that may be
useful are programmable offset and
gain controls, and a calibration func-
tion using only a few resistors and
additional I/O pins. In multiple-chip
systems, the time-dependent sampling
task can be offloaded to a low-cost
slave processor with little or no RAM
that sends intermediate results to a
host. The slave could be one of the
cheapest eight-pin microcontrollers
offered that has a suitable on-chip
voltage comparator. The minimum
mass waveform capture approach is a
T = – t = 17.4 ms
In
∆
Λ
Vin
t = 3.17 ms
Time to settle to within 1/255 of 1 V = 17.4 ms
Magnified
∆ Λ
E
I
= 1 V
Voltage at T
Figure 6—
The initial settling time must be long enough
to assure that the PWM output settles to within 1 LSB
of the final voltage. It must be calculated for the worst
case scenario, which is when it starts from 0 V. Note
that
∆
V
is the error in the settled voltage (1 LSB = 4 mV).
E
I
is the voltage applied to the circuit, which is 1 V. In is
the natural logarithm (base 2.71828…). T is the time
that voltage is applied across the circuit, and t is the
time constant of the circuit (3.17 ms).
Listing 1—
The sampling of the waveform takes place at the
sbic ACSR,5
instruction, where the output
of the comparator is tested. If the comparator’s output is low, execution proceeds to
st Y+,pwmval
, the
instruction that stores the data into the RAM array via the Y pointer. If the comparator’s input is high, the
program branches back to
nextydelay
, which imcrements the Y pointer without storing data.
nextydelay: ;Entry point. When not storing,branch back to here.
inc YL ;Increment RAM pointer and check if it’s pointing
;past the end of the array.
cpi YL,arrayend+1
;If at end of RAM array, branch to decre-
;ment PWM value.
breq decpwm
nop ;No-ops to qualize time between samples for pwmval
;saved and not saved.
nop
nexty:
ijmp ;Indirect jump to delay routine, or to oneus for 1-µs
;sampling. The address of the delay routine was loaded
;into the Z register prior to entering this routine.
oneus:
sbic ACSR,5
;Capture comparator output state by
;skipping jump if comparator zero
rjmp nextydelay
st Y+,pwmval
;Store data, increment RAM pointer
cpi YL,arrayend+1
;Check if RAM pointer is pointing past
;end of array.
breq decpwm
;If end of RAM array, decrement the PWM
;value, exit if PWM value was zero, if
;PWM was not zero, reenter this routine
;at "nextyde lay:"
rjmp nexty
;Go for another sample
capturefinsihed:
ret
0 V
1 V
T =
10 MHz
510
= 25.5 µs
∆
= E
O
E
I
, voltage across
capacitor = 0.5 V
Pulse width
modulation signal
Λ
t = – = 3.17 ms
T
In( )
∆
Λ
E
IN
2
Figure 5—
A simplified model can be used to predict
the relationship between the filter’s time constant and
the amount of ripple. The charging current for the
capacitor comes from the voltage drop between the 1 V
from the output of the resistive divider and the voltage
across the capacitor. Note that E
O
is the voltage change
across the capacitor (1 LSB = 4 mV), and E
I
is the
average voltage across the resistance (0.5 V). T is the
time that voltage is applied across the circuit (25.5 µs),
and t is the time constant of the circuit.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
45
ple system together, so why not give
it a try? You may download the AVR
Studio source code from the Circuit
Cellar
ftp site. Visit my web site
(www.wavechip.cappels.org) for
details about buying a preprogrammed
chip.
I
building block that produces a much
faster sampling rate and costs less
than conventional approaches using
on-chip A/D converters.
I suspect that by now you have
come up with some ideas of your
own. It’s easy enough to put the sam-
Figure 7
—
The FET provides an offset allowing the input to swing above and below ground as well as moving the
input to the AT90S2313’s on-chip comparator away from ground and enabling an offset adjustment. You can also
achieve these functions with op-amps, but there are several trade-offs to consider.
SOURCE
AT90S2313 microcontroller
Atmel Corp.
www.atmel.com
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2003/159.
RESOURCES
Atmel Corp., “AT90S2313,” rev.
0839I-AVR, June 2002.
Maxim Integrated Products,
“MAX232, MAX232I Dual EIA-232
Driver/Receiver,” SLLS047G,
August 1998.
Dick Cappels enjoys tinkering with
and writing about analog circuits and
microcontrollers. He has published
several papers relating to electronic
displays in computer systems, and is
currently active in the Society for
Information Display. Dick holds
17 U.S. patents. You may reach him at
projects@cappels.org.
one system that is universally accept-
ed as the best serial data transmission
method. I narrowed the field down to
those methods commonly used between
an MCU and its peripherals (and/or a
host PC). There are four popular stan-
dards: asynchronous, which is UART-
based and sometimes uses RS-232 volt-
age levels; SPI, which is a four-wire seri-
al peripheral interface developed by
Motorola and used, in similar configura-
tions, by other companies; I
2
C, which
46
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
I
’ve always been a big fan of serially
interfaced peripheral chips. Granted,
some of this enthusiasm is based on
laziness. Because I do mostly custom
projects, I either do the wiring or
design and etch the PCB personally.
There’s no contest between wiring a
serial chip with one to four wires and
running eleven or more wires to a par-
allel-interfaced device.
There are numerous other advantages
to serial devices. Many of the interest-
Serial Sidekick
ing devices available today (e.g., DACs,
ADCs, real-time clocks, EEPOTS, and
flash memory) would be available only
in larger multiple-pin packages and
would be awkward to use if they were
parallel devices. Furthermore, if you
need some form of electrical isolation
between your analog sensing or control
devices and microcontroller (for noise or
safety purposes), the serial interface is
generally the most practical way to go.
Mirroring life in general, there is no
FEATURE ARTICLE
by Brian Millier
Brian built the perfect device for troubleshooting the serial data communications methods he
uses. He calls his bench-side assistant the Serial Sidekick. The small, stand-alone device
can graphically represent up to four signal lines and has miniterminal capability.
Figure 1—
A FIFO chip, EconOscillator, and a few TTL chips handle just about all of the logic analyzer functions.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
47
ply connect it to this instru-
ment and interact with it
without actually wiring it on
an MCU development board
and writing a program for it.
I call my design the Serial
Sidekick (see Photo 1). I made
no special effort toward minia-
turization, but it still fits in a
10
″
× 6
″
× 3
″
case and takes up
little space on my bench. The
128 × 240 pixel graphic display
handles the four-channel logic
state analyzer, and, in
Miniterminal mode, it pro-
vides a 16 × 40 line text
screen, which is adequate.
The Serial Sidekick is con-
trolled by an ATmega323,
which is positioned near the
top of the AVR family of
microcontrollers. Thanks to
some clever peripheral devices,
the design requires only nine
ICs and runs comfortably on a 9-VDC,
500-mA power adapter. To achieve this
small size/chip count, I used a common
AT computer keyboard for the miniter-
minal’s keyboard input device, because
virtually everyone has such a keyboard
available for occasional use.
Apart from using the miniterminal
keyboard, all of the other user I/O
functions are handled by four push
buttons, which are located below the
one-line menu area at the bottom of
the screen. A rotary encoder is used to
adjust numeric parameters.
LOGIC ANALYZER
Although not a full-blown logic ana-
lyzer, I’m describing the circuitry that
graphically displays the state of the
four (or less) serial data lines as such.
This was the first function that I tack-
led, because it involved the bulk of
the circuitry (see Figure 1).
The serial data rates range from a slow
300-bps RS-232 link all the way up to a
4-Mbps SPI data link, so I had to provide
a fast data collection method coupled
with a wide-range clocking device. I
wanted the fastest sampling time to be
50 ns per point (20 MHz) to properly
monitor fast SPI transfers. Even fast
MCUs cannot collect data that quickly
on their own, so I used a FIFO memory
chip to store the data quickly, while also
was developed by Philips and
is often generically referred to
as the two-wire serial interface,
or TWSI; and one-wire, which
was developed by Dallas
Semiconductor. (One-wire uses
only one wire plus ground for
communication. It often sup-
plies power to the device
through that same wire.)
I use the term “standards”
loosely, and that is the dark
side of serial devices in gener-
al. The asynchronous and SPI
methods have a myriad of dif-
ferent parameters that have
to be specified. It’s safe to say
that there isn’t one parameter
that is fixed amongst the var-
ious implementations of
either method.
Fortunately, the I
2
C and one-
wire methods were developed
more recently. Specific compa-
nies created the methods, and each one
is strictly defined. This results in less
confusion when connecting various
devices using the two methods.
However, the software needed to imple-
ment the protocols associated with the
two methods is more complex than
that needed for the other two methods.
On the other hand, asynchronous
and SPI ports are generally implement-
ed in hardware in all but the low-end
MCUs. Neither I
2
C nor one-wire ports
are standard issue on most MCUs,
although Microchip includes a hard-
ware I
2
C port on many of its PICs.
Despite the time I’ve saved in actu-
ally wiring the serial peripherals, I
have to admit that I’ve probably wast-
ed a heck of a lot more time during
the programming phase as I tried to
get the devices to talk to each other
reliably. Granted, after you get MCU
A to communicate with peripheral B,
using the same two devices in the
future is easy. The problem is that I
use a lot of different peripherals and
switch MCU families every so often.
For troubleshooting serial peripheral
data communications, my digital stor-
age oscilloscope at work works well,
but I probably do as much design work
at home. My Tektronics 100-MHz ana-
log oscilloscope doesn’t really work
well for this. Additionally, for SPI, you
really need to observe three signal
lines, which is more than a two-chan-
nel oscilloscope can display.
What I wanted to design was a small,
stand-alone instrument that would
assist in troubleshooting the various
serial data communications methods
that I use. I wanted it to provide two
basic modes of operation, the first of
which is a graphic representation of up
to four signal lines. This would basically
resemble a four-channel logic state ana-
lyzer that’s tailored with a triggering
capability and timing resolution suited
for the aforementioned serial data trans-
mission methods. I wanted the second
mode to provide a miniterminal capabil-
ity. Basically, I wanted to be able to send
and monitor data using asynchronous,
SPI, or I
2
C methods. For instance, if I get
a sample of a neat new chip, I could sim-
Photo 1
—
The Serial Sidekick is as small as I could
make it while still using a 128 × 240 graphic LCD panel
and enough function keys to make it user-friendly.
Internal
oscillator
DIV1
0M1
0M0
1M1
1M0
EN0
SEL0
PDN0
PDN1
Control
registers
Two-wire
interface
SDA
SCL
P0 Prescaler
(M divider)
0M1 0M0
MCLK
P1 Prescaler
(M divider)
1M1 1M0
MUX
Control
logic
SEL0
EN0
PDN 0
Select
Power down
CTRL0
OUT0
Enable
Programmable
N divider
OUT1
Control
logic
CTRL1
PDN1
Power-down
Enable
DIV1
Figure 2—
Apart from the four slowest sample rates, the DS1077 EconOscillator
chip provided all of my time-base frequencies.
48
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
miniterminal function, I decided
against using any switches, which
would have added a lot of wiring com-
plexity. Instead, I brought out all of
the logic analyzer input lines, the trig-
ger input, the MCU’s UART, the SPI
and I
2
C lines, and 5 V and ground to a
25-pin D connector. For each of the
serial data communication methods
there is a unique 25-pin D plug with
the proper jumpers and leads attached.
These match up with the proper logic
analyzer inputs and MCU port lines
(for the miniterminal function). There
are two cables in Asynchronous
mode. One cable operates at TTL lev-
els and the other at RS-232 levels
(using the built-in MAX232 level
shifters in this instance).
As you can see in Figure 1, 8 bits of
the FIFO are connected to both the MCU
and input socket. Although only four
lines are needed for serial purposes, I am
leaving open the possibility of enhancing
the software to display all eight channels
for general logic use. There is certainly
a lot of room left in the MCU’s 32 KB
of flash memory for this.
allowing the MCU to read it out at its
own slower rate. I had AM7203-25DC
2K × 9-bit devices on hand that fit the
bill nicely. Packaged in a 28-pin skinny
DIP, they were easy to wire on my DIP-
patterned prototype board. The more
modern and readily available FIFOs
made by Cypress and Texas Instruments
come in 32-pin PLCC packages but are
otherwise functionally identical.
FIFO chips are not cheap, so I decid-
ed to place a 74LS244 buffer chip
between the FIFO and the device
under test (DUT). I allowed the buffer
to sacrifice itself instead of the FIFO
just in case something was drastically
wrong in the DUT or I messed up.
I used two TTL chips: a 74LS86 to
select trigger polarity and a 74LS74 flip-
flop to act as the run/stop latch. The
MCU performs all of the necessary con-
trol functions involved in arming the
circuit for a data collection, performing
the collection, and then reading the
results for subsequent display.
To handle the various signals
involved with each serial transmission
method for both the logic analyzer and
EconOscillator
I needed a wide-range, reasonably
accurate clock to control the rate at
which the FIFO reads the state of the
four serial lines. I decided that the
standard 1-2-5 timing interval—
repeated over several decades, as used
on a oscilloscope—would be the best
choice. The last time I had designed
something like this, which was about
10 years ago, I used a 20-MHz oscilla-
tor module, which was followed by a
74LS390 dual-decade divider chip and
an 8513 programmable timer chip (for
the lower sample rates). That worked
well at the time, but I figured there
must be a simpler way. Sure enough,
Maxim had an answer.
I’m impressed by the steady stream
of new devices that Maxim has been
putting out. I’m on the company’s
mailing list for mixed-signal design
guides, and I often get temporarily dis-
tracted from ongoing projects when I
receive the brochures. Often, the com-
pany proudly displays a little speck on
the page showing the actual size of the
device in question, which is generally
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
49
a deal-breaker for me, because I can-
not handle such miniscule devices. In
this case, though, the DS1077L
EconOscillator, which came in an
eight-pin SOIC, fit my requirements
exactly (see Figure 2).
The DS1077L is available as a 40-,
50-, 60-, or 66.666-MHz device. I used
the 40-MHz version. Although this
frequency is not quartz-accurate, it is
specified to be within 0.5% of rated
value and within
±
1.25% over temper-
ature/voltage. It is accurate enough for
my purposes, because I only use it at
room temperature and its power sup-
ply voltage is stable.
Two divider chains, each of which
feeds its own output, follow the
DS1077L’s oscillator. Channel 1 is the
most versatile, containing a 1/2/4/8
prescaler and a 12-bit programmable
N divider, which is the section I used.
A real selling feature for the DS1077L,
in this design, was the fact that it uses
an I
2
C interface. My chosen MCU
contains an I
2
C port, which was need-
ed for other peripherals.
The device also implements pro-
grammable power-down and output-
gating control. The DS1077L contains
EEPROM, so it can be preprogrammed
and left to operate in a stand-alone
configuration at a fixed frequency.
These three features were not utilized
in my design. I had DS1077L samples
on hand, so that’s what I used. The
DS1077L is a 3.6-V device. Because I
wasn’t able to get the 5-V DS1077
quickly, I added a few resistors and
diodes to my circuit to allow me to
use the L version with my 5-V logic
system. In Figure 1, you’ll notice that I
also added potentiometer R2 to set the
DS1077L’s power supply to 3.6 V. By
adjusting this voltage (within limits),
you can trim the oscillator frequency a
bit to match the nominal 40 MHz.
The EconOscillator simplified my
design considerably; however, before I
finished the project, I had read about
Dallas Semiconductor’s DS1085 fre-
quency synthesizer chip. This builds
upon the DS1077’s circuit by adding a
programmable DAC/VCO and allow-
ing the device to produce virtually any
frequency in the kilohertz to mega-
hertz range. I’m waiting for the sam-
ple of that chip that I requested!
Although the DS1077 is versatile, it
was not able to produce the four slow-
est sample rates that I had wanted
(e.g., 0.5, 1, 2, and 4 ms). To derive the
latter sample rates, I used the MCU’s
8-bit Timer0 clocked by the 7.327
MCU clock (divide by 64). Although
the MCU’s Timer0 was available for
this, I had to add U3, a 74LS157 mul-
tiplexer device, to select between the
two clock sources and gate them.
MCU AND USER INTERFACE
In addition to controlling the logic
analyzer circuitry and LCD, the MCU
also contains the UART, SPI, and I
2
C
ports required for the Miniterminal
mode of operation. I chose a high-end
member of the Atmel 8-bit AVR fami-
ly—the ATmega323. Basically, the
ATmega323 is an AT90LS8535 on
steroids: it has the same pinout as the
’8535, which I use frequently, but
contains four times as much flash
memory (32 KB) and RAM (2 KB). The
firmware for this project was quite
involved, and it would not have fit in
the 16-KB flash memory of the
ATmega163, the next lower member
of the family.
More significantly, the ATmega323
contains a hardware I
2
C port that’s not
present in lower-level devices. Because
the I
2
C protocol is fairly complex (rel-
ative to asynchronous and SPI), having
the I
2
C function in the hardware took
some of the load off the MCU and
saved a lot of code.
I use the MCU’s hardware I
2
C port
strictly for the I
2
C miniterminal
function. The I
2
C peripheral devices
used in the Serial Sidekick are con-
nected to a secondary I
2
C port
(labeled SCL1 and SDA1 in Figure 3),
which is implemented in the soft-
ware. The software I
2
C routines are
included in the BASCOM-AVR
library. Notwithstanding my com-
ments concerning the complexity of
I
2
C protocol, the secondary I
2
C port
operates strictly as a master at con-
siderably less than the full I
2
C 400-
kHz data rate. As such, the software-
implemented port is perfectly ade-
quate to communicate with its
attached peripherals.
There are a number of different
modes, functions, and parameters that
50
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
you must select when using this
device, so it is important to have a
user-friendly operator interface. I
decided to devote the bottom line of
the LCD panel to define four func-
tion keys, which are activated by
four push buttons mounted just
below the display itself. This makes
navigating through the various
menus straightforward. I incorporat-
ed a single-rotary encoder for adjust-
ing the various numeric parameters
and cursor movement.
PCF8574 I
2
C I/O EXPANDER
I heard about the interesting PCF8574
a number of years ago, but I wasn’t
using an MCU with I
2
C capability at the
time. At the time, it was manufactured
by Philips and wasn’t readily available
to me, so I ignored it. Recently, howev-
er, Texas Instruments began to second-
source it, and TI was good enough to
send me a few samples to try out.
The PCF8574 contains eight pseudo
bidirectional port lines, each capable
of sinking enough current to drive
LEDs and so on. The I/O ports are
implemented in such a way that no
pull-up resistors are needed to sense
switch closures, which is handy. As an
I
2
C device, it needs only two lines to
interface to the MCU.
What made the PC8574 particularly
well suited for this application was its
interrupt on pin-change function.
Basically, if a switch is pressed or
released, or if the rotary encoder is
moved, an interrupt is flagged on the
PCF8574’s *INT line. In this project, the
line is connected to the ATmega323’s
*INT1 input. The event triggers an ISR
that reads the state of the PCF8574’s
eight I/O lines, and determines which
switch/encoder action has occurred.
You may be aware that this function
is incorporated into certain ports on
PIC chips, but it is not present on
most AVR MCUs (except ATtiny
devices). Even if it were, there aren’t
six free I/O lines on the ATmega323 in
this project to dedicate to the switch-
es/encoders, which makes the
PCF8574 particularly valuable.
While I’m on the topic of I
2
C periph-
erals, note that in addition to the
PCF8574 and the EconOscillator, I
decided to wire up a Microchip
24LC256 I
2
C flash memory EEPROM
(32K × 8). It took only 5 min. to wire
the inexpensive eight-pin DIP device,
and it gave me the option of storing
many waveforms and the contents of
the buffers that are used in the miniter-
minal mode. I haven’t actually expand-
ed the firmware to handle this yet.
THE KEYBOARD
To allow this instrument to act as a
miniterminal requires some sort of
alphanumeric keyboard. There is no
way to fit such a keyboard on a small
The control software must be able
to respond instantly to any changes
in the four push buttons and rotary
encoder, without the overhead
involved in constantly polling the
six I/O lines associated with them.
This implies some sort of interrupt-
driven sensing routines. Because I
had already allocated virtually all of
the ATmega323’s I/O lines for other
purposes, I needed a way of accom-
plishing this without using numer-
ous I/O lines.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
51
instrument like this, particularly if
you don’t have access to the cus-
tomized membrane switch panels
found in some commercial equip-
ment; however, compact models of
the ubiquitous AT keyboard are avail-
able for a song—in fact, you may have
a spare keyboard lying around.
The AT keyboard interface, which
consists of two signal lines (data and
clock), is a cross between an asynchro-
nous interface (i.e., it uses start and stop
bits) and a synchronous interface (i.e., it
has separate clock and data lines). The
clock and data lines are pulled up to 5 V
by resistors. Either the keyboard or the
device to which it is connected can act
as the master by pulling the lines low
when sending data. Although the AT
keyboard routinely gets commands
from the PC when it’s used as a PC key-
board, the only data exchange that
occurs in this application is from the
keyboard to the Serial Sidekick.
The BASCOM-AVR compiler con-
tains a library routine supporting
polled AT keyboard input. This proj-
ect requires interrupt-driven routines,
because the program must to be able to
accept keyboard input at random times
while at the same time processing and
displaying data coming in from an
external serial device. I spent a lot of
time working with BASCOM’s devel-
oper to debug this routine.
GRAPHIC LCD
The cost of graphic LCD panels is
gradually dropping. Although some com-
panies offer surplus 128 × 240 pixel pan-
els for approximately $50, I purchased
a new AGM2412B display because it
wasn’t too expensive and has an excel-
lent datasheet. In December 2000, I
wrote a comprehensive article about
interfacing displays like this one and
the Toshiba T6963 LCD controller
chip in particular (“Using a T6963
Controller-Based Graphics LCD
Panel,” Circuit Cellar 125).
Besides the eight data lines, only
three control lines connect to the MCU,
the other control lines present in the
T6963 interface are hard-wired to the
necessary state. This display uses an
LED backlight. Although this requires
only a 5-W power resistor to run from
the raw 9-V power input, it’s somewhat
ironic that the backlight draws about
75% of the instrument’s total power!
The AGM2412B panel requires a
stable negative power source of about
14 V to operate, in addition to the
normal 5 V. I reverted to the same
MAX749-based circuit that I used in
the original T6963 graphic LCD arti-
cle. In the interim, I designed a cheap-
er alternative to the MAX749 circuit
(“Build a Graphics LCD Bias Supply,”
Circuit Cellar
144). However, I found
myself completely out of ATtiny12
MCU chips when I was building this
project, so I could not use my newer
design for this project.
For my T6963 graphic LCD article,
Figure 3—
Take a look at the MCU, the graphics LCD interface, and the associated V
EE
generator. Because it was so easy, I added an I
2
C 32K × 8 flash memory EEPROM,
but I haven’t written any firmware featuring it yet.
52
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
I spent a considerable amount of
time writing a set of assembly lan-
guage graphics routines for the
T6963. The firmware for this project
was too complex to do it in assembly
language. Luckily, the BASCOM-AVR
compiler had been recently upgraded
to contain T6963 graphic LCD sup-
port in its library, which allowed me
to write the firmware in Basic with-
out the hassle of merging my own
assembly language graphics routines
with the Basic code.
LOGIC ANALYZER OPERATION
The logic analyzer mode operates
like a four-channel digital storage oscil-
loscope, triggered by whatever signal is
appropriate for the serial communica-
tion method being monitored. In
Asynchronous mode, it is the data
signal itself, and triggering is set for “-”
to catch the falling edge of the start bit.
In SPI mode, the trigger connects to
the *SS (device select) signal and trig-
ger polarity is set to match the lead-
ing edge of the signal. This is usually
a falling edge, but not always. In the
case of I
2
C, it is the falling edge of the
SDA line (with SCL high), which indi-
cates the beginning of the data transfer.
In the Serial Sidekick, I call it Scope
mode, because it functions virtually the
same as a four-channel digital storage
oscilloscope (apart from the fact that it
can only display logic ones and zeros,
and not true voltage levels). Like an
oscilloscope it has three trigger modes:
Auto, Normal, and Single Sweep. Auto
mode is free running and presents an
ongoing display of the serial
data/clock/select lines. In Normal
mode, data collection starts after the
proper trigger and will be displayed.
Then, it will wait for the next valid
trigger. In Auto and Normal modes, the
signal you see on the LCD is 240 sam-
ples long, corresponding to the horizon-
tal resolution of the LCD panel. In
Single Sweep mode, you have the
choice of viewing any of six 240-sample
data sets (spaced at 180 sample inter-
vals) over the 1024 samples contained
in the FIFO. Overlapping the windows
makes the patterns easier to examine.
When observing signals in Single
Sweep mode, the actual elapsed time
from the trigger point to the current
cursor location is displayed at the bot-
tom of the screen. I also added a special
function to analyze the codes sent from
IR remote controls. Pressing the Special
Function button in this mode clears the
graphic display and presents a display
of the number of data samples between
each signal transition, and whether
that transition is rising or falling.
Besides the advantage of being able to
watch a four-line SPI serial data link,
the Logic Analyzer mode should also
come in handy when checking out both
wireless and power line asynchronous
data links. I recently completed several
projects involving Plinius power line
modems and various RF modules, all
using asynchronous data links. Such
modules often produce signals that
don’t meet strict asynchronous data
link specifications because of noise, low
signal strength, and so on. Trying to
troubleshoot these projects with a
two-channel analog oscilloscope was
difficult. I suspect that this was what
finally prompted me to build this
instrument.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
53
MINITERMINAL OPERATION
As I mentioned earlier, the idea here
is to allow two-way, interactive com-
munication with peripherals featuring
asynchronous (RS-232 or TTL levels),
SPI, or I
2
C ports without the necessity
of connecting them to an MCU and
writing a test program. I encounter
this situation frequently when devel-
oping circuits based on new peripheral
chips. I have a desk next to my com-
puter system where I can place a proj-
ect in progress for flash memory pro-
gramming and monitoring via RS-232.
It would be nice at times to check
things out right on my workbench
though. The Serial Sidekick is small
and portable enough for the task.
Miniterminal operation, using the
three different data link methods, is
similar, but there are differences
because of the nature of the individual
protocols. In all cases, data coming
into the Serial Sidekick is displayed on
the LCD panel; you must enter data to
be transmitted via the AT keyboard
attached to the Serial Sidekick.
ASYNCHRONOUS
The instrument handles both TTL and
RS-232 signal levels through the use of
a unique cable for each. When selecting
this mode, first use the rotary encoder to
set the data rate from a predefined list
ranging from 300 to 115,200 bps. I do not
support any hardware handshake signals,
because they generally aren’t used in
MCU-peripheral data links. To ensure
that the instrument doesn’t miss data at
high data rates, I use an interrupt-driven
serial driver combined with a 256-byte
ring buffer, which seems reasonable
for diagnostic purposes.
Most MCUs and peripheral devices
do not use parity bits anymore, so I
didn’t allow for this. The Serial
Sidekick operates strictly in the 1
start bit, 8 data bits, 1 stop bit format.
In Asynchronous mode, there are two
data entry methods: ASCII character
and hex. In the former, whatever is
typed into the keyboard is sent, char-
acter-by-character, to the external
device. Data coming in from the
external device is assumed to be
Figure 4
—
One of the secrets to the simplicity of the Serial Sidekick is its use of a custom cable for each form of
serial data transmission. This eliminates a lot of switching—either mechanical or electronic.
54
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
ASCII data, and is displayed as such.
For a continuous ASCII input stream,
the data is displayed on the LCD until
it is full, at which point it will clear
and continue displaying new data.
Hex mode is used for binary data,
which is needed when communicating
with most peripheral chips. All
incoming data bytes are displayed as
two-digit hex numbers, eight to a line.
At the end of each line, the correspon-
ding ASCII characters are also dis-
played (if printable). To send data,
enter it on the AT keyboard in hex.
Each byte is delimited with the space
bar. Hitting the Enter key during data
entry will abandon the hex number
that you are in the process of entering.
In Hex mode, you have the option of
suspending the real-time display of
incoming data and toggling between
the current and last full screens of
data for closer examination.
To exit either mode, press the
fourth function key, as shown on the
bottom of the LCD.
SPI
In the world of SPI, devices are either
masters or slaves. The Serial Sidekick
can operate in both modes, and that is
the first thing you must specify. Exercise
caution when using this mode to ensure
that only one device is the master,
because the input/output direction of
the four signal lines is determined by
the mode selection. You don’t want two
devices defining a given line as an out-
put, because a conflict will occur and
chips could get damaged. Although I
won’t go into detail about the SPI proto-
col, note that three parameters vary
amongst different peripheral/MCU
chips, and the Serial Sidekick has menus
to select the proper values for them.
The first, MSB/LSB, defines whether
the data transfer starts with the least
significant bit or the most significant
bit. Keep this one in mind, because
there doesn’t seem to be a standard
amongst IC manufacturers.
Secondly, there are four permuta-
tions of the SPI clock polarity/phase.
Different chips support all or a subset
of these four and use different nomen-
clature. Refer to the AVR SPI docu-
mentation for clock waveforms corre-
sponding to the four choices. The
Serial Sidekick is advantageous
because you can freely step through
these four options until you find the
one that works for a given device!
Finally, note that the clock rate
only applies in Master mode; it allows
you to choose different rates based on
an internal divider on the 7.327-MHz
MCU clock. Refer to the ATmega323’s
datasheet for the maximum useable
data rate in Slave mode.
After the aforementioned parameters
are set, you can send and receive data.
In Slave mode, the Serial Sidekick is
strictly a passive monitor: it will dis-
play, in hex, all bytes that are being sent
by the master. Although a slave can also
send data back to the master, if and
when it does depends on the particular
peripheral device and situation. I could
not think of a simple way to implement
the return of such data because it was
so specific to the application.
In Master mode, hex data is entered
via the AT keyboard (using the same for-
mat as in Asynchronous mode) and sent
out 1 byte at a time. In Master mode,
data coming back from the slave is
simultaneously clocked and displayed in
hex on the LCD. For many peripherals,
this means writing a command byte, and
then sending one or more dummy bytes
out to provide the clock pulses to shift in
the expected return data. For instance,
you may write a command byte to an
ADC to set its input channel/start con-
version, and then issue two writes with
dummy data to read back the 16-bit
result. To exit either SPI Master or Slave
mode, press the fourth function key.
I
2
C
Although simple to wire, I
2
C is the
most complicated protocol of the three.
I specifically chose the ATmega323
MCU because lesser members of the
AVR family do not include a hardware
I
2
C port. Acting as an I
2
C slave at high
bus rates requires a hardware port; a
software implementation is too slow.
Like SPI, you must first select the
mode in which you want to operate.
Then, select the desired device
address. In Master mode, it is the
address of the slave device you are
connected to. In Slave mode, it is the
address that you want the Serial
Sidekick to respond to (as a slave).
In I
2
C, the device address ranges from
zero to 127, with the LSB of the address
being the read/write bit (i.e., an I
2
C
device with a base address of 0x40 can
be written to at address 0x40 and read
from at address 0x41). In Master mode,
you have to decide the Serial Sidekick’s
clock rate. This may be adjusted over a
wide range by using the rotary encoder
to cycle through the 8-bit range of clock
divisors available to the hardware I
2
C
port. The actual clock rate (as opposed
to the divisor ratio) is displayed on the
LCD as you adjust the values.
Like the SPI function, the instrument
works somewhat differently in Master
and Slave modes. In the latter, the
instrument will display incoming bytes
in hex on the LCD screen. Because the
Serial Sidekick is only a general-pur-
pose diagnostic device, it has no way of
knowing what to send back to the mas-
ter in response to a read command, so
that function is not implemented.
In Master mode, however, the Serial
Sidekick is in control, and it’s assumed
that you know what to send and when
to read the slave. You enter hex values
in this mode via the AT keyboard
(using the same format as SPI and
Asynchronous modes), corresponding to
the data to be sent. If data must be read
from the slave, press the R key on the AT
keyboard, and one byte will be read from
the Slave. A typical exchange would
involve sending the slave a command
and then hitting the “R” key one time
for each byte of data expected in return.
The instrument displays various
status messages at the bottom of the
LCD, corresponding to the various sta-
tus/error codes returned by the hard-
ware I
2
C port. The ATmega323’s
datasheet lists, in detail, the signifi-
cance of these codes.
Whereas the BASCOM-AVR compil-
er contains routines for both the asyn-
chronous and SPI ports, I had to write
my own assembly language routines
to handle the hardware I
2
C port. I fol-
lowed the guidelines set out in the
ATmega323 datasheet for this routine.
FUTURE ADDITIONS
This project progressed as quickly as
I had expected; however, the firmware
took a lot more time than I had
thought it would. (What else is new?) I
32-KB flash memory, and Bascom AVR
includes one-wire library routines.
As I was writing the article, I start-
ed a small project using a Sony A/V IR
remote control. Therefore, I decided to
add an additional function to Logic
Analyzer mode, which basically lists
on the LCD the number of samples
between each signal transition occur-
ring in a single-sweep data acquisi-
tion. This makes it easy to evaluate
the method of coding used by a partic-
ular IR remote. All that was needed,
56
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
Brian Millier is an instrumentation
engineer in the Chemistry Depart-
ment at Dalhousie University in
Halifax, Canada. He also runs
Computer Interface Consultants. You
may reach him at brian.millier@dal.ca.
RESOURCES
Atmel Corp., “8-bit AVR Microcon-
troller with 32K Bytes of In-System
Programmable Flash: ATmega323/
323L,” rev. 1457E, 2001.
SOURCES
ATmega323 Microcontroller
Atmel Corp.
(408) 441-0311
www.atmel.com
AGM2412B LCD
AZ Displays, Inc.
(949) 360-5830
www.azdisplays.com
DS1077L EconOscillator
Maxim Integrated Products, Inc.
(408) 737-7600
www.maxim-ic.com
BASCOM-AVR Compiler/programmer
MCS Electronics
31 75 6148799
www.mcselec.com
Microchip Technology, Inc.
(480) 792-7200
www.microchip.com
PCF8574 Remote expander
Texas Instruments, Inc.
(800) 336-5236
www.ti.com
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2003/159/.
uncovered bugs in several of the
BASCOM-AVR library routines that I
needed for the project. Luckily, I was
in close contact with the program’s
developer, so these got straightened
out pretty quickly.
Basically, the existing hardware
would easily handle the one-wire pro-
tocol. All that I’d need would be an
additional input cable. I’d have to
expand the firmware to handle this,
but the object code uses up just a bit
more than half of the ATmega323’s
apart from additional firmware, was a
simple cable dedicated for this use, as
shown in Figure 4. You should be
aware that different IR remotes use
one of three common carrier frequen-
cies in the 32- to 48-kHz range. You
may have to choose a different IR
receiver module for your remote. I
hope that you find some of the ideas
used in this instrument useful.
I
Open Frame Power Supplies
Jameco offers a wide selection of open-frame
power supplies suitable for production, pro-
totype and design environments. Be sure to
check out our selection of Artesyn, Mean Well
and dozens of other brands with universal input, PFC
and other features you need on our web site today!
Wall Transformers
We offer a complete selection of AC-to-AC
and AC-to-DC wall transformers for general
purpose and production applications.
Most are UL approved and available
with various power plugs.
Be sure to visit our web site
and learn more.
Low-Noise Fans
Jameco offers hundreds of low-noise fans at
outstanding prices. These agency-approved low-profile
fans feature ball or sleeve bearings so you can be
assured your system will be run-
ning cool for years to come.
Get more details by asking
for a FREE catalog today.
Table-Top Transformers
Outfit your product with a professional table-top
transformer. Jameco offers a wide variety
of configurations with regulated and
unregulated outputs. Don’t forget to ask
for a FREE catalog and learn about our
selection of domestic and international
input power cords.
DC-to-DC Converters
Jameco now offers a wide selection of Isolated
and Point-of-Load DC-to-DC converters suit-
able for distributed power architectures.
Avoid the hassles of “large company”
distribution channels and get immediate
delivery from Jameco today!
219150MC
102955MC
184866MC
155213MC
210809MC
Mfr. Cross
Output Rating
Input
Jameco
Mfr.
Reference No.
(Volts@Current)
(VAC@Hz)
Part No.
Price
Mean Well
S-25-5
+5V@0-5A
85-264@47-63
123246MC
$43.95
Mean Well
S-60-24
+24V@0-2.5A
85-264@47-63
123351MC
57.95
Mean Well
S-150-24
+24V@0-6.5A
88-132/176-264@47-63 123449MC
76.95
Mean Well
SP-300-24
+24V@0-12.5A
88-264@47-63
137402MC
185.95
Power-One
PFC-500-1024
+24V@0.6-21A
85-264@47-63
202905MC
69.95
Mfr. Cross
Output Rating
Jameco
Manufacturer
Reference No.
(Voltage@Current)
Part No.
Price
Skynet
SNP-0502-B
+5V@0-2A
184866MC
$13.49
Artesyn
NLP25-7608
+5V@0.2-2A; +12V@0.1-0.8A;
218501MC
39.95
-12V@0-0.1A
Mean Well
PS-65-24
+24V@0-2.7A
148646MC
33.95
Artesyn
NLP150L-96Q5366
+3.3V@0.5+10A;
219029MC
116.85
+5.1V@1.5-2.0A;
+12V@0-2A;+12V@0-0.65A
Digital Power
USS250-115
+15V@0-16.5A
204564MC
49.95
Mfr. Cross
Output Rating
Size (+0%-20%)
Agency
Jameco
Reference No.
(Volts@Current)
H" x W" x D"
Approvals
Part No.
Price
DC1205F12
+12@500mA
2.5 x 1.9 x 1.6
UL/CSA
102496MC
$4.95
SC102TA1200-B02
+12@1500mA
2.9 x 2.0 x 2.6
UL/CUL
210809MC
12.95
DCR1205F12
+12@500mA
3.2 x 2.2 x 1.9
—
162996MC
8.95
DC1205F5
+12@500mA
2.5 x 2.1 x 1.7
UL/CSA
102277MC
4.95
41-2-15
+12@300mA
2.9 x 2.0 x 1.6
UL/CSA
190043MC
4.49
Mfr. Cross
Power
Output Rating
Input
Size (+0%-20%) Jameco
Reference No.
(W)
(Volts@Current)
(VAC@Hz)
H" x W" x D"
Part No.
Price
SPU50-6
60
+24@2.5A
100-240@47-63
5.6 x 2.9 x 1.6 161605MC $44.95
P40A-3P2JU
40
+12@3.3A
100-240@50-60
5.5 x 2.3 x 1.5 155213MC
34.95
SPU50-3
60
+12@5.0A
100-240@47-63
5.6 x 2.9 x 1.5 155230MC
49.95
KWM12F-P2MU
18
+12@1.5A
100-240@47-63
4.0 x 1.9 x 1.5 216531MC
26.95
P40A6P2J
40
+24@1.66A
100-240@50-60
4.1 x 2.6 x 1.4 181884MC
33.95
Mfr. Cross
Power
Output Rating
Jameco
Mfr.
Reference No.
(W)
(Volts@Current)
Input Range
Part No.
Price
Mean Well SCW03A-05
3.0
+5V@600mA
9-18V
213268MC
$15.49
Mean Well SD-25A-24
26.4
+24@1100mA
9-18V
175812MC
40.95
Mean Well SKE15A-05
15.0
+5V@3000mA
9-18V
155715MC
34.95
Artesyn
SIL06C-05SADJ-V
20.0
+0.9-3.3V@6
4.5-5.5V
219150MC
12.35
Astec
AA9090A
21.0 +5.1V@3750mA;
0-20V
109276MC
6.95
+12.6V@100mA;
-26V@40mA
Mfr. Cross
Voltage Air Flow Noise
Size
Jameco
Mfr.
Reference No.
(VDC)
(CFM)
(dBA)
H" x W" x D"
Part No.
Price
Sunon
KD1208PTB1-6
12
42.5
33.5
3.15 x 3.15 x 1.00
102955MC
$5.25
NMB
3110KL-04W-B10
12
25
25
3.15 x 3.15 x 1.00
131748MC
7.95
Sunon
KD1204PFB2-8
12
6.3
30
1.60 x 1.60 x 0.40
161699MC
7.95
Sunon
KD1212PMB1-6A
12
108
42
4.68 x 4.68 x 1.50
94625MC
11.95
Sunon
KD0504PFB2-8
5
5.5
23
1.60 x 1.60 x 0.40
196373MC
8.49
Closed Frame
Power Supplies
Jameco offers hundreds of closed frame
supplies from the names you trust, all priced to
help you save! Call for a FREE catalog and learn
more about our selection featuring low-leakage
medical supplies, power factor correction,
universal input and much more.
123246MC
We also stock CPU fans.
Visit our web site for a
complete listing.
58
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
Y
ears ago, I wore a Seiko watch
that was both analog and digital. The
watch had a standard watch face with
all of the normal moving hands plus a
tiny LCD that displayed the date and
did double-duty as a stopwatch. At the
time, the good old LED-based watches
had been replaced by the newer and
fancier LCD watches. By wearing my
Seiko, I was opting for the classic look
with the new technology feel.
The LCD-in-watch trend is still
alive and well. There are numerous
watches on the market that are LCD-
enabled and tout a boatload of fea-
tures. I remember when calculator
watches were big. These days, calcula-
tor watches are a no-brainer. Now you
can buy a watch that graphs the phas-
es of the moon and tidal activity in
addition to keeping the time and not-
ing when the sun sets and rises.
There’s even a touch-enabled, LCD-
faced watch out there that runs Linux!
This month’s column is not about
fancy watches; it’s all about LCDs.
My office telephone, cell phone, and
you need to see your LCD module’s
dots in the dark, you can buy an LCD
module with an integral backlight.
The LCD module is a good choice if
you want to easily display multiline
text messages; however, the cost rises
considerably as you add extra lines of
text to the display.
It doesn’t matter if you use LEDs or
an LCD module because in either case
you’ll still need a microcontroller to
complete the job. LCDs and LED dis-
plays both adhere to the first rule of
embedded computing: nothing is free.
Let’s assume you want to display
data as a simple set of between four and
eight numeric digits. The optimal solu-
tion would be an inexpensive electronic
device that includes some smarts and
Simple Data Display
APPLIED PCs
by Fred Eady
pager have one. My Microchip PRO
MATE II device programmer has one.
My VOM has one. My SMT rework
machine has one. Even my atomic
clock (that locks into WWV only
when it feels like it) has one.
Have you ever thought about why
LCDs are so prevalent? The answer is
simple: they’re cheaper to incorporate
than comparable integrated LCD mod-
ules and multiplexed LED display
solutions.
I’m willing to bet that you have
constructed some sort of a multiple-
digit LED display. If you haven’t but
want to, start by collecting the desired
number of individual LED digits, add
seven or eight current-limiting resis-
tors for each digit, and select a suit-
able digit segment driver
that can handle the cur-
rent drawn by the collec-
tion of LED segments on
each digit. Then, choose a
suitable microcontroller
to drive the LED/resis-
tor/driver display rig. If
you need more than a
couple of digits, you’re
also going to need multi-
plexing firmware to drive
your LED display.
If you don’t require
huge and bright digits,
another approach would
be to use a standard LCD
module, which includes
all of the necessary driver
circuitry and LCD glass
in a compact package. If
Thinking about incorporating an LCD in your next design? It isn’t too difficult, especially if all
you’re looking to do is display your data as a set of numeric digits. Follow along as Fred
shows you how Microchip and Atmel can help you drive a simple data display.
SEG0
SEG1
Engergized
LCD segment
Non-engergized
LCD segment
Segment line 1
Segment line 0
Common terminal 0
Figure 1
—
An LCD operating in Static Duty mode is much
like its LED counterpart, because a different segment
driver addresses each display segment individually.
Driving LCDs with Microchip and Atmel Micros
Photo 1
—
Although the Microchip PICDEM-3 development board was
designed years earlier, both the Atmel and Microchip boards contain sim-
ilar features. For instance, the boards come equipped with a 32-kHz
external oscillator, a thermistor, several general-purpose push buttons,
and an external LCD port.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
59
the circuitry necessary to drive the
LCD glass. Fortunately, that technolo-
gy is already walking the streets.
DRIVING MISS LCD
If you’ve worked with any of Micro-
chip’s PICs or Atmel’s AVRs, you’ve
already done the datasheet drill that
describes the core functionality of a PIC
and an AVR. Because the PIC16C923,
PIC16C924, PIC16C925, PIC16C926,
and ATmega169 are all about driving
LCD segments, it may be a good idea to
take a look at what it takes to make a
typical LCD work before I dive into
the specifics of what it takes to micro-
controller-enable an LCD.
The term “LCD glass” refers to two
glass plates that contain and support a
layer of liquid crystal material. Liquid
crystals are rod-shaped molecules that
flow as a liquid; they use their electri-
cal and optical properties to actually
bend light. The inner surfaces of the
glass plates are lined with transparent
electrodes, which are patterned to
form the images that are to be
displayed by the LCD. The
outer surfaces of the glass
plates are fitted with polarizers,
which are placed perpendicular
to each other and parallel to
the liquid crystal rods.
The liquid crystal material
has many layers of molecules.
Each glass is rubbed with a
polyimide coating that aligns
the liquid crystal material clos-
est to the glass with the polar-
izer. Because the polarizers are
90° out of phase with each
other, the layers of liquid crystal
material actually twist between
the upper and lower glass.
The best way I can explain
the polarizer/liquid crystal rela-
tionship is to recall a childhood
memory. Remember when the
first polarized sunglasses came
out? No? Well, I do. If you
take the polarized lenses and
look through them with one
lens behind the other, you
can rotate one of the lenses
until the light is blocked and
you can’t see through the back-
to-back set of lenses. LCDs
work in a similar manner.
When the liquid crystals are not
excited, they twist the light and allow
it to pass unimpeded through the out-
of-phase polarizing filters. In the
unexcited state, you see the normal
background color of the LCD glass.
This unexcited state is relative to
holding both of the polarized sunglass
lenses back-to-back so you can see
through them.
If the liquid crystals become excited,
or energized, the molecules within the
liquid crystals align themselves with
the electric field and fail to twist the
light. In this case, the polarizers
are out-of-phase and the light is
not bent. Thus, the light cannot
pass through the second polariz-
er filter. This is analogous to
rotating one of the polarized
sunglass lenses 90° and bringing
the lenses out of phase and
blocking the light. The absence
of light appears as a darkened
spot on the LCD glass.
Unlike standard LED dis-
plays, which are driven by
applying a DC voltage across
each desired digit segment’s
anode and cathode, LCD glass
must be driven by an alternat-
ing current. Each segment in an
LCD connects to the driver on
one side of the segment and to a
common terminal on the other
side. Applying the AC across
the segment driver and the
common terminal excites the
liquid crystal causing the seg-
ment’s liquid crystal molecules
to twist in such a way as to
allow the segment to be visible.
Even for a Cyclops, more
than one segment is needed to
make a programmable display.
So, there has to be a process
Frame
Frame
Frame
Frame
V
LCD
GND
V
LCD
GND
V
LCD
GND
–V
LCD
SEG0
COM0
SEG0–COM0
V
LCD
GND
V
LCD
GND
GND
SEG1
COM0
SEG1–COM0
Figure 2—
The resultant voltage across a segment is the difference between the segment voltage and the common
terminal voltage. Note that the sum of the voltages across the segment in each frame is equal to zero.
One frame
BP0–SEG1
BP0–SEG0
SEG1
SEG0
BP0
BP1
BP2
BP3
COM3
COM2
COM1
COM0
SEG1
SEG0
V
3
V
2
V
1
V
0
V
3
V
2
V
1
V
0
V
3
V
2
V
1
V
0
V
3
V
2
V
1
V
0
V
3
V
2
V
1
V
0
V
3
V
2
V
1
V
0
V
3
V
2
V
1
V
0
–V
2
–V
3
–V
1
V
3
V
2
V
1
V
0
–V
2
–V
3
–V
1
Figure 3
—
This particular LCD glass contains four common terminals, which
implies four backplanes. Note that only a single segment driver is required
to drive up to four segments.
60
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
that determines which segments are
visible and at what time. On a typical
LCD, the LCD segments must be
excited more than 30 times per second
to keep you from seeing them flicker.
The number of times per second the
LCD segments are excited is called
the frame rate. LCD segments cannot
turn on or turn off instantaneously.
So, if the frame rate is too high, the
segments will appear to ghost,
because the segments aren’t given
enough time to turn off completely
before being excited again. The ghost-
ing usually occurs when the frame
rate exceeds 100 frames per second.
The theory behind the LCD frame
rate is akin to video frames. Both use
the human eye and brain image per-
sistence phenomenon to fool you into
seeing a bunch of really fast flickers as
smooth motion.
There are a couple of ways to drive
a collection of LCD segments. If all of
the LCD segments are tied to a single
common terminal with separate seg-
ment driver lines for each individual
segment, then you have a static
arrangement (see Figure 1).
Each segment must be driven above
its threshold voltage to excite the liq-
uid crystal molecules with the highest
voltage applied falling equal to or below
the maximum voltage specifications
set forth for the LCD glass segments.
Applying a DC voltage to an LCD seg-
ment will either end or shorten the life
of the segment, because the DC voltage
will eventually cause the liquid crystal
material to lose its excitability. For that
reason, the LCD driver waveforms are
designed to provide a potential across
the LCD segments that is as close as
possible to 0 VDC.
In a static segment arrangement,
square waves are normally used to
drive the common terminal and seg-
ments. Segments that are excited are
driven in opposite phase of the com-
mon terminal. If the segment and com-
mon drive signals are in phase, the seg-
ment is not excited. Figure 2 depicts
the segment and common terminal
drive signals and how they affect the
segments of a statically driven LCD.
A static LCD glass with one com-
mon terminal has only a one back-
plane and runs with a duty cycle of
1/1. Duty cycle is defined as one divid-
ed by the number of segments driven
by each LCD driver, or one divided by
the number of common terminals.
An example of LCD glass capable of
running at a one-fourth duty cycle is
shown in Figure 3. Each segment driv-
er drives four segments, each of which
is driven by a separate backplane
(common terminal). To control each
segment from a single segment driver,
the segment driver must be able to
generate multiple voltage levels. The
number of voltage levels is associated
with the drive bias. Mathematically,
drive bias is one divided by the num-
ber of voltage levels minus one:
Therefore, the drive bias for the LCD
glass in Figure 3 would be 1/3, and the
drive bias for the LCD glass in Figure 1
would be 1/1.
You don’t have to guess about how
to set the duty and bias parameters.
The LCD recommended duty cycle
and drive bias settings are normally
called out in the LCD’s datasheet.
Some LCD datasheets also provide a
recommended frame rate.
DO THE TWIST
I love my job. In the process of
researching and writing this column, I
collected a bunch of goodies to play
with. I have a Microchip PICDEM-3
PIC16C9xxx development board, an
Atmel STK502 development module,
and an assortment of static and multi-
plexed LCD glass. The Microchip parts
aren’t flash memory-based, so I’ve got
to churn and burn when I develop
code for the Microchip LCD microcon-
troller. Thus, I pulled out my fancy
UV eraser and obtained a PIC16C9xx
68-pin PLCC programmer socket for
my PRO MATE II. I hate waiting for
UV parts to erase between spins. So,
to keep myself busy, I procured a cou-
ple of extra PIC16C924/CL and
PIC16C925/CL UV erasable devices.
I’m also fully covered on the Atmel
side. The ATmega169 is flash memory-
based and can be programmed and
debugged using the latest version of
AVR Studio and JTAG ICE. If I don’t
run into trouble coding the AVR, I can
use the STK500 development board
that supports the STK502 to program
the ATmega169 firmware spins. I gath-
ered my family of LCD development
1
1
Number of voltage levels
−
Figure 4—
Although there appears to be a million pins on the headers and LCD glass, after laying out everything
on a spreadsheet the process of hooking up everything was simple.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
61
tools together to produce Photo 1.
The Atmel STK502 and Microchip
PICDEM-3 both come with their own
specialized LCD glass. You can actual-
ly buy the Atmel LCD glass from a
company in Norway, but the
Microchip PICDEM-3 LCD is not a
commercial, off-the-shelf product. Just
as LCD glass is common to both
development boards, the STK502 and
PICDEM-3 are equipped with tempera-
ture sensors that are used by demo
programs that come with each board.
The STK502 holds the ATmega169 in
place with the same type of ZIF socket
used on the STK501 to hold the
Atmega128 microcontroller. A stan-
dard through-hole, 68-pin PLCC sock-
et supports the PIC16C924/CL on the
PICDEM-3.
As you’d expect, both LCD micro-
controllers are filled with demo code
and are ready to run right out of the
box. In addition, both development
kits are supplied with ample example
source code that is focused on driving
the LCD glass.
An LCD demultiplexer driven by a
separate PIC16C73 is an interesting
aside to the Microchip LCD board. The
extra PIC is programmed to demulti-
plex the LCD glass signals produced by
the on-board PIC16C924 and display
them using a special segment versus
the common terminal display program
that runs on a PC host. Basically, the
PC host program/PIC hardware demul-
tiplexer combination tells you which
segments are energized on which LCD
backplane in real time.
After absorbing the various
ATmega169 and Microchip
PIC16C92x datasheets, application
notes, and development board user
guides, I was ready to “do the twist.”
Fortunately, the minds of both the
Atmel and Microchip LCD develop-
ment board designers roll in the same
silicon gutter because both boards
make provisions for attaching external
LCD glass. The Atmel board uses a
ribbon cable and headers to connect
the ATmega169 to the LCD glass. So,
all I have to do is to remove the 34-pin
ribbon cable and I’ve got direct access
to the pins of the ATmega169 and the
STK502 LCD glass. The PICDEM-3
also provides direct access to its on-
board LCD glass and PIC via a 34-pin
ribbon cable.
Normally, the shelves in the Florida
room have all of the necessary compil-
ers to morph any development kit
example code into a real-world appli-
cation. Although the STK502 source
says it can be compiled with either
Listing 1
—
Each element in the character table is made up of three 3-bit values. The 3-bit values are
mapped into the segment matrix of each digit. The data doesn’t actually get to the microcontroller’s LCD
segment registers until all is well inside the LCD frame interrupt service routine. A detailed look at how the
segments map to the character table can be found in the VIMLCD.xls spreadsheet, which you may down-
load from the Circuit Cellar ftp site.
//The look-up table is used when converting ASCII to LCD data
//(segment control)
int16 const LCD_character_table[] = //Character definitions table.
{
0x0257,
//0
0x0044,
//1
0x0236,
//2
0x0266,
//3
0x0065,
//4
0x0263,
//5
0x0273,
//6
0x0046,
//7
0x0277,
//8
0x0267,
//9
0x0077,
//A
0x0271,
//b
0x0213,
//C
0x0274,
//d
0x0233,
//E
0x0033,
//F
0x0000
//Space
};
#int_LCD
LCD_isr()
{
unsigned char i;
unsigned char *dest;
LCD_timer--;
if( LCD_timer == 0 )
{
if( LCD_status.updateRequired == TRUE )
{
LCD_timer = LCD_TIMER_SEED;
LCD_status.updateComplete = TRUE;
//Set the ucLCD_ScrollReady to true.
//Copy the display data buffer to I/O segment registers.
dest = &LCDD00;
for(i=0;i<LCD_REGISTER_COUNT;++i)
{
*dest++ = LCD_displayData[i];
}
}
else
{
LCD_timer = 1; //If the LCD timer allows the updating of the
//LCD but the update is blocked by LCD_status.
//updateRequired == FALSE, the LCD_timer is pre-
//loaded with the smallest timer seed to ensure
//fastest LCD update.
LCD_status.updateComplete = FALSE;
//Block for further access to the LCD_displayData until the LCD
//update has been performed.
}
}
}
62
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
the ICCAVR C compiler or the IAR C
compiler, the former choked badly
when I tried to compile the raw
STK502 source code that is provided
with the Atmel development board.
After some investigation, I found
that one of the include files was miss-
ing from the source code package. The
PICDEM-3 files are PIC assembler and
would have to be ported to C for use
in either the Microchip or Custom
Computer Services PIC C compilers.
My preference of C over assembler in
this case is justified by the easy
manipulation of tables and 16-bit val-
ues made possible by functions built
into the C compiler packages.
The good news is that the suggested
code formats and compiler types used
by the LCD development kits don’t
matter, because I’ve decided to use
the best ideas from both of the LCD
development board source code
libraries to turn on some LCD seg-
ments of my own. I knew this project
was off to a good start when I opened
my flock of LCD glass. There were
five LCDs inside an antistatic bag
with their pins punched into a piece
of Styrofoam. A thin layer of standard
foam covered all the LCDs to protect
their top glass surfaces. I removed the
LCDs from the bag and lifted the
foam layer to peek at the devices. As I
peeled away the foam, every device
turned on the segments to produce a
visible one. I was already successfully
turning on segments and I hadn’t even
taken the LCD glass out of the pack-
ing material yet!
BENDING LCD CODE
The first order of business is to gath-
er the specifications of the LCD glass
and set up the LCD driver devices
accordingly. I have static and multi-
plexed parts made by Varitronix. The
static LCD is a VI-422-DP-RC-S and
the multiplexed display is identified as
VIM-404-DP-RC-S-HV. The “M” fol-
lowing the “VI” denotes that the LCD
is multiplexed, which implies multi-
ple common terminals. Both displays
are instrument displays (VI) using
standard Twist Nematic, or TN, liq-
uid-crystal fluid (S) with commercial
reflective polarizers (RC) in a dual in-
line package (DP). The “HV” parame-
ter in the multiplexed display part
number specifies that the LCD is able
to operate at a higher typical operating
voltage than the static display.
The multiplexed VIM-404 has three
common terminals. Applying the duty
cycle formula gave me an LCD duty
cycle value of one-third. Because there
are three common terminals, you
know that each segment driver will
drive a maximum of three segments;
therefore, it will take four voltage lev-
els to drive the three segments.
Applying the drive bias formula gen-
erates a resultant bias value of one-
third. The Atmel and Microchip LCD
microcontrollers support my LCD’s
required duty cycle and drive bias. The
PIC16C924 drives up to 30 segments
with three backplanes, and the
ATmega169 drives up to 25 segments
on three backplanes. The VIM-404 has
a total of 33 segments. With each seg-
ment driver handling up to three seg-
ments, the VIM-404 uses only 12 seg-
ment drivers.
www.circuitcellar.com
Issue 159 October 2003
63
CIRCUIT CELLAR
®
Things are a bit different
for the VI-422; it too has
33 total segments. The
PIC16C924 can drive a maxi-
mum of only 32 segments
with a single backplane, and
the ATmega169 is maxed out
at 25 segments, which sim-
ply means I cannot exploit
the entire segment farm on
the VI-422 with either LCD
microcontroller. That’s not a
showstopper. Regardless of
how many segments I can or
cannot drive, it takes 36 con-
nections to tie in all of the
segments of the statically
driven VI-422 versus 15 connections
for the multiplexed VIM-404. The VI-
422 is wired one segment to one LCD
driver and doesn’t require a lot of
thinking to implement. I’ll concen-
trate on showing you how to imple-
ment the VIM model.
The connections from the develop-
ment board to the external LCD glass
hardware are shown in Figure 4. I also
created an Excel spreadsheet that
are generated, both LCD
driver microcontrollers ulti-
mately do the same job by
using a similar internal
LCD data register setup.
Both microcontrollers have
similar LCD register memo-
ry maps. This similarity
allows me to leverage the
Atmel example code on the
Microchip and Atmel devel-
opment boards. The Atmel
example code is easy to
alter (it’s already in C for-
mat), so I adapted the exist-
ing Atmel example code to
drive a four-digit and an
eight-digit LCD using the Microchip
PICDEM-3 electronics.
The Atmel C example code loads
an image of the segment buffer mem-
ory into an SRAM buffer and trans-
fers the bit image from the SRAM to
the actual segment memory during a
frame interrupt. The frame interrupt
occurs at the beginning of every
frame. There are flags within the
frame interrupt service routine that
details the VIM-404 and VIM-808
pinouts, the PIC16C924 segment
memory layouts, the LCD character
maps, the VIM segment-to-
PIC16C924 segment driver combina-
tions, and the initial LCD module
register settings. You may download
the spreadsheet from the Circuit
Cellar
ftp site.
Despite some internal and external
differences in how the LCD voltages
Photo 2
—
Lots of information had to be assimilated to put numbers on the displays.
Although the schematic has enough graphical information to allow you to build the
display interfaces, a glance at the Excel spreadsheets exposes the logic behind it all.
64
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
can be set up to enable or prevent the
SRAM-based segment buffer contents
to be written to the LCD segment reg-
isters during the execution of the
interrupt service routine.
The nature of an LCD segment
doesn’t allow it to bend light instanta-
neously, and the VIM-404/808
datasheets reflect this by specifying a
typical 80-ms response time at room
temperature. Obviously, the LCD can-
not be updated at every frame inter-
rupt, so a timer routine is used to
determine how often the LCD actual-
ly gets updated from within the frame
interrupt service routine.
In addition to having a similar LCD
segment memory map, the PIC16C924
also issues an interrupt at the begin-
ning of a frame. You know where I’m
going with this idea. I’m going to use
the Atmel code as well as its logic to
write the PIC code just as if I were
writing the code for the Atmel part.
Some of the ported Atmel code is
shown in Listing 1. I’ll post the entire
port on the Circuit Cellar ftp site
along with the Excel spreadsheet.
CLEARING THE LCD
Although Photo 2 measures my
success in numbers, it’s time to stop
twisting code and light, and wrap up
this piece on driving LCDs.
Documenting the relationships
between the LCD segments, the
microcontroller segment drivers, and
microcontroller segment memory
using a spreadsheet amplified the
extent of the well-thought-out logic
that went into the design of the LCDs
and LCD microcontrollers. By incor-
porating ideas from a set of LCD
development boards, I’ve proven that
driving LCDs isn’t complicated, no
matter which embedded LCD micro-
controller you choose.
I
SOURCES
STK502 LCD Display
ACTE
www.acte.no
VIM-404 and VIM-808 Displays
Varitronix International
(852) 2197-6000
www.varitronix.com
PROJECT FILES
To download the code and spread-
sheet, go to ftp.circuitcellar.com/
pub/Circuit_Cellar/2003/159.
Fred Eady has more than 20 years of
experience as a systems engineer. He
has worked with computers and
communication systems large and
small, simple and complex. His forte
is embedded-systems design and
communications. Fred may be
reached at fred@edtp.com.
Visit us on the web www.jkmicro.com
Call 530-297-6073 Fax 530-297-6074
512K Flash plus DIP socket to accept an M-Systems DiskOnChip.
Development systems contain necessary hardware and software tools for fast development.
66
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
Y
ou’d think that after years of indoor
plumbing we’d be rid of drippy faucets
and leaky toilets. Most valves and shut-
offs use rubber or plastic washers and
seals to block the flow of our most pre-
cious commodity. Trouble looms when
these manmade materials ultimately
deteriorate to the point of allowing water
molecules to pass a restricted area. Of
course, it isn’t until nighttime that the
hustle and bustle of activity settles to a
level that makes the trouble annoying:
boink, boink, boink, boink. Arghhh!
If you think a dripping faucet can’t
amount to much, try plugging the drain.
By the next morning, you could have a
couple quarts of water in your basin. The
point is that drips eventually produce
gallons—you just need to have patience.
This fact supports this month’s project.
No, this isn’t a plumbing project; in fact,
it has nothing to do with water at all.
Recently, I was flipping through the
Digi-Key catalog in an effort to collect
items for my weekly Internet order.
(Although many old-timers would
liken the Digi-Key catalog to the Sears
catalog, I don’t keep my copy in the
outhouse.) I noticed a number of tri-
color LEDs. It’s been awhile since the
first blue LEDs were released, which
naturally led to the combining of sep-
arate color LEDs to produce white
ones. (I use a white LED flashlight for
camping and have yet to replace the
batteries.) Tricolor LEDs are fascinat-
ing because you can produce any color
of the rainbow from a single device.
When I thought about the point
source of light that emanates from an
a voltage source greater than the highest
forward drop (4.6 V). Well, so much for
using a 3-V coin cell. Actually, there are
additional problems with a coin cell.
LiMnO
2
A typical 3-V lithium manganese diox-
ide coin cell (e.g., the CR2032) has a
200-mAh capacity, but the maximum
suggested constant current draw is
approximately 200 µA. Using a single
coin cell would require not only boosting
the voltage but also asking for more cur-
rent than the cell could produce. Enter
the dripping faucet. Maybe there is a way
to collect a trickle of current and open
the floodgates when the sink is full!
AN EIGHT-PIN BRAIN
I chose the eight-pin PIC12F675 for
this project (as if jewelry needs a brain).
The microcontroller gives me the abili-
ty to control which colors are enabled,
which effectively allows the LED to
become any color and enhances the
visual effect of the dangling strobes.
If three I/Os are necessary for con-
trolling the LEDs, and if power and
ground are required for the micro-
controller, three potentially unused
I/Os are leftover. If an external res-
onator is used to clock the micro-
controller, the remaining I/O can
only be used as a digital input.
I chose the PIC12F675 because it has
a 10-bit A/D converter for charge moni-
toring. It also features an internal R/C
oscillator, which can release two I/Os
for general use. The internal RC oscilla-
tor runs at approximately 4 MHz, and
Designing with RGB LEDs
FROM THE BENCH by Jeff
Bachiochi
SMT device, I thought of the dazzling
display a diamond generates in sunlight.
Jewelry is about the only thing that
comes to mind when I think about dia-
monds. Thus, I challenged myself to
create jewelry using an RGB LED. After
tossing around the idea for a couple of
days, I decided to develop a pair of ear-
rings. I figured that I had seen weirder
objects dangling from my wife’s ears,
so as long as I could keep the weight
down, this project would have a chance.
SMT RAINBOW
The first component I selected was the
Sharp GM5WA06250A, which is a RGB
leadless chip LED (5 mm × 6 mm). Six
contacts allow for individual connections
to the anode and cathode of each of the
three red, green, and blue LEDs. The typ-
ical forward voltage drop of each LED is
different: red is at 2.3 V; green is at 4.4 V;
and blue is at 4.6 V. Each is rated at a 50-
mA maximum current (80 mA
P
pulsed).
To light this glowing wonder, I needed
With an 8-bit microcontroller driving an inexpensive RGB LED, you can bring nearly any
color of the rainbow to your next project. Jeff chose a PIC12F675 for his innovative design.
In this article, he explains everything, including the simple code you’ll need to get started.
Photo 1—
A smart shopper knows a unique gift when he or
she sees one. Where is the matching tie tac?
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
67
voltage doubler using components
C4, D1a, D1b, R7, and C1.
Without a clock, D1a/b supplies a
path for the 3-V coin battery voltage
to charge C1 through R7. The R7 × C1
charging time is 1.024 s (4700
Ω
×
0.00022 F). The maximum current from
the battery is 368 µA, which I derived
by dividing 3 V by 4700
Ω
. This drops
rapidly as the charge creeps up to 3 V
on C1. By using the microcontroller’s
I/O to apply a 3-V clock through C4, an
additional 3 V of charging voltage can
be applied to C1 through the same cur-
rent-limiting resistor, R7. Diode D1b
keeps the charging current from leaking
back into the charging circuit.
Notice that C1 is the power source
for the LEDs. Each LED can be ground-
ed by one of the microcontroller’s open
collector outputs being driven to
ground. When C1 is charging, the out-
puts are placed in Input mode to keep
the path to ground open.
DOUBLE DUTY
Using the last output to charge C1
to a voltage high enough to operate
the RGB LED is a good thing. If only I
had another pin to use as an A/D
input, I could have monitored the
charge on C1 and determined when it
was possible to enable the LED.
As you can see in Figure 1, the micro-
controller’s pin can be multiplexed not
only to perform the output function, but
also to occasionally read the voltage on
the R2/R3 voltage divider. Periodically,
the clock function is halted and the pin
is redefined as an analog input. The
voltage divider reflects half of the
charged voltage. The A/D reference is
the 3-V coin battery, so the ADC would
read a maximum value when the charge
on C1 reaches two times the battery
voltage. With the circuit limitations
(diode drops and such), the charge will
never reach two times the theoretical
value. A value of something other than
the maximum will be used to determine
a total charge and a point at which the
LED can be connected to C1.
There are designs without microcon-
trollers that can flash an LED, however,
the addition of a microcontroller allows
for the individual (yet coordinating)
control over the discrete devices within
the LED. Now let’s take a look at the
miniscule coding for this project.
THE “JEWEL” IN JEWELRY
For this project to shine, you’ll need
a small amount of code. The flow chart
in Figure 2 will help you understand it.
After the initialization of the micro-
controller’s I/O and internal peripher-
als, the code enters a simple loop that
the supply current is nearly 500 µA at
the proposed 3-V coin battery voltage.
Whoa. Although this is relatively low,
the project cannot afford this operating
current if you want to have current left-
over for the LED. Fortunately, the micro-
controller is a CMOS design, and current
consumption is relative to its operating
speed. Operating at a reduced frequency
can reduce the current consumption.
Going back to an external resonator
would require giving up the last two
I/Os necessary for the project. Using
the R/C oscillator with external R/C
components would allow for a lower
operating frequency and produce one
I/O to play with, which seemed like a
reasonable compromise.
OK, so let’s recount the available I/O:
power, ground, R/C oscillator input,
and three LED outputs. That leaves one
digital input and one digital I/O (with
an alternate A/D input function). I
needed two more functions: a clock
output to be used as a voltage doubler
and an A/D input to measure the accu-
mulated charge. Note that the digital
input is useless for both functions!
DOUBLE OR NOTHING
If you don’t have double the 3-V
coin battery voltage, the entire project
will fall apart. Refer to the schematic
in Figure 1 to see how the last I/O is
used as a clock output to create a
Figure 1—
The microcontroller uses slow external RC timing to reduce its current consumption to below 50 µA. A
code-generated clock output on GP0 is used to pump up the charge on C1 to almost double BAT1. GP0 is also
used to measure the charge on C1 to determine when to enable the LEDs. These are enabled by reconfiguring
GP1/2/4 as outputs (grounding the LEDs).
Power
on
Initialize
Define SAMP
as output
Toggle SAMP
256 times
(double clock)
Define SAMP
as analog input
Get an A/D
conversion
A/D value >
charged
point?
A/D value <
charged
point?
Get LED mask
from EEPROM
–
Enable appropriate
RGB outputs
Get an A/D
conversion
Disable
appropriate RGB
outputs
Figure 2—
The requirements for the code pro-
grammed into the PIC12F675 are simple. The code
loop consists of four basic parts: clock generation,
checking for a charged condition, enabling selected
colors, and checking for a discharged condition.
PROJECT FILES
To download the code, go to ftp.cir-
cuitcellar.com/pub/Circuit_Cellar/
2003/159.
SOURCES
GM5WA06250A RGB LED
Sharp Electronics Corp.
www.sharp-usa.com
PIC12F675 Microcontroller
Microchip Technology, Inc.
www.microchip.com
Jeff Bachiochi (pronounced BAH-key-
AH-key) has been writing for
Circuit
Cellar since 1988. His background
includes product design and manu-
facturing. He may be reached at
jeff.bachiochi@circuitcellar.com.
68
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
reduced to approximately 200 µA as
C1 approaches a full charge.
ALL THAT GLITTERS
You may think that this jewelry
project is hammered from gold bullion
because the onesies (actually twosies)
costs are quite high. Ignoring the cost
of PCBs, the three most expensive
parts are the RGB LED ($6.25), charge
capacitor ($4.63), and microcontroller
($2.08). And don’t forget, earrings nor-
mally come in pairs (see Photo 1).
Actually, the coin batteries (CR2032)
are a pretty good deal. You can replace
both of them for about $1!
I can’t predict how often my wife
Beverly will want to wear these things,
but they will definitely cause conver-
sation. As for me, they will always
remind me of dripping faucets.
I
begins with a charging phase. The SAMP
pin is defined as output, and the logic
state of the output is toggled 256 times
in a loop. At that point, the SAMP pin
is redefined as an analog input and the
charge on C1 is read via the voltage
divider R2/R3. If the charge is not high
enough, the charging cycle repeats. If
the charge is sufficient, the code pro-
ceeds to the discharging phase. Figure 3
shows a timing diagram of the charging
phase, which includes A/D sampling
and the discharging phase.
A table of all possible color combina-
tions is stored in available EEPROM.
The last 3 bits of Timer0 (free-running)
are used to pick one of the combina-
tions from the EEPROM. Timer0 acts
as a random number generator because
the timing between discharges is a rela-
tively random occurrence.
The values stored in the internal EEP-
ROM are actually masks for the GPIO
and can be used to enable the colored
devices selected within the LED and
begin the discharging phase. After the
LED is enabled, the series resistors con-
trol the initial intensity (and the dis-
charge timing). The charge on C1 is read
via the voltage divider R2/R3, looking
again for the discharge point. There is
no sense in fully discharging C1, so after
the voltage has fallen below a selected
threshold, the discharge cycle is termi-
nated and the charging phase restarts.
The initial charging of capacitor C1
takes roughly 60 s. Subsequent
recharges require approximately 30 s. I
found a slight leakage of the red LED
because of the low forward voltage drop
(2.3 V). I added a couple of diodes in
series with the red LED to more closely
resemble that of the blue and green
LEDs. You can trim the intensity of the
colors by adjusting the values of R4, R5,
and R6; however, the GM5WA06250A
is pretty well matched and produces a
good white color when all the LEDs are
enabled with identical currents.
Although there are eight possible
combinations, the “none” combin-
ation isn’t used for obvious reasons.
Therefore, besides the red, green, and
blue colors, the dual colors include yel-
low, violet, and aqua along with tricol-
or white. Measured current consump-
tion tops out at approximately 500 µA
during the initial charging. This is
Charging cycle (LEDs disabled)
~800-µs
Sample time
Discharge cycle
(LEDs enabled)
40–100 ms
256 Cycles
at 3.5 kHz
Figure 3—
Although not to scale, the timing diagram
shows the charging cycle, which consists of alternating
charge pump clocks and A/D sampling. The discharge
cycle timing depends on the number (one, two, or
three!) of LEDs that are enabled.
CANbus
Starter Packs
available for almost
any board format: PCI, ISA, PCMCIA, PC104,
VME, cPCI, etc. with software for most OS’s
inc. all Windows, Linux, QNIX, etc.
CAN/Ethernet bridges, industrial
computing and automation solutions
Industry leaders worldwide trust and
specify Janz AG’s ISO9000 systems.
Janz AG - a leading CANbus supplier.
ALSO:
S C A L A B L E L E D D I S P L A Y P A N E L S , TEMP-HUMIDITY
MONITORS, T H E R M O C O U P L E P . C . A D A P T E R S , ENVIRONMENT
MONITORING SYSTEMS, EDUCATIONAL SCIENCE PROJECTS,
GRAPHICS SOFTARE, AutoCAD PROGRAMMING COURSE, USB-PIC
BOARDS, FLASH PROGRAMMERS - IF YOU DON’T SEE WHAT YOU
NEED MAYBE WE CAN FIND IT FOR YOU? - JUST ASK FOR ALAN!
by
Janz
for
all
computers
Saelig Co. brings to USA unique, easy-to-use control and
instrumentation products from overseas. Customers inc:
Intel, Philips, NEC, Kodak, Nokia, US Military, Microsoft,
Dell, Xerox, Universities, T.I., Harris, Sony, J&J,
Thomson, Sandisk, General Dynamics, H-P/Compaq, e t c .
Industrial PCs
Turn your PC into a high-
speed scope. Sampling
rates up to 100MS/s for sin-
gle shot signals (and up to
5GS/s for repetitive signals)
with 12-bit resolution. With
FREE software, your PC
becomes a powerful 2-chan-
nel scope and spectrum
analyzer.
ADC-212/100
$1090
US232 is a 6ft USB-RS232
self-powered converter
cable which instantly and
reliably solves the problem
of laptops with no serial
ports, or legacy RS232
devices that need to be
updated to USB
IN ONLY 5
MINUTES!
Buy in bulk to
update your products - $39!
"After looking at a number of packages
both large and small we have found
TRAKIT
TM
to be the most cost effective
solution for inventory management in the
manufacturing environment available for
the small to medium size company. It
contains most of the commonly used
features of the larger programs as well as
maintaining the user ease of the smaller
programs. Some of the more advanced
features of Trakit are more successfully
implemented than packages costing
many times more. Better and easier to
use than P&V" (S.P. Ltd)
TRAKIT
manufacturing
- Inventory Management
- Bills of Materials
- Build Schedule
- Sales Orders
- Instant Builds
- Purchase Ordering
- Request for Quote
- Reminders
- Reports
K2
9p-9p self-powered RS-422/485 converter
K3
9p-9p isolated RS-422/485 converter
K3-232
9p-9p isolated RS232 converter
K232-ISOL
25p -25p RS232
K422-ISOL
25p -25p RS422
K485-ISOL
25p -25p RS485
KD485-STD
DINrail-mount
RS-232/485/20mA isolators
KD485-PROG
DINrail-mount
RS-232/485/20mA isolators
C-programmable for protocol/MODbus
conversion. Program to convert custom needs.
USB-485i offers self-
powered USB to RS485
conversion with optical
isolation to 1kV. Baud
rates 184bps - 3Mbps.
Link-selectable half-duplex
mode enables the 485
transmit-buffer when data
ready. Three-point isolated
serial communciations.
200 kS/s 12-bit dual-channel USB scope adapter for
PC. Unique software looks like a “Digital Scope” right
on your PC screen! Built-in
squarewave generator.
Weighs less than 8oz so
you can take it anywhere.
Only $189!! For details:
www.usb-instruments.com
USB protocol analyzer displays USB packets sent,
decodes descriptors, detects errors in peripherals or
drivers and measures their performance.
Ideal for anyone developing
USB peripherals,
embedded soft-
ware or drivers.
Software is easy
to use - learn all
about USB. $799!
Make PCs talk I2C easily with this industry-standard
card, available in 2 - 6V bus version for low-volt I2C
systems. Optional WINI2C/PCI software gives you a
windows-interface to develop
and debug I2C bus systems.
Monitor software lets you
transparently monitor I2C bus
activity .
NEW - USB VERSION
UCA93LV: 400kHz monitoring!
Build a custom PCMCIA or CF
card datalogger or controller
- quickly!
Wizard high-level
software completes your
project in hours not weeks.
Store GPS or CANbus data.
TDS2020F is the low-power
controller of choice for sure
LONGEVITY - this one won’t
disappear like so many other
obsolete boards. Ask us why!
Join all the industry leaders who are using this easy-use
USB ic. Single chip USB-232 solution comes with all
Windows/Mac/Linux drivers. UART ASIC-based so no
software development is needed!
Euroquartz is one Europe’s largest manufacturers and
supplier of quartz crystals, oscillators, filters and
frequency-related products. They design & manufacture
a comprehensive range of frequency-related components
including custom-made filters, high
reliability oscillators for defence
applications and radiation tolerant
oscillators for high-altitude apps.
EQ-HM oscillators reduce EMI using
Spread Spectrum Technology
to slowly shift center frequency.
Easily construct small control systems communicating
through Intranet/Internet. BIT2000 is the ideal solution
for process control, building
monitoring, data logging,
alarm systems and other
industrial uses. BIT2000
can communicate with
many types of equipment
through the fast multidrop
RS485 based bus and a
standard RS232 serial port.
At last!
This tiny pocketable USB-based and USB-
powered device is the answer to your need for an eco-
nomical logic analyzer that you can take anywhere.
About the size of a small matchbox, ANT8 can sample
eight channels at up to 500 million samples-per-sec.
ANT8 offers simple or complex
triggering, upgradeable soft-
ware. View the captured eight
digital channel traces on your
PC. Save or print screens for
reference or labnotes! $199!
Manufacturing Software
RS485 factory control
Crystals & Oscillators
Easy USB in one IC!
Basic modules
No USB knowledge required! Byte-
wide ic version FT245BM too!
FT232BM is in the ready-made
US232 cable (USB-serial) - see top
right panel. Instantly update your
legacy serial RS232 products!
PC Scope Adapters
RS232<>422/485
I2C for PCs
Datalogger/Controller
CANbus Cards
Standalone Dataloggers
SM PCB Adapters
USB PC Scope
USB Bus Analyzer
Logic Analyzer
Isolated USB<>RS485
USB-Serial Adapters
BASIC Tigers
are tiny multitasking
modules for quick project development.
Powerful features and low prices make
Tigers a number one choice: super-fast
development cycle, high reliability prod-
ucts, >100,000 instructions/s, up to 38 I/O
lines, A/D, D/A, I2C, SPI, text/graphic LCD
interface.
NOW - SmartCard Interface!
iCOM200
ready-made controller with LCD
and keypad.
Touch240
controller - with
touchpad and LCD display.
Self-contained in 2” x 3” box, these
battery-powered standalone analog
and digital loggers store events,
voltages, currents or pressures for
days to weeks. Download detailed
time and data via serial port and
review results with graphic software
or upload to an Excel spreadsheet.
More details at - www.abidata.be
These SM miniboards have two foot-
prints on either side, allowing you to
use ultra fine pitch SMD components
with a more useful array of 0.1"
spaced holes. 1-to-1 pinout for circuit
probing during design and testing.
Each unique miniboard (pat-pending)
can fit several different devices.
More at www.omega-research.co.uk
Ruggedized Industrial ATX PC systems to suit almost
any budget or PC application.
Easy maintenance, economy
and reliability. $899 version
features AMD Athlon XP1700,
shock-mounted 40GB harddrive.
Lockable front doors prevent
tampering. Full Burn-in and
Test Report with every system.
LED system status indicators.
CE EMC certified. More info at www.amplicon.co.uk
S
A
E
L
I
G
B
R
I
N
G
S
Y
O
U
S
O
L
U
T
I
O
N
S
!
algorithms, sending voice over the
radio started with amplitude modula-
tion, and AM remains a good place to
see how this stuff works. In this col-
umn, I’ll examine what a simple AM
modulator does to a carrier and an
audio tone. Then, I’ll show you how I
demodulated the signal to recover the
audio. Although the results weren’t
anywhere near broadcast quality, you
should get an idea of what all those
complex formulas in the reference
books really mean.
A DIFFERENT KIND OF VCR
Essentially by definition, amplitude
modulation means that the magnitude
of an audio signal varies the magni-
tude of a carrier waveform. In most
cases, the result should be proportion-
al to the product of the inputs, which
means that an AM modulator is an
analog multiplier.
Four-quadrant multipliers, such as
the classic MC1494 and MC1495
chips, perform this function for posi-
tive and negative values on either
input. The sign of the output voltage
follows the usual algebraic convention
of positive for like input signs and
negative for unlike signs.
You can also use a two-quadrant
multiplier that multiplies one bipolar
signal by an always-positive or
always-negative signal. This simplifies
the circuitry quite a bit and doesn’t
compromise the result, because you
could do the same thing with a four-
quadrant multiplier by simply adding
an offset to one input.
ABOVE THE GROUND PLANE
by Ed Nisley
70
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
T
he earliest radios used untuned
circuits. Any receiver within the
range of a transmitter would produce
an audio output, so there was only
one “channel” available.
Obviously, that situation couldn’t last
too long and the notion of modulating
information on a carrier signal at a spe-
cific frequency, and then using receiver
filters to reject all other carriers, quickly
took hold. Various types of modulation,
tuning, filtering, and amplification
followed at a breathtaking pace. In
55 years, radio went from Hertz’s 1887
demonstration to radar proximity fuzes
stuffed in antiaircraft shells.
Although present-day modulation
schemes tend toward complex digital
The circuit illustrated in Figure 1
implements a two-quadrant multipli-
er using an n-channel junction FET.
Although I used a VCR2N JFET
specifically designed as a voltage-
controlled resistor (VCR), any JFET
in your parts heap will work fine for
your purposes. (The VCR2N is avail-
able from Electronic Goldmine at
www.goldmine-elec.com.) The key is
to keep the drain-to-source voltage
near zero, where the transistor acts
as a linear resistor controlled by its
gate voltage.
The op-amp circuit’s voltage gain is:
where r
DS
is the JFET’s drain-to-
source resistance. Although the gain
can vary from extremely high, with
the transistor fully on, to about 1,
with it fully off, the most interesting
situations occur near the middle of
the range.
The VCR2N datasheet shows that
the gate voltage, V
GS
, controls the
1
6
+
R
r
DS
Modulation and Demodulation
Our understanding of radio technology has come a long way since Hertz’s nineteenth-cen-
tury experimentations. In this column, Ed shows you what a simple AM modulator does to a
carrier and an audio tone. In addition, he describes how you can demodulate the signal to
recover the audio.
Photo 1—
The 200-Hz modulating signal produces a
corresponding amplitude variation in the 5-kHz carrier.
Adjust the modulating input’s offset and amplitude to
see the effect on the modulated output.
Figure 1—
An n-channel JFET serves as a voltage-con-
trolled resistor that makes the op-amp gain linearly pro-
portional to the modulation input. The overall circuit is
basically a two-quadrant multiplier that produces an AM
signal at the carrier frequency.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
71
drain-to-source resistance thusly:
where r
DS(ON)
is the drain-to-source
resistance with the gate tied to
the source (V
GS
= 0). V
GS(OFF)
is the
gate voltage at pinch-off, defined
as the point where the drain cur-
rent equals 1 µA. Because this is
an n-channel device, the gate
must be negative with respect to
the source to reverse-bias the gate
junction.
The VCR2N datasheet lists r
DS(ON)
as
20 to 60
Ω
and V
GS(OFF)
as –3.5 to –7 V.
I measured a dozen VCR2Ns in my
parts heap and found r
DS(ON)
values
from 33.7 to 38.7
Ω
and V
GS(OFF)
from
3.82 to 4.89 V, a much smaller range
than I had expected.
The measurements are easy enough
to do on any n-JFET in your heap.
Finding V
GS(OFF)
requires nothing more
than a potentiometer to bias the gate
and a multimeter with decent accura-
cy around 1 µA: tweak the poten-
tiometer for 1 µA and read the gate
voltage. To get r
DS(ON)
, set up an
LM317 as a 10-mA current source
from a 12-V supply into the drain,
ground the gate and source, measure
V
DS
, and divide that by 10 mA.
Although it’s hard to believe that
the overall gain of the circuit varies
linearly with V
GS
, it’s true. I don’t
have the space here for the graph, but
the downloadable files for this column
(available on the Circuit Cellar ftp
site) include a spreadsheet with meas-
ured data, equations, and a graph.
WE HAVE MODULATION
Photo 1 shows the modulator in
r
r
V
V
DS
DS
GS
GS
=
(ON)
(OFF)
1
−
action. The top trace is the 5-kHz car-
rier at the noninverting op-amp input,
and the middle is the 200-Hz modu-
lating signal. The bottom trace shows
the modulator’s output. As the mod-
ulating voltage becomes more nega-
tive, the drain-to-source resistance
rises, which decreases the overall cir-
cuit gain. The negative gate bias sets
the average voltage gain to about
150, so the 30-mV
P
carrier becomes a
5-V
P
output.
The carrier comes from my
WA1FFL direct digital synthesizer and
needs only an amplitude adjustment
through R2. The 200-Hz tone comes
from a function generator with ampli-
tude and offset controls, eliminating
the need for additional circuitry.
Using audio frequencies for both the
carrier and modulating signal means
that you can study the circuitry with
software running on a sound-card-
equipped PC. I used Spectrogram 7.2
from Visualization Software to gener-
ate Photo 2 from the output signal.
The 5-kHz carrier frequency forms
the highest peak, which is a character-
istic of AM modulation. Flanking it at
5000
±
200 Hz are the modulation
sidebands. If I were using actual
audio, instead of a pure tone, each of
those sidebands would be as
wide as the audio bandwidth.
My function generator has
fairly high second-harmonic
distortion, and the modulator
circuitry causes even more dis-
tortion, which accounts for
the additional sidebands flank-
ing the carrier at multiples of
±
200 Hz. You can also see a
second-harmonic spur from
the carrier at 10 kHz flanked
by its own audio sidebands.
The combinations of the signals
and their harmonics in various
nonlinearities contribute to the
forest of spikes across the display.
The 220-k
Ω
resistors at the gate
of Q1 cancel out a slight nonlin-
earity in the transfer function,
which Horowitz and Hill discuss
in The Art of Electronics. [1] In a
practical modulator, you’d pay
even more careful attention to
minimizing distortion, of course.
As you adjust the carrier and
audio signal levels, you’ll see a large
effect on the output spectrum. In a
completely linear circuit the ampli-
tudes wouldn’t make any difference,
so it’s interesting to tweak them and
watch what changes. In particular,
note the large increase in distortion
products as the audio signal increases
at the modulating input.
The JFET’s gate junction remains
reverse-biased, and the drain-to-source
resistance remains fairly linear even
with a negative voltage on the drain.
The voltage divider formed by R6 and
Q1 keeps the peak amplitude seen by
Q1 roughly constant as r
DS
decreases
and the gain increases.
Pop quiz: work it out. Hint: add a
few columns to the spreadsheet in the
downloadable files that calculate the
voltage at Q1’s drain for various mod-
ulation voltages.
Even though this seems like a low-
frequency circuit, it has a closed-loop
gain approaching 200 and a band-
width over 10 kHz. That means the
op-amp must have a gain-bandwidth
product exceeding 2 MHz: the LF356
has a 5-MHz GBW. A low GBW will
cause distortion as the op-amp’s out-
put voltage chases the value demand-
ed by the input voltages. Try an
Photo 2—
The modulator’s output spectrum peaks at 5 kHz with two
sidebands at
±
200 Hz. The output also includes baseband feed-
through, additional harmonics, and other assorted mixing products.
Photo 3—
The demodulator’s unfiltered output in the
middle trace looks weird, but some RC filtering extracts
the original 200-Hz input signal. The lower three traces
show the region between the vertical cursors in the
upper part of the screen.
Photo 4—
The demodulator’s output spectrum includes the
200-Hz signal plus a bunch of other trash. The phase of the
switching signal determines the relative amplitude of the desired
signal versus the unwanted outputs.
72
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
LF441 or, shudder, a generic 741 to
see what happens.
An AM signal’s depth of modulation
is the ratio:
The modulation index in Photo 1 is
roughly 0.3. The modulation varies
the carrier from about 12 down to
6 V
PP
.
Increasing the signal on the JFET’s
gate increases the modulation index,
up to the limit of 1.0 where the carri-
er nearly vanishes at the most nega-
tive peaks of the modulating signal.
Increasing the signal beyond that
point causes a dramatic increase in
harmonics because the output wave-
form is irretrievably distorted. The
average modulation index for voice
signals must be much smaller than 1.0
so that peak sounds aren’t distorted.
Increasing the modulation index
increases the relative amplitude of the
sidebands, thus putting more power
into the signal and less into the carri-
er. When the modulation index hits
1.0, the carrier uses half the power
and each sideband has one-fourth of
the total. That’s the best you can do!
Amplitude modulation is notorious-
ly wasteful of bandwidth and trans-
mitter power: the carrier doesn’t con-
vey any useful information, and the
identical modulation sidebands carry
the same information. Double-side-
band, suppressed-carrier modulation
does exactly what you’d expect (gets
rid of the carrier) and single-sideband
modulation disposes of both the carri-
er and one sideband, but both of those
require more complex demodulators.
Now for a bit of a review. Compare
Photo 2b in my February column
maximum V minimum V
maximum V
minimum V
PP
PP
PP
PP
−
+
(“Nonlinear Mixing,” Circuit
Cellar
151) with Photo 2 in
this column. In both cases,
two frequencies produce a
forest of mixing products. I
just call the first situation
trouble and this one ampli-
tude modulation!
It turns out that amplitude
modulation is just a form of
frequency mixing. No matter
how you do it, you get similar
results: a simple diode mixer
can do roughly the same thing as a
complex linear multiplier. The differ-
ence lies in the nuances: the spectral
purity of the output, the mixing loss,
the drive requirements, and so forth.
I elected to leave the spurs in place
to illustrate the problems, but a band-
pass filter at the modulator’s output
would remove the spurs on both sides
of the sidebands. AM transmitters
(actually, all RF transmitters) must
conform to strict emission specifica-
tions that limit spurious emissions,
so getting rid of unwanted mixing
products is the first step toward a
clean signal.
Whether it’s called a modulator or a
mixer, I’ll demodulate the AM signal
using an analog switch to show that it
doesn’t matter.
AND SOME DEMODULATION
The earliest AM demodulator was a
semimetallic crystal, typically galena,
with a cat-whisker contact. The junc-
tion between the whisker and the
crystal formed a rectifier so that the
output was just the upper (or lower)
half of the waveform seen in Photo 1.
A capacitor held the peaks, removed
the carrier, and produced an output
proportional to the original modulat-
ing voltage.
I won’t show the circuit here, but
you can demodulate the output of
Figure 1 using a Schottky diode simi-
lar to a 1N5819 and a small RC filter.
Try it and see!
A single diode produces a half-wave
rectified output that discards half the
input signal. A full-wave rectifier
would be better, but diodes have a
voltage drop that wastes power. A
synchronous rectifier solves both
problems by switching between the
input signal and an inverted copy
using low-loss analog switches.
The MAX4526 phase-reversal ana-
log switch in Figure 2 is optimized for
this application. The control input
connects outputs X and Y alternately
to inputs A and B through a pair of
low-resistance CMOS switches. It’s
limited to switching frequencies
below about 100 kHz and is not suited
for direct RF demodulation, but it can
easily handle audio and ultrasonic
applications.
The LM441 op-amp inverts the
input signal. The MAX4526 can
therefore multiply the input by +1 or
–1 by selecting the proper input. If
you think this sounds like the diode
ring modulator in my April column
(“Balanced Mixing,” Circuit Cellar
153), you’re right. The trick is to syn-
chronize the switches with the carrier
frequency.
The lower half of Figure 2 is an
obvious cheat, because a radio receiv-
er generally doesn’t have access to the
pure carrier signal from the transmit-
ter’s input. Extracting the carrier from
the AM signal requires an amplifier
and a limiter to strip away the modu-
lation, then a phase-locked loop to
stabilize the recovered frequency.
That’s more complexity than I wanted
Photo 5—
A simple RC filter attenuates the unwanted signals and
leaves a reasonably clean output. The frequency separation is much
higher for real RF, making the filter correspondingly more effective.
Photo 6—
Hairball circuitry like this barely works at
audio frequencies and fails at RF. Don’t do as I do, do
as I say!
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
75
for this column, although I encourage
you to explore the references and
build it the right way.
A synchronous rectifier requires a
switching signal with a precise 50%
duty cycle that is most easily derived
from a binary divider. The audio
transformer and diodes in Figure 2
produce a full-wave rectified version
of the carrier that the LM311 then
clips into a signal of twice the carrier
frequency. R2, a trimmer, varies the
phase of that signal by about 90° rela-
tive to the input. The 74LS112 then
divides the frequency in half to pro-
duce a perfect TTL square wave.
Photo 3 shows the demodulator in
action. The three bottom traces are a
magnified view of the top three
between the vertical cursors. The top
trace in each half is the AM input sig-
nal, the middle is the MAX4526 out-
put, and the bottom is a low-pass fil-
tered version of the output.
Under ideal conditions the synchro-
nous rectifier should switch at the car-
rier’s zero crossings. I adjusted R2 so
that the switchings occur at about 45°,
a poor choice for good demodulation,
but one that allows you to see the
waveforms more easily. The two phas-
es of the input waveform aren’t quite
balanced around 0 V, indicating that
the op-amps have uncorrected offsets.
Despite those faults, Photo 4 shows
that the demodulator does, in fact,
extract the 200-Hz audio input. The
peaks at the carrier’s 5 kHz and its
strong second harmonic at 10 kHz clear-
ly indicate the presence of those steep
edges. Remember that the AM output
isn’t filtered, so the demodulator’s
input is rich in unwanted harmonics.
The R8-C1 low-pass filter in
Figure 2 knocks off those edges and
recovers a decent replica of the origi-
nal audio input, with the harmonic
content shows in Photo 5. As with
the modulator, an RF demodulator
would have the carrier and audio fre-
quencies separated by many orders of
magnitude, which would make the
filtering even more effective.
CONTACT RELEASE
The hairball circuit in Photo 6 pro-
vided all the signals for this column.
Solderless breadboards are great for
quick prototypes and terrible for low-
level analog circuitry. In particular,
getting that LM311 comparator to
work without oscillating was almost
enough to make me start over with
an etched circuit board!
A friend suggested using the
MAX4526 as the heart of a bat detec-
tor. Use an ultrasonic transducer as a
microphone, filter out everything
below 20 kHz, and vary the LO
between about 20 and 100 kHz. A
bat’s ears have more bandwidth than
yours, but you’ll hear a slice of their
world. Sounds like a great science fair
project, doesn’t it?
I
PROJECT FILES
To download additional files, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2003/159.
Ed Nisley is an E.E., P.E., and author
in Poughkeepsie, NY. You may con-
tact him at ed.nisley@ieee.org.
REFERENCE
[1] P. Horowitz and W. Hill, The Art
of Electronics
, 2d ed., Cambridge
University Press, Cambridge,
UK, 1989, p. 140.
RESOURCES
W. Hayward (W7ZOI), Introduction
to Radio Frequency Design
, ARRL,
Inc., Newington, CT, 2000.
U. Rohde and J. Whitaker,
Communications Receivers: DSP,
Software Radios, and Design
, 3rd
ed., McGraw-Hill, New York, NY,
2000.
W. Sabin and E. Schoenike, eds., HF
Radio Systems & Circuits
, rev. 2d
ed., Noble Publishing Corp.,
Naorcross, GA, 1998.
D. Smith (KF6DX), Digital Signal
Processing Technology: Essentials of
the Communications Revolution
,
ARRL, Inc., Newington, CT, 2001.
Vishay Siliconix, “FETs As Voltage-
Controlled Resistors,” AN05,
www.vishay.com/docs/70598/70598.
pdf, 1997.
———“JFET Voltage-Controlled
Resistors,” 70293, www.vishay.com/
document/70293/70293.pdf, June 2001.
SOURCES
VCR2N Voltage-controlled resistor
Vishay Siliconix
www.vishay.com
Electronic Goldmine
www.goldmine-elec.com
Spectrogram 7.2
Visualization Software
www.visualizationsoftware.com
Figure 2—
A synchronous demodulator switches between the direct and inverted input, effectively multiplying the
signal by 1 and –1. The diodes, comparator, and flip-flop produce a switching waveform synchronized with the car-
76
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
H
as it really been more than 10 years
since I first wrote about ARM (then
known as Acorn) CPU chips (“Nuts
About RISC,” Circuit Cellar 23)?
Time flies when you’re having fun.
There are two parts to the ARM
story. One is about a CPU architec-
ture, which I’ll get into shortly. The
other is about a business model. Much
is made these days of the surely soon-
to-blossom intellectual property mar-
ket in which chip designs are traded
to-and-fro like so many baseball cards.
Give ARM credit for being one of
the first, and arguably the most suc-
cessful, to actually make it happen.
Although much is made of fabless chip
companies that sell ICs fabricated by
independent third-party foundries,
ARM takes that a step further: they’re
a chipless outfit that sells an architec-
ture, not silicon.
Of late, I’ve heard some
comments casting doubts
about ARM, pointing to
declining revenues, fewer new
licensees, and the effect of a
weak dollar. However, my take
is that these are more like
short-term hiccups in a long-
term success story than any-
thing else. And, after all, the
company still has managed to
remain profitable, which even
the most jaded analyst must
concede is no small feat.
There’s success as meas-
ured by the financial pages,
lator, and you’ll see current shipments
work out to nearly two million units a
day, and I’m talking about 24/7/365.
Impressive, and all the more so when
you remember that it takes awhile for
“licensees” to turn into “royalties” (i.e.,
the time between signing the paper-
work and chips getting designed, built,
and shipped in volume). In fact, it turns
out that the two million units a day are
the output from only 48 of the part-
ners. What happens when the other
64 licensees (i.e., 112 – 48), not to men-
tion the ongoing new sign-ups, kick in?
BACK TO THE FUTURE
Back in ’91, the ARM2 CPU that I
wrote about was less than 30,000 tran-
sistors, a mere speck of sand in com-
parison to today’s technology. But
time and silicon marches on and,
since then, ARM has migrat-
ed the CPU up the ladder
into double digits with the
latest and greatest ARM11.
Although leaner than big-
ticket PC/workstation CPUs,
ARM11 has picked up its
share of architectural trinkets
along the way: an eight-stage
pipeline, branch prediction,
nonblocking caches, DSP vec-
tor-processing (i.e., SIMD)
instructions, and Java acceler-
ation. The CPU may not have
the peak performance or sex
appeal of the fancier chips,
but it doesn’t have the die
In ARM’s Way
SILICON UPDATE
by Tom Cantrell
and then there’s success in the sockets.
The fact is, as of the quarter ended in
March 2003, ARM has gathered a
remarkable 112 licensees for their archi-
tecture, a veritable who’s-who with
names like IBM, Sony, NEC, Nokia,
Motorola, and even Intel. Further dig-
ging into the quarterly report yielded
additional nuggets of data that suggest
the prospects for ARM—and its affect
on the industry—is much higher than
today’s stock price.
The number of ARM-powered chips
shipped by licensees increased by
almost one-third, quarter to quarter,
from 127 to 178 million units. Er, how
many other chip companies can match
that? Very few, I daresay. Impressive
growth, especially in the context of a
global economy that’s tepid at best.
Punch the numbers into your calcu-
0 0 1
1 0
Rd
8-bit immediate
15
Thumb code
0
Major opcode
denoting format 3
move/compare/add/sub
with immediate value
Minor opcode
denoting ADD
instruction
Destination and
source register
Immediate
value
1110
00
1
0000 8-bit immediate
0 Rd
0 Rd
0100
1
31
0
Always condition code
ARM code
Example: ADD Rd, #Constant
Figure 1—
Carving a 16-bit Thumb instruction from its full-size ARM equivalent is
a matter of sacrificing and shuffling instruction bits.
You cannot always measure a tech company’s strength by what you read in the financial
pages of a newspaper. Sometimes you have to dig deeper. Fortunately, you can turn to Tom
when you’re looking for the scoop on companies working in the world of silicon chips. In this
column, he cuts through the news stories, press releases, and rumors to set the record
straight regarding ARM’s past, present, and future.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
77
size, power consumption, and
price bloat. ARM11 will no
doubt find success among
ARM’s traditional customer
base for applications like cell
phones, PDAs, handheld
games, and so on. It’s amazing
how much processing power a
small handheld gadget with a
screen demands these days.
For this column, let’s go
back in time to the ARM7
core, specifically the
ARM7TDMI variant. Frankly, I
think the latest developments
at the low end are where the
action is. Remember way back
when the “R” in RISC actually meant
“reduced”? ARM7 has a lot more in
common with the ARM2 (and the origi-
nal RISC concept) than with the latest
performance-at-any-price CPU chips.
With ARM7, I’m talking about a sin-
gle-issue, three-stage pipeline, load-
and-store machine with architectural
roots going way back. If PC and work-
station chips are Ferraris and Porsches,
the ARM7 is the mini pickup. If you
floor the thing, you may hit 100 MHz,
but that’s about it. If you find this
yawn inspiring, you needn’t read on.
I’m writing this for designers of deeply
embedded gear who typically use an
8/16-bit MCU and understand that
you don’t haul wood with a Ferrari or
Porsche. Oh yeah, they also understand
that the mini pickup business is a heck
of a lot bigger than the luxo-niche.
UNDER MY THUMB
“This youngest boy was very little.
At his birth he was scarcely bigger
than a man’s Thumb, and he was
called in consequence ‘Little Tom
Thumb.’”
—Charles Perrault
One of the enhancements ARM came
up with in the mid-’90s is known as
Thumb (the “T” in the ARM7TDMI
designator). I’ll get into “what” in a
moment. For now, let’s go back and
study the original RISC concept to
see the “why.”
Historically, RISC chips (e.g., ARM2)
were known for relatively simple fixed-
length, 32-bit instructions. Other tenets
of the RISC theology include load-and-
store architecture in which data is
moved to and from memory for pro-
cessing, i.e., all instructions (except, of
course, load and store) address-only reg-
isters. Furthermore, the relatively wide
32-bit instruction word enables three-
operand addressing (e.g., adding the
contents of two registers and storing
the sum in a third register).
That’s all well and good, achieving
decent performance while making life
easy for both the chip designer and the
compiler writer, but there’s a problem.
Simply put, as a practical matter, devot-
ing a full 32 bits to each instruction is
overkill. Do you really need 32 bits to
increment a register or branch a tight
loop (i.e., a few bits of address displace-
ment), not to mention all the NOPs that
litter delayed-branch and load designs?
Between having to use simpler
instructions to get the job done and
the fact that each and every instruc-
tion was a full 32 bits, RISC got a bad
rap for poor code density compared to
CISCs like the x86 or 68000. It might
require as much as two times the code
memory to get the same job done.
Enter Thumb, which is a code-com-
pression scheme ARM came up with
in 1995 to put the code density issue
to rest once and for all.
Just as with audio and video, there
are a lot of conceptual ways to com-
press code, but some are more esoteric
and complicated than others (e.g., con-
sider MPEG versus simple run-length
coding). You could switch to a variable-
length instruction set that encodes the
most common instructions in fewer
bits. (CISC lives?) Or, you could even
go as far as to optimally compress each
specific application’s ROM code (the
way you would ZIP a file on
your PC) if you’re willing to
accommodate the extra hard-
ware and additional critical
path delays for decompression.
I give ARM credit for keep-
ing it simple with Thumb. In
essence, the scheme maps the
instruction set for a simpler
machine (Thumb has only
36 instructions) on the existing
hardware. Here’s how it works:
With the goal of a 16-bit
Thumb instruction word, a
number of features associated
with the full-bore, 32-bit ARM
instruction set had to be jetti-
soned (see Figure 1). Three-operand capa-
bility was one of the first to go, followed
by the nifty but hardly mandatory condi-
tional execution feature. Finally, the
number of bits specifying each operand
(i.e., register address) was reduced from
4 to 3 bits, so a Thumb program only
sees the lower eight of the 16 general-
purpose registers (although there are
hooks to access the high eight).
The beauty of the scheme is that it is
simple and fast. Decompression consists
of little more than a table look up and
shuffling some of the instruction bits. In
fact, the designers were able to fit the
translation into an unused phase of the
instruction decode stage, so there’s no
performance penalty (see Figure 2).
Well, you might reasonably ask,
why not use an 8/16-bit MCU with
short instructions to begin with?
Remember that although a Thumb
instruction is only 16 bits, by the time
it hits the execute stage of the
pipeline, it’s a regular ARM instruc-
tion that still works with 32-bit regis-
ters and can do 32-bit stuff like add
two of them or take a long branch.
Switching between 16- and 32-bit
instruction modes is accomplished via
a BX instruction, which toggles the
state of a Thumb/ARM bit in the pro-
gram status register (PSR). Thus, it’s a
simple matter to mix and match
Thumb and ARM code to optimize
performance and code size trade-offs
for a particular application.
Ironically, in the original context of
the earlier era in which Thumb was
defined, it’s arguably no longer need-
ed. Back then, the code density issue
Fetch
stage
Decode stage
Execute
Thumb
instruction
decompressor
16
16
Mux
Mux
16
32-bit data
Mux
A[1]
Thumb state
ARM
instruction
decode
Figure 2—
Thanks to its simplicity, the Thumb scheme doesn’t get in the proces-
sor’s way or bog it down with a lot of extra hardware.
78
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
was about reducing the number of
memory chips you had to hang on an
external bus. But given the incredible
boost in density over the years, I sus-
pect the challenge today is finding a
memory chip that’s small enough for
your application.
That’s OK. In fact, it’s often the case
that a feature designed for one purpose
finds a higher use somewhere further
down the road. It turns out that code
density still matters for 32-bit chips,
maybe more than ever. Why? Because
the memory is going on-chip with the
CPU. Memory now competes with
everything else for space on the
System-on-a-Chip, and designers can
surely find something better to do
with their silicon than waste it on
needless instruction bits.
“C”INGLE CHIP
At the spring Embedded System
Conference in San Francisco, I came
across three—count ’em, three—
ARM7TDMI 32-bit MCUs with built-in
flash memory (see Table 1). They aren’t
the first 32-bit chips with built-in flash
memory, nor are they the first high-
integration ARM-based devices, but I
was struck by how clearly the parts are
positioned as true single-chip MCUs.
There’s no better example of this
than the new Philips LPC210x line of
microcontrollers. In this case, a pic-
ture is worth a thousand words (see
Photo 1). There may be a complete
32-bit system under the hood, but,
from the outside, it looks more like a
typical 8-bit MCU.
The similarity extends to the selec-
tion of peripherals, which include all
the usual suspects: serial ports (UART,
SPI, and I
2
C), timer/counters (PWM,
RTC, and watchdog), and so on. You
may imagine that Philips would use
its existing ’51 family I/O functions,
but the high-performance, easy-to-use
peripherals on the LPC210x are more
modern. For instance, the timer/coun-
ters are 32-bit units with full cap-
ture/compare capability. Gone are the
days when you had to struggle to get a
coarse, glitchy PWM out of a ’51. The
LPC210x can easily control multiphase
motors and the like with plenty of chan-
nels and advanced features like edge
control, which refers to the ability to
move the active part of the duty cycle.
Similarly, the UARTs are full-fledged
’550 compatibles, including built-in
FIFOs and dedicated data rate genera-
tors. One of the UARTs (UART1) even
includes a full complement of six
modem-control signals (RTS, CTS, etc.).
A glance at the block diagram in
Figure 3 reveals a key point: the
LPC210x is not only capable of oper-
ating as a single chip, but that is the
only option because there is no exter-
nal memory expansion bus.
A PC seems to need megabytes of
memory just to keep up with a key-
board and mouse, so just how much
functionality can you expect to fit in
the LPC201x’s 128 KB of flash memory?
Although your PC and the ARM7 are
both 32 bits, you’ve got to put the
bloatware mentality aside. Sure, you’re
not going to be running WinCE or
Embedded Linux, but factoring Thumb
into the equation, I think 128 KB will
go further than you think.
There may not be a ton of bits, but
Philips did address another major
flash memory issue (i.e., speed). By
incorporating a wide 128-bit flash
memory bus, Philips overcame the
limit imposed by the typical 50-ns
flash memory access time and main-
tained zero wait state operation up to
the advertised 60-MHz clock rate.
Another fundamental concern for
embedded designers relates to power
supply and voltage levels. Like a lot of
chips based on the latest semiconduc-
tor technology (0.18 µm in this case),
native 5-V operation is history. The
LPC210x requires two supplies, 1.8 V
for the core and 3.3 V for the I/O.
Fortunately, however, the I/O lines
are 5-V tolerant, providing an easy
upgrade path for the LPC210x into
existing 5-V designs.
I give Philips credit for pushing the
32-bit MCU envelope with a single-
chip-only strategy. There are arguably
few, if any, chips that pack as much
performance in as few pins.
OK BY OKI
ARM is also Oki Semiconductor’s
choice for boosting its MCU fortunes.
Although the company was, years ago,
a bit of a player with ’51s, they’ve cer-
tainly fallen off the list of names that
come to mind when you consider
MCU suppliers.
Actually, the lack of baggage (i.e.,
existing parts and customers) has
given Oki a chance to start with a
clean slate, and they’re taking full
advantage of it. A February 2003 press
release reads, “Oki teams with ARM
to establish ARM7 family as the new
8051-type standard for 16/32-bit MCU
market.” Talk is cheap, but Oki is
putting its chips on the table this year
with the introduction of 10 ARM-
based devices.
The ML674K and ML675K lines
comprise half a dozen parts, with each
Philips LPC210x
Oki ML674K/675K
Atmel AT91F40816/FR4081
Atmel AT91FR40162/FR4042
Clock rate
60 MHz
33 MHz/60 MHz
40 MHz
70 MHz
Flash memory
128 KB
0-, 256-, 512-KB versions
2 MB/1 MB
2 MB/512 KB
SRAM
16-, 32-, 64-KB versions
32 KB
8 KB/136 KB
256 KB/256 KB
Cache
No
No/8 KB
No
No
Expansion bus
No
24-bit address, 16-bit data
24-bit address, 16-bit data
24-bit address, 16-bit data
Peripherals
5 timers, 2 serial ports,
10 timers, 2 serial ports, 2 clock
4 timers, 2 serial ports
4 timers, 2 serial ports
2 clock serial ports
serial ports, four-channel 10-bit
ADC, two-channel DMA
Power supply
1.8-V core, 3.3-V I/O
2.5-V core, 3.3-V I/O
3.3 V (2.7–3.6 V)
1.8-V core, 3.3-V I/O (2.7–3.6 V)
Package
44-pin QFP
144-pin QFP, BGA
120-pin BGA
121-pin BGA
Table 1—
ARM yourself with a practical 32-bit flash memory MCU courtesy of Atmel, Oki, and Philips. Check out the options for on-chip memory.
80
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
line having three variants comprising
0, 256, and 512 KB of flash memory.
Otherwise, the major difference
between the ML674K and ML675K is
that the latter has 32 KB of cache
(unified code and data, four-way set
associative), which allows it to handle
a higher clock rate—60 versus 33 MHz
for the ML674K. In general, I am not a
big fan of cache for embedded apps,
but, clearly, it can be useful in some
situations. Kudos to Oki for letting
designers make the choice.
As for peripherals, Oki’s parts come
with all the typical MCU goodies:
UART, SPI, I
2
C, timer/counters (7 ×
16 bits), PWM (2 × 16 bits), a watch-
dog timer, and then some. Notable
additions include a two-channel DMA
controller with all the fancy features
(e.g., internal/external request,
burst/cycle steal, and 8-, 16-, and
32-bit bus matching), a four-channel
10-bit ADC, and a 4-KB
boot ROM with built-
in code to reprogram
the flash memory via
a UART.
Like the Philips
parts, Oki also requires
separate power suppli-
ers for the CPU core
(Vdd_CORE = 2.5 V)
and I/O (Vdd_IO =
3.3 V). Unlike Philips
parts, however, the I/O
lines are not 5-V toler-
ant. The maximum
allowed input is
Vdd_IO + 0.3 V.
The Oki chips are
more conventional
than Philips chips
because they provide
an external bus inter-
face, consuming nearly
half of the 144-pin
package. The interface
is easy to use; it pro-
vides glueless connec-
tivity to most memory
(including convention-
al and even synchro-
nous DRAM) and I/O
devices, and comes
with all the trimmings
(e.g., chip selects, an
internal and external
The FAQ section of Oki’s web site
contains several relevant statistics.
Thumb code typically requires 40%
more instructions than 32-bit ARM
code, but because each Thumb
instruction is half the size, the total
code space for Thumb is only 70% of
the 32-bit version (i.e., 140% divided
by two). The bottom line states that
when operating within the confines of
a 16-bit interface, Thumb code is 45%
faster than ARM code!
One of the major benefits of the
ARM bandwagon is that there’s a
healthy and growing infrastructure of
development tools. The fact that all
ARM7TDMI variants (the “D” stands
for debug and the “I” is for ICE)
include standard JTAG-based debug
hooks (e.g., hardware breakpoints,
trace scheme, etc.) makes life easier
for tool developers.
OKI offers a custom-tailored version
of the official ARM
RealView develop-
ment suite, which
includes a compiler,
debugger, and JTAG-
based ICE for $2000.
For hardware evalua-
tion, there’s a rela-
tively lean and mean
evaluation board
from Unique Memec
(see Photo 2). Of
course, third parties
cover the spectrum
from the high end
(e.g., Green Hills) to
the bargain basement
(e.g., GNU).
STACKING THE
DECK
The final twist on
the ARM subject
comes from Atmel in
the form of their
AT91 family (see
Photo 3). In most
respects it’s quite
similar to the others.
Perhaps a little
lighter weight on the
peripherals and the
bus interface (again
16-bits) is a bit sim-
ple-minded (i.e., no
wait state generator, etc.).
But what’s this, the data bus is only
16 bits, won’t that be a bottleneck? Of
course, the cache option provides a
conventional, if partial, solution.
Thumb is the real lifesaver. Here’s
why: Although the Thumb version of
a particular routine invariably requires
more instructions than the full 32-bit
ARM version, it doesn’t require two
times as many. Thus, over a 16-bit
bus, the Thumb version will actually
execute faster than the 32-bit version.
ARM7TDMI-S
Test/debug interface
Em
ulation tr
ace
module
AHB Bridge
Internal SRAM
controller
64-, 32-,
and 16-KB
SRAM
Internal flash
memory controller
128-KB
Flash memory
ARM7 Local bus
AHB-to-VPB
Bridge
VPB
Divider
VPB (VLSI Peripheral bus)
AMBA AHB
(advanced high-performance bus)
EINT0*
EINT1*
EINT2*
External
interrupts
Capture/
compare
Timer0
CAP0…2*
MAT0…2*
Capture/
compare
Timer1
CAP0…3*
MAT0…3*
General-
purpose I/O
GPIO (32 pins)
PWM0
PWM1…6*
Real-time
clock
I
2
C Serial
interface
SCL*
SDA*
SPI Serial
interface
UART0
UART1
Watchdog
timer
SCK*
MOSI*
MISO*
SSEL*
TxD*
RxD*
TxD*
RxD*
Modem control (6 pins)*
System
control
* Shared with GPIO
1
When the test/debug interface is used, GPIO/other functions sharing these pins are not available
System
functions
Vectored
interrupt
controller
AHB
Decoder
PLL
System
clock
T
RST
1
TMS
1
TCK
1
TDI
1
TDO
1
Xtal1
Xtal2
RST
V
DD
V
SS
Figure 3
—
From the outside, it may look like a typical 8/16-bit MCU, but inside the Philips LPC210x is
a 60-MHz, 32-bit ARM7TDMI processor and the memory it needs to do something useful.
Photo 1—
By going single-chip only (i.e., no expansion
bus), Philips crams the LPC210x into a 44-pin package.
T h e
NEW
W I R E L E S S D ATA I N D U S T R Y
O C T O B E R 2 1– 2 3 , 2 0 0 3
E X P O a n d C O N V E N T I O N , Ve n e t i a n H o t e l , L a s Ve g a s , N V, U S A
OCTOBER 20, 2003
Pre-conference Seminars
OCTOBER 21, 2003
CTIA Educational Sessions, Special Interest Seminars
& Exhibit Hall Preview Reception
OCTOBER 22-23, 2003
Exhibits, CTIA Educational Sessions
[10/22 only]
& Special Interest Seminars
Your 0000 0001 to success
Come see what is new in wireless applications at CTIA
WIRELESS I.T. & ENTERTAINMENT 2003 and forge
ahead in the NEW wireless data industry.
Exhibit Show Floor Showcasing all of the Major
Leaders in Wireless Data
Comprehensive Educational Programming
•
Executive Smart Pass Program on WiFi
•
16 in-depth sessions dedicated to developments in
Mobile Entertainment and Enterprise Solutions
Key Networking Receptions
•
Exhibit Hall Preview
•
Invite-only Mobile Entertainment Reception
Developer Sessions
•
AT&T Wireless Business Partner Forum
•
The Wireless LBS Challenge
•
UIQ Development for Sony Ericsson Smartphones
For over seven years CTIA has fostered and guided the wireless developer community. Today,
the CTIA WIRELESS I.T. & ENTERTAINMENT 2003 show has become the one place where devel-
opers for all platforms can meet to learn, exchange ideas and form crucial partnerships.
Host
Partners
Sponsors
Merrill Brown,
Senior Vice President,
RealOne Services,
Real Networks
Brian Bonner, Vice
President & Chief
Information Officer,
Texas Instruments
Incorporated
Tony Scott, Chief Tech-
nology Officer, General
Motors Information
Systems and Services
Organization
DA
Y
TWO
DA
Y
ONE
Lucy Hood, Senior
Vice President,
Content, News
Corporation
Kent Thexton,
Chief Data &
Marketing Officer,
mmO2 PLC
Nada C. Usina, General
Manager of Entertainment
& Media, North & South
America, Nokia
DA
Y
THREE
What’s Next!
Industry visionaries look
into the future of wireless
data and deliver keen
insights on real devices and
applications being devel-
oped now that will impact
your business tomorrow.
82
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
direct DRAM support). On the plus
side, some versions operate off a sin-
gle, wide-voltage supply (2.7 to 3.6 V)
and are 5-V I/O tolerant.
The AT91 stands out in one notable
way: the on-chip flash memory is
big—up to a whopping 2 MB (1M ×
16), not to mention up to 512 KB of
SRAM! Throw in the Thumb density
advantage, and the bottom line is that
you can cram a lot of code into this
chip. Even using a high-level lan-
guage, one million instructions go a
long way.
How did they do that? It turns out
that Atmel (and Oki as well) is using a
stacked-die approach that combines
separate CPU and memory die in a
single AT91 chip.
As someone who’s watched the hype
and hope for multichip modules repeat-
edly dashed over the years, I admit a bit
of initial skepticism. However, after
studying up on the subject, I have to
concede that the stacked-die approach
seems viable. You don’t have to take
my word for it. Check out what the
leaders in IC packaging are doing (see
Figure 4). The approach is being used
in production parts by many of the
fair warning to suppliers of proprietary
single-source MCUs: watch out,
you’re in ARM’s way.
I
leading manufacturers.
From a user’s perspective, the
advantage is that the difference in
packaging between a stacked-die and
monolithic chip is rather impercepti-
ble. Perhaps it’s a little thicker, but
otherwise you’d never notice the dif-
ference at a glance. I wonder about
thermal concerns, but if there are
any, they certainly aren’t showstop-
pers—the Atmel and Oki parts deliv-
er –40° to 85°C industrial tempera-
ture operation.
The benefits of the stacked-die
approach for the manufacturers are
numerous. They don’t have to design
a bunch of separate parts or fuss with
a compromised flash memory and
logic process, and can take advantage
of the good price and availability of
standard flash memory chips.
To be fair, stacked-die parts don’t
exploit the wide bus technique (like
Philips) that allows for bypassing the
flash memory bottleneck. That means
wait states (or reducing the clock rate
accordingly) for flash memory access.
However, remember that all of the
chips offer 32-bit on-chip RAM (not to
mention the cache on the Oki ’675K)
that can accommodate the highest-pri-
ority code and data with single-cycle
access. Use your memory hierarchy
wisely.
LESS FILLING, TASTES GREAT
There you have them—three sepa-
rate parts that prove that putting
32 bits and an MCU together isn’t
oxymoronic. I’m talking about parts
that are truly stand-alone, with all the
built-in memory and I/O features
needed to single-handedly take on sig-
nificant applications.
More to the point, I’m talking about
MCU-like, single-digit prices ($5 is
routinely bandied about), not the dou-
ble- or triple-digit tags for 32-bit
PC/workstation bloat chips. But
there’s much more to the ARM story
than the bits, bytes, and bucks. The
political, if not polite, way of putting
it may be: it’s the business model, stu-
pid. The benefits of multisourced
architecture—more chips, more sup-
pliers, more tools, and more users—
are going to become apparent and,
dare I speculate, overwhelming. I give
SOURCES
Stacked-die IC packaging
Amkor Technology, Inc.
(610) 431-9600
www.amkor.com
ARM7 Architecture and tools
ARM
+44 01223 400400
www.arm.com
AT91 Flash memory-based
ARM7TDMI Microcontroller
Atmel Corp.
(408) 441-0311
www.atmel.com
Oki Microcontroller evaluation
board (KITML674000)
Unique Memec
www.unique.na.memec.com
Photo 3—
Thirty-two bits don’t have to break the bank.
Like the other ARM aficionados, Atmel offers a low-cost
evaluation board—the $200 AT91EB40A.
Solder ball
Dielectric
Top and
bottom die
Die attach
film/paste
1.40 mm
(maximum)
Photo 2
—
Thanks to the multisourcing bandwagon
there’s plenty of third-party support for ARM chips,
including this $199 Oki 674K-based evaluation board
from Unique Memec.
Figure 4—
Atmel, Oki, and others deliver System-on-a-
Chip without the ASIC hassles thanks to the emer-
gence of stacked-die techniques (courtesy of Amkor).
Tom Cantrell has been working on
chip, board, and systems design and
marketing for several years. You may
reach him by e-mail at tom.cantrell
@circuitcellar.com.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
83
IDEA BOX
THE
DIRECTORY
OF
PRODUCTS AND
SERVICES
AD FORMAT
: Advertisers must furnish digital submission sheet and digital files that meet the specifications on the digital submission sheet.
ALL TEXT AND OTHER ELEMENTS MUST FIT WITHIN A 2
″″ ××
3
″″
FORMAT
. Call for current rate and deadline information. Send your disk and digital submis-
sion sheet to: IDEA BOX, Circuit Cellar, 4 Park Street, Vernon, CT 06066 or e-mail kc@circuitcellar.com. For more information call Sean Donnelly at (860) 872-3064.
Suppliers Directory now available online. Check out our web site
www.circuitcellar.com to see who has what and how to get it!
Insert-ready Single Board Computer modules in sub-miniature
dimensions (as small as 47x55 mm) populated by:
applicable controller signals extend to standard pin header (2.54
mm) or high-density Molex (0.625 mm) connectors, enabling SBC
to be plugged like a big chip into OEM targets
achieved via GND circuitry, multi-layer PCB, by-
pass capacitor grid and short signal traces achieved via small
footprint and use of 0402 SMD passive components
32 KB to 64 MB external SRAM and Flash (controller-dependent)
CAN, Ethernet, RS-232 and RS-485 interfaces; ADC, DAC
(controller-dependent); freely-available /CS and I/O lines
AC adapter, serial cable and SPECTRUM CD with eval software
tools, electronic documentation and demos
: insert-ready PHYTEC SBC modules accompany you
from evaluation through protyping to end production...
accelerating your design cycle and reducing your time-to-market
New Generation
Single Board Computer
84
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
85
Interface Keypads, Switches, or RS-232 to your PC Keyboard Input
Up to 12 x 12 matrix Programmable RS-232 Port Macro Capability
The KE24 is the ultimate in flexibility. Inputs or serial data can
emulate any of the 101 keys from a standard keyboard.
Up to 9 x 9 matrix 2.5" x 3.0" Size PC Keyboard Port PCXT, AT Compatible
The KE18 combines a multitude of features with small size at an
economical price. Custom units available.
86
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
Ready-Made Graphical User Interface
Bright, High Contrast 1/4 VGA (320x240 pixel)
Electroluminescent (EL) or Monochrome Display
Precoded menu managing software
Real-time Multitasking Executive
tel: 510-790-1255 fax: 510-790-0925
applications - wherever you need an I/O rich computer and
Expansion options with Peripheral Boards
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
87
88
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
sales@sealevel.com 864.843.4343
• Supports data rates up to 921K bps
• Ethernet 10/100Base-T (autosense)
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
89
90
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
92
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 159 October 2003
93
i
Hierarchical Menus in Embedded Systems
Mixed-Signal AVR Simulator
Programming the ’386 in 32-bit Protected Mode
Pure Digital Audio: Build an All-Digital Amplifier
Timing (Analysis) is Everything
I
I Applied PCs: RF Made Simple
I From the Bench: OOPic Eases Programming Headaches
I Silicon Update: Go Sell the Spartans
94
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
84
Abacom Technologies
9
Accutek Microcircuit
91
ActiveWire, Inc.
49
AeroComm, Inc.
53
All Electronics Corp.
91
Amazon Electronics
85
American PCB Assembly LLC
85
Animated Lighting, L.C.
84
AP Circuits
15
Arcom
7
Atmel
27
AutoTRAX
85
Avocet Systems, Inc.
84
Bagotronix, Inc.
90
Basic Micro
91
Bellin Dynamic Systems, Inc.
50
CadSoft Computer, Inc.
89
Capitol Automation
87
Carl’s Electronics
89
CCS-Custom Computer Services
92
Conitec
45
Connecticut microComputer, Inc.
81
CTIA Wireless
83
Cyberpak Co.
25
Cygnal Integrated Products
1
Cypress MicroSystems
89
CWAV
91
DataRescue
91
Decade Engineering
88
Delcom Engineering
The Index of Advertisers with links to their web sites is located at www.circuitcellar.com under the current issue.
Page
84
Deys Electronics, Inc
86
Digital Products
68
DLP Design
8
Earth Computer Technologies
87
EE Tools
(Electronic Engineering Tools)
22
EMAC, Inc.
93
Embedded Micro Software
88
eProtos
9
ExpressPCB
83
FDI-Future Designs, Inc.
92
Front Panel Express
92
Futurlec
85
Hagstrom Electronics
65
HI-TECH Software, LLC
34
ICOP Technology Inc.
89
IMAGEcraft
84
Intec Automation, Inc
84
Intrepid Control Systems
91
Intronics, Inc.
86
Ironwood Electronics
57
Jameco
64, 86
JK microsystems, Inc.
93
JPA Consulting
68
JR Kerr Automation & Engineering
93
LabJack Corp.
68
Lakeview Research
39
Lemos International
2
Link Instruments
52
Linx Technologies
88
Machine Bus Corp.
56
MaxStream
90
MCC (Micro Computer Control)
45
Microchip
92
microEngineering Labs, Inc.
83
Microsoft
90
MJS Consulting
86
Mosaic Industries, Inc.
33
Motorola
74
MVS
86
Mylydia Inc.
C2
NetBurner
88
OKW Electronics, Inc.
62
On Time
92
Ontrak Control Systems
22
PCBexpress
87
PCB Fab Express
48
PCBpro
C4
Parallax, Inc.
83
Phytec America LLC
87
Phyton, Inc.
88
Picofab Inc.
86
Pioneer Hill Software
85
PrintCapture
93
Pulsar, Inc.
84
Q-Kits
31
R2 Controls
73
R4 Systems Inc.
42
Rabbit Semiconductor
63
Remote Processing
79
Renco Electronics, Inc.
Page
Page
Page
5,55
Renesas Technology Corp.
13
Renesas Contest
90
RLC Enterprises, Inc.
69
Saelig Company
3
Scott Edwards Electronics Inc.
90
Scidyne
88
Sealevel Systems
86
Senix Corp.
95
Sierra Proto Express
83
Signum Systems
93
Softools
84
TAL Technologies
C3
Tech Tools
89
Techniprise
18, 19
Technologic Systems
90
Technological Arts
89
Tern Inc.
88
TLData Corp.
85
Trace Systems, Inc.
91
Triangle Research Int’l, Inc.
62
Trilogy Design
93
Weeder Technologies
93
Xeltek
87
Z-World
91
Zanthic Technologies Inc.
86
Zexus
23
Zilog, Inc
December Issue 161
Deadlines
Space Close: Oct. 9
Material Due Date: Oct. 20
Theme:
Graphics & Video
A
TTENTION
A
DVERTISERS
e-mail: sean@circuitcellar.com
INDEX OF ADVERTISERS
Preview of November Issue 160
Theme: Embedded Development
For Unparalleled
Quality, Technology,
Delivery and Price
Insist on 2 to 24 layer
PCBs from Sierra Proto
Express
We offer the highest quality, the broadest range of technology (2 – 24 layers), the fastest, most
reliable turns (99% on-time delivery) and a competitive price. And we prove it every day,
with every PCB we ship.
Comprehensive quality checks are throughout our PCB prototype manufacturing processes
– never in the price. Every multilayer board we produce ships with our
unique Evidence of Quality reports – the results of each of these tests.
Microsection Analysis report such as the one featured here, is one test that
provides proof your board meets or exceeds your specifications.
In fact, it is our commitment to total quality that enables us to run our
operation so cost-effectively. And that comes back to you in our
competitive prices.
We’d like you to know more about our commitment to quality, our range
of technology and our 99% on-time track record of delivery. We’d like
you to know why our equipment, our people and our processes are
without parallel in the industry.
For proven quality that never costs extra, put
Sierra Proto Express on your team today.
To start a relationship now, please call a
Sierra Proto Express experienced Account
Manager at 1.800.763.7503, e-mail your files
to files@protoexpress.com, and visit us at
www.protoexpress.com
Microsection
14 Layer Board
C
ircuit Cellar contest participation is truly an international affair. On average, 50% of the entries and 50% of the prizes go to international
participants. Following a recent contest, I contacted one of our international winners from China to tell him the good news. After getting to know
the winner via e-mail and phone calls, it occurred to me that he could help me reach out to other Chinese engineers interested in our design
contests. Im happy to say that I now have a new Circuit Cellar contest coordinator for China. He directly promotes our contests to the Chinese
technical community, but, more importantly, he now does the physical sample distribution for China.
In accomplishing his new role, he is setting up a Chinese web site. Primarily in English (because contest entries have to be submitted in
English), the site is structured very much like youd expect a contest promotion site to look. It also includes an in-depth Frequently Asked
Questions section to help explain our design contest concept to Chinese engineers. Ive been writing the answers for many of these FAQs
myself just to make sure there is nothing lost in the translation.
This morning I got another FAQ to answer that I found very interesting: How do I protect the intellectual property of the entry? Will I lose
the intellectual property of the project if the circuit charts and source codes are exposed publicly?
My first reaction was to chuckle. Someone from the one place on Earth with the greatest problem of copyright piracy wants an FAQ
answered on how to protect his intellectual property (grin). In all fairness to my friend in China, however, this was an unfair and fleeting thought.
The best answer I could give to quell any nervousness was to explain exactly how we treat contestants intellectual property. Only by demon-
strating that you believe in protecting the IP of others do you create a system that protects your own.
One of the prime tenets of a Circuit Cellar-conducted contest is that the contestants always retain the intellectual property rights to their
projects, even if they grant us publishing rights or win prizes. When it comes to this contest FAQ, however, I dont think the answer should deal
with the legality of protecting design IP. Rather, it should convey a practical understanding of what the real intellectual property is in a contest
project.
One of the hardest things for engineers to understand is that their ideas usually arent unique. Most designs arent instantly commercial-
ized and put into production simply because of their sheer existence. Even if you patent a design, it doesnt keep someone from using that
design for personal use. It is only in the realm of commercial exploitation of patented designs where there is potential protection (to the limits
of your legal budget).
Posting a project complete with schematics and source code doesnt mean youve instantly given away your intellectual property rights. Im
not a lawyer, but I believe there is a certain window of time between presenting something publicly and it being considered public domain. In
fact, the presentation itself often certifies the invention date should the design really have some commercial value.
The more practical value of posting design projects is that it is a public exhibition of your competence as an engineer or programmer. A
number of contestants have sent us testimonials about how they have received job offers, consulting positions, and manufacturing opportuni-
ties after we posted their contest projects.
In all deference to people who think their ideas are unique and need to be protected from theft, it doesnt happen that way. Any honest
manufacturer wants a documented design trail before investing big dollars to put something into production. Companies are interested in
reducing design-to-manufacture time and costs, not stealing designs. The way that virtually all of them do this is to either hire the entrant who
designed the project or license the concept from him to eliminate potential conflict later on. Ninety-nine out of 100 times, the company will still
redesign whatever it was, but youll have gotten the job or some other tangible benefit from exhibiting your capability.
Posting a contest project provides exposure and opportunity. The real IP in a contest isnt the schematics and code, but rather the knowl-
edge and expertise you bring to the table.
Intellectual Property
PRIORITY INTERRUPT
steve.ciarcia@circuitcellar.com
96
Issue 159 October 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
by Steve Ciarcia, Founder and Editorial Director
Wyszukiwarka
Podobne podstrony:
circuit cellar1990 10,11
circuit cellar2002 10
circuit cellar1996 10
circuit cellar1995 10
circuit cellar2004 10
circuit cellar1991 10,11
circuit cellar1992 10,11
circuit cellar1994 10
circuit cellar1993 10
circuit cellar1997 10
circuit cellar2001 10
circuit cellar2000 10
circuit cellar1990 10,11
circuit cellar1991 10,11
circuit cellar2003 10
circuit cellar1994 10
circuit cellar1997 10
circuit cellar1993 10
więcej podobnych podstron