7
9
25274 75349
0 6>
CIRCUIT
CELLAR
®
ww
ww
ww
..cc
iirr
cc
uu
iitt
cc
ee
llll
aa
rr
..cc
oo
mm
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 PROGRAMMING
Battery Monitor For RC Apps
Coding And Debugging With
JTAG ICE
Invisible Components
Open Source
Motor Control
#143 June 2002
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
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
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
5
BatMon to the Rescue
A Battery Monitor for RC Applications
Extreme OSMC
Part 1: Open Source Motor Control Project
Ultra-Low Power Flash MCU
MSP430 Design Contest Winners
Announcement
Selecting the Best CAN Controller
Starting Down the Pipeline
Part 1: Hyper-, Super-, Whatever-Pipelines
RoCK Specifications
Part 3: Behavior-Based Programming
ROBOTICS CORNER
Behind the Scenes
Part 2: Software Control
APPLIED PCs
Still Swimming With the STK500
Onto the JTAG ICE
SmartMedia File Storage
Part 1: A Windows/DOS-Compatible File
System
SILICON UPDATE
FPGA Power Play
24
COLUMNS
ISSUE
Task Manager
Jennifer Huber
Summer Fun
New Product News
edited by John Gorsky
Advertiser’s Index
July Preview
Priority Interrupt
Steve Ciarcia
Broadband—A Report Card
6
8
11
94
96
143
28
58
66
70
76
12
20
40
50
44
FEA
TURES
ummer is finally here. Usually, that would bring
a smile to my face as I think of leisurely lounging
in a lawn chair and reading. The thought of summer
gets me ready for trips to the shore, barbecuing, and long
afternoons of playing stick with my dog. But this year, I don’t know what
to expect from the weather. The atmosphere is under some Sybil-like
control. It seems just as likely that it could be a steamy 115°F or –10°F
and hail on any given day.
Spring certainly had some ups and downs. Does everyone remem-
ber April? Here on the East Coast, we started the month with a freakish
90°F-plus heat wave, followed by snow the following week. And about a
week later, a dramatic storm sent more than a dozen tornadoes across
the Midwest and up the eastern seaboard. Record-breaking tornado
winds near 300 mph were reported in southern Maryland.
With the worsening greenhouse effect and global warming, it’s pre-
dictable that unpredictable months like that one probably won’t be rare.
Unfortunately, I may have to curtail my plans for outdoor activities as I
head for cover from unfathomable heat or sleet and snow in July.
As more and more things in life become less and less predictable, it’s
comforting to know that some things are the same. Technology remains
an indomitable force in all of our lives. It will be you guys, the engineers,
who devise the best solutions for curbing pollution and decreasing
greenhouse gases.
Well, all of the solutions may not be ready yet, but the progress of
embedded programming is on course. In this issue, you’ll find some
interesting projects that mark this trend. How about a high-tech battery
monitor for use in your remote control applications? Working with a
remote-controlled model helicopter, Thomas Black needed a reliable
monitor that would fit the size constraint of the model (p. 12).
Possibilities abound for his resulting monitor. You’ll find a lot of potential
in Sonny Lloyd’s project, as well (p. 20). His open-source motor con-
troller works with whatever remote control project you have in mind.
Sonny notes that with his motor controller, you’ll have added reliability,
robustness, and protection.
In addition, Fred Eady is back with his take on the Atmel STK500
(p. 58). This month, he moves on to talk about the JTAG ICE. Fred gives
the STK500 tool two thumbs up, so you don’t want to miss this article.
This month we’re also announcing the winners of the Ultra-Low
Power Flash MCU MSP430 Design Contest, which was sponsored by
Texas Instruments. Turn to page 24 to read about the various projects.
Congratulations to all of the winners!
So, as always, there are some intriguing articles for you to read. If
you plan to kick back, relax, and read this issue outside, you would be
wise to bring sunscreen and a parka, just in case.
6
Issue 143 June 2002
www.circuitcellar.com
CIRCUIT CELLAR
®
EDITORIAL DIRECTOR/PUBLISHER
Steve Ciarcia
WEB GROUP PUBLISHER
Jack Shandle
MANAGING EDITOR
Jennifer Huber
SENIOR EDITOR
Rob Walker
TECHNICAL EDITOR
C.J. Abate
WEST COAST EDITOR
Tom Cantrell
CONTRIBUTING EDITORS
Ingo Cyliax
Fred Eady
George Martin
George Novacek
NEW PRODUCTS EDITOR
John Gorsky
PROJECT EDITORS
Steve Bedford
David Tweed
ADVERTISING
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 CLERK
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
ACCOUNTANT
Howard Geffner
CUSTOMER SERVICE
Elaine Johnston
ART DIRECTOR
KC Prescott
GRAPHIC DESIGNERS
Cindy King
Mary Turek
STAFF ENGINEERS
Jeff Bachiochi
John Gorsky
QUIZ COORDINATOR
David Tweed
EDITORIAL ADVISORY BOARD
Ingo Cyliax
Norman Jackson
David Prutchi
TASK
MANAGER
Cover photograph Ron Meadows—Meadows Marketing
PRINTED IN THE UNITED STATES
s
Summer Fun
jennifer.huber@circuitcellar.com
NEWS
8
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
NEW PRODUCT
Edited by John Gorsky
ALL-IN-ONE IN-CIRCUIT DEBUGGER/PROGRAMMER
The MPLAB ICD 2 is an in-circuit debugger and program-
mer that provides a flexible microcontroller development sys-
tem. The ICD 2 supports Microchip’s PIC16Fxx/18Fxx flash
memory microcontrollers and PIC digital signal controllers.
The device connects between a PC operating with the
MPLAB IDE via a USB or RS-232 and the product board. You
can view the microcontroller,
allowing real-time viewing of vari-
ables and registers using watch win-
dows. A single break point can be
set, halting the program at a specif-
ic point. You can use the device to
(re)program the microcontroller
while installed on the board.
Additional features include built-
in over-voltage and short circuit monitors, support of 2- to 6-
V operation, diagnostic LEDs, program memory space erasure
with verification, and freeze-on-halt for diagnostic purposes.
The MPLAB ICD 2 costs $159; the evaluation kit costs $209.
DUAL-PORT ETHERNET CONTROLLER
Featuring two independent Ethernet ports, the new
Dual-E is a unique SBC. Aimed at applications requir-
ing connection to multiple networks, the Dual-E can
function as a bridge between separate 10Base-T net-
works, serve as a firewall/router, or provide Ethernet
and serial connectivity to existing equipment.
The USNET Embedded TCP/IP protocol suite from
US Software provides the TCP/IP functionality. The
board features an Intel 386Ex processor and DOS oper-
ating system. The serial ports, counter/timers, and
interrupt controller are fully compatible with a PC at
both the hardware and software levels. Additional fea-
tures include a watchdog timer, hardware clock/calen-
dar, RS-232/485 serial port capabilities, network status
LEDs, as well as flexible storage options.
The Dual-E costs $199
and includes USNET. A
development kit is avail-
able for $399.
Microchip Technology, Inc.
(480) 792-7668
www.microchip.com
JKmicrosystems, Inc.
(530) 297-6073
www.jkmicro.com
Adjust Speed and/or Direction
Easy Serial Interface
Tachometer/Counter Input
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
9
NEWS
NEW PRODUCT
WIRELESS SENSOR TRANSCEIVER
The RT12-4204 is a highly accurage wireless sensor
transceiver that converts a wired system into a seam-
less, wireless connection. The RT12-4204 allows a con-
nection between any 4- to 20-mA, 0- to 5-VDC, or 0- to
10-VDC sensor and a data logger, controller, or SCADA
equipment, eliminating up to 20 miles of wiring.
The device accepts up to four analog inputs and two
optically isolated inputs/open-collector outputs. It can act
as a signal converter by allowing independent configura-
tion between the input and output modules. The device
also can supply a voltage to most sensors.
The RT12-4204 has an on-board 2 × 16 LCD that dis-
plays real time information. User-configurable parame-
ters include a transmission sampling rate, transmission
retries, analog scaling factors, and controller ID number.
The RT12-4204 may be shipped
with a 900-mHz or 2.4-MHz, license-
free ISM band, frequency hopping
spread spectrum radio. A pair costs
$937 in 100-piece quantities.
ENTRY-LEVEL PC/104 CPU
The CoreModule 4Gn is a PC/104-based SBC. It pro-
vides entry-level functionality for embedded applications
that require a low-cost x86 processor. The device
includes a high-integration 100-MHz, 486DX4-compatible
processor. The processor includes a real time clock with
CMOS setup and battery-free option, watchdog timer, and
2-Kb configuration EEPROM (512 bits available for OEM
use supported through Ampro Enhanced BIOS services). It
also has 16-MB on-board DRAM expandable to 32 or 48 MB
via a socketed DRAM module and a byte-wide socket for
DiskOnChip 2000 or Millennium bootable flash disk.
The I/O supports one or two fast IDE disk drives, two
RS-232 serial ports (one with RS-485 option), a bidirection-
al parallel port, floppy, and PC/AT keyboard/mouse inter-
face. The unit has a power requirement of 5 V at 0.8 A
and runs at 0°C to 70°C, with optional –40°C to 85°C
extended temperature support.
The CoreModule 4Gn costs about
$300 in volume.
Ampro Computers, Inc.
(800) 966-5200
www.ampro.com
Advanced Embedded Systems, Inc.
(520) 682-4364
www.advancedembedded.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
11
CIRCUIT CELLAR
Test Y
Your E
EQ
Problem 3
—
What is the area density of this
technology?
Contributed by Naveen PN
Problem 4
—
If the disk is spinning at 5400
rpm, what is the raw transfer rate to/from the
disk surface?
Contributed by Naveen PN
Problem 1
—
What does the term “zombie”
mean when it comes to computer security?
Contributed by Naveen PN
Problem 2
—
Modern disk drives can pack
75,000 bits in one linear millimeter of track
length, and 750 tracks per millimeter of radius.
What is the raw capacity of a disk surface
whose minimum usable diameter is 3 cm and
maximum usable diameter is 8 cm?
Contributed by Naveen PN
What’s your EQ?
—The answers and 4 additional
questions and answers are posted at
www.circuitcellar.com/eq.htm
You may contact the quizmasters at
eq@circuitcellar.com
AD422 (Requires 9VDC) $79.00
AD422-1 for 110VAC
ADA485 (requires 9VDC) $79.00
ADA485-1 for 110VAC
CMC’s low cost converters adapt any
use with RS422 or RS485
devices
• Adds multidrop capability to
ADA425 (requires 9VDC) $89.00
ADA425-1 for 110VAC 99.00
Mention this ad when you order and deduct 5%
Use Visa, Mastercard or company purchase order
WWW.2CMC.COM Fax:(203)775-4595
PO BOX 186, Brookfield,CT 06804
Connecticut microComputer, Inc.
12
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
hate to see
folks suffer with
old-fashioned reme-
dies. After three decades
of such anguish, I decided that enough
is enough. So what am I talking about?
Well, my focus for today’s pain relief is
related to monitoring the battery packs
used in RC models. The cure comes as
BatMon, the sophisticated battery mon-
itoring accessory shown in Photo 1.
I started flying RC model aircraft in
the late 1960s. Back then, I was a young
lad with an expensive hobby support-
ed by neighborhood lawn mowing
jobs. Because of my limited budget, I
used inexpensive Rayovac carbon zinc
cells in my RC transmitters and
receivers. My radio gear was simple
and this was a suitable solution.
But, affordable digital proportional
radios eventually came along and the
battery needs changed dramatically.
Rechargeable NiCd battery packs
became the power source of choice.
The common configuration for air-
borne electronics was a four-cell pack
that provided 4.8 VDC. Battery capaci-
ties were typically 500 to 600 mAh.
Checking the battery was something
of a witch hunt. You would measure
the pack with a voltmeter modified to
expand the reading near the nominal
4.8-V range. A flashlight bulb was used
as a moderate resistive load. A meas-
urement that was under 4.7 V would
indicate that it was time to end the
day, because the pack was unsafe to
fly. A higher voltage was assumed to
be good to go. It was a reliable method
if you observed its limitations, but at
best it only offered a pass/fail status.
Other than by gut-felt experience,
you never really knew the true dis-
charge state of the pack. But given the
needs of the day and the available tech-
nology, I was happy with the voltmeter
test. Sure, new folks to the hobby
would occasionally misuse the method
(or ignore the test) and fly on a near
empty pack. Even the pros did this
from time to time. As you can guess,
an airborne RC model with a dead bat-
tery is not a pretty sight. Fortunately,
balsa wood was cheap back then.
Because a battery’s storage capacity
is analogous to a car’s fuel tank, I want-
ed to be able to see the charge level in
the same way a gas gauge works in a
car. That would be much better than
the voltage method, because a peek at
the remaining capacity would offer
advanced warning if I were flying on
fumes, so to speak.
The underlying problem is that the
discharge voltage curves for NiCd bat-
teries are not linear. In fact, they
spend nearly all of their useful dis-
charge time at 1.2 V per cell. To com-
plicate matters, the voltage is affected
by the load (servo movement) and out-
side temperature. The voltage charac-
teristics also change as the battery
ages. Predicting the remaining battery
capacity with any accuracy was out of
the question for the average modeler.
Fast forward about 30 years. I now
fly RC model helicopters. These high-
tech aircraft are notorious for consum-
ing battery current because the servos
are quite active and under a heavy load.
But, no matter what type of model is
flown (or driven), I still use NiCd bat-
tery packs. Following them in populari-
ty are the nickel metal hydride (NiMh)
type. Both chemistries provide 1.2 V
per cell and are rechargeable. Their
nonlinear discharge curves have not
changed much. There are other battery
technologies that are in use, but these
two are used by most RC hobbyists.
BatMon to the Rescue
i
For years, hobbyists
have relied on volt-
meters and guesswork
to monitor the storage
capacity of battery
packs for RC models.
Now, Thomas intro-
duces a more precise
high-tech battery moni-
tor that is small
enough to be mounted
in the cockpit of an RC
model helicopter.
Thomas Black
FEATURE
ARTICLE
A Battery Monitor for RC Applications
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
13
mount in each model aircraft (see
Figure 1). This is not your typical larg-
er-than-life Gotham City solution. It’s
only 1.3
″
× 2.8
″
and weighs one ounce.
But the BatMon does have the typical
dual persona expected of a super hero.
For user simplicity, it reports battery
capacity as a zero to nine (0% to 90%)
level value. This is my favorite mode
because it works just like a car’s gas
gauge. However, for those of you who
must see hard numbers, it also reports
the actual remaining capacity—up to
2500 mAH—with 5% accuracy.
In addition, it reports problems asso-
ciated with battery pack failures, bad
on/off switches, and defective servos.
A super-bright LED indicator flashes if
any trouble is detected. Even in mod-
erate sunlight this visual indicator can
be seen from a couple hundred feet
away, which is perfect for fly-by checks.
The BatMon is compatible with all
of the popular battery sizes. Pack
capacities from 100 mAH to 2500 mAH
can be used. They can be either four-
cell or five-cell of either NiCD or
NiMH chemistries. The battery param-
eters are programmed by using a push
button and simple menu interface.
The device has three connections.
Two of the RC-style connectors are
inserted in series with the battery pack.
Because you are making current meas-
urements, this sort of intimate connec-
tion is necessary. There is a third con-
nector that plugs into a spare channel
of the RC receiver (or you can use a
Y adapter on any servo). This connector
enables the display when the RC
receiver’s power switch is turned on.
The thought of losing control of a
flying model, due to a defect in the
BatMon, was not something that I
wanted to encourage. My main concern
was that the BatMon circuitry was
directly in the path of the RC equip-
ment’s battery. Fortunately, only three
passive components are in this critical
area, and two of them are RC type con-
nectors. The third is a shunt resistor
that was carefully selected to ensure
reliable operation. If you assemble the
BatMon correctly, it will not pose a
risk to your equipment’s reliability.
Perhaps the most important ele-
ment of the project was the display. I
searched for a suitable two-line LCD,
We still use four cells to power our
receivers and servos. Some folks have
implemented five-cell power sources
to turbo charge their servo speeds. Over
the years, the packs’ milliamp-hours
capacities have dramatically increased
and the size and weights have tumbled.
I am happy to report that cell reliability
is extraordinary. Battery troubles nowa-
days are nearly always self-inflicted.
But, the same inaccurate voltage
test is used to determine the discharge
state of battery packs. Oh sure, the
measuring devices have transformed
into cute bar graph indicators, bright
LEDs that blink morse code warnings,
and audio beepers. Of course the
expanded scale voltmeters that we used
in the old days are still popular, too.
But all of these methods rely on the
same brainless go/no-go voltage test.
So, what gives? The battery gauging
technology required to report the true
remaining cell capacity (milliamp
hours) has been around for years. This
is common practice in portable com-
puters and other consumer devices.
Patiently, I waited for an RC battery
gauge to show up at the hobby store.
Sadly, a little on-board gadget that
would work with my RC receiver never
materialized on the store shelf. Several
years ago there was a rumor that one
was available, but it quickly disap-
peared long before I could get my hands
on one. Today, electric model hobbyists
use the digital watt-meter devices, but
they are designed to monitor the heavy
currents consumed by electric motors.
I wanted finer resolution so I could
use it with my RC receiver and servos.
With that in mind, a couple of years
ago, I convinced my firm that we
should tackle this challenge. Although
we were not in the RC equipment busi-
ness, there was some interest. It was
decided that I would develop a proto-
type that would act as a proof-of-con-
cept. The premise was that if I could
stir up some interest among local RC
pilots, then a more advanced design
would follow before we attempted to
pitch it to the hobby industry. With
luck, this was to become a low-cost
RC accessory at the local hobby store.
As you will soon see, the project was
completed and has served me well for
over two flying seasons. Sadly, it did
not become a commercial offering.
I’m happy to report, however, that I
finally have what I always wanted and
I’m pleased to share it with all of my
RC comrades. The project is well suit-
ed for monitoring the battery in near-
ly any electronic device, so its use is
not limited to RC applications.
At the start of the project, I assumed
that the most logical design centered
on installing the tiny battery gauging
IC inside the battery pack. A special
hand-held LCD readout would plug
into the model’s charge jack (a handy
place to do so). It would extract the
remaining capacity via the unused con-
nector pin found on all RC receiver bat-
teries. The nice thing about having the
data stored inside the battery is that it
allows you to swap the pack and the
data remains with it. It also appeared
to be a cost-effective arrangement.
But this solution was soon deemed
unacceptable for several reasons. First,
existing battery packs would need to
be outfitted with the special IC. This
is a low-cost effort at the time of pack
assembly, but a retrofit connector-based
solution would be more costly. Also, it
was not common to swap packs in the
field, so this assumed advantage really
did not add much value. But most
importantly, this concept did not have
any visual warning features that would
alert you of pack trouble while flying.
My solution evolved into the
BatMon, a standalone device that can
4.8- or 6-V
battery
8
BAT RX AUX
BatMon
Radio
Control
RCVR
BAT
CH1
CH2
CH3
CH4
Connect to any channel
Charge
plug
On/off
Figure 1—
Installation in an RC model is as simple as
plugging in three cables. Multiple point measurements
allow the system to detect battery-related trouble.
Voltage detection at the RC receiver even helps detect
stalled servos and electrical issues.
components required to use the
DS2438. RSENSE is a fractional ohm
current sense resistor. RF and CF are
configured as an input filter. Don’t let
this simplicity fool you, this fellow
has a lot going on under the hood.
The DS2438 is a register-based
device. The registers are accessed by
the host through a clever bidirectional
communication scheme. If you have
ever used a low-pin-count Dallas IC
before, then you are no doubt
acquainted with the company’s one-
wire bus protocol. The chip is self suf-
ficient and can operate by itself after
the host has configured it. A nifty
one-wire trick is that the registers can
be accessed even if the battery source
is completely dead. This feature is not
needed in the BatMon design.
In the BatMon, the one-wire bus
begins at pin 6 (port RA4) of the
PIC16C63 microcontroller and termi-
nates at the DS2438’s DQ I/O line (pin
8). Using bit-banging I/O, the PIC can
read and write the necessary registers.
The timing is critical, but the PIC is
capable of handling the chore. Full
14
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
but I didn’t find any decent offerings. I
decided to use a seven-segment LED
display for the initial design. I reck-
oned that a custom LCD would need
to wait for a production version of the
BatMon. In retrospect, the LED dis-
play works surprisingly well.
The seven-segment display will
accommodate one character at a time.
This works nicely with the zero to
nine battery level values, but some
trickery is used to show the four-digit
capacity and two character error
codes. These values are merely
“spelled out” in a flash card sort of
way. For example, 575 mAH would
repeatedly flash as “5,” “7,” or “5.”
An issue with the LED readout is
that it consumes almost 60 mA of cur-
rent. Because it does not need to be on
while the aircraft is flying, it can be
set to display only when you press the
push-button switch. Upon release it
will shut off after a few seconds. As a
convenience, the level value flashes
every 5 s when the display is off. But, if
you want the display active at all times,
you can set the BatMon to do so.
The battery gauging IC that I used
is from Dallas Semiconductor. There
are other firms that have similar parts
(Unitrode, TI, etc.), but the Dallas
DS2438 Smart Battery Monitor was a
perfect choice for my RC application
(see Figure 2). This eight-pin coulomb-
counting chip contains an A/D-based
current accumulator, A/D voltage
convertor, and a slew of other features
that are needed to get the job done.
The famous Dallas one-wire I/O
method provides an efficient interface
to a PIC16C63 microcontroller.
There’s a lot I could say about the
DS2438, but the Dallas folks have done
a fine job of explaining its operation in
the 30-page datasheet. But, I will gladly
take you for a quick stroll just to help
acquaint you with some areas of inter-
est. You will quickly realize that the
chip has significant smarts built into it.
Looking at the block diagram in
Figure 3, you can see that there are
few connections to the outside world.
Communication to the host requires
only one pin. Besides a host microcon-
troller, there are only three external
Figure 2—
A battery fuel gauging IC
and a microcontroller are combined to
accurately measure the current con-
sumption of an RC system. The single-
character LCD is used to display bat-
tery data and status messages.
352*5$03,&
352*5$03,&
352*5$03,&
352*5$03,&
352*5$03,&
ª6,1%$6,&
ª6,1%$6,&
ª6,1%$6,&
ª6,1%$6,&
ª6,1%$6,&
MBasic Software
W
hether your just learning or a professional, Programming PICmicro®
MCUs has never been easier ! MBasic is much simpler than C or
Assembly. MBasic creates a one click solution that allows you to
experiment and test code changes on-the-fly! Bring your projects to life
quicker and easier with MBasic for PICmicro® MCUs !
ICD - In Circuit Debugger
Stop wasting time strategically planting debug statements throughout
your entire program. MBasic includes a built-in ICD (In Circuit
Debugger ) FREE. Watch variables, SFRs and RAM values as each
line executes. MBasic’s ICD is so easy to use, even the first time user
can have it up and running in minutes !
MBasic and Assembly Language
Seasoned Assembly programmer or just learning ? MBasic allows an
easy mix of BASIC and Assembly. Instead of spending weeks writing
your program, have it done in days !
Syntax
A complete set of easy to use commands ! Serin, Serout,
If..Then..Elseif..Else..Endif, Do..While, While..Wend, OWin, OWout,
ADin, Pulsin, Pulsout, PWM, Xin, Xout and more! Plus easy acces to
all PICmicro built-in hardware peripherals.
Math
MBasic is the only BASIC compiler that supports 32 bit floating point
and integer math. This includes 32 x 32 bit divides and multiplies.
MBasic Pro Only $229.95
Includes Printed Manual and CD-ROM with MBasic.
3,&0,&52722/6
3,&0,&52722/6
3,&0,&52722/6
3,&0,&52722/6
3,&0,&52722/6
ISP-PRO Programmer
- Uses PC Serial port (USB w/ adapter)
- Very Simple to use
- Free Software updates
- Complete with Windows IDE!
- Easy in-circuit programming
- Supports PIC, Scenix, I2C and more!
- Firmware upgrades Free!
- RJ-11 / 10 Pin Header
- Includes RJ-11 Cable
Solderless Development
- Completely Assembled Board
- In Circuit Programmable (ISP)
- Solderless Bread Board
- Built in RS232 (w/ Max232)
- Built in Power Connector
- Removable Oscillator
- Documentation
- Auto Disconnect for RB3, RB6, & RB7
- Available in several models
Development Kit
Includes:
- MBasic Pro Compiler
- 2840 Development Board
- ISP-PRO Programmer
- PIC16F876-20
- 10Mhz Resonator
- Serial Cable
- Power Supply
- CD-ROM and Manual
Download MBasic
Lite FREE !
Starting At $159.95
Starting At $59.95
Only $59.95
Learn to Program PIC Microcontrollers in easy to use BASIC
Optional ISP-PRO
Items Available
- Plastic Enclosure
- 40 Pin Zif Adapter
- Universal Adapter
Try before you buy !
PICMICRO
MCU
®
TOOL
S
7RRUGHUYLVLWwww.basicmicro.com
M i c r o c o n t r o l l e r s M a d e E a s y™
MBASIC is a registered trademark of Basic Micro Inc.
PICmicro is a registered trademark of Microchip Inc.
Join our on-line PIC forums, information and help FREE!!!
16
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
details of the I/O protocol are outlined
in the DS2438 datasheet, so I won’t
repeat them here.
The integrated current accumulator
(ICA) register is the main workhorse
inside this petite part. It records current
consumption using a coulomb-counting
scheme. An internal oscillator sam-
ples the voltage across the RSENSE
resistor (R12) at a rate of 36.4 times
per second. The RC filter (R2 and C2)
has a cutoff of about 16 Hz, which
tames noise but allows the needed
current spikes to be captured.
Because small current ADC offset
errors can severely affect the long-term
accuracy of the ICA, the DS2438 has a
register that cancels the offset currents.
The offset register makes the correction.
The BatMon is designed to use this
clever nonvolatile R/W register. There
is a special user-invoked mode that
initializes the correction value. This is
done using the push-button switch
after the board is assembled. For full
details to the offset calibration, read
the user guide, which can be down-
loaded from the Circuit Cellar ftp site.
The DS2438 has registers that report
instantaneous current, battery voltage,
and external voltage. These features
were a blessing to the project. But not
all of the goodies were needed. The
temperature, elapsed time meter (ETM),
disconnect time stamp (DT), charge
current accumulator (CCA), discharge
current accumulator (DCA), and end-
of-charge (EOC) registers are all ignored.
These features are available if you wish
to expand the functionality of the
BatMon. For example, cold battery tem-
peratures will reduce effective capacity,
so the temperature register could be
used to adjust the reported values.
After the PIC has initialized the
DS2438, battery consumption is auto-
matically tallied by the ICA register. It
has eight scaled bits of resolution, so
the sense resistor (R12) determines the
bit weights. With the selected 0.050-
Ω
value, each count is 9.765 mAH, which
results in a max count of 2500 mAH.
The ICA can sense the direction of
current flow, so the accumulator counts
down during battery discharge and
counts up during recharge. The ICA
register is read by the PIC16C63 every
100 ms and the value is scaled into
milliamp-hours and a zero to nine level.
You decide what to display on the
seven-segment LED. You can toggle the
two measurements (level versus capaci-
ty) by pressing the push-button switch.
I also wanted to accommodate some
of the oddities that are associated with
NiCd and NiMh batteries. For one
thing, they are not 100% efficient dur-
ing the charge cycle. They also tend to
self-discharge when they are resting. To
partially mask these issues, the PIC
compensates the values held in the ICA
register. During a charge cycle, the
PIC reduces the ICA’s value by about
20%. This mimics an 80% charge effi-
ciency. During idle periods, the ICA is
reduced by 2% every 24 h.
Both of these corrections are practical
values and work well. Zealots may
argue that the values are too general-
ized, but hey, these are often the same
guys who use a voltmeter to check
their packs. Besides, the BatMon does
not change the way you maintain your
batteries, so a fresh charge is always
expected before using them. This
requirement makes the correction
process unnecessary, but I added it to
the software anyway.
Limiting the BatMon’s job to mere
fuel gauging would have been short-
sighted. After all, there are all sorts of
things that can go wrong but can easi-
ly be detected by monitoring the
pack’s voltage under load. The DS2438
can measure two voltages, so it was
elected to lend a helping hand.
Photo 1—
The BatMon is small enough to fit in most
RC models. The three cables plug into the model’s
RC system. A bright LED remotely warns the pilot of
battery trouble. The single character display reports
the remaining capacity of the battery.
Mixed-Signal Controllers
MSP-FET430P120
development
tool-$99
Device
Flash
RAM
I/O
WDT
Timer_A
USART
ADC
Price
MSP430F1232
8 kB
256
22
✔
✔
1
10-bit
$2.79
MSP430F1222
4 kB
256
22
✔
✔
1
10-bit
$2.62
MSP430F1132
8 kB
256
14
✔
✔
10-bit
$2.48
MSP430F1122
4 kB
256
14
✔
✔
10-bit
$2.24
MSP430 offers 50X more throughput.
Features
200-kSPS 10-bit ADC with
Data Transfer Controller
8-kB ISP Flash
0.8-µA standby mode,
250-µA active mode
On-board brown-out detector
USART can be used in
UART/SPI mode
MSP430the choice in ultra-low-power Flash MCUs
Experience the ultimate SOC solution for battery-powered measurement. A flexible clock system
switches from ultra-low-power standby to high-performance signal processing in less than 6 µs.
Embedded emulation reduces design cycle time. Get your design started today with the
easy-to-use MSP-FET430P120 Flash emulation tool.
MSP-FET430P120 development tool for $99,
product bulletin, F12x2 Datasheet and FREE samples
MSP430F1232
Enter the MSP430 Design Contest
www.ti.com/gadgetorama2002
▲
even if the aircraft is flying. It will
flash a single wink if the battery
capacity is low (under 30%). A double-
wink indicates a more serious issue
that needs immediate attention.
One of the issues that needed to be
addressed was that the end user’s bat-
tery pack ratings can vary. To work
effectively, the BatMon needs to know
the pack’s rated voltage and milliamp-
hours capacity. After all, the model
could be equipped with nearly any pack
capacity. To complicate matters, four
cells (4.8 VDC) or five cells (6 VDC)
might be installed. The solution
involves the push-button switch and
some fancy footwork.
There is a special programming menu
that can be activated by following a
certain power-on sequence. First, turn
on the model’s power using its on/off
switch. Wait for the display to appear.
Second, turn off the power. Immediately
press and hold the push-button switch
(SW1). Third, within 2 s, turn on the
power and confirm that the display
shows a flashing “P.”
From this point you can traverse the
different menu settings by quickly
cycling the on/off switch. Items in a
menu are selected by pressing the push
button. You can choose cell capacity
(100 to 2500 mAH), cell count (four or
five), and other features. Full details
are contained in the user guide.
The PIC16C63 firmware was writ-
ten in C using CCS’s PIC C Compiler.
It uses all but about a dozen bytes of
18
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
The PIC reads the two independent
voltage measurements and determines
if they are within safe limits. The bat-
tery voltage is measured at the
DS2438’s V+ and V– pins. The battery
pack is a low-impedance current
source, so the voltage drop is small
under the expected loads. However, if
the voltage is too low, the display will
report a U1 error (battery voltage low).
This can trap charge issues, cell fail-
ures, or serious current draw problems
from the servos.
The other measured voltage is on the
switched side of the RC system’s on/off
switch, complements of the DS2438’s
VAD input (pin 4). Because this meas-
urement is made on the RC receiver’s
load side, it will see a higher nominal
voltage drop. If it is excessive, a U2
(bad switch, weak battery, stalled
servo) or U3 (low battery voltage,
binding servo) error will be reported.
If any trouble is detected, the LED
status indicator will flash. This LED
can be installed on the PCB or
remotely mounted on the aircraft. It is
bright, so you should be able to see it
Photo 2—
Here's how the battery monitor looks
installed in the RC model helicopter’s cockpit. You can
use the BatMon on RC airplanes, cars, and boats too.
Or, you could adapt the design for battery monitoring
applications that aren’t RC-related.
the 40-KB code space. If you
wish to add features, you
should plan on upgrading to
a different MCU.
All of the important tasks
are performed by the real-
time kernel, which is done
by the
serv_jiffy() func-
tion (a simple task scheduler
that’s synchronized to
Timer 1). It has 50-ms resolu-
tion and can launch sequen-
tial tasks at periods up to
once per minute. It is called
from the main function in
order for the PIC’s sleep cycle
to easily utilize it.
Speaking of the sleep
cycle, when the equipment is
turned off, the PIC is shut
down after a few seconds of
being idle. The operating cur-
rents are reduced to ~180 µA
while in Sleep mode. To achieve this
low current, you must disable the
brownout fuse during chip burning.
During Sleep mode, the PIC wakes
up periodically to calculate the self-
discharge and charge correction values.
It is also during this period that it
checks to see if the RC power switch
has been turned on. If so, the PIC fully
wakes up, enables the display, and per-
forms all of the monitoring features.
The software is fully documented. It
will not be easy to dissect my code,
however, all of the information to do
so is in the source text. Given the size
of the program and some of its com-
plexities, I’m sorry to say that I will
not be able to answer specific questions
concerning the software’s C functions.
Besides, there’s no fun in being spoon-
fed all of the answers. So, just roll up
your sleeves and study the code.
The BatMon is not a good candidate
for perfboard construction. A big issue
is that RC models present a harsh
operating environment. Vibration and
less than pleasant landings demand
that you use rugged electronic assem-
bly techniques. My vote is that you
design a circuit board for it. It is not a
complicated circuit, so with the help
of a freeware PCB program you should
be on your way. My latest version used
nearly all through-hole parts. I could
have accomplished drastic size reduc-
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
19
SOFTWARE
To download the software and users
guide, go to ftp.circuitcellar.com/
pub/Circuit_Cellar/2002/143/.
SOURCES
PIC C Compiler
Custom Computer Services, Inc.
(262) 797-0455
www.ccsinfo.com
DS2438 Battery Monitor
Dallas Semiconductor, Inc.
(972) 371-4000
www.dalsemi.com
PIC16C63 Microcontroller
Microchip Technology, Inc.
(480) 786-7200
www.microchip.com
tions if I used the SMT components.
Please be aware that sloppy PCB
layouts may allow the 3.58-MHz
oscillator to radiate unwanted har-
monics. This could cause interference
with RC receivers. Lastly, the current
sense resistors’ accuracy can be com-
promised if you are not careful how it
is connected to the DS2438. You can
expect inaccurate capacity values if
the sense line traces are in the cur-
rent carrying path.
The connections to the battery pack
and receiver are made with standard
RC hobby servo connectors. They are
available at most RC hobby shops. You
will need a 22-AWG, two-conductor
female cable for the battery (J1), a 22-
AWG, two-conductor male for the RC
switch (J2), and a three-conductor (any
AWG) for the Aux In (J3) connector.
Please note that the battery cables are
heavy-gauge to minimize voltage
drops. Keep them short (less than 6
″
)
and strain relief all cables at the PCB.
I found that large heat shrink tub-
ing makes a robust enclosure for the
finished unit. The tubing I used is the
type that is designed for RC battery
packs. It is low cost and is sold by the
foot at most hobby shops that special-
ize in RC cars. You can also use the
heat shrink tubing that is sold as cov-
ering material for the main blades on
RC model helicopters.
Thomas Black designs and supports
high-tech devices for the consumer
and industrial markets. He is currently
involved in telecom test products.
During his free time, he can be found
flying his RC models. Sometimes he
attempts to improve his models by
creating odd electronic designs, most
of which are greeted by puzzled
amusement from his flying pals
.
All you have to do is cut
small holes for the three
cables, slide it on, shrink
it, and then trim some
openings for the LED’s and
switch. With some addi-
tional trimming, I can cre-
ate flaps on the open ends
that are easily bent down
and glued in place. The fin-
ished unit is protected
from field dust and it’s also
moderately fuel proof (glow
fuel is very conductive).
The finished unit is
mounted in the model’s
cockpit using double-sided
tape or held with rubber
bands (see Photo 2).
As you can see, there is a
high-tech solution to moni-
toring your RC battery
packs. If you’re still sold on
the old-fashioned voltage method, be
my guest to continue the practice.
But, holy cow! With the BatMon,
there is a better way.
I
64-bit S/N
and 1-Wire
control
Disconnect
sense
Temperature
sensor
To host
DQ
1-Wire
V
DD
V?
Oscillator
Voltage
A/D converter
Current
A/D converter
)
R
SENS
C
F
+
VSENS-
R
F
GND
VSENS+
V
DD
V
AD
V
REG
8-byte
SP (00h)
8-bit CRC
8-byte
SP (01h)
8-bit CRC
8-byte
SP (02h)
8-bit CRC
8-byte
SP (03h–07h)
8–bit CRC
Temperature
register
Battery/general
voltage register
Battery current
register
Threshold
register
RTC
register
Offset
register
(DIS) Connect
register
40-byte non-
volatile memory
Current
accumulators
Control logic
DS2438
Figure 3—
The Dallas DS2438 was designed for battery fuel gauging of low-cost con-
sumer products. It records current consumption and has an assortment of other fea-
tures to support battery-powered applications. The data stored in registers is
accessed via the Dallas one-wire bus.
20
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
iscriminating
engineers appreci-
ate finishing touches.
Electronic speed control
is an important add-on feature for
projects that incorporate DC motors.
Imagine driving a vehicle in which the
only speed control you have is either
keeping your foot off the brakes or
putting the pedal to the metal, no in-
between. City driving would be diffi-
cult—precision cornering, maneuver-
ing, and providing a smooth ride to pas-
sengers would be impossible. It’s now
obvious why so much value is placed
on methods of speed control. This arti-
cle will explore one such method, the
Open Source Motor Controller (OSMC)
project. The OSMC project provides
electronic speed control for a direct
current permanent magnet motor. A
complex subject made easy with step-
by-step instructions and pictures so
that you can build it, too.
I must admit that I used an OSMC
board to gain a competitive edge in
combat robot tournaments. This appli-
cation is in fact the reason why the pro-
ject’s original founders began develop-
ing it. You can use the electronic
speed controller in a variety of applica-
tions, however, the OSMC project was
developed with the needs and require-
ments of fighting robots in mind. The
result is a reliable, high-power, low-
cost speed controller that you can build.
OSMC INTRODUCTION
The OSMC project was developed
using the open source concept in an
online forum to directly assess the
need for an affordable, high-quality,
robust electronic speed controller.
Several people of varying experience
and expertise came together to impart
their knowledge and ideas for its
development. Using opinion polls to
select the most appropriate compo-
nents and posting schematics for
review and comment allowed the proj-
ect to swiftly turn into a successful
prototype in August 2001.
Interest in the project grew on the
Internet. People from across the globe
were interested in incorporating this
electronic speed controller into their
projects, ranging from remote-con-
trolled cars, boats, and, the most popu-
lar, fighting robots. If you would like
to participate, have any questions or
comments, or would like to speak
with other enthusiasts, feel free to join
the online message board. On the
OSMC official web site, you’ll also
find free schematics, PCB layout(s),
project documentation (includes
assembly instructions), and photos.
SCHEMATICS
The OSMC circuit follows the com-
monly used H-Bridge form. There are
four legs, which allows current to flow
through the motor in two different
directions. The blue arrows indicate
the current flow direction through the
circuitry of Figures 1 and 2.
The direction of current flow in DC
motors dictates the rotation of the
rotor either clockwise or counter-
Extreme OSMC
d
Whether you’re a
Formula One racer or
commuter weaving
through rush-hour
traffic, speed control
is a concern. Brakes
alone won’t suffice, so
you need a motor that
pitches in. With this
step-by-step guide,
you can tailor Sonny’s
OSMC project for RC
cars, boats, or robots.
Sonny Lloyd
ROBOTICS
CORNER
Control
signal
Motor
Control
signal
Control
signal
Control
signal
Battery
GND
Figure 1—
When these opposite MOSFETs are on,
they allow current to flow through the motor from posi-
tive to negative.
Part 1: Open Source Motor Control
Project
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
21
following design techniques. The first
method is to connect four MOSFETs
per leg in parallel. In this manner, the
source current is forced to divide into
four equal currents (the actual current
per MOSFET will differ slightly because
of the individual variation of its inter-
nal resistance, which occurs naturally
in the manufacturing process). One
side effect of parallel MOSFETs is the
increase in gate capacitance as seen by
the HIP4081A. The incoming signal is
forced to charge the now greater gate
capacitance first, which could potential-
ly slow the signal propagation signifi-
cantly. This negative effect, however, is
nullified by the ability of the HIP4081A
to provide fast gate charge pump action.
The particular choice of MOSFET
used also plays an important factor in
maintaining current carrying capabili-
ties. The IRF1405 is rated at 169 A con-
tinuous, but the package maximum for
the TO220 is approximately 75 A. [2]
So, when you calculate 75 A multiplied
by the four MOSFETs per leg, the result
is a maximum continuous current of
300 A. But this is misleading. The
MOSFETs can handle this current, but
the real problem is the ability of the
device to efficiently dissipate heat. If
the MOSFETs get too hot they will
simply melt. For this reason, you’ll
find a recommendation in the OSMC
assembly notes to mount heatsinks on
each MOSFET as shown in Photo 1.
Caution is still important though.
Photo 2 shows the finished OSMC
board with an electric fan mounted to
provide adequate cooling airflow.
clockwise. Thus, one OSMC board can
easily provide forward or reverse
movement if, for example, the motor
is connected to a wheel.
At the heart of the OSMC board is
the HIP4081A bridge driver chip made
by Intersil. [1] This chip is a monolithic
full H-Bridge driver chip that includes
both high-side and low-side FET drivers
and provides voltage boost capability.
The HIP4081A can accept main battery
voltage from 12 to 80 V and generates
all needed signals and voltages required
to drive the H-Bridge (see Figure 3).
As you can see, the HIP4081A has
four inputs that correspond to the out-
puts used to switch each leg of the H-
Bridge. An additional disable output is
not shown in Figure 3. The digital sig-
nal source must provide the PWM sig-
nals to the HIP4081A inputs in order
to drive the bridge.
The input lines of the HIP4081A are
modified TTL, in that a high-level sig-
nal is any voltage between 3 and 12 V.
This allows a wide variety of signal
sources to be used to drive the chip.
The nature of the n-channel MOSFETs
used in this high-power H-Bridge cir-
cuit requires that the bridge driver
must provide approximately 10 V
above the positive voltage source into
the gate of the high-side MOSFETs to
turn them on. The HIP4081A can pro-
vide up to 90-V drive voltage on the
high-side outputs AHO and BHO. It
does this through a capacitor switched
charge-pump subsystem. Using only
an external diode and capacitor, the
HIP4081A generates the required volt-
ages to drive the high-side MOSFETs.
We should now take a closer look at
one of the legs of the OSMC. The four
legs were designed for reliability and
high-current capacity, two important
factors necessary for combat robots.
Figure 4 shows a portion of the OSMC
schematic. The gates of MOSFETs such
as those used here are sensitive to high
and low voltages. A few volts too high
or low even for an instant can destroy
the MOSFETs. To protect the gates of
the MOSFETs, the Zener diodes (D2
and D4) are added to the circuit in order
to clip both high and low voltages.
The gate of a MOSFET acts like a
capacitor, therefore, voltage spikes may
be generated while rapidly charging or
discharging the gate capacitance when
switching the transistor. These are a
result of the dI/dt effect of a rapidly
changing current. Thankfully the Zener
diodes clip these transient voltages,
which protect the gates. The Schottky
diodes, D16 through D19 work in con-
junction with the series gate resistors,
R2 through R5. The Schottky
diodes allow the gates to
discharge (or turn off) rapid-
ly, while the resistors slow
the turn-on time of the
MOSFETs. They are both
used to ensure that the
MOSFETs of opposite legs
are not turned on simultane-
ously. Note that a condition
known as “shoot through”
would occur if the high side
or low side were on simulta-
neously, which could severe-
ly damage or destroy the
OSMC board.
One of the shining features
of the OSMC board is its abil-
ity to effortlessly handle high-current
demands. A stalled DC motor can eas-
ily draw outrageous amounts of cur-
rent, sometimes in excess of 200 A!
This fact becomes a serious considera-
tion when designing for combat robots
because they are often pushing each
other face to face, in other words, their
motors are presented with an infinite
load. As simple motors, this sudden
maximum load will cause a locked
rotor situation, thus drawing copious
amounts of current. The OSMC can
handle these high-current situations.
CAPABILITIES AND PROTECTION
The OSMC is capable of passing
large currents through its components
and 4-oz copper traces because of the
Control
signal
Motor
Control
signal
Control
signal
Control
signal
Battery
GND
Figure 2—
Unlike what you see illustrated in Figure 1,
these opposite MOSFETs allow current to flow through
the motor from negative to positive when they’re
turned on.
Figure 3—
The HIP4081A not only controls the PWM of the OSMC
board, but also provides some necessary circuit protection and circuit
performance improvements.
22
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
By paralleling four MOSFETs, attach-
ing individual heatsinks, and mounting
a cooling fan, you have taken several
steps in the right direction to increase
the maximum continuous current draw
ability. It’s difficult to say exactly
what the maximum continuous cur-
rent rating is because of the many
variables. Given this, the OSMC
design group feels relatively confident
in claiming that the OSMC can easily
support high-current applications, in
the range of 100 A and greater. All
mathematical calculations, quality
control tests, and practical implemen-
tations support this conclusion.
Other areas of concern are the possi-
ble voltage spikes coming from induc-
tive loads (such as DC motors) and
high-frequency noise from brushes and
commutators. These issues were seri-
ously considered during the design
phase. The OSMC handles these with
devices called transient voltage suppres-
sors (TVS). The TVS devices can be con-
sidered “super” Zener diodes. They are
optimized to handle high-current volt-
age spikes safely. They are connected
across the battery terminals in order to
clip the voltage spikes and protect the
MOSFETs from voltages exceeding their
drain to source breakdown limits.
Additional protection from high-fre-
quency spikes coming from the motor
brushes and commutators is provided
in the form of an RC-Snubber network
across the motor leads. This is formed
by a series connection of a low-value
resistor and a small, high-frequency,
polyester capacitor. Finally, gross fil-
tering of the supply voltage is done by
large electrolytic capacitors.
The rest of the circuitry on the
OSMC board is dedicated to providing
a stable 12-V source to the HIP4081A,
and is handled by an LM2574-HV12
voltage regulator. This
chip is a step-down
switching regulator,
which provides much
higher efficiency
when dropping high
battery voltages
down to 12 V than a
linear regulator. The
LM2574-HV12 also
supplies 12 V off-
board through the
interface connector to the digital logic
driver circuit. This eliminates the need
for a secondary power supply for the
microcontroller or other logic source.
Each of the components involved
has its own operating voltage. The
range of allowable voltage applied to
the OSMC board should be between
12 and 50 V. This will allow all of the
parts to receive sufficient power while
not exceeding their maximum rating.
For a more detailed look into the
circuit, its protection schemes, expla-
nation, and capabilities please refer to
the OSMC web site.
FUTURE CONSIDERATIONS
The development of the OSMC is an
ever-evolving project. Part replacements
and improved design ideas are some of
the many suggestions you will find
posted on the OSMC message board.
For example, the suggestion of direct
current limiting techniques as a safety
precaution for the board surfaced on the
message board. Another active topic
regards modification so that the project
can handle even more power (a heavy-
duty board capable of delivering 500 A-
plus to a load). Perhaps in the near
future these features will be developed
and added to the OSMC project.
READY FOR PART 2
As you have read, the open source
motor controller provides your elec-
tronics project with a high degree of
reliability, robustness, and protection.
These qualities will give a distinct
advantage for any competitor in the
highly popular fighting robot challenges
or it can be used industrially because of
its high level of reliability and power
consumption capability. Either way you
look at it, the OSMC is a valuable con-
tribution to any project that requires a
Figure 4—
Putting MOSFETs in parallel provides increased capacity to carry
current. You can see one leg of the H-Bridge (OSMC) in this illustration.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
23
high-performance, low-cost electronic
speed controller. A lot of time and
effort was spent on making this board
as robust and reliable as possible. Some
of the protection components may
seem excessive or unnecessary, but
experience has shown them to be
needed for reliable operation under the
extreme conditions of robot combat.
As complex as the OSMC board may
sound, it is still considered a “dumb”
controller. It merely accepts PWM sig-
nals at the inputs of the bridge driver
circuitry and controls the on and off
states of the four legs as requested. The
intelligence to convert the speed com-
mands into these required PWM signals
is provided by an external source—a
dedicated microcontroller, PC, or even
a multitude of home-made methods.
In our case, the modular OSMC brain,
or MOB for short, provides the essen-
tial brains of this electronic speed
controller. When I return next month
with Part 2, I will explain how the
MOB interfaces to the OSMC and thus
completes the reliable, high-power,
low-cost, do-it-yourself package.
I
Photo 1—
A populated OSMC board with heatsinks
attached to the IRF1405 MOSFETs provides increased
heat dissipation ability.
Photo 2—
A cooling fan attached to the metal stand-offs
increases the heat dissipation ability of the OSMC board.
REFERENCES
[1] Intersil Corp., “HIP4081A
80V/2.5A Peak, High Frequency
Full Bridge FET Driver,” 3659.5,
November 1996.
SOURCES
HIP4081A Bridge driver chip
Intersil Corp.
(949) 341-7000
www.intersil.com
LM2574-HV12 Voltage regulator
National Semiconductor Corp.
(408) 721-5000
www.national.com
Official OSMC project site
groups.yahoo.com/group/osmc
Sonny Lloyd graduated with a BS in
Electrical Engineering from Ryerson
University in Canada. While attend-
ing university, he worked a 16-month
internship at Siemens Westinghouse
Power Corp. He hopes to win top
rankings next year with his OSMC
project in local and international
robotics competitions.
[2] International Rectifier,
“Automotive MOSFET IRF1405,”
PD-93991A, March 25, 2001.
The Texas Instruments Ultra-Low Power Flash MCU
MSP430 Design Contest has come to a close and it
proved to be another great opportunity for designers from
around the world to showcase their talents. Thirteen countries were repre-
sented among the entrants and the projects ranged from practical everyday devices to unique
industry-specific solutions. The quality of the entries once again put our judging team to the test
and below you will find photos and abstracts from all of the top designs. All contest entrants are
invited to submit articles on their projects, so keep an eye on the print magazine in the months
to come for in-depth articles on some of the projects you see below. Thanks to everyone who
participated for making the TI MSP430 contest a successful venture!
Ultra-Low Power Flash MCU
MSP430 Design Contest
Winners
Announcement
1st Place—Tiny Guidance Engine—$5000
Tom Hynes & Jim Hynes
California, USA
tomhynes@pacbell.net
jhynes@socal.rr.com
This project uses the TI MP430f149, MEMS inertial and magnetic
sensors, and a GPS receiver as a general-purpose guidance engine
for military and commercial applications. Over the last few years,
MEMS inertial sensors (accelerometers and angular rate sensors)
have experienced rapid advancement. The improvements were driven
by the commercial market, which is composed primarily of the automo-
tive and military industries. With support from the Army through the
SBIR (Small Business Innovative Research) program, we started build-
ing a low-cost IMU (Inertial Measurement Unit) with commercial
grade MEMS sensors and a microcontroller.
Traditional IMUs with spinning wheel or laser gyros
typically cost at least $20,000. The strapdown
IMU task is to digitize the analog output
of the sensors, apply calibration fac-
tors, and integrate once to provide
change in angle and change in veloci-
ty (
∆Θ
,
∆
V) of the platform over a pre-
cise time interval, typically 100 Hz. These
measurements are used by other avionics
modules to navigate the airplane or missile.
We then realized that the chosen TI MP430
had enough integrated peripherals for the entire
guidance task. This guidance engine can steer a
missile, UAV, or guided bullet to any point in space.
The tennis computer is a small device that a tennis player
wears on his wrist to collect match statistics during play. It is
about the size of a wristwatch, has five buttons for data input,
and an array of LED lamps to display the score. After play he
uses a cable to connect the tennis computer to a PC and
downloads the match statistics. There is an application on the
PC that stores, displays, and analyzes this data.
There were several important requirements that had to be
met for the project to be successful. For starters, the device
had to be extremely low-cost, lightweight, and durable. Five
buttons are required for data entry and a low-cost data display
system was needed.
The Tennis Computer is battery operated with excellent bat-
tery life. Battery life should be at least three months under nor-
mal operation (defined as three matches per week). It needed
to have nonvolatile data storage for retaining match statistics
when the device was not in use. The device is sealed and
water-resistant, and provides an RS-232 link to allow data
dumps to a PC.
Ultra-Low Power Flash MCU MSP430 Design Contest
2nd Place—Automatic Blood Pressure Meter—$2000
The meter is intended for systolic, diastolic pres-
sure, and pulse rate measurement in medical insti-
tutions and at home. It does not require any spe-
cial skills for the user and may be used for self-
measuring. Ten recent measurement results are
stored in internal archive. The device can work
under PC control transferring internal tables and
signal samples for analysis and algorithm
improvements.
Between measurements the device stays in Low Power
Mode 3 (consumed current is less than 10 µA). When the
I/O button is pressed the MCU wakes up and prepares for
measurement. It displays the LCD test and then maximum
pressure, which should be 30-40 mm hg higher than expect-
ed systolic pressure. Then the meter goes to "ready to
measure" mode, indicated by a buzzer.
The cuff must be placed around the user's hand and con-
nected to the meter via the attached air tube. During meas-
urement the LCD displays current pressure value. The air
compressor inflates the cuff up to specified maximum pres-
sure and stops. Air steadily goes out through the vent hole.
The MCU samples the pressure sensor signal and extracts
instantaneous pressure changes caused by blood pulses.
Each detected pulsation is indicated by a blinking heart icon
and a buzzer sound. Simultaneously, the pulse rate is meas-
ured. At pressures below diastolic, the measurement stops
and pulsation parameters are used to calculate systolic and
diastolic pressures. If maximum pressure appears insuffi-
cient, it’s automatically incremented by 40 mm hg and the
measurement cycle is repeated.
The user can view archive data by pressing and holding
the I/O button. The Start button scrolls through the archive.
Pressing and holding the I/O button once more cancels
archive reading. The device is turned off by shortly pressing
the I/O button. Also, it automaticallly shuts off after no but-
tons are pressed for 3 min.
2nd Place—
Tennis Computer
—$2000
Greg Fisher
California, USA • skinnyd@onebox.com
A. Britov, V. Zakharchenko, V. Lomakovsky,
A. Makeenok & S. Khlebnikov
Kiev, Ukraine • dsplab@cad.ntu-kpi.kiev.ua
Visit www.circuitcellar.com/msp430 for more info
Design contests are excellent for
opening the mind for special ideas.
Without any pressure from customers,
bosses, or other hindrances of the daily
grind, you can work on a variety of
splendid projects. The result of such an
idea is SOPHOCLES, which stands for
SOlar Powered Hidden Observing
VehiCLE(S). SOPHOCLES is a robot, a
very small system designed for watch-
ing. Its detector looks for poisonous
gases or sticky air. Then, the motors
bring the robot to the area, the built-in
camera shows pictures of these dan-
gerous areas, and his radio gives you
information about the detected materi-
als. Furthermore, you can control the
robot and how the solar cells spend
power for missions that require low-
power intermittent operation over the
course of many weeks.
The robot has two main operation
modes, autonomous and command
modes. The first mode is powered by
the implemented artificial intelligence of
each robot. The robot works independ-
ently, checks air quality, and gives a
signal if any difference has occurred.
The second mode is command mode.
In this mode, the robot is controlled by
an operator. The operator sends direc-
tional commands to the robot, such as
left, right, go ahead, go back, and such.
Of course, the operator can take pic-
tures with the built-in camera. Short pic-
ture sequences can be saved as an
animated slide show for documentation
purposes.
Jens Altenburg
Soemmerda, Germany
jens.altenburg@t-online.de
The impetus for this project was that
local paraglider pilots wanted a cheap
and maintenance-free weather station
that could tell them about the current
wind condition at their favorite flying site.
They had access to a PSTN line at
the clubhouse by the landing field. The
take off is on a mountaintop 300 m
above the landing. A mobile phone
weather station was considered but it
needed an expensive solar cell to
charge the backup battery. It is also
more expensive to call a mobile phone
than a PSTN telephone.
The solution was to use the PSTN
line and have two units, both based on
a MSP430F148, and a wireless link
between them. The first unit (TX unit) is
placed on the mountaintop. It consists
of an MSP with some additional elec-
tronics, a Davis anemometer, a battery,
a cheap solar cell, and a walkie-talkie
(27 MHz AM) transmitter. The second
unit (RX unit) is placed inside the club-
house and consists of a board with an
MSP, a telephone answer machine, a
walkie-talkie receiver, and an AC adapter.
The TX unit logs the wind speed and
direction for the last 15 min. Every 30 s
it turns the transmitter on and sends a
FSK encoded 13-byte package to the
receiver at a speed of 300 bps. The
quality of the package is ensured by a
CRC-16 word, which is checked at the
receiver end. The package consists of
sun intensity and maximum and mini-
mum wind direction and speed (present
and mean values).
In this project, the green chipset
TRF6900/MSP430 is used to improve
the ease of use of IrDA-enabled
devices. An ISM/IrDA repeater is built,
which extends the possible range
between two IrDA devices to around
10 m. In addition, the new link does not
require a line of sight between the two
devices anymore.
The two most important disadvantages
of common IrDA connections are elimi-
nated! The heart of the application is
the low-power microcontroller MSP430
and the transceiver chip TRF6900.
The data received at the IrDA trans-
ceiver is processed in the communica-
tion stack of the MSP430 and sent over
the air to the other peer. The communi-
cation protocol implemented on the
MSP430 is capable of correcting up to
six bit errors within one data frame (6
bytes with Golay(23,12). In addition, the
implemented frequency hopping allows
to use 31 channels within the 868-MHz
ISM band. Interruption caused by fad-
ing or other users are significantly
shorter or do not appear. The integrated
DDS of the TRF6900 is a key compo-
nent for the realization of this frequency
hopping application.
3rd Place
—$1000
SOPHOCLES
Arne Jan Dahl
Hommesaak, Norway
ajdahl@online.no
Reto Bucher & Marcel Wattinger
Bubikon, Switzerland
rbu@elektrobit.ch &
mwa@elektrobit.ch
3rd Place
—$1000
Wireless Weather
Station with Voice
Synthesis
3rd Place
—$1000
ISM-IrDA
Repeater
Ultra-Low Power Flash MCU MSP430 Design Contest
Visit www.circuitcellar.com/msp430 for more information
Vessel Microcomputer Network
Glen Worstell
Oklahoma, USA
worstelg@earthlink.net
There are many applications for small networks of micro-
computers, including home automation, boats, trucks, and
factory floors for process control and data collection. This
project describes the design and implementation of the
Vessel Microcomputer Network (VuN), a general-purpose,
low-cost system for connecting multiple micros and trans-
ferring data among them. VuN is currently in use on the
author’s 36¢ sailboat, where it is used to collect and display
information about fuel and water levels, engine information,
GPS position and tracking information, and other parame-
ters. Node power is essentially zero when using MSP series
microprocessors, except during periods of data transmis-
sion, when the average current is about 1.5 mA. In this
application, the network is idle most of the time, and it often
operates on battery power. There is no reason why VuN
could not be used in applications where low power is not a
requirement.
Universal Meter
Giuliano Corticelli
Padova, Italy
gcorticelli@libero.it
This project describes measurement instrumentation,
designed for voltage and current measurement in the indus-
trial low-power range (up to ~30 KW). The Universal Meter
controls the operation of a stabilized power supply or battery
charger. It has a set of analog and digital inputs. The meter
can measure the true rms value of a 1-AC voltage source
(obtained generally from a voltage transformer), 1-AC cur-
rent source (obtained from a 50-Hz T.A.), three DC-current
floating photo-coupled sources (one allowing positive and
negative measurement), three DC-voltage common negative
sources, two temperatures in the 0–150°C range. The meter
can also monitor four digital inputs for alarms and/or status
signalling. In Editor mode, the software permits using only
three keys to associate a 10-character string name to every
inputs (e.g., the VAC input could be “Line Volt.”). A four-row
presentation string is fully programmable too, including the
possibility to declare a VDC input as a battery input for moni-
toring charge status.
Intelligent Tire Inflator
Kirt Weakman
Michigan, USA
kirt_w_weakman@email.whirlpool.com
This application describes a compressed air tire inflation
system using the MSP430F1121 MCU. The system is able to
read the pressure of a tire and control compressed air in
such a manner that you are able to select the desired infla-
tion pressure. Some of the technologies used in this applica-
tion are: MSP430 RISC MCU, LCD, Staco 1 × 4 keypad,
piezo beeper, Clippard low-voltage solenoid, pressure sen-
sor, and power management for battery operation.
The SEAL
Doug Varney
Maryland, USA
info@seapuppy.com
The SEAL is intended for used by mountaineering and ori-
enteering groups that may require GPS capability. With the
GPS activated, the UTC time, latitude, and longitude will be
shown. Compass bearing is provided by a magnetometer, as
GPS will not give reliable bearing data if you’re not moving.
The unit can function without the GPS. Barometric pressure,
which can be converted to altitude, is displayed in millibars.
Honorable Mentions
Because temperature is a component of the pressure com-
pensation, it too is available in centigrade format. The SEAL
operates on two AAA batteries lasting many hours.
Card Access Control Project
Integrated Electronics Systems Development Team
Kuala Lumpur, Malaysia
ies@tm.net.my
This single door, stand-alone system uses two MSP
processors. The need for a second processor (MSP1101)
allows the locking mechanism to be place in a safe area
away from possible tampering. The MSP135 has the five
functions. First, it can accommodate 512 card users with a
personal identification number in the MSP’s flash memory.
Each card number consists of six digits and the PIN consists
of four digits. Second, it can determine the weekday based
on day, month, and year information (Note: functions related
to category and timer setting depend on weekdays.) Third,
the Enable/disable PIN mode is based on category and timer
setting and allows the system to determine if a PIN is
required when a valid card is read. Fourth, the system can
lock/release the door based on the category and timer set-
ting. Fifth, it reads and interprets Weigand information sent
from a Weigand card reader. This partially interrupt-driven
function reads and interprets Weigand code to form the card
information. Weigand code transmitted from the reader is 42
bits but only the first 26 bits are used. The Weigand card
reader uses a MSP430F1101 (details of its operation cannot
be revealed under the nondisclosure agreement). The
Remote Lock Unit MSP1101 can communicate with the
MSP135 via a software UART using the 422 communication
standard, interpret data sent to determine the action taken,
and be fitted with two relays for lock and alarm. It has a ded-
icated trip wire to detect tampering on the communication
wire, and uses a random unique ID system to ensure com-
munication to the correct MSP135. (Another main unit with-
out proper setup will not communicate to Remote Lock Unit.)
TeHuMet—Temperature-Humidity Meter
Dubravko Gacina
California, USA
dgacina@yahoo.com
This project outlines the principle of operation of a digital
thermometer and humidity meter design. The measurement
is done using slope ADC capabilities of the timer port mod-
ule on the MSP430F413 microcontroller. This project contains
information on how to position the ultralow-power capabili-
ties, an on-chip LCD driver, and other peripherals of
MSP430F4xx family of microcontrollers in battery-powered,
ultralow-power designs.
The PDA²-430 (Programmable Digital to Analog Assistant
with MSP-430)
Bruce Pride
New Hampshire, USA
bpride@monad.net
The PDA
2
-430 is a hand-held, battery-/DC input-powered
DMM. It combines a useful power supply and multi-meter
functions into one unit. I chose functions that could be the
most useful while developing and debugging the electronic
control-based systems. The user interface and LCD provide
an easy-to-use menu-driven interface to control the power
supply and DMM functions. The power supply is digitally pro-
grammable from 0 to 30 V in 0.5-V increments. This range
satisfies the voltage requirements of many devices like
breadboard circuits, circuit board assemblies, and sensors.
The DMM functions consist of a continuity tester and a logic
probe. The continuity tester provides basic point-to-point
testing for verifying device nets like PCB board traces and
cable/harness assemblies. The logic probe verifies voltage
levels greater than or equal to logic levels and can even
detect switching at lower frequencies.
GSM Interface Module
Karoly Horvath
IntPecs, Hungry
horikari@kiwwi.hu
In most offices (and homes) there is a security system and
an alarm panel that can report the changing of status (e.g.,
open/close, burglary/fire, restore), if the telephone line is avail-
able. If not, then the Central Monitor Station (911) does not
receive any information from the customer. The problem with
this system is that the telephone line may be problematic, may
get cut off or short (technical problems caused by supplier or
burglar), or the CMT is busy (the bottom line equipment cost
is too high). By adding a GSM reporting capability to the
existing system there are no more wiring problems and sys-
tem enlarging (establishing) cost is lower for the CMT.
Additionally, the customer is able to call their GSM partners
through the same phone for the home network price.
Trail Counter Sensor System
Lien Dayman
Colorado, USA
toizzz@hotmail.com
The Trail Counter Sensor (TCS) is a device that counts
the number of people/animals that traverse a hiking or gam-
ing trail. The basic principle used to create detections is the
concept of breaking an infrared beam. Each TCS unit con-
tains both the transmitter and receiver hardware. By setting
one TCS unit as the transmitter and one for the receiver,
detections over 80¢ are easily achieved. In addition, accura-
cy problems associated with aiming to a reflector are elimi-
nated. Data download and system setup are achieved using
the Trail Counter Handheld (TCHH). The TCS uses the
same infrared receiver and transmitter used for detections to
communicate with the TCHH unit. Data is accessed using
the same infrared transmitter and receiver used for detec-
tion. This is possible using the MSP430’s UART to do half-
duplex communications. A hand-held data collection device
(another MSP430 device) sends commands to the sensor
and downloads data from it for immediate viewing or later
uploading to a PC.
Portable MP3 player
Jeff Pollard
California, USA
xylotex@hotmail.com
This simple design creates a small, hand-held, battery
operated, portable MP3 player using an MSP430F123 for
overall system control, a MultiMediaCard (MMC) for data stor-
age and VLSI’s VS1001K chip for MP3 decoding and sound
amplification. Two 1.5-V AAA batteries are connected in
series to give a raw voltage of 3 V (nominal). This is fed into a
voltage booster that creates 3.3 V from input voltages as low
as 1.2 V. The boosted voltage is then routed to a semiconduc-
tor power switch. This power switch is controlled via software,
and is enabled after the microprocessor is reset, and shut
down at power-off. The initial start-up voltage is conducted via
a user pressed on button, which enables the voltage booster
to supply operating voltage to the microprocessor. After being
powered by the manual button, and subsequently running, the
microprocessor then enables the power switch, after which the
user button may be released. The M430F123 processor has
8 KB of regular program flash memory and 256 bytes of data
RAM. It also includes several built-in peripheral devices,
including the SPI, UART, a 16-bit timer, and a voltage com-
parator. Also used are several digital I/O lines.
28
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
ast month, I
described the
design and assembly
of my own animation
system. This month, I plan to demon-
strate how the system works, specifi-
cally the PIC firmware, and how it
may be modified for various DIY and
commercial motor controllers men-
tioned in Part 1. In addition, I’ll
explain other potential applications
for the animation system.
Walt Disney was known for his
superbly animated cartoons and fea-
ture films, but he was also a pioneer
in animation and puppetry. You can
see exhibitions of his work at
Disneyland and Epcot Center. I’ve
always been fascinated by the lifelike
figures. My interest in animatronics
began as a child when I was intrigued
by the realistic figures at many of the
rides at Disneyland in California.
Even more sophisticated animations
were to be found at Epcot Center. The
natural movements of the Pirates of
the Caribbean chasing each other with
verisimilar expressions, the 999
ghosts in the Haunted Mansion, and
the fierce Tyrannosaurus Rex at Epcot
Center all had me asking repeatedly,
“How did they do that?”
Years later, I realized the magic was
made with actuators from servos,
relays, stepper motors, and DC motors.
The servos are the same powerful RC
servos used by model RC airplane
builders. I also discovered that Disney
uses CD players or tapes for storing
their complex motion programs
encoded with music and soundtracks
for playback with a special decoder.
These systems are not entirely unlike
the player pianos of the last century.
RE-ANIMATOR
With my Hero I robot, which is just
one test platform for my animation
system, I could save only short anima-
tions, because of limited memory and
obsolete electronics. But this situation
has improved with the recent addition
of my sensor controller board. [1, 2] I’d
like to increase the Hero I robot’s abili-
ty to remember maneuvers and perform
complex movements, including navi-
gating rooms and picking up small
objects with its 6-DOF arm shown in
Photo 1. The compact joystick con-
troller board described in Part 1 of this
series should allow it to function with
the older Hero I electronics, to pro-
duce a research-quality robot.
There are many animation projects
that can be done with toys such as the
RC cars sold at Radio Shack. I was
able to purchase a slightly damaged
Radio Shack RC truck for about $15
and an RC racing car for $10 just after
Christmas. I also purchased a toy
R2D2 robot that needed minor repairs
and a small Lost in Space toy robot,
both of which I plan to modify for use
with the controller. A Radio Shack
Armitron robot arm or the OWI robot
arm kit, are also future candidates for
use with the animation system.
Laser light shows are another poten-
tial application that would require
special hardware, such as a Galvo and
a music decoder to synchronize the
show with the music. If a programma-
ble relay driver card is used, props
that use solenoids or relays for actua-
tors (e.g., train set drawbridges and
muscle wire actuators for robotic
hands) can be animated.
Virtual reality applications can be
carried out by applying some of the
technologies described in this article
Behind the Scenes
l
Last month, Daniel
described the design
of his DIY animatron-
ics project, which
involved a controller
board, motors, con-
trollers, sensors, and
a host robot. In this
article, he demon-
strates how his sys-
tem works and how
you can use it in your
own animation project.
Daniel Ramirez
ROBOTICS
CORNER
Part 2: Software Control
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
29
vide a DIP switch (S3) to allow the
user to select a specific address for the
SERVO84 board when more than one
board is being used. Photo 2 shows the
suggested component layout. Note
that the address switches and the 5-V
power supply sections are optional.
The switches may be hardwired to a
specific address and the 5-V supply
can be from an external source.
The 6-V RC servo power supply
should be isolated from the 5-V digital
power supply, although I have used the
6-V supply to power the 78L05 voltage
regulator with some success in my
AntiqueBot. Doing this eliminated the
need for a 9-V battery. The downside is
that voltage spikes may cause the RC
servos to malfunction sporadically.
JOYSTICK SOFTWARE
Let me illustrate how easy it is to
use a joystick controller using my my
GardenBot robot as an example. First, I
move the Record switch to the on posi-
tion and the red Record LED lights up.
Next, I start moving the robot around
the yard using the joystick to control
the robot’s speed and direction and
making it move around my front yard
using a simple trajectory, returning to
its original position. When the robot is
back at the starting point, I move the
Record switch to its off position.
Now, I move the Play switch to its
on position, thereby
lighting the green Play
LED. The GardenBot will
attempt to make the
same journey as before
by reproducing the same
moves, except that tire
friction and other
mechanical errors start
to creep in and it falls
short of its goal. Of
course, it works better
on smooth surfaces such
as a driveway. It will try
to repeat the same moves
indefinitely until the
Play switch is moved to
its off position. A toggle
switch or push-button
switch may also be sub-
stituted for the on-board
animation switches with
minimal modifications
along with the new class of Stamp-
sized web servers that are now avail-
able from companies such as NetMedia
(www.siteplayer.com). Using a Mattel
Power Glove or similar input device,
two people can send motion commands
to destination sites in the form of
Internet TCP/IP data packets in order
to carry out a virtual handshake. [3]
NASA pioneered many of these meth-
ods for deep space and interplanetary
exploration, and now these methods
are used for remote medical applica-
tions, artificial limbs, and even remote
monitoring of a home or business.
PIC PROGRAMMERS
A PIC programmer such as the
Warp13 or PICSTART and a UV eraser
are needed to program the animation
system firmware into the PIC18C452.
Soon there will be a new version, the
PIC18F452, that is flash memory-
based and will not require a UV eras-
er. Instead, it will use in-circuit pro-
gramming (ICSP). This arrangement
will greatly improve productivity and
reduce the cost of using these devices.
Programming and Customizing
PICmicro Microcontrollers
, by Myke
Predko, gives clear explanations of the
various programmers available for the
PIC, and is a fantastic reference for
PIC programming. [4] He provides his
examples in PIC C and PIC assembly
language. He also included
applications that use RC
servos and DC motor con-
troller H-Bridge circuits.
He currently has a robot
kit for sale at the Barnes &
Noble bookstores that
looks like it might work
with my animation sys-
tem using IR protocols.
David Tait, who was
one of the first people to
design an inexpensive
PIC programmer, has pub-
lished numerous articles
about a DIY PIC16F84
programmer that is easy to
build. With his easy direc-
tions, Tait is responsible in
part for the PIC revolution
today. To read many of
the articles, head to
members.optushome.com.
au/donmck/dtait/index.html. Bob
Blick describes another DIY PIC16F84
programmer and provices a PC board
layout on his web site (www.bobblick.
com/projects/PicProg/index.html).
Check out Bob’s other great projects
including his POV experiments, espe-
cially the Propeller Clock.
SERVO84 BOARD SCHEMATIC
Last month, I described Mark
Sullivan’s SERVO84 controller appli-
cation but there wasn’t enough room to
include the schematic or any construc-
tion details, except where to obtain the
firmware. Without further ado, Figure 1
shows the schematic that I reverse
engineered from the SERVO84 soft-
ware for the board shown in Photo 2. I
have used this design in many of my
RC projects and I have found it to work
well using both PCB and point-to-point
construction techniques. Mark’s ’16F84
SERVO84 application is well written in
PIC assembly and is available for free at
mks.niobrara.com/microtools.html.
Refer to Part 1 for how the board is
used with my animation system.
Note the use of 0.1 pin headers that
are keyed to interface to standard RC
servos. Pay particular attention to the
POWER and GROUND pins because
connecting these backwards destroys
the RC servo’s delicate electronics. As
you can see in the schematic, I pro-
Figure 1—
Here’s the schematic for a SERVO84 controller board that I reverse engineered
from Mark Sullivan’s SERVO84 software.
extensively throughout this applica-
tion. More information about develop-
ing software for the PIC18C452 using
Microchip’s tool suite can be found in
several of the references. [1, 2, 4]
There is no need for you to use C
compiler unless you’re familiar with
C and wish to customize the anima-
tion code, because I’ve provided the
firmware in Intel format hex files for
both the USART interface and the
embedded menu versions. The only
hardware needed in this case is the
Warp13 PIC programmer.
The PIC18C452 microcontroller has
the extensive processing capabilities
needed to handle many common con-
trol-related algorithms used for robot-
ics. These capabilities include PWM
hardware to control DC motors, cap-
ture registers used to read optical
encoder(s), and ADC(s) used for read-
ing temperature, current, and voltage.
Software for the PIC joystick con-
troller consists of a menu-driven sys-
tem that accepts simple ASCII com-
mands to enable the operator to record
and play animation sequences and cal-
ibrate the selected joystick. The main
embedded application (
animate.c)
requires a WARP13 or PICSTART pro-
grammer to burn it into a PIC18C452
microcontroller. All of the necessary
files are located on the Circuit Cellar
web site. A word of caution regarding
30
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
to this design. Both of the joystick’s
trigger and fire buttons may independ-
ently control up to four relays or other
kinds of actuators.
The controller has three modes of
operation. The first is Calibration
mode, which requires a connection to
a PC or laptop host to provide the joy-
stick controller with important motor
scaling parameters and also to cali-
brate the joysticks for the first time.
The second mode is a serial RS-232
menu that allows a host PC or laptop
or master microcontroller to send sim-
ple commands to the automation con-
troller for processing. I used this mode
extensively during debugging.
The simplest mode is Embedded
mode, which uses the record, play, and
calibrate switches shown in Table 1 to
enable these functions. I prefer this
mode of operation because it doesn’t
require a host to send it commands.
This makes it portable and easy to
connect to various robotic projects,
animation props, and so on.
During embedded calibration, the
software defaults to joystick number
one and the last sampling period and
window commands entered by the
menu-driven calibration process if used.
Otherwise, the embedded animation
control mode defaults to a window
appropriate for a standard RC servo
(1.0, 1.0, 110.0, 110.0) and a sampling
period of 50 ms. A small hardware and
software change would be required to
select one or two joysticks using the
embedded mode. This would work
similar to the animation control
switches. Otherwise, the RS-232 Menu
mode should be used for controlling
two joysticks at the same time.
STAMP EQUIVALENT FUNCTIONS
I’m a big fan of the Stamp devices
from Parallax. I use them initially to
test most of my designs before re-
hosting them on a PIC. They are far
too precious to use on any particular
project because of their high unit
cost. Naturally, because I like to
reuse the Stamp code as much as
possible, I developed a library of PIC
C versions of these handy Stamp
functions
pause, high, low, shiftout,
rctime, and others.
The C equivalent code of the pause
function is shown in Listing 1. I provid-
ed it as an example because it plays
such an important part in keeping the
animations synchronized. I also took
advantage of the PIC18C452 timers
when implementing the function. I
will continue to work on translating
the remaining Stamp functions to PIC
C until I have a complete library of
Stamp functions in C. My ultimate
goal is to have the C firmware func-
tion identically to the Stamp for each
application that I develop.
MICROCHIP C COMPILER
The joystick controller software is
written in PIC C that targets the
Microchip PIC18C452 microcontroller.
I used a demo version of the Microchip
C compiler to develop most of the
related joystick control processing
algorithms and experiments used for
this board, including the Animation
System application provided with this
article (
animate.c). I also used the RS-
232 (USART)
printf and dec functions
Listing 1—
This section of code shows how to implement the PIC C version of the Stamp BS2
pause
func-
tion. It is used throughout my joystick controller firmware to delay for a specific number of milliseconds and it
plays an important part in the overall animation system timing.
****************************************************************************
pause—pauses for n units of 1000 instruction cycles (milliseconds at 20 MHz).
It works the same way as the Stamp pause function. This function uses Timer
1 or Timer 3, with the prescaler set to 1:8 and a system clock of 20 MHz.
****************************************************************************
void pause(unsigned int n)
{
//Use Timer 1
//Clear the Timer 1 overflow flag
PIR1bits.TMR1IF = 0;
do
{
WriteTimer1_16(0x8FFD);
//Two's complement of 625 (0xFD8F) for a 1-ms delay. Use LSB to MSB
order to compensate for the Microchip timer library bug. Use
WriteTimer1_16 instead of WriteTimer1 to compensate for another
Microchip timer library bug.
//Wait until Timer 1 counts down to zero or the Timer 1 over
flow
flag is set while (Count = ReadTimer1()) != 0xFFFF);
while (!PIR1bits.TMR1IF);
//Clear the Timer 1 overflow flag
PIR1bits.TMR1IF = 0;
} while (--n);
}
S1 S2
Mode
Off
Off
Standby
Off
On
Play
On
Off
Record
On
On
Calibrate
Table 1—
There are four embedded animation control
modes that enable the joystick controller to be used as
a stand-alone device.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
31
the animation software: it’s still
under construction and may (proba-
bly) have bugs in it.
The user interface is serially driven
using the PIC’s USART to communi-
cate with a host PC or laptop using
HyperTerminal, Visual Basic, or Visual
C++ or a Master Stamp or PIC micro-
controller using PBASIC. The data and
command format is usually in two- or
four-hex byte format (see Table 2).
In this project, I also took advantage
of the ’18C452’s floating point capabili-
ties to calibrate and scale the joystick
coordinates to a predefined window
that corresponded to the necessary
servo or DC motor command ranges.
MICROSOFT VISUAL C++
I’ve also used debugging algorithms
using VC++ in the absence of good
hardware debugging tools such as
emulators. Sometimes MPLAB simu-
lations are too slow or too limited for
debugging algorithms that include
floating point. This is where VC++,
one of the best C/C++ software debug-
gers, shines. By including software
flags for the type of compiler used, I
can selectively compile and simulate
code using the PIC C or VC++.
I exclude code that cannot be run
directly such as hardware access or
interrupt service routines by also
using C conditional compile flags.
Delay functions are disabled and stan-
dard serial I/O functions are redirected
to read and write from RAM buffers.
THE MSART INTERFACE
The PIC’s master synchronous asyn-
chronous receiver transmitter (MSART)
provides the I
2
C, SPI, Microwire, and
Dallas one-wire interfaces. [5] In this
application, the I
2
C interface is used
as an I
2
C master to communicate
with the 24LC16B serial I
2
C EEPROM
in order to read and write calibration
and animation data to it. New motor
controllers now provide a built-in I
2
C
or SPI synchronous interface that
provides efficient communications
with these controllers.
I mentioned in Part 1 that I am cur-
rently involved in developing an
embedded I
2
C motor controller appli-
Photo 2—
Take a closer look at the SERVO84 con-
troller board that I have used in countless animation
and robotics projects.
Photo 1—
You can see the Hero I showing off its
6-DOF arm, which is ready to be animated.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
35
host via the serial port so that it may
be recorded there. The sample period
or time interval between samples is
specified either in the command line
or during calibration by default.
The Record function is used to ani-
mate, digitize, and store animation
scripts containing the joystick posi-
tions (commands) and button states to
EEPROM memory for playback later.
Recording an animation script is done
in one of the following ways. The first
way is to start recording an animation
script from the host by having it send
the
Axx,yyyy; command from Hyper-
Terminal or a C, C++, or BASIC appli-
cation in order to execute the record
function using the xx joystick with a
sampling period of yyyy milliseconds.
The second and preferred method is
to switch the S1 and S2 switches to
Record mode (see Table 1). The Record
function terminates when all available
EEPROM memory has been used or
when the state of S1 and S2 has
changed. If the switches are left in
Record mode, the animation script is
rerecorded to EEPROM memory start-
ing at the beginning until all of the
memory has been used again or until
the state of the switches has changed.
The sampling period selected is the
one set during the joystick calibration.
The Record LED lights up when this
function is selected and stays lit until
the recording process has ended. If the
record switch is in the record position,
the recording process will start over
and the Record LED will remain lit.
To demonstrate the Record command
example, when using the USART inter-
face version, enter the
A01,0010;
command from the PC or laptop. This
command should make the joystick
controller begin animating and record-
ing movements from joystick number
one using a sampling period of 16 ms.
The Record function may also be
used to send large animation scripts via
the serial port data to a host PC or lap-
top using HyperTerminal for playback
with another user written host appli-
cation. This requires a PC-based appli-
cation to read the data collected by
HyperTerminal and then send it to the
animation hardware. In this case, the
PC’s hard disk (instead of the joystick
controller’s EEPROM) is used as a
large buffer for storing the animation
scripts. The firmware could be modi-
fied to apply a compression algorithm
such as run length encoding (RLE) to
the sampled data to save memory and
increase the playback capacity.
PLAY COMMAND
The Play command implements a
play mode that sends all of the joy-
stick position and status information
that has been saved to EEPROM back
to the host or sends it to the PIC
SERVO84 application. This function
could be used in animatronics applica-
tions requiring exact motion replay,
such as in special effects for movies.
Slow motion, real-time motion, and
fast speed can be accomplished by
changing the playback frequency or
cation that will be written in PIC C
using the PIC I
2
C Slave mode. So far,
I’ve found this to be a frustrating
experience, but I’ve learned a lot from
information I found on the ’Net and
also from a book titled Serial PIC’n. [6]
I highly recommend this book for any-
one developing applications using
these synchronous protocols, because
it has many I
2
C, SPI, Microwire, and
Dallas one-wire interface examples that
are clearly written in PIC assembly.
Although I have not used the I
2
C
interface to communicate with a
motor controller via Slave mode, I am
in the process of building Jeff
Bachiochi’s board and I will proceed to
integrate it into my animation system
as soon as I have finished it. [7]
THE USART INTERFACE
The PIC’s universal synchronous
asynchronous receiver transmitter
(USART) is used for a serial, RS-232
interface to the PIC18C452 microcon-
troller. [5] The USART plays a critical
part in the animation system because
it is the primary user interface used to
access the sophisticated functions avail-
able from the joystick controller. The
USART is also used to communicate
with other animation system compo-
nents such as motor controllers. A
detailed description of some of the joy-
stick commands is provided in Table 2.
To customize the serial interface for
a particular motor controller (commer-
cial or DIY), use the example shown in
Listing 2. For details of the proper seri-
al motor commands, refer to the docu-
mentation provided by the individual
vendors of these motor controllers. To
illustrate this, the listing demonstrates
how to change one of my joystick con-
troller functions to use Scott Edward’s
Mini-SSCII RC servo controller board
instead of the DIY SERVO84 board. I
have not tried using this controller, but
after reading the specs, I find that they
are similar to the SERVO84 format.
RECORD COMMAND
The Record command implements a
teaching pendant mode that uses the
joystick functions to collect joystick
position and button information. Next,
it records the information in EEPROM
or sends the information back to the
Command
Description
Axx,SamplePeriod
Enter the sampling period (ms) in four-digit hex format to record an animation for the selected
joystick, xx. The joystick ID range (01–02) is in a two-digit hex byte format.
Bxx,SamplePeriod
Enter the sampling period (ms) in four-digit hex format to play an animation for the selected
joystick, xx. The joystick ID range (01–02) is in a two-digit hex byte format.
Cxx,SamplePeriod
Calibrate the selected joystick xx. The joystick ID range (01–02) is in a two-digit hex byte for-
mat and the sampling period (ms) is in four-digit hex format for recording and playback.
Sxx
Send calibration data from joystick xx, where the joystick ID range (01–02) is in a two-digit
hex byte format
Wxx,XwindowMin,
Accept window data used to scale the XwindowMax and XwindowMax joystick commands,
YwindowMin where the joystick ID range (01–02) is in a two-digit hex byte format and the four 16-bit
hex words that follow represent integer values for the minimum and maximum window
coordinates.
Rxx
Read and Send raw joystick position and button status information from joystick xx, where
the joystick ID range (01–02) is in a two-digit hex byte format
Pxx
Read, process, and send scaled joystick position and button status data from joystick xx,
where the joystick ID range (01–02) is in a two-digit hex byte format
Txx
Test the selected joystick xx, where the joystick ID range (01–02) is in a two-digit hex byte
format
Z
Reset the joystick controller
Table 2—
These commands require that a host PC be connected to the joystick controller using a serial cable.
36
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
ed to move the joystick in a circular
motion, then to release the joystick
back to a neutral position, and then
press the Fire button when done. Using
the information collected by this
process, the calibration function will
compute the minimum, maximum,
and neutral joystick position values
for both the x-axis and y-axis. These
values are later stored to EEPROM or
scratch pad RAM available on the
PIC. From there they can be accessed
by other applications that need them.
This calibration data is used during
normal operation to determine if any
of the joystick’s center coordinates are
outside of their calibrated dead-band
region. If they are, then the joystick
may need to be adjusted using the
sliding switches that control the joy-
stick’s gain for each axis (x and y).
New joystick hardware will require
manual calibration initially.
Another feature of this animation
system is the joystick automatic cali-
bration feature, which reduces the
number of times needed to calibrate a
joystick or other input device. The
feature checks to see if the current
neutral joystick position is the same
as a previously calibrated position. If
the position is the same, a calibration
period. The period is specified directly
on the command line or during cali-
bration by default.
The play function is used to play
back the animation scripts previously
recorded to EEPROM. Animation is
accomplished by sending simple actu-
ator commands to the hardware.
Playback of a previously recorded ani-
mation script is accessed by one of
the following methods. The first way
the play function may be called from
a host application is by having it send
the
Bxx,yyyy; command from
HyperTerminal or a C, C++, or BASIC
serial application. This command exe-
cutes the play function using the xx
joystick with a sampling period of
yyyy
milliseconds.
The second (and preferred) method
is to use the S1 and S2 switches to
switch to Play mode as shown in
Table 1. If the switches are left in Play
mode, the animation script is played
back repeatedly until the state of the
switches is changed. The Play LED
remains lit until the switch is
changed from the Play position.
To demonstrate the Play command,
when using the USART interface ver-
sion, enter the command
B01,00FF;
from the PC or laptop. This command
should make the joystick controller
play the animation script previously
recorded with a sampling period of
255 ms. Note that the period used dur-
ing Play may be different from the peri-
od used during Record, thus allowing
for special affects such as slow motion.
CALIBRATION COMMANDS
Joystick calibration commands
include entering window limits and
sampling parameters such as the
Joystick ID and Period. The user inter-
face includes an embedded menu that
allows you to select the calibration,
record, play, and diagnostics functions.
The Calibrate command is called to
allow the operator to manually cali-
brate the selected joystick. Pressing
the Calibrate button or typing the
Cxx,yyyy; command function (from
HyperTerminal) using the xx joystick
with a sampling period of yyyy mil-
liseconds executes the Calibrate func-
tion when the USART interface ver-
sion is used. The operator is prompt-
Listing 3—
To the animation system, digitizing flexible resistors such as those used in a home-built power
glove looks like this.
****************************************************************************
ReadSensor reads the raw sensor value from the A/D channel.
****************************************************************************
int ReadSensor(byte SensorID)
{
int RawSensorValue;
//Raw sensor value
SetChanADC(SensorTable[SensorID].Channel);//Select the sensor A/D channel
DelayMilliSeconds(1);
//Delay 1 ms for A/D conversion to complete
ConvertADC();
//Start conversion
//Delay10TCYx(5);
//Delay for 50TCY
DelayMilliSeconds(20);
//Delay 20 milliseconds for A/D conversion to complete
RawSensorValue = ReadADC();//Read result and store it in RawSensorValue
return RawSensorValue;
//Return actual sensor value read
}
Listing 2—
This is what it takes to customize the joystick controller serial interface to use the popular com-
mercial Mini-SSC II controller from Scott Edwards Electronics.
****************************************************************************
DisplayJoystickReadings displays the x- and y-axes joystick readings.
Scaled joystick positions are sent back to the host via the serial port
and also sent to the LCD (if connected). These commands are sent back
later (RECORD/PLAY) to implement a teaching pendant.
****************************************************************************
void DisplayJoystickReadings(byte JoystickID)
{
byte Sync = 255;
// Mini SSC II Sync byte
byte Servo1 = 1;
// Servo 1 ID
byte Servo2 = 2;
// Servo 2 ID
byte Servo7 = 7;
// Servo 7 ID
// Send joystick commands directly to a Mini SSC II Controller using
the serial port set for: 9600,8,N,1.
// Move servo #1 "B" platform
send_byte(Sync);
// Send Sync byte to Mini SSC II
send_byte(Servo1);
// to servo #1
send_byte(XJoystick[JoystickID]); // Send Position
// Move servo #2 "C" left wheel
send_byte(Sync);
// Send Sync byte to Mini SSC II
send_byte(Servo2);
// to servo #2
send_byte((byte) XJoystick[JoystickID]); // Send Position
// Move servo #7 "G" right wheel
send_byte(Sync);
// Send Sync byte to Mini SSC II
send_byte(Servo7);
// to servo #7
send_byte(YJoystick[JoystickID]); // Send position
}
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
37
LED is lit. If the position is different,
the manual calibration function is
invoked automatically.
The embedded menu calibration
mode that I developed allows you to
specify a limited version of the above
calibration procedure by setting the
toggle switches to the calibrate position
as is shown in Table 1. This mode
only allows the default sampling period,
along with the default window param-
eters or the sampling period and win-
dow parameters specified by a previous
write to the serial EEPROM via the
USART interface, to be used for the cal-
ibration process. The advantage to this
method is that the joysticks can be cali-
brated without the need for a host PC
or laptop, and can be carried out on the
target robot platform itself because
most of these parameters hardly ever
change once they have been defined.
The calibration data is read from
EEPROM along with window coordi-
nates that are used to map the raw joy-
stick positions to RC servo commands.
These window coordinates are entered
with the joystick controller window
command,
Wxx,aaaa,bbbb,cccc,
dddd; before any calibration takes
place. The fields are entered using hex.
For example, sending the command
W01,000A,000A,0078,0078; will
cause the automation controller to
scale any joystick commands from
their raw positions (counts) to RC
servo commands between 10 and 120
(decimal). I opted to use hex format
for all I/O because it reduced the seri-
al data required and kept each packet
to a fixed size. It also made it easier to
parse the data for host serial applica-
tions using C, C++, or BASIC.
Joystick Calibration mode enables
the PIC to scale motor commands
according to the specified limits set by
the Window command. Now any val-
ues that exceed these limits for the x-
and y-axes will automatically be lim-
ited to the boundaries using the sec-
ond set of equations shown in Part 1
(Circuit Cellar 142, p. 41).
These equations allow you to com-
pensate for each individual RC servo,
DC motor, or any other actuator that
requires the same position or velocity
but because of mechanical and electri-
cal differences, does not move identi-
cally (e.g., if you want your robot to
move forward in a straight line).
Scaled commands can represent RC
servo commands, PID motor com-
mands, or PWM motor commands,
depending on the type of actuator used
and the control algorithm required.
DIAGNOSTIC COMMANDS
Diagnostic joystick controller com-
mands to read a joystick position, read
the joystick button states, and so on,
are available to the user to tailor the
software to their needs. This can be
done with simple PIC and Stamp seri-
al applications or serial applications
written in VC++ and VB from a PC.
The Test command tests the joystick
software with the actual hardware by
exercising the connected joystick hard-
ware. The test counts the number of
times the selected joystick Fire and
Trigger buttons have been pressed. It
also checks to see if button debouncing
is necessary. If debouncing is needed,
the application will delay for a speci-
fied number of milliseconds in order
to debounce each joystick button. The
current joystick position is computed
from the raw x- and y-axes potentiome-
ters by scaling the values with the joy-
stick calibration values and sending
them back to the host (along with the
button status) via the serial port. An
LED is lit each time a joystick Trigger
or Fire button is pressed.
Three examples that show how to
run joystick controller diagnostic
commands are available for download
from the Circuit Cellar site.
JOYSTICK INTERFACE
This application uses a PIC18C452
microcontroller to interface up to two
joysticks to the PC serial port. Both
PC-compatible resistive joysticks and
voltage-divider joystick models (Color
Computer) can be used. The
rctime
that I described in great detail in Part 1,
is a function used to obtain position
information from the PC-compatible
resistive joysticks and flexible resistors
by measuring using an RC time con-
stant. I also stated that the PIC18C452
ADC could be used to obtain joystick
positions from voltage divider joysticks.
Positions from these analog voltage
divider joysticks can be read quickly
as compared to the PC compatible
(RC) joysticks. One way to accomplish
this task would be to integrate my
sensor controller board into the ani-
mation system to digitize the analog
joystick. Another way is to modify the
joystick controller firmware to obtain
joystick positions directly using code
from the sensor controller firmware.
An example of using the ADC to read
a flexible resistor to be used in the con-
struction of an input device similar to
the Mattel Power Glove is shown in
Listing 3. [3] These flexible resistors are
Listing 4—
This snippet is the PIC C equivalent of the Stamp BS2 PWM function. The only limitation of
this function is that is uses the dedicated PWM I/O pins RC1 and RC2 for a total of two PWM channels.
By adding two 74LS138 IC(s), the number of independent PWM channels could be increased to 16.
**************************************************************************
Currently, the PWM function defaults to PIC18C452 I/O pin RC2 (PWM1).
Support for PWM2 is missing and needs to be added. The pin parameter has
a different meaning than that of the Stamp BS2. Here it selects one of
the outputs of the first 74LS138 1:8 decoder IC to support up to eight
PWM devices when PWM1 is used or 16 PWM devices (when both PWM1 and PWM2
are used). The PIC allows a 10-bit duty cycle whereas the Stamp allows
only an 8-bit duty cycle. The period is initialized by default to 1 ms.
You can change this with the InitializePWM function.
**************************************************************************
void pwm(byte Pin, word Duty, word Cycles)
{
word i;
//Cycle loop index
//Select the PWM1 pin by setting the address bits (0–2) using port B.
Bits 0–2 are connected to the 74LS138 IC.
PORTB = Pin;
for (i=0; i<Cycles; i++)
{
while(!PIR1bits.TMR1IF);
PIR1bits.TMR1IF = 0;
SetDCPWM1(Duty);
//Set duty cycle
}
}
38
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
available from Jameco for $10 each, so
a glove made from these components is
not going to be cheap. I intend to hot-
glue these flexible resistors to welding
gloves for my own DIY version.
Using the PIC’s 10-bit ADC should
allow far better position readings than
those available from the Mattel Power
Glove. I have not had a chance to try
this yet, but I assume it will work
because the code works for the sensor
controller. The only problem remain-
ing to be solved is locating the glove
in 3-D space (pitch, yaw and roll)
using some kind of IR or sonar bea-
cons. My ultimate goal is for a virtual
handshake capability to be used in
tele-presence applications with my
animation system.
The joystick Trigger and Fire but-
tons are assigned to individual PIC I/O
bits. These bits can be reassigned for
custom hardware applications such as
triggering relays, solenoids, and other
kinds of actuators under control of the
animation system.
PWM INTERFACE
In Part 1, I mentioned that the PIC
has a PWM peripheral that can be used
to generate PWM waveforms automat-
ically. [5] Previously, I had used a Stamp
BS2 to generate the PWM waveforms
used to control the heavy-duty 24-V
MCIPC-24 motor control board from
Diverse Electronic Services in my
GardenBot. I am now in the process of
converting the Stamp PBASIC applica-
tion to PIC C so I can use it with my
animation system to drive the Diverse
H-Bridge directly. When I get this
function working, I will be able to use
the joystick to train GardenBot direct-
ly, so it will recognize my lawn’s
boundaries in order to automatically
seed the lawn this spring.
Listing 4 shows the PIC equivalent
of the Stamp PWM function. By fol-
lowing this example, other H-Bridge
motor controllers and RC servos that
require PWM may be directly connect-
ed to the joystick controller board using
the two ’18C452 PWM I/O pins (RC1
and RC2). The addition of two 74LS138
devices should allow me to expand the
two PWM channels to a maximum of
16 PWM channels with the appropriate
modifications to the joystick controller
firmware (
animation.c) located on the
Circuit Cellar
site.
FIRMWARE IMPROVEMENTS
Future improvements to the joy-
stick controller firmware that I plan
to carry out include upgrading the
serial EEPROM drivers to use multi-
ple 24LC256 serial I
2
C EEPROM
devices for longer and higher resolu-
tion animations. In addition, I would
like to implement an I
2
C interface to
the joystick controller that works sim-
ilar to the serial RS-232 interface,
using the USART. In order to do this, I
need to get the I
2
C slave mode work-
ing. Serial PIC’n and Jeff Bachiochi’s
I
2
C motor controller application will
be quite helpful in that process.
I could use a PIC processor to trans-
mit joystick information to a robot
using the Sony IR remote control pro-
tocol with a modulated IR LED trans-
mitter and a Sharp IR receiver, thereby
providing control for props that use IR.
IT’S A TAKE
In the course of these two articles, I
have provided you with detailed infor-
mation on various kinds of commer-
cial and DIY motor controllers, as
well as information on many types of
motors, including servos, DC motors,
and stepper motors, and how those
motors may be used with my anima-
tion system. In addition, I included a
detailed schematic for the DIY
SERVO84 RC controller board.
Although I was only experimenting
with DIY animations with my system,
I found out that I was able to carry out
some complex animations.
As you can gather from all of the
information presented in this article,
animatronics encompasses many
fields of study. It’s a challenge to pull
everything together into your own
animation system, but bringing your
props to life can be a fun and reward-
ing project.
I
SOFTWARE
REFERENCES
[1] D. Ramirez, “Robot Sensor
Controller Board—Part 1: The
Brain,” Circuit Cellar 135,
October 2001.
[2] ———, “Robot Sensor
Controller Board—Part 2: How
the Brain Works,” Circuit
Cellar
136, November 2001.
[3] L. Jacobson, Garage Virtual
Reality
, SAMS Publishing,
Indianapolis, IN, 1994.
[4] M. Predko, Programming and
Customizing PICmicro Micro-
controllers
, 2nd ed., McGraw-
Hill, New York, NY, 2000.
[5] J. Bachiochi, “DC Motor Control
for the I
2
C Bus,” Circuit Cellar
62, September 1995.
[6] Microchip Technology Inc.,
”PIC18CXX2 High Performance
Microcontrollers with 10-Bit
A/D,”DS39026B, 1999.
[7] R.L. Stevens, Serial PIC’n,
V.2.0, Square 1 Electronics,
Kelseyville, CA, 1999.
SOURCES
PIC microcontroller
Microchip Technology, Inc.
(800) 344-4539
www.microchip.com
BASIC Stamp
Parallax Inc.
(888) 512-1024
www.parallaxinc.com
Mini-SSCII board
Scott Edwards Electronics, Inc.
(520) 459-4802
www.seetron.com
Daniel Ramirez is currently a senior
software engineer with over 10 years
of experience working on real-time
embedded systems. His hobbies
include travel, golf, treasure hunting,
and robotics. You may reach him at
mgatron@aol.com.
RESOURCES
Microchip Technology Inc.,
“MPLAB IDE Simulator, Editor
User’s Guide,” DS251025E,
2001.
———, “MPLAB-CXX Compiler
User’s Guide,” DS51217B, 2000.
———, “MPLAB-CXX Reference
Guide,” DS51224B, 2000.
CAN Interfaces
PCI
USB
LPT (parallel)
32-bit CAN SBCs
MPC555
16-bit CAN SBCs
C167Cx
C164CI
ST10F168
ST10F269
XAC3
8-bit CAN SBCs
C515C
DS80C390
P8x591
T89C51CC01
Software
CANopen Master/Slave
PLC:
Programmable Logic Control
CAN Analyzer
CANopen Node
CANopen Chip
PLC Chip
USB-CANmodul
PCAN
®
-PCI
CANopen-Chip
8-bit phyCORE
®
-T89C51CC01
16-bit phyCORE
®
-ST10F269 HS/E
32-bit phyCORE
®
-MPC555
I
nsert-ready, OEM-able Single Board Computer
modules power CAN Applications
Rapid Development Kits
Rapid Development Kits
Rapid Development Kits
Rapid Development Kits
Rapid Development Kits available for all SBC modules, including:
■ Development Board enabling easy SBC start-up and
programming
SBC Module
Controller
SBC Features
1 (100) Unit Price
phyCORE
®
-MPC555
MPC555
72x57 mm
■
dual TouCAN
■
to4 MB Flash, 4 MB SRAM
$499
($374)
phyCORE
®
-ST10F269 HS/E ST10F269
60x53 mm
■
dual 2.0B CAN
■
Ethernet
■
high-speed
$299
($239)
phyCORE
®
-167
C167Cx
60x53 mm
■
2.0B CAN
■
to 2 MB Flash, 1 MB SRAM
$259
($181)
phyCORE
®
-ST10F168
ST10F168
60x53 mm
■
2.0B CAN
■
to 2 MB Flash, 1 MB SRAM
$259
($194)
phyCORE
®
-XAC3
XAC37
55x47 mm
■
2.0B PeliCAN
■
to 2 MB Flash, 2 MB SRAM
$179
($134)
miniMODUL-167
C167CR
85x55 mm
■
2.0B CAN
■
to 2 MB Flash, 2 MB SRAM
$279
($195)
nanoMODUL-164
C164CI
47x48 mm
■
2.0B CAN
■
to 1 MB Flash, 1 MB SRAM
$195
($146)
DIPmodul-164
C164CI
DIP-40 size
■
2.0B CAN
■
to 1 MB Flash, 1 MB SRAM
$129
($ 97)
phyCORE
®
-T89C51CC01
T89C51CC01
55x44mm
■
2.0B CANary
■
to 512 KB Flash, 128 KB SRAM $119
($ 89)
phyCORE
®
-591
P8xC591
55x40mm
■
2.0B PeliCAN
■
to 512 KB Flash, 128 KB SRAM $139
($104)
phyCORE-390
DS80390
55x47.5mm
■
dual 2.0B CAN
■
to 2 MB Flash, 1 MB SRAM $169
($127)
miniMODUL-515
C515C
85x55mm
■
2.0B CAN
■
to 512 KB Flash, 160 KB SRAM
$169
($118)
CAN Accessory
Conversion
Description
1 (100) Unit Price
CANopen-Chip
CANopen Slave I/O
8-bit CAN node with pre-configured CANopen firmware
$69
($ 55)
USB-CANmodul
USB-CAN
USB-to-CAN interface in palm-sized housing
$225
($180)
PCAN
®
-Dongle
parallel-CAN DB25 parallel-to-CAN interface in Dongle housing
$225
($169)
PCAN
®
-PCI
PCI-CAN
PCI-to-CAN interface via PC insert-card
Call!
CANopen Software
---
CANopen Slave and Master Source, Libraries
Call!
PLC Software
---
Easy CAN Programmable Logic Control software
Call!
CAN Accessories
■ Spectrum CD with
evaluation software
(compiler,
debuggers),
FlashTools download
utility, demo code
and extensive
documentation
■ AC adapter and
serial cable
8-bit miniMODUL-515 (depicted above -left)
Standard Config
40
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
n today’s con-
stantly improving
product market, a
technology can go from
cutting edge to antique status in a
short matter of time. But even though
the controller area network (CAN) has
been around for 15 years, it continues
to be implemented and is still gaining
popularity. The number of CAN
nodes sold and installed rises each
year and currently exceeds 200 mil-
lion new nodes per year. These sales
figures are collected and published by
the CiA, the CAN in Automation
International Users and Manufacturers
Association that also organizes the
yearly international CAN Conference.
Traditionally, CAN was used in
automotive applications. Today, CAN
is one of the best choices for embed-
ded networking applications that
need to communicate between sever-
al embedded 8-bit and 16-bit micro-
controllers. The biggest cur-
rent growth sectors are
embedded machine control
applications such as home
appliances, industrial
machines, and other machin-
ery containing multiple micro-
controllers that need to com-
municate with each other.
A big advantage of CAN compared to
other network solutions is the price/
performance ratio. When it comes to
price, CAN is the most affordable net-
work, next to a regular serial channel.
It costs about $3 to CAN-enable an
existing microcontroller design. When
you break it down, replacing an 8-bit
or 16-bit microcontroller with one
that features a CAN interface costs
about $1. An additional $1 is needed
for the transceiver (line driver for
twisted pair) and another $1 for con-
nectors and additional PCB area.
Replacing a microcontroller with
one that features a CAN interface
seems easy, because about 20 different
semiconductor manufacturers produce
microcontrollers with one or multiple
on-chip CAN interfaces. However,
there are major dissimilarities in the
CAN controllers available that can
make a big difference when it comes
to performance. The difference can be
that with one device, the communica-
tion overhead uses all of the available
MCU performance, whereas on anoth-
er device the same communication
task can be performed with a mini-
mum of MCU execution time.
This article will point out some of
the major differences between CAN
controllers available and explain how
the differences can affect your applica-
tion. With so many manufacturers pro-
ducing CAN components, there isn’t
enough space in this article to cover all
of the available controllers. Instead I
will focus on the most commonly
available implementations and the
most innovative enhancements seen
today. For a complete listing of all
CAN controllers, go to www.can-
cia.org and check the product listings.
REQUIRED PERFORMANCE
Before I get started, let’s take a clos-
er look at typical worst-case scenarios
for CAN communication. The highest
Selecting the Best CAN
Controller
i
Selecting the right
CAN controller for
your specific applica-
tion can be a daunting
task when you con-
sider the numerous
options on the market
today. Fortunately,
Olaf has some great
advice that can help
you minimize cost
and maximize per-
formance.
Olaf Pfeiffer
FEATURE
ARTICLE
Bus interf
ace
CAN
protocol
controller
Acceptance
filtering
Status control
registers
Transmit
buffer(s)
Receiver
buffer(s)
Host interf
ace
Figure 1—
Take a look at a basic CAN interface.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
41
either transmit or receive), each
having its own transmit/receive
buffer for one message, and each
having one filter match register.
This arrangement allows you to
set a message object to listen for
only one message (one identifier).
As long as the total number of
messages a node needs to listen to
is smaller than the number of mes-
sage objects available, these inter-
faces are efficient. They will cause
an interrupt to the MCU only if a
wanted message was received.
However, this mechanism does
not offer any protection from a back-
to-back worst-case scenario. Each
message object has a single buffer and
a matching incoming message will
override the buffer’s contents, so mes-
sages have the potential to get lost. As
long as a buffer is configured for a sin-
gle message identifier, this scenario is
not too bad because it’s unlikely that
the producer of that message produces
them back-to-back. As soon as any of
the message objects are configured to
receive multiple CAN identifiers, the
microcontroller must be prepared in
the event that these come in back-to-
back. On a 1-Mb CAN network, that
means about 50 µs from receive inter-
rupt occurrence to a potential over-
write of that message by the next
incoming message.
The only way to get around the
back-to-back message problem and the
high performance and timing demands
on the interrupt service routine is with
a receive FIFO buffer (see Figure 3). A
typical implementation features a
number of filters that include both
match and mask registers. Upon a fil-
data rate currently supported is
1 Mb. The longest possible mes-
sage contains 8 data bytes and the
shortest possible message (0 data
bytes) takes about 50 bit times on
the bus. At 1 Mb, 50 bit times
corresponds to 50 µs.
If the goal of the application is
handling CAN interrupts in real
time, the microcontroller would
need to digest an incoming mes-
sage with 8 data bytes in less than
50 µs. Potentially, this is the
shortest time during which the
next receive interrupt could occur.
Keep in mind that to leave enough
MCU operating time for the real appli-
cation (whatever is handled besides
CAN communication), the digestion
process should take far less than 50 µs.
Experienced 8-bit microcontroller
users will immediately see that such a
worst-case scenario could be challeng-
ing for some microcontrollers and
could keep them busy with nothing
else but CAN communication.
However, it is seldom the case that a
single node needs to receive and work
on 100% of the messages on the bus.
On the average, a node often only
needs to listen to a certain percentage
of the messages.
Although this helps reduce the over-
all average MCU operating time
required for handling the CAN com-
munication, workarounds are still
needed to handle bursts of back-to-
back messages that an individual node
might need to receive. Fortunately,
modern CAN interfaces have hard-
ware filtering and buffering features
that help with the task of ignoring
unwanted communication and buffer-
ing back-to-back messages.
HARDWARE FILTERING
The functionality of hardware filters
is similar on many CAN devices.
While receiving a CAN message, the
identifier (and sometimes even the
data) can be compared to a configured
filter. Only if the incoming message
matches the filter does the message
get stored in a receive buffer. The two
major differences in filters are usually
the width of the filter, and if it is a
match-only filter or also allows a
mask to be used.
The filter width specifies how many
bits of an incoming CAN message can
be processed. At least 11 bits are
required for a standard CAN message
identifier and an extended CAN mes-
sage identifier will need 29 bits.
A match filter allows you to per-
form only one exact match (e.g.,
exactly one identifier), a combination
of match and mask allows for filtering
message groups (e.g., identifiers 0x100
to 0x11F). Usually a bit set in the
mask register means that the corre-
sponding bit in the CAN message is a
“don’t care” value for the acceptance
filtering. If a bit is cleared, it must
match the value in the match register.
DIFFERENT IMPLEMENTATIONS
The original CAN interfaces avail-
able were later called Basic CAN
interface (see Figure 1). Basic CAN
interfaces only offer a limited number
of receive buffers and filters (typically
one to three). If a node using such a
controller needs to listen to a number
of different messages (different CAN
message identifiers), the filters usually
have to be set wide open causing
an interrupt with every single
message on the bus. Obviously,
the microcontroller will get
many CAN interrupts because it
has to check in software to see if
a message can be ignored or
needs to be worked on.
The next generation of CAN
controllers was the so-called Full
CAN implementation (see Figure
2). Full CAN controllers use a
number of message objects (typi-
cally 15) with each being bidirec-
tional (they can be configured to
Bus interf
ace
CAN
protocol
controller
Acceptance
filtering
Status control
registers
Message
object 1
Message
object 2
Bus interf
ace
Message
object 1
Message
object 2
.
.
.
Figure 2—
In block diagram form, here’s the Full CAN interface.
Bus interf
ace
CAN
protocol
controller
Extended
acceptance
filtering:
screeners
for message
ID and
data
Status control
registers
Transmit
buffer
Host interf
ace
Extended
receive
buffer
(FIFO)
Figure 3—
Notice that the latest improvements to CAN do not
have standard names. That’s because chip manufacturers are
developing their own unique solutions. Philips developed the
PeliCAN interface. The interface includes a receive FIFO.
Several chip manufacturers
now offer devices that com-
bine the benefits of Full
CAN and an FIFO. Examples
are the CANary from Atmel
and the TwinCAN from
Infineon Technologies.
The most powerful
approach is a Full CAN
implementation with a dedi-
cated FIFO for each single
message object (see Figure 4).
The Philips XA-C37 serves
as an example. Although
powerful, these are also the most com-
plex controllers to configure, especial-
ly if each individual FIFO can be
freely located in RAM and can be of
individual lengths.
Another option is to take a Full CAN
implementation and be able to con-
catenate message objects to a FIFO.
Instead of one message object having
one buffer, a FIFO can be formed by
borrowing the buffers of other message
objects. Although fairly flexible, the dis-
advantage is obvious: with each buffer
added to an FIFO, one message object
42
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
ter match, the incoming
message is moved into the
FIFO buffer. An interrupt
request to the MCU is made
depending on the configura-
tion—either a certain fill-
level is reached or a high
priority filter received the
last incoming message.
Even if such a FIFO can
only hold 64 bytes, it is still
big enough to improve the
back-to-back scenario men-
tioned earlier. If the FIFO is
configured to cause an interrupt with
every single incoming (matched) mes-
sage, the MCU has at least 500 bit
times until the FIFO will overflow.
That’s about 10 times more time
available to the MCU than with Basic
CAN or Full CAN implementations.
On the downside, messages in the
FIFO cannot overtake each other. So,
if the FIFO already contains several
messages and an additional but high-
priority message comes in, the MCU
first needs to process all messages pre-
viously stored in the FIFO before it gets
access to the high-priority message. In
a Full CAN interface, the order that
message objects are checked is up to
the interrupt service routine and it
would be possible that a higher priori-
ty message can overtake previously
received lower priority messages.
The latest developments do not
have standardized names because chip
manufacturers came up with their
own customized improvements for
the CAN interfaces. Philips provides a
solution with PeliCAN (with the peli-
can’s beacon functioning as a FIFO).
Bus interf
ace
CAN
protocol
controller
Status control
registers
Message
object 0
Message
object 1
Bus interf
ace
.
.
.
FIFO 0
FIFO1
FIFO n
Message
object n
.
.
.
Figure 4—
Now this is what you really need. The CAN controller shown in this
block diagram combines the benefits of both Full CAN as well as FIFO.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
43
Olaf Pfeiffer holds a degree in
Technical Computer Science from
Co-Op University of Karlsruhe,
Germany. He frequently conducts
seminars about embedded network-
ing and internetworking. He is one of
the founders of the Embedded
Systems Academy (www.esacade-
my.com) and represents the CiA non-
profit organization in America. You
may reach him at us-office@can-
cia.org.
is lost. So the value of this feature
increases with a high number of mes-
sage objects, but decreases if the num-
ber of message objects decreases, too.
IN THE END
Many CAN controllers offer addi-
tional features such as extended error
reporting and diagnostic functions or
auto-data detection. For the scope of
this article a complete feature com-
parison was impossible, so I concen-
trated on the number one feature
essential to many CAN applications:
receiving messages.
Before choosing a CAN interface for
an application, do a worst-case analy-
sis. What is the fastest transfer rate
the node needs to support? How much
of the network traffic needs to be
worked on? How much additional
network traffic is there and can it be
completely eliminated by hardware
filters? Which percentage of the MCU
performance is needed for the CAN
communication and which percentage
is required by the real application run-
ning on that MCU?
Some online calculators that help
with worst-case CAN traffic calcula-
tions are available for free from the
Embedded Systems Academy (www.
esacademy.com/faq/calc/).
When it comes to transmitting
CAN messages, Full CAN style con-
trollers are advantageous compared to
CAN controllers that feature only one
transmit buffer. Having multiple, pre-
configured transmit buffers simplifies
transmitting reoccurring messages or
sending messages from different tasks.
Usually, multiple transmit buffers can
be configured to support CAN’s priori-
ty scheme—a higher priority message
to be transmitted can overtake a
lower priority message that was not
yet transmitted.
In case your application uses a high-
layer CAN protocol such as CANopen,
communication channels are already
CAN controller friendly. In CANopen,
for example, it is virtually impossible
to receive back-to-back messages using
the same identifier. There is only one
specific, optimized communication
mode (block transfer of large data
areas, supported by specialized, high-
end CANopen nodes) during which
back-to-back messages could occur.
In general, CAN controllers sup-
porting a combination of Full CAN
and receive FIFOs are the most desir-
able, although they are not always the
easiest to master. In any case, with
the help of this article you should
now be able to recognize if a particu-
lar CAN interface will jeopardize
your project by taking too much of
the MCU performance away from
your real application.
I
44
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
hey say that
time is nature’s
way of keeping every-
thing from happening at
once. In the same way, pipelines are a
microprocessor’s way of spacing
things out. From 8-bit thermostat
controllers to 64-bit UltraSPARC III
workstation heaters (oops, processors),
all microprocessors have a pipeline.
Whether you’re a programmer or a
hardware guy, if you want to know
what goes on inside your favorite
CPU, MCU, MPU, or DSP, start by
staring down the pipeline.
Processors have a lot to do and most
of them can’t get it all done in a sin-
gle clock cycle. There’s fetching
instructions from memory, decoding
them, loading or storing operands and
results, and actually executing the
shift, add, multiply, or whatever the
program calls for. Slowing down the
CPU clock until it can accomplish all
this in one cycle is an option, but
nobody likes slow clock rates. A
pipeline is a compromise between the
amount of work a CPU has to do and
the amount of time it has to do it.
Processors are a bunch of synchro-
nous circuits organized in a big daisy
chain, each one feeding the other. You
can double the clock rate of these cir-
cuits if you cut their workload in half.
Instead of doing a shift and an add all at
once, you can increase the clock rate by
inserting a latch or flip-flop between
these two operations. First the shift,
then the add. The flip-flop stores the
intermediate result between the two
and cuts the workload more or less in
half. However, you haven’t really
expedited the process; you’ve just cut it
into two parts. There’s no magic potion
that will make the shift circuitry or the
addition circuitry work any faster.
By the way, this explains part of the
big myth about PC clock speed: it real-
ly doesn’t matter much. If you don’t
know how much work is getting done
each cycle, what’s the big deal about
cycle time? PowerPC and Pentium
guys argue forever about this stuff.
PowerPC megahertz are not the same
as Pentium megahertz (or SPARC
megahertz, or MIPS megahertz, etc.) if
you’re trying to estimate performance.
But that’s a story for another day.
Okay, so you know that faster clock
rates lead to longer pipelines. But
which comes first, the long pipeline or
the high clock speed? The pipeline
does; high clock speeds are possible
because of long pipelines, not vice
versa. Processor designers set a clock-
frequency target, and then design a
chip around the number of pipeline
stages needed to hit that speed. Again,
because all processors are different,
some might need five pipeline stages
to hit 200 MHz, while another CPU
might need eight pipeline stages to hit
the same speed. It all depends on how
much work you have to divide up.
YELLOW BRICK ROAD
A long pipeline is not really a good
thing. It’s less of a benefit and more of
a liability because long pipelines cause
more problems than they solve. The
one saving grace of longer pipelines is
that they enable you to hit higher
clock frequencies, which is good for
marketing. But basically, pipelines are
a necessary evil.
Let’s take a look inside a typical
five-stage pipeline to see where the
demons are lurking. Figure 1 is an
example from an ARM7 processor, a
pretty simple and common RISC
design. RISC processors, by definition,
Starting Down the Pipeline
t
The best way to
approach a project is
with as much knowl-
edge as possible. Do
you know everything
there is to know about
microcontrollers? In
Part 1 of Jim’s two-
part article, he teach-
es us a lesson about
pipelines, the key
ingredient in micro-
controllers.
Jim Turley
FEATURE
ARTICLE
Part 1: Hyper-, Super-, Whatever-Pipelines
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
45
called load-use penalty. Let’s say one
instruction loads a value from memory
and the next instruction adds it to
another number. The load happens in
the second pipeline stage but the usage
(the addition) happens in the third stage
of the next instruction. Do you see the
inherent one-cycle delay? Even if the
load happens immediately (which it
won’t), the pipeline has to stall for one
cycle until the loaded value makes it
to the right place in the pipeline. A
really good C compiler will spot these
dependencies and try to move the load
up a few slots in the program.
Related to the load-use penalty is
the use-load penalty. Suppose one
instruction adds two numbers togeth-
er and the next instruction takes that
result and adds a third number to the
total. The first instruction will calcu-
late its answer in the execute stage,
while the second instructions is still
in the read stage. But wait, the second
instruction has nothing to read
because the answer it needs hasn’t
been stored yet. On the next clock
cycle, the first instruction will store
its result, so now the second instruc-
tion can proceed. On the third clock
cycle, the second instruction can cal-
culate its sum but it has already lost a
cycle waiting. Some processors avoid
this hazard with a special bypass path
from the execute stage back to the
read stage. This problem happens
often enough that it’s worth a few
extra gates and some wire to fix it.
The execute stage can be tricky. This
is where the heavy lifting is done, so
this has some of the most complex cir-
cuitry. Most CPU instructions are han-
dled in a single cycle here. Some may
take a few extra cycles. Multiplication,
for example, is complicated enough that
most chips need a few extra cycles.
Floating-point operations (if your chip
supports them at all) will definitely be
spending some extra quality time here.
Square-roots and long division can take
dozens, or even hundreds, of cycles. In
those cases, the other pipeline stages
stall while the execute stage crunches
on a hard problem.
Even the final write-back stage can
cause stalls. It’s like the reverse of the
fetch stage and susceptible to the
same memory delays. Any time the
are simpler than CISC processors such
as the ’186 or 6805, so they make good
example cases to put on the slab for a
little comparative anatomy.
The first stage of this pipeline (and
of most processors) fetches, or loads,
one instruction from memory.
Depending on how fast or slow the
memory ROMs are, this might actual-
ly take longer than one pipeline stage
or one clock cycle, and therein lies the
first problem. What if the processor is
running at 10 MHz (100-ns cycle time)
but the ROMs take 300 ns to respond?
You stall the processor. Pipeline
stalls are the bane of every processor
and they can’t always be avoided. In
this case, the processor would mark
time and clock its registers, but not do
any useful work until the ROM pro-
vided a new instruction. Two or three
cycles would be wasted.
Stage two (decode) cracks the
instruction word and uses it to enable
multiplexers, latches, and whatever
else is necessary for that instruction.
At this point the processor can tell
what the instruction is (add, subtract,
shift, load, etc.) so it enables and dis-
ables the parts of the processor (adder,
shifter, etc.) that will be needed.
Stage three (read) loads one or two
operands from the CPU’s on-chip reg-
isters, if required. For example, a mul-
tiply instruction needs two numbers
(usually from accumulators or registers
in the chip) to multiply. These regis-
ters were presumably loaded through
previous instructions in the program.
The read stage routes these values
from their registers into the adder or
multiplier, etc. for the next stage.
Stage four (execute) does what it
sounds like. This is where the algorith-
mic logic unit (ALU) adds, subtracts,
shifts, rotates, or does whatever else it’s
supposed to do. The exact operation is
controlled by instruction bits that were
cracked out in the decode stage.
Stage five (write back) stores the
result of the execute stage, probably in
another register. If the result is sup-
posed to be stored in memory instead
of a register, this stage handles that,
too. In that case, the processor is like-
ly to stall for a few more cycles wait-
ing for the external memory to process
the store (write) transaction.
There you have it. These five stages
are pretty much inviolate; every
processor has them although the exact
instructions that processors can execute
change from processor to processor.
THE DARK SIDE
So where are the problems? There
are quite a few, starting with the fetch
stage. Because external RAMs or ROMs
are probably slower than your proces-
sor (Moore’s Law has not been kind to
memory vendors), you’ll probably stall
every single time you fetch an instruc-
tion. That’s like an elephant breathing
through a straw, and why instruction
caches are so popular for all but the
slowest CPU chips. Caches provide a
little bit of fast (but expensive) memory
close to the chip, where it can supply
an instruction as soon as it’s needed.
The decode stage is usually clear of
hazards unless it’s a complicated CISC
processor. CISC instructions are, well,
complex so they sometimes take a lit-
tle time to untangle. AMD’s upcoming
Hammer 64-bit processors take two to
five pipeline stages (out of 12) just to
decode ’x86 instructions into some-
thing intelligible. This stage is also
where branch instructions are decod-
ed, which we’ll get to in a minute.
The read stage can be free of delays
because it’s not hard to transport a few
bits across the chip. That is, unless,
you’re talking about Itanium. Intel’s
newest processor is so big that it
requires two clock cycles (at 800 MHz)
just to read data from its own registers.
The real hazard with the read stage is
loading from memory instead of from
registers. Like any external access, this
can cause stalls. Finally, there’s the so-
Time
1
2
3
4
5
F
etch instr
uction
Decode instr
uction
Read registers
Ex
ecute instr
uction
Wr
ite bac
k results
Figure 1—
A typical RISC processor uses a five-stage
pipeline, in which each instruction takes five clock
cycles to pass through the processor.
fetching code from that point instead
of their normal straight-ahead mode.
Forward branches can be ignored
because the processor fetches straight
ahead by default anyway.
Incorrectly predicting a branch
won’t do anything wrong or cause
any problems with software, it just
slows down processing and robs per-
formance. This either/or prediction
isn’t all that elaborate and has been
wrong plenty of times, but it’s still
better than nothing.
The next step is static branch pre-
diction, where you, the programmer,
provide a hint to the processor as to
whether or not you think a particular
branch is likely to be taken. This
requires a processor with two forms of
branch instruction, a branch-likely and
a branch-unlikely form. Without these,
there’s no static branch prediction.
Moving up to the next level, there’s
dynamic-branch prediction. This is
actually an attractive option and the
source of a lot of innovation. In its
simplest form, dynamic-branch pre-
diction consists of a 2-bit counter
that the processor maintains for each
branch in the program. (Realistically,
there aren’t enough counters in a
CPU to keep track of every branch,
so a limited set of counters is distrib-
uted among the branches using
caching tables.)
Each time the processor executes a
given branch, it records whether that
branch was taken or not taken by
incrementing or decrementing the
counter. The counter saturates at its
minimum and maximum values, 00
and 11, respectively. Over time, the
counter will show that a particular
branch is consistently taken or consis-
tently not taken (see Figure 2).
The processor uses this history to
make its decision and redirect its nor-
mal fetch path. The beauty of this sys-
tem is that it reflects the real-world
behavior of the code, and it can
change over time if the system or the
program starts behaving differently.
More elaborate branch-prediction
systems use more bits (bigger coun-
ters), more counters (for more branch-
es), and even multiple different predic-
tion algorithms, which are then
weighted and recorded in real time.
46
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
processor has to access another chip,
there’s the potential for stalling. This
is why data caches are just as popular
as instruction caches. The cache gives
the processor a chance to stuff its
results in the cache and worry about
memory transactions later.
OUT ON A LIMB WITH BRANCHES
The biggest problems with pipeline
stalls, by far, are branch and jump
instructions. Any time a program
changes direction it upsets the proces-
sor. The longer the pipeline, the worse
the problem gets.
Processor pipelines are like railroad
trains: once they get up to speed, they
run smoothly, but it’s hard to make
them change direction. The bigger and
longer the train is, the harder it is to
slow it down or make a sudden turn.
Railroad engineers need to know well
ahead of time if their train is expected
to turn off the main line. You can’t
surprise a train traveling at 100 mph
and expect it to turn on a dime. The
same goes for processors. They run
great in a straight line, but any devia-
tion from that path (e.g., a jump or a
branch instruction) causes all kinds of
problems. Metaphorically, you have to
back up the train and start over.
Processors are pretty stupid, really.
After all, they’re just a bunch of syn-
chronous circuits. They fetch instruc-
tions from memory in sequence, one
after the other, and stuff them into the
pipeline. Fine and dandy. But eventual-
ly, along comes a branch instruction
that says, “Start fetching instructions
from over there, instead.” Now the
processor has to eliminate, or flush,
instructions from its pipeline.
At least one instruction (the one
immediately after the branch) has
probably already been fetched from
memory and is through the first or
second stage of the pipeline. That one
needs to be thrown away for sure
because it’s not really supposed to be
executing. If the processor executed
that instruction, it would cause a pro-
gramming error. The processor may
have to flush several instructions if it
has a long pipeline (more than about
five stages). Then, it has to fetch new
instructions from the new memory
location, which takes even more time.
It gets even trickier. For really fast
processors (think Athlon or Pentium 4),
the chip might not realize it has fetched
a branch until it’s too late and some of
the subsequent instructions have
already been through the pipeline and
actually finished executing! Now
you’ve got a worse problem: how do
you undo the work already done? This
is where advanced techniques like reg-
ister renaming, load/store queues, and
committed state come in, but that’s a
topic for another article.
These branches cause a pipeline bub-
ble, where one or more empty stages
in the pipeline have to be flushed out,
undoing useful work and wasting
time. Pipeline bubbles are always at
least one stage/cycle long and usually
longer. A good rule of thumb is that
branch-delay bubbles are about half
the total length of the pipeline.
BRANCH PREDICTION
You could solve this problem with
branch prediction. If the processor
could somehow tell where a branch is
going to go, it can start fetching
instructions from the right place
instead of stupidly assuming that
everything will run in a straight line.
The bad news is that about 20% of all
programs are branches. The good news
is that some branches have fairly pre-
dictable behaviors.
Statistics show that most backward
branches are taken (that is, they loop
back to the top of a routine) and that
most forward branches (those that jump
ahead in the program) are not taken.
Armed with this knowledge, processors
can assume that any backward branch
they encounter will be taken and start
Strongly
taken
Strongly
not taken
Weakly
taken
Weakly
not taken
Figure 2—
A typical 2-bit branch-prediction algorithm
remembers whether or not a branch was recently taken
and uses that history to make the next prediction.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
47
Expect this niche of digital design to
advance rapidly as Motorola, Intel,
AMD, and the other CPU vendors
strive mightily to improve the per-
formance of their processors through
more accurate branch prediction.
CACHE WITHDRAWAL
Knowing (or at least, predicting)
whether or not a branch will be taken
is half the battle. The other half of
the battle is knowing where the
branch will branch to. Fortunately,
this is pretty easy because it’s record-
ed in the program itself. Every branch
has to go somewhere (its branch tar-
get); it’s just a matter of devoting
transistors to finding out where.
In binary code, most branches are
encoded with a positive or negative
offset that tells the processor to jump
forward or backward by some
amount. It’s easy enough to calculate
the target address using this offset. It
gets tough when the branch target is
specified with a register (e.g., “branch
to the address held in AX”) because
the value of that register might
change without notice. Besides, even
if the processor does know where the
branch target is, it still takes time to
fetch new instructions from there.
Enter branch-target buffers. A
branch-target buffer (BTB) is yet
another special cache within the chip
that stores two things: the target
address of the last few branches and
the first few instructions from that
address. This way, the CPU can get a
head start on executing code immedi-
ately after a branch. If it’s lucky, the
processor can skip immediately to
the instructions pointed to by the
branch without missing a beat—or a
clock cycle. The first few instruc-
tions in the BTB should be enough to
fill the pipeline and cover the time
required to start refilling it from the
new target address.
BANZAI PIPELINES
Next month, I’ll look at some of the
crazier pipelines currently in produc-
tion, such as the Pentium 4, Itanium,
Athlon, PowerPC, and so on. It’s sur-
prising the lengths to which some
Jim Turley is an independent analyst,
columnist, and speaker specializing
in microprocessors and semiconductor
intellectual property. He is the former
editor of
Microprocessor Report and
Embedded Processor Report and host
of the annual Microprocessor Forum
and Embedded Processor Forum con-
ferences. You may write to him at
jim@jimturley.com or visit his web
site at www.jimturley.com.
designers will go (or have to go) to
speed up their processors. And as
pipelines get longer the hazards
become more complex and subtle.
Athlon, for example, devotes most of
its long pipeline to figuring out what
it really wants to do. The doing takes
only a single pipeline stage.
Then there’s superscalar, multi-
scalar, super-pipelining, hyper-thread-
ing and plenty of other odd terms for
features deliberately obscured by the
marketing department. The simple
five-stage pipeline seems to be on its
way out and even “simple” RISC
designs are loaded with complexities.
I
50
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
e introduced the
RoCK in the last
two issues, and thus
far we’ve covered the
RoCK’s specifications and circuitry (see
Photo 1). In this issue, we’ll describe
the programming scheme for the
Robot Conversion Kit. Behavior-based
programming is the modern robot
control technique that gives the RoCK
much of its muscle and versatility.
Behavior-based programming was
inspired by bugs. Insects perform
amazing feats. They navigate, find
food, and evade predators under all
sorts of adverse conditions. And they
accomplish these things using less
computational might than is available
in a common desktop computer. By
the mid-1980s it was clear to robotics
researchers that dumb bugs could put
our best robots to shame.
A principal problem for robots of
that period was their brittleness. In a
static environment with every mathe-
matically described object nailed to
the floor, a robot might be programmed
to perform an impressive chore. But
change the position of one object
while the robot was in motion or
demand that the robot’s speed exceed
that of a snail and the robot dramati-
cally revealed its shortcomings.
To address these deficiencies, the
first behavior-based robot program-
ming scheme was proposed by Rodney
Brooks in 1986. [1] Behavior-based
programming turned the then-domi-
nate modeling/planning paradigm on
its side. Behavior-based programming
eschewed complex mathematical
models of the world and detailed
motions plans in favor of reactive
responses and simple computations
performed in parallel.
A behavior-based system consists of
a number of simple, independent
behaviors. Each of these primitive
behaviors has an area of expertise but
no behavior by itself provides all of
the control the robot needs to accom-
plish a given job. However, when the
outputs of the component behaviors
are combined, an overall global behav-
ior emerges. We call these global
behaviors tasks.
When researchers began building
behavior-based robots they discovered
many advantages. Behavior-based
robots can react quickly to changes in
their environment, they can respond
adaptively to unexpected situations,
and they require little computing
power. All of these features make the
behavior-based approach ideal for
researchers and hobbyists alike.
You can think of each primitive
behavior programmed into a behavior-
based robot as a simple-minded expert
system. A given behavior knows what
to do in only a limited set of situa-
tions. In all other situations, that
RoCK Specifications
w
It’s easy to see why
Joseph and Ben’s
Robot Conversion Kit
was successful in the
2001 Design Contest.
So far, they’ve cov-
ered the specifications
and circuitry, and now
it’s time to describe
the fundamentals of
the module’s behav-
ior-based program-
ming scheme.
Joseph Jones & Ben Wirz
FEATURE
ARTICLE
Part 3: Behavior-Based Programming
Photo 1—
The RoCK’s circuit board is shown here. You
connect the battery and motors from your RC base to
the blue terminal block at the right.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
51
might take the light levels
sensed by left- and right-
pointing photocells, compute
the difference, multiply by a
gain factor, and then send the
value to the motors to control
which way the robot rotates.
Behaviors are executed in
such a way that they seem to
operate in parallel. Each
behavior constantly computes
whether it wants control of
the robot and, if so, what it
wants the robot to do. Each
behavior carries out this com-
putation in complete igno-
rance of the internal state of
all other behaviors.
The job of Arbiter is to
decide which behavior com-
mands reach the motors.
The RoCK’s Arbiter function
does this using a simple
fixed-priority scheme.
Arbiter steps through the
output from each behavior. The high-
est priority behavior that wants to
control the robot wins.
The behavior priority list, along
with the particular settings of relevant
parameters, specifies a task. A task
can be thought of as job that you want
the robot to perform.
Our system allows each task to
assign control of one parameter to the
user potentiometer. This allows you
to adjust one key aspect of the robot
(say, robot speed or light follower
gain) without connecting the RoCK to
the host computer.
We think of all of the software com-
ponents in Figure 1 as running in par-
allel. If this were actually the case,
there would be no need for a sched-
uler. The scheduler creates the appear-
ance of parallelism on a microproces-
sor that operates serially.
The RoCK implements a type of
parallelism known as cooperative
multitasking. Cooperative multitask-
ing makes the scheduler’s job especial-
ly easy. In this scheme, each parallel
element (each behavior, the Arbiter
function, the utility functions that
update sensor values, and so on) runs
for a brief time and then returns con-
trol to the scheduler. The scheduler
then calls the next element. Thus the
behavior does not know what
to do, and in those inapplica-
ble situations, the behavior
does nothing.
For example, suppose that
you have written an uncom-
plicated primitive behavior
called Escape. Escape is
designed to help your robot
recover from a collision.
When a collision occurs,
Escape issues commands to
make the robot back up and
then spin a little in one direc-
tion. But if no collision has
occurred recently, Escape has
no idea what to do and so it
sends no commands to the
robot’s motors.
The simplicity of the primi-
tive behaviors means that
they can be programmed
quickly, they are easy to
debug, they require little code
space, and with little internal
state they consume only modest
amounts of RAM. The sophistication
and power of a behavior-based system
comes from stitching together primi-
tive behaviors in such a way that some-
thing complex and interesting emerges.
What happens when two or more
behaviors think they know what to do
at the same time? Imagine that you’ve
programmed two behaviors. The first,
called Follow, uses the robot’s photo-
cells to home in on bright lights. The
second behavior, called Avoid, evades
collisions using IR sensors. Suppose
Follow is issuing commands to home
in on the flashlight you’re holding
when Avoid begins to produce con-
flicting commands intended to move
the robot away from an obstacle
Avoid has detected. Who wins?
Behavior-based systems rely on arbi-
tration. In the RoCK, a dedicated
function called Arbiter evaluates all of
the commands intended for the
robot’s motors and picks a winner.
The RoCK uses a fixed-priority arbi-
tration scheme. When you command
the robot to perform a particular task,
that task sends Arbiter a list of behav-
iors in order of decreasing priority. If
two or more behaviors issue com-
mands at the same time, the behavior
with the higher priority gets control
of the robot and commands from the
lower priority behavior are ignored.
Assume that during programming
you gave Avoid a higher priority than
Follow. The global behavior that then
emerges is one where the robot follows
the flashlight beam toward you but
swerves around any obstacles it
encounters along the way. If you
reverse the priority list giving Follow
a higher priority than Avoid, you
could use the flashlight to force the
robot to push small objects toward you.
Turn off the flashlight and the robot
will avoid objects as it wanders around.
For more details on behavior-based
programming, you may want to read
Mobile Robots: Inspiration to
Implementation
. [2]
RoCK SOFTWARE
The RoCK’s code structure is shown
in Figure 1. The software was written
in C and compiled using ImageCraft’s
ICCAVR compiler. Debugging was
accomplished by running the code on
the RoCK circuit board and using
Atmel’s AVR Studio simulator.
BEHAVIORS
Behaviors transform sensory inputs
into motor control commands. For
example, a light-following behavior
Task 1
Task 2
Task 10
User Task 1
User Task 4
Sensor
values
Parameter
values
Task
selector
Beeper
control
Behavior 1
Behavior 2
Behavior 8
Scheduler
Arbiter
Motor
control
Figure 1—
This simplified diagram shows the structure of the software. Primitive
behaviors run constantly. Each uses the current sensor values and a set of
parameters to compute an output for the robot’s motors. The Arbiter function
decides which behavior is permitted to control the motors. The Arbiter bases its
choice on a priority list supplied by one of the tasks via the user-controlled task
selector. The task selector also decides how the beeper is controlled. The user
tasks operate in a way identical to the other tasks except that user task specifi-
cations are stored in EEPROM rather than flash memory. The scheduler runs
one behavior after another and keeps the sensor values updated.
Remote is implemented using only
the Joystick behavior. So, when using
this task, you are responsible for pre-
venting collisions.
USER TASKS
User tasks are tasks that you config-
ure via the host computer. To program
a user task you need only specify a
behavior priority list for the Arbiter
function and choose values for the
associated parameters. After you’ve
programmed it, you can select the
user tasks in exactly the same way as
the built-in tasks.
The RoCK’s primitive built-in
behaviors are summarized in Table 2.
The Dance behavior causes the robot
to move according to a stored pro-
gram. A dance is a sequence of motion
commands that specify the robot’s
turn angle and the duration of motion
at that angle. A motion command is
stored in a single byte using the for-
mat: [tttfffff], where ttt is 3 bits of
duration information and fffff is 5 bits
of angle information. Dance has one
parameter, dist_factor. For each
motion step, Dance multiplies
dist_factor by the duration bits to
compute the length of time the robot
holds the associate turn angle. One
dance program is built into the
RoCK, but you can program and
store in EEPROM a second dance of
over 100 steps.
The IR_follow and VL_follow
behaviors are similar in operation.
The former computes robot motion
using data from the left and right IR
sensors, the latter uses information
from the left and right photocells.
These motion computations are made
using a general technique that pro-
vides an arbitrary linear mapping from
a two-degree-of-freedom (DOF) input
into a two-DOF output. The tech-
nique also computes whether or not
to request control of the robot.
IR_follow and VL_follow both com-
pute values for their local variables
action
, translation, and rotation. The
action
variable specifies whether the
behavior wants to control the robot. If
the value of action is zero or less,
then no command is output—the
behavior gives up control to the next
lower priority behavior. If action is
52
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
RoCK’s scheduler consists of a list of
subroutines that are called endlessly
one after another.
The low overhead of such a system
makes it expeditious. On average,
the RoCK gives each behavior a
chance to run over 500 times per
second. One downside to cooperative
multitasking is the discipline it
requires of the programmer. Each
element must be designed to com-
pute for only a short time, then
return control to the scheduler. A
behavior that runs too long will
freeze out all of the other behaviors.
TASK SELECTOR
To select a particular task, hold
down the user button while adjusting
the user potentiometer. The index of
the selected task is indicated by the
pattern displayed on the RoCK’s four
LEDs. When you release the select
switch, an index specifying the cho-
sen task is written into EEPROM.
When the select switch is released or
whenever the processor is restarted,
the index of the selected program is
fetched from EEPROM. This index is
used to cause the values that instan-
tiate the corresponding task to be
written into RAM.
The set of tasks built into the
RoCK along with the behaviors that
implement them are listed in Table 1.
Let’s take a look at the descriptions
of each task.
The Theremin task is the only task
that does not make the robot move. It
uses the photocells and beeper to sim-
ulate an early electronic musical instru-
ment, the theremin. The difference in
the light level falling on the left and
right photocells controls the frequen-
cy of sound emitted by the beeper.
Waltz makes the robot move in a
programmed pattern while a tune plays
on the beeper. The user potentiometer
controls robot speed. Like most tasks,
Waltz specifies the Escape behavior as
its highest priority behavior. This
means that if the robot bumps into
something while Waltzing, the robot
will attempt to extricate itself before
continuing with the dance.
The Wimp task gives the robot a
shy personality. The robot sits still
until an object moves close enough to
be sensed by the IR detectors. When
this occurs, the robot backs away.
Schizoid gives the robot a nervous
personality. The robot cruises in a
straight line, occasionally spinning or
turning randomly. The interval
between these events is controlled by
a parameter. Increasing the parame-
ter makes the robot seem calmer;
decreasing the parameter makes the
robot more frantic.
The Pounce task has the robot sit in
one spot until something comes near
enough to be picked up by the IR
detectors. The robot then races full
speed forward until it collides with
the encroaching object.
When running the Moth task, the
robot uses the difference in the left
and right photocells to servo toward
the brightest light. The robot will
thus respond as if it were a moth
homing in on a flame.
The Mouse task enables the robot
to follow walls. Using its IR detectors,
the robot cruises along a wall going
through doorways and turning away
from inside corners.
Chicken causes the robot to use its
IR sensors to play chicken. The robot
travels along at high speed and turns
away just before colliding with
objects it encounters.
When the room is dark, the RoCK
waits patiently while in Roach mode.
But, when the light is switched on,
the RoCK races toward a dark spot.
Safely concealed in the shadows, the
RoCK comes to a halt.
The Remote task allows you direct
control of the robot when the robot is
connected to the host computer.
Table 1—
A task is implemented as an ordered list of
behaviors. The table summarizes the relationship
between the RoCK’s built-in tasks and the behaviors
that instantiate them.
Index
Task
Behaviors
1
Theremin
Beeper
2
Waltz
Escape, Dance
3
Wimp
Escape, IR_follow
4
Schizoid
Escape, Boston, Cruise
5
Pounce
Escape, IR_follow
6
Moth
Escape, VL_follow
7
Mouse
Escape, IR_follow, Cruise
8
Chicken
Escape, IR_follow, Cruise
9
Roach
Escape, VL_follow, IR_follow
10
Remote
Joystick
11–14
User
(programmable)
54
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
positive, then the behavior outputs
translation
and rotation commands.
Translation
is the speed of forward
motion; rotation is the signed rate of
robot rotation.
Three sets of three coefficients
(parameters) are used to compute the
triplet of translation, rotation, and
action
from the input values. If the
inputs are L and R (left and right IR
detection values or left and right
photocell values), the computed out-
puts are:
Translation = a × (L + R) + b × (L – R) + c
Rotation = d × (L + R) + e × (L – R) + f
Action = g × (L + R) + h × (L – R) + i
To specify the behavior of the robot,
you assign values to the coefficients a
through i. For example, suppose you
wish to instantiate a light-following
behavior that is always active. You
ensure that action is always greater
than zero by setting: g = 0, h = 0, i = 1.
This means VL_follow will always
return a motion command. Next,
you cause forward motion to always
occur by setting: a = 0, b = 0, c =
speed. Finally, you force rotation to
aim at the light with the parameter
set: d = 0, e = gain, f = 0.
To reiterate, with these parameter
settings, when action = 1, VL_follow
always wants control. When transla-
tion = speed, the robot moves forward.
When rotation = gain × (L – R), the
rate and direction of rotation depends
on the difference in light levels seen
by the photocells.
A negative value for e, the rotation
gain, causes the robot to seek dark-
ness rather than light. With a different
set of parameter values, you can cause
the robot to move toward or away
from a light until a certain
light intensity is reached.
Choose action parameters as
before, such that action = 1.
Set rotation parameters to:
d = 0, e = 0, f = 0. Compute
translation
with a = –1, b = 0,
c = threshold.
In this case, if the robot is
pointed at a distant light
source (L + R is near zero) the
nonzero value of c makes the
robot move forward. As the
robot gets closer to the light, L + R
increases so that translation goes to
zero. Rewriting: translation = thresh-
old – (L + R). The robot moves for-
ward until the translation velocity
goes to zero at some distance from
the light determined by a threshold. If
the robot gets too near the light,
translation
becomes negative and the
robot backs up.
Finally, consider the situation just
described but change the rotation
parameters to: d = 0, e = 0, f = small
value. Nonzero f now causes the
robot to spin slowly while alternately
moving closer to or farther from the
light. The path the robot follows in
this case should be interesting but
hard to predict.
The Boston behavior causes the
robot to drive erratically. Most of the
time Boston outputs no motion com-
mands. Occasionally, however, Boston
specifies a rotation, backup, or other
motion. The parameter time_
between_events specifies the number
of seconds between such events. The
event_duration parameter determines
how long each motion event lasts. A
random factor is included in the
motion computation to make the
behavior less regular.
Cruise ignores all sensors and
makes the robot move at a constant
velocity. Cruise has one parameter
pc_dir, the desired direction or turn
angle of the robot. To make the robot
turn at an arbitrary angle, we employ
a crude sine/cosine utility. We let
left_velocity = speed × sin(theta) and
right_velocity = speed × cos(theta).
Theta is represented by pc_dir scaled
to the range zero to 255 and offset
such that when pc_dir equals 128, the
robot goes straight. The choice of off-
Table 2—
Each behavior can have a number of parameters that
affect the behavior’s output. Most parameters are unique to a par-
ticular behavior. The speed parameter, however, is used by a num-
ber of behaviors.
Index
Behavior
Parameters
1
Dance
dance_tune_index, tempo, speed
2
IR_follow
speed, nine gain parameters (see text)
3
VL_follow
speed, nine gain parameters (see text)
4
Boston
time_between_events, event_duration
5
Cruise
speed, turn_angle
6
Escape
backup_dist, spin_dist, fwd_dist
7
Joystick
turn_angle, speed
8
Beeper
source, tempo
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
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
55
set is made so that when pc_dir is
connected to the user potentiometer,
centering the potentiometer causes
the robot to drive forward.
The Escape behavior attempts to
extricate the robot after it has collided
with an object. When the collision
detector triggers, Escape responds by
commanding the robot to back up,
spin in place, then go forward before
releasing control. The duration of each
of these steps is controlled by a param-
eter. The final go-forward step is
included to prevent the robot from
immediately returning to the situation
that caused the bump in the first place.
The Joystick behavior allows you to
directly control the robot when the
serial cable is connected. The robot’s
speed and heading are obtained direct-
ly from the host computer.
BEEPER BEHAVIOR
Rather than build a second arbitra-
tion method for the beeper, we require
that each task specify one way of con-
trolling the beeper. Tasks can pick
one of the following six ways of con-
trolling the beeper.
Flash_tune plays a tune stored in
flash memory. EE_tune plays a tune
you compose and stores it in EEPROM
(100-plus notes can be stored).
“Photocell difference” behaves like
Theremin; the beeper’s output fre-
quency is a function of the difference
in light intensity sensed by the two
photocells. “Photocell sum” beeper
frequency is a function of the total
light intensity; the brighter the light
the higher the frequency.
The Bumper task beeps in mono-
tone when a collision occurs. And,
the IR_detect task frequency depends
on the IR detector: no sound for no
detection, different tones for detections
by the left, the right, and both
detectors. Lastly, if you don’t choose a
task, the beeper is silent.
SERIAL INTERFACE
For programming and monitoring
purposes, your host computer con-
nects to the RoCK via a serial inter-
face. Transactions, always initiated
by the host, are restricted to
read/write operations in on-chip
RAM using a three-byte protocol
(3BP). This allows read/write access to
all system variables, all AVR control
registers, and all I/O lines.
During all transactions, the host
sends three bytes of data over the seri-
al line to the AVR and receives one
byte from the AVR in response. An
interrupt service routine (ISR) is trig-
gered by RXC (the serial receive flag)
each time a complete byte has been
received by the UART. The ISR uses a
pointer to store the byte just received
and then increments the pointer.
When the third byte has been received
(the pointer now equals three), the ISR
interprets the stored bytes and
responds. If a write operation is com-
manded, the ISR interprets two of the
bytes as an address and the third as
data. The ISR stores the data at the
indicated address in RAM and echoes
the data byte by writing it to UDR,
the UART data out register. If a read
is commanded, the ISR fetches the
data stored at the given address and
writes it to UDR.
56
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
RAM, the control registers, and the
general-purpose registers occupy loca-
tions $0000 to $025F in the data
address space. Thus, only 10 bits are
needed to address every location.
This is incorporated into the 3BP
data format that the host sends to
the AVR as follows:
Byte 1: [X-----ab]
Byte 2: [cccccccc]
Byte 3: [dddddddd]
where X represents the operation. A
zero means read, and a one indicates
write. Dashes represent bits that are
not interpreted. The variables a and b
are the two highest bits of the address,
and c indicates the lower eight bits.
The d characters represent data for a
write operation. The AVR ignores the
third byte in a read operation.
Data returned to the host has the
following format: Byte 1: [eeeeeeee].
Here, e is the echoed byte (the same
as d for a write operation) or e is the
data read from the requested address
for a write operation.
To write data to EEPROM, a func-
tion called eewriter is called during
each iteration of the main loop. This
function constantly examines certain
declared RAM locations. When you
use 3BP to write address and data val-
ues to these locations, the function
stores the data in EEPROM.
AWAITING PRODUCTION
The RoCK packs quite a punch into
only 8 KB of flash memory and it is
behavior-based programming that
makes such economy possible. Now
that you’ve learned the fundamentals of
this scheme and have seen an example
implementation, we hope you will be
encouraged to try this powerful
method in a project of your own.
I
Authors’ Note: We plan to offer the
RoCK for sale. Please check our web
site, www.wirz.com/rock/, for avail-
ability and additional information.
Ben Wirz also grew up in a small town
in the Missouri Ozarks. He studied
physics and electrical engineering at
Washington University in St. Louis,
and graduated in 1997. He is current-
ly employed as a senior electrical
engineer by iRobot in addition to run-
ning his company, Wirz Electronics.
You may reach him at ben@wirz.com.
REFERENCES
[1] R. Brooks, “A Robust Layered
Control System for a Mobile
Robot”, IEEE Journal of Robotics
and Automation,
RA-2 14-23,
April 1986.
[2] J. Jones, A. Flynn, and B. Seiger,
Mobile Robots: Inspiration to
Implementation
, A K Peters, Ltd.,
1999.
Joseph L. Jones grew up in a small
town in the Missouri Ozarks. He stud-
ied physics at MIT and received an BS
in 1975 and an MS in 1978. He took a
trip around the world, worked at the
MIT Artificial Intelligence Lab, and is
now senior roboticist at iRobot Corp.
You may reach him at jlj@irobot.com.
58
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
etween visits
from the usual
musically inclined
guests and deploying the
Atmel armed forces camped in the
Florida Room, it’s been a busy month.
Amidst the hustle, I realized that thus
far I’ve had no problems getting help
from the Atmel staff and the JTAG
ICE and STK500 development board
work perfectly together as an AVR
microcontroller development system.
In addition to the great Atmel hard-
ware, I’m using some awesome sup-
porting software products as well. I’ve
installed a new and more helpful ver-
sion of Atmel AVRStudio, and the
ANSI-based ImageCraft AVR C com-
piler has proven to be just as good as
AVR assembler when it comes to gen-
erating efficient AVR assembler code.
The future’s so bright I need to wear
RayBans. Some of the folks back home
in Tennessee would say that I’m as
happy as a hog loose in the corn crib.
I’ve been working toward putting
one or both of the AVR devices I have
in the Florida room on the Internet. In
addition to the ATmega163 and
ATmega16 parts, I’ve acquired some
ATmega128 micros as well. I don’t
have the STK501 plug-in that allows
the STK500 development board to
support the ATmega128 right now,
but I will try to get my hands on one
so I can do something down the road
with the heavy-duty ATmega128
micro. At this point in time, I’m sure
the ATmega16 and ATmega163 can
handle the application at hand. So,
with that let’s slip and slide our way
towards the Internet on the JTAG ICE.
AVR JTAG ICE
The JTAG ICE functionality is
enhanced with the new version 4 of
AVRStudio. With an ATmega16
mounted on the STK500 development
board and the JTAG ICE connected, I
have a full view of the ATmega16
internals. I can also debug my code
using ImageCraft’s ICCAVR C source
or the AVR assembler generated by
the ImageCraft AVR C compiler.
The JTAG ICE works its magic
using a concept called on-chip debug-
ging (OCD). Most of the microcon-
troller emulators that you and I have
encountered use a specialized bond-out
integrated circuit that contains the
CPU and I/O cores of the microcon-
troller it’s emulating. Thus, the code
is actually running on the bond-out
device, and the supporting emulator
hardware and software have the abili-
ty to reach into the bond-out and pull
out the microcontroller internals for
inspection and debugging. Instead of
depending on a bond-out device, the
JTAG ICE interfaces with the target
AVR’s internal OCD system via the
JTAG IEEE 1149.1-compliant interface.
Every AVR microcontroller with a
JTAG pin set houses OCD logic. The
JTAG ICE takes control of the target
AVR and controls the execution of the
firmware using the OCD logic via the
target’s JTAG interface pin set. Because
the code is actually running on the
real device, the target device’s original
electrical and timing characteristics are
retained. The JTAG ICE/OCD combi-
nation has several advantages over tra-
ditional emulator methods, but there
are some things this duo cannot per-
form. For instance, the trace buffer
function is not a part of the OCD.
If you’ve ever had to interface to
anyone’s emulator, you know that
there are some basic operations com-
mon to them all. The JTAG ICE is no
Still Swimming With
the STK500
Onto the JTAG ICE
b
Last month, Fred
introduced us to
Atmel’s STK500,
which is the starter kit
for the company’s
AVR flash memory
microcontrollers. This
month, he tackles
coding and debugging
with Atmel’s JTAG
ICE. He’s thrilled with
the result, so don’t
miss this follow-up.
Fred Eady
APPLIED
PCs
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
59
JTAG ICE. The
AVR OCD logic
has four registers
available that can
each store one
memory address.
One of the four
registers is
reserved by the
JTAG ICE for per-
forming the single
step function. That
leaves three of the
registers free for
you to use as hard-
ware break point
containers.
Before you start to get comfortable
with the JTAG ICE, three break point
registers doesn’t sound like enough. The
unique implementation of the three
free hardware break point registers
makes up for the seeming lack of break
point quantity. You can use each break
point as a general-purpose break point,
which gives you three traditional set
and clear break point types, or you can
use up to two of the three break points
as data break points with the leftover
break points remaining for general-
purpose use. If you want to get fancy,
you can dedicate two break point loca-
tions to a mask that operates against
the AVR’s SRAM or flash memory.
A general-purpose break point can
be placed anywhere, including any-
where in an assembler program or any-
where a valid statement resides in a C
program. The break will occur before
the execution of the code at the break
location. Data memory break points
are a tad more complex. You must
select one of three break point
modes, which consist of a combi-
nation of reading and writing the
data memory area (SRAM). Data
memory break points are invalid
for the Register file.
Because nothing is free, when
it comes to embedded computing
you pay for the data memory
break points by having to use a
symbolic variable-capable com-
piler or assembler. I’m using
ICCAVR so I’m covered if data
memory break points are in the
future. Another difference to
note is that the break occurs
different. When the AVR JTAG ICE is
in Run mode, code execution is not a
JTAG ICE concern. JTAG ICE polls
the running target looking for a break
condition. When a break is sensed, the
OCD goes to work and uses the JTAG
interface to reach into the target AVR
and pull out the same information a
standard emulator would. Remember,
the OCD doesn’t incorporate a trace
buffer function. So, all you get is
information captured at the time of
the break event, minus execution his-
tory up to that point.
When a break point is encountered,
program execution, as far as JTAG ICE
is concerned, is halted. But, because the
JTAG ICE doesn’t contain the CPU and
I/O core of the device it’s attached to,
the AVR I/O operations that were exe-
cuting at the break point continue to
run. The best example of this is the
ability of a standard emulator to trace a
UART transmit function bit by bit.
JTAG ICE will only see the result of
the operation because the I/O in
the target will complete the oper-
ation regardless of the break point.
Speaking of break points, the
AVR OCD can handle hardware
and software break points. AVR
software break points are placed
in the normal code path. The
instruction that resides at the
selected software break point
location is replaced by the break
instruction. When the software
break point is reached, the code
execution halts. To continue, a
start command must be issued to
the OCD. At that point, the actu-
al instruction at the break point is
executed and the code moves on to
completion or the next break point.
The AVR family is flash memory-
based as far as program memory is con-
cerned. So, using software break points
is not as healthy as using hardware
break points, in that every time you
change the break point in your code
you must reprogram the AVR as well.
The AVRs are good for at least 1000
program flash-memory write/erase
cycles. Theoretically, you can debug a
guaranteed 1000 times using software
break points exclusively. In my experi-
ence with flash memory-based micro-
controllers, this 1000-cycle limit is
conservative and I can recall only one
time that I may have exhausted a part
by reprogramming it beyond the pre-
scribed write/erase limits.
If you feel you will exceed 1000 limit
write/erase cycles during the develop-
ment of your project, go for the hard-
ware break point system offered by the
Photo 1—
UCSRC is at address 0x20. Note that the write to UCSRC was performed before the break point halted the code.
Photo 2—
There…I’ve gone and blown the warranty. By the way,
there’s nothing on the other side of the board.
branch/skip. This break point works
on a change of program flow. That
means that anything that interrupts
the normal flow of a program such as
jumps, branches, calls, skips, or inter-
rupt handling will generate a break
point after executing the instruction
that caused the break point.
I have used the three general-pur-
pose hardware break points and single
stepping for most of the debugging so
far. Despite the absence of certain
standard emulator features, the JTAG
ICE and AVRStudio version 4 do a
good job of telling you what’s going on
inside that target ATmega micro.
While I’m on the subject of what’s
inside, I could not resist taking my
JTAG ICE apart to see what makes it
tick. From left to right in Photo 2, the
first IC is a MAX232 RS-232 interface.
The 44-pin TQFP next to it is an
ATmega163 running at 7.37 MHz.
It really makes me feel good to
know that Atmel uses its own
stuff to build its development
tools. The large IC surrounded by
who knows what is a 74HC244D
octal buffer that is being protected
by a couple of ProTek Devices
SM16LC08 high-speed TVS diode
arrays. The rest of the high-rise
components and their strip malls
handle the JTAG ICE power details.
The bottom line is that the real
tricks are done with AVR firmware
and the AVRStudio front-end code.
USING THE JTAG ICE
The JTAG ICE comes with every-
thing you need to get you coding and
debugging quickly. Most of the JTAG
ICE installation process was a no-
brainer. But, the person or machine
that assembled the 10-pin JTAG inter-
face ribbon cable had me swinging at a
slider. Because the Atmel engineers
went to the trouble of color coding the
JTAG-to-STK500 development board
ribbon cable and meticulously detail-
ing the JTAG ICE JTAG header, it
would have been easy to just trust the
colors and connect the JTAG ICE to
the STK500 development board with
the brown lead being pin 1, the red
lead pin 2, and so forth.
If this isn’t your first time reading
my words in Circuit Cellar, you know
that I have an affinity for smoking
things. To avoid letting the magic out
60
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
after executing the instruction
when using the data memory break
point feature.
Masked break points use an
address base and address mask,
which are ANDed together to gen-
erate the break points. The address
base is a symbol name or a memory
address. The result of the AND is
then compared against the program
counter or data address to check
for a valid break condition. Setting
a bit in the mask to zero makes
that a “don’t care” bit position.
“Don’t care” bits always generate a
valid break point regardless of the
logic level of the corresponding pro-
gram counter or data address bit.
If the mask bit is a one, this forces
the program counter or data address
bit to be the same logic level as the
corresponding bit in the base address.
Think of the mask break point mask
in this way: If you set all of the bits in
the address mask high, only the base
address would generate a break point.
Conversely, if you set all of the mask
bits low, all of the addresses would
cause a break point. Like the data
memory break points, the masked
break points break execution after exe-
cuting the instruction at the break
point address. A real example of a
masked break point is depicted in the
double-wide screen shot in Photo 1.
There’s one more break point that
has absolutely nothing to do with the
general-purpose break points: break on
Photo 3—
At first I thought the STK500 development board was a
bit busy, but as I got more comfortable with it, all the bells, whis-
tles, and jumper blocks became part of my development process.
Photo 4—
I really found the Info feature handy while debugging my code. All of the registers and their bits are available in an easy-to-read format. I saved a lot of production
time by not having to look up registers and bits in the datasheets.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
61
of the little plastic boxes, I’ve started
checking everything and trusting
nothing. As it turns out, the ribbon
cable was assembled in the reverse
order with the brown lead represent-
ing pin 10 of the JTAG connector and
the black lead posing as pin 1. I
scratched my head, gathered my
thoughts, hooked the suspect JTAG
cable to a VOM, and shot the leads. I
wasn’t losing it; the cable was indeed
assembled backwards.
I continued on with the installation
process and connected the JTAG rib-
bon cable “backwards” and was able
to use the JTAG ICE without melting
it. I really don’t think I would have
harmed anything if I had not been
Photo 5—
For inquiring minds, here’s the whole enchilada. If you don’t have a dual-head setup, the various windows automatically interlock when you place them on the desk-
top. You can also compact and expand each window, so it is possible to have them all staged on the desktop.
62
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
site. The LCD will be accessible to you
via a Telnet session from wherever you
may be, 24 hours a day, 7 days a week.
I recently installed a higher resolu-
tion web cam on my web site at
www.edtp.com and have it pointed at
the ATmega16 Internet device you see
in Photo 6. A server is dedicated to
putting pictures of the ATmega16/
Packet Whacker Internet device from
that web cam on the Internet for you.
The idea is to allow you to use a
Telnet session to write to the LCD that
is being controlled by the Atmega16/
Packet Whacker Internet device. The
web cam puts you there live as you
are interfacing with the LCD.
As you can see from Figure 1, the
Packet Whacker takes much of the
complexity out of the hardware
design. I’m using an LCD as an out-
put device, but the idea behind it all
is that you can do anything with the
output pins that are not being used by
the Packet Whacker NIC.
Using the Atmel ATmega series of
micros makes this project easy to
modify as far as a microcontroller is
concerned. You could substitute an
ATmega128 in the schematic for the
ATmega16. The ATmega128 would
give you an additional 23 I/O lines
attentive. It just
wouldn’t have worked
until I corrected the
wiring. That’s really
the only problem I had
during the JTAG ICE
install. I was able to
obtain all of the latest
firmware and front-
end software from the
Atmel web site and
from there I was off to
the races. My AVR
development system
hardware is shown
naked in Photo 3.
I develop with a
dual-head monitor sys-
tem. This allows me to
put the ICCAVR appli-
cation on the right
monitor and AVR
Studio on the left mon-
itor. The ImageCraft
AVR C compiler IDE is
excellent. I am able to
segregate my code using projects. I cre-
ated a separate test project to actually
code and debug my AVR C code one
module or line at a time. In the same
ImageCraft IDE window structure, I
opened another window of C source
that would eventually be the complet-
ed working code that would be loaded
into the ATmega16. The final working
code window code is not included in
the test project. I debugged code snip-
pets in the test project and moved the
working routines over to the final code
window as I finished them. All of the
code writing and compilation was per-
formed on the ImageCraft screen.
The left display is where all of the
JTAG ICE programming and debug-
ging took place. The STK500 develop-
ment board has an on-board ISP pro-
gramming header to allow the socket-
ed AVR to easily be programmed using
AVRStudio. The JTAG ICE is a good
AVR programmer as well. I’ve includ-
ed a 10-pin ISP header on the AVR
Internet device. This will allow me
(and you) to program the ATmega16 in
socket using any device that supports
AVR ISP, like the Kanda dongle.
I found myself going from datasheet
to user’s guide to application notes
often during the development process.
I was pleased to discover the Info fea-
ture of AVRStudio 4. With this feature,
I could simply point at an AVR subsys-
tem in the Workspace window and get
a short description of what the subsys-
tem was made of and how it worked.
Also, being able to see the bit structure
for a register or I/O location helped
keep the manuals closed. Photo 4 is a
doublewide shot of the result of execut-
ing a write to the USCRB USART reg-
ister, while Photo 5 is a panorama of
the various windows available to you
during code development.
ATMEGA16 IN CHARGE
The final step of the AVR Internet
project takes the ATmega16 from the
STK500 development board and mates
it with an appropriate Internet-capable
interface. I’ll couple the ATmega16
loaded with a minimal TCP/IP stack
and Telnet application with a Packet
Whacker and a backlit LCD. The
Packet Whacker is a microcontroller
NIC based on the Realtek RTL8019AS
that will allow the ATmega16 to inter-
face with a router in the Florida room
that is attached to the Internet. For
those of you not familiar with the
Packet Whacker, there’s lots of Packet
Whacker info on the Circuit Cellar web
Figure 1—
There isn’t much here to call play-by-play. The Packet Whacker is a self-contained NIC module that’s interfaced to a self-con-
tained TCP/IP-enabled microcontroller.
www.circuitcellar.com/PSoC2002
• The fastest growing
MCU architecture
• The highest level
of integration
• The next new thing
in Embedded
Get paid to learn about PSoC
™
MCU
For complete rules and entry form
Win a share of
Brought to you by:
The Cypress logo mark is a registered trademark of Cypress Semiconductor and Cypress MicroSystems, PSoC, and Programmable System-on-Chip are trademarks of Cypress Microsystems Inc. The Circuit
Cellar name is a registered trademark of Circuit Cellar Inc.
$15,000 in Cash Prizes!
\64
\64
Take your career to the next level.
64
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
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.
SOURCES
STK500 starter kit
Atmel Corp.
(408) 441-0311
www.atmel.com
ICC AVR Compiler
ImageCraft
(650) 493-4326
www.imagecraft.com
and 3 KB of extra SRAM buffer area,
and you wouldn’t have to change a
significant amount of the original
Internet device code to squeeze it in.
If your Internet device doesn’t need
the resources of a more complex
microcontroller, you don’t have to put
them there, but if you really want to
rock and roll, you can shoehorn the
big ATmega128 motor in.
The final working AVR TCP/IP
code is a port of various algorithms I
have assembled on other microcon-
trollers over time. Unlike some of the
micros I ported this code from, the
AVR ATmega16 architecture is
designed to lean towards programs
written in high-level languages like C.
As a result, I was able to eliminate all
of the assembly language routines
from the ported code and write them
fully in AVR C using ImageCraft’s
ICCAVR Professional. The AVR code
is basically a combination of modules
that perform a specific Internet-relat-
ed function. All of the basic functions
are there including a limited TCP
module. For instance, an ARP module
is included in the AVR code to allow
other devices on the Internet or LAN
to establish a communications ses-
sion with the AVR Internet device.
IN THE PIPE
I’ve enjoyed putting this series on
the Atmel development tools and
JTAG ICE together. The Atmel gear
I’ve been exposed to is inexpensive
and top notch. I look forward to see-
ing you on the AVR Internet device
LCD, and when I do, we will have
proven that the ATmega16 isn’t com-
plicated. It’s embedded.
I
Photo 6—
The Packet Whacker is a real microcon-
troller network interface card (NIC) that’s plugged into
a virtual slot on the ATmega16.
Visit us on the web www.jkmicro.com
Call 530-297-6073 Fax 530-297-6074
Tools
to
Move
Data
Ether6
*
10Base -T Ethernet
6 Serial Ports
1MB SRAM
Rugged Enclosure
Optional On Board
Modem & 10Base-2
Starts at
$369
µFlashTCP-EP
*
10Base-T Ethernet
2 Serial Ports
7-34 VDC
Rugged Enclosure w/
Industry Standard
Connectors
Starts at
$229
Software
DOS & Web Server On-Board
Royalty free TCP/ IP source code provided
eRTOS available for Multi tasking applications
Borland C/C++ in Development Kits
LogicFlex
*
10Base -T Ethernet
46 Digital I / O’s
Programmable Xilinx CPLD
Hardware Clock/Calendar
Expansion Bus for Peripherals
Starts at
$189
µFlashTCP
*
10Base-T Ethernet
2 Serial Ports
10 Digital I/ O’s
3.75” x 2.50”
30% smaller than PC104
Starts at
$149
TCP/
IP
Solutions
All products based on the Intel 386Ex with DOS, TCP/IP and Web Server software pre-installed.
NE2000 compliant 10Base-T Ethernet
&
DIP socket to accept an M-Systems DiskOnChip standard.
JK microsystems connects you with embedded control solutions. Our cost-effective DOS based
controllers are ideal for data acquisition, networking or industrial technology applications.
*
66
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
his year, my
wife Mary decided
to begin her bicycle
commuting season in
March, rather than waiting for Daylight
Saving Time to kick in. She normally
leaves work around 5:30 p.m., near
sunset, which means she needed good
lighting for her four-mile ride.
The large LED cluster I described in
my column last April (Circuit Cellar
129) serves admirably as a taillight,
but what makes a good headlight?
Many years ago, I built a PWM bright-
ness controller for an automobile
headlight powered by a motorcycle
battery, a bulky and corrosive way to
go, but it worked wonderfully.
After considering the options for
this project, I chose simplicity and
reliability over fancy features. Photo 1
shows what half an hour pondering
the stock at the local Home Depot
plus a bit of rummaging through my
parts heap produced. A handful of 2
″
Schedule 40 PVC fittings house a
halogen spotlight and a switch, pow-
ered by a sealed lead-acid battery with
an automotive blade-style fuse.
All of the parts that could cause
trouble are conspicuously absent.
Lacking a brightness control, voltage
step-up or step-down circuitry, fancy
LED status indicators, and without a
single microcontroller, what can go
wrong? Alas, it still requires wires,
connectors, and a filament.
In the analog domain, however, it’s
often the components you can’t see
that give you the most trouble. Let’s
take a look at some considerations
and, along the way, discover why
schematics don’t tell you everything
you need to know.
DIRECTED LIGHTING
I picked a General Electric ESX/CG
halogen MR16 spotlight to get a tight
beam pattern that illuminates the road
without lighting up the trees. The
reflector has a cover glass that protects
the bulb, which is vital because an
exposed halogen bulb can shatter when
a drop of water hits it. Although Mary
doesn’t plan to ride in the rain, such
things can happen. The cover glass also
keeps dust and grime off the reflector.
The lamp isn’t specified for outdoor
use or a bicycle’s vibration, so I won’t
be surprised if it doesn’t reach its
4000-hour rated life. On the other
hand, it’s cheap and readily available,
which makes up for a lot. Smaller
reflector bulbs, in the 6-V MR11
series, should work equally well.
As a rule of thumb, if your design
depends on exotic parts, you should
expect procurement troubles at some
point during your product’s life. While
stranding your wife in the darkness
may not be worse than stranding your
customers, I strongly recommend
avoiding either outcome.
The bulb draws a continuous 20 W
from a 12-V supply, which can be
either AC or DC. Although many peo-
Invisible Components
t
What you can’t see
can hurt you—at least
in the analog domain.
In this article, Ed flags
all of the hidden
obstacles you’re likely
to encounter on the
road to building a
trouble-free bicycle
headlight. This project
goes nicely with Ed’s
earlier instruction on
building a taillight.
Ed Nisley
ABOVE THE
GROUND
PLANE
Photo 1—
A halogen spotlight, a sealed lead-acid bat-
tery, a fuse, a switch, and a handful of PVC plumbing
fittings make a fine bike headlight. In the analog
domain, though, it’s what you don’t see that can make
all the difference.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
67
Capacity and efficiency are inverse-
ly related to discharge current, so you
cannot expect a 5-Ah battery to supply,
say, 50 A for 0.1 h. SLA batteries can
provide an average discharge rate up to
about 0.2 C (1 A for a 5-Ah battery).
Maximum average currents can reach
1 C, but the capacity drops off with
high-current, high-duty cycle loads.
NiCd batteries can supply much
higher average currents, up to 2 C,
with NiMH batteries at 0.5 C and
lithium ion batteries at 1 C under
ideal conditions. All of these values
depend on the battery’s construction,
with physically smaller batteries hav-
ing lower ratings.
Battery voltages are not strongly
temperature-sensitive, but their cur-
rent capacity declines about 10% per
10°C below 25°C. Around here, March
temperatures near 0°C are not unusu-
al, which means adding another 25%
to the initial capacity (work it out: a
20% reduction equals a 25% increase).
You cannot, however, extract all of
a battery’s rated energy capaci-
ty during a discharge cycle. SLA
batteries and lithium ion batter-
ies react badly to deep cycling,
while NiCd and NiMH can tol-
erate nearly complete dis-
charges. Over-discharging a bat-
tery will cause irreparable dam-
age to its weakest cell, so you
must ensure that the load cuts
out before that point.
Obviously, you must know
all of the values for the particu-
lar batteries under considera-
tion for a project. I can only
supply a rough outline here,
based on average numbers and
estimates. You get to fill in
your own details!
ple think that bike headlights can be
powered from a pedal-turned generator,
it turns out that riding requires 0.1 hp,
about 75 W, on a continuous basis.
Adding 20 W to that just for lighting
isn’t practical—just ask my wife!
BATTERY BASICS
Rechargeable batteries come in a
bewildering array of configurations
and chemistries. Lithium ion batteries
seem to be the hands-down favorite in
the hand-held arena due to their high
energy density. Nickel cadmium batter-
ies, the old standby, have given way to
nickel metal hydride in an effort to
keep cadmium out of the waste stream.
Lead-acid batteries haven’t gone away
yet, either. Choices, choices!
Years ago, a bicycle headlight might
have consisted of a flashlight bulb and
a pair of D cells. In round numbers,
that was a 1-W system: less than half
an amp from a 3-V supply. If you’ve
ever ridden with such a setup, you
know why 1 W isn’t enough light and
why they were called “glow worms.”
Automotive headlights dissipate 50
to 75 W, so a 20-W spotlight sounds
about right for a bike. Simple division,
though, tells you that delivering 20 W
from a 12-V supply requires 1.7 A. In
terms of the usual hand-held electron-
ic gadget, that is a lot of current.
Most portable devices draw a few
tens to perhaps a few hundreds of mil-
liamps and incorporate power-saving
techniques to reduce the current
whenever possible. Lighting systems,
on the other hand, have a high
and constant current drain.
Lower power dissipation means
less light and if I wanted less
light, I’d use a smaller bulb.
Batteries have four key speci-
fications: capacity in ampere-
hours (Ah), energy density in
watt-hours per kilogram
(Wh/kg), lifetime in recharge
cycles, and, last but not least,
price. A battery’s capacity tells
you how long it will supply a
given load, its density sets the
overall size, and its lifetime
indicates how soon you must
worry about the cost of a
replacement. Obviously, you
want the highest capacity in
the smallest container with the
longest life at the lowest cost, a rat
race that has driven battery develop-
ment in some truly weird directions.
Sealed lead-acid (SLA) batteries
have an energy density around
30 Wh/kg and a life of a few hundred
cycles. NiCd batteries offer triple the
lifetime and double the density at
twice the price. NiMH batteries have
a slightly lower lifetime and higher
energy density than NiCd batteries at
150% of their price (if cadmium
weren’t toxic, you’d never see a
NiMH battery). Lithium ion batteries
can hit 100 Wh/kg with best-case
lifetimes around 1000 cycles, but at
four times the price of an equivalent-
capacity SLA battery.
Within each battery family physical-
ly larger batteries provide greater
capacity, so you can choose a size to
suit your application. Each battery
also has a maximum current rating
that is limited by its internal chem-
istry and plate arrangement. Ignoring
the current specification can lead to
serious disappointment, because it
directly affects the battery’s lifetime.
In battery-speak, “C” represents
the nominal capacity in ampere-
hours at a specific discharge current,
typically 1/20 of the capacity (0.05 C)
for SLA batteries. For example, a 5-Ah
SLA battery would last for 20 h while
supplying 250 mA. Other battery
chemistries are rated at the nominal
1-C discharge rate, so a 5-Ah NiCd
battery could supply 5 A for 1 h.
13.50
13.00
12.50
12.00
11.50
11.00
–1.50
–1.00
–0.50
0.00
0.50
1.00
1.50
2.00
2.50
SLA battery discharge
Room temperature
Refrigerated
Elapsed time (h)
Figure 1—
Battery capacity and output voltage are temperature-dependent.
A cold battery produces less light for a shorter time. The “before zero” part
of the lower curve shows the battery cooling down with no load.
Photo 2—
A trivial 1-A LM317 current source turns a
DMM into a milliohm meter. The blue heat-shrink tubing
insulates four parallel 5.1-
Ω
resistors that set the current.
DOWN THE DRAIN
The 1.7-A bulb current determines
the discharge rate, with the peak equal
to the average. Assuming a 0.2-C drain
for an SLA battery means 8.5 Ah, NiMh
at 0.5 C requires 3.4 Ah, and a NiCd
battery at 1 C would be only 1.7 Ah.
In this situation, the bulb’s high
and constant current sets the mini-
mum battery capacity. Normally, you
can reduce the battery size by the cir-
cuit’s duty cycle: half an hour of use
at, say, 100 mA would require only
50 mAh from the battery.
Cold temperature operation adds
25% and limiting discharge to half the
rated capacity doubles the result. That
SLA battery is beginning to look like a
real monster at 20 Ah, the NiCd pack
hits 4 Ah, and the NiMH is twice that.
Charger complexity affects the deci-
sion though. SLA batteries have dead-
simple (albeit slow) chargers, NiCd and
NiMH batteries are even worse, and
lithium ion batteries are downright
finicky. When you design a product,
you must factor in the charger’s com-
plexity. I’d rather not design an exotic,
one-off charger for a device that will be
used perhaps for two months each year.
Like the spotlight bulb, SLA batter-
ies are cheap and readily available,
which means replacements won’t be a
problem. They use a simple charger
and can withstand half a year of sit-
ting around with no attention at all.
68
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
They’re an example of a mature tech-
nology, which means they’re well
understood and fully characterized.
Not to mention, of course, that I
have several SLA batteries in my parts
heap. They work well for powering
amateur radio gear after those teeny
NiCd batteries wear down!
I popped a charged 5-Ah SLA battery
in the refrigerator for a few hours to
verify its cold-weather performance.
Figure 1 compares discharge cycles at
16°C (my rather cool shop) and 3°C,
both ending at 11.4 V, equivalent to
90% depth of discharge.
Assuming a constant 7.5-
Ω
bulb
resistance and eyeball-fitting the
curves, the total battery capacities
work out to 50 Wh and 37 Wh. The
nominal capacity of 60 Wh shows you
the effect of both high discharge rate
and low temperature. The battery
reaches half-discharge at 12.2 V after
1 h when warm and only half an hour
at March temperatures.
I suspect drawing this much power
under such adverse conditions will
drastically shorten the battery’s life, at
which point I’ll deploy another SLA
battery from my collection. If there’s a
real problem, I may have to dip into
my NiCd stash.
INVISIBLE RESISTORS
Circuitry in the analog domain has
many components that don’t appear
on normal schematics. In
previous articles, I’ve dis-
cussed how parasitic
inductances and stray
capacitances can affect
RF and switching cir-
cuits. Now, down at DC,
you will meet, if not see,
some invisible resistors.
Figure 2 seems to be
about as simple a
Figure 3—
LM317 voltage regulators make good current sources, too.
Note that the LM317 output terminal does not connect directly to the
source’s output jack. Set your DMM to read millivolts and think milliohms.
Figure 2—
Small resistances can add up to large trouble if you’re not careful. The resistor values are in milliohms.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
69
schematic as you can imagine: bat-
tery, fuse, switch, and bulb. Flip the
switch and the light goes on. It looks
like a beginning electricity project!
But what about all those resistors?
Their values, shown in milliohms, may
seem trivial. After all, what effect can
33 m
Ω
possibly have on a circuit?
For low-speed logic signals, circuit
board traces behave like idea conduc-
tors and digital folks may be forgiven
for believing that schematics represent
the real world. Unfortunately, there’s
a tendency toward false generalization.
Those power semiconductors that
switch kiloamps and kilovolts at the
flip of a bit are definitely not ideal!
Analog folks know that trouble
comes in many shapes and sizes. In
that simple bulb-and-battery circuit,
those trivial resistors drop 140 mV at
1.6 A, a power loss of ~2%. Trivial, per-
haps, but consider the power supply for
a single Intel Pentium 4 CPU. The volt-
age regulator must supply about 1.5 V
at up to 70 A, with a maximum voltage
drop at CPU pins of only 130 mV.
When you work the numbers, this
implies a resistance of 1.8 m
Ω
between
the regulator and CPU. Actually, it’s
worse because the power distribution
specification restricts the voltage drop
to
≤
55 mV, a resistance of only 0.8 m
Ω.
Remote voltage sensing can compen-
sate for the DC drop, but the power
dissipated in the conductors repre-
sents a serious board-design problem.
If you’ve never measured the resist-
ances of wires, connectors, and connec-
tions, you should invest a few hours
in your own education. Unfortunately,
most DMMs cannot measure resist-
ances below 1
Ω
, if only because the
resistance of their test leads intro-
duces a significant error. I have an old
Fluke 8060A DMM that can resolve
10 m
Ω
with a Relative setting to can-
cel lead resistance, but cheaper meters
are useless below a few ohms.
Photo 2 shows a useful DMM acces-
sory: a LM317 voltage regulator wired
to produce an accurate 1-A current.
Figure 3 presents the schematic. You
can use a 1-A wall wart or a bench
supply to provide the input power.
A quartet of 5.1-
Ω
resistors in paral-
lel sets the LM317 current to 1.0 A. If
you have an accurate ammeter you
can trim the resistors as needed, but
for our purposes a few percent accura-
cy will suffice. At 5 V, a 1-A power
supply produces an open-circuit out-
put voltage of about 3.5 V, which may
be a bit high for testing circuits with
semiconductors already in place.
Because the source drives 1 A into
what’s effectively a dead short, it’s
useful only for brief tests. The LM317
will overheat and shut down in ther-
mal overload after a minute or two, at
which point the metal box will be
toasty warm. You have been warned.
To measure the resistance of a con-
ductor or connection, set up your volt-
meter to display millivolts, typically
around 200 mV, and attach it as close
as possible to the device you’re meas-
uring. Attach the current source leads
beyond the voltage sensing leads. Turn
on the juice and read the DMM as
though it were displaying milliohms.
You must separate the current drive
and voltage sense connections for this
type of measurement to eliminate
errors caused by resistance in the
sense leads. To achieve more accuracy
you must pay more attention to subtle
effects, but a simple Kelvin connec-
tion will get you most of the way to
the goal. Make a few measurements
and see which invisible resistors lurk
in your circuitry.
I
Ed Nisley, PE, is an electrical engi-
neer and a ham radio geek (call sign
KE4ZNU). You may contact him at
ed.nisley@ieee.org.
RESOURCES
I. Buchmann, “Batteries in a Port-
able World,” www.buchmann.ca.
Maxim Integrated Products,
“Battery-Powered Circuit
Measures Milli Ohms and Micro
Ohms,” dbserv.maxim-ic.com/app
notes.cfm?appnote_number=106.
QuadTech, Inc., “Multi-Terminal
Impedance Measurements,
or…Why Do Those Bridges Use
So Many Connections?”
www.quadtechinc.com/digi
bridge/articles/035027.pdf.
R. Soja, “An Integrated PWM Light
Controller,” Circuit Cellar 137,
December 2000.
70
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
ack in 1999, I
presented a project
that used a small PIC
processor to read and
write sectors of a SmartMedia memory
device. Because of RAM limitations,
the project provided a basic interface
and rudimentary storage primitives.
Even with a working knowledge of
SmartMedia, the burden of compatible
file storage was left to your application.
It’s time to revisit SmartMedia and
see how processor improvements
bring user-friendly file storage to your
embedded applications. This project
will allow an application to load/save
user files to SmartMedia using a
Windows/DOS-compatible file format.
Now you can exchange your embedded
data with your PC applications. The
universal interface is a serial port that
looks like an external disk drive (see
Photo 1). Simply dump your file using
a
WRITE S:FILENAME.EXT<cr> com-
mand. Hardware handshaking handles
buffer control and EOF indication.
To be ready for a SmartMedia inser-
tion, the interface must provide a safe
haven by assuring that signals do not
inadvertently apply signals interpreted
as destructive commands. Basically,
you want the data bus in High-Z mode,
the control lines applying disabling
states, and power initially enabled in
the 3.3-V mode. Before attempting any
investigation commands, proper
power-up procedures should be fol-
lowed as shown in Table 1a. (Note:
This also means that if for some rea-
son the media is removed. Proper
power-down procedures should be fol-
lowed as shown in Table 1b.)
After the SmartMedia insertion has
been handled, the interface should be
in an idle state and ready for action.
To assure that the module has the
proper physical format, a read ID com-
mand can be executed. SmartMedia
recognizes the commands listed in
Table 2. Some newer devices have
additional commands, however, the
commands in Table 2 are compatible
throughout the SmartMedia modules.
Sending command
90h will access a
1-byte manufacturer code and a 1-byte
device code. The manufacturer codes
are not needed to determine format-
ting, but the device codes shown in
Figure 1 will be necessary. From the
device code value, a table look-up rou-
tine provides the application with
some of the physical format constants
that are necessary to use the
SmartMedia module.
Just because you successfully read
the ID bytes doesn’t mean that the
SmartMedia is ready to use. In fact, it
may not have been physically or logi-
cally formatted. Normally, the media
comes physically formatted, mainly
because of its design.
SmartMedia File Storage
b
Jeff has
showed
us how a
small PIC
processor
reads and writes por-
tions of a SmartMedia
memory device. This
month, he shows us a
project that will help
you to exchange
embedded data with
your PC applications.
Jeff Bachiochi
FROM THE
BENCH
Part 1: A Windows/DOS-Compatible
File System
Figure 1—
The Device code identifies what the physical format of the module should be.
Size
Page size
Block size
# of Blocks Device code
1 MB (8 Mb)
256 + 8 bytes
16 Pages
256 Blocks
6Eh, E8h, ECh
2 MB (16 Mb)
512 Blocks 64h, EAh
4 MB (32 Mb)
512 + 16 bytes
6Bh, E3h, E5h
8 MB (64 Mb)
1024 Blocks E6h
16 MB (128 Mb)
32 Pages
73h
32 MB (256 Mb)
2048 Blocks 75h
64 MB (512 Mb)
4096 Blocks 76h
128 MB (1 Gb)
8192 Blocks 79h
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
71
The cylinder or track is the area of
the platter/disk covered by a record/
playback head fixed at a specific dis-
tance from the center of the platter/
disk while the medium spins beneath
it. The head is the actual record/play-
back device (of which there is usually
one per side of each disk or platter).
A sector is a fraction of a cylinder,
like the curved pieces of an electric
train track assembled to create a cir-
cle. The CHS number allows any sec-
tor of any cylinder under any head to
be individually identified. Like the
physical formatting of a device (indi-
cating its capacity) a CHS table for
each media size is predefined for
SmartMedia (see Table 3). Notice that
the sector size for each device size is
consistently 512 bytes. Neglecting
the 1- and 2-MB device sizes, the log-
ical sector size is the physical page
size, nice and simple. Also notice
that the total sector count times the
sector size is less than the capacity,
which allows the media to have extra
sectors set aside to take over for
media page failure.
It is much easier when talking
about a location to visualize the
media as one long chain of sectors,
rather than the physical positioning of
the head over a track and cylinder. So
the term logical block address (LBA) is
used as a linear position indicator.
Remember, the LBA is a sequential
logical address. The SmartMedia also
has a physical address associated with
it. You might be tempted to say that
the physical address is the logical
address. That would be true except for
two points. First, the CIS/IDI already
takes up the first page (sector/block)
so the DOS*FAT format has to skip
that sector of the media (logical
address 0000h is more likely to be
Notice the page size for SmartMedia
of 2 MB or less is 256 + 8. These units
are no longer manufactured and I will
assume for this discussion that they
don’t exist. This simplifies the over-
view. All SmartMedia is designed with
512-byte pages (plus 16 additional
bytes of redundant information). Each
page consists of an even 256-byte page
and an odd 256-byte page (plus the
redundant bytes). These three areas
are accessed using the three read com-
mands, one for each area of the page.
Pages are grouped into blocks of 16
to 32 pages depending on the module
size. The maximum allowable number
of blocks is 1024, so modules in excess
of 16 MB (more than 1024 blocks) have
an additional constant , called the
zone. A zone is a group of 1024 blocks.
This means that the 128-MB device
has eight zones (0–7) of 1024 blocks.
Beyond these physical definitions there
is a minimum amount of data that is
pre-placed within the module.
PHYSICAL FORMAT
The card information structure and
identify drive information (CIS/IDI)
data must be found in the first page of
the first good block of the
SmartMedia module. The fifth
byte of the redundant area of each
page indicates the valid data flag
area (VDFA) of that block. A bad
block (one marked as having some
kind of problem) is identified by a
byte with four or more 0 bits.
The routine involved with look-
ing for a good CIS/IDI page must
locate the first good physical
block by reading in the redundant
area of the first page of the block
and checking the VDFA. If it indi-
cates a good block, the even page
data for that page is read and
checked for errors using the ECC
field-1 (bytes 14–16 of the redundant
area). At least the first 10 bytes of the
even page are checked for the proper
data against a good copy of CIS data
stored in the CIS table of the applica-
tion. This process can be repeated on
the odd pages. Even and odd pages (the
first 256 and second 256 bytes of a
page) should have identical data stored
in each, which reduces the possibility
of errors. If everything looks OK, then
it’s safe to assume that the module
has a sufficient number of good blocks
to make up the physical format adver-
tised in the device code. A good
CIS/IDI is an indication that all the
blocks have been tested and bad
blocks identified and marked as such.
SSFDC—LOGICAL FORMAT
SmartMedia suggests using a
DOS*FAT format similar to that used
with solid state floppy disk cards. This
format originated with floppy and
fixed disk media and requires three
parameters: CHS, Master Boot, and
Partition. Cylinder-head-sector (CHS)
parameters refer back to the physical
parts of the floppy/fixed disk media.
Photo 1—
SmartMedia support circuitry easily fits into a small
plastic enclosure for external use.
Table 1a—
Here’s an overview of the power-up procedure for the SmartMedia socket upon media removal. In
b
, you can see the power-down procedure upon media removal.
State
I/O1-8
*WP
*WE
*RE
ALE
*CE
CLE
R/*B
LVD
*CD
Vcc
(Pdn)
(Pdn)
(Pup)
(Pup)
(Pdn)
(Pup)
(Pdn)
(Pup)
(Pdn)
(Pup)
No Media
High-Z
High-Z
High-Z
High-Z
High-Z
High-Z
High-Z
In = 1
In = 0
In = 1
Off
Insert Media
High-Z
High-Z
High-Z
High-Z
High-Z
High-Z
High-Z
In = 1
In = 0
In = 1
3.3 V
High-Z
Out = 0
Out = 1
Out = 1
Out = 0
Out = 1
Out = 0
In = 1
In = 0
In = 1
3.3 V
If…
In = 0
Then…
High-Z
Out = 0
Out = 1
Out = 1
Out = 0
Out = 1
Out = 0
In = 1
In = 0
In = 0
5 V
If…
In = 1
No Media
High-Z
High-Z
High-Z
High-Z
High-Z
High-Z
Out = 0
In = 1
In = 0
In = 1
Off
a)
b)
address × 2), with the LSB being an
even parity bit. All pages within the
block have the same BAF values.
MASTER BOOT SECTOR
Assuming no bad blocks, the CIS/IDI
is written in physical block 0 (page 0).
The master boot sector is written in
physical block 1 (page 0), yet identified
as logical block 0 as indicated by the
BAF value 1001h (remember, 1000h +
(logical block number × 2) and even
parity). The master boot sector must be
written in the first page of the second
“good” physical block and is considered
logical block 0, sector 0. When you per-
form a SYS on a floppy/fixed media,
boot code (up to 446 bytes) is written
into the beginning of the master boot
sector. SmartMedia doesn’t require any
code here but reserves the room for it.
At location 01BEh (even page 0BEh)
72
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
physical address 0001h). Second, solid-
state media has a limited life span.
Continually erasing and writing to a
sector will eventually wear it out. You
need a way to circulate SmartMedia
pages such that all of the pages will
get used equally. Although a file’s data
is divided into logical sequential sec-
tors, they are not necessarily mapped
into consecutive physical sectors.
This dynamic assignment of physical
sectors allows a particular rewritten
logical sector to be contained in a dif-
ferent physical sector each time it is
rewritten. This identification is han-
dled by the internal data configuration
variable Block Address Field 1 & 2
located in the redundant area of each
page. These two-byte variables hold
the key to the dynamic logical block
numbering. These fields are written
with 1000h + (the logical block
Number of
Number of
Number of
Total number
Sector size
cylinders
heads/cylinder
sectors/cylinder
sectors
(bytes)
1 MB
125
4
4
2000
512
(8 Mb)
(0–124)
(0–3)
(1–4)
2 MB
125
4
8
4000
512
(16 Mb)
(0–124)
(0–3)
(1–8)
4 MB
250
4
8
8000
512
(32 Mb)
(0–249)
(0–3)
(1–8)
8 MB
250
4
16
16000
512
(64 Mb)
(0–249)
(0–3)
(1–16)
16 MB
500
4
16
32000
512
(128 Mb)
(0–499)
(0–3)
(1–16)
32 MB
500
8
16
64000
512
(256 Mb)
(0–499)
(0–7)
(1–16)
64 MB
500
8
16
128000
512
(512 Mb)
(0–499)
(0–7)
(1–32)
128 MB
500
16
32
256000
512
(1 Gb)
(0–499)
(0–15)
(1–32)
Table 3—
This table shows the logical format specifications for SmartMedia capacity based on using a DOS*FAT
format. Note that the cylinder and head are numbered from zero and the sectors are numbered from one.
Table 2—
An Auto Block Erase requires two commands to prevent accidental erasure.
First cycle
Second cycle
OK while busy
Serial Data Input
80h
–
–
Read mode (1)
00h
–
–
Read mode (2)
01h
–
–
Read mode (3)
50h
–
–
Reset
FFh
–
X
Auto Program
10h
–
–
Auto Block Erase
60h
D0h
–
Status Read (1)
70h
–
X
ID Read (1)
90h
–
–
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
73
there’s a 16-byte partition 1 entry.
Although there’s room for four parti-
tion entries, only one is presently
used for SmartMedia. Figure 2 shows
the partition entry of the master boot
sector with data specific to an 8-MB
SmartMedia device. The values entered
in this parameter table come from the
logical format specifications based on
SmartMedia size from Table 4.
The start head/sector/cylinder data
points to where the first partition
boot sector will be found. The end
head/ sector/cylinder data points to
the last data sector (last partition boot
sector). The partition size is equal to
the LBA of the partition’s last data
sector minus the LBA of the parti-
tion’s first sector minus one. The
master boot sector defines where to
go next and the extent of where you
can look for any data. It does not tell
you how to find any specific data
(other than the partition boot sector).
PARTITION BOOT SECTOR
The partition boot sector gives addi-
tional information about this media’s
partition definition. To limit the
amount of bookkeeping necessary to
store a file, files are given space in
cluster increments with a limited
Start
Start
Start
Root
Storage
FAT
Cluster
Total
partition
FAT
FAT
directory
sectors
type
size
clusters
sector
sector
(copy)
sectors
number
number
sector
1 MB
0Dh
0Eh
0Fh
10h–1Fh
20h–0C7h
12-bit
4 KB
0F6h
(8 Mb)
2 MB
0Bh
0Ch
0Eh
10h–1Fh
20h–0F9Fh
12-bit
4 KB
1F0h
(16 Mb)
4 MB
1Bh
1Ch
1Eh
20h–2Fh
30h–1F3Fh
12-bit
8 KB
1F1h
(32 Mb)
8 MB
19h
1Ah
1Dh
20h–2Fh
30h–3E7Fh
12-bit
8 KB
3E5h
(64 Mb)
16 MB
29h
2Ah
2Dh
30h–3Fh
40h–7CFFh
12-bit
16 KB
3E6h
(128 Mb)
32 MB
23h
24h
2Ah
30h–3Fh
40h–0F9FFh
12-bit
16 KB
7CEh
(256 Mb)
64 MB
2Fh
30h
40h
50h–5Fh
60h–1F3FFh
16-bit
16 KB
0F9Dh
(512 Mb)
128 MB 2Fh 30h 50h
70h–7Fh
80h–3E7FFh
16-bit
16 KB 1F3Ch
(1 Gb)
Table 4—
This table shows format parameters based on SmartMedia size.
Offset
Parameter
Data
000h–1BDh
Boot code
00h–00h
1BEh
Partition 1
Boot ID
80h (Active)
1BFh
Start head #
01h LBA = 19h
1C0 (bits 5–0)
Start sector #
0Ah
1C1h (bits 7–6) (bits 7–0)
Start
cylinder
#
00h
1C2h
System
ID
01h
1C3h
End head #
03h LBA = 3E7F
1C4h (bits 5–0)
End sector #
10h
1C5h (bits 7–6) (bits 7–0)
End cylinder #
0F9h
1C6h–1C9h
Start
partition
sector
#
00000019h
1Cah–1CDh
Partition
size
00003E67h
1CEh–1DDh
Partition 2
00h–00h
1DEh–1EDh
Partition 3
00h–00h
1EEh–1FDh
Partition 4
00h–00h
1FEh–1FFh
Fixed data signature
AA55h
Figure 2—
This is the master boot sector located in logical block address 0.
FAT using: FAT Offset
equals three times the clus-
ter number divided by two.
For odd clusters, the 12-
bit word is stored at FAT
Offset plus one (and FAT
Offset plus two) in LSB to
MSB format. Just use the
upper 12-bits.
For even clusters, the
12-bit word is stored at
FAT Offset (and FAT Offset
plus one in LSB to MSB
format). Here, just use the
lower 12-bits.
The location for cluster 0
has 0F8Fh stored and the
location for cluster 1 has
0FFFh (this is stored packed
into three bytes—0F8h,
0FFh, and 0FFh). Notice
that the data area begins in
logical block 3, which is is
cluster 3 for the 8-MB device.
Immediately following the FAT
table is the directory. This is where
file names (and sub-directories) are
stored. As read in the partition sector,
there is room for 100h directory
entries; each entry is 32 bytes in
length. Except for the subdirectory
and long file name entries’ directory
entries, follow the format shown in
Table 6. The entries can be searched
using the file name/extension fields.
The file’s starting location is identi-
fied in the number of Start Cluster
74
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
number of directory entries. The max-
imum number of root directory
entries is shown in Table 5. With a
cluster count of 997 (3E5h) and each
value in a 12-bit FAT requiring 1.5
bytes (they’re packed two values for
every 3 bytes), the FAT must be:
Referring to Figure 3, you can see
how each piece of information is
slowly becoming a bigger picture.
After the partition table is read, the
location and size of
FAT area 1 and 2 can
be calculated. Two
FAT areas are used for
security purposes, the
second immediately
following the first.
When media has no
files stored, each FAT
has 000h stored in FAT
cluster locations 2
–
997
(12-bit packed).
Byte packing is a
way to save two 12-bit
values into three bytes
instead of four (it’s
complicated, but you
have to live with it for
compatibility reasons).
The cluster values are
read/written to the
Table 6—
Directory entries are 32 bytes long and initially begin with a 00h to
indicate no entry. 0E5h indicates a deleted entry. Legal file name values
include alpha, numeric, and a few odd characters (#, $, %, &, ‘, -, @, and “,”)
Offset
Description
Contents
00h–07h
File name
…
08h–0Ah
File extension
…
0Bh
File attribute
Bits 7 and 6, reserved
…
…
Bi 5, archive
…
…
Bit 4, subdirectory
…
…
Bit 3, volume name
…
…
Bit 2, system file
…
…
Bit 1, hidden file
…
…
Bit 0, read only
0Ch–15h
Reserved area
00h
16h–17h
Last edit time
Bits 0–4, seconds/2 (0–29)
…
…
Bits 5–10, minutes (0–59)
…
…
Bits 7–15, hours (0–23)
18h–19h
Last edit date
Bits 0–6, year 1980 (0–127)
…
…
Bits 7–10, month (1–12)
…
…
Bits 11–15, day (1–31)
1Ah–1Bh
Number of start cluster
0000h
1Ch–1Fh
File size
00000000h
Table 5—
The Partition Boot sector holds additional information includ-
ing a description of the directory and FAT formats.
Offset
Parameter
Data
00h–02h
Jump command
0E90000h
03h–0Ah
Manufacturer and version
…
0Bh–0Ch
Number of bytes/sector
0200h
0Dh
Number of sectors/cluster
10h
0Eh–0Fh
Number of reserved sectors
0001h
10h
Number of FAT tables
02h
11h–12h
Number of root directory entries
0100h
13h–14h
Total # partition sectors
3E67h
15h
ID byte
0F8h
16h–17h
Number of FAT sectors
0003h
18h–19h
Number of sectors/track
0010h
1Ah–1Bh
Number of heads
0004h
1Ch–1Fh
Number of hidden sectors
00000019h
20h–23h
Total # BIG partitions sectors
00000000h
24h
Physical drive number
00h
25h
Reserved
00h
26h
Extended boot record signatures 00h
27h–2Ah
Volume ID
00000000h
2Bh–35h
Volume label
00h-00h
36h–3Dh
File system type
“FAT12”
3Eh–1FDh
Reserved
00h-00h
1FEh–1FFh
Signature fixed data
0AA55h
field (also a FAT entry). Because most
files are not in 512-byte increments
(the size of one sector), the File Size
field tells exactly how many bytes are
in the file. The FAT can be interrogat-
ed to find either an EOF marker or an
additional cluster used by the file.
READY YET?
This project will look like a disk
drive connected to a serial port.
Minimum commands are implement-
ed to act like its hardware counter-
part. If you attempt to access any
drive with no media you get an error
message. This application returns a
“No Media” message if you send a
carriage return (<cr>) before initializa-
tion is complete. Remember, initial-
ization begins with identifying
SmartMedia inserted into the socket
and setting the appropriate media
voltage. The application must then
attempt to identify the physical and
logical formats of the media. If the
media seems to be satisfied, the inter-
face will return the drive letter “S:”
in response to a carriage return. The
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
75
SOURCES
SmartMedia-compliant products
SSFDC Forum
www.ssfdc.or.jp/english/index.htm
PIC18F452 Microcontroller
Microchip Technology Inc.
(888) 628-6247
www.microchip.com/flashmcus
Jeff Bachiochi (pronounced BAH-key-
AH-key) is an electrical engineer on
Circuit Cellar’s engineering staff. His
background includes product design
and manufacturing. He may be reached
at jeff.bachiochi@circuitcellar.com.
following commands will be recog-
nized after the drive is initialized:
DIR, READ S:FILENAME.EXT, and
WRITE S:FILENAME.EXT.
As homework, I suggest you read up
on the PIC18xxx family. I will be using
the new PIC18F452 for this Smart-
Media interface project. Next month’s
hardware will get your SmartMedia
identified and ready for action. Those
of you who have asked about where to
get SmartMedia sockets may want to
check with Digikey.
I
Physical
block
0
1
2
3
4
Physical
block
0
1
2
…
13
14
15
0
1
2
…
13
14
15
0
1
2
…
6
7
8
9
10
11
12
13
14
15
0
1
2
...
13
14
15
0
1
2
...
Logical
block
0
1
2
3
Logical sector
(LBA)
0
1
3
...
13
14
15
16
17
18
...
22
23
24
25
26
27
28
29
30
31
32
33
34
...
45
46
47
48
49
50
...
Description
CIS/IDI
Reserved area
Master boot sector
Reserved area
Partition boot sector
FAT1
FAT2 (copy)
Root directory
Data area
Figure 3—
This map of the SmartMedia shows the physical and logical formatting (based on no bad media blocks).
76
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
fter all these
years, one thing I’ve
learned is that when it
comes to silicon, it’s usu-
ally a matter of when, not if. The
march of Moore’s Law provides backup
for the bluest of blue-sky predictions.
If it can be done, it will be done. If it
can’t be done, just wait a while.
If I sound a little breathless in my
praise for silicon, it’s because I’m still
a bit lightheaded after my first peek
under the hood of the new Xilinx
Virtex-II Pro FPGAs.
Yes, the current Virtex-II parts are
no slouches, with plenty of mega
(gates, bits, pins, and hertz) power in
their own right. But I must say the
Pro makes regular Virtex-II parts look
like, well, amateurs.
So without further ado,
I’m giving Xilinx my
Outrageous Chip of the
Year award. There are
plenty of super-chips
around, but to my mind
none matches the sheer
audacity of Virtex-II Pro.
Of course, with price tags
well into triple digits, V-
II-P is an extreme chip
with an extreme price to
match. Signing that first PO will hurt,
but remember that time and Moore’s
Law heals all.
LOWLY LUT NO MORE
Going back 20 years, most of the pro-
grammable logic action centered around
programmable array logic (PAL).
Invented by Monolithic Memories,
PALs utilized explicit AND and OR
gates with a fuse-based semi-fixed
interconnect. Subsequently, MMI and
their PAL patents were acquired by
AMD, but ultimately for naught as
AMD eventually sold their program-
mable logic operation to Philips.
Anyway, old-timers will recall that
Xilinx got started by pioneering the
concept of using SRAM-based look-up
tables (LUTs) with a more versatile
hierarchical interconnect as the basis
for programmable logic. Purists may
well argue that the idea of using a
memory for logic functions goes back
to ’70s-era bipolar PROMs and PLAs,
but there’s no denying that Xilinx
took the ball and ran with it.
The concept is simple enough. A
four-input LUT is essentially a 16 × 1
SRAM with logic inputs connected to
the four address lines and output driv-
en by the data line.
It’s easy to see how the LUT can han-
dle any combinatorial logic operation of
the four inputs simply by pre-loading
the proper data into the SRAM. For
instance, a four-input OR gate is simply
a matter of loading a 0 at address 0000b
and 1s at addresses 0001–1111b. If all
of the inputs (i.e., address lines) are
zero, the output is zero. If one or more
of the inputs is one, the output is one.
Want a four-input AND instead?
Just put a one at address 1111b and
zeros everywhere else. You really need
FPGA Power Play
a
Tom Cantrell
Xilinx
deserves
an award.
Why?
Well, they
turned Virtex-II parts
into pros. This month,
Tom takes a look at
the new Xilinx Virtex-
II Pro FPGAs and
compares it to the
Virtex-II and other
“super-duper” chips.
SILICON
UPDATE
Table 1—
V-II-P includes multiple (12 to 216) 18-Kb block RAMs that can
be configured in various single- and dual-port (shown here) configurations.
Blocks can be cascaded to implement deeper or wider arrays.
Port A
16K x 1
16K x 1
16K x 1
16K x 1
16K x 1
16K x 1
Port B
16K x 1
8K x 2
4K x 4
2K x 9
1K x 18
512 x 36
Port A
8K x 2
8K x 2
8K x 2
8K x 2
8K x 2
Port B
8K x 2
4K x 4
2K x 9
1K x 18
512 x 36
Port A
4K x 4
4K x 4
4K x 4
4K x 4
Port B
4K x 4
2K x 9
1K x 18 512 x 36
Port A
2K x 9
2K x 9
2K x 9
Port B
2K x 9
1K x 18 512 x 36
Port A
1K x 18
1K x 18
Port B
1K x 18 512 x 36
Port A 512 x 36
Port B 512 x 36
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
77
most modern wonder-chips,
chips that require 5-V con-
nections need not apply.
Better yet, the parts offer a
digital controlled impedance
(DCI) option. To deliver max-
imum throughput, many of
the latest I/O standards
require proper termination
using serial or pull-up/down
resistors to match the trans-
mission line impedance (see
Figure 3). It doesn’t sound like
a big deal until you’re faced
with the prospect of adding
dozens or even hundreds of
discrete resistors to your board
design, at which point you’ll
be glad that Xilinx put them
inside the chip for you.
18 BITS AND I LIKE IT
To fulfill true SoC pretensions,
FPGAs need a healthy complement of
on-chip memory. It’s true that the
LUTs themselves can be called to duty
as memory, after all they are 16 × 1
RAMs. However, it’s an inefficient use
of logic resources, so distributed LUT
RAM is best used for size-limited and
speed-critical functions such as shift
registers. Indeed, dedicated SHIFTIN
and SHIFTOUT connections allow
one CLB (i.e., four slices or eight
LUTs) to implement a 128-bit shifter.
Recognizing the need for a more effi-
cient bulk memory solution, FPGAs
have begun incorporating additional
dedicated RAM. For V-II-P, block RAM
comes in 18-Kb chunks that can be
organized in various ways (see Table 1).
The 9-, 18-, and 36-bit options are avail-
able for those applications that need
parity protection, although the genera-
a NAND? Just reverse the
AND setup (i.e., zero at 1111b
and ones elsewhere). Note that
unlike real gate arrays, the
speed (propagation delay) is the
same (SRAM access time) no
matter what the logic function.
Add a flip-flop to the output
(for synchronous designs) and a
bit of interconnect (including
feedback, carry, etc.) and it’s
easy to come up with a reper-
toire of high-level functions
such as adders.
Yes, a 16-bit SRAM takes
more silicon than a particular
hardwired gate, but the flexi-
bility of the scheme and densi-
ty of the SRAM process
allowed the LUT-based scheme
to prevail as programmable
logic moved from hundreds to thou-
sands of gates and beyond.
Compare the configurable logic
blocks (CLBs) of yore with those in the
V-II-P class and you’re in for a surprise.
In fact, the logic in Figure 1 is now
known as a mere slice, four of which
make up today’s CLB on steroids.
Moore’s Law has a way of sneaking up
on you if you don’t pay attention.
STAY ACTIVE
You can cram all of the fancy CLBs
or whatever you call them on a chip,
but it’s all for naught if there’s no way
to connect them. Adding more logic
just ups the ante for the programmable
interconnect, which consists of a hier-
archy of short/fast and long/slow lines.
Routing bottlenecks can emerge, but
much like a street closure, the grid
arrangement means there’s usually
some way to get a signal from one
place to another. The bad news is that
a serpentine route can severely affect
the overall performance because a
chip is only as fast as its slowest (i.e.,
most critical) path.
This is where an experienced FPGA
designer can work magic by exploiting
the overall knowledge of their design
and the chip to manually organize
(i.e., place) elements of the chip with
routing in mind. However, even those
people with the know-how to get that
far under the hood could surely find a
better use for their time.
Xilinx has come up with a helping
hand for the place-and-route chal-
lenged in the form of active intercon-
nect, which adjusts the drive level on
signals according to the route they
take. Although it’s a simple concept,
active interconnect really pays off by
not only speeding critical paths but
also helping the design software (and
the designer) in the time-consuming
quest for a workable layout.
I/O U
Just as routing is important for tak-
ing full advantage of the fancy logic,
you also need to be able to do some-
thing useful with the signals when
they reach the edge of the chip. Enter
the I/O blocks (IOBs), which ring the
chip fronting the pins.
Each IOB is made up of six registers
that can be configured as edge-sensitive
D-type flip-flops or level-sensitive
latches (see Figure 2). Notice the DDR
multiplexors that support double data
rate transfers, typically by driving each
register on opposite edges of a clock.
The full merit of the I/O scheme isn’t
apparent in Figure 2. The so-called
“Select I/O Ultra” feature allows the
FPGA I/O pins to mimic literally
dozens of signal logic and level stan-
dards. Exploiting dedicated I/O power
supply and reference voltage inputs,
the list includes a myriad of variations
of 1.5- to 3.3-V single-ended and dif-
ferential standards. As is the case with
Figure 1—
You’ve come a long way, baby. To get an idea of how far, note that
the top-end V-II-P includes nearly 50,000 of the half-slices shown here.
Reg
OCK1
Reg
OCK2
DDR mux
3-State
Reg
OCK1
Reg
OCK2
DDR mux
Output
Reg
OCK1
Reg
OCK2
Input
PAD
IOB
Figure 2—
Delivering potential V-II-P performance to
the pins is twice as easy with double-data rate (DDR)
capable I/O blocks.
SHIFTIN
SOPIN
G4
G3
G2
G1
WG4
WG3
WG2
WG1
0
Dual-port
Shift-regulator
A4
A3
A2
A1
WG4
WG3
WG2
WG1
LUT
RAM
ROM D
G
MC15
WS DI
ALTDIG
BY
SLICEWE[2:0]
WSG
WE[2:0]
WE
CLK
WSF
Shared between
x and y register
MULTAND
SHIFTOUT
G2
Prod
G1
BY
1
0
CYOG
MUXCY
O
ORCY
COUT
I
MUXCY
O
I
XORG
GYMUX
YBMUX
SOPOUT
YB
Y
DY
FF
LATCH
D Q
Y
CE
CK
SR REV
DYMUX
CE
CLK
Q
SR
DIG
CIN
To that end, V-II-P incorporates what
Xilinx calls “Rocket I/O.” It’s a high-
speed serial transceiver technology
licensed from Mindspeed (a division of
Conexant), where it’s known as
“SkyRail.” Call it what you will, run-
ning at up to 3.125 Gbps, I call it fast.
Needless to say, it’s not surprising
that you may need something fancier
than an SPI port or UART when
you’re talking less than a nanosecond
per bit (see Figure 4). Programmable
interface width (8-, 16-, 32-bit), built-
in 50-/75-
Ω
termination, selectable
pre-emphasis and differential voltage
are just the beginning.
One important feature is the 8B/10B
coding. The scheme maps 8-bit bytes
into 10-bit characters in a way that
yields a number of desirable attrib-
utes. [1] Most important is the guaran-
tee of sufficient transitions to allow
clock recovery. By tracking the data
being transmitted, the 8B/10B coder
chooses among alternative versions of
the code to guarantee a run of no more
than five consecutive ones and zeros.
78
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
tion and checking are left to the design-
er. These configurations are also a nat-
ural fit with RGB video applications.
The block RAM can be configured
for either single- or dual-port access.
Note that the latter option supports a
variety of bus-width matching options.
For instance, four cascaded block
RAMs, can implement a dual-port
RAM that is accessed as 8K × 8 from
one port and 4K × 16 from the other.
Xilinx has been pushing FPGAs as a
unique solution for DSP processing.
With the 18-Kb block RAMs a natural
for storing data and coefficients, there’s
also a bunch of matching 18-bit multi-
pliers. Throw in an accumulator
implemented in LUTs, and you’ve got
a formidable amount of firepower that
can be brought to bear when cranking
through DSP loops in hardware.
CLOCKED AND LOCKED
It’s safe to say that, except for eso-
teric asynchronous designs, nothing
happens on chips until a clock starts
wiggling. As their custom chip fore-
bears, FPGA designers soon learn that
clock generation, distribution, recov-
ery, and such can be a tough challenge.
Remember that any skew or drift goes
right to the bottom line, with even a
few nanoseconds of slop dragging your
maximum clock rate down.
It comes as no surprise that larger
FPGAs incorporate special clock-relat-
ed features, notably dedicated high-
speed, low-noise clock distribution
buses. However, the digital clock
manager (DCM) of the V-II-P goes way
beyond the call of duty.
The DCM is a designer’s dream, tak-
ing whatever clock(s) you’ve got, gener-
ating whatever clocks you need, getting
them wherever they need to go and
spiffing them up along the way. Each
DCM (there are four or eight per chip)
can synthesize just about any frequency
with doubling and non-integer divide
factors. Overall skew is adjusted to
synchronize input clock edges with
the clock delivered to internal logic
and RAM or to a pin for external use.
Better yet, there’s a combination of
coarse and fine phase adjust more like
you might expect to find on an expen-
sive lab instrument than a chip. The
specific tuning capability depends on
the particular DCM modes and set-
tings, but even the worst case offers
fine (less than 1%) phase adjustment.
ROCKET SOCKET
So far, all the features I’ve described
are part of the regular Virtex-II (i.e.,
non-Pro) lineup. It’s all quite impres-
sive so far, but hang on to your hats.
Perhaps you’ve heard of emerging
ultra-high speed serial I/O schemes
such as Fibre Channel, Infiniband, and
10G Ethernet. These new standards are
less about conventional LAN usage and
more about replacing traditional paral-
lel buses (such as PCI) with crossbar
connected point-to-point serial links.
z
0
2R
2R
V
CCO
Virtex-II
Pro DCI
Virtex-II
Pro DCI
Figure 3—
Digitally controlled impedance (DCI) takes
advantage of built-in serial and parallel termination resis-
tors that support a variety of single-ended I/O standards.
AVCCAUXRX
VTRX
2.5V RX
Termination
supply RX
RXP
RXN
TXP
TXN
Serializer
clock
manager
Deserializer
Power down
POWERDOWN
RXCHECKINGCRC
RXCRCERR
RXDATA[15:0]
RXDATA[31:16]
RXNOTINTABLE[3:0]
RXDISPERR[3:0]
RXCHARISK[3:0]
RXCHARICOMMA[3:0]
RXRUNDISP[3:0]
RXBUFSTATUS[1:0]
ENCHANSYNC
CHBONDDONE
CHBONDI[3:0]
CHBOND[3:0]
RXLOSSOFSYNC
RXCLKCORCNT
TXBUFERR
TXXFORCECRCERR
TXDATA[15:0]
TXDATA[31:16]
TXBYPASS8B10B[3:0]
TXCHARISK[3:0]
TXCHARDISPMODE[3:0]
TXCHARDISPVAL[3:0]
TXKERR[3:0]
TXRUNDISP[3:0]
TXPOLARITY
TXINHIBIT
LOOPBACK[1:0]
TXRESET
RXRESET
RECLK
REFCLK2
REFCLKSEL
RXUSCLK
RXUSCLK2
TXUSRCLK
TXUSRCLK2
Comma
detect
realign
P
a
rallel Loopbac
k P
ath
8B/10B
Decoder
CRC
check
RX
elastic
buffer
GNDA
TX/RX GND
AVCCAUXTX
2.5V TX
VTTX
Termination
supply TX
Output
polarity
TX
FIFO
8B/10B
Decoder
CRC
Channel bonding
and
clock correction
RXRECCLK
RXPOLARITY
RXREALIGN
RXCOMMADET
ENPCOMMAALIGN
ENMCOMMAALIGN
Figure 4—
Launch your data into orbit with the built-in Rocket I/O multi-gigabit transceivers (MGT).
80
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
The transition richness eases the task
of clock recovery with little overhead.
Contrast 8B/10B’s 25% overhead with
the 100% overhead (8B/16B, if you will)
of the traditional Manchester coding
scheme. In addition to guaranteeing
periodic transitions, 8B/10B maintains
good average DC balance (i.e., equal
number of ones and zeros over time),
which eases the tasks of active gain,
equalization, and threshold setting.
Another feature is that 8B/10B cod-
ing has room for out-of-band symbols.
These are special characters such as the
“,” that are outside of the 256 charac-
ters required to map a byte. Further-
more, their bit pattern is also guaran-
teed to never appear in a sequence of
byte data, allowing them to be used
for higher level signaling functions.
One key use for these special out-of-
band codes is clock correction. A recov-
ered clock may differ slightly from that
synthesized from the local reference
clock. Incoming data is stored in the
receive FIFO with the recovered clock
and removed from the FIFO with the
locally generated clock. If something
isn’t done, the difference will ultimate-
ly lead to data under- or overrun.
The answer is an elastic FIFO
scheme that exploits the 8B/10B out-
of-band signaling feature. A transmit-
ter is required to periodically insert
removable sequences of out-of-band
characters. In turn, when the receiver
detects such a sequence, it can either
throw away or replicate it as neces-
sary to dynamically keep the FIFO
centered (see Figure 5).
Another synchronizing application
of special characters is channel bond-
ing. Yes, V-II-P parts come with up to
16 Rocket I/O channels. Grouping
(bonding) them together is just the
thing if you need something on the
order of 10-GBps (yes, that’s bytes, not
bits) aggregate throughput.
In bonding situations, the 8B/10B
special characters serve to keep data
aligned across multiple channels. Each
receiver tracks the location of the spe-
cial characters in their own receive
FIFO. Periodically, one transceiver
designated the master commands all
the other transceivers to come into
alignment (see Figure 5).
Read
RXUSRCLK
Write
RXRECCLK
Nominal condition: buffer half full
Read
Write
Buffer less than
half full (emptying)
Repeatable
sequence
Read
Write
Buffer more than
half full (filling up)
Removable sequence
Figure 5—
The 8B/10B coding scheme features out-of-
band (i.e., non-data) repeatable and removable
sequences that allow compensation for mismatched
FIFO read and write clocks.
Photo 1—
Come out, come out wherever you are.
You’d never know by looking that there’s a 32-bit
PowerPC CPU under the hood of this XC2VP4.
Embedded controllers with an attitude.
With a bit of imagination and a relentless pursuit of innovation, the divers that film Shark Week
902 Waterway Place | Longwood, FL 32750 | 800·635·3355 | 407·262·0066 | Fax 407·262·0069
Visit our website @ www.micromint.com to see our complete line of OEM Solutions.
82
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
“PRO” AS IN PROCESSOR
As the final chapter in this tale of
silicon largesse, I suppose it won’t sur-
prise anyone that V-II-P tops it off with
a complete 300-MHz-plus PowerPC
CPU. OK, but maybe the fact there are
V-II-Ps with two and even four of the
CPUs on-board will raise an eyebrow.
Although the PPC 405 core is rela-
tively lean and mean for a 32-bit
RISC, it’s by no means stripped down.
It has a full-bore five-stage pipeline,
hardware multiply and divide, 64-entry
MMU, three timers, and even a respect-
able complement of cache (16 KB each
for instruction and data in a two-way
set associative configuration).
The CPU-FPGA connection relies
on the IBM CoreConnect architecture
made up of a hierarchy of buses: on-
chip memory (OCM), processor local
bus (PLB), and device control register
(DCR) interfaces.
The final jaw-dropper for this tech-
nological tour-de-force came as I sat
in the Xilinx conference room staring
at one of the brand new V-II-P wafers.
They looked like plain FPGAs to me,
but in fact they were XC2VP4 chips
(i.e., a version with a PowerPC CPU).
I don’t see a CPU on that die in
Photo 1? Where is it? It’s buried
somewhere beneath (count them)
nine layers of metal, courtesy of a
fancy IBM copper 0.13-µm process.
The fact that you can’t see the
PowerPCs is a huge deal. If you could
see them, that would mean they’re in
the way, disrupting the critical cross-
chip routing. Instead, the heavy metal
approach preserves the integrity of
the overall FPGA fabric and provides
for full and high-speed connectivity
with the PowerPCs.
LESS IS MOORE
Finally we come to the so-called
kitchen sink unit (KSU). Just kidding,
I think. Let’s take stock of the V-II-P
(see Figure 6). Up to four high-speed
32-bit processors with cache. Up to
16 multi-gigabit Rocket I/O trans-
ceivers. Hundreds of single-ended or
differential I/Os. Dozens of high-speed
multipliers. Megabits of block RAM.
Tens of thousands of slices represent-
ing hundreds of thousands or call it a
million gates of programmable logic.
Sure, the V-II-P is great, but who
can afford to design-in such expensive
chips? For example, the XC2VP4 with
one PowerPC, half a megabit of block
RAM, and four Rocket I/Os is project-
ed to sell for $120.
The answer, of course, is that rela-
tively few apps can justify chips with
triple-digit price tags. But that’s the
right answer to the wrong question.
The right question is what will you
do with such a miraculous chip when
it costs $60? Any takers at $30? $15?
Ponder it a bit. There’s no rush.
Thanks to Moore’s Law and the march
of silicon, time is on our side.
I
Device
XC2VP2
XC2VP4
XC2VP7
XC2VP20
XCVP50
Rocket I/O
transceiver
blocks
4
4
8
8
16
PowerPC
processor
blocks
0
1
1
2
4
CLB
(1 CLB = 4 slices = max 128 bits)
Array
row × column
16 × 22
40 × 22
40 × 34
56 × 46
88 × 70
Slices
1408
3008
4928
9280
22,592
Max
distributed
RAM (Kb)
44
94
154
2900
706
18 × 18 bit
multiplier
blocks
12
28
44
88
216
18-Kb
blocks
12
28
44
88
216
Max
block RAM
(Kb)
216
504
792
1584
3888
DCMs
4
4
4
8
8
Max
I/O pads
204
384
396
596
852
Block Select RAM
Figure 6—
Five members of the Virtex-II Pro lineup have been announced. The VP4, VP7, and VP20 are available
now. The VP2 and VP50 are scheduled for production later this year.
Tom Cantrell has been working on
chip, board, and systems design and
marketing for several years. You may
reach him by e-mail at tom.cantrell@
circuitcellar.com.
REFERENCE
[1] A. Widmer, P. Franaszek, “A
DC-Balanced, Partitioned-Block,
8B/10B Transmission Code”, IBM
J. Res. Develop
, 27(5), pp. 440–451,
September 1983.
SOURCE
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
83
Insert-ready sub-mini SBCs (small as 47x55 mm.) supporting the
Philips
achieved via GND circuitry, 6 to 8 layer PCB, by-
32 KB to 8 MB external SRAM & Flash (controller-dependent)
FlashTools enable on-board in-system (ISP) programming
C & CAN interfaces; ADC; Chip-Select signals
PHYTEC America LLC ■ 255 Ericksen Avenue ■ Bainbridge Island, WA ■ USA 98110
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!
84
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
85
86
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
87
88
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
2.0GHz Intel Pentium 4 Processor
60GB 7200RPM ATA 100 Hard Drive
P4 Mid Tower Chassis & ATX PS
1 Parallel, 1 Serial, 4 USB ports
64MB AGP GeForce Video Adapter
Integrated Sound & 107 Keyboard
Netgear 10/100 PCI Ethernet Card
Windows XP Pro & Microsoft Mouse
1.7GHz Intel Pentium 4 Processor
1 Parallel, 1 Serial, 4 USB & PS/2 Port
P4 Mid Tower Chassis & ATX PS
40950 Encyclopedia Cr. ~ Fremont, CA 94538
1.9GHz Intel Pentium 4 Processor
256MB PC/133MHz SDRAM Memory
1 Parallel, 1 Serial, 4 USB & PS/2 Port
ATI Xpert 2000 32MB AGP Video Card
Sound Card & 120 WATT Speakers
107 Enhanced Internet Keyboard
56K v.90 Lucent PCI Modem w/Fax
P4 Mid Tower Chassis & ATX PS
1.9GHz Intel Pentium 4 Processor
60GB 7200RPM ATA 100 Hard Drive
1 Parallel, 1 Serial, 4 USB ports
64MB AGP GeForce Video Adapter
P4 Mid Tower Chassis & ATX PS
Integrated Sound & 120W Speakers
Windows XP Home & Optical Mouse
Tel: 510.353.1800 Fax: 510.353.0990
FAST & RELIABLE WITH RAMBUS MEMORY,
WINDOWS XP PROFESSIONAL & MORE!
BEST BUY! INTEL 845BG MAIN BOARD WITH
INTEGRATED SOUND, 60GB HD & 256MB RAM.
AVAILABLE UP TO 2.2GHz!
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
89
Denver, Colorado, 720-940-5002
Embedded Networking Specialists
90
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
92
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 143 June 2002
93
Graphics & Video
94
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
INDEX
85
Abacom Technologies
92
Abia Technology
85
ActiveWire, Inc.
69
All Electronics Corp.
85
Amazon Electronics
82
American Raisonance Corp.
9
Amulet Technologies
92
AP Circuits
90
Appspec Computer Tech. Corp.
84
Atlantic Quality Design, Inc.
48,49,88
Arcom Control Systems
18
Arcturus Networks, Inc.
86
Avocet Systems, Inc.
85
Bagotronix, inc.
15,84
Basic Micro
72
B + K Precisions
55
CadSoft Computer, Inc.
91
CCS-Custom Computer Services
86
Cermetek Microelectronics Inc.
92
Conitec
11
Connecticut mircoComputer Inc.
91
Copeland Electronics Inc.
91
Cyberpak Co.
10
Cypress MicroSystems
C4
Dataman Programmers, Inc.
91
Dataprobe Inc.
86
DataRescue
83
Decade Engineering
89
Delcom Engineering
88
Dreamtech Computers
1
Earth Computer Technologies
The Advertiser’s Index with links to their web sites is located at www.circuitceller.com under the current issue.
Page
74
ECD (Electronic Controls Design)
84
EE Tools
(Electronic Engineering Tools)
83
Electronic Brains
11
EMAC, Inc.
90
EVBplus.com
74
ExpressPCB
84
FDI-Future Designs, Inc.
89
Futurlec
84
Hagstrom Electronics
56
HI-TECH Software,LLC
91
HVW Technologies Inc.
86
ICE Technology
87
IMAGEcraft
86,92
Intec Automation, Inc.
86
Intronics, Inc.
75
Intuitive Circuits, LLC
73
JED Microprocessors Pty Ltd.
64
JK microsystems
68
JR Kerr Automation & Engineering
75
LabJack Corp.
47
Laipac Technology, Inc.
75
Lakeview Research
93
Lemos International
2
Link Instruments
93
Lynxmotion, Inc.
7
MaxStream
87
MCC (Micro Computer Control)
90
Microcross
89
Micro Digital Inc
92
microEngineering Labs, Inc.
81
Micromint Inc.
84
MicroSystems Development, Inc.
87
MJS Consulting
23
Mouser Electronics Inc.
79
MVS
86
Mylydia Inc.
65
NetBurner
95
Netmedia, Inc.
31
New Micros, Inc.
87,90
OKW Electronics Inc.
43
On Time
93
Ontrak Control Systems
90
Paradigm Systems
C2
Parallax, Inc.
39,83
Phytec America LLC
83
Phyton, Inc.
91
Picofab Inc.
85
Prairie Digital Inc.
63
PSoC 2002 Design Challenge
89
Pulsar Inc.
91
R2 Controls
57
R4 Systems Inc.
34
Rabbit Semiconductor
89
Rad Proto
85
R.E. Smith
47
Remote Processing
89
RLC Enterprises, Inc.
88
RPA Electronics Design, LLC
86
Rutex
4
Saelig Company
89
Scidyne
3
Scott Edwards Electronics Inc.
RoCK Specifications—
Part 4: Creating User-Programmable Tasks
80C31-Controlled Power Supply
Starting Down the Pipeline—
Part 2
Short Solutions:
An AVR MCU-based AC Phase Controller and Build a
Graphics LCD Bias Supply
Robotics Corner:
Extreme OSMC—Part 2: The Modular OSMC Brain
An LCD Controller for a PIC
Driving the NKK Smartswitch
I From the Bench:
SmartMedia—Directory Entries
I Silicon Update:
Eight Isn’t Enough
I Applied PCs:
Building A Modular Programming Platform—Part 1: The Program Module
Page
Page
Page
PREVIEW
144
ADVERTISER’S
Attention Advertisers:
August Issue Deadlines
Space Close: June 7
Material Due Date: June 14
Theme: Analog Techniques
88
Sealevel Systems Inc.
90
Senix Corp.
85
Sensory, Inc.
83
Signum Systems
87
SmartHome.com
91
Softools
8
Solutions Cubed
92
Spectrum Engineering
83
Square 1 Electronics
80
SUMBOX Pty Ltd.
16
Systronix
C3
Tech Tools
90
Techniprise Inc.
32,33
Technologic Systems
93
Technological Arts
61,88
Tern Inc.
17
Texas Instruments
84
Timeline Inc.
87
Triangle Research Int’l Inc.
56
Trilogy Design
42
Vector CANtech, Inc.
90
Vesta Technology Inc.
86
Vetra Systems Corp.
93
Weeder Technologies
91
Xilor Inc.
87
Z-World
68
Zagros Robotics
85
Zanthic Technologies Inc.
f you ask people these days about broadband connection to the Internet, most will say that they are going to sign up the
instant it becomes available. But if you look at the statistics showing how many actually do sign up when it is offered in their
area, you’ll notice that the number is much smaller. So what’s going on?
There are a variety of broadband alternatives and they use an assortment of transmission mediums—from copper wire installed
a hundred years ago to the latest space-based satellites. Each form of technology is an attempt to satisfy a specific objective. Some offer mobile
computing while others offer isolated area coverage, low cost, or higher bandwidth.
There are currently two wireless technologies, satellite and fixed-point wireless. Satellite wireless is pretty straightforward. As long as you can
point a dish at the southern sky you can have broadband Internet (older systems use a dial-up modem for uploading while newer systems transmit
directly back to the satellite). That’s also provided you don’t mind a shared connection like cable modems, a very high installation cost, and that read-
ing my editorial about broadband may be as close as you are going to get to the Internet during bad weather. Of course, if you live 45 min. from the
nearest human, it may be your only choice.
Fixed-point wireless is basically our cell phone system with some new equipment and another plan for billing us. Europeans are way ahead of us
here because we seem to think that unrestricted capitalism is a better idea than organized communication standards. That’s one reason why their cell
phones work everywhere and ours work nowhere. My bitterness aside, high-speed wireless broadband has a rosy potential but we may be waiting a
long time for the right infrastructure.
Presently, the cable modem is the most widely used form of broadband technology. It is available in both urban and suburban areas, and it is
growing quickly. The technique is simple. Digital data travels over the same cable television lines and a modem separates data and television at the
home. Service tends to be reliable because the cable providers own the entire infrastructure and they are responsible for installation, making provi-
sions, and answering service questions. If there is a downside, it’s the lack of package choices (from a cable monopoly) and that technically it’s a
shared bandwidth. The more people connected to your local cable line, the lower the throughput available to you.
Based on the number of installations, direct subscriber line (DSL) is the second most popular broadband connection. DSL data travels over plain-
old telephone service (POTS) lines and a filter separates data and voice at the house. One reason for its popularity is that DSL can technically go
anywhere there is a phone line (all of us who installed second phone lines for dial-up modems can put the money toward DSL service) and there are
many service providers and speed versus price packages. That’s the good news.
The bad news is putting some truth into DSL’s biggest marketing claim—that because cable modems are a shared bandwidth and everyone in the
neighborhood is dividing down one data rate, connections can slow to a crawl. By contrast, DSL is a dedicated 1.5-MBps connection and it’s all yours.
In theory, this may be true. In reality, however, the speed you get varies by how good your provider is and how much they’ve oversubscribed the
service. As in my own case, the DSL provider can put his scope on the side of my house and show me 1.5 MBps between me and the CO down the
road, but damned if I’ve ever seen anything faster than 800 Kbps when I’m on the Internet. In other words, the bottlenecks are simply further down
the pipe. However potentially fast your connection speed, the ISP network ultimately governs your throughput.
The dot-bomb era taught us that when necessity isn’t the mother of invention, it has a big downside. Business grew too fast and too much of the
venture capital went to providing superfluous content. The same might be said for broadband. In my opinion, the initial surge in sales for high-band-
width connections came from businesses and computer-savvy individuals (like us) who tend to get antsy waiting for web pages. Broadband is like cell
phone history. It became ubiquitous only when people felt they couldn’t live without it.
For broadband to become truly universal, it must be offered at a price that is more appealing and the content that people demand has to be readily
available for them to download. It isn’t enough to just have a bunch of high-quality video clips on every web site. Broadband Internet connectivity has to
evolve into an integrated experience for users. Online video gaming has to evolve from simply calling up video frames from a resident CD-ROM to trans-
mitting moves, messages, and all of the audio grunts and screams with no latency. And watching a movie has to be real time, not an 8-hour download.
I have no doubt that broadband on the Internet will eventually be all that it claims. Success will arrive when people see what they can’t get else-
where more conveniently. Hopefully, it won’t take forever. Until then, we’ll have to live with the irony that 99% of
today’s broadband connections come through the same old pre-Internet pipes.
Broadband—A Report Card
INTERRUPT
i
steve.ciarcia@circuitcellar.com
96
Issue 143 June 2002
CIRCUIT CELLAR
®
www.circuitcellar.com
PRIORITY
STILL THE WORLD’S MOST
POWERFUL PORTABLE
PROGRAMMERS?
$795
inc 4mb ram
Orders received by 4pm will normally be despatched same day.
Surely not.
Surely someone somewhere
has developed a portable programmer that
has even more features, even greater
flexibility and is even better value for
money.
Actually, no. But don’t take our word for
it. Use the feature summary below to see
how other manufacturers’ products compare.
$1295
DATAMAN-48LV
• Plugs straight into parallel port of PC or
laptop
• Programs and verifies at 2, 2.7, 3.3 & 5V
• True no-adaptor programming up to 48
pin DIL devices
• Free universal 44 pin PLCC adaptor
• Built-in world standard PSU - for go-
anywhere programming
• Package adaptors available for TSOP,
PSOP, QFP, SOIC and PLCC
• Optional EPROM emulator
DATAMAN S4
• Programs 8 and 16 bit EPROMs,
EEPROMs, PEROMs, 5 and 12V FLASH,
Boot-Block FLASH, PICs, 8751
microcontrollers and more
• EPROM emulation as standard
• Rechargeable battery power for total
portability
• All-in-one price includes emulation
leads, AC charger, PC software, spare
library ROM, user-friendly manual
• Supplied fully charged and ready to use
S4 GAL MODULE
• Programs wide range of 20 and 24 pin
logic devices from the major GAL vendors
• Supports JEDEC files from all popular
compilers
SUPPORT
• 3 year parts and labor warranty
• Windows/DOS software included
• Free technical support for life
• Next day delivery - always in stock
Still as unbeatable as ever. Beware of
cheap imitations. Beware of false
promises. Beware of hidden extras.
If you want the best, there’s still only one
choice - Dataman.
Order via credit card hotline - phone
today, use tomorrow.
Alternatively, request more detailed
information on these and other market-
leading programming solutions.
NEW MODEL
MONEY-BACK
30 DAY TRIAL
If you do not agree that these truly are the
most powerful portable programmers you can
buy, simply return your Dataman product
within 30 days for a full refund
Wyszukiwarka
Podobne podstrony:
circuit cellar1995 06
circuit cellar2001 06
circuit cellar1996 06
circuit cellar1993 06
circuit cellar1994 06
circuit cellar1991 06,07
circuit cellar1992 06,07
circuit cellar2004 06
circuit cellar1997 06
circuit cellar2003 06
circuit cellar1990 06,07
circuit cellar1995 06
circuit cellar2001 06
circuit cellar1991 06,07
circuit cellar1993 06
circuit cellar1996 06
więcej podobnych podstron