7
9
25274 75349
0 1>
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)
EMBEDDED APPLICATIONS
Frequency Modulation
ARM-Based Devices
Electric Airplane
#150 January 2003
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
hile we were picking a cover concept for the fif-
teenth-year celebration (after narrowing it down to
crystal—for the Emily Post fans—champagne flutes or
festive fireworks, we went with the unsubtle theme), I looked
back at the early days of the magazine to see what made it such a success.
What began as a 40-page bimonthly journal in January 1988 quickly grew in
volume and prestige. In fact, in just two short years,
Circuit Cellar had expand-
ed to 88 pages. In this business, you have to keep up with the exponential
pace of progress; one calendar year is more like two years in Silicon Valley.
In those beginning years, we went through several changes, including our
title. The magazine was introduced as
Circuit Cellar INK—Microcomputer
Applications, but became Circuit Cellar INK—The Computer Applications
Journal in July 1988. Eleven years later, we dropped the “INK,” changed the
tag line, and became
Circuit Cellar—The Magazine for Computer Applications.
Over the past 15 years, our ardent readers have pushed us to remain at
the forefront of the engineering magazine industry. Our position as a rep-
utable resource for engineers has helped us continue to attract talented,
innovative designers to write articles. We’ve developed a close relationship
with many of these designers, and have asked a handful of notables to join
us as columnists.
In the premier issue, readers were introduced to columnist Ed Nisley’s
expert designs with his article, “High Security on a Budget—Build a Video
Hand Scanner/Identifier.” Jeff Bachiochi and Tom Cantrell also appeared in
the first issue as editors; but their engineering prowess quickly awarded
them writing duties, making them an integral part of the magazine’s early
success. By issue 5, Jeff’s hands-on approach had earned him his own col-
umn, “From the Bench.” A year later, readers got their first dose of Tom’s
“Silicon Update.” Then, in 1995, Fred Eady caught our attention with his arti-
cle, “Take Your PIC—A Look at the PIC16C
xx Family.” His enthusiasm and
skillfullness so impressed us that we asked him to join our burgeoning staff
to write the “Applied PCs” column.
Throughout the years, our columnists have evolved with the industry, giving
us fresh, pertinent material month after month. It’s a tough job, especially con-
sidering they’ve had to keep up with about 30 years’ worth of progress. I want
to take this opportunity to thank them for their tireless efforts.
Circuit Cellar cer-
tainly wouldn’t have gotten to where it is today without their dedication.
A special thanks also goes to our feature writers for their contribution
and impressive loyalty. Readers who have been with us since the beginning
should also recognize the names of some of our staple feature writers—
those guys who consistently give us outstanding projects to read about.
Names like George Novacek and Tom Napier come to mind. Together,
George and Tom have written nearly four dozen articles, each offering use-
ful experiences to draw from. And in this celebratory issue (by the way, it’s
also our one-hundred-fiftieth issue), we’ve made sure to give you the very
best of Jeff, Fred, George, and both Toms.
Here’s to another 15 years!
4
Issue 150 January 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
ADVERTISING SALES MANAGER
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) 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
TASK
MANAGER
Cover photograph Ron Meadows—Meadows Marketing
PRINTED IN THE UNITED STATES
w
Fifteen Moore Years
jennifer.huber@circuitcellar.com
CANbus
Starter Packs
PCI/ISA/PCMCIA/PC104/
VME/cPCI format boards.
Software drivers for most OS’s.
CAN/Ethernet bridges, etc.
Saelig Company
brings you unique,
easy-to-use control and instrumentation
products to USA, mostly from Europe,
but now from worldwide. (Need USA
sales help - overseas companies?)
Our customers comment
on our unrivalled FREE
after-sales support.
“Hi - I’m Alan
- you can email me at
saelig@aol.com for free
advice for your control or
measurement problem.”
www.saelig.com • saelig@aol.com
• Plug directly into PC
—
self powered!
• Drive any RS422
or RS485 devices.
• Send control and data
100s of feet!
K422/K485, 25pin > 9pin . . .
$
69
K2 9pin > 9pin . . . . . . . . . .
$
69
Isolate RS232/422/485 signals
K4xx-ISOL 25pin
self-powered . . . . . . . .
$
139
NEW! 9p-9p K3-ISOL - $129!
Make PCs
talk I
2
C
easily!
RS232 to RS422/485
self-pwrd converters
• Store analog/digital
/GPS or CANbus data
on FlashATA cards -
read on your own PC!
• > 100 customizable
software modules—
finish REALLY quickly.
• 8ch 10bit A/D, 33 I/Os, I
2
C, 2 x
RS232, interrupts, sleepmode,
pre-emptive multitasking, easy to
attach LCD or keypad.
• CANbus adapter—recompile or log
data over huge network!
PCMCIA
Datalogger TDS2020
lowpower PCcard logging
PC-based
Instruments
ADC-10
8-bit
$
85
through
ADC-216
16-bit
$
799
—display
scope, spectrum and meter
simultaneously. Connect to PC
parallel
port
and
start
gathering/displaying
data
immediately!
• EnviroMon
temperature
logging/alarm system
standalone or with PC.
•
TH-03
thermistor-
to-PC converter
•
TC-08
8x thermocouples
N
O
W
!
G
P
S
L
o
g
g
i n
g
check out what’s new at www.saelig.com!
Industry-standard card for PC’s
ISA/P-port/PCI versions
2-6V I2C bus versions
• Master, Slave or Bus monitor
• Control or program I
2
C devices
ICA90/93LV - PICA90/93LV PCI90/93LV
- from
$299!
USB ic’s
USB <> RS232 easily!!
US232: USB <> RS232 cable
$35
SMD PCB adapters
for prototyping
“How
to I
2
C”
www.saelig.com
by
Janz
for
all
com
puters
DrDAQ plugs into a PC for useful
datalogging at school, college,
industry. Built-in sensors for light,
sound, temp. or add pH sensor and
run one of the many
suggested
science experiments!
- only $99!
DrDAQ
Educational
Datalogger
with built-in
sensors!
www.drdaq.com
NEW!!
12-bit
100Ms/S
dual-ch
scope
adapter
ADC-212/100
$1015!!
WILKE TIGER MODULES
multitasking powerful BASIC building blocks
BASIC Tigers
are
tiny multitasking
computer systems
for quick project
d e v e l o p m e n t .
Powerful features and low
prices make Tigers a number
one choice for developers: super-fast
development cycle, high reliability products,
>100,000 instructions/s, up to 38 I/O lines,
A/D, D/A, I2C, SPI, , text/graphic LCD inter-
face, up to 50,000 lines of BASIC, RTC/watch-
dog timer. Easy connection and software for
Expansion Modules
for CANbus, TCP/IP for
net-access, opto-I/O, 64 analog inputs, 64 dig-
ital outputs, high-current outputs, etc.
TIGER Starter Kits start from $159!
NEW!
Euroquartz filters/crystals!
Remote control & data acquisition
BIT
link
®
power & data
on two-wire
control network
2-year
self-contained
DATALOGGERS for volts, switch-
closures, events, flow, pressure, etc.
See www.abidata.be for details
6
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
Use Frequency Modulation to Send
ASCII Data
The PSoC RangeFinder
A Simple Ultrasonic Distance Meter
AVR Video Generator
Teaching Programming and Graphics
Embedded XML
Make your Customer’s IT Department Happy
ARMs to ARMs
Part 3: Working in the World of ARM
I
I
APPLIED PCs
Construct an ATA Hard Drive Controller
I
GUI Interfacing
A Straightforward, Simple Solution
I
COLUMNS
ISSUE
Task Manager
Jennifer Huber
Fifteen Moore Years
Advertiser’s Index
February Preview
Priority Interrupt
Steve Ciarcia
Inside the Box Still Counts
4
8
11
94
96
150
12
26
40
32
FEA
TURES
Contest Related Articles
72
78
44
52
18
58
68
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.
INTEGRATED SYNTHESIZER
The AD9858 is an integrated synthesizer that is the
first solution to feature a 1-Gsps direct digital synthe-
sizer (DDS), 10-bit D/A converter, fast frequency hop-
ping, and fine-tuning resolution functionalities on a
single chip. The low-cost synthesizer performs at more
than triple the speed of previous solutions, without
increasing power dissipation.
The AD9858 DDS is a flexible device that consists of
a power-efficient DDS core, a 32-bit phase accumulator,
a 14-bit phase offset adjustment, and a 1-Gsps 10-bit
DAC. It features an analog mixer capable of operating at
2 GHz, a 150-MHz
phase-frequency detector
(PDF), and a programma-
ble charge pump (CP)
with advanced fast-lock
capability. These RF
building blocks can be
used for various frequen-
cy synthesis loops or as
needed in system design.
The new DDS can
directly generate fre-
quencies up to 400 MHz
NEWS
8
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
NEW PRODUCT
Edited by John Gorsky
when driven at a 1-GHz internal clock speed. The refer-
ence clock can be derived from an external clock source
of up to 2 GHz by using the on-chip divide-by-two fea-
ture. The on-chip mixer and PFD/CP make possible a
variety of synthesizer configurations capable of gener-
ating frequencies in the 1- to 2-GHz range or higher.
The AD9858 is easily configured by writing data to its
on-chip digital registers that control the operations of
the device. In addition, it can be programmed to oper-
ate in Single-Tone mode or in Frequency-Sweeping
mode. To reduce power
consumption, there is
also a programmable Full-
Sleep mode.
The AD9858 is avail-
able in a 100-lead EPAD-
TQFP at $49.50 per unit
in 1000-piece quantities.
Use the Cypress PSoC
™
instead of an MCU for
more flexibility, fewer parts and lower cost.
The versatile PSoC
™
Programmable System-on-Chip
™
microcontroller, winner of EDN magazine’s Innovation
of the Year Award in the 8- and 16-bit microcontroller
category, is the world’s first MCU that lets you custom
configure the exact part you need.
Graphically select, place, and interconnect
the peripherals you want and adapt the
architecture with PSoC Designer
™
software.
Dynamically reconfigure a single PSoC
chip multiple times—changing functionality
on the fly in any application.
Reduce BOM cost by reducing the number
of external components.
MCU
later.
There are many more blocks to work with—
and thousands of MCU configurations. To learn more
about our innovative PSoC solutions and to enter a
drawing to win a free PSoC Development Kit
Customized MCU Design In 20 Minutes or Less.
Build your custom PSoC
™
microcontroller with
programmable analog and digital functions from
our extensive mixed-signal library.
Cypress, PSoC, Programmable-System-on-Chip, and PSoC Designer are trademarks of Cypress Semiconductor Corporation. ©2002 Cypress Semiconductor Corporation.
10
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
NEWS
NEW PRODUCT
CAPACITIVE SWITCH ELEMENT
The CSE15 uG (Capacitive Switch Element under
glass) is a capacitive momentary/latching switch with-
out mechanical parts that could lead to a functional
failure caused by damage, freezing, or wear and tear.
The switch is actuated by touch or simply approach-
ing the surface under which it is mounted. The sensi-
tivity of the CSE uG can be adjusted. For example, it
is possible to operae the CSE uG behind an overlay up
to 20-mm thick, even when the opera-
tor is wearing gloves. Any nonconduc-
tive materials (e.g., glass, plastic,
wood, ceramic, etc.) may be used as a
base for the overlay.
The CSE uG comes with point illu-
mination in serveral colors. (LEDs are
positioned in each of the four cor-
ners.) It can be permanently illumi-
nated for use in dark environments.
Connecting the illumination directly
to the switched ouput signal will
result in an on/off feedback. All elec-
SUBCOMPACT SBC
The Gene-6320, is one of the first SBCs in the 3.5
″
FDD
form factor to use either the Intel Celeron ULP 300-MHz
processor or the Mobile Intel Pentium LP 700-MHz
processor. This diminutive board features an integrated
AGP-2X 2-D/3-D graphics accelerator, 24-bit TTL and
LVDS LCD support, NTSC/PAL TV output, PCI audio,
Type II Compact Flash socket, and Gigabit Fast Ethernet
or Fast Ethernet. It also features two COM ports, one
multi-mode parallel port, two USB ports, and one IrDA
port. The clever design of the Gene-6320 allows it to be
produced in one of four different feature configurations.
The Gene-
6320 has superi-
or features, per-
formance, and
expandability
with a PCI-104
connector; yet it
still requires
only 5-VDC
input power
(fanless opera-
tion only) in a 5.75
″
× 4
″
(146 mm × 101.6 mm) size. This
latest in a series of subcompact boards promises to fulfill
the growing needs of POS/POI, kiosk, networking appli-
ance, multimedia, industrial automation, medical appli-
ance, car PC, and gaming markets for years to come.
AAEON Electronics, Inc.
(732) 203-9300
www.aaeon.com
LED MiniMeters
The LM15 MiniMeter is a low-cost LED designed to
replace fragile analog/mechanical and expensive digital
panel meters. It is mounted on a panel.
The LM15 features an integral display and current
transformer. It is housed in a rugged water-clear poly-
carbonate shell less than 1 square inch. The LM15 dis-
plays AC load curents up to 15 A for either 50- or 60-Hz
service. Five-amp (LM5) and 20-A (LM20) models are
also available. A companion model, the VM120, dis-
plays line voltage from 50 to 150 VAC.
The display is self powered so no additional compo-
nents are required. A tiny portion of the load current is
used to illuminate the display’s colorful LEDs. The
LED segment colors can be customized in volume
orders. The LM15 is C-UL listed, double insulated, and
available with CE marks to meet safety requirements
worldwide. The meters also can be installed with gas-
kets or encapsulated for sealed applications.
All MiniMeters can be installed without tools.
Electrical connections are made by quick-connect
blade terminals. A single brass spring retainer is
used to mount the unit. Panel thickness of over
0.25
″
can be accommodated.
The MiniMeters are
priced at $20 in low vol-
umes and under $15 in
10,000-piece quantities.
Avatar Engineering Corp.
(978) 590-7060
www.avatarengineer.com
tronic parts are completely molded into a compact
plastic frame, making the assembly impervious to
dust, dirt, moisture, and heat.
This newest variation allows for even smaller center-
to-center switch spacings. The switches can be arranged
for a grid of 15 mm × 15 mm with a simple connection
system using a PCB connector; thus you avoid expen-
sive installation costs associated with mounting single
switches. The PCB connector can be
integrated to the base PCB, which
allows the single switching array to be
mounted using a simple plug-in tech-
nique. The CSE uG is ideal for use in
public areas, medical applications, and
for POI and POS.
Pricing for the CSE uG starts at $25
for 50 pieces.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
11
Problem 3
Open circuit stubs are preferred
for lines such as microstrip/stripline. True or
false?
Contributed by M.K. Suvarnakumar
Problem 4
Multiple reflections take place
between a quarter wave matching section and
the load even when the line is actually matched.
True or false?
Contributed by M.K. Suvarnakumar
Whats your EQ?
The answers are posted at
www.circuitcellar.com/eq.htm
You may contact the quizmasters at eq@circuitcellar.com
CIRCUIT CELLAR
T
T e
ess tt Y
Yo
ou
urr E
E Q
Q
Problem
1
Which of the following techniques
is preferred for nullifying the effects of a disconti-
nuity in a waveguide?
a) Tuning Posts
b) Irises
c) Bends
d) None
Contributed by M.K. Suvarnakumar
Problem 2
Impedance inversion is offered by
which of the following stubs?
a) 1/8-wave
b) 1/4-wave
c) 3/8-wave
d) 1/2-wave
Contributed by M.K. Suvarnakumar
Edited by Dave Tweed
12
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
n many of my
articles, I’ve
described the con-
struction of devices that I
now use on a daily basis. Readers who
follow my instructions should end up
with useful instruments. I’ve also writ-
ten tutorials on neat technology, leav-
ing the applications to the reader’s
imagination. This article started out as
the former but ended up as the latter.
Some years ago, I bought a pair of
25-kHz ultrasonic transducers with the
intention of transmitting data from a
robot over distances of a few hundred
feet. At that range, ultrasound seeming-
ly had advantages over infrared or radio.
In practice, the transducers’ narrow
bandwidth limits the data rate, multi-
path interference causes huge variations
in signal strength, and the link must
cope with the Doppler frequency shift
produced by the robot’s movement.
I built an ultrasonic transmitter that
used a PIC as a variable frequency
oscillator. Using frequency-shift key-
ing (FSK), the transmitter sent data at
300 bps. I worked on a receiver, but I
never finished it. The project was fea-
sible, but I couldn’t justify the amount
of work it would take to complete it.
Nevertheless, the project prompted
an article in which I described the PIC
oscillator (Circuit Cellar 99). In this
article, I’ll discuss FSK modulation
and show you how it can be used to
send ASCII data.
NORMAL VS. FUN MODULATION
I spent the first half of the 1990s
developing equipment to recover data
transmitted from distant spacecraft.
The signal modulation was a variety
of quadrature phase shift keying
(QPSK) at data rates ranging from 10
to 420 million bps.
QPSK has the advantage that the
transmitter always runs at its maxi-
mum power level without needing to
be linear. The signal bandwidth is fair-
ly narrow for a given data rate. A
wider bandwidth can improve the sig-
nal-to-noise ratio at the receiver, but,
for most applications, you should min-
imize the bandwidth used to transmit
your data. In addition, it’s important
to avoid creating spurious outputs
beyond the specified bandwidth.
A QPSK modulator is simple enough,
but you need fairly complex circuits in
the receiver to lock to the carrier phase
and bit rate. FSK is easier to understand
and a lot easier to implement.
In FSK, you send a 0 bit as a burst of
one frequency and a 1 bit as a burst of
a different frequency. You could trans-
mit using two widely different and
unrelated signal frequencies, but this
would tie up two separate spectral
areas. It would also generate noise over
a wide band every time a data transi-
tion happened to fall near a peak in
either tone. Using coherent FSK elimi-
nates the latter problem (i.e., the fre-
quencies and phases of the two tones
are chosen so that the output wave-
form is continuous during modulation).
At first glance, you might consider
synchronizing the zero crossings of the
tones to the data transitions; however,
that would give you a waveform with
discontinuous changes of slope. The
standard method is to switch frequen-
cies at the waveform peaks where the
slope of both tones is zero (i.e., use a
cosine wave rather than a sine wave).
A moment’s reflection will show
you that coherent FSK requires both
tones to be multiples of one-half the
bit rate. If a bit contains an even num-
ber of half cycles, the waveform will
Use Frequency Modulation
to Send ASCII Data
i
Several years ago,
Tom completed an
ultrasonic transmitter
project built around a
PIC16C84. Now, he
returns to this subject
to explain the impor-
tance of frequency
modulation and
describe how it’s used
to send ASCII data. In
his latest project, Tom
switches to a ’16C54.
Tom Napier
FEATURE
ARTICLE
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
13
wave at a rate three or more times the
output frequency. It continuously adds
a number proportional to the desired
frequency to a phase accumulator reg-
ister, causing it to wrap around one
time per output cycle. The register’s
contents are translated into sine wave
samples using a hardware or firmware
look-up table (LUT). A DAC and low-
pass filter convert the samples into
the desired analog output. Changing
the number that’s added to the regis-
ter changes the output frequency.
A commercial NCO chip adds 24-bit
numbers in 15 ns or less. You can do
the same trick with a firmware loop
that takes 16 instructions. Because
your PIC won’t run faster than 5 mil-
lion instructions per second, the best
sample rate you can achieve is about
300 kHz. Note that an NCO chip runs
about 250 times faster.
In my original PIC NCO design, the
phase register had 24 bits, allowing
arbitrary frequencies to be set in
0.01-Hz increments. I need only two
closely related frequencies in a modem.
My resolution is 600 Hz, not 0.01 Hz,
so the phase register needs only 8 bits.
Not having to carry from register to
register saves many instructions.
I chose to use a readily available
19.6608-MHz crystal. This is the high-
est frequency the PIC can handle; it’s
also a nice multiple of 9600 bps. At
start and end with the same phase (i.e.,
either 0° or 180° if you’re talking about
cosines). If a bit contains an odd num-
ber of half cycles, the phase will differ
by 180° between its two ends. This is
tricky to achieve unless you implement
a numerically controlled oscillator
(NCO), which automatically preserves
the phase at frequency transitions.
If you’re one of my older readers, you
should be feeling déjà vu by this time.
Pre-IBM home computers (and the first
IBM) used audiocassette recorders as
data storage devices. The coding system
was often FSK (e.g., a zero was a burst
of 1200 Hz and a one was a burst of
2400 Hz). In the extreme case, a bit was
a single cycle of 1200 Hz or two cycles
of 2400 Hz. Early modems used a simi-
lar method to send data over phone
lines at 300 bps. (I liked 300 bps, you
could read e-mail as fast as it arrived.)
THE MINIMUM SHIFT
Assuming phase continuity, the min-
imum possible frequency difference
between the two tones occurs when
one is one-half the bit rate higher than
the other (i.e., minimum shift keying
(MSK)). The resulting signal spectrum
is a symmetrical peak with nulls at
three-fourths of the bit rate on either
side of the theoretical center frequency.
At gigahertz frequencies, MSK is gen-
erated from the carrier by using a bal-
anced modulator to add or subtract a
sine wave at a quarter of the bit rate.
The data bit determines whether to add
or subtract. At low frequencies you just
generate one of two cosine waves.
WHAT SHALL WE BUILD?
So, what would make a useful MSK
demo system? My abortive robot link
used twice the minimum tone separa-
tion. (I misinterpreted the textbook
definition of MSK!) It sent 300-bps
data using two frequencies near the
transducers’ 25-kHz resonance. A 0 bit
was 83 cycles of 24.9 kHz, while a 1 bit
was 84 cycles of 25.2 kHz.
I use 9600-bps links between my
various computers and other devices,
so I decided to take that as my target
rate. The necessary waveforms are
generated using a PIC chip and DAC.
As I'll explain in a moment, a 1 bit
should have four (or a multiple of
four) cycles. Thus, a 0 bit has either
3.5 or 4.5 cycles. Picking 4.5, the two
tones become 38.4 and 43.2 kHz.
PUSHING THE PIC
Unlike the ’16C54 oscillator in my
1998 article, which went offline when-
ever a new frequency was entered, this
PIC accepts serial input bits and selects
the correct frequency on the fly.
To recap briefly, an NCO generates
samples that define the output sine
Figure 1—This PIC/DAC/filter combination will be familiar to most Circuit Cellar readers. Here, it generates a modulated frequency to transmit 9600-bps data.
14
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
with a zero-level start bit and ends
with a stop bit at the “one” level.
Most EIA-232 driver/receiver chips
invert when converting to and from
TTL levels so the PIC will treat a TTL
high as a data one. Therefore, a start
transition is from high to low.
LOCKING UP
By making the “one” frequency four
times the data rate, each output cycle
corresponds to a quarter of a bit. In its
standby condition, the PIC checks the
input at the end of each cycle. When a
start transition is detected, it waits an
additional quarter bit and then starts
sampling the input once per bit for the
next nine bits. This guarantees that
every input bit will be sampled just
before its midpoint. If the bit is a zero,
the PIC generates the higher clock fre-
quency for 32 samples (one bit period);
otherwise, it generates the lower fre-
quency for 32 samples.
This process ends somewhere
around the middle of a character’s
stop bit. At least one low-frequency
cycle is generated before the input is
sampled to check for the start bit of
the following character.
Continuous data presents a slight
problem, because the input data rate
can be marginally faster or slower
than the rate at which the PIC is
generating output bytes. With this
algorithm, the worst that can hap-
pen is that the PIC will output a stop
16 instructions per sample, the sample
rate becomes 307,200 per second.
Each bit period contains 32 samples.
At 38.4 kHz, there are eight samples
per cycle and the register increment
number will be 32. To get 43.2 kHz,
the increment number must be 36.
These are both divisible by four, so I
can get away with a 6-bit phase regis-
ter. With only 64 possible register
states, a 360° conversion table is prac-
tical. This speeds up the code signifi-
cantly, because it avoids the sign and
table direction switching that were
needed in my earlier design.
SERIAL DATA INPUT
Before I get to the frequency-generat-
ing part of the loop, let’s look at what
else the PIC needs to be doing. If I had
a constant stream of input data at
9600 bps and everything was synchro-
nized, all would be well. Unfortunately,
the transmitting device sends bytes
whenever it feels like it. There’s no
guarantee that the time between bytes
is an even multiple of a bit period.
The PIC must synchronize itself to
the input data and churn out a phase
sample every 16 instruction times,
despite whatever else is going on.
Using EIA-232 (formerly RS-232)
levels, a negative signal (–12 V) sup-
posedly corresponds to a data one. A
positive signal (12 V) is a data zero.
The line remains at the “one” level
between data bytes. Each byte starts
bit that’s three or five cycles long
rather than four. Normal UARTs
shouldn't mind this.
GETTING AN OUTPUT
An 8-bit DAC hanging on the PIC’s
port B converts the cosine sample to a
current (see Figure 1). Just about any
parallel DAC will do. I used the $2
DAC-08 (a.k.a. National Semiconduc-
tor’s DAC0800). Because this needs a
negative power rail to supply its out-
put current source, 5- and –5-V sup-
plies are needed. If you’re using an
EIA-232 interface, you’ll have a nega-
tive supply available, even a MAX232
driver chip generates it.
One trick I’ve used is to hang a volt-
age doubler on the most significant
PIC output bit. This supplies around
–2.7 V, which is iffy but generally
enough to make the DAC work.
With eight or so samples per cycle,
the DAC output requires little filter-
ing. I used a 70-kHz, three-pole Bessel
filter because both frequencies must
be delayed by the same amount (for
the best results). The output is 2 V
PP
from the output of an op-amp, which
is enough to drive the chosen commu-
nications device.
NOW FOR FIRMWARE
Because I’m using a single-byte
phase accumulator and a full-cycle
LUT, the inherent instruction count
per sample is quite low. This time, I
didn’t use my combined table look-up
and loop repeat trick because I wanted
to call the LUT from several places.
The basic output loop takes
14 instruction times, so it has two
NOPs to pad it to 16. Before it starts,
it must be told the frequency and how
many samples to generate. There are
three loops. The standby loop is one
output cycle long; it repeats indefi-
nitely until a start bit is received.
The delay loop, inserted when a start
bit has been detected, generates one
more cycle to shift the bit test point
closer to the center of the bit. The
main loop generates the high or low
frequency as needed for one bit peri-
od. It decrements the bit count and
hands back to the standby loop after
9 bits have been processed. The stop
bit is a special case.
Figure 2—A comparator and PIC make a simple FSK demodulator. The transformer is optional, and the input can
be AC coupled to the comparator.
16
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2003/150/.
SOURCES
MAX232
Maxim Integrated Products, Inc.
(408) 737-7600
www.maxim-ic.com
PIC16C54 Microcontroller
Microchip Technology, Inc.
(480) 792-7200
www.microchip.com
DAC0800 D/A Converter
National Semiconductor Corp.
(408) 721-5000
www.national.com
SECRETS OF A PIC ADDICT
All of these loops have extra jobs to
do. How do I fit them in? The secret
is that at the start of a cycle, you
don’t need to perform a time-consum-
ing table look-up, because you know
that the first phase sample is either 0°
or 180°. Every loop starts with code
containing the special functions that
are needed. Then, it generates the
first sample, either plus or minus full
scale, and jumps into the loop that
supplies the rest of the cycle or bit.
Such time-critical code with loops
within loops is difficult to write and
debug. I left the DAC’s inverted out-
put pin unfiltered; it made an invalu-
able firmware test point. Every
instruction counts, and every opera-
tion must occur in the right order.
Groups of instructions must be exam-
ined to see if they can be postponed
and moved to a less time-critical spot.
And, silly things can go wrong.
At the start of each bit, I updated
the frequency from the input data,
incremented the phase, and sent out a
sample. Wrong! The phase of the zero
sample of each bit is derived by adding
the previous frequency increment,
not the new one. Reordering events
added a seventeenth instruction to
the loop, forcing yet another loop to
be partially unrolled. And so on.
AT THE RECEIVING END
In my original ultrasound scheme,
the high and low tones were separat-
ed by the bit rate. The data frequency
discriminator was a 74HCT4046 PLL
chip locked to the lower signal fre-
quency. One bit’s worth of the higher
frequency resulted in a signal phase
shift of 360°.
Using the appropriate type of phase
detector—the chip has three—pro-
duces a bipolar error signal for each
0 bit. Because this has no net DC com-
ponent, the VCO’s frequency remains
unchanged. This is the dreaded “false
lock” phenomenon that’s a pest in
data receivers. Here, it comes in
handy. Filtering one of the other phase
detectors produced a triangular pulse
for each 0 bit. This triggered a mono-
stable to regenerate the NRZ input.
This time around, the tone separa-
tion is one-half the bit rate; a 0 bit
generates only a 180° phase shift. I
put in a frequency-doubling trans-
former and got everything to work,
but it took plenty of filters and com-
parators to get a clean ASCII output. I
couldn’t help thinking there must be
an easier way.
A PIC TO THE RESCUE
It struck me that I could filter the
phase detector output—a PWM TTL
signal—with a PIC-based digital filter.
It took another 30 s to realize that the
PIC was fast enough to discriminate
the input frequency all by itself. The
PLL handled Doppler shifts and noise,
but for most applications it’s suffi-
cient to amplify and limit the input
and then measure the period of the
resulting square wave. The ensuing
receiver is shown in Figure 2.
The firmware continuously meas-
ures the period of the input cycles.
Whenever two consecutive cycles are
both above or below a threshold
length, a 1 or 0 output bit is generat-
ed. Periods are measured by waiting
for an up transition, reading the PIC’s
timer, waiting for a second up transi-
tion, and then rereading the timer.
This allows for an unsymmetrical
input waveform. The timer reading at
the end of one cycle becomes the
start reading for the next.
The PIC’s timer increments at the
instruction rate every 203 ns, while
the wait loop timing resolution is
about 600 ns. One period of the low
frequency contains 128 timer counts.
Because the high-frequency period
contains fewer than 114 counts, the
two are easily distinguished.
THE DOWNSIDE
One advantage of the analog PLL
approach is that its timing is consis-
tent (i.e., the output bits closely follow
the timing of the original input bits).
The moment the PIC generates an
input bit can vary by half a tone peri-
od, an eighth of a bit period, producing
jitter in the resulting ASCII output.
This is not easy to eliminate. In
principle, the PIC could store and
retime the output bytes. However,
because it’s running from an inde-
pendent clock, it might generate out-
put bits slower than they’re being
received, resulting in the loss of data
no matter how much storage it uses.
This is a common dilemma in
telecommunications systems that
use independent clocks, and it has
already cropped up in the transmitter.
Synchronizing the PIC’s clock to the
incoming signal could obviate it, but
would require putting back the PLL. I
might as well have used it to decode
the data in the first place. I made do
with a jittery output.
ACROSS THE ROOM OR WORLD
I ended up with three PIC16C54
micros hooked together: one generated
9600-bps test strings, another generated
the MSK signal, and the third decoded
it. All were on the same bench top, but
in principle the transmitter and
receiver could have had miles of cable
between them (or a 1000-mile radio
link for that matter). And, a parting
thought: Given a low impedance trans-
mitter, you can use the signal as a
transformer-coupled power source for
the receiver, achieving complete DC
isolation at the remote location.
I
Tom Napier is a former physicist and
embedded systems pioneer. In 1977,
he designed an 8080-based radiation
monitoring system for CERN in
Switzerland. Today, Tom provides
electronics consulting services and
writes about his design projects.
HC08 Q FAMILY OF 8-BIT MICROCONTROLLERS
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.
2002.
• 1.5K–4K of second-generation .5 micron Flash
• 128 bytes of RAM
• Up to 4-ch 8-bit A to D converter
• 2-ch 16-bit timer with input capture, output compare, or PWM
• Trimmable internal OSC (+/-5% accuracy)
• Available in 8-pin DIP/SOIC or 16-pin DIP/SOIC/TSSOP
• 68HC908QT4 demonstration board and tutorial
– CodeWarrior
®
Integrated Development Environment
– C compiler, assembler, linker and debugger
– Auto code generator for on-chip peripherals
– Full chip simulation and Flash programming
HC08 Q FAMILY KEY FEATURES
Efficient. Programmable. Affordable.
Our powerful HC08 Q family of 8-bit micro-
controllers includes six new derivatives,
available now, in volume, and competitively
priced against 8-bit MCUs without Flash.
Available in small 8- and 16-pin packaging
with a full set of peripheral options – and
more are in development. Leading edge
Motorola Flash is easier to program and
is re-programmable in
the field, so products
are “Future Enabled”
to stay in the market longer. Get started for just $25 with the comprehensive
68HC908QT4 Demonstration Kit. Order yours now at www.motorola.com/mcu
JUST WHAT 8-PIN MCUs NEED:
A LITTLE FLASH
.
System Integration Module
External Interrupt
Power-On-Reset
Low-Voltage Inhibit
MON08
COP
Internal RC
128 Bytes RAM
HC08
CORE
2 Channel
16-Bit Timer
• Input Capture
• Output Compare
• Pulse Width Mod.
4K Bytes
FLASH
1.5K Bytes Option
4 Channel
8-Bit ADC
I/
O
Demonstration Kit
18
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
recently
designed a small
Geiger counter for the
purpose of adding radia-
tion detection capability to a robotic
sensing platform. As I worked on the
project, I had the chance to review
some physics concepts, track down
some neat surplus deals, and learn
about Geiger tubes. Although I don’t
claim to be an expert, or even to pres-
ent any new circuit advances, I
thought I would share what I learned
with you. Perhaps you can use this
information in your own projects.
There is no shortage of Geiger count-
er circuits. A quick search on the ’Net
will reveal sources for kits (e.g.,
Velleman), scads of schematics, and sev-
eral sites for used (surplus) civil defense
instruments. Most of the circuits pre-
sented are similar. In them, some sort of
oscillator drives a transformer to pro-
duce an AC voltage between 50 and
100 V. A voltage multiplier chain
boosts this to around 800 VDC, which
is applied to the Geiger tube. An ampli-
fier and/or integrator are used to drive
a meter or speaker.
Most of the circuits I found refer-
enced an obsolete or surplus source for
the tube. This was a problem for my
application, because I required a cur-
rently viable commercial source for
the tube and a much smaller means of
producing the high voltage.
I will share with you my solutions
to these problems later in the article.
Now, before I get into the details of
the circuit, I’ll review some basic
physics concepts and give you a closer
look at the Geiger tube.
NUCLEAR RADIATION
As you probably know, there are
three main types of nuclear radiation:
alpha particles, beta particles, and
gamma rays. Although alpha particles
are the largest and heaviest of the
three, they’re the weakest in energy.
They can travel only a few centime-
ters in the air and are easily stopped
by a sheet of paper. Essentially, these
particles are helium nuclei, consisting
of two protons and two neutrons.
Furthermore, alpha particles are
characterized by their unusually
strong ionizing power; each alpha
particle is capable of producing thou-
sands of ions before absorption.
Capable of traveling 2 to 3 meters in
the air, beta particles are more ener-
getic than alpha particles. You can
stop them with a few millimeters of
aluminum. Another difference is that
beta particles are thousands of times
smaller than alpha particles. They’re
formed when a neutron in the nucleus
of an atom decomposes into a proton
and beta particle (electron). The beta
particle is expelled, and the proton
remains in the nucleus.
Beta particles are able to travel
much farther in air then alpha parti-
cles, but the ionization they produce
The (G)Eiger Sanction
i
Recently, one of Tom’s
customers asked him
to design a Geiger
counter for a robotic
sensing platform. That
request led him on an
exciting journey that
involved everything
from hunting for sur-
plus parts to reviewing
physics concepts.
Now, Tom is ready to
share his experiences.
Tom Dahlin
ROBOTICS
CORNER
Photo 1—The large tube in the back was removed
from a surplus civil defense unit. Saint-Gobain Crystals
and Detectors manufactures the two smaller units. The
20-pin DIP is shown for scale.
The Design, Construction, and
Interfacing of a Radiation Detector
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
19
tube. This electron
then starts the ioniza-
tion avalanche.
Note that Geiger
tubes cannot distin-
guish between parti-
cles, nor can they
determine the energy
level of them.
Nevertheless, you can
filter out alpha and beta
rays by placing the
appropriate absorbing
materials in front of the tube.
RADIATION UNITS
Now that you have an understand-
ing of the Geiger tube as a sensor,
you’re probably interested in learning
how to use it to measure radiation.
Because the Geiger tube is a nonlinear
device that’s sensitive to all types of
radiation, it produces a click for each
ionizing particle that enters the tube,
regardless of its type and energy. You
can count these clicks and equate the
count to a unit of measure, provided
you have a sensitivity specification
from the manufacturer and know the
type of radiation being applied.
Now, let’s briefly review some of
the units you can use to measure and
specify radiation. It’s a bit confusing
because most of the literature on the
subject uses older non-SI units; how-
ever, some of the newer material has
made the switch to SI.
Nuclear radiation is specified in
terms of nuclear activity, absorbed
dose, and dose equivalent. The unit of
activity is the curie (Ci), which is
equivalent to 3.7 × 10
10
nuclear disin-
per centimeter traveled is
roughly one two-hun-
dredth of what alpha par-
ticles produce. Whereas a
thin piece of tin foil will
completely absorb alpha
particles, beta particles
require about 3 mm of
lead to accomplish the
same thing.
Gamma rays are a form
of electromagnetic radia-
tion similar to light and
x-rays. They have a shorter wave-
length than x-rays and aren’t deflected
by magnetic or electric fields. Gamma
rays are high energy and extremely
dangerous. In comparison to the other
two forms of nuclear radiation,
gamma rays can travel hundreds of
meters in the air and penetrate much
deeper than x-rays because of their
shorter wavelength. These rays can
penetrate iron and lead plates that are
several centimeters thick.
THE GEIGER-MUELLER TUBE
The Geiger tube was conceived by
Hans Wilhelm Geiger around 1908.
Then in 1928, Geiger and Walther
Mueller refined the tube. The “Geiger-
Mueller tube” has become the com-
mon name for the device.
Today, the Geiger-Mueller tube
remains the most widely used radia-
tion sensor because it’s sensitive, easy
to interface, and relatively inexpen-
sive. Other types of sensors include
ionization chambers, proportional
counters, scintillation counters, semi-
conductor diodes, neutron detectors,
and spectroscopes. [1]
The classic Geiger-Mueller tube
consists of a glass-encased metal
cylinder in which a wire electrode (the
anode) is inserted axially (see Photo 1).
The center wire, which is depicted in
Figure 1, is electrically insulated from
the metal cylinder. The glass enclo-
sure surrounding it is sealed and filled
with argon gas (and typically a hint of
a halogen). Approximately 500 to
1000 V is applied across the two, and
the center wire is made positive with
respect to the housing.
When an atomic particle enters the
tube, some of the gas atoms become
ionized, producing electrons and posi-
tive ions. The high voltage accelerates
these charges, moving them toward
the tube’s electrodes with the opposite
charge. On their journey, the charges
strike other gas atoms, furthering the
ionization process. This results in an
avalanche, or “gas multiplication,”
that produces a large current flow. The
duration of the current flow is approx-
imately 100 µs. This process is
repeated for each new atomic particle
entering the tube.
The voltage level applied across the
tube determines the tube’s response.
As you can see in Figure 2, there is a
plateau in the characteristic curve that
you want to operate in. A voltage
that’s too low results in no ionization.
If the voltage is too high, breakdown
via self-ionization or arcing will result.
For most tubes, an operating voltage
between 600 and 800 V is typical.
Geiger tubes can detect all three
forms of radiation, but they’re not ide-
ally suited for alpha and gamma detec-
tion. In order to detect alpha particles,
the tube must use a thin mica window
on its end or side. This allows the rel-
atively large and slow-moving alpha
rays to enter the tube. Glass-
windowed Geiger tubes per-
form poorly, or not at all, as
alpha detectors. Gamma rays
blast right through the tube’s
gas content and are so fast and
small that they almost always
miss the gas atoms. However,
gamma radiation can be detect-
ed by virtue of the interaction
of the gamma rays on the
tube’s cylindrical cathode.
When a gamma ray hits the
cathode, it produces an ener-
getic electron that can pass
through the interior of the
+
–
High-voltage
supply
Center wire
+
End seal
Outer cylinder
End seal
Radiation
particle
Figure 1—A wire electrode is inserted axially into a metal cylinder. The ends of the cylinder
are sealed with the center wire insulated. An inert gas, such as argon, is usually used to fill the
tube. A voltage of approximately 800 V produces a potential across the two electrodes.
Start
Counts
Threshold
Breakdown
Plateau
region
V
O
Voltage
Figure 2—The curve shows the relationship between the output
counts and operating voltage. As you can see, too little voltage
results in low count rates. On the other hand, too much voltage
results in a breakdown or arcing. The proper operating voltage is
approximately one-third of the way into the flat plateau; it’s typi-
cally around 500 to 800 VDC, depending on the tube used.
20
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
minute with an absorbed dose rate of
1 milliroentgen per hour (cpm/mR/h),
respectively. This is the result of the
size difference between them. The beta
sensitivities are not provided, although
the tubes are sensitive to beta particles.
CIRCUIT DESCRIPTION
I made two versions of the circuit.
The first was a larger breadboard that
allowed for the quick substitution of
components and easy access to test
points. This version included a Basic
Stamp II for data collection. The sec-
ond version was a miniaturized rendi-
tion of the debugged breadboard that
included SMT components without the
Basic Stamp (a PIC processor was avail-
able to do the Basic Stamp’s chores).
I’ll describe the breadboard circuit
and implementation in this article,
because I haven’t secured permission
to disclose any of the end-use infor-
mation. I use the term “breadboard”
loosely, because I actually laid out a
circuit board. In this day and age of
quick turnaround on two-layer
boards, I find it’s much more produc-
tive to use a board to construct my
prototypes as opposed to point-to-
point or wire wrapping. Ontime
Circuits, an Illinois-based company,
fabricated this board for me. Photo 2
shows the assembled circuit board.
Finding a source for the Geiger tube
was one of the first problems I encoun-
tered. As I mentioned before, most of
the circuits you’ll encounter will refer-
ence obsolete sources for tubes, such
as those made by the Raytheon or
tegrations per second. This is a
tremendous amount of activity. A
more practical unit for lab use is the
becquerel (Bq), which is equal to one
nuclear disintegration per second. The
becquerel is the SI unit for radioactivi-
ty. Thus, 1 Bq = 2.7 × 10
–11
Ci.
A radiation level is typically meas-
ured in terms of an absorbed dose,
which is the ratio of the absorbed
energy in a volume of matter to the
mass of the matter. In SI units, one
gray (Gy) is equal to one joule per kilo-
gram of absorbing material. The older
unit was called the “rad,” which is
equal to 0.01 J/kg of absorbing materi-
al. The absorbing material must be
specified for either unit.
To really confuse you, the term
“roentgen” is often encountered. A
roentgen is a unit of radiation expo-
sure that’s determined by the amount
of ionization produced in the air.
Specifically, it has been defined as the
quantity of radiation that will ionize
dry air at 0°C and standard atmospheric
pressure to produce one electrostatic
unit of charge of each sign (both posi-
tive and negative) in 1 cm
3
. The expo-
sure rate measured at a point in roent-
gens per hour is numerically equal to
the absorbed dose rate in rad per hour
at that point for external sources of
radiation. The meters in older civil
defense instruments are often calibrat-
ed in roentgens per hour (r/h).
Finally, the dose equivalent units
are the “seivert” (Sv) and the “roent-
gen equivalent man” (rem). Although
the seivert is the SI unit, rem is
encountered more often, especially
when you’re dealing with older litera-
ture. These units consider the effects
of the different types of radiation on
living tissue and incorporate a biologi-
cal effectiveness factor, or Q. This Q
factor is one for beta and gamma rays,
and 20 for alpha rays. Note that alpha
radiation is a more powerful ionizer
and causes more cell damage.
One seivert is equal to the absorbed
dose in Gy times Q times another fac-
tor (N), which is presently unspecified
and set to one. One rem is equal to
the absorbed dose in rad × Q × N.
Getting back to the real world, the
two tubes I used have gamma sensitiv-
ities specified at 18 and 450 counts per
Mullard companies. I found a U.S.
source on the Saint-Gobian web site
(www.gammalabs.com). The compa-
ny’s subsidiaries manufacture several
different types of tubes, including the
miniature peanut type I required and
larger, more traditional tubes. Photo 1
shows two of their smaller tubes
alongside a 20-pin DIP (for reference)
and the tube from my surplus civil
defense counter. The larger of the two
miniature tubes is a G1320, and the
smaller is a G1300. I used the smaller
unit to save space. The larger tube is
about 25 times more sensitive.
Another challenge was finding a
way to produce the required high-
voltage DC without using too much
circuit volume. An obvious first pass
was to use a 555 driving an audio
interstage transformer followed by a
half-dozen diodes and capacitors in a
multistage voltage multiplier. While
functional, this circuit required too
much board space.
In the middle of the design, I
remembered a few of the articles Jim
Williams wrote on the subject of cold
cathode fluorescent lamp (CCFL) driv-
ers. [2] This sparked (no pun intended)
a quick search in the Digi-Key catalog
for commercially available CCFL
drivers, which in turn resulted in the
discovery of JKL BXA-502. This
miniature marvel produces an approx-
imately 600-V
PP
AC signal from a 5-V
input. Roughly the size of a postage
stamp, it was just the ticket.
Referring to my schematic (see
Figure 3), I found that the CCFL power
supply (U5) likes to have a 1-M
Ω
load
resistor to help it maintain regulation.
This is shown as R3. A voltage-dou-
bler stage—consisting of R8, D1, D3,
C2, and C9—was added to double its
output. This produces about 650 V
across C2. Note that I recently discov-
ered JKL’s BXA-503, which produces
1200 VAC from a 6-VDC input. This
could eliminate the need for a doubler
in future applications.
The Geiger tube I used was the
G1300. The manufacturer suggests an
operating voltage of 550 V and a mini-
mum anode resistor of 2.2 M
Ω
. I
found that using a 10-M
Ω
anode resis-
tor (R6) worked well with the high-
voltage supply.
Photo 2—I elected to use a circuit board to minimize
problems with the high-voltage portion of the circuit that
uses a high-frequency, high-voltage CCFL inverter. The
9-V battery separates the high-voltage section (on the
left) from the logic section (on the right). The Geiger
tube is on the far left.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
21
On the breadboard, I built in the
option of picking off the Geiger pulse
on either the high or low side of the
tube. Resistor R4 is used to facilitate
a low-side pickoff. Jumper JP1 selects
the pickoff to be used. It turns out
that a low-side pickoff works fine and
can be DC coupled (eliminating C11)
into the following stage. A high-side
pickoff is often used if the Geiger
tube’s metal shell is to be kept at
ground potential. If this method is
used, it’s necessary to use a blocking
capacitor (i.e., C10) to couple the
pulse into the following stage. Because
this capacitor is required to be a high-
voltage type, I chose to perform the
low-side pickoff to save space.
When a pulse occurs in the tube,
the tube briefly appears as a short
circuit. The resistor pair of R6 and
R4 then makes up a voltage-divider
chain. When a 650-V supply is used,
R4 will develop about 12 V across it.
Diode D2 clamps this to the 5-V
logic rail to prevent the Schmidt trig-
ger U1 from taking a hit. Resistor R9
limits the current.
The output of U1 (pin 2) is a low
true 100-µs pulse. It’s fed to the 555
circuit and configured as a mono-
stable (one-shot) to stretch the Geiger
pulse to light LED DS1. This provides
a way of observing the circuit’s opera-
tion without software. Also, you can
use a speaker that’s coupled capaci-
tively to the 555 output to provide an
authentic click-click sound.
I also included a Basic Stamp II (U4),
a counter (U6), and an external LCD to
count and display pulses. A dedicated
PIC would eliminate the need for the
counter chip, but I like to have the
ability to modify code quickly when
I’m working with a breadboard. Thus,
I used the Basic Stamp II.
The firmware is trivial. A time
interval for count integration is
selected (i.e., 5, 10, or 60 s). One time
every integration cycle, the counter is
cleared and you enter a pause. At the
end of the pause, read the counter and
display the count. There’s nothing
fancy here. Listing 1 contains a sim-
plified version that uses the debug
statement for I/O. You may download
the rest of the code from the Circuit
Cellar
ftp site.
TESTING AND RESULTS
In order to test the circuit, you need
access to a radioactive test sample.
Access to a known functional Geiger
counter will also help you to determine
if your sample is actually radioactive.
To address this need, I ordered a sur-
plus Geiger counter for $84. This
proved to be a helpful purchase, but
chances are your local high school or
university physics department has
one too. I’ll elaborate on the market for
surplus equipment a little later.
Obtaining a radioactive test sam-
ple was a little trying at first. I got
some interesting reactions when I
called scientific supply companies
asking for radioactive test samples. I
remembered using some in a physics
class back in the ’70s, but they’re
apparently not made or used any-
more. Fortunately, there are some
safe, easy-to-obtain materials that
are mildly radioactive.
Uranium glass, With its characteris-
tic yellow color, was popular after
World War II. You’ll often find pieces
Listing 1—A short Basic Stamp II program resets the counter, waits 10 s, reads it, and then displays the results
on the debug terminal (PC). During the 10-s pause, the counter accumulates pulses from the Geiger tube.
C_Reset
con
8
Counts
var
byte
Loop: High C_Reset
//Clear the counter with a high
Pause 1
//Wait 1 ms
Low C_Reset
//Ready to count
Pause 10000
//Pause 10 s
Counts = INS.lowbyte //Read the count on low 8 bits of INS
Debug "Counts = ",dec Counts,cr
//Write result to monitor
goto loop
22
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
of it in antique stores. I did a search
on eBay and found a shop that sells
radioactive glass marbles. I ordered a
handful for about $12 (see Photo 3).
These marbles produce 45 counts per
minute on my CDV-700 Geiger
counter and about six counts per
minute on my breadboard circuit. As
an aside, it’s fun to give a handful to a
friend and then tell him or her that
they’re radioactive. Just be ready to
pick them up off the floor.
Another good radioactive test
source is orange Fiestaware. The
ceramic glaze that’s used is mildly
radioactive. Older versions of
Coleman gas lantern mantles are
doped with thorium. These are also
good emitters. Rumor has it that
newer versions don’t contain thorium.
The best source I found came with
the Geiger counter. Affixed to the
side of the unit was a small sample of
a radium D and E source that pro-
duces 900 counts per minute on the
CDV-700 and 100 counts per minute
on the breadboard.
Having secured a radioactive test
sample, the rest was easy. After veri-
fying that the Geiger tube had the
proper voltage across it, all I had to do
was bring the test sample close to the
tube and watch for activity coming
from the LED connected to the 555. A
few seconds after doing this, the LED
flashed one time. A few seconds later,
two flashes occurred. There was a
long period before another flash
occurred. Such is the random nature
of radioactive decay. Hooking up the
counter circuit and loading in a Basic
Stamp II program to read and display
the counter was the last step.
20/20
I hope this little article helps you.
I present it to you as documentation
of just one way to make a Geiger
counter. As with any design, hind-
sight is always 20/20, and this one is
no different.
You could use a larger tube for
increased sensitivity. This wasn’t
possible for my miniature applica-
tion, but I recommend it for applica-
tions that aren’t limited by space. If
you want to save power, you could
implement processor control of the
the high-voltage section. Try a FET to
switch on the high-voltage supply for
Figure 3—In the circuit for the breadboard version of the Geiger counter, a CCFL inverter whose output is doubled generates the high-voltage DC. The Geiger tube (G1) out-
put is fed into a Schmidt trigger whose output triggers a 555 pulse stretcher for a visual indication of clicks. The Schmidt trigger output also feeds a counter that’s read by a
Basic Stamp II to drive an LCD.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
23
a brief period every few seconds.
Because the Geiger tube doesn’t
draw too much current, you can rely
on the output capacitor to hold up
the DC in the interim. Obviously, a
Basic Stamp II is overkill; a little 8-
pin PIC could do the job of counting
pulses and driving an LCD.
Finally, the CCFL inverter works
well as an electrical noise generator
in addition to its intended purpose.
But note that careful attention must
be given to leads run near it to avoid
picking up noise.
FROM MY LAWYER
It goes without saying that this cir-
cuit is potentially dangerous. The high
voltage can give you a nasty shock.
The Geiger tube is a dandy capacitor
and remains charged even after the
power is removed. Watch out!
Also, most radioactive sources are
toxic. The Fiestaware and uranium
glass marbles should be safe to han-
dle. Other sources, such as gas man-
tles, must be handled carefully to
prevent the ingestion of particles
through your nose, mouth, or skin.
Use common sense. And if you’re in
doubt about something, seek an
expert’s opinion.
SURPLUS INSTRUMENTS
There’s no shortage of surplus gear
on the market. Most of what you’ll
find was developed for the U.S. Office
of Civil and Defense Mobilization
(OCDM). Apparently, large quantities
of these instruments were manufac-
tured for distribution to local govern-
mental agencies during the Cold War.
It looks as if either too many were
made or the initiative was cancelled
prior to distribution, because I found
dozens of vendors and various kinds
of gear available on the ’Net.
A wonderful resource for surplus
radiological equipment is Lee Frank
(www.surplustuff.com). Lee maintains
a good stock of several OCDM-issue
Geiger counters, scintillation probes,
radiation monitors, and Geiger tubes.
I purchased a used CDV-700-6B
Geiger counter for about $85 (see
Photo 4). Lee was kind enough to
check it out and calibrate it for me. I
used this unit to calibrate my circuit
and search for radioactive specimens.
Note that when shopping for sur-
plus radiology gear, you should make
sure you’re purchasing a true Geiger
counter and not a survey meter. The
latter is much less sensitive because
it uses an ion chamber as a detector.
In fact, if it reads anything at all, you
probably don’t want to be there!
Remember, both types of meters look
similar, so it’s hard to tell them apart
in some ads. Caveat emptor.
I
Tom Dahlin runs a small consulting
company specializing in microproces-
sor, sensor, and motion control
designs. He enjoys weekend retreats
to his cabin, teasing his cats, and
making loud noises with his guitar
and tube amp. You may reach Tom at
tdahlin@isd.net.
Photo 4—I purchased both of these instruments from
surplus dealers. The survey meter (on the right) is use-
less for measuring low-level radiation. In fact, if the
meter moves, you’re in trouble because it uses an ion-
ization chamber for sensing. The Geiger counter (on
the left) is an Electro-Neutronics CD V-700 6B. It’s
over 2000 times more sensitive than the survey meter
and is great for debugging the circuit described in this
article. Both instruments cost less than $100 each.
Photo 3—I found these marbles on eBay after search-
ing for uranium glass. As you can see, this type of glass
has a characteristic yellow color. It’s mildly radioactive
and is an example of a test source that’s easy to obtain.
SOURCES
BXA-502 Inverter
JKL Components Corp.
(800) 421-7244
www.jkllamps.com
CD V-700-6B Geiger counter
Lee Frank (distributor)
www.surplustuff.com
LMC555 CMOS Timer
National Semiconductor Corp.
(408) 721-5000
www.national.com
Basic Stamp II
Parallax, Inc.
(916) 624-8333
www.parallaxinc.com
G1300/1320 Geiger tube
Saint-Gobain Crystals and
Detectors
www.gammalabs.com
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2003/150/.
RESOURCES
C. Seymour, “A Geiger-Muller
Radiation Monitor and Counter,”
Electronics Today International
,
March 1987.
N. Tsoulfanidis, Measurement and
Detection of Radiation
, McGraw-
Hill, New York, NY, 1983.
Federal Emergency Management
Agency, “Radiation Safety in
Shelters,” CPG2-6.4, September
23, 1983.
E. Negus, “Interfacing the BASIC
Stamp I Rev D to the Velleman
K2645 Geiger-Muller Counter,”
Reynolds Electronics, 1999.
REFERENCES
[1] G.F. Knoll, Radiation
Detection and Measurement
,
John Wiley and Sons, Inc.,
Hoboken, NJ, 1979.
[2] J. Williams, “A Fourth
Generation of LCD Backlight
Technology,” Linear
Technology Corp., 65,
November 1995.
ticular surface and return. Then, the
device calculates the distance based
on the estimated speed of sound. In
this article, I’ll explain how I built
this simple ultrasonic distance meter.
Photo 1a is a picture of my PSoC
RangeFinder with an LCD. The display
is optional, and I removed it for
Photo 1b. For this particular applica-
tion, the only required components are
a PSoC microcontroller, two 40-kHz
ultrasonic transducers, two resistors,
and two capacitors. Similar circuits are
typically complicated and expensive,
consisting of a large number of inte-
grated circuit and passive components.
Take a look at the RangeFinder’s
system block diagram in Figure 1. As
you can see, it’s divisible into three
parts: the transmitting section, receiv-
ing section, and output section. Each
section contains several PSoC blocks.
Using the PSoC chip family, all of the
digital and analog devices are on-board
with the microcontroller.
The RangeFinder has numerous
applications. You can use it for the
positioning of robots as well as meas-
uring generic distances, liquid levels
in tanks, and the depth of snow banks.
The device can also serve as a motion
detector in production lines where sur-
faces must not be damaged, or you can
use it for educational purposes.
A restricted target angle (it requires
a near-perpendicular surface) and large
beam, which can create poor resolu-
tion, seem to be the RangeFinder’s
only limitations. Despite these draw-
backs, you’ll find the device’s main
features to be extremely useful.
The RangeFinder has a 40-kHz oper-
ating frequency, a range of 25 to 200 cm,
and 1-cm resolution. In addition, it
26
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
here are several
ways to measure
distance without con-
tact. Some products
have infrared light emitters and
receivers that determine an object’s
distance by implementing the optical
triangulation method. Other devices
have laser-based systems that increase
accuracy and precision. For electrical-
ly conductive metal objects, the eddy
current method is an option, and
capacitive sensors that are independ-
ent of the metal used in the measured
objects can be used.
I decided to use ultrasonic waves.
My ultrasonic PSoC RangeFinder
measures the amount of time it takes
for a pulse of sound to travel to a par-
The PSoC RangeFinder
t
Some distances are
more difficult to meas-
ure than others.
Therefore, Fabio built
his own ultrasonic
rangefinder, which
won First Prize in the
Cypress PSoC design
contest. It can be
used for measuring
liquid levels, generic
distances, and even
the depth of snow.
Fabio Piana
FEATURE
ARTICLE
Photo 1a—There are several things to consider when building your own ultrasonic rangefinder, including whether
or not to incorporate an LCD. b—Take a look at the PSoC RangeFinder without the LCD.
A Simple Ultrasonic Distance Meter
a)
CONTEST WINNER
b)
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
27
where T is equal to the air tempera-
ture (°C). So, for a middle value of
22°C:
For a round-trip ping, you have:
And with a 24-MHz MCU clock:
An 8-bit counter (F40kHz) drives the
ultrasonic transmitter and a digital
inverter (F40kHz_inv). The phase of
the voltage applied to the positive and
negative terminals of the sensor has
been shifted 180°, so two times the
supply voltage is applied to the sensor.
The 40-kHz transmission enables an
8-bit counter (called “Meter”) that
increments one step per centimeter.
The Meter clock input is TimeBase
(17,240 Hz).
The ultrasonic receiver’s negative ter-
minal is connected to the analog ground
reference (AGND—pin 25, P02) provid-
ed by RefMux_1, a reference multiplex-
er allocated in the ACA03 block. The
ultrasonic receiver’s positive terminal is
connected to an amplification chain
based on a programmable gain amplifi-
er (PGA_1) and two two-pole passband
filters (BPF2_1 and BPF2_2). The first
passband filter is designed for a 40-kHz
center frequency and a correspondent
gain of 33 dB. The second filter is also
designed for a 40-kHz center frequency,
but it has a 10-dB pass-
band gain. Because of the
discrete value of the
capacitors integrated in the
switched-capacitor analog
blocks, the real frequency
response is different from
the nominal one.
Figure 2 shows the
BPF2_1 and BPF2_2 fre-
quency responses. The
BPF_2 output is sent to
the programmable thresh-
old comparator (CMP-
PRG_1). When a 40-kHz
f
TimeBase
=
24 MHz
116
= 2 MHz
116
=17. 24 kHz
12
f
TimeBase
= V
SOUND IN AIR
2
= 17. 23 kHz
V
SOUND IN AIR
= 331.4 + (0.6
×
22) =
344 .6 m/s = 34,460 cm/s
V
SOUND IN AIR
= 331.4 + (0.6
×
T)
requires only a single 5-VDC power sup-
ply and draws just 25 mA (23 mA with-
out the LCD). The device has one PWM
output and one TTL-level serial output
(9600 bps, 8 bits, 1 stop bit, and no pari-
ty). Finally, don’t forget the optional
2 × 16 LCD, software calibration, and
dynamic receiver stage gain increment.
MICRO CONFIGURATION
Several PSoC microcontroller
resources were used in this project. I
applied the following PSoC digital
resources: five 8-bit counters, an 8-bit
serial transmitter, two 8-bit PWMs,
and a digital inverter. I implemented
the following analog resources: one
programmable gain amplifier (PGA),
two two-pole passband filters, a pro-
grammable threshold comparator, and
a reference multiplexer. In
addition, I used the EEP-
ROM and LCD toolbox
software modules.
Photo 2 is a screen shot
of the PSoC Designer
with the Device Editor
showing the placement of
the PSoC’s digital and
analog resources. As you
can see, a large number of
resources are required.
All of the digital blocks
and several analog blocks
are employed.
The software modules include the
LCD toolbox user module and a com-
plete set of library routines that allows
you to write numbers and strings to a
two-line LCD using standard Hitachi
HD44780 commands. An EEPROM
emulation library allows you to store
important data in flash memory space
as if it were a physical EEPROM.
PRINCIPLES
The transmission section is based
on four digital blocks allocated in the
DBA00, DBA01, DBA02, and DBA03
blocks. An 8-bit counter (called
“TimeBase”) provides a 17,240-Hz
time base frequency. Sound velocity
depends on ambient air temperature,
which is calculated for an air tempera-
ture value of 22°C:
Figure 1—There are three distinct sections in my PSoC RangeFinder project: digital
blocks, analog blocks, and transducers.
Listing 1—The time base interrupt routine is the heart of the measuring process. Remember, the PGA_1
gain is dynamically reconfigured from one to 16.
TimeBaseINT:
//Interrupt rate = 58 µs
push a
inc [time1]
cmp [time1],26 ;25
//35 × 58 ms = 2-ms blank
jc timebase1
//Jump if time 1 < 35
//Test comparator
tst reg[CMP_CR],0b01000000 //Test if comparator = 1
jz timebase1
//If comparator = 0, then jump
//gest comparator = 1 (pong)
mov A,[time1]
mov [range],A
//Distance in range
call TimeBase_DisableInt
//Disable time base interrupt
timebase1:
//Set PGA_1 gain
mov A,[time1]
cpl A
or A,0b00001111
//Add X8h
call PGA_1_SetGain
//Set pga_1 gain in 16 steps
pop A
reti
TimeBase
CNTR8
Meter
CNTR8
F40kHz
CNTR8
F40kHz_inv
US TX
TX Section
BPF2_1 _
^
BPF2
BPF2_2 _
^
_BPF2
RX Section
PWM_Output PWM
Baud9600 CNTR8
Serial TX TX8
PWM out
Serial out
Output section
RefMux_1
REFMUX
US RX
AGND
PGA_1
+
–
An_Clock CNTR8
1, 5 MHz
+
–
V
REF
CMPRG_1
28
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
selected this value for a good contrast
in the LCDs used in prototypes. It can
be changed to adjust the contrast
using different LCD modules. In addi-
tion, a 10-k
Ω
trimmer with the wiper
to the contrast input and other pins
connected to 5 V and GND can
replace it. This allows for decent LCD
contrast regulation.
Without an LCD, the circuit draws
approximately 23 mA from a 5-V power
supply. If you use an LCD, the current
consumption is 25 mA. The optional
LCD is a standard 2 × 16 model.
THE SOFTWARE
Figure 4 is a flowchart depicting the
microcontroller’s software. The main
program sets up the analog and digital
blocks before testing JP1 to determine
signal is received, the CMPPRG_1
output is high logic level, so the soft-
ware can read it.
There are two different output devices
in the output section: an 8-bit pulse
width modulator and an 8-bit serial
transmitter. In the former, the frequency
of the rectangular signal that’s available
on the PWM output (P2.7, pin 5) is
approximately 780 Hz; its pulse width
is proportional to a measured distance
value (5 µs per centimeter). The latter is
a standard TTL logic-level serial output.
Transmission parameters are 9600 bps,
8 data bits, 1 stop bit, and no parity bit.
An 8-bit counter, Baud9600, provides a
9600-Hz time base for the serial trans-
mitter block, SerialTX, with its output
on P2.4 (pin 22). If you need RS-232
interfacing, you can use an external TTL-
level RS-232 converter (e.g., the
common, inexpensive MAX232).
This means that you can also
interface the RangeFinder to a PC
or microcontroller-based system
with a standard RS-232 port.
THE HARDWARE
The RangeFinder’s circuitry is
quite simple (see Figure 3). The
most important part is U1,
which is a CY8C26443 PSoC
microcontroller. U1 does all of
the work with its internal analog
and digital blocks.
Two capacitors, C1 and C2,
suppress high- and low-frequency
noise on the 5-V supply line. R1
is a 100-k
Ω
resistor that holds
the DC input voltage of the
receiving stage to AGND (2, 5 V).
R2 regulates the LCD contrast. I
Normal or Calibration mode. If JP1 is
shorted, the control program runs the
Normal mode procedure. Otherwise,
the calibration routine is executed.
In Normal mode, the software con-
tinuously runs the transmitted ultra-
sonic burst (ping). After a blanking
time, it waits for the returned ultra-
sonic signal (pong). The time between
the start of a transmitted burst and
the start of a received burst is propor-
tional to the distance between the
RangeFinder and the obstacle. By
polling the comparator bus register, the
software measures this time and stores
it in a RAM location. Finally, the range
value is written to the LCD (if present),
sent to the serial interface, and the
PWM duty cycle is set to a value
that’s proportional to the distance.
Figure 3—Building the circuitry for the PSoC RangeFinder isn’t complicated . All of the functions are concentrated in the
C48C26443 PSoC microcontroller, which is clearly the most important part of the design.
Nominal
Expected
Frequency (Hz)
40
35
30
25
20
15
10
Gain (dB)
20,000
25,000
30,000
35,000
40,000
45,000
50,000
5
0
0
20,000
40,000
60,000
80,000
Frequency (Hz)
15
10
5
0
–5
–10
–15
Gain (dB)
Nominal
Expected
Figure 2a—This is the BPF2_1 frequency response graph. b—The BSF2_2 frequency response graph is a little different. For the filter design, I used the appropriate Cypress
filter design folder in Excel.
a)
b)
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
29
The software in Calibration mode is
similar to that in Normal mode; how-
ever, the measured value is compared
with the constant value 50, and the
resultant offset is stored in nonvolatile
EEPROM and used to calculate the
measured range in Normal mode.
TimeBase_int is the interrupt sub-
routine for the TimeBase 8-bit counter.
This is the most important portion of
code (see Listing 1). When
time1 is
greater than the value of blank time
(blank time prevents false echoes
caused by the lateral
receiving of transmitted
40-kHz bursts), the soft-
ware tests the logical
value of the comparator.
If a pong is received, the
comparator output logic
level is one, the
time1
value is stored in RAM
location
range, and the
TimeBase interrupt is dis-
abled. As a result, the
value stored in the
range
location represents the
measured distance.
If the comparator logic
level output is equal to
zero, then the PGA_1
gain is dynamically
incremented in 16 steps
from one to 16 by modi-
fying the corresponding
gain register; therefore,
the far echoes are much
more amplified.
As you can see in Table 1, the PGA_1
gain increment is not linear. This is not
a problem, because more amplification
is required for long distances. As you
can see in Listing 1, the
PGA_1_SetGain
routine is called to change the amplifier
gain and the value stored in the relative
configuration register.
PRACTICAL CONSTRUCTION
Constructing the circuit isn’t diffi-
cult. It will take you just a few min-
utes. You may download the single-
sided PCB design from the Circuit
Cellar
ftp site. The corresponding
component layout is available on the
ftp site, as well.
First, you have to mount the two
wire links. The links are followed by
the microcontroller socket, two resis-
tors (mounted vertically), and two
capacitors. Pay attention to the polari-
ty of C2, which is a tantalum elec-
trolytic capacitor. Follow with the two
headers and jumper. J1 is a four-pin
male header for the power supply and
output connections. J2 is a 14-pin
female header for the LCD connection.
The two ultrasonic transducers are
soldered directly to the copper-sided
padstacks. These common 40-kHz
ultrasonic transducers are the kind
used in car alarms. Make sure you
Main
Calibration
TimeBase_int
Initialize and
start blocks
JP1?
Send 40-kHz
ping
Wait for
blank time
Wait for
40-kHz pong
Calculate
and send
range to
LCD, PWM,
and serial
Calibration
N
Y
Send 40-kHz
ping
Wait for
blank time
Wait for
40-kHz pong
Calculate
offset
and store in
EEPROM
Ret
Time>=
blank?
Inc time1
Compare
= 1?
Disable
TimeBase_int
save time1
Increment
PGA_1 gain
Ret
N
N
Y
Y
Figure 4—A flowchart will help you understand the software associated with
this project. Note that there are three relevant routines: the main program, the
calibration routine, and the TimeBase 8-bit counter interrupt subroutine.
Gain
Value
PGA_A_G16_0
08h
PGA_A_G8_00
18h
PGA_A_G5_33
28h
PGA_A_G4_00
38h
PGA_A_G3_20
48h
PGA_A_G2_67
58h
PGA_A_G2_27
68h
PGA_A_G2_00
78h
PGA_A_G1_78
88h
PGA_A_G1_60
98h
PGA_A_G1_46
A8h
PGA_A_G1_33
B8h
PGA_A_G1_23
C8h
PGA_A_G1_14
D8h
PGA_A_G1_06
E8h
PGA_A_G1_00
F8h
Table 1—The PSoC’s PGA gain values are used to set
the PGA_1 gain during the measuring routine. For
more information, study the PGA_A module datasheet
from Cypress.
. Shipping and handling for the
Limited. NO COD. Prices subject
CHARGE ORDERS to Visa, Mastercard,
450 for $2.25 each
990 for $1.50 each
100 for $50.00 - 1,000 for $350.00
- water-clear 1,500 mcd T-1 3/4
100 for $115.00 • 1,000 for $950.00
- water-clear 3,000 mcd T-1 3/4
30
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
position the two ultrasonic
transducers correctly. Usually,
the negative terminal is soldered
to the case for good noise immu-
nity. You can make the connec-
tion to the LCD by soldering a
14-pin male connection to the
LCD module with a flat ribbon
cable or a set of individual flexi-
ble wires. After a final inspec-
tion of the populated board, you
can insert a programmed PSoC
microcontroller into its 28-pin socket.
POWER AND CALIBRATION
This circuit needs a 5-V regulated and
filtered power supply. Because of the
reduced circuit size, the voltage regu-
lator is not included. If an external 5-V
power source isn’t available and all you
have is an unregulated 8-V supply, you
can use a three-legged voltage regulator
(i.e., 78L05 at 5 V–100 mA maximum)
and some capacitors to increase ripple
rejection and transient behavior.
You must calibrate the unit before
it’s installed. The calibration proce-
dure is simple. First, place the
rangefinder 50 cm in front of a perpen-
dicular, flat obstacle (e.g., a wall or
wood panel). Second, remove jumper
JP1 and power up the circuit by con-
necting the 5-V regulated power sup-
ply. Finally, insert jumper JP1 and
power down the circuit. At this point
the circuit is calibrated and the offset
value is stored in EEPROM. The value
will be read from the software at each
circuit power-up and used in the dis-
tance calculating operation.
Figure 5 shows the text displayed on
the LCD in Normal and Calibration
modes. This text is easy to change,
because it’s stored as ASCII strings.
You may download the strings
from the main.asm file on the
Circuit Cellar
ftp site.
THINGS TO CONSIDER
I used the 28-pin CY8C26443
microcontroller because of its
availability; however, you can use
the eight- (if you don’t use the
LCD) or 20-pin versions for a
smaller PCB. With the LCD con-
nected, you can display useful
information while setting up and cali-
brating your own PSoC RangeFinder.
It’s easy to change the program if
you’re thinking about modifying the
device’s behavior. Because any one of
several obstacles can surface at any
time, the ultrasonic distance meter
can make mistakes during the meas-
urement process. However, if you
want to prevent measurement errors,
you can modify the software to calcu-
late the average value of several meas-
urements and discard the measured
values that are out of range.
The measurement process is based
on a typical air temperature of 22°C.
P
S
o
C
r
a
g
n
e
f
I
n
d
e
r
Normal mode
D
i
s
t
n
c
e
N
N
N
c
m
a
5
0
c
m
c
a
i
l
b
r
a
t
i
o
n
Calibration mode
P
l
a
c
J
1
P
j
u
m
e
r
e
p
Figure 5—The LCD text that appears in Normal and Calibration mode
is fairly easy to change. Note that NNN represents the measured value.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
31
This can be limiting when the specif-
ic application involves a wide operat-
ing temperature range.
If you use a 28- or 20-pin integrat-
ed circuit, there will be a lot of free
pins in the PSoC microcontroller. It
would be an improvement to imple-
ment an external integrated tempera-
ture sensor to measure the air tem-
perature. Because of its low accuracy
(
±
20°C), the internal FlashTemp
module isn’t suitable for the job. But,
if you want to increase the precision,
you can calculate and compensate
for the different sound velocities at
different air temperatures.
I
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2003/150/.
Fabio Piana has been teaching elec-
tronics and systems automation for
the last 15 years in several technical
schools in Italy. In addition, he’s an
electronics design consultant. You
may reach him at fabiopia@tiscali.it.
RESOURCES
Cypress MicroSystems,
“CY8C25122, CY8C26233,
CY8C26443, CY8C26643 Device
Data Sheet,” CMS10002A-R3.15,
2002.
———, “PSoC Designer, PGA_A
Module Data Sheet,” 2002.
SOURCE
CY8C26443 PSoC Microcontroller
Cypress MicroSystems, Inc.
(877) 751-6100
www.cypressmicro.com
Photo 2—Note the placement of the PSoC’s resources. For this application, all of the digital blocks are required.
32
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
any articles
have been written
about the advantages
of using a hardware
description language such as VHDL or
Verilog to design hardware. First,
example VHDL code is provided to
describe the operation of circuits.
Second, the software description of the
circuit is simulated and proven to
work inside the simulator. Finally, the
author states that the software descrip-
tion can be transformed into the actual
hardware. But where is this hardware,
and how is the process completed?
In this article, I’ll present you with a
hands-on tutorial that you can use to
create an actual arithmetic logic unit
(ALU) chip. I’ll explain how to design
the ALU with VHDL and show you
that it simulates correctly. Then, I’ll
demonstrate how the VHDL descrip-
tion of the ALU is used to create the
actual hardware. Finally, you’ll see
that the ALU hardware chip actually
runs according to the initial design.
To prove that the chip can be easily
reprogrammed with another design,
I’ll add two other components that
interface with the ALU. The first
component is a 3-bit binary counter,
the output of which is used to drive
the 3-bit ALU select lines. The second
component is a BCD-to-seven-segment
display driver that connects to the
output of the ALU. With these two
additional components, testing the
ALU is simplified.
USING SOFTWARE
The world of computers is changing
rapidly. Moore’s Law states that the
densities of transistors on a chip dou-
bles every 18 months. One thing that
has helped the computer industry to
achieve this goal is its ability to use
software to design and build hardware-
integrated circuit chips. This technol-
ogy requires three components: the
ability to describe the behavior of a
digital logic circuit using software; the
capability to translate the software
description of the circuit into a
description of how the circuit is con-
nected; and the ability to implement
the circuit in an IC.
VHDL is a computer software lan-
guage that’s used for describing the
behavior of digital logic circuits.
Jointly developed by the U.S.
Department of Defense and IEEE in
the mid-1980s, VHDL was standard-
ized by the IEEE in 1987 and extended
in 1993. In many ways, the syntax is
similar to high-level programming lan-
guages, as you’ll see later.
However, just being able to formally
describe a hardware circuit with a
software language is neither sufficient
nor particularly useful. The analogy is
like writing a computer program in C:
if you don’t have a C compiler (or
Where’s the Hardware?
m
It would take years,
even for the most
voracious reader, to
thumb through all of
the books published
on the topic of using
software to build hard-
ware. Fortunately,
Enoch has done much
of the legwork for us.
He put together a con-
cise tutorial on design-
ing an ALU chip.
Enoch Hwang
FEATURE
ARTICLE
Photo 1—The complete development system includes
a Windows-based computer system and Altera UP1
development board connected to it via the parallel port.
The screen shows the MAX+PLUS 11 GUI environment.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
33
trate on the overall process of making
the hardware with software rather
than focusing on design details.
The ALU is responsible for all of the
arithmetic and logic operations inside
a CPU. The arithmetic operations
include addition, subtraction, incre-
ment, and decrement. Multiplication
and division are usually performed in
another module, but there is no reason
why you couldn’t put it in the ALU
too. Because you’re building your own
chip, you can do whatever you want to.
Logic operations include
AND, OR,
NOT, XOR, and so on. The ALU has
two main inputs for the two operands.
A set of select lines is used to select
the operation to perform on the two
operands. The number of required
select lines is dependent on the num-
ber of operations you want to imple-
interpreter) to translate the C program
into a machine language, then your
program cannot be executed.
Additionally, you need to have the
ability to translate the software descrip-
tion of a digital circuit into a netlist,
which is a description of how the cir-
cuit is realized or connected using basic
logic gates. This translation process is
referred to as synthesis. You’ll need a
synthesizer to perform this operation.
A synthesizer is like a compiler,
except the output is a netlist of the
circuit rather than machine code. The
popularity of using VHDL (or Verilog)
for designing digital circuits began in
the mid-1990s when commercial syn-
thesis tools became available.
A netlist is similar to a schematic
diagram, telling you which components
are needed and how they’re connected
to build the circuit. This isn’t, however,
the actual hardware circuit that you
can power up and then see
lights flash. What you need
is an actual hardware chip
that is programmed with
the given netlist. The field
programmable gate array
(FPGA) chip provides this
important link, giving you the
ability to create hardware
with software automatically.
An FPGA contains many
generic logic cells that can be
programmed to connect in
any fashion. Hence, these
logic cells can be programmed
to connect according to the given net-
list. What you end up with is an actual
chip that has been programmed to oper-
ate according to your original software
description. The end result is hardware
that’s been created using software.
Similar to flash memories, the con-
nections made inside an FPGA are
nonvolatile, although they can be
erased and reprogrammed. Newer
FPGAs can contain several hundreds
of thousands of basic logic gates.
Therefore, a fairly complex circuit can
fit inside one FPGA, or you could put
several independent circuits inside the
same FPGA to reduce the chip count.
ALU DESIGN
Now, I’ll describe the process of
building hardware with software by
designing an ALU. I purposely kept
the following example to a bare mini-
mum. This will allow you to concen-
Photo 2—The Waveform Editor window shows the three input sig-
nals
S, A, and B, and the output signal F. S is the 3-bit select line for
the ALU.
A and B are the input operands, and F is the output result.
All of the values are shown in binary. The input operand values are
3 (0011 in binary) and 6 (0110 in binary) for
A and B, respectively. For
each of the eight operations selected according to the value of
S, you
can see the corresponding result on
F. For example, between 400
and 500 ns, the value of
S is 100, which is the select for the addition
operation. Hence, you have the result
F = 1001 (in binary) = 9 (in dec-
imal) during that same clock period, which is the result of 3 + 6.
Photo 3—Take a closer look at the Altera UP1 FPGA
development board. The power and parallel port con-
nection cables are at the top left corner. The large chip
on the left is the MAX7000S, and the large chip on the
right is the FLEX10K. Both of these chips can be pro-
grammed independently. The rest of the discrete com-
ponents are mainly switches and LEDs for providing
I/Os to these two chips.
e)
a)
b)
c)
g)
f)
d)
h)
Photo 4—The results of the eight ALU operations on the two input operands 3 and 6 show the same sequence of operations as the simulation from Photo 2: a—pass
A; b—
A and B; c—A or B; d—not A; e—A + B; f—A – B; g—increment A; h—decrement A. The left set of eight DIP switches is the input for A and B. The first four switches are for
the 4-bit
A operand, and the last four switches are for the 4-bit B operand. The three rightmost DIP switches are for the 3-bit S select lines. The switches are down for a zero
and up for a one. The output result is displayed on the first column of four LEDs. The top LED is the most significant bit of the result. For example, the four LEDs in 4e show
the value 1001 (9 decimal), which is the result for the operation 3 + 6.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
35
ment in the ALU. The ALU has one
output, which outputs the result of
the operation on the two operands.
Using behavioral VHDL code to
design an ALU is extremely simple.
You have to choose the width of the
two input operands and the operations
to implement in the ALU. For simplic-
ity, I implemented the eight opera-
tions shown in Table 1. With eight
operations, three select lines were
needed (S
0
, S
1
, and S
2
). The variables
A
and
B are the two input operands
using four bits each.
The behavioral VHDL code that
describes the ALU is shown in
Listing 1. The
ENTITY section defines
the ALU’s input and output signals.
The select-line signal
S is declared as a
3-bit input vector.
A and B are the two
input operands declared as 4-bit vec-
tors, and
F is the 4-bit output result
from the operation.
In the
ARCHITECTURE section,
behavioral code is used to describe the
ALU’s actual operations. Specifically,
a
CASE statement is implemented to
select a particular operation, depend-
ing on the three select lines. In each of
the cases, a signal assignment state-
ment is used to assign the value from
the result of the intended operation to
the output signal
F.
For example, if
S = “000”, then the
A operand is passed to the output F.
Thus,
A is assigned to F using the sig-
nal assignment statement
F <= A. If
S = “100”, then you want to add A and
B to get the statement F <= A + B.
As you can see, the behavioral coding
is straightforward. You need to know
the operations of the ALU without hav-
ing to know the details of the required
logic gates and how they should be con-
nected together to realize the circuit.
SYNTHESIS
Now that you know how to write
VHDL code for the ALU, you’re ready
to learn how to synthesize it. Recall
that synthesizing the code will translate
the high-level description of the circuit
into the netlist that creates the circuit.
The synthesis tool that I’ll describe is
Altera’s MAX+PLUS II. You may down-
load a free student edition of the soft-
ware from the company’s web site.
The complete development system
with the MAX+PLUS II GUI environ-
ment on the screen is shown in Photo 1.
The VHDL code for the ALU is
entered or copied into the Text Editor
window (see Listing 1). To start the
synthesis process, click on the Start
button in the Compiler window. A red
progress line in the Compiler window
shows that the synthesizer is working.
At the end of the synthesis process,
a message window opens to show you
that the process has been completed
Select lines
Operation name
Operation
S
2
S
1
S
0
0
0
0
Pass
Pass A to output
0
0
1
AND
A AND B
0
1
0
OR
A OR B
0
1
1
NOT
A
′
1
0
0
Addition
A + B
1
0
1
Subtraction
A – B
1
1
0
Increment
A + 1
1
1
1
Decrement
A – 1
Table 1—Each ALU operation is given a unique binary code as specified by the three select lines S
2
, S
1
, and S
0
.
For example, when the select lines are given the value 001, the logical AND operation is selected. The ALU will
perform the AND operation on the two input operands
A and B, and pass the result to the output.
Listing 1—The
ENTITY section of the VHDL code describes the interface to the module, which consists
of the two input operands
A and B, the 3-bit select line S (for selecting what ALU operation to perform),
and the ALU output
F for outputting the result of the operation. The actual coding of the circuit is in the
ARCHITECTURE section. The CASE statement uses S to select one of the eight operations to perform
according to Table 1. For each case, the associated operation is performed, and the result is assigned to
the output
F.
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_unsigned.all;
ENTITY alu IS
PORT (S:
IN STD_LOGIC_VECTOR(2 downto 0);
//Select for operations
A, B:
IN STD_LOGIC_VECTOR(3 downto 0); //Input operands
F:
OUT STD_LOGIC_VECTOR(3 downto 0)); //Output
END alu;
ARCHITECTURE Behavior OF alu IS
BEGIN
PROCESS(S, A, B)
BEGIN
CASE S IS
WHEN "000" =>
//Pass A through
F <= A;
WHEN "001" =>
//AND
F <= A AND B;
WHEN "010" =>
//OR
F <= A OR B;
WHEN "011" =>
//Not A
F <= NOT A;
WHEN "100" =>
//Add
F <= A + B;
WHEN "101" =>
//Subtract
F <= A - B;
WHEN "110" =>
//Increment
F <= A + 1;
WHEN OTHERS =>
//Decrement
F <= A - 1;
END CASE;
END PROCESS;
END Behavior;
36
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
without errors (hopefully). It’s not nec-
essary to know all of the details con-
cerning the netlist that’s generated
from the synthesis process; however, if
you’re curious, you can take a look.
FUNCTIONAL SIMULATION
After completing the synthesis
process, I performed a functional sim-
ulation of the ALU code. First, I
needed to bring up the Waveform
Editor window and specify the signals
that I wanted to observe in the simu-
lation trace. For the ALU, I had the
select lines, two operands (
A and B),
and output (
F) that I wanted to
include in the simulation trace (see
Photo 2). Next, I had to assign values
for the
S, A, and B input signals. I
wanted to test all eight of the ALU’s
functions, so I specified the eight
possible values for
S. I arbitrarily set
the two 4-bit operands
A and B to
three and six respectively.
Issuing the Start Simulation com-
mand begins the actual simulation.
The simulator generates the trace for
all of the output signals (i.e., the trace
for the output
F in this case). Looking
at the
F signal trace in Photo 2 and
referring back to the ALU definitions
in Table 1, you’ll see the results of the
ALU operations. For example, when
S = 000, A is passed through to F,
which is
0011. When S = 001, F =
0011 AND 0110 = 0010. When S =
101, the operation is 3 – 6. The result,
–3, is shown as the signed value
1101
in two’s complement representation.
PROGRAMMING THE FPGA
Look at the close-up of Altera’s UP1
FPGA development board in Photo 3.
This board contains two FPGAs. Located
on the left, the MAX7000S chip has a
gate capacity of about 2500 logic gates.
On the right, the FLEX10K has a gate
capacity of about 20,000 logic gates.
These two FPGAs are independent of
each other and programmed individual-
ly. The remaining components on the
board are mostly switches and LEDs
that are used for testing the I/O signals
to and from the FPGAs.
The ALU example I’m describing
can fit on the MAX7000S chip, so I’ll
show you how to program this chip.
To perform the synthesis, a target
chip must be specified so that the syn-
thesizer produces a netlist and also
fits the netlist onto the specific FPGA.
Furthermore, you can specify which
I/O pins on the chip are used for ALU
I/O signals. To do this, the Floorplan
Editor window should be brought up
for a graphical view of the chip with
all of its pins. I/O pins that are current-
ly assigned to a signal are colored blue
with the signal name next to it. The
unused I/O pins are white. A signal
can be repositioned by dragging it
from one I/O pin to another. If an I/O
Listing 2—In the
ARCHITECTURE section of the VHDL code, the 3-bit binary counter (cnt) is defined as
a 3-bit register (variable). At each rising edge of the clock,
cnt is incremented by one. The current value
of the count is then assigned to the output (
Q).
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_unsigned.all;
ENTITY counter IS
PORT (clk :IN BIT;
Q
:OUT STD_LOGIC_VECTOR(2 downto 0)
);
END counter;
ARCHITECTURE Behavior OF counter IS
BEGIN
PROCESS (clk)
VARIABLE
cnt : STD_LOGIC_VECTOR(2 downto 0);
BEGIN
IF (clk'EVENT AND clk = '1') THEN
cnt := cnt + 1;
END IF;
Q <= cnt;
END PROCESS;
END Behavior;
Photo 5—Take a look at the results of the same eight ALU operations on the two operands 3 and 6 automatically cycling through and displayed as a hexadecimal digit: a—
pass
A; b—A and B; c—A or B; d—not A; e—A + B; f—A – B; g—increment A; h—decrement A. In contrast to Photo 4, you don’t need the 3-bit select switches for S, because
you’re using the 3-bit counter to provide for that input. Also, you’re using the binary-to-seven-segment display decoder to convert the 4-bit result to a hexadecimal digit for dis-
play on the seven-segment LED.
a)
b)
c)
d)
e)
f)
g)
h)
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
37
pin is reassigned, the design must be
synthesized again so that it will refit
the signals to the newly assigned pins.
To actually program the chip, con-
nect the JTAG cable between the
board and parallel port of the comput-
er, connect a 9-V power source to the
board, bring up the Programmer win-
dow, and click on the Program button.
In just a few seconds, the ALU design
will be programmed onto the FPGA
chip. Finally, an actual ALU chip!
POWER THE CHIP
The next step is to test the ALU on
the chip. First, the DIP switches for the
inputs must be connected to the
S, A,
and
B input signals. Because the switch-
es are on the board, the jumper wires
are connected to the appropriate pins on
the chip according to the floor plan.
The output signal
F is connected to four
LEDs. By setting the DIP switches for
the input operands
A and B and the oper-
ation select
S, it’s easy to see the result
of the operation from the four LEDs.
Photo 4 shows eight operations per-
forming in sequence (S = 0 to 7) with
the two operands 3 and 6. For the DIP
switches, the down position is zero and
up is one. The four leftmost DIP
switches relate to the operand
A. The
next group of four DIP switches is for
B.
The rightmost group of three DIP
switches is for
S. The four red LEDs
on the left show the binary result of
the operation
F with the top LED being
the most significant bit. The results for
the eight operations are in the following
order: 0011, 0010, 0111, 1100, 1001,
1101, 0100, and 0010, which matches
the
F signal trace in Photo 2.
Listing 3—The VHDL code for the BCD to seven-segment decoder contains a
CASE statement that’s used
to determine the input BCD value. Depending on the BCD value, the corresponding LED is turned on or off
by assigning a one or zero to it. For example, to show a zero on the seven-segment LCD all of the LEDs are
turned on except the one in the center. Hence, you assign a string of six 1 bits followed by a 0 bit. On the
UPI board, the LEDs are actually turned on with a zero, not a one; therefore, you need to invert the zeroes
and ones at the end for the actual output.
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY BCD IS
PORT (I
:IN STD_LOGIC_VECTOR(3 DOWNTO 0);
SegmentsI
:OUT STD_LOGIC_VECTOR(1 TO 7)
);
END BCD;
ARCHITECTURE Behavioral OF BCD IS
SIGNAL Segs: STD_LOGIC_VECTOR(1 to 7);
BEGIN
PROCESS(I)
BEGIN
CASE I IS
WHEN "0000" => Segs <= "1111110";
-- 0
WHEN "0001" => Segs <= "0110000";
-- 1
WHEN "0010" => Segs <= "1101101";
-- 2
WHEN "0011" => Segs <= "1111001";
-- 3
WHEN "0100" => Segs <= "0110011";
-- 4
WHEN "0101" => Segs <= "1011011";
-- 5
WHEN "0110" => Segs <= "1011111";
-- 6
WHEN "0111" => Segs <= "1110000";
-- 7
WHEN "1000" => Segs <= "1111111";
-- 8
WHEN "1001" => Segs <= "1110011";
-- 9
WHEN "1010" => Segs <= "1110111";
-- A
WHEN "1011" => Segs <= "0011111";
-- b
WHEN "1100" => Segs <= "1001110";
-- C
WHEN "1101" => Segs <= "0111101";
-- d
WHEN "1110" => Segs <= "1001111";
-- E
WHEN "1111" => Segs <= "1000111";
-- F
WHEN OTHERS => Segs <= "0000000";
-- all off
END CASE;
SegmentsI <= not Segs;-- invert the 0’s and 1’s
END PROCESS;
END Behavioral;
38
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
CHANGING DESIGNS
To show you how easy it is to
change the design and reprogram the
FPGA chip, I’ll explain how to add a
3-bit binary counter and BCD to the
seven-segment decoder on the original
ALU design. These two components
make testing the ALU a little easier
and the output more user-friendly.
The output of the 3-bit binary counter
is used to drive the three select lines
on the ALU, and the BCD-to-seven-
segment decoder is used to display the
ALU output signal
F as a hexadecimal
digit on the seven-segment LED.
The behavioral VHDL code for the
3-bit binary counter is shown in
Listing 2, and the BCD-to-seven-seg-
ment decoder is shown in Listing 3.
With the three components defined,
the next step is to connect them. To
connect two or more together in VHDL,
it’s important to define a high-level
entity with the needed components
inside it, as you can see in Listing 4.
Enoch Hwang has a Ph.D. in comput-
er science. Currently, he is an associ-
ate professor at La Sierra University
and a lecturer at the University of
California, Riverside. Enoch’s techni-
cal interests include embedded sys-
tems, software/hardware portioning,
and power reduction. You may reach
him at ehwang@cs.lasierra.edu.
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2003/150/.
SOURCES
FLEX10K FPGA, MAX+PLUS II
GUI software, MAX7000S CPLD
Altera Corp.
(408) 544-7000
www.altera.com
The components are connected using
the structural-level method. Signals
declared in the
ARCHITECTURE section
are used to connect the component
I/O lines together. The component
statement declares the components
needed in the top-level design.
The top-level design includes only
the three components defined previ-
ously. The
PORT MAP statement pro-
duces an instance of that particular
component. The signals listed in the
PORT MAP statements define how the
I/O signals for the components are
actually connected together. For
example, the output of the binary
counter must be connected to the
ALU select input; therefore, the 3-bit
signal name
S is used for both the
counter
PORT MAP output and the ALU
PORT MAP select input.
It turns out that this design, with the
three components, cannot fit on the
smaller MAX7000S chip. So, the larger
FLEX10K chip is programmed instead.
On the development board, the DIP
switches and seven-segment LEDs are
connected directly to the FLEX10K
chip so that no jumpers are required.
However, to use these switches and
LEDs, it’s important to use the appro-
priate I/O pins on the FLEX10K chip
that are connected to them.
Again, the Floorplan Editor speci-
fies the pins needed to assign to the
design’s I/Os. In addition, an external
square-wave generator can provide the
clock signal for the counter. After set-
ting the DIP switches to three and six
for the two operands (
A and B) and
starting the clock, you can see the
ALU’s results displayed as a hexadeci-
mal digit on the seven-segment LED
and automatically cycling through the
eight select operations (see Photo 5).
YOUR TIME AND MONEY
As you now know, it’s easy to build
hardware with software. Using a hard-
ware description language, you can write
the functional description for complex
circuits, synthesize it using a synthesis
tool, and then program an FPGA chip
that realizes the circuit. Moreover, it’s
easy to modify or add to your design
and then reprogram the FPGA. This
capability saves development time
and money because you don’t have to
manufacture a custom chip.
I
Listing 4—A structural-level style of code is used to connect the ALU, counter, and BCD. The
COMPO-
NENT statements declare the components to be used, and the PORT MAP statements specify the num-
ber of instances needed for each component. For this project, you need one instance of each component.
The components are connected together using the same signal names (e.g., the output of the counter and
the select input of the ALU both use the same signal name,
S).
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY top IS
PORT (clk:IN bit;
A, B :IN STD_LOGIC_VECTOR(3 downto 0); //input operands
Segments: out STD_LOGIC_VECTOR(1 to 7)); //7-segment output
END top;
ARCHITECTURE Structure OF top IS
SIGNAL S: STD_LOGIC_VECTOR(2 downto 0);
SIGNAL ALUout: STD_LOGIC_VECTOR(3 downto 0);
COMPONENT ALU port (S: in STD_LOGIC_VECTOR(2 downto 0);
A: in STD_LOGIC_VECTOR(3 downto 0);
B: in STD_LOGIC_VECTOR(3 downto 0);
F: out STD_LOGIC_VECTOR(3 downto 0));
end component;
COMPONENT counter port (clk: in bit;
q: out STD_LOGIC_VECTOR(2 downto 0));
end component;
COMPONENT BCD port (I: in STD_LOGIC_VECTOR(3 downto 0);
SegmentsI: out STD_LOGIC_VECTOR(1 to 7));
end component;
BEGIN
U1: counter PORT MAP (clk, S);
U2: ALU PORT MAP (S, A, B, ALUout);
U3: BCD PORT MAP (ALUout, Segments);
END Structure;
40
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
any interesting
microcontroller
applications have a
graphics component.
The students in my class (ECE 476 at
Cornell University) often want to use
graphics for their design projects. Over
the past few years, the students have
experimented with graphics devices
including LCDs, arrays of LEDs, analog
oscilloscopes used as x-y plotters,
mechanical x-y plotters, and applica-
tions running under Windows. While
many of the applications have been
clever and worked well, none of the
graphics devices were appropriate to
deploy widely in a teaching setting.
Any device used in the teaching lab,
whether it’s a graphics device or micro-
controller development board, must sat-
isfy several criteria. First, the device
must be relatively inexpensive (there
are about 75 students in my course and
we need 30 to 50 sets of hardware).
Second, the device must be robust so
that it has a chance of surviving. Third,
the device must be easy to understand
so that it can be taught quickly. And
fourth, the device must be standardized
so that it can be easily replaced.
After looking at the options for
graphics devices, it looked like a
small, cheap black and white televi-
sion would be perfect. Not only does
it meet all of the above constraints,
the TV is also a good example of a
hard real-time system. If the sync
pulses don’t arrive on time, the image
jitters or breaks up. Because the
microcontroller is directly driving the
TV, timing errors show up as a degrad-
ed image, giving the students rapid,
understandable feedback.
The Atmel AVR Mega163 has just
enough memory and speed to generate
a black and white video signal. The
implementation broke down into three
parts: sync generation, image display,
and image content generation. All
three parts ran on a single Mega163.
For ease of teaching, I wanted as much
of the code as possible to be in C, with
little or no assembler. With careful
attention to the CodeVision compiler,
I was successful and used just a few
lines of assembler. The time-critical
image display code is as good in C as I
could write in assembler, requiring
four machine cycles per pixel. The
only external components were three
resistors and two diodes that formed
the video DAC.
Before going into the implementa-
tion details, let’s briefly review how a
TV is controlled. I learned much of
the following from four web sites. I
obtained a lot of useful information
from the Stanford University web site
on a page for course EE 281. Pascal
AVR Video Generator
m
Pop quiz: What do
you get when you mix
a small black and
white TV with the
Atmel AVR Mega163?
If you’re a lab-orient-
ed professor, you get
a standardized, cost-
effective video gener-
ator for your class-
room. Follow along
as Bruce describes
how he did it.
Bruce Land
FEATURE
ARTICLE
Photo 1—The “Cornell ECE476” message and time
in the lower right corner are computed by the pro-
gram. The “Circuit Cellar,” triangle, and dot are the
result of commands issued to the Mega163 from
HyperTerminal. The commands are: t0530CIRCUIT
(text starting at x = 05, y = 30); t1538CELLAR;
L055058501 (line x1 = 05, y1 = 50, x2 = 58, y2 = 50,
color = 1); L055032701; L585032701; and p32601
(point x = 32, y = 60, color = 1).
Teaching Programming and Graphics
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
41
the line counters are updated. All of
the logic for counting lines, inverting
the horizontal sync to make vertical
sync, and changing the I/O port pin
are contained within the 5-µs horizon-
tal sync pulse time (see Listing 1).
The main program initializes ports,
timers, and static image material, and
then goes into a while loop. The loop
is repeated once per line and includes
an assembler sleep command to sus-
pend execution until the next inter-
rupt. You may download a summary
of the program functions from the
Circuit Cellar
ftp site.
After the sync interrupt, the Mega163
draws one line of the image and then
goes back to sleep until the
next line. Image content
resides in 800 bytes of RAM of
the Mega163. The 6400 bits
are arranged as 100 lines of
64 binary-level pixels per line.
With 8 bytes per line, I could
convert a pixel position to the
address of the appropriate
image byte using shifts and
adds rather than multiplies.
At the beginning of each
line, 8 bytes were pre-fetched
from RAM and sent to the reg-
isters. The eight registers were
then clocked out of a port pin,
bit by bit. I unrolled all of the
loops so that the pixel rate
would be constant. Inspection
of the assembler code generat-
ed by the compiler showed
four cycles per pixel. Therefore,
at 8 MHz, a pixel would be
0.5/63.625 of a scan line, or
Stang’s lab assignment, titled “TV
Paint,” provided insight. [1] Also,
Alberto Ricci Bitti’s excellent projects
offered many useful hints, including
putting the CPU to sleep just before
an interrupt in order to make the
interrupt timing more reliable. [2]
Glen Williamson’s site provides well-
explained diagrams of video signals. [3]
To read about a range of video projects
and code, I also checked out Rickard
Gunée’s web site. [4]
VIDEO SIGNAL GENERATION
The video signal I decided to imple-
ment was a simplified version of
RS170 (NTSC-rate black and white)
video. RS170 uses a scheme in which
sync pulses are 0 V, black is about 0.3 V,
and white is about 1 V. Each line starts
with a 5-µs sync pulse. This pulse
causes the TV to reset the electron
beam to the left edge of the screen.
After another 5 µs, you can start to
write out the image content for that
line (for a maximum of about 50 µs).
At the end of each field (frame), the
electron beam has to be moved back
to the upper left corner of the screen
to start a new field. The vertical sync
pulse consists of three consecutive
lines of sync-level voltage interrupted
by inverted horizontal sync pulses.
Full RS170 uses interlaced fields, in
which odd lines are drawn and
then even lines are filled in-
between them. Interlacing is
used to reduce flicker.
My main simplification was
not making an interlaced pic-
ture, but rather drawing every
field with exactly 262 lines
(instead of the RS170 standard
of 262.5 lines per field). Figure 1
shows the timing relationships
and line numbers. The dura-
tion of each line was increased
slightly so that each field was
exactly 1/60 s. NTSC specifies
63.55 µs per line. My code pro-
duces 63.625-µs lines. The
resulting signal displays cor-
rectly on every TV I have tried;
the signal does not flicker and
it records perfectly on a VCR.
Each field consists of
242 lines on which image con-
tent may be displayed and
20 lines dedicated to generating the
correct vertical sync pulses. The lines
from 243 to 247 should be at black
level with no image content. Lines
248 to 250 generate the actual vertical
sync pulse. Lines 251 to 262 should
remain at black level. Because no
image content is displayed during
lines 242 to 262, and because image
display is the most CPU/memory-
intensive task, new image content
may be computed during these lines
to be displayed when RAM is dumped
to the screen again in the next field.
Sync generation occurs in an inter-
rupt service routine (ISR) triggered
from AVR Timer 1, compare-match
channel A. The channel A compare-
match function also (optionally) zeroes
the timer in hardware to ensure an
accurate time base. With an 8-MHz
crystal, the timer interrupt is triggered
every 509 cycles for a period equal to
the horizontal sync rate of 63.625 µs.
It is essential that the ISR always be
entered from the CPU sleep state so
that the interrupt latency remains the
same number of cycles. Normally the
AVR interrupt latency varies by one or
two cycles because instructions can-
not be interrupted and are one to
three cycles long (most often one
cycle). In the ISR, the horizontal and
vertical sync pulses are generated and
Photo 2—This DLA program example takes 5547 s to
compute. You can see the current free particle as a
blur in the lower right corner of the screen.
Figure 1—The top trace shows the waveform of one line of the video signal.
Each horizontal sync pulse is 5-µs long. The sync level is 0 V, the black level is
0.3 V, and the white level is 1 V. The bottom trace shows the waveform of one
field (frame) of the video. Each narrow downward pulse is a horizontal sync
pulse. The line numbers within the field are numbered. Image data appears on
lines one to 242. Vertical sync starts at line 243 and ends at line 262.
Sync
Black
White
One line
63.625 µs
1
262
248
242
Image
Vertical sync
1/60 s
1
about 0.7%. The 64 pixels per line
thus fill the middle half of the screen.
To make the pixels almost square, I
duplicated them vertically onto two
lines so that the 100 vertical pixels
covered 200 video scan lines. This
duplication also reduced flickering.
To display an image, you need to
compute points, lines, and text to fill
the image RAM. I wrote a point plotter
routine that could set, clear, or invert a
pixel given its x, y coordinates. On
top of the point routine, I wrote a
Breshenham line drawing routine that
runs quickly on a small CPU because
it requires no divisions, only shifts and
42
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
adds. [5] I wrote two character genera-
tors, one for 5 × 7 characters and one
for 3 × 5 characters. The 3 × 5 charac-
ters are adequate for numbers, but mar-
ginal for text. However, the 3 × 5 char-
acters can be drawn quickly because
they’re placed into image memory via a
bit copy operation and do not use the
point drawing routine. The 5 × 7 char-
acters are placed into image memory
point by point. The precise placement
creates better-looking and denser text.
On top of the character generators are
functions that take string input.
Two port pins are used: one for the
video level and one for the sync level.
The output logic levels are converted to
video levels and impedance using three
resistors and two diodes (see Figure 2).
Including the diodes made it easier to
figure out the values of the resistors.
APPLICATIONS
After the sync generation and pixel
blasting is done, the Mega163 still has
some cycles leftover. On lines that
don’t display the image (lines 231 to
262), the CPU is used for about 7 µs
for sync generation; the rest of the
63 µs is available for general computa-
tion. The number of cycles available is
about 55 × 20 × 8 = 8800 (microsec-
onds per line × number of lines ×
8 cycles per microsecond). I wrote a
few simple applications to see what
would fit into 8800 cycles and not
interfere with the image generation.
To test the image generation, I
wrote a command line interpreter that
received commands via the UART
from Microsoft HyperTerminal. I
implemented commands for line,
point, and text. Also, the entire image
could be erased (see Photo 1).
To avoid image degradation from
asynchronous UART events, the
UART was polled 60 times per second
for an incoming character. The com-
mand string was built up until a car-
riage return occurred, and then inter-
preted during the interval when no
image lines were actually being dis-
played. This program is a prototype for
a student lab in which one CPU gener-
ates video (the graphics controller)
while another connected CPU com-
putes a game, sends graphics com-
mands, and produces sound effects.
Port D.6 video
Port D.5 sync
75
Ω
To TV
1k
Ω
300
Ω
Figure 2—During a 0-V sync pulse, both outputs are
low. At the black level, the sync output is high. At the
white level, the video output is high.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
43
I wrote a diffusion-limited aggrega-
tion (DLA) program to check the parti-
cle dynamics and the image RAM
read-back (see Photo 2). A DLA is a
structure that grows by sticking new
particles to an existing clump. The
DLA generally develops a fractal shape
as more particles stick to it. In my
code, the DLA starts as a single pixel
in the center of the screen and grows
every time a randomly moving parti-
cle happens to hit it. When a particle
hits, it is frozen in place, and a new
particle appears at the edge of the
screen to diffuse. A single particle can
easily move 60 random steps per sec-
ond, including: erasing the old posi-
tion; computing two random steps (x
and y); drawing the new position;
checking for adjacent frozen particles;
releasing a new particle (if necessary);
and updating the clock display once
Bruce Land is a senior research asso-
ciate in the Neurobiology and Behavior
Department and Electrical and
Computer Engineering Department at
Cornell University. He teaches two
courses in NB&B and one in ECE. He
provides general research support in
electronics design and computer tech-
niques. When time allows, he does
some neural modeling. You may reach
him at brl4@cornell.edu.
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2003/150/.
REFERENCES
[2] A. Ricci Bitti, “Video DVM,”
www.geocities.com/Cape
Canaveral/Launchpad/3632/
dvm.htm.
[3] G. Williamson, “Television,”
www.williamson-labs.com/
480_tv.htm.
[4] R. Gunée, “Software Generated
Video,” www.efd.lth.se/%7Ee96
rg/mc/mc.html#softvideo.
[5] D. Rodgers, Procedural Elements
of Computer Graphics, 2nd edi-
tion, McGraw-Hill, New York,
NY, October 1997.
SOURCE
AVR Mega163
Atmel Corp.
(408) 436-4270
www.atmel.com
Listing 1—Amusingly enough, the logic to generate 5-µs sync pulses exactly fits in about 40 cycles (5 µs);
thus the C code is sufficient except for a few lines of code written in assembler.
//The sync generator must be entered from Sleep mode to get accu-
rate timing of the sync pulses. At 8 MHz, all of the sync logic
fits in the 5-µs sync pulse.
syncON is initialized to zero
syncOFF is initialized to pull bit 5 high: 0b00100000
The tokens "begin" and "end" are used instead of the usual
C curly brackets
*/
interrupt [TIM1_COMPA] void t1_cmpA(void)
begin
PORTD = syncON; //Start the sync pulse
LineCount ++ ; //Update the curent scanline number
//Begin inverted (vertical) sync after line 247. Inverting sync
means reversing the values of syncON and syncOFF.
if (LineCount==248)
begin
syncON = 0b00100000;
syncOFF = 0;
end
//Back to regular sync after line 250
if (LineCount==251)
begin
syncON = 0;
syncOFF = 0b00100000;
end
//Start new frame after line 262
if (LineCount==263) LineCount = 1;
PORTD = syncOFF; //End sync pulse
end
//ISR
per second. This program is a proto-
type for a game-type student lab.
To test its performance, I tried to
see how many new characters or lines
I could draw before the image genera-
tion code overran into the image
refresh time. I could write four large
characters (4 × 35 = 140 pixels writ-
ten), 40 small characters, or four
lines, each one-half the screen width.
A complex image can be built up over
several frame times, but any animat-
ed pieces of the image must be limit-
ed to less than about 140 pixels per
frame. Recoding the point routine in
assembler speeds up line drawing by
about a factor of two; I plan to assign
this task as a student lab exercise.
IN THE LAB
I plan to use this software in an
upcoming semester. The performance
is good enough for simple games (e.g.,
Pong or Snake), a clock, a digital volt-
meter, or an oscilloscope display. The
real-time control of the TV in itself
makes a useful learning exercise. I look
forward to seeing what kinds of things
creative students will do with it. You
may download the source code from
the Circuit Cellar ftp site or the
Cornell web site (instruct1.cit.cornell.
edu/courses/ee476/video/index.html).
I
44
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
lthough the
“electric airplane”
buzzword seems to be
everywhere, the princi-
ples and activities it stands for are
anything but new. The automobile
industry has been gradually replacing
hydraulic actuators with electric
motors for years.
Hydraulic actuators have been the
workhorses of the industry for many
good reasons. In particular, their
excellent size-to-power ratio, low
weight, simplicity, and reliability fig-
ure prominently on the side of the
positives. So, why replace them when
electric motors have a long way to go
to catch up to their performance,
price, and weight? To understand
this, you must consider them as part
of an entire system.
Continuously generating 3000 psi of
hydraulic pressure, whether it’s need-
ed at the moment or not, and distrib-
uting it throughout the vehicle via a
hot, corrosive fluid like Skydrol is
inefficient. The hydraulic pumps must
run continuously, the ancillary equip-
ment is heavy, and the potential for an
accident because of a broken hose or
leakage is considerable, the cost and
frequency of maintenance notwith-
standing. One study shows that the
substitution of traditional hydraulic
systems with electric ones on the new
Airbus A380 super jumbo airplane
could save 1000 lbs.
Some systems have an intermedi-
ate solution in which the electrically
driven hydraulic pump forms an inte-
gral unit with the hydraulic actuator.
But, with the development of new
materials for powerful permanent
magnets and, consequently, more effi-
cient, powerful, and lighter electric
motors, the time when most vehicle
actuators will be electric motors is
not too far away.
The state-of-the-art brushless
direct current (DC) motors run at
more than 20,000 rpm, easily deliver
60 to 100 kW of power, and are
incredibly small. To ease the heavy
current burden on a vehicle’s wiring
that’s required to carry power to the
motor, some European manufacturers
(e.g., Mercedes) have already raised
their battery voltage to 42 V from
the common 12 V.
Aircraft have been using 28 V for a
long time. For reasons of airworthi-
ness certification, this probably won’t
change anytime soon. But, unlike
cars, aircraft have 115-V, 400-Hz,
three-phase power available. You’ll
find that many electric actuators on
aircraft run from 200 to 300 VDC.
Generating that kind of supply is a
subject for another article.
I was recently reviewing the specifi-
cations for a new, electrically actuated
flight control system. Everything
looked straightforward until the last
paragraph on the last page where the
author stated, almost as an after-
thought, that the system availability
must be better than 10
–7
. Obviously,
this was a mistake. The author meant
Building an Electric Airplane
a
When it comes to
planes and automo-
biles, many engineers
see electric motor
technology as the
ticket to an energy-
efficient, cost-effective
future. With this in
mind, George shows
us how to design an
electrically actuated
system, focusing on
control and braking.
George Novacek
FEATURE
ARTICLE
Stator
Rotor
Permanent magnet
Figure 1—For this typical brush-type motor, the stator
is created by permanent magnets and the rotor by sev-
eral windings fed through a brush commutator.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
45
MAGNETISM
Figure 1 depicts the cross section
of a typical DC motor with a perma-
nent magnet stator. The rotor (or
armature) contains several windings.
Electrical current is directed to the
windings through the brush commu-
tator in such a way that the magnet-
ic field generated in the armature
creates torque.
Mathematically, a brushless DC
motor can be described by two equa-
tions. Equation 1 refers to the back
electromagnetic force (EMF):
E = 2NlrB
ω
[1]
The torque (T) is computed in the fol-
lowing way:
[2]
I’m going to refer to several other
equations in this article, so make sure
that you’re familiar with the follow-
ing variables: N is the number of
winding turns per phase; l represents
the length of the rotor; r denotes the
internal radius of the rotor; B stands
for the rotor magnet flux density;
ω
is
the motor’s angular velocity; i is the
phase current; L is the phase induc-
tance;
θ
is the rotor position; and R is
the phase resistance.
Torque is defined as the product of
force and the perpendicular distance
from the pivot to the force vector. You
T = 1
2
i
2
dL
d
θ
1
2
B
2
dR
d
θ
+ 4N
π
Brl
π
i
–
that the probability of a system fail-
ure had to be less than 10
–7
, or that
the system availability is 1 – 10
–7
.
This translates to a guarantee that
the system will work with
99.99999% certainty.
This is no laughing matter, but it
can and must be done if the electric
airplane is to become a reality. In
this article, you’ll learn about the
backbone to the electric airplane
concept, which is synonymous with
the electric actuator. In addition, I’ll
help you review the fundamentals of
electric motors by focusing on the
brushless DC motor, or BLDC, as it
is called in the literature. You won’t
learn how to design one, but you’ll
walk away with an understanding of
the underlying principles of this
amazing device, without which the
electric airplane could never exist.
We’ve already walked through the
steps to design an electrically actuat-
ed system that meets the tough,
99.99999% reliability requirement. I
urge you to review my article
“Designing for Reliability” (Circuit
Cellar
125 and 126) to brush up on
the theory of predicted reliability and
fault tree analysis, which you’ll find
useful if you start your own project.
Another useful article to read is “A
Sure Thing—Guaranteeing 99.99999%
Reliability” (Circuit Cellar 129).
You’ll design the system architec-
ture before the power drivers and
controller. To do so, you must devel-
op an understanding of how to tackle
tough design problems, such as this
one, where performance and avail-
ability are paramount.
Note that you cannot design an
electrically actuated system—be it for
aircraft, automobiles, or robotics—
without understanding its motor. So,
let’s start by reviewing what electric
motors are all about. I’m going to
focus on DC brushless motors,
because they’re the most versatile and
common type for critical applications,
although the principles you’ll learn
are equally valid and transferable to
the other motor types.
ELECTRIC MOTORS
The DC motor has been around
since the early days of electricity; it’s
one of the oldest and most common
methods of converting electrical
power to mechanical power. The ori-
gins of this technology can be traced
to Michael Faraday, the nineteenth-
century British physicist credited with
formulating the fundamental concepts
of electromagnetism.
The popularity of DC motors
diminished somewhat at the end of
the nineteenth century, when DC
power distribution was replaced with
AC. AC-operated induction motors
were simpler, less expensive to
manufacture, and didn’t suffer the
inherent problems of the brush
commutators (i.e., their limited life
and need for maintenance). DC
motors, however, were never
replaced in applications where AC
power was not available or the
unique characteristics of the DC
motor (e.g., high starting torque,
high speed, easy reversing, and speed
control) were prerequisites.
With the development of brushless
commutators, DC motors in their
BLDC incarnation have gained a
presence in areas where the brush
DC motors were traditionally diffi-
cult to use because of their high
level of electromagnetic interfer-
ence and brush maintenance
requirements. Usually, preference
was given to other types of actua-
tors (e.g., hydraulic).
But, you shouldn’t assume that
the traditional DC motor is dead.
To this day, there remain many
applications where the brush-com-
mutated DC motor’s characteristics
and low cost, despite their known
weaknesses, are impossible for other
actuators to beat.
Shaft v
elocity
Torque
Figure 2—A permanent magnet DC motor shows a lin-
ear relationship between torque and speed. Notice that
maximum torque is achieved at zero speed (i.e., start-
up). PM motors are more efficient than wound-type ones.
Stator
Rotor
Permanent magnet
Figure 3—It sure looks similar to the brush-commutat-
ed motor, but there are some important differences.
Notice how the windings are now in the stator, and the
rotor is made of a permanent magnet.
46
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
can write this as: T = F × r, where T
stands for the torque, F represents
the magnetic force, and r is the
radius of rotation. If several forces of
different magnitude are applied at dif-
ferent points along the radius, the
resultant torque is:
[3]
The sum describes the turning
moment of the shaft and
includes negative torques,
which are caused by bearing
and brush friction. The
torque triggers the rotor to
turn, while the current is
switched to the successive
sets of windings to maintain
the rotation.
When a current-carrying
conductor is placed in a mag-
netic field, a force will act on
it. The magnitude of this
force is a function of magnetic
flux density (B), the current
(I), and the orientation of the
field and current vectors. If
the conductor is considered to
be of unit length, the force is:
[4]
The exact opposite also
exists. If a conductor is
moved through a magnetic
field, an electric voltage is
generated across the conductor. For
a unity-length conductor, you can
write E = B × v, where v is the speed
of the conductor moving through
the magnetic field.
This important aspect is responsi-
ble for the back EMF and used for
power generation. To decrease the
torque ripple and keep the coil
inductance low (thus minimizing
EMI generated by an inductive kick
at the coil switch-over), a typical
brush-commutated rotor has numer-
ous windings. Despite the usually
large number of windings, some-
times you’ll see just two or three in
inexpensive motors.
The stator is commonly made of a
permanent magnet. Modern, high-
coercivity permanent magnets
allow you to build small DC motors
that are powerful and efficient.
Motors have been built with stator
windings instead of (or in combina-
tion with) permanent magnets.
These windings can be in parallel or
in series with the rotor, allowing
you to create motors with different
characteristics.
The focus of this article is on
BLDCs, which use permanent mag-
nets, so I won’t dwell on the wound-
field type of motors. You should note,
however, that permanent magnet
(PM) motors have significant advan-
tages over the wound-field motors,
because they have a linear torque-
speed characteristic.
The wound-field type of motor
exhibits significant nonlinearity at
high torque. This is because of the
stator magnetic flux weakness caused
by armature reaction. PM motors also
feature high stall (accelerat-
ing) torque. With permanent
magnets, there is no need for
electric power to generate the
stator magnetic field. Thus,
PM motors are more effi-
cient, and, for a given output
power, the frame of the PM
motor is smaller and lighter.
The torque characteristic of a
permanent magnet DC motor
is illustrated in Figure 2.
DROPPING THE BRUSHES
You can switch the stator
and rotor so that the rotor is
made of a permanent magnet
and the stator is composed of
windings (see Figure 3).
Although you can see only
two poles, the rotor can be
composed of numerous per-
manent magnets, depending
on the requirements.
The task of commutating
(i.e., selectively feeding elec-
tric current into the windings)
0
A–B
60
360
300
240
180
120
60
Q6
Q5
Q4
Q3
Q2
Q1
B–C
A–C
–60
Figure 4—You can build a brushless motor commutator with MOSFETs, bipolar transistors, IGBTs, and thyristors,
although additional circuits are needed to turn the thyristors off.
Figure 5—As you analyze the timing diagram of the brushless motor, you
should refer back to Figure 4 so you can identify the windings and switches.
What's Hot!
Before
Can't use all outlets
After
Every outlet is usable
Get full use of your power strips and UPS
outlets with our quality adapter cable. Plug your
big bulky power adapters into our cables then plug
the cables into those previously unusable outlets!
121 2570
Liberator II
doubles your
outlets
To order call 800-892-1010 or online
at www.cyberguys.com/cc0103
121 2550
$
1
79
121 2550
Original
3-in-1 Pen Tool, Now You Can Write,
Fix and Repair With a Single Tool!
This convertible slotted/
Philips screwdriver is a space-
age pen too. Constructed of
heat-treated S-2 tool-steel, with
a tough nylon handle, these drivers can exceed 60
inch-pounds of torque. The pen inside with a pres-
surized ink cartridge, writes underwater, on most
any surface, at any angle (even upside down), at
temperatures down to -30˚F. and lasts three times
longer than typical ballpoints.
When the handle is on, the pen point
is retracted and protected...
...but slip off the handle and a hidden
pen emerges from the Philips point.
10 of each:
•
insulating washers
•
hex head screw
•
pan head screw
•
mini jumpers
•
brass standoff
•
hard drive screw (fi ne thread)
•
taper head screw (fi ne thread)
•
pan head screw (self threading)
Technician's Shirt Pocket
Hardware Pack
Be Prepared!
Be Prepared!
$
2
49
Keep Switching Power Supplies “Alive”
Connect this “dummy
load” to the +5VDC
output of any switching
power supply to keep the
supply switched ‘on’—no
motherboard required.
ATX Power Supply Tester
Quickly diagnose power
supply problems
Plug this tester into
the motherboard power
connector of your ATX
power supply, power up,
and the LED indicator
shows if your power
supply is good or bad.
"Keystroke-Catcher" Records Up to 32 Pages of Typed Text
1
- Discreetly installs between keyboard and
motherboard. No software needs to be loaded.
3
- Records keystrokes to a plain
text fi le which can be viewed on most
wordprocessors. Includes NetPatrol
™
feature to
identify web
addresses and a
custom search
function.
2
- KeyKatcher captures EVERYTHING typed on your keyboard:
E-mail, instant messaging, chat room activity, web URL’s, etc.
Protect your children from the ever-present
dangers on the internet or monitor unauthorized
use of your computer with the KEYKatcher
™
.
With 64k of memory the KEYKatcher
™
records
approximately 32 typed pages of text. A change-
able password allows only the authorized user to
view recorded keystroke fi les.
Plug-In NiCd/NiMH Charger FULLY
Recharges Hi-Capacity Batteries
FULLY
recharge your
high-capacity
batteries again
and again!
Finally! A battery
charger built for power
users who depend on
their personal elec-
tronics and use them
hard. Most chargers
cannot fully recharge
the new breed of high-capacity batteries. This
charger was designed to do exactly that.
AA Batteries
Flip down adapter
AAA Batteries
To order call 800-892-1010 or online
at www.cyberguys.com/cc0103
113 0282
$
9
95
To order call 800-892-1010 or online
at www.cyberguys.com/cc0103
115 3112
$
12
75
To order call 800-892-1010 or online
at www.cyberguys.com/cc0103
141 0345
$
18
98
•
Charge NiCd/NiMH batteries up to 1000x
•
Accepts AA/AAA & NiCd/NiMH batteries
•
NiMH batteries are environmentally friendly
and suffer no memory effect
Includes
4- 1800mAh
AA batteries
To order call 800-892-1010 or online
at www.cyberguys.com/mpc0103
115 7655
$
18
49
Charging slot on
back holds two
more batteries
HOT Price!
HOT Price!
$
1
79
COOL Item!
COOL Item!
$
2
99
132 0393
$
66
95
To order call 800-892-1010 or online
at www.cyberguys.com/cs1002
Be Secure!
Be Secure!
$
66
95
Switched On!
Switched On!
$
9
95
ATX Tester!
ATX Tester!
$
12
75
Recharge!
Recharge!
$
18
98
Work/Write!
Work/Write!
$
18
49
To order call 800-892-1010 or online
at www.cyberguys.com/mpc0103
115 1025
$
2
49
Power Strip Liberator
64K memory -
approximately
32 pages of text
Spend $100 and we'll throw in a cool Cyberguys
48
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
Figure 6—Brushless commutation is easy to achieve with off-the-shelf dedicated ICs such as the ECN3018 from Hitachi.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
49
no longer requires a rotating commuta-
tor, and, thanks to modern electronics,
it can be simple. You must detect the
position of the rotor and feed current
into the appropriate windings via
electronic switches. When you do, the
brushless motor is born.
Such a motor has numerous advan-
tages. In particular, it gets rid of unre-
liable brushes and their horrible EMI,
the suppression of which is a major
problem in applications where elec-
tronic circuits are in proximity. The
stator has greater thermal mass than
the rotor and is much easier to keep
cool. This arrangement also elimi-
nates the serious failure of brush-
commutated motors caused by the
loosening and jamming of a rotor wire
between the stator and rotor, effec-
tively stopping the motor.
You’ll also find applications where
the physical location of the rotor and
stator in a brushless motor have been
reversed. The electronically commu-
tated stator sits inside the motor,
while the permanent magnet rotor
revolves around it. This arrangement,
although not as efficient in terms of
thermal conduction as the external
stator, has the advantage of larger
inertial mass and is used when a low
torque ripple is needed. In addition,
it’s commonly used in computer cool-
ing fans. In some applications (e.g.,
tape decks), this design has been
known to take over the function of an
otherwise costly and bulky flywheel
and drive the spindle directly.
The electronic commutation of a
brushless motor is illustrated in
Figure 4. You can replace MOSFETs
Q1 through Q6 with bipolar transis-
tors, IGBTs, and even thyristors,
although the use of thyristors would
require special care in order to make
sure they’re turned off consistently.
The drawing shows the most com-
monly used configuration—the three-
phase, full-bridge driver.
Similar to the brush-commutated
motors, it’s certainly possible to
have more than three windings in
the stator, but the benefits aren’t
usually worth the additional cost of
the more complex drivers, switching
logic, and windings. Inasmuch as
brushless motors can be run at high
speeds (20,000 rpm is not unusual)
and the rotors are composed of a
number of poles, the torque ripple is
rarely a problem.
The characteristics of solid-state
switches, compared to those of
mechanical brushes, don’t make the
need for low-winding inductance a
critical issue. Similarly, the savings
achieved by using H-Bridge drivers or
two windings instead of three rarely
outweighs the losses in performance.
The high volume of commercially
available, inexpensive, off-the-shelf
drivers and switching logic circuits
makes it difficult to justify deviation
from the established three-phase, full-
bridge standard configuration.
The freewheeling diodes connected
in parallel to switches Q1 through Q6
0
10
20
30
40
50
60
70
80
90
100
Torque
Synchronous speed (%)
Step rate (shaft velocity)
Torque
a)
b)
Figure 7—As you can see in these graphs concerning the torque and speed of an induction motor, the usefulness
of velocity control is limited to a small region ranging from 85% to 100% of the synchronous speed. b—The dis-
continuities you see in this stepper motor graph are caused by resonances that are inherent in the motor’s design.
50
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
serve an important purpose (see
Figure 4). When a switch turns off
(like an automobile ignition coil),
the energy stored in the magnetic
field of the stator winding causes an
inductive transient voltage to rise to
a level that’s likely to destroy the
switch. The diodes provide paths for
the energy to dissipate in the cur-
rently active windings and power
supply capacitor (C1).
The timing diagram in Figure 5
explains the brushless motor opera-
tion. The top traces show the wind-
ing current, and the bottom traces
show the status of switches Q1
through Q6. Note that conduction is
always continuous in one leg, while
the other is being commutated. For
example, when Q1 is conducting dur-
ing the first 60° of rotation, Q5 is
also conducting and current flows
from point A to point B. In the next
sequence, 60° to 120°, Q6 is ener-
gized and the current flows from
point A to point C. In the meantime,
the current through leg B declines to
zero through its freewheeling diode,
adding to the power supply. The full-
bridge topology remains efficient by
making sure that two-thirds of the
windings are always operational.
TIMING IS EVERYTHING
The electronic switches require pre-
cision sequencing. This is achieved
with a microprocessor, DSP, FPGA, or
dedicated IC. The off-the-shelf con-
troller depicted in Figure 6 is manu-
factured by Hitachi. If you spend some
time searching of the Internet, you’ll
find other sources such as Texas
Instruments, International Rectifier,
and Unitrode, just to name a few.
Different schemes, such as optical
encoding, can detect the shaft posi-
tion, but the most prevalent method
seems to be the use of Hall effect
sensors. Many commercially avail-
able ICs already come equipped with
the Hall effect sensor-conditioning
circuits. Needless to say, engineers
succeeded in cutting costs by simpli-
fying the BLDC construction, so it
shouldn’t come as a surprise that the
rotor-position sensors have been elim-
inated in some designs.
In the simplest approach, the timing
is calculated by a microprocessor,
which works in an open-loop system.
An improved solution uses the back
EMF to establish the position and
rotational speed from which it com-
putes the timing sequence. Another
design needs only one Hall effect sen-
sor instead of three, using its signal to
synchronize a phase-locked loop (PLL),
which then controls the generation of
the timing sequence.
All of these modifications improve
the cost savings by sacrificing per-
formance in one way or another. So,
if optimal performance with maxi-
mum efficiency is your goal, the
three sensors are the way to go.
OTHER MOTORS
Control circuitry for brushless, step-
per, and frequency-controlled induc-
tion motors may appear nearly identi-
cal at first glance; however, the differ-
ence between the motors is best
demonstrated by their respective
torque-versus-speed diagrams. The
Talk the language. Talk SCPI with JPA-SCPI Parser.
Take a look at some of the highlights
Suitable for any peripheral interface
e.g. GPIB, RS232, USB etc.
Works on almost any processor/platform
Minimal ROM & RAM requirements
Written in C, fully ANSI/ISO compliant
Fully compliant to current SCPI standard
C source code comprising the parser itself
and access functions
Template command sets for 10 common
types of instrument
Base template suitable for all instruments
Comprehensive user manual to take you
through each stage to your SCPI parser
Unlimited royalty-free runtime licenses
Free technical support and product
upgrades for 1 year
A multi-brand site license is available for
consultancy houses:
accelerating product development
Download our demo application to see
for yourself just what it can do.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
51
brushless motor has the same per-
formance as the DC permanent mag-
net motor shown in Figure 2. In con-
trast, the induction motor’s character-
istics are revealed in Figure 7a, and
the stepper motor’s characteristics are
shown in Figure 7b.
The induction motor shows a
completely different torque-speed
relationship. In velocity-control
applications, the induction motor’s
usefulness is limited to 85% to
100% of synchronous speed. The
stepper motor also exhibits a nonlin-
ear relationship between the torque
and speed. What’s more, the discon-
tinuities in this characteristic,
which are caused by resonances
inherent in the motor design, give
this unique and otherwise useful
device limited value in velocity-con-
trol applications.
CONTROL CHARACTERISTICS
It’s easy to control the speed and
direction of a DC motor. This is an
important attribute, particularly
when precision motion control is
required (i.e., for operation in
closed-loop control systems). You
can achieve this via voltage and
polarity variation, but changing the
supply voltage amplitude is not
energy efficient.
Currently, pulse width modulation
(PWM) is the most prevalent speed
control, even for small motors. The
same principle is fundamental to
brushless motors. Polarity reversal is
not practical for brushless motors;
therefore, turning the switching logic
by 180° reverses the rotation.
A brushless motor’s controller is
more than just a sequencer. In fact,
it’s a sophisticated closed-loop con-
troller. Figure 8 illustrates a typical
BLDC motor control, consisting of
two closed loops (i.e., a velocity
loop and current loop). This is the
George Novacek has 30 years of expe-
rience in circuit design and embed-
ded controllers. He is currently the
general manager of Hispano-Suiza
Canada, a division of Snecma Group
of Companies, the world’s leader in
manufacturing propulsion and land-
ing-gear systems. You may reach him
at gnovacek@nexicom.net.
RESOURCES
Electro-Craft Corp., DC Motors,
Speed Controls, Servo Systems
,
5th ed., Hopkins, MN, 1980.
G. Novacek, “Designing for
Reliability,” Circuit Cellar 125
and 126, 2001.
G. Novacek, “A Sure Thing—
Guaranteeing 99.99999%
Reliability,” Circuit Cellar 129,
2001.
brain that makes the brushless
motor what it is today.
The current can be measured as a
voltage drop across a small sensing
resistor in the driver, such as R
S
in
Figure 6. For larger motors, however,
other means are necessary. Current
transformers and Hall effect sensors
are common.
For velocity control, rotational
speed measurement is required. You’ll
see tachometers, which are small
dynamos integral with the motor shaft
in many systems, using DC brush-
commutated motors. Tachometers
used to be popular because they were
reliable and simple to work with. They
were expensive, though. The advent of
PWM control, instead of supply-volt-
age modulation through resistors or
regulators, brought with it a less
expensive way of measuring speed.
Based on the principle that the EMF
is proportional to the velocity when
power is not supplied to the motor
during PWM, the windings generate a
voltage called the back EMF. By
measuring this voltage during the
powerless time slot, you can deter-
mine the motor’s speed.
With brushless motors, it’s much
less complicated to measure velocity.
You already have a sensor on the shaft
to control the switching sequence. By
counting and timing the pulses, the
control electronics determine the
speed accurately. Precision velocity
control, inherent to the brushless
motor, is another attribute responsible
for its success in robotics and modern
positioning systems in general.
BRAKING
Our discussion about motor control
wouldn’t be complete if I didn’t talk
about braking. Being able to stop the
motor quickly is just as important as
acceleration. And, once again, help
comes from the back EMF.
Speed
computation
PI
Controller
PID
Controller
Synchronization/
PWM control
Three-phase
inverter
Three-
phase
BLDC
motor
Speed
Position
Speed
reference
I Phase
I Ref
+
–
–
+
Figure 8—The BLDC motor control comprises a couple of control loops: velocity and current.
By diverting the back EMF into an
electrical load, you effectively apply
brakes to the motor. The load resis-
tors dissipate the power as heat, and
you can adjust the deceleration (i.e.,
the braking force) by changing the
load or duty cycle by PWM. With
proper gating, bridge drivers that are
already in the system can be used to
this effect, whether they’re in brush-
less motors or H-type PWM brush
motor drivers. You must make sure
they can handle the energy, because in
some systems braking power can
exceed driving power.
Now you have a better understand-
ing of one of the most essential
building blocks for constructing elec-
tric airplanes and automobiles. I
expect the electric automobile to
become a reality by the middle of
this decade. By that time, the electric
airplane will be in the midst of its
certification testing.
The phrase “fly-by-wire” is being
transposed to automobiles not only as
“drive-by-wire,” but also as “x-by-
wire.” This means that the transporta-
tion industry will use electric actua-
tors to replace many mechanical and
hydromechanical functions in today’s
automobiles and airplanes in an effort
to save money, weight, and energy.
I
52
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
nstrument
designers seldom
talk to IT depart-
ments. But, this will
change with the increased use of
extensible markup language (XML)
coded data. Most IT departments have
decided to implement XML through-
out their companies, which means
that XML must extend to the requests
sent to instruments and the data gen-
erated by them.
Consequently, instrument manufac-
turers must start polling their poten-
tial customers and speaking to IT
department database designers. In
many cases, database designers have
already defined a schema for their
XML coded data. A manufacturer can-
not economically customize every
instrument, but it’s possible to devise
a common set of XML tags that are
easily mapped to the existing database
schema. This collaboration must
broaden to competitors and other man-
ufacturers supplying instrumentation to
the same industry. To date, only a few
industries have created industry-wide
XML standards like this.
The information coded with XML
doesn’t have to be data; it can
include actions and related parame-
ters similar to remote procedure calls
(RPC). Now, IT departments have the
ability to control and manage devices
on the plant floor.
XML BASICS
XML provides a processor-independ-
ent way of encoding data for inter-
change between diverse systems. Like
hypertext markup language (HTML),
XML is derived from standard general-
ized markup language (SGML); howev-
er, XML is simplified for easier machine
parsing. Unlike HTML, XML has no
predefined meanings associated with
its elements or tags. Instead, it’s a set
of rules (a syntax) for constructing tag-
delimited information. Individual
XML documents can use different ele-
ment definitions to encode informa-
tion from dissimilar data environ-
ments. A set of element definitions to
encode data from a particular data envi-
ronment is called a “schema.”
Different schemas or element defi-
nitions that use XML syntax are being
developed for diverse application envi-
ronments. Some of these schemas
include vocabularies for chemical
engineering, vector graphics, electron-
ic invoicing, weather information, and
spreadsheet formulas. A specific XML
schema (tag set definition) can be
defined by one organization and pub-
lished for others. For example,
Microsoft has defined a set of XML
tags for exchanging spreadsheet and
word processing documents with the
Office 2000 and Office XP product
suites. Industry standards groups
sometimes get together to define ele-
Embedded XML
i
The popularity of XML
is growing. As a
result, engineers must
work closely with IT
departments to meet
data management
requirements. The
task can be difficult,
but there are ways
you can help enhance
data flow without hav-
ing to customize each
device you design.
Edward Steinfeld
FEATURE
ARTICLE
Make Your Customer’s IT Department
Happy
Incorrect (acceptable as HTML)
Correct (required by XML)
<tag>data
<tag>data</tag>
<tag1><tag2>data</tag1></tag2>
<tag1><tag2>data</tag2></tag1>
<tag1 arg1=abc>data</tag1>
<tag1 arg1="abc">data</tag1>
Table 1—It’s important to note the differences between XML and HTML. When comparing the strict XML format-
ting to HTML, remember that XML is case sensitive and attributes within tags require quotation marks.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
53
and the IT department. Special embed-
ded XML parser/framers are used in
the testing instruments.
XML/HTML COMPARISON
As I explained earlier, HTML and
XML were derived from the tag descrip-
tion language SGML. There are differ-
ences, though. Both SGML and HTML
describe the format of the data; alterna-
tively, XML describes the content of
the data. Unlike XML tags, whose defi-
nitions are up to the programmer (and
sometimes the industry), all SGML and
HTML tags are predefined.
Before I continue with this compari-
son, I want to familiarize you with
XML’s key features: all elements must
be balanced with a start tag and end
tag, or they must use a special self-ter-
minating format; nesting is strictly
enforced; and attributes within tags
always use quotes. Finally, remember
that XML is case-sensitive; therefore,
for example,
<TAG>, <tag>, and
<Tag> are different and could have
different meanings (see Table 1).
XML syntax provides a free-format
interchange of data. The definitions of
the schema can be documented in a
number of ways, allowing communi-
ties of users other than the original
definer to understand what the design-
er of the schema intended. You can
document schemas with SGML DTD
language, W3C XML schema defini-
tion language, or other techniques
using XML primitives. The XMLSPY
suite is an inexpensive program that
can help with XML schemas. It’s an
ment sets. Vector graphics and chemi-
cal engineering groups are currently
developing XML schema standards.
Two functions, or programs, are
required to convert a schema-defined
document into internal data and vice
versa. A parser is a program that reads
an XML document and provides
access to the data inside the XML
tags. On the other hand, a framer is a
program that takes internal data and
formats it into an XML document.
HOSPITAL DATA FLOW
From the time a doctor decides to
test a patient’s blood to the time that
data is actually provided, the requests
for and results concerning the tests
pass through a number of steps.
Telling the appropriate instruments
what tests to perform is one of the
important steps in the process.
After a set of tests is chosen, the doc-
tor either enters the requests into a
computer or has a nurse do so (see
Figure 1). The requests are XML framed
and sent to the hospital’s IT computer.
From there, the requests are sent to the
nurse’s station on the floor where the
patient is located. A pick-up list is
printed so the nurses know which
patients are having tests done. In addi-
tion, they’re provided with a bar-coded
labels to attach to the vials of blood.
The IT computer also sends the
requests to the appropriate laborato-
ries. The pathology laboratory receives
the information for blood tests. The
data that’s sent to the lab includes
patient identification material and
specific test information.
The IT computer does not
specify which instruments will
perform the tests, and the same
information is sent to all of the
instruments. Most embedded
XML parsers will ignore data
framed by tags that are not iden-
tified for them. On the other
hand, they’ll accept all of the
data within the tags they under-
stand. This means the same set
of data records can be sent to
every test instrument in the
pathology lab (see Listing 1).
The blood chemistry tester will
accept all tests enclosed by the
ChemTest tag (i.e., blood urea
nitrogen, or BUN test)
,
but will
ignore test requests enclosed by the
CellTest tag. The blood cell analyzer
will accept both the
leukocyte_count
(i.e., total white blood cell count test)
and
diff (i.e., the percentage difference
of each type of white cell) test requests.
All instruments will accept the
patient identification data. In the
meantime, the nurse collects the flu-
ids and carries them to the lab. After
the tests are completed, the results
and patient identification information
are sent to the hospital’s IT computer.
A copy of the results is delivered to
the nurse’s station to be printed or dis-
played. Another copy of the results is
forwarded to the requesting doctor’s
computer. Finally, a copy of the tests
is sent to the billing and insurance
department’s computer.
Generalized XML parser/framers are
used in the computers for the doctor
nurse’s station, billing department,
Figure 1—Something as simple as a routine blood test involves
a lot of communication between numerous people and devices.
In this example, it’s XML framed data that’s flowing from doctors
to instruments and back.
Nurse’s station
Nurse prints barcodes
and picks up list of
patient and samples
to be collected
Nurse gets blood
samples and
delivers to lab
Blood chemistry and
cell analysis
test instruments
(embedded systems)
Hospital’s
central computer
Billing and
insurance
computer
Doctor’s
computer
Doctor orders
blood tests
Requests
Results
Listing 1—XML code is sent to a number of devices. Each device will recognize only the XML tags that
are defined in its
ObjectDefs.o. The other tags are ignored.
<PatientTest>
<Patient>
<FirstName>John</FirstName>
<MiddleName>Wesley</MiddleName>
<LastName>Jones</LastName>
<idNumber>572-89-2387</idNumber>
</Patient>
<PathologyLab>
<ChemTest>BUN</ChemTest>
<CellTest>leukocyte_count</CellTest>
<CellTest>diff</CellTest>
</PathologyLab>
</PatientTest>
54
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
general-purpose XML parser are
prohibitive. An embedded device
doesn’t need a dynamic tag set or
vocabulary, because each embed-
ded tool is typically a dedicated,
single-purpose device. Allegro
provides the RomXML parser/
framer toolkit for such devices.
An embedded XML parser effi-
ciently translates data between
the XML syntax and an internal
format (e.g., a C structure).
Allegro’s RomXML parser/
framer provides a lightweight
translation between predefined
C language structures and XML-
based representations.
By defining the rules for data trans-
lation external to the embedded
device, you can build a small-foot-
print, special-purpose XML translator
that uses dedicated vocabulary defini-
tions to reduce the size of code and
data storage. This permits the embed-
ded device to move data to other
XML editor, schema designer, and
more. You may download a 30-day
evaluation copy from the XMLSPY
web site (www.xmlspy.com).
With some schema definition tech-
niques, a general-purpose parser can
read a DTD or schema file that con-
tains the definitions it needs to parse a
particular XML document. A parser
that checks an XML document for cor-
rect XML syntax is said to be check-
ing for well-formed XML documents.
A parser that checks XML documents
against an external DTD definition is
said to be a validating parser. Because
embedded systems (as well as devices
and instruments) and their XML tags
are predefined, the schema definitions
can be handled outside the embedded
system, consequently reducing the
system requirements in the device.
XML documents are both human and
machine-readable. The same schema
can be defined using multiple tech-
niques. Allegro Software Development’s
RomXML parser and framer use a spe-
cial schema definition language called
RxSchema. This definition language is
similar to the W3C XML schema defi-
nition that uses XML elements to
define the XML schema. RxSchema
provides control of the internal storage
definition, which is useful in limited-
resource embedded environments.
EMBEDDED PARSER/FRAMER
It’s useful for an embedded device to
exchange XML-based information with
other embedded devices, general-pur-
pose desktop workstations, and main-
frame computers. However, the pro-
cessing and memory requirements for a
machines in an XML-based standard
format without carrying the overhead
of general-purpose XML tools. The
RomXML parser/framer fits in about
10 KB of memory in the device.
Additionally, the RomXML toolkit
uses a set of XML tags to define an
XML object. The XML object is defined
with the C internal storage structures
and the XML tag set that’s used for the
XML-based data interchange.
The RomXML TagBuilder utility
program analyzes the RomXML object
definitions and produces an object
definition file in C language (see
Figure 2a). This is compiled with the
RomXML parser/framer code (see
Figure 2b). The object definition file
contains the transformation tables
that the runtime RomXML code uses
to perform specific translations for
each XML object between the defined
C structures and XML tag set.
The RomXML TagBuilder program
uses standard C library calls for read-
ObjectDefs.xml
ObjectDefs.c
TagBuilder
Figure 2a—Using the TagBuilder utility, you can create XML
object definitions outside the device. b—XML object definitions
are compiled and linked with the application, RomXML runtime
library, and real-time operating system (RTOS).
ObjectDefs.c
RomXML Parser/
framer with
device code
RomXML
runtime
library
Application,
OS, other
libraries
Listing 2—You can transmit different types of information with XML. This portion of an XML framed data
transfer provides a few examples.
<?xml version="1.0"?>
<datarecord>
<Patient OutPatient="false">
<idNumber>572892387</idNumber>
<name>
<firstname>John</firstname>
<middle>Wesley</middle>
<lastname>Jones</lastname>
</name>
</Patient>
<field1>23</field1>
<field2>1026</field2>
<switch>192.23.45.67</switch>
</datarecord>
****************************************************************
You can store the XML framed data in an embedded device using C.
****************************************************************
typedef struct {
Patient sPatient;
Unsigned8 Field1;
Unsigned32 Field2;
char SwitchAddress[4];
} myRecord;
typedef struct {
PatientName sName;
Unsigned32 Number;
Unsigned8 outpatient;
} Patient;
typedef struct {
char FirstName[20];
char MiddleName[20];
char LastName[32];
} PatientName;
a)
b)
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
55
ing and writing the XML object defi-
nition files. It’s delivered in exe-
cutable form as a Windows program
or in source format so you can host it
in a particular UNIX environment.
The RomXML runtime code is a
series of calls that you can use to
handle the XML objects. Therefore,
you can pass an incoming XML datas-
tream and XML object definition to
the RomXML program, and it will
parse the XML datastream into a C
structure (see Figure 3a).
Furthermore, you can pass a C
structure and the XML object defini-
tion to the RomXML program and it
will prepare an XML datastream by
framing the data from the C language
structure with the appropriate XML
tags (see Figure 3b).
RomXML software works directly
with a stand-alone embedded applica-
tion or other Allegro products. XML
datastreams are transmitted to and
from other systems as an HTTP object
with the RomPager embedded web
server or RomWebClient embedded
HTTP client. The XML datastreams
are also sent and received as e-mail
attachments via the RomMailer or
RomPOP embedded e-mail programs.
XML TRANSLATION
An XML document contains XML
syntax elements that describe the
structure of the data and underlying
data. The XML document itself does
not contain any information about how
to store the data in a given device.
Listing 2 shows an example of an
XML document that contains some
information about a customer. The
XML schema or tag set used in this
particular document provides a
framing of the data that can be
clearly understood by both you and
a machine. In order for an embed-
ded device to use the data in this
XML document, it might decide to
store the underlying data in a series
of C structures.
The RomXML parser/framer pro-
vides an efficient mechanism for
translating data between XML and
internal C structure representations
of the data. The RxSchema language
is used to describe the relationships
between the XML document and C
structures. Because XML is a string
language that expresses structure (not
data types), the RxSchema language is
also used to tell the embedded device
that the
<field2> tag frames an
unsigned 32-bit integer value, and the
<switch> tag frames a value
expressed in dotted-decimal notation.
TagBuilder UTILITY
The RxSchema language is expressed
in XML via a notation similar to the
Listing 3—RomXML embedded XML uses an XML-based schema to define the relationships between the
XML data tags and the embedded C program data structure. The schema is used to predefine these relation-
ships; therefore, resources aren’t used during runtime. I compiled this schema using the TagBuilder utility,
and then linked it to the embedded application.
<?xml version="1.0"?>
<objectList>
<object name="myObject">
<header><?xml version="1.0"?></header>
<struct sname="myRecord" fname="myRecord" xname="datarecord">
<struct sname="Cust" fname="sCust" xname="Patient">
<attribute fname="outpatient" xname="OutPatient" type="boolstr"/>
<element fname="Number" xname="idNumber" type="Unsigned32"/>
<struct sname="CustName" fname="sName" xname="name">
<element fname="FirstName" xname="firstname" type="string.ansi" size="20"/>
<element fname="MiddleName" xname="middle" type="string.ansi" size="20"/>
<element fname="LastName" xname="lastname" type="string.ansi" size="32"/>
</struct>
</struct>
<element fname="Field1" xname="field1" type="Unsigned8"/>
<element fname="Field2" xname="field2" type="Unsigned32" default="51"/>
<element fname="SwitchAddress" xname="switch" type="dotform" size="4"/>
</struct>
</object>
</objectList>
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
57
databases, parsers, documenta-
tion, and the like. Few compa-
nies provide an embedded
XML parser/framer product.
Allegro and NetSilicon are
two. Many RTOS vendors,
such as Green Hills Software
and OSE, provide embedded
XML from third parties.
Others, like Wind River
Systems, provide pointers to
compatible offerings. I suggest
that you go to your favorite
RTOS provider to search for
XML products and information.
Allegro’s embedded XML toolkit
products are provided as ANSI C
sources. The toolkit sells for $15,000,
but it’s royalty free for runtime code
sold on a single platform or product.
This is typical of many network
toolkits meant for embedded prod-
ucts. So, make your customer’s IT
department happy. Implement XML
in the next product you design.
I
RESOURCE
SOURCES
RomXML Embedded XML toolkit
Allegro Software Development
Corp.
(978) 264-6600
www.allegrosoft.com
XMLSPY
Altova, Inc.
(978) 816-1600
www.xmlspy.com
Edward Steinfeld has more than 25
years of experience in real-time and
embedded computing. He began his
career as a programmer, writing code
and designing hardware to test hybrid
circuit boards. His international expe-
rience includes a stint in Hong Kong
as a Far East channels manager for
international OEM sales in the Pacific
Rim and Europe. Currently, Ed pro-
vides market research, planning, and
services to the embedded computing
industry. You may reach him at
edward@go-embedded.com.
W3C XML schema definition lan-
guage. The definitions of the XML
document that will be parsed and
framed along with the definitions of
the internal C structure are compiled
by the TagBuilder utility. This utility
provides a compact internal represen-
tation of the translation definitions.
After linking the compiled defini-
tions with the RomXML runtime
library and the rest of the embedded
device software, the device can read
an XML document and call the
RomXML parser to translate the doc-
ument into the internal format. When
the device is ready to create an XML
document, it then calls the RomXML
framer to translate the internal for-
mat into the document.
The XML document that contains
the set of RxSchema definitions for
the sample C language structures
and XML document is depicted in
Listing 3. This example is a modi-
fied subset of an example taken
from the RomXML programming
reference manual.
AVAILABLE NOW
Network-enabled devices become
easier to deploy and interoperate
when IT departments use embedded
XML parsers and framers. When
you’re designing a device, you can
implement the more general XML
products, but the additional required
resources can make the device too
expensive to produce. And, because
embedded or stand-alone products are
usually single-purpose devices, there’s
no need for dynamic tag resolution.
Results tend to vary when search-
ing the ’Net for “embedded XML.”
You’ll get hits for embedded XML
Record.xml
RomXML
parser
ObjectDefs.o
Internal C
structure
Figure 3a—Incoming XML-framed records are scanned by the
RomXML parser program, predefined object definitions, and the
data inserted in the appropriate C data structures. b—Data in the
device is XML-framed by the RomXML framer and the predefined
XML object definitions.
Internal C
structure
NewRecord.xml
RomXML
framer
ObjectDefs.o
a)
b)
Circuit Cellar is available in
58
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
o you remember
your first comput-
er with a hard drive?
What about when 5 MB
was a lot of hard drive space? Have
you ever wanted to put something of
your own on a hard drive without
having to rely on somebody else’s
expensive and proprietary hardware
and driver code? Ever want to read,
write, and control a hard drive with a
microcontroller?
If you answered “yes” to any one
of these questions, then this project
is for you. I’ll show you how to build
an ATA hard drive controller with a
microcontroller and a few common
parts. In addition, you’ll learn
how to write simple code that
will form the basis for deploy-
ing a stand-alone, networkable,
microcontroller-based data
storage system.
Even if you aren’t interested
in communicating with hard
drives, there’s something here
for those of you who don’t need
a microcontroller-driven hard
drive controller. The bonus
track is in the hardware. Do
you need an in-system program-
ming-capable test stand for an
Atmel ATmega128 with RS-232,
Ethernet, and 64-KB of external 16-bit
memory? Well, this project is for you
too. Hard drives or no hard drives,
let’s get started.
THE HARDWARE
Hanging a standard PC or laptop
hard drive from the 40-pin connec-
tor shown in Photo 1 is the reason
why we’re gathered here today. I
wanted the ATA hard drive con-
troller’s electronics to be flexible. So,
in addition to the standard RS-232
port, which is driven by a Sipex
SP233ECT, I added 10-Mbps Ethernet
capabilities with the RTL8019AS/
LF1S022 combination.
The ATmega128 has plenty of
internal SRAM (4 KB), but I thought
adding 64 KB of 16-bit external
SRAM would be nice. Adding the
SRAM is sort of like buying rope:
you can always make the rope short-
er, but it’s a pain to add rope later if
you need it.
The ATmega128 has enough I/O
structure to service the big SRAM
with some help from a couple of
74HCT573 latches. As you can see in
Figure 1, the external SRAM is
attached to the ATmega128 in the
standard manner. This allows those
of you who aren’t interested in plac-
ing bits on a spinning piece of mag-
netically coated aluminum to do
your thing with the big chunk of
SRAM and the raw power of the
ATmega128. With the SRAM in this
configuration, the results of the hard
drive I/O operations can be buffered
by the external SRAM or operated on
by the AVR directly.
Construct an ATA Hard
Drive Controller
d
It’s about time you had
full control of your hard
drive. The controller
you’ve been waiting for
is just one project
away. This month,
Fred shows you how
easy it is to build an
ATA hard drive con-
troller. Amazingly, all
you need is a good
micro and a few every-
day parts.
Fred Eady
APPLIED
PCs
Photo 1—The board is clean and simple. All of the supporting
capacitors and resistors are SMT parts mounted on the oppo-
site side of the board.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
59
Whacker code already has hooks to
allow for the easy transmission and
reception of the hard drive data.
The RS-232 port has a dual purpose.
Running at 57.6 kbps, it’s fast enough
to spit out a sector’s worth of ASCII
data to a terminal emulator for debug-
ging. In addition, it can be used effi-
ciently in an application to transfer
data and commands between the
AVR-based hard drive controller and a
peripheral device. The 10-pin header
makes assembling a serial cable easy,
if you use 9- or 25-pin IDC shell con-
nector parts and ribbon cable.
I’ve standardized with 10-pin male
headers for all of the external ports
with the obvious exceptions of the
Ethernet and hard drive I/O ports. As
long as you put the right connector
in the correct header socket, using
the 10-pin headers with the keyed
shrouds eliminates the possibility of
inserting the ISP and serial connec-
tors incorrectly.
The 10-pin arrangement is also
standard for most of the ISP dongles
that support the AVR series of ISP-
The Ethernet interface, shown in
Figure 2, is actually a wire-by-wire
copy of the Packet Whacker micro-
controller NIC. The original Packet
Whacker firmware that was written
for the ATmega series of AVRs is
used in the ATA hard drive con-
troller code, as well. The Packet
Figure 1—No surprises here, either. The craftiness of this design lies in the way the firmware utilizes the hardware resources.
Listing 1—A core set of registers is the gateway to the hard drive platters. Everything needed to access a
particular data point on the hard drive is represented here.
//ATA I/O port functions and address definitions
//Control block registers
//
RESET
//
|DIOW
//
||DIOR
//
|||DA0
//
||||DA1
//
|||||DA2
//
||||||CS0
//
|||||||CS1
//
||||||||
#define ATA_IO_HIZ
0b11111111
#define ATA_IO_ASTAT
0b11101110
#define ATA_IO_DEVICECNTL
0b11101110
//Command block register addresses
#define ATA_IO_DATA
0b11100001
#define ATA_IO_ERROR
0b11110001
#define ATA_IO_FEATURES
0b11110001
#define ATA_IO_SECTORCNT
0b11101001
#define ATA_IO_SECTORNUM
0b11111001
#define ATA_IO_CYL_L
0b11100101
#define ATA_IO_CYL_H
0b11110101
#define ATA_IO_DEVICE_HEAD
0b11101101
#define ATA_IO_STATUS
0b11111101
#define ATA_IO_CMD
0b11111101
The first spin of the ATA hard drive
controller used a 2-mm header that
mated directly to the 44 I/O pins
found on 2.5
″
laptop drives. My expe-
riences with the 2-mm parts were not
good ones. The pins and connectors
are fragile, and I really don’t like
working with the 1-mm ribbon cable.
In the process of attempting to work
at 2 mm, I purchased a gaggle of new
surplus 2.5
″
Hitachi 540-MB drives.
That purchase, as it turns out, was a
good thing. After junking the 2-mm
idea, I purchased some surplus 850-MB,
3.5
″
drives that turned out to be most-
ly junk. I never really had any inclina-
tion to put real data on them, so it’s
not a total loss. At less than $10 per
drive, what did I expect?
When I bought the laptop drives, I
also purchased some 2-mm to 0.1
″
(or
2.5
″
to 3.5
″
) converter boards. The
idea was to be able to attach the lap-
top drives to a PC for the debugging
and verification of the ATA drive con-
troller’s firmware and hardware.
The moral of the 2-mm hard drive
story is that, thanks to my foresight,
you’ll see how I brought the ATA hard
drive controller to life with the 2.5
″
Hitachi drives and converter boards.
This may sound funny, but when I
was formatting the 3.5
″
850-MB
drives, I was hoping that a few of
them would show some errors. I want-
ed to verify that the hard drive con-
troller could detect them, and then
show you what they looked like. I
really didn’t expect them to be trashed
so badly. So, the drive error examples
will come from the 3.5
″
drives, and
the good data examples will feature
the smaller Hitachi drives.
The ATA hard drive controller
requires a single 5-VDC power source.
Also, the Hitachi drives require only
60
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
capable microcontrollers. I used a
Kanda AVR ISP dongle and a version
of the company’s ISP software to pro-
gram the hard drive controller’s
ATmega128. Because the dongle
interface is dedicated to certain pins
on the AVR and power isn’t trans-
ferred within the programming cable,
I was able to keep the dongle
attached to the hard drive controller
throughout the programming and
debugging process.
The ATmega128 is clocked at
14.746 MHz to keep the data rate
error percentage at a minimum for
the 57.6-kbps serial port. For this
project, the ATmega128 I used was a
5-V part that can run at 16 MHz.
The 14.746 MHz is the closest stan-
dard crystal to the maximum clock
speed that will clock the big AVR
with the least amount of serial data
bit error rate.
Figure 2—If this looks familiar, it’s because it’s actually a Packet Whacker that’s been melded into the ATA controller design. The Packet Whacker code was reused, as well; it
can be found wound into the ATA controller source.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
61
5 VDC. However, the larger 3.5
″
drives
need 12 VDC in addition to the 5 VDC.
The original spin of the hard drive con-
troller used a 2-mm, 44-pin hard drive
I/O attachment point. The extra four
pins on the 2-mm connector provided
5 VDC and ground for the 2.5
″
drives
right at the hard drive I/O connector. In
this spin, the 44-pin, 2-mm pin set is
replaced with the standard 40-pin 0.1
″
pin set, and there isn’t a power supply
outlet at the hard drive I/O connector.
The hard drive controller is equipped
with a standard 4-pin floppy drive
power plug. As you might have fig-
ured out, the inclusion of a standard
PC power connector on the hard
drive controller allows you to power
the 3.5
″
drive and the hard drive con-
troller’s electronics from a common
off-the-shelf PC power supply.
If the 2.5
″
drives are used, you’ll
have to provide an attachment to sup-
ply power to the extra I/O-based power
pins on the drive. That’s where the
2.5
″
to 3.5
″
drive I/O adapters come in.
The adapters I purchased have a 3.5
″
drive power connector that has only
the 5-VDC lines tapped into the 44-pin,
2-mm drive connector. The drive con-
verter board allows you to use the
smaller 2.5
″
drives with the standard
40-pin 0.1
″
cables and a PC power
supply. Although using a commodity
power supply is the easiest way to go,
any other suitable power supply
method will work just as well. Photo
2 is a shot of an Hitachi 2.5
″
drive and
its associated converter board attached
to the ATA hard drive controller.
THE FIRMWARE
I wanted the ATA hard drive con-
troller to be capable of interfacing to
any standard ATA device. With that
design requirement mind, I wrote the
hard drive controller’s AVR firmware
with ImageCraft’s ICCAVR C compil-
er and guidance from the ATA-3 speci-
fication. What I ended up with was a
basic set of routines that allows you
to exercise the standard ATA com-
mand set, query the hard drive register
set, and exchange data with the
attached ATA hard drive.
As soon as I had access to the hard
drive’s register set and data, I set out
to write code to move the data that
Listing 2—Because the routines are identical, with exception to the status bit that’s checked, I took some
liberties and squashed all three
ready, busy, and error routines into a single function to save some
space. The unsigned
int ata_bsy(void) function includes the if(ata_byte_read &
ATA_STAT_BSY) line and the other two functions follow the same logic.
#define recalibrate
ata_send_cmd(CMD_RECALIBRATE)
#define CMD_RECALIBRATE 0x10
#define PORT_ATA_IO_CNTL
PORTF
#define ATA_DIOR
0x20
#define PORT_ATA_DATA_L_IN PINA
#define ATA_STAT_BSY
0x80 //ATA busy
#define ATA_STAT_RDY
0x40 //ATA ready
#define ATA_STAT_ERR
0x01 //ATA error
#define busy
ata_bsy()
#define drq
ata_drq()
#define error
ata_err()
#define ready
ata_rdy()
#define hard_reset
ata_hard_reset()
#define select_device_0
ata_select_device(0x00)
#define select_device_1
ata_select_device(0x01)
#define recalibrate
ata_send_cmd(CMD_RECALIBRATE)
#define identify_device
ata_send_cmd(CMD_IDENTIFY_DEVICE)
*****************************************************************
Initialize drive. This routine assumes drive 0 is the only drive
that is attached.
*****************************************************************
void init_ata(void)
{
while(!ready & busy);
hard_reset;
delay_ms(10);
while(!ready & busy);
select_device_0;
while(!ready & busy);
recalibrate;
while(busy);
if(error)
printf("ERROR!");
printf("\r\nDrive is READY!\r\n");
//Functions are squashed for space savings
unsigned int ata_bsy(void)
unsigned int ata_rdy(void)
unsigned int ata_err(void)
{
unsigned char ata_byte_read;
avr_databus_in;
delay_us(1);
PORT_ATA_IO_CNTL = ATA_IO_STATUS;
PORT_ATA_IO_CNTL &= ~ATA_DIOR;
delay_us(1);
ata_byte_read = PORT_ATA_DATA_L_IN;
PORT_ATA_IO_CNTL |= ATA_DIOR;
PORT_ATA_IO_CNTL = ATA_IO_HIZ;
if(ata_byte_read & ATA_STAT_BSY)
if(ata_byte_read & ATA_STAT_RDY)
if(ata_byte_read & ATA_STAT_ERR)
return 1;
else
return 0;
}
//End of squashed functions
void ata_hard_reset(void)
{
avr_databus_in;
PORT_ATA_IO_CNTL = ATA_IO_HIZ;
PORT_ATA_IO_CNTL &= ~ATA_RESET;
(Continued)
62
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
Listing 1, you’ll notice that the
basic components (in register form)
of addressing data on a hard drive
are represented. Cylinder head sec-
tor (CHS) addressing is implied in
the control block register names;
however, in the ATA hard drive
controller firmware, I’ll use these
was harvested from the hard drive to
the outside world. The first logical
choice of data transport was a serial
port. After thinking it over, I decided
that an Ethernet interface would be an
excellent way to move data in and out
of the hard drive controller. The
Ethernet port would allow the hard
drive controller to be networked and
provide a high-speed data connection
for transfer rates beyond the capabili-
ties of a serial port. In either case (seri-
al or Ethernet), you could use any of
the Visual (e.g., Visual Basic, Visual C)
or Borland compilers to build an
embedded or PC interface to the ATA
hard drive controller.
The first order of business as I start-
ed to develop the AVR firmware was
to define all of the functions that
would run against the hard drive.
With respect to the software, a hard
drive looks like an 8- or 16-bit I/O
port that leads to an internal register
set. Register I/O is normally
achieved in 8-bit mode, while data
transfers are typically performed in
16-bit operations.
If you review Figure 1, you’ll see
that a 16-bit data bus is pinned out on
the 40-pin hard drive I/O connector.
The data bus signals are supported by
a set of I/O read and write signals.
Access to the internal hard drive regis-
ter set is accomplished using the I/O
read/write signals and data bus signals
in conjunction with the address and
select signals found on the 40-pin
hard drive I/O connector. The control
block is the core set of hard drive
internal registers. Listing 1 is my def-
inition of how the control block reg-
isters are addressed.
If you take a close look at the con-
trol block register definitions in
delay_ms(10);
PORT_ATA_IO_CNTL |= ATA_RESET;
}
void ata_select_device(unsigned char device)
{
PORT_ATA_IO_CNTL = ATA_IO_DEVICE_HEAD;
switch (device)
{
case 0x00:
ata_write_byte(ATA_DH_DEV0);
break;
case 0x01:
ata_write_byte(ATA_DH_DEV1);
break;
default:
ata_write_byte(ATA_DH_DEV0);
break;
}
}
void ata_send_cmd(unsigned char atacmd)
{
PORT_ATA_IO_CNTL = ATA_IO_CMD;
avr_databus_out;
PORT_ATA_DATA_L_OUT = atacmd;
ata_write_pulse;
PORT_ATA_IO_CNTL = ATA_IO_HIZ;
avr_databus_in;
}
Listing 2—Continued
Word
F/V
Identify device information
0
General configuration of bit-significant information:
F
15 0 = ATA device 1 = ATAPI device
F
14 Obsolete
F
13 Obsolete
F
12 Obsolete
F
11 Obsolete
F
10 Obsolete
F
9
Obsolete
F
8
Obsolete
F
7
1 = Removable media device
F
6
1 = Not removable controller and/or device
F
5
Obsolete
F
4
Obsolete
F
3
Obsolete
F
2
Obsolete
F
1
Obsolete
F
0
Reserved
Table 1—If you like to write code that parses data, then writing ATA hard drive code will keep you happy (and busy) for days. The data in Photo 3 was culled from this table of
words spoken by the little Hitachi DK211A-54. F represents a fixed value, V represents a variable value, X represents a vendor-specific value, and R represents a reserved value.
Word
F/V
Identify device information
1
F
Number of logical cylinders
2
R
Reserved
3
F
Number of logical heads
4
X
Obsolete
5
X
Obsolete
6
F
Number of logical sectors per logical track
7–9
X
Vendor specific
10–19
F
Serial number (20 ASCII characters)
20
X
Obsolete
21
X
Obsolete
22
F
Number of vendor-specific bytes available on read/write long commands
23–26
F
Firmware revision (eight ASCII characters)
27–46
F
Model number (40 ASCII characters)
47
X
15–8 Vendor specific
R
7–0
00h = Reserved
F
01h–FFh = Maximum number of sectors that can be transferred
per interrupt on read/write multiple commands
48
R
Reserved
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
63
same CHS-based registers to per-
form logical block address (LBA)
mode addressing operations. LBA
mode is a means set forth by the
ATA standards to allow for the lin-
ear addressing of sectors. LBA
addressing is derived from the CHS
addressing format as follows:
LBA = ((cylinder × heads_per_cylinder +
heads) × sectors_per_track) + sector – 1
For instance, cylinder 0, head 0, sec-
tor 1 is LBA address 0. Therefore, for
LBA mode to function, the hard drive
must support LBA mode internally,
and that’s the case for the 540-MB
laptop drives as well as the larger
850-MB 3.5
″
drives.
The ultimate goal is to use LBA
mode to read and write to sectors on
the hard drive. To do this, you must
first be able to read and write to the
hard drive’s register set. A good place
to start with the firmware descrip-
tion of this process is with the hard
drive initialization routine, whose
source code is included in Listing 2.
The first register access occurs
when the
while(!ready & busy)
statement executes. Note that
ready
and
busy are macros that call the
ata_rdy(void) and ata_busy(void)
functions. The
ata_rdy(void) and
ata_busy(void) functions are iden-
tical with the exception of the status
bit they check. In both cases the AVR
data bus pins are put in Input mode,
the status register is addressed, the
I/O read pin is toggled, and the status
register data is read (8 bits).
Additionally, the hard drive I/O port
is put into a high-impedance state, the
status condition is determined, and a
return code is generated. Note that
the external buffer SRAM is not used
by these functions.
After the hard drive has done its
own power-on reset, the ready bit will
show that the hard drive is ready for a
command, and the busy bit will indi-
cate a “not busy” status. At this
point, a hard reset is toggled using the
RESET pin on the hard drive I/O bus,
and time is marked to allow the phys-
ical and electrical hard drive reset
process to finish. Because I was
attaching a single hard drive that’s
strapped as master drive 0, I selected
drive 0 in LBA mode using the
Photo 2—The 540-MB
drive formats quickly and
is easy to handle even
with the converter boards
attached. This made for
quick turnarounds in the
initial development
stages when I was exper-
imenting, debugging, and
doing a lot of hard drive
formatting.
64
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
select_drive_0 macro. The
next step was to issue a recali-
brate command and check the
error status register. In
instances like this, a “drive
ready” banner is sent to the
serial port if all is well.
At that point, I wasn’t ready
to start reading hard drive sec-
tors, because I needed to make
sure I could address and com-
mand the hard drive interface
accurately. The easiest way to
verify this was to execute an ATA
Identify Device command.
Basically, the Identify Device com-
mand instructs the hard drive to
divulge its factory-loaded identifiers,
and 255 words are returned. All I had
to do was pick up the words from the
hard drive I/O port, parse them, and
send the results to the serial port. All
255 words weren’t needed. As you can
see in Table 1, the first 46 words tell
you if things are working correctly.
Photo 3 is a HyperTerminal shot
showing you what the little Hitachi
drive had to say about itself.
Now that you know how to get data
from the hard drive, I’ll show you how
to read a sector. Before the code is test-
ed, however, there’s work to be done
on the hard drive, and you’ll need a
way to verify your results.
Because I plan to develop AVR
firmware to manipulate FAT32 format-
ted drives, it would be logical to format
the hard drives that will be used with
MSDOS by way of Windows 98.
Formatting in this way puts master
boot records, partition tables, and data
in predictable places on the drive.
Two drives should be formatted: one
is used on the ATA hard drive
controller, and the other is used
on a PC for verification and as
an aid in debugging.
The verification program for
the PC is called WinHex.
Normally, WinHex is used to
inspect and repair files on PC
hard drives. This program does it
all as far as hard drives are con-
cerned; it understands FAT12,
FAT16, FAT32, NTFS, and CDFS.
In addition, WinHex includes a
disk editor that allows you to become
a dangerous hard drive technician. You
can also use WinHex to create tem-
plates that automatically parse known
data areas of the hard drive.
Photo 4 is a screen shot of an actual
WinHex panel that’s aimed at the 2.5
″
Hitachi drive attached to the PC. I’ve
dialed in the MBR master boot record
(MBR), which resides at cylinder 0, head
0, and sector 1 or LBA 0. If all goes well
with the sector read on the hard drive
controller, the data in the Hyper-
Terminal window should be identical to
the bytes found in the WinHex window.
Photo 3—Things are good when the numbers in this photo match the
numbers written on the hard drive.
Visit us on the web www.jkmicro.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
65
The HyperTerminal readout in
Photo 5 matches the numbers picked
up by WinHex from the clone drive in
Photo 4. As Spock would say, “Random
chance seems to have operated in our
favor.” The
ata_read_sector()
function shown in Listing 3 works as
designed. Reading a sector in LBA mode
entails loading the Device/Head register
with the LBA mode bit set, loading the
cylinder High/Low and Sector registers,
and issuing the Read Sectors command.
Here’s where that big chunk of
external 16-bit SRAM is handy.
Instead of pulling the data directly
into the AVR, I used the AVR to gen-
erate address information for the
SRAM and manipulate the SRAM’s
write enable and chip select lines to
store the incoming data in the exter-
nal 64 KB of SRAM.
I divided the SRAM into logical
pages of 256 words each and wrote
routines to read and write these
pages. Each page of external SRAM
holds one sector of hard drive data,
allowing up to 256 sectors to be
buffered. That pretty much takes
care of verifying the ATA hard drive
controller’s read functionality.
Writing to the hard drive is a simi-
lar process. The external SRAM is
filled with a sector’s worth of data
(256 words), and then that particular
SRAM page is written to the hard
drive I/O port’s data bus. Instead of
performing an ATA I/O read, an ATA
I/O write is performed when the data is
presented on the external SRAM data
pins. I tested the write sector code
successfully on random sectors of the
hard drive attached to the ATA hard
drive controller. Additionally, I veri-
fied the writes by moving the hard
drive to the PC and reading the sectors
I wrote using WinHex.
GETTING FAT
All of the reading and writing up to
this point was completed with simple
C routines that were teamed together
to perform a much larger and more
complex task. Believe it or not,
designing the ATA hard drive con-
troller hardware and finishing the C
coding for the controller I/O func-
tions was the easy part. The Ethernet
code was just as easy, because I
copied AVR code that was
already written for the Packet
Whacker microcontroller
NIC. The next step in the
process of assembling a micro-
controller-based networkable
mass storage system was a
bit more demanding.
CadSoft Computer, Inc., 801 S. Federal Highway, Delray Beach, FL 33483
Hotline (561) 274-8355, Fax (561) 274-8218, E-Mail : info@cadsoftusa.com
Schematic Capture • Board Layout
Pay the difference for Upgrades
You can use EAGLE Light for testing and
SMD pads can be rounded or round
Different pad shapes for Top, Bottom,
or Inner layers
Satisfied customers - the key to our success
Photo 4—
There isn’t much about a hard
drive you will want to know that WinHex
won’t tell you.
66
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
I completed a tremendous
amount of research in prepara-
tion for writing AVR code to
implement Microsoft’s FAT32
file system. Thanks to a series
of Circuit Cellar articles writ-
ten by our own Jeff Bachiochi
(Circuit Cellar 143–146), I had
a good idea about the roads I will
travel and battles I will fight.
The journey starts with the
bytes in Photo 4, the master boot
record. Because I’m not execut-
ing instructions on a legacy x86
machine and using a PC BIOS or
MSDOS, I’ll have to interpret the
data and adapt it to the AVR. For
instance, there’s executable code in the
MBR that I don’t care about. The prob-
lem is that I have to navigate through
it to find markers that either give me
information about where FAT-related
constants and parameters reside or
point me to places where I can read
and write my data.
In the case of the MBR, I’m inter-
ested only in the last 66 bytes,
because that’s where the partition
table resides. The fun starts at offset
0x1BE in the MBR, which is the first
partition entry. Because the drives I
formatted were secondary drives,
the FDISK program couldn’t make
their partitions active. So, the first
byte at offset 0x1BE was 0x00 (inac-
tive) on my drives.
Other interesting information
resides at offset 0x1C6 in the MBR.
This is the number of sectors
between the MBR and the first
sector of the first partition. As
you can see in Photo 4, WinHex
shows that number as 0x3F. I
used the WinHex program to
dial in 0x3F sectors beyond the
MBR and, lo and behold, there
was the FAT32 boot sector with
additional fields of information
to parse. The plan is to collect
documentation and use WinHex
to obtain the actual visuals con-
cerning how data and control
areas on a FAT32 hard disk are
defined and laid out.
So, you see that I have my
work cut out for me. The good
news is that you’ll be able to share
the fruits of my labor, because I will
make the ATA hard drive controller
hardware available to those of you
who want one. The code discussed in
this article is available for you to
download from the Circuit Cellar ftp
site. All of the basic functions neces-
sary to read and write to an ATA
hard drive can be found in the code
I’m providing.
Photo 5—The format of the data may not be pretty, but the data itself is
beautiful because it matches the clone drive’s MBR data read by WinHex.
of you, you’ll see that everything
you’ve read about in this article isn’t
complicated, it’s simply embedded.
I
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
67
After you have all of the ImageCraft
C source code, a copy of WinHex, and
an ATA hard drive controller in front
Listing 3—There aren’t any tricks in this code. It’s all simple read and write I/O between the hard disk and
the SRAM. The routine reads an LBA-addressed sector into an SRAM page.
*****************************************************************
Read a sector. device = 0x00 or 0x01
*****************************************************************
unsigned char ata_read_sector(unsigned char device, unsigned
long lbasector \ ,unsigned int page)
{
unsigned int i,ram_address;
lbasector &= 0x0FFFFFFF;
ata_set_io_addr(ATA_IO_DEVICE_HEAD);
switch (device)
{
case 0x00:
ata_write_byte(lbasector >> 24 | 0xE0);
break;
case 0x01:
ata_write_byte(lbasector >> 24 | 0xF0);
break;
default:
ata_write_byte(lbasector >> 24 | 0xE0);
break;
}
while(busy);
ata_set_io_addr(ATA_IO_CYL_H);
ata_write_byte(lbasector >> 16);
while(busy);
ata_set_io_addr(ATA_IO_CYL_L);
ata_write_byte(lbasector >> 8);
while(busy);
ata_set_io_addr(ATA_IO_SECTORNUM);
ata_write_byte(lbasector);
while(busy);
ata_set_io_addr(ATA_IO_SECTORCNT);
ata_write_byte(0x01);
while(busy);
ata_send_cmd(CMD_READ_SECTORS);
while(busy);
while(!drq);
ram_address = page * 0x100;
for(i=0;i<256;++i)
{
avr_databus_out;
PORT_ATA_DATA_H_OUT = ram_address >> 8;
PORT_ATA_DATA_L_OUT = ram_address;
latch_ram_addr;
avr_databus_in;
ram_on;
while(busy);
PORT_ATA_IO_CNTL = ATA_IO_DATA;
PORT_ATA_IO_CNTL &= ~ATA_DIOR;
delay_us(1);
ram_write_pulse;
delay_us(1);
PORT_ATA_IO_CNTL |= ATA_DIOR;
PORT_ATA_IO_CNTL = ATA_IO_HIZ;
while(busy);
ram_off;
++ram_address;
}
return (error);
}
Fred Eady has more than 20 years of
experience as a systems engineer. He
has worked with computers and com-
munication systems large and small,
simple and complex. His forte is
embedded-systems design and com-
munications. Fred may be reached at
fred@edtp.com.
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2003/150/.
SOURCES
ATmega128 Microcontroller
Atmel Corp.
(408) 441-0311
www.atmel.com
DK211A-54 2.5” Disk drives
Hitachi, Ltd.
(800) 448-2244
www.hitachi.com
ICCAVR C compiler
ImageCraft Creations, Inc.
(650) 493-9326
www.imagecraft.com
AVR ISP Dongle and ISP software
Kanda Systems
+44 (0) 870 744 6807
www.kanda.com
MAX233
Maxim Integrated Products, Inc.
(408) 737-7600
www.maxim-ic.com
74HCT573 Octal D-type trans-
parent latch
Philips Semiconductor
www.semiconductors.philips.com
RTL8019AS Ethernet controller
Realtek Semiconductor Corp.
+886 (0) 3 578 0211
www.realtek.com.tw
SP233ECT RS-232 Line drivers/
receivers
Sipex Corp.
(978) 667-8700
www.sipex.com
68
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
n my last two
articles, I described
the ARM architec-
ture, instruction set, and
Thumb mode, but I barely mentioned
anything about its implementation.
Although I find much of the imple-
mentation independence to be a nice
feature of the ARM architecture, it
won’t help you drop a specific chip
into a design. Therefore, in this final
article, I’ll cover the practical topics of
cores, tools, and tool chains.
ARM CORES
The cores are the physical imple-
mentation of the ARM architecture.
Although there were ARM cores prior
to the ARM7TDMI, I’ll discuss only
those that you’re likely to use in your
embedded designs. If you’re using an
old Apple Newton, please use the refer-
ences at the end of this article to find
more information about the ARM6.
The ARM7 core is an implementa-
tion of the V.4T architecture that con-
tains a three-stage pipeline with a sin-
gle memory port without an inherent
internal memory hierarchy. This core
is the basis for the ARM7TDMI.
The processor core supports Thumb
instructions (the “T” in the name) and
32 × 32 bit multiplication with a 64-bit
result (the “M” in the name). In addi-
tion, the core has the JTAG debug mod-
ule and Embedded ICE JTAG in-circuit
emulator module, which provides a
mechanism for hardware breakpoints
and watch points. Additional coproces-
sors, such as a memory management
unit (MMU) or memory protection
unit (MPU), can be included with the
ARM7TDMI core. You shouldn’t
assume that these coprocessors are
present if they aren’t specified, because
the core exists without them.
The core is used mainly in low-cost,
deeply embedded designs. ARM7TDMI
cores tend to be in CPUs that have
microcontroller-like peripheral sets,
and they’re used in CPUs meant for
low-power designs where battery life
is more important than performance.
This core is not limited to deeply
embedded designs. ARM7TDMI is
supported in Palm OS 5, the first non-
68K version of Palm OS.
The ARM720T is a CPU core instead
of a processor core like the ARM7TDMI.
It has an ARM7TDMI processor core.
This core adds a memory hierarchy,
including write buffers, an MMU, and
an 8-KB, four-way, set-associative uni-
fied cache. The write buffer has a capac-
ity of eight data words in four unique
addresses. The exception vectors can be
remapped to start at 0xFFFF0000.
Note that this is a Windows CE oper-
ating system requirement.
The ARM720T is used in systems
with resource-intensive operating sys-
tems (e.g., WindowsCE and Linux).
These systems tend to be heavier than
those that use a straight ARM7TDMI.
You’ll find that designs that require
good memory-system performance but
not the fastest processor on the block
will do well with the ARM720T.
The ARM740T has the memory per-
formance features of the ARM720T, but
it doesn’t have the MMU. Instead, the
’740T has an MPU that allows you to
restrict access to memory and memory-
mapped I/O regions without the over-
head of the MMU. Memory system
safety and performance with greater
predictability than an MMU system is a
combination that meets the needs of
many real-time and embedded systems.
In comparison to the ARM7 family,
the ARM9 processor core contains var-
ARMs to ARMs
i
Now that you’ve been
fully assimilated into
the world of ARM, it’s
time to get to work. In
this final installment of
Robert’s series, he
demonstrates how to
implement the ARM
architecture in CPU
and system cores, tool
chains, and tools.
Now, you don’t have to
rely on the x86 or 68K.
Robert Martin
FEATURE
ARTICLE
Part 3: Working in the World of ARM
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
69
intended for high-end designs, is
apparently targeted at the same mar-
ket as the StrongARM. The latter has
a 16-bit data bus and is intended for
designs that don’t require the perform-
ance of the PXA250.
The PXA210 has a maximum clock
frequency of 200 MHz. According to
Intel marketing material, the PXA250
product line’s clock frequency will
increase to 600 MHz. Extensive infor-
mation is available on the Intel devel-
oper web site. Since its release, the
400-MHz version of the PXA250 has
replaced the StrongARM as the
processor of choice among the high-
end PocketPC PDAs.
The PXA250 and PXA210 have a
high level of system-level peripheral
integration. Integrated LCD, PCM-
CIA/Compact Flash, and USB client
controllers have removed the need for
the companion chip that was required
for the StrongARM. Both processor
families have the usual array of serial
controllers as well. This level of inte-
gration has become a must in the
hand-held and wireless worlds.
Another requirement in those
worlds is multilevel power manage-
ment. The XScale processors take an
ious performance improvements while
staying within the V.4T architecture.
The core has a five-stage pipeline and
separate instruction and data ports. The
pipeline improvements and changes that
were incorporated to increase memory
bandwidth allow the ARM9TDMI core
to run at a higher clock frequency than
the ARM7TDMI core.
The ARM920T and ARM940T cores
are analogous to the ARM720T and
ARM740T cores, respectively. With
read and write ports to the ARM9TDMI
core, the ARM920T and ARM940T
contain separate data and instruction
caches rather than the unified cache
in the ARM7 cores. The interface to
external memory is still unified.
INTEL CORES
All of the cores that I’ve described
so far are licensable from ARM, Ltd.
There are high-end cores available
from Intel where the architecture is
licensed from ARM but not the core
itself. Digital Semiconductor initially
did this, but Intel assumed the rela-
tionship with ARM after acquiring
Digital Semiconductor.
The StrongARM core (SA1), which
was originally designed by Digital
Semiconductor, incorporated perform-
ance improvements that were later
adopted by ARM, including a five-stage
pipeline. This core was developed prior
to the development of the Thumb
instruction set and the Debug and
Embedded ICE macrocells. Essentially,
this means that StrongARM processors
have performance numbers at or
exceeding ARM9 cores but don’t have
all of the features available in the
ARM7TDMI. Specifically, the JTAG
port on chips based on the SA1 core
can be used only for boundary scan
and ROM loading.
Until recently, the StrongARM was
the ARM System-on-a-Chip technolo-
gy of choice for embedded designs that
needed processing power, memory
system performance, and low-power
usage. The SA1110 has been used
widely in Windows CE devices, espe-
cially in high-end, PocketPC-based
PDAs such as the Compaq iPAQ and
now defunct HP Jordana.
The SA1110 comes in 206- and
133-MHz models. As part of its
power-management features, the clock
rate can be reduced from the maxi-
mum for the model.
Intel acquired the StrongARM core in
its acquisition of Digital Semiconductor.
The age of the design, the design deci-
sions that limited productions to for-
mer Digital Semiconductor fabs, and
the lack of a StrongARM upgrade path
aided Intel in deciding to move for-
ward with the new XScale microarchi-
tecture. XScale is based on the ARM
V.5TE architecture; therefore, it con-
tains the Thumb instruction set and
DSP functionality. This specific
implementation of the ARM architec-
ture is an Intel-only design.
XScale uses many of the latest
advancements in RISC processor design
to maximize performance and limit
pipeline stalls and other mechanisms
that increase the cycles per instruc-
tion from the theoretical minimum.
The design is interesting, but it would
require another article to do it justice. If
you’re interested in learning more
about the design, you should refer to
the documentation on Intel’s web site.
In February 2002, Intel released the
first two XScale processors, PXA250
and PXA210. The former, which is
Mode
Description
Entered
Exited
Run
Standard mode. Clock frequency
Software
Software or power fail
is selectable. All other modes are
entered from Run mode; other
modes must exit into Run mode.
Turbo
Clock speed is a multiple of the
Software
Software
Run clock speed. Intended
for times when extremely fast
processing of instructions is
required with few accesses of
external memory. External
memory accesses may cause
pipeline stalls because of the high
internal clock speed.
Idle
CPU clock is disabled. On-chip
Software
Interrupt, generally coming
peripherals still receiving nominal
from a peripheral.
clock frequency.
Sleep
Only the real-time clock and
Software or power fail Preselected group of inter-
power manager receive input
rupts. System must reboot
strobes. SDRAM is placed
when exiting Sleep mode;
in Self-Refresh mode. The
essentially all CPU state
internal processor state is lost.
information was lost.
Table 1—Although the clock frequency of the Run and Turbo modes is selectable, it’s best to change the frequency
only when booting the system. Changing the frequency during normal running requires several additional steps
because of the latency of frequency change and the effect it has on system stability.
70
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
GNU TOOLS
The GNU tool chain is available for
ARM; it includes the GCC compiler,
the GNU binutils package, and a
library package. The newlib open-
source library package, currently spon-
sored by Red Hat, is meant for embed-
ded applications, so it fits well. The
newlib license is different from the
GNU general public license (GPL); it’s
considered to be friendlier toward
commercial projects than the GPL.
Although the commercial tool chains
generally provide a warm and comfort-
able development environment, the
GNU tool chain requires more of an
investment of your time in order to be
fully set up for development. I’ve found
the GNU tools to be worth the effort,
but they’re truly not for everyone.
In December 2001, Bill Gatliff wrote
an excellent article that provides a ter-
rific starting point for setting up the
GNU tool chain with the newlib C
library (“Why Not GNU?” Circuit
Cellar
137). If you’re only using ARM
code and don’t want Thumb or
Thumb Interworking, then you don’t
need to look farther than Bill’s article.
But, if you do want Thumb or
Interworking capabilities, there are
additional steps that you must take.
The 2.95.x versions of GCC don’t
include Thumb support. To use Thumb
or Interworking, you must implement
either one of the 3.x versions or a
recent development snapshot. Using a
recent version still will not give you
interworking capability without some
additional effort on your part.
First, you must take out the com-
ments in the multilib sections for inter-
working in the $GCC_SOURCE/gcc/
config/arm/t-arm-elf file in the GCC
source distribution. Then, go through
the tool chain compilation steps
described in Bill’s article. If you have an
earlier version of newlib compiled for
ARM, you’ll need to recompile it with
interesting approach to power manage-
ment with a four-level system (see
Table 1). The addition of Turbo mode
is quite telling; embedded processors
have come now that they’re capable of
running faster than 100-MHz SDRAM.
For those of you writing code, the
PXA210 and PXA250 have two advan-
tages over the StrongARM. First, the
support for Thumb mode is a nice
addition to systems that use low-cost
16-bit memory. This is especially
important for the PXA210 because its
external memory bus is only 16-bits
wide. The second advantage is expan-
sion. Both the PXA210 and PXA250
have JTAG ports that you can use for
software debugging.
TOOLS AND TOOL CHAINS
With a large number of chip offer-
ings, ranging from low-end processors
for deeply embedded work to high-end
processors for demanding PDA appli-
cations, it’s not surprising that there’s
a great selection of tools for ARM. You
can find many different tool chains,
JTAG emulators, ROM monitors, and
evaluation boards to help you go from
a concept to a deployable product.
There are numerous commercial
tool chains available for ARM proces-
sors. ARM has its own set of tools, as
well as its own JTAG emulator. Green
Hills, Metaware, IAR, and others also
have tools for ARM.
The tool chains normally include
some sort of professional IDE, an
assembler, C compiler, source code
debugger, and possibly a simulator.
Of course, these all come with a pro-
fessional price tag to match. Most of
the development tools have time-
limited evaluation versions that are
available free of charge. The evalua-
tion versions generally give you a
month or two to decide whether or
not you’re going to invest the money
in the tool chain.
the GCC version that supports inter-
working. Otherwise, you will not get
the multilib support in newlib.
To determine if you have the proper
interworking support in a tool chain,
type
gcc –-print-multi-lib. If all
went well in the earlier steps, you’ll
see lines containing
thumb-inter-
work. The additional GCC command
line arguments for multilib support
are shown in Table 2.
JTAG EMULATORS
One of the advantages of using one
of the cores with the Debug and
Embedded ICE units is the JTAG debug
port. You can hook a JTAG in-circuit
emulator to the processor to assist in
all of the stages of development.
There are JTAG emulators available
for ARM in all price ranges. The
Wiggler and Raven are within the hob-
byist’s price range. More expensive
emulators from ARM, Agilent, Green
Hills, Abatron, and others are accessible
using Ethernet interfaces. When buying
an emulator, verify that it will work
with the debugger in your tool chain.
ROM MONITORS
The ARM standard ROM monitor
that’s available on most development
boards is the ARM Angel debugger.
Angel provides a standard interface for
debuggers. The debuggers in both com-
mercial and GNU tool chains support
this connection mechanism.
You can use Angel in a stand-alone
mode or, in later stages of develop-
ment, in a more limited role, applying
the Angel library to provide start-up
code, entry points, and raw device
drivers. ARM provides a porting guide
that will help you get Angel running
on your custom hardware. [1]
Red Hat’s RedBoot debug monitor is
available for some ARM platforms.
RedBoot is based on the eCos operating
system; therefore, if eCos is available
for your platform, RedBoot probably is
too. RedBoot provides both a debugger
interface for gdb and a command line
interface for downloading and flashing
applications on your board. RedBoot
operates over a serial line or Ethernet.
Angel and RedBoot work well for
general application debugging. One
thing you need to remember if you’re
Module mode
GCC options
ARM only, no interworking
No additional options necessary, can use
-marm
Thumb only, no interworking required
-mthumb
ARM with interworking
-mthumb-interwork
–marm
Thumb with interworking
-mthumb
–mthumb-interwork
Table 2—A GCC version later than V.2.95 is required to have support for Thumb mode and ARM-Thumb
Interworking. Note that for ARM modes,
-marm can be specified on the command line but isn’t necessary.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
71
using either Angel or RedBoot is that
both require their own exception han-
dlers. You will need to chain the
ROM monitor’s exception handlers
after your own exception handlers. So,
how can you step through your inter-
rupt handlers? Unfortunately, you’ll
need to use either a JTAG ICE or
ROMulator, or you’ll have to set LEDs.
DEVELOPMENT BOARDS
There’s quite a selection of develop-
ment boards available from ARM and
the silicon manufacturers themselves.
For ARM7TDMI development aimed
at deeply embedded targets with lim-
ited resources, the Atmel AT91EBxx
series and ARM Evaluator-7T fit the
bill. Both boards are inexpensive and
contain systems appropriate for start-
ing deeply embedded designs.
The price tag will increase substan-
tially if you start working on an eval-
uation board base on an ARM720T or
ARM9 family processor. These are
higher performance chips meant for
systems with greater resources, so
these evaluation boards come with
much more memory and Compact
Flash than the straight ARM7TDMI
boards. Most non-Intel development
boards come without a screen.
Currently, the situation for finding
development boards for the Intel ARM
offerings is in a state of flux. The Intel
StrongARM development boards are no
longer available from the company.
Third-party evaluation boards are avail-
able from Applied Data Systems. There
is at least one XScale development
board currently available from Intel.
In addition, Applied Data Systems
has added an XScale development
board to its product line. The boards for
the Intel offerings tend to be aimed at
PDAs, wireless consumer devices,
Internet appliances, or set-top boxes.
They usually have PDA or Internet
appliance-sized LCD screens and are
loaded with memory and Compact
Flash. Even the form factor of the Intel
Assabet StrongARM board is PDA-sized.
WHAT NOW?
Start-up code and a mixture of C and
assembly code for the Atmel AT91EB40
eval board are on the Circuit Cellar ftp
site. This code will demonstrate much
Robert Martin received a Ph.D. in
Physics from The College of William
and Mary. Currently, Robert is an
engineering manager directing a team
of embedded software engineers near
Phoenix, Arizona. You may reach him
at rmartin@sonoranfoothillseng.com.
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2003/150/.
REFERENCE
[1] ARM, Ltd., “Application Note
54: Angel Porting Guide,”
ARM DAI 0054A, 1998.
RESOURCES
ARM, Ltd., “ARM Architecture
Reference Manual,” DDI 0100E,
1996.
eCos, sources.redhat.com/ecos/.
S. Furber, ARM System-On-Chip
Architecture,
2nd ed., Addison-
Wesley, Harlow, England, 2000.
Intel developer information,
developer.intel.com.
SOURCES
Angel Debug monitor, ARM
ARM, Ltd.
www.arm.com
AT91EB40 Evaluation board
Atmel Corp.
www.atmel.com
PXA210/250, StrongARM, Xscale
Intel Corp.
www.intel.com
RedBoot Debug monitor
Red Hat, Inc.
www.redhat.com
of what has been discussed here. If
you’re new to ARM, this should pro-
vide a starting point for future work.
Next time a project comes your
way that requires something more
than a simple microcontroller, think
about ARM instead of just reaching
for an embedded x86 or 68K. There
are a number of OS choices available
for ARM processors, ranging from
RTOSs to WindowsCE or Linux.
I
New Generation
Single Board Computer
Bainbridge Island, WA 98110 USA
Controller signals extend to high-density Molex (0.625 mm)
connectors on two sides of the board
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
2 (to 8) MB external SRAM & 4 (to 8) MB Flash, 4 (to 16) KB
EEPROM
RS-232 transceiver supports 3x asynchronous serial interfaces
82C900 TwinCAN controller, 2x 82C251/TLE6250 CAN transceivers
CS8900A 10BaseT Ethernet controller, JTAG-interface
AC adapter, cables and SPECTRUM CD with eval software tools
), electronic documentation and demos
Single Board Computer module pricing: $299 single unit, $209.30/
unit @ 100 units; Rapid Development Kit pricing $499
72
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
very time I reach
under the sink for a
bottle of cleaner, I’m
forced to choose between
a dozen different products. You need to
be a chemist nowadays to decide on the
appropriate purifier, disinfectant, sani-
tizer, or germicide for a toxic cleanup.
And these choices are independent of
whether you want the citrus fresh,
mountain meadow, or bouquet scent,
not to mention the streak-free, low-
residue, or aloe-based (gentle on your
hands) options. Enough already. Just
give me the soap. I don’t need colored
swirls, specially shaped bottles, or
pleasant scents. I just
want it to clean.
Half of the stuff I try
doesn’t seem to cut
through the goo. But,
isn’t this true of most of
the things we do today?
Getting the job done can
be frustrating. When you
grab a wrench, you never
know whether you’re
looking for a metric or
English size. Half of the
parts on today’s automo-
biles require special tools
for removing them. Have
you ever purchased a
piece of electronic equipment only to
find out after the fact that it requires a
special battery? Did your furniture
come with an inadequate assembly
manual that was written in a foreign
language? Nothing is easy anymore.
When I design a product, I like to
keep things simple. Amulet has sim-
plified the task of interfacing a micro-
controller to a GUI front-end. The
Easy GUI Browser Chip, along with a
few peripheral chips, can store and dis-
play all of your application’s HTML-
authored graphic screens. In addition,
it handles analog touch-screen input
for a complete GUI front-end, thus
reducing the load on your microcon-
troller. All of this is interfaced through
a simple serial interface.
GUI ENGINE
The AGB64LV01-QC GUI engine is
an 84-pin PQFP package that will sim-
plify your life. It achieves this by off-
loading all of the raw LCD control
from your application processor and
acting like a stand-alone HTML web
page server.
As an LCD controller, the chip sup-
ports raw dot matrix LCDs up to
480 × 640 (VGA). A hardware UART
provides simple application communi-
cation and enables the flash memory
updates of your display pages. A paral-
lel address and data bus interface to
SRAM for system and active display
data storage. Furthermore, an SPI
interface is used for nonvolatile, com-
pressed (uHTML) display screen and
graphics storage. Analog touch-screen
input is supported through the SPI
GUI Interfacing
A Straightforward, Simple Solution
e
Without
the proper
tools,
even a
straightfor-
ward project like inter-
facing a micro to a
GUI can be complicat-
ed. So, it’s always
refreshing when a
company develops
technology that can
simplify such a project.
Jeff Bachiochi
FROM THE
BENCH
Photo 1—The LCD configurator is one cool tool. Based on an LCD model
or its characteristics, the tool creates the proper configuration settings for
the GUI controller chip.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
73
HTML. Besides the standard anchor,
area, image, and meta refresh com-
mands, Amulet supplies other UI
objects created specifically for its GUI
controller solution. There are 12 special
objects: widgets, bar graph, checkbox,
custom button, function button, image
bar, image sequence, line plot, list,
numeric field, radio button, slider, and
string field. You probably recognize
many of these objects. The advantage of
using these Amulet UI objects is that
they can interact with each another.
The display property of widgets like
disappearing reverse video can be con-
trolled via other widgets. A number of
predefined local variables can be set
and read, including byte (0–255), word
(0–255), and string (0–255). Variables
associated with multiple widgets
allow for dynamic control. Although
an application such as an informa-
tion kiosk could be designed using
just the GUI controller, associated
circuitry, LCD, and touch screen,
interaction with other devices is pos-
sible via the same serial port that
allows ’64VL01 programming.
port using a touch-screen IC like Burr
Brown’s ADS7846. Refer to Figure 1
for the typical circuit arrangement.
In addition to general-purpose com-
puting, the CPU was designed to ren-
der graphics and handle I/O. The LCD
controller consists of a line buffer and
raster controller. The line buffer shares
the SRAM with the CPU. A memory
interface unit is implemented to
resolve arbitration between the two.
The raster controller is responsible for
producing horizontal and vertical syncs
as well as the data clock and pixel data
(from the line buffer) for the LCD.
The CPU, by way of a separate inter-
nal I/O bus, handles the raster con-
troller along with the three system
timers, UART, and SPI master. The SPI
flash memory stores the uHTML pages.
The size of the memory is the limiting
factor for display page capacity (and
how storage space can be increased).
SUPPORT TOOLS
Amulet supplies a number of soft-
ware tools that make it easy to work
with the GUI Browser Chip. The
HTML compiler is used to program
the ’64VL01 (actually the flash memo-
ry) with the HTML display pages and
LCD specifications. The LCD control
lines on the ’64LV01 are configured
via the LCD characteristics section of
the HTML compiler.
Although a few LCDs are predefined,
you can rely on an LCD’s datasheet to
supply the needed information. After
the selections are made, initialization
parameters are prepared for storage in
the flash memory. The ’64VL01 can
configure its LCD I/O control lines
based on these parameters. Additionally,
it handles LCDs up to the full VGA
(see Photo 1). I’ll say more about com-
piling HTML later. With the LCD
defined, a default-sized page becomes
your pallet, and anything placed within
the default page boundaries is legal (i.e.,
will be displayed on the LCD).
HTML pages are made up of a list
of HTML commands. These describe
display text and images and how
they will be handled. Although
today’s HTML editors allow you to
view and edit HTML directly, the
WYSIWYG drag-and-drop interface is
far easier to use. You can spend time
placing text and images instead of
dealing with the HTML language.
Placing text isn’t any more difficult
than using a text editor. You get to
choose the font style and size, and
place it anywhere on the HTML page.
To get a bit-mapped LCD the best-fit
fonts, Amulet provides a font converter.
This program converts the bit-mapped
font into one sized for the LCD’s
screen. If you choose to use an unusual
font in your HTML page, you will be
required to convert that font file into
an Amulet-compatible font file. This
conversion is as simple as choosing the
font file to convert and naming the
converted file. For instance, taking a
TrueType 56-KB font file and convert-
ing it into an Amulet font file reduces
the size down to 3 KB.
Graphics images placed within the
default page boundaries can be resized
so that their size is in correct propor-
tion to the other information on the
screen. Naturally, you can reduce an
image’s size to the point where it’s
unrecognizable. So, pick (or design)
your images accordingly.
To help with user interfacing (UI),
there are some controls supported in
Photo 2—The Phantacy Phactory’s home page was
designed with FrontPage. It’s displayed on the STK-
GT570 using the AGB64LV01 Easy GUI Controller Chip.
Photo 3—The AL4 is one of many products Mars
Electronics International makes for the amusement and
vending machine industry. This unit will validate $1, $5,
$10, and $20 bills.
Photo 4—A previous project’s PCB was almost a per-
fect match for this month’s circuit. The iButton recepta-
cle plugs into an RJ11. Having plenty of status LEDs
allows you to keep an eye on the code execution.
Photo 5—As bills are accepted, the AL4 outputs puls-
es, which are accumulated in the microcontroller. The
number of pulses represents credits, and this value is
sent to the GUI interface. You get credit feedback on the
LCD for the paper money inserted into the bill acceptor.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
75
I had to design 10 HTML
pages for this project. It took less
than two hours to complete,
because many of the pages
required only text changes.
When I finished, I was ready to
load them into the ’64VL01.
After entering the name of the
home page into the HTML com-
piler tool, it proceeds to strip out
all of the unnecessary code and
look for links to other pages.
All of the hyperlinked pages are
also compiled into one small
file. This file is downloaded
into the ’64VL01.
The serial port defaults to
115 kbps to program the
HTML pages quickly. After
they’re programmed, the ’64VL01 dis-
plays the home page and the serial
port is open for business. HTML com-
mands as well as widgets can request
byte, word, string variable values, or
set byte and invoke a remote procedure
call (RPC) via the serial port. A simple
command/value protocol is imple-
mented with the ’64VL01 as a master
controlling all external device commu-
nication. The only important rule is
that the slave device must answer all
commands within 200 ms (even if its
only a single-byte acknowledge).
To make the GUI controller com-
plete, it must control an LCD and
accept input from a touch screen on
top of the LCD. The ’64VL01 sup-
ports an SPI touch controller like the
ADS7846. This touch controller uses
a four-wire x-y interface. Check the
Amulet web site for a resource page
that includes manufacturers for both
LCD panels and touch screen inter-
faces. For those of you who don’t
have the desire or facility to design a
PCB using the GUI controller chip,
Amulet offers a complete GUI con-
troller PCB with an integrated LCD
and touch screen in both the 3.8
″
and
5.7
″
backlit one-fourth VGA sizes.
If you use one of Amulet’s LCD
modules with an integrated GUI con-
troller PCB, you can design all of your
pages prior to building additional
hardware. Any application program at
the other end of the GUI’s serial link
can be simulated using the included
Amulet simulator. This will allow
you to transfer byte, word, and string
variables as requested from your live
GUI controller/display. The simulator
displays all requests and responses.
Each request is ACKed until you
enter response data.
CURRENCY CONVERTER
This month’s project incorporates
Amulet’s GUI hardware solution along
with a bill (paper money) acceptor,
iButton reader, and microcontroller to
produce a currency converter for an
arcade center (see Photo 2). The
Phantacy Phactory arcade uses iButton
technology to store user credits.
You can use an iButton to purchase
game plays and refreshments, elimi-
nating the need for cash or tokens. To
automate the operations, this project
creates a system to accept $1, $5, $10,
and $20 bills and credit a user’s
iButton with the appropriate amount
of credit (see Figure 2).
BILL ACCEPTOR
The Mars Electronics AL4 series bill
acceptor is a secure module that out-
puts pulses based on a bill’s denomina-
tion (see Photo 3). A detailed descrip-
tion of currency acceptance is beyond
the scope of this article, but I will
revisit the topic in a future column if
my readers show enough interest.
Configuration switches on the AL4
can set the number of output pulses
per dollar. For this particular project, I
chose four pulses per dollar (i.e., one
credit = $0.25).
iBUTTON
Dallas Semiconductor has
been supporting iButtons and
one-wire technology for several
years. One-wire technology
that’s housed in a stainless
steel case has proven to be a
safe, durable, and inexpensive
approach to identification, data
storage, and security.
The DS1963S iButton has par-
tial storage protected by a
secure hash algorithm (SHA-1)
system. A secure secret writ-
ten to a write-only (WO) regis-
ter is used (along with many
internal registers) to calculate
a message authorization code
(MAC). The unreadable MAC
is checked internally against a user-
entered MAC. A match indicates a
trust that data is not tampered with.
Again, a detailed description of secu-
rity features is beyond the scope of
this article and can be revisited in a
future column.
For the purposes of this project, I
directly altered a 2-byte location
within the first page of an NV memo-
ry at addresses 0x18 and 0x19. The
user credits are stored at these
addresses for clarity and simplicity,
allowing the code to be followed easi-
ly. Note that without the use of the
special mechanisms afforded by the
secure iButton devices, you’re leaving
the system open to counterfeiters.
Dallas Semiconductor has a cool IC
that makes it easy to add one-wire
communication to a system that has
a serial port. The DS2480B can take
serial commands and handle all of the
one-wire communication in the back-
ground. This device works well in a
dongle connected externally to a
Amulet GUI controller
LCD with touch screen
Mars AL4
bill acceptor
Dallas
iButton receptacle
Microcontroller
Figure 2—The currency converter includes a microcon-
troller for reading and writing iButton data. A bill accep-
tor outputs monetary value pulses to the microcon-
troller as paper money is accepted. A GUI LCD touch
screen requests data from the microcontroller based on
the HTML web pages it hosts.
Crystal
Display
ICLK
XTAL
CP
PIXEL D0-D7
XSYNC
DISP
M
YSYNC
ADDR0-16
DATA0-7
*WE
*OE
*FSS
SCLK
MOSI
*RESET *IRQ *TSS MISO
*Reset
SRAM
Flash memory
Touch screen
DCLK
CS
D
IN
D
OUT
IRQ
CS
SCK
SI
SO
Figure 1—Amulet’s AGB64LV01 GUI controller requires few external compo-
nents to support an LCD and touch panel. It can serve stored HTML pages
to an LCD and retrieve user feedback without the use of any other processor.
76
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
serial port. Also, it has inverted logic
for connecting directly to the TTL
serial connections on a microproces-
sor (see Photo 4).
APPLICATION FLOW
Not many small microprocessors
have multiple serial ports. In this
case, two would work well. Bit bang-
ing a one-wire connection would be a
cost-effective alternative to bit bang-
ing a second UART; however, I want-
ed to become familiar with the ’2480.
So, I chose to create a software serial
port for the iButton interface, leaving
the hardware UART for the Amulet
GUI connection (see Figure 3).
The primary communication chan-
nel to the GUI interface operates at
115 kbps. The secondary communica-
tion channel to the iButton runs at
9600 bps. The third piece of the puz-
zle—the credit pulses from the bill
acceptor—is taken in via T1CKI, the
external counter input for Timer 1.
A rising edge on this input automat-
ically increments the TMR1L and
TMR1H registers, allowing for the
One of the requirements for GUI
communications requests is a response
of ACK or data within 200 ms. Some
requests can take longer, so Timer 2
is used to indicate when it’s time to
respond. Each procedure uses a flag to
indicate that a response is ready. A
Timer 2 match checks this flag. If it’s
not ready, it automatically responds
with an ACK. When a procedure is
ready, it shuts off Timer 2 (to prevent
an ACK) and responds with data.
At reset, the home page is dis-
played. You’re presented with two
function buttons, Check Balance and
Add Credit. When the Check Balance
button is touched, the
viewaccount
page is displayed, which prompts you
to touch the iButton tag to the recep-
tacle or touch the Cancel button to
return to the home page.
When the iButton tag has been suc-
cessfully read by the microcontroller,
a value is sent to the GUI that directs
it to display the balance page. The
GUI asks for the balance, and the
microcontroller responds with a word
value. This value is formatted and
displayed in a numeric field
widget. The screen will con-
tinue to be displayed until
you press the Done button,
at which time the GUI will
display the home page again.
When the Add Credit
button is pressed, the
addtowhichaccount page
is displayed, which prompts
you to touch the iButton tag
to the receptacle or touch
the Cancel button to return
to the home page. When the
iButton tag has been suc-
cessfully read by the micro-
controller, a value is sent to
the GUI, which directs the
GUI to display the
addbills
page. At this point, you can
decide to touch the Cancel
button or insert bills into
the bill acceptor.
The GUI interface asks
the microcontroller to signal
when the credit counter
(from pulses received from
an enabled bill acceptor on
T1CKI) is no longer zero.
After a bill is inserted and
counting of credits without any code
execution. For security purposes, the
counter is only enabled when bills are
being inserted.
Figure 4 shows the program flow
that’s used in the microcontroller.
Each dotted group of procedures and
decisions represents the application
code that will be executed for that
specific HTML page.
As the GUI displays most of the
new pages, it will request a word
variable from the microcontroller.
The variable number that’s requested
determines which procedure will be
executed within the microcontroller’s
application. If the microcontroller
has not performed the requested pro-
cedure, it replies with an ACK. The
GUI can make another request for
the information or respond to user
input (i.e., touching a function button
on the LCD). The GUI interface is
always in control, updating or dis-
playing a new HTML page based on
the response of either a word vari-
able’s value (from the microcon-
troller) or a widget.
Figure 3—This project’s schematic shows you how the microcontroller connects to the GUI interface through the hardware
UART. A Dallas Semiconductor DS2480B interfaces a software serial port (port A) to the Blue Dot Receptor (iButton receptacle),
eliminating the special timing requirements of the one-wire bus. In External mode, Timer 1 automatically accumulates pulses
from the bill acceptor connected to T1CKI.
accepted by the bill acceptor, credit
pulses are sent. Finding a nonzero
count, the microcontroller responds.
The GUI interface jumps to the
addmorebills page where a display
of accumulated credits is continu-
ously updated until you touch the
Finished button (see Photo 5).
At this point the GUI interface asks
you to touch the iButton tag to the
receptacle. The credits will be added
only to the original iButton. If any are
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
77
SOURCES
AGB64LV01-QC Easy GUI
Controller Chip, STK-GT570
starter kit
Amulet Technologies
www.amulettechnologies.com
AL4 Bill acceptor
Mars Electronics International, Inc.
www.marselectronics.com
DS1963S SHA iButton, DS2480B
interface chip
Maxim Integrated Products, Inc.
www.maxim-ic.com
PIC16F873 Microcontroller
Microchip Technology, Inc.
www.microchip.com
Microsoft Corp.
www.microsoft.com
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2003/150/.
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.
used except the original iButton, the
credits aren’t added and a request to
try again is issued. This assures you
that the cash that’s inserted is added
to the correct tag. A good tag match
updates the tag and returns to the bal-
ance page to show you the new credit
balance. In order for a tag to be recog-
nized, it must have correct CRC val-
ues on each block of data, and the data
must match a predetermined format.
Bad tags are rejected.
DESIGN IN
After you realize the benefits of
using the Easy GUI Browser Chip,
your applications will thank you for it.
Besides taking a great load off of the
microcontroller, you won’t have to
update the entire application just to
change the look and feel of the GUI.
You can easily draw a line between
the microcontroller’s support applica-
tion and the GUI’s artsy HTML appli-
cation. This allows for multiple appli-
cation development paths.
Transferring WYSIWYG screens into
bit-mapped images reduces the labor
involved with designing pleasing dis-
play screens. The included widgets add
pizzazz without frustration. Amulet
must agree with my mantra—Providing
good tools is necessary for a success-
ful product—because the company
includes all you need to make the most
of the GUI hardware solution.
I
Start
Initialize
Home
Add
credit
Y
Check
balance?
N
N
Y
Read Tag
Y
Tag
found?
N
Y
Cancel?
N
Good
Tag?
Y
N
Which
account
Display
balance
Y
N
Done?
Balance
Y
N
OK?
wrongtag
Wrong
Tag
Read Tag
Y
Tag
found?
N
Y
Cancel?
N
Good
Tag?
Y
addtowhichtag
N
N
Y
OK?
Bad Tag
badtag
Y
BadAdd
Tag
badtagadd
N
OK?
Y
Got a
bill?
Cancel?
Got a
bill?
addbills
Enable bill
acceptor
N
N
Y
Y
Done?
addmorebills
Display
credits
N
N
Y
Tag
found?
Y
addtoaccount
Read Tag
Y
Same
Tag?
N
Bad
Tag?
N
N
Y
Figure 4—The microcontroller executes the procedures for each HTML page that’s displayed. The HTML pages
use meta tags to request data from the microcontroller via the serial connection.
78
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
recently got a
chance to peek
under the hood of an
advanced concept car. No,
it wasn’t the souped-up, candy-apple
hot rod you might find at a car show.
And with a top speed of barely 80 mph,
this four-door econo-box, like most of
its ilk, can barely keep up with traffic.
There is one difference worth noting.
Stick your nose next to the tailpipe,
and you won’t smell a thing. But, do
bring a hanky, because what goes into
the tank of this otherwise mild-man-
nered Ford Focus is hydrogen, and what
comes out of the tailpipe is water (see
Photo 1). More than a century after the
phenomenon was first described, fuel
cells are poised to hit the road.
I had a chance to ask the Ford repre-
sentative a few questions. Why does it
have a radiator? Because lots of heat is
generated as a byproduct of the fuel
cell electrochemical reaction, not to
mention the drivetrain including the
100-kW (315 V at 330 A) inverter and
65-kW (87 hp) AC induction motor.
What about that 5000-psi hydrogen
tank in the trunk? Arguably safer than
a gas tank and indeed even 10,000 psi
(thereby increasing range) appears fea-
sible. [1] When do they go on sale?
Going Mobile
i
Tom Cantrell
After pop-
ping the
hood on
another
concept
car, Tom started think-
ing about LIN technol-
ogy. Clearly, car mak-
ers are hyping the
value of it, and soon,
other industries are
likely to hop on the
bandwagon.
SILICON
UPDATE
Surprisingly soon, at least for fleet or
corporate buyers that can arrange for
their own source of hydrogen.
For the rest of us, there is the small
matter of waiting for infrastructure
(i.e., hydrogen gas stations or maybe
even six-packs down at the grocery
store). There’s also the fact that
although there’s plenty of hydrogen
around and about, energy—from some-
where—must be expended to extract it.
No, the migration to fuel cell vehi-
cles—not to mention a greater hydro-
gen economy—won’t happen overnight,
but I think it’s only a matter of
when, not if.
LITTLE INEXPENSIVE NETWORK
Whatever kind of motor is under the
hood, the trend toward making cars
smarter in all ways continues at a
tremendous pace. I’ve covered the
topic of so-called in-vehicle networks
(IVNs) before (Circuit Cellar 118 and
119). You’ll recall that relatively
sophisticated networks (e.g., CAN,
J1850, and fancier ones on the hori-
zon) have been adopted to act as the
backbone that interconnects major
subsystems such as the engine, trans-
mission, emissions control, and diag-
nostic equipment (see Figure 1).
The fundamental premise of IVNs—
replacing bulky and balky analog wiring
harnesses with a few digital cables—
has taken off with a vengeance. The
automakers took the IVN bet, and now
they want to raise the ante.
Why stop with just the engine,
transmission, and so on? I know from
firsthand experience that my other-
wise thoroughly modern J1850-net-
worked ’99 still has plenty of wires
running hither and yon. There’s a bun-
dle at least an inch thick just to con-
nect the door. That’s no surprise given
the myriad of switches, relays, lights,
and motors that handle the windows,
locks, and mirrors.
Why not just use the existing back-
bone J1850 or CAN bus to network
the door, replacing the point-to-point
analog wiring? That sounds simple
enough, but in practice there are a
couple of problems.
First, having never met an MCU they
didn’t like, car designers are already in a
network traffic jam. There’s a lot of
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
79
Physically, the network is a single-
wire bus up to 40 m in length (subject
to the overall combined wire and
device capacitance limit) and accom-
modates up to 16 nodes. Both specs
seem more than adequate for localized
subsystems such as a door or seat.
LIN may lack the speed and whizzy
features of other networks, but it
makes up for it with a hardy constitu-
tion. The operating voltage range is a
wide 8 to 18 V, and LIN chips are even
required to survive the infamous “load
dump” 40-V surge. The transceiver
must tolerate (i.e., thermal shutdown)
and automatically recover from short
circuits. The loss of ground in a partic-
ular node doesn’t compromise the oper-
ation of the residual network. Slew
rates are controlled (1 to 3 V per
microsecond) to limit EMI.
WHO’S THE BOSS?
I must admit to
breathing a sigh of relief
at LIN’s adoption of a
simple single-master
multi-slave protocol.
After all, the peer-to-
peer concept is all the
rage, and even simple
networks (e.g., I
2
C) pre-
sume to offer multi-mas-
ter capability. It must
have been quite tempt-
ing for the LIN folks to
hop on the free speech
bandwagon.
Frankly, I’m glad they
didn’t. Multi-master
schemes always rely on
some kind of arbitration
time-sensitive traffic and not much
spare bandwidth to go around. Consider
a network of PCs using Ethernet.
Would it make sense to run every
mouse and keyboard over the network?
Neither does it make sense to hang
every switch, light, relay, and motor on
the primary CAN or J1850 bus.
Furthermore, big-ticket IVNs are
overkill for something as simple as
detecting a switch closure or activating
a relay. The cost and performance of
the networking hardware and software
vastly exceeds that which is justified by
the actual work involved, as it would
for an Ethernet keyboard or mouse.
What’s needed for cars is a subnet-
work that offloads the main IVN and
costs less to boot. Enter LIN, which
stands for local interconnect network,
but might as well stand for “little
inexpensive network.”
Founded by Motorola and a group of
car manufacturers including Audi,
BMW, DaimlerChrysler, Volkswagen,
and Volvo, the LIN consortium has
established a standard that’s freely
available and well on its way to pro-
duction. And although targeting the
automotive biz, I think it’s likely that
LIN will migrate into non-automotive
applications as well. Let’s take a clos-
er look, and you’ll see what I mean.
LIFE IN THE SLOW LANE
If real estate is all about “location,
location, location,” the essence of LIN
boils down to “cost, cost,
cost.” That’s not to say
there aren’t other techni-
cal objectives and consid-
erations. For instance,
keeping EMI to a dull
roar is important as the
number of ones and
zeroes flying about
climbs. And, of course,
reliability and durability
are always a concern in
automotive applica-
tions that have to toler-
ate all manners of
abuse from the weather,
potholed roads, and
shade-tree mechanics.
Nevertheless, if the
price isn’t right, there’s
no need to bother.
To that end, LIN does a
pretty good job of avoiding
the feature creep that can
subvert even the most well
intended standards efforts.
The pragmatism is reflected
in a strategy of leveraging
existing technology while
avoiding the temptation of
trying to do all and be all. As
you go through the specs,
you’ll see a lot of examples
of the “Keep it simple, stu-
pid” (KISS) principle at work.
When it comes to net-
working cost, power con-
sumption, reliability, EMI, and all the
rest, the story is simple: speed kills.
Thus, LIN specifies a maximum data
rate of 20 kbps and even allows run-
ning at a slower rate. Though not a
strict requirement, the recommended
data rates for slow, medium, and fast
devices are 2400 bps, 9600 bps, and
19.2 kbps, respectively.
As the rates might imply, LIN uses
the familiar UART scheme. There are
some embellishments, which you’ll
see a little later, but for the most part,
it’s the plain vanilla 8N1 (i.e., 1 start
bit, 8 data bits, and 1 stop bit)
approach that’s been around as long as
I can remember. Because practically
every designer knows how a UART
works and practically every MCU has
one, the LIN folks were wise not to
reinvent this wheel.
Embedded control
Multimedia
D2B, MOST
Optical ring
Flexray, TTx
time-triggered (TDMA),
fault-tolerant, dependable
2 × 2 wire/optical
Bluetooth
wireless medium
CAN-C
Arbitration (CSMA),
dual-wire
CAN-B
Arbitration,
fault-tolerant, dual-wire
J1850
LIN
Time-triggered,
master-slave,
single-wire, no quartz
Relative communication cost per node
0.5
1
2.5
5
25 Mbps
10 Mbps
1 Mbps
125 Kbps
20 Kbps
Data r
ate
Figure 1—With J1850 and CAN first off the line, the in-vehicle network (IVN) race is just get-
ting started. IVNs offer digital cables as an alternative to bulky analog wires.
Photo 1—Drive me to the moon? The fuel cells that powered the
Apollo space program are coming to a road near you.
80
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
LIN instead classifies messages accord-
ing to an identifier rather than an
address. In essence, a LIN identifier
describes the meaning of the data rather
than a source or destination.
So, using the window example, the
LIN master would issue a single mes-
sage (e.g., WINDOW_SWITCH_STATUS).
Both the window switch and window
control nodes detect that they are
involved, the former issuing a response
(e.g., NONE, UP, DOWN, EXPRESS_
DOWN) and the latter grabbing it and
driving the window accordingly. The
result is de facto direct slave-to-slave
communication in a single message.
Error handling, or “fault confine-
ment” in LIN-speak, is handled in a
similarly laissez-faire manner. Nodes
(master and slave) monitor their own
transmissions (i.e., compare what’s on
the wire with what they’re sending),
validate checksums, and perform a
variety of other error checks.
Slaves can note errors and report
them should the master choose to
interrogate. However, keeping with the
hack that invariably leads to compro-
mises in performance, predictability,
and complexity.
By contrast, all communication in a
LIN network takes place under the
direction of a single master. There’s
no arbitration overhead or uncertain-
ty, and slaves enjoy guaranteed access,
presuming, of course, the master
chooses to grant it. Note that a master
can also act as a slave (i.e., to itself).
One knock on polled master-slave
networks is that communication
between slaves requires a two-step
process. For instance, the master
might first interrogate a window
switch and then send the appropriate
command to the window motor/relay.
Not that this would be overly bur-
densome, but LIN offers a way around
the concern. Although most networks
are source and destination oriented,
Master control unit
Master task
Slave task
Slave control unit
Slave task
Slave control unit
Slave task
Bus
…
t
1
Inter-frame
space/break
Master task
Sync break
13 bit (minimum)
Sync field
1 byte
Identifier field
1 byte
Next sync break
Slave task
t
Response
space
Data field
2, 4, or 8 bytes
Check field
1 byte
Figure 2—In LIN, the master always initiates communication with a sync break, sync byte, and identifier.
Subsequently, a slave (possibly including the master) issues a response (1, 2, or 4 bytes of data) and checksum.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
81
“speak only when spoken to” master-
slave concept, there are no automatic
retries or ACK/NAK handshaking.
Instead, what happens when an error is
detected is left up to the designer and
application software. The spec recom-
mends basically ignoring intermittent
errors and bailing into the limp home
mode in the face of persistent errors.
No, it isn’t elegant, but that’s OK.
Consider the window switch message
example. If there’s a glitch and it does-
n’t get through properly, is there any
reason to panic and go through a fire
drill? Nope, just wait for the next
time around in the polling cycle. The
slight probability of a delay (a fraction
of a second) in window response surely
isn’t a showstopper, if even noticeable.
FRAME UP
With the previous explanation in
mind, understanding the LIN message
structure is a snap (see Figure 2). The
action starts when the master issues a
sync break, driving the bus low for 13 bit
times. This is the single area where LIN
is a little fussy about UARTs. Those who
don’t have hardware break generation
and detection will have to use an inter-
rupt and/or I/O line. Of course, the same
goes for bit-banged implementations,
which are feasible thanks to the relative-
ly low speed and complexity involved.
Following the break, the master
issues a sync byte, 0x55. Slaves use the
alternating ones and zeroes to align
with the master’s time base. This is a
key feature that allows LIN devices to
get by with relatively sloppy (i.e.,
±
15%) on-board (typically RC) clocks.
Of course, if both the master and slave
utilize accurate clocks (e.g., crystal),
the entire issue can be ignored.
Finally, the master issues the afore-
mentioned identifier byte comprised of
a 4-bit ID code, 2-bit length field, and
even and odd parity bits. At this point,
all slaves have detected the sync break
and established proper timing. After
receiving the identifier byte, the appro-
priate slave responds with 2, 4, or
8 bytes of data (depending on the length
field in the identifier byte) and a check-
sum. Thankfully, there are no rigid
response time specs, making life easy
for everyone. The only restriction is
that the overall response must arrive
within the maximum time allowed for
a single message in order to allow a loss
of communication to be detected.
Of the 64 unique identifiers that are
available (i.e., combined 4-bit ID and 2-
bit length), four are reserved by LIN for
administration (e.g., upload and down-
load firmware) and future extensions.
One of the administrative commands
the master can issue is Sleep, which
tells all of the nodes that they can
ignore the LIN bus until further notice.
Photo 2—The PICDEM LIN evaluation board from
Microchip shows off the new PIC16C432 and ’433
MCUs with built-in LIN transceivers.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
83
Said notice comes in
the form of a bus wake-up
signal, which is like a
Sync Break (nominally
eight bit times versus the
latter’s 13), except that
the slave issues it. The
wake-up signal tells the
master to start polling and
alerts other slaves to get
ready for LIN bus action
(i.e., the forthcoming sync
break issued by the newly
woken master).
Yes, the master doesn’t
know which slave issued
the wake-up call, and the
service time will be deter-
mined by that slave’s
place in the polling pecking order;
however, at least that service time is
completely predictable because, like
all other LIN timing, it’s totally under
the master’s control.
The bottom line is that every time
you’re about to raise an objection
and say, “But…,” just remember
we’re talking about switches, lights,
motors, and humans (i.e., a timescale
that even the slowest incarnations of
LIN can manage).
CHIPS AND DIPS
Witness to the credibility of LIN is
the off-the-shelf availability of a spec-
trum of silicon solutions from a num-
ber of major players. Presuming
you’ve already got a
UART (hardware or bit-
banged) and a handle on
the protocol, getting on
the LIN bus is as easy as
adding a transceiver such
as the Philips TJA1020
(see Figure 3).
There are only eight
pins to deal with, but
appearances can be mis-
leading. Just standing up
to the challenge of an
automotive electrical envi-
ronment is tough. Direct
battery connection calls
for all manner of protec-
tion against transients,
short-circuits, loss of
power, and so on.
The Philips transceiver goes further
with extras that simplify the overall
design. For instance, a node that’s
sleeping can be awakened remotely
(i.e., via a wake-up message on the
LIN bus) or locally (NWAKE pin), and
the transceiver informs the MCU of
the wake-up source.
*NWAKE
I
IL
(NWAKE)
Wake
timer
*NSLP
Sleep/norm
timer
R
SLP
TXD
RXD
R
TXD
TxD
Time-out
timer
Control
RXD/
INT
Bus
timer
Receiver
Transmitter
Temperature
Protection
Filter
BAT
INH
LIN
GND
I
IL(LIN)
R
SLA
VE
Figure 3—Turning a UART into a LIN port is as simple as adding the protocol software
(typically 0.5 KB of code or so) and a LIN transceiver, such as the TJA1020 from Philips
Semiconductor.
84
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
The popularity of LIN is
further highlighted by the
emergence of MCUs with
built-in transceivers (e.g., the
Microchip PIC16C432 in
Photo 2) and other LIN-orient-
ed support, such as the 2%
trim on-chip oscillator and
LIN-savvy break detection
logic on the Motorola
MC68HC908EY.
Motorola offers yet another
variation on the theme with
so-called “system basis chips”
that throw a LIN transceiver
into a comprehensive bag of
peripheral tricks. Examples
include the MC33689 and
MC33895, which are designed
for applications using DC motors, stepper
motors, lamps, and so on (see Figure 4).
With built-in LIN transceivers, these
chips will help seed standards in auto-
motive applications and beyond.
The Cypress PSoC is a novel chip
that, not surprisingly, has a novel take
on the LIN subject. Messages are han-
dled by three separate programmable
logic configurations that are dynami-
cally swapped in real time, cutting the
amount of logic consumed by two-
thirds (see Figure 5).
LIN SPIN
There’s no doubt LIN is destined for
success in automotive applications.
There’s also no doubt that relatively
few embedded designers work for car
companies. So why bother?
The fact is that LIN, like CAN before
it, is likely to evolve into other applica-
tion areas. For instance, Motorola notes
that the aforementioned MC33xxx
chips are not only ideal for a car door
or seat, but just as well for copiers,
printers, robotics, computer numerical
control machining systems, and electri-
cal actuators in appliances.
Both the transmitter and receiver fea-
ture line-monitoring sanity checks. If
the LIN bus is shorted to ground, the
receiver detects it and puts the trans-
ceiver to sleep, shutting off current
flow that might otherwise drain the
battery. Similarly, if the transmitter
input TXD is continuously asserted,
the transmitter is automatically shut
down so that one jabbering node does-
n’t bring the entire network down.
The INH pin is an output that’s
driven with the battery voltage when
the transceiver is awake. Thus, it can
be used to cycle power to the node
(i.e., MCU), either by controlling or,
with up to 50 mA on tap, supplying
an external voltage regulator.
Going one step further, the Melexis
TH8060 combines the LIN transceiver
with an on-chip regulator (5-V, 50-
mA, or 100-mA versions) and RESET
output. The chip also includes low-
voltage detection (SENSE) and a gen-
eral-purpose analog comparator (SI
and SO). The TH8060 connects easily
to your favorite MCU and automati-
cally handles power-on and reset via
LIN bus wake-up.
Figure 5—Dynamic
reconfiguration comes
out of the lab and
goes to work in the
Cypress Micro
Systems PSoC imple-
mentation of LIN.
SOURCES
TH8060 LIN Transceiver
Melexis, Inc. (USA)
www.melexis.com
PICDEM LIN, PIC16C432/433
Microcontrollers
Microchip Technology, Inc.
www.microchip.com
MC33895 Control drivers,
MC68HC908 microcontroller
Motorola, Inc.
www.motorola.com
TJA1020 LIN transceiver
Philips Semiconductor
www.semiconductors.philips.com
RESOURCE
LIN Consortium, www.lin-
subbus.org.
REFERENCES
[1] Ron Cogan’s Green Car
Journal
, “Hydrogen Storage at
10,000 PSI Certified In
Germany,” August 2002.
[2] S. Caldwell and D. Zehrbach,
“LIN Bus Enables Cost
Savings in Design, Inventory
Management, Manufacturing,
Design, and Maintenance,”
Microchip Technology, Inc.
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@cir-
cuitcellar.com.
Microchip specifically mentions the
security and fire protection market,
making a persuasive argument that
LIN is ideal for white goods or appli-
ance applications. [2]
Yes, there are a lot of contenders for
such LAN-in-a-box applications, but,
whether you consider it a kind of
CAN-Lite or I
2
C on steroids, it’s clear
that hardiness, availability, cost, and
simplicity stand in favor of LINs.
One thing’s for sure: with close to
10 million 8-bit MCUs shipping every
day, the party has just begun. Whether
a car or a washing machine, pop the
hood on the latest model, and you’re
going to find ever more micros and ever
more connections between them.
I
Figure 4—LIN is just part of the package for the MC33895 chip
that combines the network transceiver with a variety of blue-col-
lar I/O functions.
Header
Response
Sync break
field
Sync field
Sync break
generation
configuration
Data transmission
configuration
Identifier
Data
Check
Data reception configuration
(if data received)
Data transmission configuration
(if data transmitted)
Slave not responding; error detection
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
85
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
Bainbridge Island, WA 98110 USA
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!
86
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
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.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
87
88
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
Download the free ›Front Panel Designer‹
to design your front panels in minutes
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
89
90
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
92
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 150 January 2003
93
GPS-GSM Mobile Navigator
MCS-51 SBC for the Classroom—Part 1: Hardware
A Wireless Indoor/Outdoor Humidity Meter
USB Parallel Port
Robotics Corner: Easy Image Processing—Camera Interfacing for Robotics
I Above the Ground Plane: Nonlinear Mixing
I Applied PCs: A P89C668 Development Board for 8051 Fans
I From the Bench: Newcomer Nitron—Motorola’s Leading 8/16-Pin
MCUs
I Silicon Update: Working the ’Net
Preview of February Issue 151
Theme: Communications
94
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
INDEX
91
Abacom Technologies
42
Acon, Inc.
86
ActiveWire, Inc.
29
All Electronics Corp.
88
Amazon Electronics
8
Amulet Technologies
92
AP Circuits
90
Appspec Computer Tech. Corp.
34
Arcom
7
Atmel
87
Bagotronix, Inc.
86,95
Basic Micro
90
Bellin Dynamic Systems, Inc.
65
CadSoft Computer, Inc.
55
CCS-Custom Computer Services
92
Conitec
11
Connecticut mircoComputer, Inc.
47
Cyberguys
91
Cyberpak Co.
9
Cypress MicroSystems
88
CWAV
90
DataRescue
86
Decade Engineering
88
Delcom Engineering
1
Earth Computer Technologies
87
EE Tools
(Electronic Engineering Tools)
48
EMAC, Inc.
88
eProtos
The Advertiser’s Index with links to their web sites is located at www.circuitcellar.com under the current issue.
Page
91
EVB Plus
71
ExpressPCB
86
FDI-Future Designs, Inc.
88
Front Panel Express
86
Hagstrom Electronics
66
HI-TECH Software, LLC
91
HVW Technologies Inc.
63
ICOP Technology Inc.
87
IMAGEcraft
91,92
Intec Automation, Inc.
90
Intronics, Inc.
21
Intuitive Circuits, LLC
74
Jameco
64,90
JK microsystems, Inc.
50
JPA Consulting Ltd.
21
JR Kerr Automation & Engineering
37
LabJack Corp.
90
LabMetric
37
Lakeview Research
93
Lemos International
2
Link Instruments
93
Lynxmotion, Inc.
81
MaxStream
89
MCC (Micro Computer Control)
11
Microchip
90
Microcross
89
Micro Digital, Inc.
92
microEngineering Labs, Inc.
82
Micromint
86
MicroSystems Development, Inc.
85
MindTel LLC
87
MJS Consulting
17
Motorola
56
MVS
93
Mylydia Inc.
C2
NetBurner
55
OKW Electronics, Inc.
83
On Time
93
Ontrak Control Systems
48
PCBexpress
66
PCBpro
C4
Parallax, Inc.
71,85
Phytec America LLC
85
Phyton, Inc.
91
Picofab Inc.
89
Pioneer Hill Software
31
Polydroids
90
Prairie Digital, Inc.
89
Pulsar, Inc.
85
QKITS.COM
80
R2 Controls
39
R4 Systems Inc.
15
Rabbit Semiconductor
93
Radovan Robotics
83
RF Digital
89
RLC Enterprises, Inc.
Page
Page
Page
ADVERTISER’S
92
Rutex
5
Saelig Company
3
Scott Edwards Electronics Inc.
30
SeaFire Micros, Inc.
87
Senix Corp.
86
Sensory, Inc.
85
Signum Systems
89
Softools
92
Spectrum Engineering
85
Square 1 Electronics
88
SUMBOX Pty Ltd.
49
Systronix
37
TAL Technologies
C3
Tech Tools
24,25
Technologic Systems
91
Technological Arts
88
Tern Inc.
90
Triangle Research Int’l, Inc.
30
Trilogy Design
93
Weeder Technologies
91
Xeltek
87
Z-World
21
Zagros Robotics
93
Zanthic Technologies Inc.
March Issue 152
Deadlines
Space Close: Jan. 9
Material Due Date: Jan. 17
Theme:
Signal Processing
A
TTENTION
A
DVERTISERS
Call Sean Donnelly to
reserve your space!
860.872.3064
e-mail: sean@circuitcellar.com
here are many readers who are familiar with the statement, “Inside the box still counts” and understand its history.
If you are a new subscriber, I’ll give you a hint.
Circuit Cellar started 15 years ago with exactly these words on the
front cover. Although not as historically significant as Patrick Henry’s eighteenth-century “Give Me Liberty or Give Me
Death” speech, it was a declaration of independence nonetheless.
The year was 1987, and as most of you know, I was writing for
BYTE at the time. Depending on which floor you were standing on at
McGraw-Hill, I was viewed either as the best marketing attraction they had or their worst nightmare. The reason was pretty straightforward
and entirely political. Without sounding too egotistical, my project articles were the reason many readers subscribed, and I had a loyal fol-
lowing. McGraw-Hill didn’t have to spend a lot of money getting these people to renew their subscriptions. Unfortunately, my hands-on proj-
ects such as an in-circuit debugger, a brain-wave analyzer, and a programmable infrared remote control didn’t fit their new redirected corpo-
rate interest in the PC.
When I say “interest,” I say it with a smile. I doubt they had any more understanding of the PC than they had of my projects. What they did
see, however, was the IBM PC market expanding and many new magazines jumping on the gravy train. Rather than create a new publication
to specifically address PC interests, they decided to refocus
BYTE from being a general computer design and technology magazine into a
competitive clone of
PC Magazine. They essentially told 450,000 readers that, like some U.S. senators, they had switched parties.
When the change happened, it was like flipping a switch. I was still under contract but I could see the writing on the wall, or bits in the ether.
Anything non-PC was viewed as “the old discipline,” and anything PC was the new religion. They didn’t say, “here’s some money, now go
away,” so I just continued doing my thing for the next year. If you look back at the ’87 and ’88 issues, you’ll see that there were some really
fantastic projects, even an AT clone and a Mandelbrot generator containing 64 parallel processors. I guess I wanted to leave with a bang!
In all fairness, I have to say that McGraw-Hill did make me an offer to stay. Provided I only covered PC-oriented subjects, wrote hardware
reviews for advertiser’s products, and did it all for 50% less, I could stay. Needless to say, I’m not one who caves under pressure, and I
thought that contributing to the collective insanity was masochistic.
A few other noble
BYTE patriots agreed that going down with the ship makes sense for national defense but not corporate ambition, so
they joined with me to start
Circuit Cellar INK—Microcomputer Applications. This was before the technical world was freely using the term
“embedded control” to describe our focus; however, we all knew what we were trying to say. The first issue’s simple title “Inside the Box
Still Counts,” said it all.
BYTE’s search for the pot of PC gold at the end of the rainbow is history. Everyone knows they failed, but I take no special pleasure in say-
ing they’re gone while I’m still here. They failed not because they refocused on the PC, but because they never succeeded in focusing on it
enough. In other words, they never quite got it right and readers lost the feeling that seeking excellence was
BYTE’s highest priority.
We’ve been around for 15 years now and I think we’ve done a good job of making sure you know that the quality of the content is para-
mount to us. Perhaps it’s because I have firsthand experience seeing what losing focus can do to a magazine, I take special care to make
sure we maintain ours. We’ve changed the intensity of presentation over the years, but we’ve also endeavored to remain an authoritative
applications resource. And, unless I’ve been in a fog for a pile of years,
Circuit Cellar is still aimed directly at embedded control.
We started a magazine because we felt that our expertise and interests were being abandoned by people in search of a pot of gold. Today,
we know that our little corner of the computing world is bigger than all of the PCs put together and worth its own pot of gold. Back then we did-
n’t really know enough to call it embedded control. We just knew that we had to tell people that what’s inside the box still counts.
Inside the Box Still Counts
INTERRUPT
t
steve.ciarcia@circuitcellar.com
96
Issue 150 January 2003
CIRCUIT CELLAR
®
www.circuitcellar.com
PRIORITY
Wyszukiwarka
Podobne podstrony:
więcej podobnych podstron