circuit cellar2001 12

256MB 133MHz SDRAM

20GB 7200RPM Hard Drive

1 Parallel, 1 Serial, USB & PS/2 Port

ATI Xpert 2000 32MB AGP Video Adapter

Sound Card & 120 WATT Speakers

Logitech PS/2 Mouse

107 Enhanced Internet Keyboard

Netgear PCI 10/100 Ethernet Card

Intel Pentium III Processor

128MB 133MHz SDRAM

40GB UDMA Hard Drive

1 Parallel, 2 Serial, USB & PS/2 Port

17" .27 1280x1024 Monitor & AGP VGA

Integrated Sound & 120 WATT Speakers

Windows 98, Logitech PS/2 Mouse

107 Enhanced Internet Keyboard

Micro ATX Tower Chassis

AMD Duron Processor

128MB 133MHz SDRAM

20GB UDMA Hard Drive

1 Parallel, 2 Serial, 2 USB ports

Micro ATX Tower Chassis

Integrated AGP Video Adapter

Integrated Sound & 120 WATT Speakers

Logitech PS/2 Mouse & Keyboard

256MB PC800 RAMBUS

40GB 7200RPM Hard Drive

1 Parallel, 1 Serial, 2 USB ports

32MB AGP Video Adapter

Yamaha Sound System & 120WATT Speakers

Windows 98, PS/2 Mouse & Keyboard

256MB PC800 RAMBUS

60GB 7200RPM Hard Drive

1 Parallel, 1 Serial, 2 USB ports

E-VGA 64MB GeForce II AGP Video Card

Windows XP PRO & Microsoft Intellimouse

107 Enhanced Internet Keyboard

Netgear PCI 10/100 Ethernet Card

256MB 133MHz SDRAM

40GB 7200 RPM Hard Drive

1 Parallel, 1 Serial, 2 USB ports

CDRW 40x16x10

17" .27 1280x1024 Monitor

ATI Xpert 2000 32MB AGP Video Adapter

Sound Card & 320 WATT Speakers

Windows XP Home, Logitech PS/2 Mouse

Internet Keyboard

Accelent Systems Inc.
(330) 864-2300
Fax: (330) 864-8674
www.accelent.com

NEWS

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

NEW PRODUCT

INTERNET APPLIANCE DEVELOPMENT PLATFORM

The new StrongARM-based Integrated Development

Platform (IDPTM) is now available to Intel customers
developing StrongARM-based products.

This platform speeds the Internet appliance( IA) devel-

opment cycle by providing a robust environment that
facilitates the development of software applications or
the prototyping of an IA device in a Microsoft Windows
CE operating system and StrongARM-processing envi-
ronment. With the included binary
release code, the IDP can be used for
the various aspects of application
and product development, testing,
and prototyping.

By using the IDP, developers can

shift their focus from the hardware
and system level software to spend-
ing time on developing the applica-
tions and differentiating features
that will make their product com-
petitive in the market. This, in turn,

leads to a feature-rich product in less time, lower cost,
and with less risk than traditional methods of product
development. Targeted applications for the IDP include
PDAs, wireless web pads, set-top boxes, Internet audio
and video devices, kiosks, point of sale products, hand-
held gaming devices, portable data terminals (PDT), and
a wide variety of applications.

Built-in features include support for USB, PS2 and

matrix keyboards, PS2 mouse,
numerous serial and parallel ports,
Ethernet, PCMCIA, compact flash,
IDE for hard disk and CD-ROM,
IrDA, touch panel, AC97 audio,
JTAG, 802.1 lb, Bluetooth, cellular
radio and more.

Edited by Rick Prescott

NEWS

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

NEW PRODUCT

MOTOR DRIVER FOR TINY MOTORS

Designed for use in stepper motors rated at 300 mA or

less, the CY-21-LP motor driver current can be pro-
grammed to between 25 and 300 mA using one resistor.

It works with all two- and four-phase step motors, and

works in Full and Half Step modes. The microstepping
feature provides 16 microsteps per full step. The CY-21-
LP supports a step frequency up to 200 kHz.

The unit can either have a cable connection using IDC

connectors, or the module can be turned upside down
and mounted on a PCB or plugged into a PCB socket.
The module can be used with power supplies from 12 to

42 VDC. The driver’s signals
for step, direction, and enable
are opto-isolated.

Pricing starts at $108 in sin-

gle quantity.

Cyberpak Company
(800) 328-3938
www.cyberpakco.com

SINGLE BOARD COMPUTER

The PC/II+zT board is a rugged, complete 586-class

(32-bit, ’x86) SBC with a wide range of I/O features. It
carries the 33- to 133-MHz ZFx86 S.O.C. processor, inte-
grated north and south bridges and
I/O controller, 128 MB of 66-
MHz soldered SDRAM, 16
MB of soldered flash mem-
ory, dual 10/100 Ethernet
ports, quad IDE/ATA-4
and ATA-5 channels,
dual serial, dual USB, IrDA,
VGA and 24-bit panel video, and all
standard AT peripherals, as well as an external 32-bit, 33-
MHz PCI bus. It is also PC/104-Plus compliant.

The board is offered in its base configuration, which

includes minimal memory, minimal flash, and CPU.

Megatel Computer Corp.
(416) 245-2953
www.megatel.ca

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

f you’ve been

following any

news related to

embedded systems

development recently, you’ve heard
that GNU tools are growing increas-
ingly popular for mainstream embed-
ded systems development. To say that
they are just now becoming popular
for all types of embedded develop-
ment would be untrue. In fact, GNU
tools have been used to produce
embedded applications since their cre-
ation, but haven’t seen widespread
use in the greater embedded commu-
nity until recently.

This article provides you an oppor-

tunity to evaluate GNU tools for
embedded development in a low-cost
setting using the ARM Evaluator-7T
SBC. This inexpensive and versatile
platform is a good choice for an intro-
ductory GNU experience because the
ARM family of chips are well-sup-
ported by GNU. This board in partic-
ular comes ready-to-play with the
entire GNU development tool chain,
including the GNU debugger.

I’ll discuss some of the advantages

and disadvantages of using GNU
tools for embedded development, then
dive right in and show you how to set
up and explore your own GNU devel-

FEATURE
ARTICLE

opment environment using a simple
“hello world!” program. After that,
I’ll run the program on the GNU
debugger’s ARM instruction set simu-
lator and on the Evaluator-7T board.
I’ll show a couple of commercial
GNU tool distributions for those of
you who want ready-to-use, support-
ed, or customized versions of the soft-
ware for this project.

WHY GNU?

One of the obvious advantages of

the GNU family of development tools
is their price. By virtue of their distri-
bution license, source code for GNU
tools like the compiler, linker, and
debugger can be had at virtually no
cost by simply downloading them
from the Free Software Foundation
(FSF)’s GNU web site. What you will
find if you go this route, however,
may disappoint you.

The source code distribution pack-

ages do not come configured for any
of GNU’s supported targets, so you
must configure and install them your-
self. Furthermore, the base tool distri-
butions do not include a graphical
Integrated Development Environment
(IDE) to facilitate point-and-click code
generation or debugging. Such tools
exist, but they are not part of the base
GNU tool distributions. I’ll explain
this later on when I discuss the GNU
debugger in detail.

After you have the GNU develop-

ment tools configured and installed,
you have at your disposal a powerful
and flexible foundation of products
that can be used to deliver just about
any kind of embedded solution,
regardless of how arcane or extreme
your needs are. GNU tools are highly
adaptable, and can be tailored to pro-
vide solutions that few competitive
commercial offerings can. These
include debugging over CAN and
other atypical communications links,
quick replacement of internal
libraries like floating point emulation,
and fine-grained, precise control over
linker memory assignments.

GNU tool flexibility extends

beyond the target domain, however.
No other embedded tool chain in exis-
tence, proprietary or otherwise, sup-
ports as many combinations of host

Bill Gatliff

Why Not GNU?

No doubt, one of the
major selling points of
the GNU family of
development tools is
their low cost. Beyond
that, Bill shows us that
the tools are effective
solutions for a variety
of embedded needs.
Follow along as he
covers the strengths
and weaknesses of an
option to consider.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

other host. Heterogenous develop-
ment environments are especially
attractive for GNU, because build
management and automated debug-
ging scripts will move consistently
and transparently between systems
with minimal or no modifications.

Perhaps the most surprising thing

of all is how well GNU tools are sup-
ported. In addition to several commer-
cial support offerings, an active
embedded GNU user base keeps in
almost constant contact via a collec-
tion of mailing lists, online guides,
and web sites. In many cases, the
authors of the tools in question pro-
vide direct assistance.

I have consistently found that if I

ask an intelligent question, I get an
intelligent answer back in less than a
day—generally less than four hours.
That’s an impressive statistic for any
help desk, but an especially impres-
sive one for a help desk that costs
nothing to use.

WHY NOT GNU?

Alongside their long list of strengths,

the GNU tools have a short list of
weaknesses. The first two are that
GNU tools aren’t well documented for
widespread embedded use, and they
aren’t shrink-wrapped to the point
that new users can get started quickly.
In response, a growing list of independ-
ent consultants and a few commercial
vendors offer CDs containing config-
ured GNU setups that work with pop-
ular development hardware (I’ll get
into this later on with some examples).

Another drawback of the GNU

world is that a switch to it from a
commercial, closed development
environment may incur some serious
headaches or, even worse, be an all-or-
nothing proposition. Many proprietary
embedded development tool and
library vendors don’t publish specifi-
cations for their file formats, so usual-
ly you can’t directly import outputs
from their tools into a GNU system.
In other words, if a vendor of a closed-
source library of code won’t provide
the library in a format that the GNU
linker understands, then you’re sunk
before you’ve even left the harbor.
Ditto for the communications proto-
col used by your hardware emulator.

Sparcstation, or even a Win32
machine, GNU probably runs on it,
and runs exactly the same as on any

and target environments as GNU.
Whether your development worksta-
tion is a Linux PC, Solaris

Listing 1—To install the GNU tools, use these commands.

$ export TARGET=arm-elf

$ export PREFIX=`pwd`/${TARGET}

$ export PATH=$PATH:$PREFIX/bin

$ tar xzvf binutils-2.11.2.tar.gz

$ patch -p0 < binutils-2.11.2.patch

$ mkdir build-binutils && cd build-binutils

$ ../binutils-2.11.2/configure --target=$TARGET --prefix=$PREFIX

$ make all install 2>&1 | tee make.log

$ cd ..

$ tar xzvf gcc-2.95.3.tar.gz

$ patch -p0 < gcc-2.95.3.patch

$ mkdir build-bootstrapgcc && cd build-bootstrapgcc

$ ../gcc-2.95.3/configure --target=$TARGET --prefix=$PREFIX \

--with-newlib --without-headers --with-gnu-as \

--with-gnu-ld --disable-shared --enable-languages=c

$ make all-gcc install-gcc 2>&1 | tee make.log

$ cd ..

$ tar xzvf newlib-1.9.0.tar.gz

$ patch -p0 < newlib-1.9.0.patch

$ mkdir build-newlib && cd build-newlib

$ ../newlib-1.9.0/configure --target=$TARGET --prefix=$PREFIX

$ make all install 2>&1 | tee make.log

$ cd ..

$ mkdir build-gcc && cd build-gcc

$ ../gcc-2.95.3/configure --target=$TARGET --prefix=$PREFIX \

--with-gnu-as --with-gnu-ld --enable-languages=c,c++

$ make all install 2>&1 | tee make.log

$ cd ..

$ tar xzvf gdb-5.0.tar.gz

$ patch -p0 < gdb-5.0.patch

$ mkdir build-gdb && cd build-gdb

$ ../gdb-5.0/configure --target=$TARGET --prefix=$PREFIX

$ make all install 2>&1 | tee make.log

$ cd ..

Listing 2—This "hello world!" program is used for exploring the debugger.

#include <stdio.h>

int a_global = 10;

int foo ( int arg )

{

static int foo_counts = 0;

foo_counts++;

return foo_counts + arg;

}

int main ( void )

{

int nloops;

char* charstr = "hello, world!\n";

for( nloops = 0; nloops < 10; nloops++ ) {

printf( "%s", charstr );

foo( nloops );

}

return 0;

}

So why aren’t you buying a CD?

Well, an article that recommends,
“just go buy a CD” would be really
short, and probably not interesting.
There is educational value in setting
up the tools by hand, particularly if
you can do it in a hobbyist’s environ-
ment where the business case argu-
ments aren’t applicable. The GNU
development tool installation process
is similar to the process used to
install other GNU and related tools,
so going through the procedure manu-
ally a few times is a training exercise
that pays dividends down the road
when you start using and adapting
GNU tools for more specialized use.

The main reason you’re doing

things by hand, however, is that there
is no better way to get a thorough
look at what the GNU tools are all

Issue 137 December 2001

www.circuitcellar.com

CIRCUIT CELLAR

One much-hyped limitation of the

GNU tools that isn’t really a limita-
tion at all is the notion that you can-
not use GNU tools to produce propri-
etary, closed-source products. This is
simply untrue. In fact, most people
use the embedded GNU tools in this
way, and do so legally.

The real limitation, if you want to

call it that, is that you can’t incorpo-
rate libraries of code licensed under
the GNU General Public License
(GPL) into applications that remain
proprietary to the end user. For more
on this, you should read the text of
the GPL and related licenses as they
appear on the Free Software
Foundation’s web site. And while
you’re doing that, you should also
read the licenses for the tools you are
using today; you may find that you’re
already agreeing to some terms that
are just as surprising.

The Free Software Foundation is

not the only place to look for libraries
of GNU-compatible materials that
may be downloaded. The Internet is
literally bursting with source code,
released under licenses varying from
“must use in open source applications
only” to “come and get it.” Graphics
libraries, boot loaders, diagnostic
tools, and even entire operating sys-
tems like Linux (www.kernel.org) and
eCos (sources.redhat.com/ecos) can be
easily found after just a few minutes
with your favorite search engine.

If GNU tools are free, why buy a

CD? The Free Software Foundation
doesn’t exist to provide development
tools to engineers at no cost. Its mis-
sion is to provide development tools
and other code in a way that preserves
the freedoms of the end users of that
code. The zero cost part is just one
beneficial side effect.

A useful analogy is that of an auto-

mobile. When you buy a car, the
automaker doesn’t tell you where you
may and may not drive it. The FSF
provides licenses like the GPL to
enable software developers to pursue
a similar philosophy if they so choose.

The Free Software Foundation web

site has a more detailed presentation
of how the licenses and tools relate to
its mission. When you buy a CD con-
taining Free Software Foundation

products, you demonstrate support of
the FSF’s goals with your dollars. So,
the FSF wins and so do you.

Purchasing a CD also gets you

some support time with the vendor,
which can come in handy if you have
trouble with installation or when you
set out to adapt the tools to run on
your own hardware. Usually this
adaptation process is straightforward,
but having someone around who
knows the tools in greater detail is
always an advantage.

Finally, buying a CD usually makes

business sense. You can find one for
about the same price as a couple of
hours of an engineer’s salary. Unless
you have a lot of prior GNU experi-
ence, creating a basic GNU installa-
tion by hand in a business setting
will cost you more.

Listing 3—The

objdump command can, among other things, produce an intermixed listing.

$ arm-elf-objdump --source hello | less

...

80d8: 000114fc streqd r1, [r1], -ip

80dc: 00010bc0 andeq r0, r1, r0, asr #23

80e0: 000000ff streqd r0, [r0], -pc

000080e4 <foo>:

80e4: e1a0c00d mov ip, sp

80e8: e92dd800 stmdb sp!, {fp, ip, lr, pc}

80ec: e24cb004 sub fp, ip, #4 ; 0x4

80f0: e24dd004 sub sp, sp, #4 ; 0x4

int a_global = 10;

int foo ( int arg )

{

80f4: e50b0010 str r0, [fp, -#16]

static int foo_counts = 0;

foo_counts++;

80f8: e59f2028 ldr r2, [pc, #28] ; 8128 <foo+0x44>

80fc: e59f3024 ldr r3, [pc, #24] ; 8128 <foo+0x44>

8100: e59f2020 ldr r2, [pc, #20] ; 8128 <foo+0x44>

8104: e5921000 ldr r1, [r2]

8108: e2812001 add r2, r1, #1 ; 0x1

810c: e5832000 str r2, [r3]

return foo_counts + arg;

8110: e59f3010 ldr r3, [pc, #10] ; 8128 <foo+0x44>

8114: e5932000 ldr r2, [r3]

8118: e51b1010 ldr r1, [fp, -#16]

811c: e0823001 add r3, r2, r1

8120: e1a00003 mov r0, r3

8124: ea000000 b 812c <foo+0x48>

8128: 00010cc4 andeq r0, r1, r4, asr #25

}

812c: e91ba800 ldmdb fp, {fp, sp, pc}

...

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

You will need an ARM Evaluator-

7T board if you want to attempt the
“hello world!” program on real hard-
ware. If you don’t want to invest in
hardware just yet, stick with me any-
way. The GNU debugger comes with
an excellent ARM instruction set
simulator that can emulate much of
what the Evaluator-7T can do, and in
some cases even more, without any
external hardware.

On Circuit Cellar’s web site, I’ve

provided a list of the files you will
need to download. There will proba-
bly be later versions of each of these
packages by the time you get around
to downloading them, but stick with
the listed versions until you’ve com-
pleted the process at least once.
Updates occasionally change the
installation procedure.

Note that if you use Internet

Explorer from Microsoft to download
these, you must right-click on the
download link and select Save Link
As. As you might imagine, the Free
Software Foundation’s web site stays
busy. If you have trouble getting a
connection, try using one of the mir-
ror sites listed on the GNU site, at
www.gnu.org/order/ftp.html.

about than by digging around and get-
ting a little dirt under your finger-
nails, so to speak. Let’s get started!

BUILDING GNU TOOLS

In the next few sections, I’ll explain

how to set up a compiler, runtime
library, assembler, linker, and debugger
that may be used to produce and run
applications for the ARM Evaluator-
7T development board. Then, you’ll
test it by building and running a sim-
ple “hello world!” style application
on the ARM microprocessor.

The first step in the process is to get

the materials. Note: I assume you’re
working in one of two host environ-
ments, either a Linux or other Unix-
like workstation or on a Win32 PC
running a Unix emulation environ-
ment called Cygwin (sources.redhat.
com/cygwin). If you install Cygwin for
this article, use the default installation
setup. If you’re trying to run Cygwin on
Windows 95 or 98, make sure you get
the latest version of Cygwin. Earlier
versions don’t deal well with the bugs
in these two operating systems, to the
point that frequent reboots would be
necessary in order to complete the
process you’re about to start.

The binutils package includes the

GNU assembler and linker. Next,
note that the gcc package contains
the GNU C/C++ compiler. Newlib is
the C runtime library you’ll use to
supply functions like

printf(). And

lastly, the gdb package contains the
GNU debugger.

The text in Listing 1 shows the

commands needed to configure and
install the GNU tools. Use the

command to change to the directory
containing the files you just down-
loaded, and then type in the com-
mands as they appear in the figure.

The commands are the same for

both Unix and Cygwin environments.
The first section of the commands
sets up a few environment variables,
and makes sure that the installation
location is in the path. Each subse-
quent section then configures and
installs each of the components in
the GNU tool chain.

When you’re finished, you will see

a number of programs in the directo-
ry

${PREFIX}/bin (c:\cygwin\home\

administrator\arm-elf\bin). The com-
piler is

arm-elf-gcc, the assembler

arm-elf-as, and the linker is

arm-elf-ld. arm-elf-objcopy is a
utility that translates files to different
formats (from elf to S Record, for
example), and

arm-elf objdump is a

utility that can dissect the compo-
nents of a file to show you things like
symbol addresses and a disassembly
of the file’s object code.

You need about 500 MB of free disk

space in order to build a complete GNU
cross-development environment. If
space is tight, you can delete the files
left at the end of each stage of the
procedure before you move on to the
next step. For example, after you move
on to the

build-bootstrapgcc

directory, you can delete the contents
of the

build-binutils directory.

The installed tool set requires less
than 100 MB of disk space.

Note that if you have to reboot

your computer during this process,
you will need to again add the loca-
tion of the GNU tool binaries like
sh-elf-gdb to your search path
before continuing:

$ export PREFIX=‘pwd‘/arm-elf

Listing 5—When gdb stops at a breakpoint, you can print and display variables.

Breakpoint 2, main() at hello.c:20.

20 printf( "%s", charstr );

(gdb) print nloops

$1 = 0

*****************************************************************

(gdb) display nloops

1: nloops = 0

Listing 4—gdb's

list command displays source codes of functions.

(gdb) list main

9 foo_counts++;

return foo_counts + arg;

11 }

int main ( void )

14 {

15 int

nloops;

char *charstr = "hello, world!\n";

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

$ export PATH=$PATH:${

PREFIX}/bin

Take note, the

pwd trick works

only if you run the Export command
from the same place you ran it from
previously. If you can’t remember
where that was, you’ll have to add the
right path in by hand.

COMPILING A PROGRAM

Now that you have shiny new

tools, let’s try them out. Using the
text editor of your choice, create a

hello.c

file that looks like Listing 2.

The basic command to compile

hello.c into an ARM executable file
called

hello, is this:

$ arm-elf-gcc -Wall -g -o

hello hello.c

The

-Wall option causes gcc to

emit warnings for almost every kind
of suspicious code construct it finds,
and the

-g option includes debugging

information in the output file. gcc
supports many, many command line
options, including options to opti-
mize code, and others to translate the
code into assembly language. See the
gcc web site for more options. If you
are using the GNU tools under some
versions of Cygwin, the compiler’s
output file is called

hello.exe

instead of just

hello.

USING OBJDUMP AND OBJCOPY

The utilities

objdump and objcopy

are two of many hidden gems of the
GNU tool family.

Objdump cracks

apart the contents of object and exe-
cutable files to display their contents.
Objcopy translates object and exe-
cutable files to different formats. One
common use of

objdump is to see an

application’s source code intermixed
with assembly code. The output in
Listing 3 shows how to do this. Press
the spacebar a few times to scroll
through the output.

To translate your hello program

into a Motorola S Record file, use
objcopy:

$ arm-elf-objcopy -output-

target srec hello
hello.srec

DEBUGGING

So far, I’ve showed you how to set

up a GNU cross development tool
chain for the ARM7 microprocessor,
and used the tools to build and dis-
sect a simple, “hello world!” pro-
gram. We just scratched the surface of
what GNU tools can do, but the
introduction was still worthwhile.

Now, let’s run some code.
If you do not have the Evaluator-7T

or you just don’t want to set it up
yet, you may use the GNU debug-
ger’s ARM instruction set simulator
to do all of the following steps with-
out any ARM hardware. The simula-
tor is so complete, in fact, that even
printf() works properly (the out-
put shows up on the gdb console).
Typical of GNU tools, the debugging
procedure is almost exactly the
same whether you are using the
instruction set simulator or real
hardware. For clarity, I will provide

two sets of instructions in places
where there is a difference.

If you intend to use real hardware,

unwrap your new Evaluator-7T board
and plug it in now. Connect the serial
cable to the debug port on the board,
and connect the other end to a serial
port on your PC. Make note of the
serial port you connect it to, because
the debugger will use that port in a
moment to control the board.

Change to the directory containing

the

hello executable, and use the fol-

lowing command to launch the GNU
debugger from the command prompt
on your workstation:

$ arm-elf-gdb hello

If you’re using the ARM instruction
set simulator, tell gdb to establish a
connection to it:

(gdb) target sim

Listing 6—The

next and step commands step over and into function calls.

(gdb) next

hello, world!

21 foo( nloops );

(gdb) step

foo (arg=35704) at hello.c:6

(gdb) step

(gdb) <ENTER>

Listing 7—The

disassemble as well as the x command show the assembly language for a function.

(gdb) disassemble main

0x80e4 <main>: mov r12, sp

0x80e8 <main+4>: stmdb sp!, {r11, r12, lr, pc}

0x80ec <main+8>: sub r11, r12, #4 ; 0x4

0x80f0 <main+12>: sub sp, sp, #8 ; 0x8

0x80f4 <main+16>: bl 0x8214 <__gccmain>

0x80f8 <main+20>: ldr r3, [pc, #3c] ; 0x813c <main+88>

0x80fc <main+24>: str r3, [r11, -#20]

0x8100 <main+28>: mov r3, #0 ; 0x0

0x8104 <main+32>: str r3, [r11, -#16]

0x8108 <main+36>: ldr r3, [r11, -#16]

0x810c <main+40>: cmp r3, #9 ; 0x9

0x8110 <main+44>: ble 0x8118 <main+52>
0x8114 <main+48>: b 0x8134 <main+80>
0x8118 <main+52>: ldr r0, [pc, #20] ; 0x8140 <main+92>

0x811c <main+56>: ldr r1, [r11, -#20]

(gdb) x/i $pc

0x8178 <main+72>: ldr r3, [r11, -#16]

Working on your

next masterpiece?

It’s time for new tools.

POWERFUL PCB LAYOUT

AUTOROUTING & AUTOPLACEMENT

NETWORK & COMMUNICATIONS SIMULATION

Powerful & easy-to-use PCB layout & editing

Reroute while move (full rubberbanding)

3D board visualization

Real-time design rule check

Component push & shove with springback

Extensive copper placement capabilities

Benchmark test leader with superior routing results

Combination of grid-based/gridless routing available

Highly ﬂexible router provides complete control

Optimal part placement improves routing performance

Supports manual wire pre-placement

Pin and gate swap

Powerful, yet easy-to-use fast, accurate simulation tool

Model & simulate end-to-end communications systems

Analog, digital & mixed system design capability

Industry-leading block libraries — channels,

encoders/decoders, modulators/demodulators

View simulation results in various methods

— time domain, frequency domain, xy plots,

log scale, eye diagrams and power spectra

from $399

SCHEMATIC CAPTURE, SIMULATION & PROGRAMMABLE LOGIC

Advanced modeless schematic capture

Library of 16,000 parts supplied, with 12 million online

Analog, digital and mixed-mode simulation

Patented co-simulation of SPICE, VHDL and Verilog

Suite of “virtual instruments” including oscilloscope,

wattmeter, spectrum analyzer & network analyzer

Design collaberation across the Internet

sales: 800.263.5552 • http://www.electronicsworkbench.com

© 2001 Interactive Image Technologies. All rights reserved. Electronics Workbench, Multisim and Ultiboard are registered trademarks of Interactive Image Technologies Ltd. All other trademarks are registered trademarks of their respective owners.

Electronics Workbench products are
used by more designers than any
other software of their kind. They
will help you reduce development
times and produce higher quality
circuits — We guarantee it, or your
money back!

We offer a portfolio of products
to meet all your design needs:
Schematic Capture, Component
Database, SPICE/VHDL/Verilog
HDL/RF Simulation, PCB Layout,
Autoplacement, Autorouting and
now Network & Communications
Simulation.

Ease-of-use continues to be one of
our biggest strengths, letting you
produce designs in the time it takes
to install and conﬁgure most other
programs.

Our unique combination of power
and unrivaled ease-of-use allows
us to offer this guarantee. Power
means you get capabilities simply
not available elsewhere, such
as patented co-simulation of
SPICE/VHDL/Verilog/RF all together.

That’s why we are the EDA supplier
of choice to over 150,000 users
worldwide.

The World’s Most Popular

Electronic Design Tools

The red/black banner is a trademark of Texas Instruments. 45-5216R

Mixed-Signal Controllers

Choose, don’t compromise. The MSP430F12x from Texas Instruments is the latest addition to

the expanding portfolio of Flash-based 16-bit RISC MCUs. From $0.99 to 60 kB, the MSP430

family provides a range of exceptional cost/performance solutions to meet the rigorous

requirements of low-power applications. See for yourself: order your development tool today.

TI MSP430: the choice in
ultra-low-power Flash MCUs.

MSP-FET430P120 Flash

emulation tool for

only $99 or a free

MSP430F12x data sheet.

www.ti.com/sc/f12x

■ Ideal for battery-powered applications such

as utility metering, intelligent sensing and
portable measurement

Features:

■ Ultra-low power consumption –

250-µA active mode, 0.8-µA standby mode
at 2.2 V (typ.)

■ Integrated analog peripherals

ideal for precision data conversion

■ 16-bit RISC CPU enables new

applications at a fraction of the code size

■ In-system programmable Flash allows

last-minute code changes and remote
field upgrades

P120

Flash RAM I/O WDT Comp_A Timer_A USART Timer_B

ADC MPY Price

†

MSP430F1101 1 kB 128 14

$0.99

MSP430F1111 2 kB 128 14

$1.34

MSP430F1121 4 kB 256 14

$1.74

MSP430F122 4 kB 256 22

$2.39

MSP430F123 8 kB 256 22

$2.51

MSP430F1222* 4 kB 256 22

10-bit

$2.62

MSP430F1232* 8 kB 256 22

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

If you are using the Evaluator-7T

board, tell gdb to establish a connec-
tion to it instead. The command used
here will vary depending on what
kind of host machine you are using
and what serial port you’ve plugged
into. Let’s look at an example of how
to select the right debugging target.

If you’re using a Cygwin host, use a

command like this:

(gdb) set remotebaud 57600
(gdb) target rdi com1 (or

com2, or ...)

For a Linux or other Unix-like host,
change the second line of the com-
mand to read:

(gdb) target rdi /dev/ttyS0

(or /dev/ttyS1, or ...)

You may see an “unimplemented

message” error when gdb establishes
the connection to the target board.
This is normal, it just means that the
board’s firmware has a few low-level
commands that gdb doesn’t recognize
or that the target board lacks some
commands that gdb understands.
During the connection process, gdb
will negotiate with the target board
until the two agree on the set of com-
mands that are available. After gdb
has established a connection with the
instruction set simulator or Evaluator
board—referred to uniformly as the
debugging target—gdb tells it to
download your application to the tar-
get in preparation for debugging:

(gdb) load

Set a breakpoint at

main() with:

(gdb) break main
Breakpoint 1 at 0x8140: file

hello.c, line 14

Now, it’s time to launch the appli-

cation. If you are running the
instruction set simulator, use the
Run command. If you chose the
Evaluator-7T, make sure to use the
continue command:

(gdb) run
(gdb) continue

The debugger should stop when you

reach

main():

Continuing.
Breakpoint 1, main(), at hello.c:14
14 {
(gdb)

This display says that gdb encoun-

tered the breakpoint you set, and is
currently stopped at source line 14 in
hello.c. gdb displays the source line,
which contains only an opening bracket.

Type

list to list a few lines from

main() (see Listing 4). In general, gdb
repeats your last command if you just
press enter. So if you press enter here
a few times, listing will continue
beyond

main() if there is anything

beyond it to list. Set a breakpoint at
the

printf() function call on line 20,

then continue running the program:

(gdb) b 20
(gdb) c

Listing 8—The

stepi command steps individual machine instructions.

(gdb) stepi

0x817c 19 for( nloops = 0; nloops < 10; nloops++ ) {

(gdb) <ENTER>

0x8180 19 for( nloops = 0; nloops < 10; nloops++ ) {

(gdb) display/i $pc

2: x/i $pc 0x817c <main+76>: add r2, r3, #1 ; 0x1

(gdb) stepi

0x8180 19 for( nloops = 0; nloops < 10; nloops++ ) {

2: x/i $pc 0x8180 <main+80>: str r2, [r11, -#16]

(gdb) <ENTER>

2: x/i $pc 0x8184 <main+84>: b 0x8154 <main+36>

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

function call, reports the argu-
ments to

foo(), and reports

its location in the source code.
Remember that if you just
press enter, gdb will repeat
your previous command.

Listing 7 shows the

disas-

semble command. To disassem-
ble just the instruction the
processor is about to execute,
use the examine memory (

command, with the instruc-
tion (

/i) option.

To step one processor

instruction, use the

stepi

command. In situations in
which multiple processor
instructions are associated

with a single C statement, the
program counter value shown

at the far left of the output changes
even though the source line displayed
stays the same.

When combined with the

display

command, you can use the

stepi

command to watch the processor step
through assembly code (see Listing 8).
To see the value of a particular regis-
ter, use the

print command. To pre-

vent clashes with similarly named C
objects, use a

$ prefix for register

names (e.g.,

(gdb) print $r3).

To see the value that a call to

foo() would return, simply invoke
foo() from the debugger. The called

When you reach the next break-

point, examine the value of

nloops

(see Listing 5). The

print command

displays

nloops only once; display

will display it every time the debug-
ger stops the program when it is in
scope. In either case, the current
value of

nloops is zero. The $1 text

is a mnemonic that can be used in
place of

nloops to save some typing

later or for scripting (see Listing 6).

The output of the

next command is

the result of the

printf() function

call, which you didn’t step into. The
step command steps into the foo()

Photo 1—Check out a screen capture for the DDD debugger.

Photo 2—Here, you can see a screen shot from the VIDE integrated development environment.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

Bill Gatliff is a freelance embedded
developer and training consultant
with nearly 10 years of GNU and
embedded experience. He is the cur-
rent maintainer of the CrossGCC
FAQ, an active participant on the
CrossGCC mailing list, and a noted
lecturer and author. Bill welcomes
comments and feedback, and may be
reached through his web site at bill-
gatliff.com.

function is actually run by the debug-
ging target, so any side effects pro-
duced will remain:

(gdb) print foo(10)
$4 = 12
(gdb) print foo(10)
$4 = 13

Finally, when you’re done, quit with
(gdb) quit.

GRAPHICAL DEBUGGING

By now you may have concluded

that although gdb is functional, it
isn’t pretty. And trying to debug code
that interacts with complicated data
structures using a command line
interface can be tedious at best. Is this
the best that GNU can do? Of course
it isn’t. Like many GNU tools, gdb is
a command line application because
it is used as a foundation for other
applications, including several graphi-
cal debugging interfaces. As a result,
all the point-and-click you could ever
want in a debugger is available, and
from a variety of sources.

A screen shot for a popular graphi-

cal debugging front-end to gdb is
shown in Photo 1. This application is
called DDD, which uses a command
line gdb running in the background to
do its work. This may sound clumsy,
but it has tremendous benefit: the
same binary DDD application works
for all versions of the GNU debugger,
regardless of the target chosen.

Another popular program is called

Insight, an enhanced gdb that can run
on both Win32 and all other Windows
workstations. Insight must be config-
ured and installed for each version of
the debugger that you intend to use.

WHAT ABOUT IDE?

There are many freely available

packages for complete point-and-click
development environments. Like the
strategy used to enhance gdb with
graphical capabilities, all of these
options use the standard GNU com-
piler and other tools behind the scenes,
which is why it is important to know
how to set up the basic tools first.

One option open to you is called

VIDE. This package contains features
you would expect in an integrated

SOURCES

Software
Free Software Foundation
(617) 542-5942
Fax: (617) 542-2652
www.gnu.org

ARM Evaluator-7T board
ARM, Inc.
82 31 712 8234
Fax: 82 31 713 8225
www.arm.com

GNUPro
Red Hat, Inc.
(888) 733-4281
(919) 547-0012
Fax: (919) 547-0024
www.redhat.com

GNU X-Tools
Microcross, Inc.
(478) 953-1907
Fax: (478) 953-7661
www.microcross.com

SOFTWARE

The code and a list of the software
needed are available on Circuit
Cellar

AD422 (Requires 9VDC) $79.00
AD422-1 for 110VAC

development environment, including
a graphical editor, project files, and
build management.

Another option to try, albeit one

that takes some work to set up for
embedded use, is KDevelop (kdevel-
op.kde.org). This environment is cur-
rently in widespread use on Linux
hosts to write and maintain applica-
tions for the KDE window manager.
And, it is an extremely powerful and
full-featured IDE for producing native
applications. Because it uses GNU
tools behind the scenes, however, it
can be suited for embedded duty by
tweaking some configuration files.
Take a look at the screen shot of
KDevelop in Photo 2.

COMMERCIAL GNU OFFERINGS

Earlier I mentioned that a handful

of companies offer pre-configured and
ready-to-go versions of GNU tools for
all kinds of embedded processors. I’ve
had good luck with GNUPro by Red
Hat and X-Tools by Microcross.

At the high end, you can’t get much

better than GNUPro. This product
contains the latest and greatest ver-
sions of everything GNU has to offer,
thoroughly tested and maintained by
the company that employs more
GNU developers (embedded and oth-
erwise) than any other company in
the world. And, Red Hat offers a level
of support that you simply cannot
find anywhere else.

But, this level of attention comes at

a cost. A GNUPro distribution starts
at about $20k (US $), including
unlimited support for up to 10 users.
For organizations contemplating
aggressively customized GNU tools,
this is a reasonable and pragmatic
sum of money. For someone who just
wants an introduction to GNU, the
package is overkill.

Fortunately, there is an option at

the low end. X-Tools is a unique offer-
ing that costs about $150. Microcross
markets a single CD containing GNU
tools for almost every target that
GNU supports. In addition, you get an
informative and well-written manual,
a graphical installer, PDF versions of
all available GNU documentation,
and a copy of the VIDE integrated
development environment.

The Microcross CD makes sense

for someone who wants an introduc-
tory look at using GNU tools for
embedded work and doesn’t want to
get mired in the details of setting up
the tools themselves. X-Tools is also
a good choice for someone who
knows he will be working with mul-
tiple target architectures or someone
who may need service or support in
the future. Finally, X-Tools is espe-
cially appropriate in situations in
which the development environment
must be a Win32 host; X-Tools comes
in both Windows and Linux flavors.

CIRCUIT CELLAR

www.circuitcellar.com

n the last few

years, I have found

much pleasure and

value in riding bicycles

in and around the streets and trails of
Austin, Texas. I use my bike to com-
mute to work and ride the local dirt
trails. In the winter, I often have to
cycle back from work or a day on the
trails in darkness. At first I used a
low-cost, 2.5-W, handlebar-mounted
lamp, which was woefully inadequate.
A quick browse through the local bike
shops revealed that a good quality,
lightweight bike light would cost
almost as much as my bike! The spe-
cialized mail-order catalogs were not
less expensive.

The crunch came when some of my

biking buddies persuaded me to join
their team in a 24-h relay bike race,
which of course required nighttime
riding. That was the incentive I need-
ed to come up with my low-cost,
adaptable solution to my problems. I
would build my own bike light con-
troller and battery charger system.

There are two parts to this project,

the lamp controller and battery charger.
Let’s start things off by discussing the
lamp controller development. The
controller and main part of the charg-
er are one and the same hardware.

The main difference is in the software.
Additionally, the charger requires a
constant current source of around 2 A.

LAMP CONTROLLER

I split the project into four main

parts—definitions of requirements,
design details, implementation, and
debugging and testing. Let’s look at
the requirements first.

Small size is important for two

main reasons. Firstly, I wanted the
controller to be connected in-line
with the existing power cord between
the battery pack and lamp unit,
which necessitated low weight and,
therefore, small size to minimize
strain on the power cord. Having an
in-line connection made it easy to fit
the controller to the bike light assem-
bly. Plus it meant that in the, ahem,
unlikely event that the controller
failed, I could quickly remove it and
just run the lamp directly off the bat-
tery, giving me a “limp home” mode.

Secondly, I wanted to mount the

controller on the helmet, and any
increase in weight might cause undue
neck strain.

Low cost is the next requirement.

Cost can mean many different things,
but for me, the time to develop the
system and the cost of the tools were
actually more important than the
component costs.

I knew from experience that the

component costs would be low,
regardless of the type of components
(e.g., MCU, power device, connectors,
and switches). For me, the overriding
cost factor was time, because I had
only one month of spare time to have
a completely reliable controller up
and running. To meet my technical

Richard Soja

An Integrated PWM
Light Controller

FEATURE
ARTICLE

Like many great proj-
ects, this one started
out when Richard
decided that commer-
cial offerings of night-
time riding lamps for
bicycles were just too
expensive. More than
merely a bright idea,
this project also
included a battery
charger and a host of
other enhancements.

Issue 137 December 2001

Figure 1—A small number of physical interconnects
are needed in the light controller when a highly inte-
grated MCU is part of the design.

Downloaded

patch

Monitor

driver

MCU

Application code

MCU

Mode

jumper

Battery

Power
switch

Lamp

Piezo

zzer

Hardware

Software

Physical

serial

interface

User

select

switch

Part 1: A Light Controller

www.circuitcellar.com

CIRCUIT CELLAR

requirements in the time frame avail-
able, I would have to use a standard
MCU that I was familiar with and
have the tools to program and debug
the system in real time.

This led to using a MC68HC811E2

by Motorola for the MCU, and using
the free PCBUG11 tool for program-
ming and debugging. Because the code
space was limited, and I had to imple-
ment a number of interrupt handlers,
I used the free assembler, ASMHC11.

I also needed the unit to be easy to

use. To keep things simple, I required
a single push button switch to provide
on/off and variable power control as
well as a means to signal the remain-
ing battery time left. Operation of the
switch had to be simple enough to
allow on-the-move control of the
lamp, without causing distraction,
which could easily lead to a crash.

I decided that the device must work

with NiMH batteries and standard 6-V
bicycle lights. NiMH batteries are an
ideal power source for cycling lights
because they’re light and provide a
high-energy density, making them
compact enough to attach to the
human body without much discom-
fort. My quick survey of lighting sys-
tems and availability of replacement
lamps revealed that 6 V was the most
common voltage used, and thus
became a requirement.

A reliable low battery warning was

another must. Being out on a dark trail
when the battery runs down can result
in serious problems. It could mean
walking in total darkness back to the
trailhead. Because walking pace is about
four to six times slower than cycling,
what was only a 10-min. ride back to
base could turn into an hour hike.

Knowing how much battery capac-

ity is left can be crucial, but also this
is where many of the problems lie. I
have read reports that some commer-
cially available “smart chargers”
indicate low charge after only 15 min.
of use of a fully charged battery, and
then revert to a “limp home” mode to
conserve power. Clearly I wanted to
avoid the latter situation. Moreover,
the method of reporting low battery
charge had to be unambiguous, but
should not require distracting the
rider in any way.

Another important part of the

system is a range of lamp power
levels and good battery duration.
Because riding conditions can
vary on both a dirt bike trail and
on the road, it isn’t always neces-
sary to run at full lamp power.
And reducing the power will, of
course, extend the duration
before the battery is discharged,
thus providing more riding time.

The base requirement was for

at least 1.5 h of useful illumination.
My initial plan was to ride in a 24-h
relay race, which meant two or possi-
bly three 1-h laps at night. One and a
half hours of illumination would pro-
vide an adequate safety margin in the
event that I had a flat or crash.

For cycling needs, lamp life is not a

big issue. A typical lamp used for
cycling is a 10-, 12-, or 15-W, 6-V
MR11 halogen, which is normally
rated at around 2000 h at the rated
voltage. This is equivalent to riding
1 h every night for a period of almost
three years! Because a long lamp life
wasn’t a concern, this opened up the
possibility to over drive the lamp to
increase its output power, thus pro-
viding improved illumination over the
tough technical sections of the trail,
or just to make sure oncoming vehi-
cles see me on the road.

One important requirement con-

cerning lamp life was to ensure that
the lamp would not fail when switched
on because of the characteristic initial
high surge current. This occurs because
the lamp impedance when cold is
usually one order of magnitude lower
than when it is hot. A typical 12-W,
6-V MR11 lamp has a cold impedance
in the region of 0.2

Ω

. The battery

impedance is around 0.15

Ω

, and a

nominal 7.2-V battery has an initial
voltage of around 8.4 V when fully
charged. The resultant initial surge
current into a lamp could be around
24 A. The requirement was to provide
a means to ensure the lamp did not
fail by limiting the inrush current.

When compiling a list of require-

ments, I thought about the design
process. Because I had to balance the
time I could spend on the develop-
ment of this project between my fam-
ily life and work, the project had to be

relatively easy to construct with off-
the-shelf components and minimal
design effort. Using a Motorola
MC68HC811E2 meant that few exter-
nal components were required and the
connection to the programming and
debug tool was trivial.

I also considered that the project

should be easy to program and debug.
Ideally, I wanted to program and debug
in the same environment as the final
application, and not have to change the
run time code or its operating charac-
teristics when in Debug mode. I met
this requirement with PCBUG11.

I wanted to use the same hardware

to perform battery charging control.
This gives the potential benefit that
the system will be able to more accu-
rately know the state of the battery’s
charge and provide more accurate
information to me.

Last on the list, because this was

my first foray into the details of
rechargeable batteries, I wanted to be
able to log the charge and discharge
characteristics directly, so that I could
best determine the charged state of
the battery from its voltage profile.

DESIGN

Hardware and software partitioned

the design. Figure 1 shows the high-
level partitioning of the bike light
controller. The key parts of the hard-
ware were the lamp, battery, MCU,
power switch for controlling lamp
power, user input push button switch
for selecting power levels, a piezo-
electric buzzer for signaling battery
condition, and a jumper for selecting
either Single-Chip mode for normal
application execution or Bootstrap
mode to permit reprogramming of the
EEPROM. The software consisted of
three main modules—the application

Issue 137 December 2001

Figure 2—One channel of the timer system of the 68HC11 is
configured as a software-assisted PWM output. No external
interconnections are required to configure the two compare
registers and pin logic.

Free-running timer

control

latch

Output compare 3

Reset

Output compare 1

Set

Software access

PWM on

port A,

bit 5

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

code, debug monitor driver (talker),
and a downloaded patch to monitor
battery voltage every minute.

The application code itself was par-

titioned into a number of sub-modules,
including three interrupt handlers (a
PWM function to control the lamp
power, buzzer timer control, and real-
time clock (RTC) for battery monitoring
and profiling and for push switch
debounce). Another sub-module con-
sists of initialization routines to set up
the on-chip hardware system, program
variables, PWM, and RTC functions.
A background task, designed as a finite
state machine, processes any new push
button switch and takes appropriate
action depending on the current state.

Still others include: a push switch

read routine; battery check routine to
determine when a message should be
emitted to the buzzer; buzzer driver;
ADC driver; a power-to-PWM modu-
lation conversion routine; and a routine
to range check the target power value
and set the power ramp direction.

It may seem overly complex for a

simple light controller, but there were
several factors that caused me to
design the software this way.

The 68HC11 I chose has a simple,

straightforward timer system that has
neither a hardware PWM nor hard-
ware RTC. This meant I had to design
these plus the buzzer timer control in
software using interrupt handlers.

The system operates in Single Chip

mode, so I had no ability to access the
real-time activities of the application
code through an external bus interface,
especially the interrupt handlers. To
minimize the opportunity for software
errors, I partitioned the software in a
way that would isolate the functionality
by module. Then, hopefully the source
of any errors could be more readily
detected by code inspection, simula-
tion, and program variables analysis.

Communication with the PC-based

debugger/programmer tool was through
an RS-232 physical serial interface
connected to the SCI of the HC11.

Because average brightness from the

halogen lamp is a function of average
applied current, a pulse width modu-
lation method was used to vary the
average voltage, and hence the average
current into the lamp. Reduction of
inrush current to the lamp (soft start)
was achieved by gradually increasing
the PWM value from some minimum
level, ideally zero, but the implemen-
tation somewhat restricted the
dynamic range of the PWM. This did
not affect the operation of the lamp.

The optimum frequency of modula-

tion was unknown, so some experi-
mentation with PWM parameters was
necessary. This was built into the
architecture of the software. The trade-
off was between minimum PWM high
time and maximum PWM frequency.

I toyed with the idea of providing

flexible control of the lamp brightness
by letting the lamp power cycle grad-
ually through its full range while the
push button was depressed. On release
of the button, the power would stay
constant. However, this seemed to be
a trail rider’s nightmare, because too
much time spent holding down the
button left only one hand in control
of the bike which could result in a
nasty fall. The final design detected a
quick push and release to cycle through
four fixed power values, including off.

The remaining battery charge would

be reported as coded beeps from a sound
transducer. The coding had to be sim-
ple to understand and easy to imple-
ment. The final choice was to sound a
single short beep for each 5 min. of
estimated time remaining. The code
would be preceded by a beep of
noticeably longer duration and tone,
to introduce the arrival of a code.

OC1 Match

OC3 Match

OC1 Match

OC3 Match

OC1 and OC3 Match

OC1 Match

OC3 Match

Period

Figure 3—This is an example of the effect on modulation when you turn off the lamp. The PWM modulation pro-
gressively decreases to the minimum value, and then abruptly switches to 0%.

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

Although I had some great data on

nickel metal hydride (NiMH) cell dis-
charge characteristics from Panasonic’s
web site, it was important to observe
the discharge characteristics of the
batteries I would use in the implemen-
tation. This was the only way I could
be confident that I had calculated the
battery charge duration versus delivered
power levels, and be able to approxi-
mately determine the final 15-, 10-,
and 5-min. points of the batteries I
would use. Luckily, the local CompUSA
was selling off old NiMH laptop bat-
teries for $10. They were rated at 7.2 V,
3.7 AH, which was perfect for my
needs! However, the batteries were
past their shelf life, so I needed to be
sure they could hold charge and deliv-
er close to their rated capacity.

IMPLEMENTATION

As I planned to allow overdriving

of the 15-W, 6-V lamp with potential-
ly 7.2 V (giving 44% more lamp
power), I needed a CMOS-controlled
power switch that could handle 3 A
continuously at ambient temperatures
of at least 95°F (35°C). Texas nights
can be real hot!

Packaging also had to be compact.

The IRF7311 dual N-channel power
MOSFET in the SO8 package met the
requirements perfectly. Its low
Rds(on) of around 30 m

Ω

meant

power loss was also kept to a minus-
cule 270 mW. With thermal imped-
ance of 62.5° C/W, the maximum

junction temperature would not
exceed around 52°C—well within the
150°C rated maximum. The small
outline package and pin configuration
also enabled me to solder the gate and
source pins of the device directly to
the timer and ground pins of the
HC11 to provide PWM control.

On the 68HC811E2, the PWM was

synthesized by software interrupt
handlers, which drives a pair of cou-
pled output compares onto a single
output pin. Figure 2 shows the logical
internal connections that are config-
ured by the software initialization
routine. An output compare function
works by comparing the value loaded
into the output compare register with
the value of a free-running timer.

Free running means the timer is

never reset nor started at any specific
value. The 16-bit timer of the HC11
just counts continuously from 0 to
$FFFF, then restarts again at zero.
When the timer value matches the
output compare value, a signal is sent
to the pin logic and CPU interrupt
system. The pin logic can then cause
the physical pin of the MCU to
change state in the same clock cycle
as the timer match occurred.

Additionally, the signal to the inter-

rupt system can cause the MCU to
execute an interrupt handler to update
the value stored in the output com-
pare register, plus any other activities
that are necessary. In this way, the
output compare function allows soft-
ware to schedule a change in the pin
state in real time and do it independ-
ently of the software execution time.

Scheduling the pin state is done by

adding an offset to the last time the
pin changed state (i.e., the time when

the last compare occurred), and writ-
ing the new value to the appropriate
compare register. Using this tech-
nique, any arbitrary real-time pulse
train can be synthesized in software,
provided the time between adjacent
pin changes or pairs of pin changes is
at least greater than the execution
time of the software needed to sched-
ule these pin changes.

Figure 3 shows a typical PWM output

from this system. The period is defined
between rising edges, and is scheduled
using Output Compare 1. The falling
edge is scheduled using Output
Compare 3. Both can be scheduled at
the same time because both edges are
scheduled from different compare reg-
isters. The advantage of this mecha-
nism over scheduling a toggle action
each consecutive edge with a single
output compare is that the maximum
value of the PWM modulation (maxi-
mum high time) is independent of the
latency of the interrupt handler, and
can therefore reach 100%.

The minimum modulation is

greater than zero, in fact, it is greater
than it would be if there were separate
interrupt handlers for the rising edge
and falling edges. However, it’s impor-
tant to be able to achieve a 100% PWM
modulation; this would be quite messy
and cause discontinuities on modula-
tion if separate rising and falling edge
interrupt handlers were used.

Testing when the minimum modu-

lation approached the latency of the
OC1 interrupt handler or reached 100%
was performed in a background task
that updated the modulation value
based on the requested power level. If
the modulation reached the minimum
boundary, the modulation was forced
to 0%. And if the modulation tried to
exceed the PWM period, it was forced
to the period value. This avoided the

Photo 1—The prototype controller is shown here.

Photo 2—Check out the helmet mounting.

Photo 3—Here I am testing the e

quipment in field trials.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

need for the interrupt handler to per-
form time-consuming tests on the
modulation values, except for a zero
value, because an interesting dilemma
occurs at the 0% and 100% modula-
tion values in this implementation.

At these modulation values, the

OC1 and OC3 matches are concur-
rent, and the state the pin takes as a
result of these matches is dictated by
the particular hardware design of the
pin logic. In the HC11, OC1 has prior-
ity, which results in 100% modula-
tion. To achieve 0% modulation, the
interrupt handler has to make the pin
go low instead of high when the OC1
match occurs.

To simplify the software, I applied

the soft start concept to the power
selection operation as well as to the

initial start up of the lamp. That is,
any request for a change in power
would be met by ramping the power.
So, from the off state, power is
applied slowly to provide soft starting.
Thereafter, when you request a differ-
ent power level, the power level
ramps towards its new target value.

The software contains a number of

checks to ensure that the target power
demanded by you is tracked properly.
By rapidly pressing the push button,
you can cycle through the power selec-
tions faster than the software can
keep up with. The outcome of this is
that the ramp can change direction
before power has reached its previous-
ly requested target value. This is not
because the software is inefficient,
but rather the power ramping time
constant implemented in the software
was chosen to be slow.

The user-selected power value is

coupled to the PWM operation
through a routine that updates the
target modulation factor and ramp
direction based on the current modu-
lation factor. The software also

ensures the modulation values are
kept within the maximum and mini-
mum range and allows the off value
of 0% modulation.

The other timing function controls

the buzzer through the second MOS-
FET switch in the IRF7311 package.
Because this device requires only 7 mA
at 12 V, there were no issues with
power dissipation. The MOSFET sim-
ply provides switching of the battery
voltage onto the buzzer terminals.

I used a buzzer from Radio Shack. It

provides reasonable output level, small
size, and DC voltage operation. The
latter meant that simple timed output
pulses were all that was needed to
generate the buzzer codes. The codes
were synthesized with the driver that
handled a programmed data pattern to
represent the beeps, and an interrupt
handler to manage timing of the codes.

The interrupt handler used Output

Compare 5 to time the duration of
time codes, and the warble frequency
of the annunciator (the tone that pre-
cedes the time code information).
Figure 4 shows the timing diagram of

1-Warble

2 × 250-ms Beeps

Figure 4—The initial higher frequency burst applied to
the buzzer produces a warbling effect to announce the
imminent arrival of information about potential problems.

89.00

AD422L signal powered

84.00

ADA485 (requires 9VDC) $79.00
ADA485-1 for 110VAC

89.00

ADA485L signal powered 84.00

CMC’s low cost converters adapt any

RS232 port for RS422 or RS485
operation. These converters provide your
RS232 device with all the advantages of
RS422 or RS485 including reliable high
speed operation (up to 200 kbaud) and
data transmission distances up to 5000
feet. Two AD422s can be used to extend
any RS232 link up to 5000 feet.
Completely transparent to the system;
no software changes of any type are
necessary.

RS232/RS422/RS485 Converters

• Converts an RS232 port for

use with RS422 or RS485
devices

• Supports up to 40 RS485 or

RS422 multidrop devices

• Adds multidrop capability to

RS232 devices

• Automatically determines

data direction.

RS232 TO RS485

4 wire

• Makes your RS232 port an

RS485 port

• Supports up to 40 RS485

devices

• Automatically determines

data direction.

• Signal powered version

available

RS232 TO RS485

2 wire

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

code

CC83

PO BOX 186, Brookfield,CT 06804

(203)740-9890

Connecticut microComputer, Inc.

• Converts bi-directionally

between RS232 and RS422

• Use as a short haul modem
• Plug in and go. No software

changes required

RS232 TO RS422

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

a 10-min. code. The annunciator lasts
1 s and is modulated at 100 Hz (tog-
gled every 5 ms) to produce a warbled
tone. This is followed by two 250-ms
beeps separated by 250 ms to indicate
10 min. of charge time left.

The user control momentary push

button was simple to make. I took
advantage of the HC11’s maskable bit
testing instruction to implement a
simple debounce algorithm for the
push button. The principle was to
left-shift the key state into the vari-
able

KEYSTAT every 5 ms (using the

RTC interrupt handler). Then, the
amount of debounce could be tuned
to a resolution of 5 ms by executing
the single instruction:

BRSET KEYSTAT,#MASK,FOREVER

where

MASK is the mask containing

right-justified zeroes, each representing
5 ms of debounce time. In this appli-
cation, I set a debounce time to at least
10 ms by using a mask value of $E0.
Note that this corresponds to three 5-ms
samples, which is necessary to guar-

antee at least 10 ms between samples.

Battery voltage was detected by

applying it through a voltage divider
to one of the HC11’s ADC inputs. I
used a divide-by-two network to
allow measurement of up to 10 V,
although in practice the maximum
voltage delivered by the fully charged
battery was around 8.8 V. This gave a
resolution of 39 mV/bit with an HC11
nominal supply voltage of 5 V. I was-
n’t sure if this would be sufficient to
accurately detect the discharge knee
of the battery, but subsequent tests
proved it was adequate.

It was important to take due care of

when the battery voltage was read,
because the controller would be pulse
width modulating a current of 3 A.
Note: The ADC may be sensitive to
power supply noise. The implementa-
tion read the ADC synchronously to
the PWM frequency during powerup,
that is, only after the voltage had
transitioned to the on state did the
A/D conversion start. In this way, I
was able to read the battery voltage
deterministically, and always when it

was under load.

In order to minimize interrupt han-

dler execution time, I split the ADC
driver into two routines—one to start
the conversion and one to read the
first conversion after a known elapsed
time. Although this technique relied
on knowing exact instruction timing,
it did allow the interrupt handler to
run concurrently with the ADC suc-
cessive approximation process. The
ADC on the HC11 takes 32 system
clocks to return the first result, so I
placed the read ADC routine suffi-
ciently far into the handler to ensure
the result was ready when I needed it.
The total worst-case elapsed time of
the handler was in 193 system clocks
(386 µs), which in part defined the
minimum high time of the PWM. The
other factor that contributed to the
minimum PWM high time was the
RTC interrupt handler.

The RTC monitors battery dis-

charge. I implemented it in software
using Output Compare 2 to record
elapsed minutes, seconds, and 5-ms
intervals, the latter being the resolu-

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

tion of the RTC rate. Note that no pin
action was required on OC2, and
indeed had to be avoided, because the
pin associated with OC2 was connect-
ed to the source of the power MOS-
FET switch. The pin was forced to
ground in the initialization routine.

The PWM period was also set to 5 ms.

This was considered a more than ade-
quate modulation frequency for the
halogen lamp, but to allow for experi-
mentation, I set up the key modula-
tion parameters as initialized vari-
ables. I could then adjust their values
dynamically using PCBUG11 to deter-
mine the effects on lamp and software
operation. Additionally, because the
PWM and RTC run at the same fre-
quency, by careful phase positioning
of the RTC interrupt, I could use it to
read the no-load battery voltage for
test purposes. This was accomplished
by setting the first match time in real
time to be in advance of the PWM
interrupt by 160 µs.

I chose this value as a compromise

between guaranteeing the battery was
not under load when the measurement
was made and that the RTC interrupt
handler would not significantly delay
the start of execution of the power
control PWM interrupt handler. The
RTC interrupt handler had a worst-
case execution time of 176 cycles
(352 µs), so its effect on the PWM
handler was about 192 µs (352 – 160).
Under most load values, the battery
would be in the off state during the
start of execution of the RTC handler.
Figure 5 shows the relative timing of
the two interrupt handlers.

The power supply to the HC11 is a

simple 4.7-V zener diode, a 10-µF tan-
talum decoupling capacitor, and 180-

Ω

series resistor. The same hardware

would be used to imple-
ment the battery charger.
Therefore, the maximum
applied input voltage could
exceed 15 V or so, resulting
in a maximum power dissi-
pation of around 0.6 W. The
minimum operational volt-
age is around 6 V, resulting

in a minimum supply cur-
rent of around 6 mA.

I run the HC11 at 2 MHz

to minimize power supply

current requirements. With this oper-
ating frequency, the MCU bus rate is
500 kHz.

DEBUGGING AND TESTING

I used the PC-based tool PCBUG11

to download the code to EEPROM.
One of the nice features of PCBUG11
is that it can control the execution of
the EEPROM resident code, so I could
halt and single step code when neces-
sary. Unfortunately, halting and single
stepping the code caused a complete loss
of the real-time behavior of the inter-
rupt handlers, so this technique was
only used to verify and debug some of
the non-real-time algorithms, such as
calculating the new ramp direction.

The software was designed to allow

easy modification of the critical vari-
ables, so the main debug technique I
used was to modify these parameters
on the fly while the code was execut-
ing in real time, and observe the actu-
al effects versus what I thought
should have happened. For example, I
may dynamically force the new target
value of the duration of the PWM
high time and observe the effect this
has on the ramp flag.

PCBUG11 communicated with the

HC11 through an RS-232 protocol
serial connection using a target resi-
dent monitor kernel call a Talker. The
Talker was interrupt-driven from a
non-maskable IRQ (the XIRQ on the
HC11). This permitted on-the-fly
inspection and modification of appli-
cation data parameters, even while
the application code interrupt han-
dlers were running.

The only side effect is that the

Talker overhead is high enough to
cause real-time discontinuity of the
interrupt handlers. This means that

PWM

Interrupt

Read battery

on voltage

RTC

Interrupt

Read battery

off voltage

Figure 5—The ADC reads the battery voltage at two predefined
points every PWM period. The first is under a full load at the start of
the PWM period, and the second is under a no-load condition near
the end of the period. The reads occur in separate interrupt handlers.

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

the PWM will elongate
while the Talker is active,
resulting in the lamp bright-
ness increasing for a fraction
of a second. To give some
idea of the effect, say the
Talker was dumping 16
bytes of memory at 9600
bps. The Talker would trans-
fer about 20 bytes (4 bytes
for protocol overhead) in
about 2 ms, which, during
worst-case conditions,
would be added to the high
time of the PWM. I didn’t
see this as an obstacle for
debugging the code, because the inter-
rupt handlers are robust enough to
recover from the hiatus, and continue
with correct real-time behavior after
the data dump is finished.

After the code was debugged, I

installed a special battery voltage log-
ger into the RAM, to characterize the
discharge profile of the battery under
different load conditions, sampling
the voltage every minute. Luckily, the
HC11 had sufficient RAM to hold the
application variables, plus the data
logger code, variables, and logged data.

The results were plotted in a

Microsoft Excel spreadsheet, and I
used the profile to adjust the battery
discharge monitor warning algorithm.
I also plotted an integral of the dis-
charge to show that the controller
was indeed delivering constant power
over the full profile of the battery.

Figure 6 shows the battery voltage

profile and the linear ampere-hour dis-
charge profile for a 3.7-AH, 7.2-V NiMH
battery. The load was a 6-V, nominal
12-W lamp delivering 9 W. There are
two critical characteristics in this bat-
tery profile. One is the excessively
high initial 8.8-V battery power when
fully charged, and the second is the
rapid drop-off of the voltage in the
last 10 to 15 min. By implementing a
constant power algorithm, I was able
to compensate for the initial peak and
final decay of the battery.

A point to note is that although the

PWM mechanism doesn’t completely
eliminate peak currents to the lamp,
the peaks appear to be sufficiently short
to prevent overstress to the lamp; I’ve
now used this system for two winter

seasons without any lamp failures.

During field trials (see Photos 1–3),

the battery discharge detection algo-
rithm I initially implemented did not
provide the reliability I needed. After
some analysis of the discharge data, I
developed a more robust algorithm
that is undergoing tests. The nice part
about this setup is the flexibility and
easy reprogramming. Within a matter
of minutes I may reprogram the appli-
cation and start evaluating a new
algorithm without using major exter-
nal hardware components.

A WORKING UNIT

The challenge of saving some money

by building my own controller plus the
deadline I faced helped me resurrect
some old programming skills that I had
not used in many years. The short time
period I had to complete the project
meant I stuck with familiar components
and techniques. I chose assembly lan-
guage in favor of C because a large
portion of the design was interrupt
handlers, I was familiar with the HC11
instruction set, and I didn’t want the
code overhead in an application that
required less than 2 KB of code.

The onboard EEPROM means I

could quickly and easily make modifi-
cations to the program and data con-
stants. Using a top-down approach to
the development process meant I had
few serious problems with the imple-
mentation. And finally, by partition-
ing the software carefully, I was able
to debug the real-time code without
the use of complicated development
tools. This approach also makes it
relatively easy to port the imple-

mentation to another type of
MCU, such as a Motorola
68HC05/ 8/12 family or
Microchip PIC family.

Interestingly, in this appli-

cation where delivered power
is controlled, the capacity of
the battery is best defined as
watt-hours (WH) rather than
ampere-hours (AH). So, my
battery has a nominal specified
rating of 26.64 WH (3.7 AH ×
7.2 V). The results I obtained

noted that the battery deliv-
ered 9 W for 2.17 h, giving a
measured rating of only about

19.5 WH. I suspect the battery is
indeed past its peak, because the loss-
es in the controller are insignificant
(worst case: 0.27 W × 2.17 h = 0.59
WH, ignoring switching losses). My
next step is to buy some proper
NiMH batteries and see what ride
time improvements I can get.

In the end, I had a working lamp

controller in time for the 24-h race.
My team finished in a respectable
fourth position, and the controller
operated flawlessly, which is more
than I could say for my performance

Richard Soja graduated from Aberdeen
University, Scotland, in 1974, with a
BS in Engineering Science. He is a
senior principal staff engineer at
Motorola and has more than 17 years
of experience designing, implement-
ing, managing, and supporting hard-
ware and software embedded control
applications. Fixing flat tires and
home PC network administration are
currently interfering with mountain
bike racing. You may reach him at
rsoja128@aol.com.

RESOURCE

NiMH battery information
Panasonic
www.panasonic.com/industrial/
battery/oem/chem/nicmet/

SOURCE

68HC811E2
Motorola, Inc.
(847) 576-5000
Fax: (847) 576-5372
www.motorola.com

Figure 6—

The linear slope shows that a constant power of 9 W was extracted

from the battery over the test time of 130 min. The curved discharge profile I
measured is typical for a NiMH battery. Note the precipitous decay at the end.

For complete abstracts visit

This project demonstrates how the FPSLIC can be used to provide a simple, low-cost, highly

1st Place

WINNERS

integrated solution for embedded MP3 decoding. The FPSLIC is capable of providing all the

necessary decoding elements, including storage interface, user interface, and actual MP3 decoding

on a single chip. The only external components required are a storage device and a DAC with

appropriate audio interface circuitry. The FPSLIC-based design has significant cost and power

consumption advantages over alternative designs, both of which are significant considerations in

the consumer marketplace.

The Design Logic 2001 may have been the first time

Atmel sponsored a design contest with Circuit Cellar, but

judging by the interest the contest generated and the

number of projects that were submitted, it certainly wont

be the last time! Besides generating more entries than any

other Circuit Cellar design contest, there were more

international entries to the Design Logic 2001 contest than

weve ever had before. Fifty percent of the projects were

submitted from outside the United States! We had winning

projects from Australia, Belgium, Canada, China, France,

India, Romania, South Africa, and the U.S., proving once

again that Circuit Cellar contests are a global gathering of

designers and engineers with real-world design logic.

While some people were up to the challenge of using

the FPSLIC and FPGA parts to present some intriguing

designs, the ever-popular AVR series of components stole

the show. Dozens of projects were submitted in the AVR

category including an AVR-controlled weaving loom,

several weather-monitoring devices, and even a tracking

system that was designed to aid in the study of leopard

sharks.

Not only was the quantity of AVR projects great, but

the quality of the entries was so evenly matched that the

top 30 projects were only separated by a 40-point spread

(out of 150 total possible points) after the judges results

were tabulated. Unfortunately, even with a few additional

Runners-Up prizes added to the AVR category, there still

wasnt a way to award prizes to all of the great projects

that came in. However, even though not all of the projects

are displayed in this section, all of the entrants are invited

to submit articles about their projects. Stay tuned to Circuit

Cellar in the months to come and youll find out more

about the top projects as well as a number of other great

projects that were submitted.

So, in wrapping up the Design Logic 2001 contest Id like

to say thank you to everyone who submitted a project.

Your involvement helped make this design contest a

success and ensures the future of design contests here at

Circuit Cellar.

Contest Administrator

Lionel Theunissen

Brisbane, Australia

Blueport is a card-sized module intended to be used as a smart SPI peripheral to provide

seamless communication over Bluetooth for any embedded application. The application designer

doesnt have to be concerned about all the inner workings of the Bluetooth protocol stack because

these are handled by Blueport. From the application designers point of view, communicating over

Bluetooth is reduced to writing API calls to the SPI port to open or close a communication channel

to another Bluetooth device, and to send data to or receive data from the remote device. Blueport

is applicable for any embedded application where wireless communication over Bluetooth has to

be achieved with minimum code overhead.

Blueport

FPGA

Versatile
Communications
Card for Linux

Designing a PCI interface card from scratch is not a trivial exercise. The hardware design

and PCB, logic design for the FPGA, and driver software all need to be completed before it can

even be tested with a line of application code! This communications card provides a generic

hardware platform, which takes care of the difficulty of PCI interfacing and allows the engineer to

concentrate on the FPGA logic design.

The sample application, describing an X.21 interface, with a driver for Linux, can be adapted

easily for different purposes. Even non-communications applications are possible! Possible uses

include RS-232/-485 or X.21/X.22 communications, protocol conversion, communications encryption,

replacement of obsolete ISA cards for legacy support, PCI prototyping, and FPGA experimentation.

Molnar Zoltan-Istvan

Cluj-Napoca, Romania

MPSLIC:

A Single-Chip FPSLIC MP3 Decoder and Player

2nd Place

With diagnostic equipment being so expensive, doctors in India are unable to attend to a vast

majority of rural population. Amit took this opportunity to design this low-cost yet highly competitive

diagnostic audiometer to test for hearing loss.

Hearing loss is a common problem among elderly people and it is increasingly affecting younger

people living in urban areas as the cities get crowded and people are exposed to increasing ambient

sound levels. To determine this hearing loss pattern, doctors use diagnostic equipment known as

audiometers. Doctors usually require training before they can take full advantage of the audiometers

features.

Many effective instruments have been developed over the past decade for determining hearing loss,

but the inclusion of semiconductors introduced new and more accurate devices.

Most of the audiometers offer common functions and share the same level of accuracy, the

competitive viability is based solely on cost. Thus, the AT90S8535-based audiometer provides the same

accuracy and functions as the commercially available audiometers but at a lower cost.

The AT90S8535-based audiometer offers both Speech and Tone Audiometry. It also allows printouts

of the audiogram, showing the hearing loss pattern in various frequencies.

AVR Audiometer

Amit Davjekar

Mumbai, India

Better Adders for the AT40K FPGAs

Adder speed and size are undeniably crucial factors in determining the success of a family of FPGAs.

The 16- and 32-bit adders Vitit designed are fast, small adders for the AT40K FPGA family. These adders

are simple carry-skip adders specifically designed for FPGAs, where cells and interconnects are optimized

for ripple chains. I composed ripple chains in a way that shortens the critical path delay significantly

without too much cost.

The 16-bit adder is approximately 23.5% faster than its ripple counterpart, and is 37% larger. The 32-bit

adder, on the other hand, is 34% faster than its ripple counterpart, while using only 28% more cells. On

the contrary, a 16-bit carry-select adder automatically generated by Atmels IDS is more than three times as

large as the ripple adder and sometimes operates more slowly than ripple adders in practice.

Unlike the IDSs carry-select adders, the carry-skip adders dont duplicate ripple chains for any bit

position. Instead, these new adders divide the adders bit positions into groups and determine

inexpensively whether the carry into a group will be propagated through as a carry out of that group. If

so, that group is said to be skipped. The carry out of a skipped group of bits can be determined with a

multiplexer without having to wait for the carry in to ripple slowly through the bit positions of that group.

In the 16-bit adder, the 16 bit positions are divided into three blocks of sizes 5, 6, and 5. The 32-bit

adder is divided up into blocks of sizes 10, 12, and 10. In both adders, the most and least significant

blocks are just ordinary ripple adder blocks, but the middle block is a special block with a skip

mechanism. No carry signal ripples slowly all the way through from LSB to MSB, making the worst-case

delay much better than that of the ripple adder.

A design contest is always a good opportunity to try to reinvent the wheel, but only if its a far

better wheel than the existing ones. This project, UPSC4, is not the first universal counter designed, but

implements an innovative and cost-effective design approach. UPSC4 features are head to head with

the existing high-range universal countersbut UPSC4 is built with only 10 integrated circuits! Yes,

nothing more than five small analog chips, one DAC, one ADC, one UHF prescaler, and one Atmel

device with its initialization EEPROM to support basic frequency and period measurements as

well as advanced features such as automatic slew rate calculation or gated frequency measurements,

min/max or rolling averages, with gate times as low as 250 µs and up to 11 digits resolution. Moreover

the flexible architecture of the UPSC4 counter will allow you to add new features without any

The GPS-GSM Mobile Navigator is the main part of a Port Navigation System. The Port

Navigation System includes many GPS-GSM Mobile Navigators and a Base System (the

control center). In order to monitor ships around the port, the GPS-GSM Mobile Navigator

on ships receives GPS signals and then computes the location information, which is sent to

the control center. With that information, the control center can know where each ship is.

Besides receiving and transferring the GPS information, the GPS-GSM Mobile Navigator can

also send an alarm to the control center if an emergency occurs or receive information from

the control center.

The core of the GPS-GSM Mobile Navigator is an AT90S8515. A GPS module receives GPS

signals and sends it to the MCU via an RS-232 interface. The GSM module allows the MCU to

communicate with the GSM network via RS-232 interface. Another RS-232 interface is used to

exchange data with a PC. Because there is only one RS-232 interface in the AT90S8151, a

three-channel multiplex switches the three work modes. All location information and other

data is stored to an AT45D021 (2-Mb serial data flash memory) The GPS-GSM Mobile

Navigator saves GPS signals every 20 s so the flash memory stores up to 2160 pieces of

location information in 12 h. The MCU communicates with the data flash memory via an SPI

interface.

An LCD displaying the system status connects to the MCU through seven standard I/Os.

The GPS-GSM Mobile Navigator has four buttons to control the system. Because the

AT90S8515 is a flash memory MCU, the systems remaining four SPI pins are easily updated.

An I/O pin controls a buzzer to give alarms.

Ma Chao

Shanghai, China

GPS-GSM Mobile Navigator

The Slic-Stepping Debugger system is a bench-top device that connects to an external

circuit boards microprocessor bus. It monitors, captures, and then converts a single

microprocessor bus cycle into useful engineering data. That data is then displayed to the

user via the systems integrated LCD.

The system is used in conjunction with a single-stepping software debugger on a PC,

which is connected to the processors debug port. Every time the user steps through code

with the software debugger, the Slic-Stepping Debugger captures the first bus cycle and

displays the address bus value, data bus value, whether it was a read or write cycle, and

how big the current transfer size was. This allows the engineer to monitor and verify basic

microprocessor bus cycles during development of new hardware and software designs. Of

course, there are many families of microprocessors and all have different bus protocols.

The first microprocessor protocol and bus that will be interfaced to will be the 32-bit

PowerPC 860 family.

Slic-Stepping Debugger

This entry is an implementation of an elliptic curve public-key cryptosystem on a

programmable SOC. A complete hardware implementation has limited flexibility, but is

ideally suited for the implementation of the underlying finite field arithmetic. A complete

software implementation, on the other hand, benefits the global control but suffers from

efficiency problems concerning the finite field arithmetic. A standard basis representation

is used for the field elements and projective coordinates to implement the group

operation. The results concerning area are comparable with existing hardware

implementations. Although no attempts have been made yet to reduce the critical path

delay of the hardware part, promising results towards speed and throughput have been

obtained. A maximum clock frequency of 10 MHz is realized, but 200 MHz could be

possible after optimization.

An Elliptic Curve Public-Key
Cryptosystem

Bruce Pride

Gilsum, NH USA

3rd Place

Johan Thomas &
Sven Janssens

WINNERS

FPSLIC

Merchtem, Belgium

For complete abstracts visit

The Robot Conversion Kit (RCK) is an AVR-powered electronic package that enables a user to convert a radio-controlled (RC) car into an autonomous

Robot Conversion Kit

robot. The RCK provides the fundamental set of sensors, motor drivers, and functionality needed by nearly every mobile robot.

Ethernet-Based Remote Audio Player

The project is a hardware device designed to access MPEG-encoded audio over a 10BaseT Ethernet network. The system employs a protocol designed

to allow multiple player units to connect to a single server and simultaneously and independently receive audio over the network.

Joseph Jones
Acton, MA
USA

Mike Neufeld
Kelowna, BC
Canada

Pieter
Conradie
Stellenbosch,
WP
South Africa

David Collins
Pottstown, PA
USA

VFO Frequency Counter and PLL Stabilizer

This project can be used to stabilize a free-running oscillator and provide a frequency readout in one package. The board consists of a gate/prescaler

circuit, a microcontroller, and a loop filter/VCO control circuit using a passive integrator and voltage follower.

PalmScope

The PalmScope is a hardware and software project implementing the functionality of a portable oscilloscope, a spectrum analyzer, and a logic

analyzer using a PC- or PalmOS-based PDA for display. With a maximum sample rate of 40 Msps and a bandwidth of 2 MHz, it is possible to view a

wide range of input signals with great accuracy.

Richard
Hosking
Nedlands, WA
Australia

Aaron
McFarland
Knoxville, TN
USA

FAT32 Hard-Drive-Based MP3 Player with 512 Bytes of SRAM

This project shows how an 8-bit microcontroller can be interfaced to an IDE (ATA) hard drive with the minimum of external circuitry. A FAT32 file system

with long file names and multiple directories are supported with only 512 bytes of SRAM. The user-selected files data is streamed to an MP3 decoder,

which in turn streams the raw (decoded) data to a 16-bit DAC.

Greenhouse Controller

The transmitter units gather data from temperature sensors and, based on this data, operates two vents, a heater and a fan. The unit then transmits the

temperature data and the state of the vents, heater, and fan using the license-free 433.9-MHz band. This information is also displayed on a 4 × 20 LCD in the unit.

Runners-Up

Reads up to 20 keys

(4X5 Matrix)
Programmable Rows

& Columns
Programmable Key Values
PC/AT or Serial Output
Automatic or Polled Key Reporting
Programmable Debounce & Typematic Times

64 Bytes of User Accessible EEPROM

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

Digital Distributorless Ignition System

Frantisek Bachleda

Kosice, Slovakia

Versatile AVR-Based EPROM Emulator/Programmer

Hossam Eldin AbdelBaki
Alexandria, Egypt

GameBoy Camera Interface and Object Tracking System

Daniel Herrington
Fort Collins, CO, USA

BikeLogger Data Acquistion System

Virachat Boondharigaputra
Bangkok, Thailand

The Cooking Coach PDKA (Personal Digital Kitchen Assistant)

Paras Shelawala
Cornell University, USA

TinyPlanet: Single-Bit, Wireless, Planet-Wide I/O Port

Alberto Ricci Bitti and Claudio Lanconelli
Lugo, Italy

SCUBA Diving Data Logger

David Smith
Waynesboro, VA, USA

Four-Port Terminal Server with Digital I/O

David Helland and Steve Freyder
Encinitas, CA, USA

CW Keyer with Adjustable Speed and Sidetone Pitch

John Reynolds

Beaverton, OR, USA

Wireless MP3 Remote Jukebox

Brian Millier
Hubley, NS, Canada

PC-to-Vintage Jukebox Interface

Travis Whitehead
Queensbury, NY, USA

Model Rocket Flight Data Recorder

Jamie Pollock
Fall River, KS, USA

IrDA Connection Between an AVR and a Palm Pilot

Marian Duris
Freising, Germany

Dual-Deployment Rocketry Altimeter

Scott Olsen
Salt Lake City, UT, USA

Not wanting some of the great AVR projects to go unnoticed, the Circuit Cellar staff has selected 20

of the top AVR projects that didnt win prizes to be highlighted here (listed in no particular order).

NTSC-to-PAL Closed-Caption Decoder

Ekachai Leelarassmee
Patumwan, Bangkok, Thailand

Zip Drive Digital Camera All-in-One System

Chris Bartholomew and Sean Keller
Cornell University, USA

Wireless Data Module Networking

Liu Kai
Shanghai, China

Distributed Home Audio Control System

Jeff Tyhack and Jason O’Connor
Cornell University, USA

Pinewood Derby Computer

Matt Meerian
Chanute, KS, USA

Pocket Morse Code Tutor

Ted Yapo
Arlington, MA, USA

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

PEG-4 is a new

ISO/IEC standard

that targets streaming

multimedia. It provides

tools to deliver multimedia content
over different communication channels
and targets a wide range of interactive
multimedia applications. MPEG-4 pro-
vides new features such as object-based
media representation, scalability, and
error-resilient techniques. These
enable a higher compression ratio and
higher level of interaction with the
scene contents, transmitting the same
content using different channels, and
enables robust transmission over low
bit rate noisy channels, respectively.

MPEG-4 is an ISO/IEC standard

developed by the Moving Picture
Experts Group (MPEG). [1] MPEG-4
provides the standardized technologi-
cal elements that enable integration,
distribution, and content access for
multimedia streaming. MPEG-4
describes the scene as composed of
individual objects named audio-visual
objects (AVOs). [2, 3] For example, the
visual object (VO) corresponding to
the talking person and the correspon-
ding voice are tied together to form a
new compound media object, contain-
ing both the aural and visual compo-
nents of that talking person.

FEATURE
ARTICLE

It provides a standardized way to do

many things, including: describe an
interactive scene that allows you to
place media objects anywhere in a
given coordinate system; apply trans-
forms to change the geometrical or
acoustical appearance of a media
object; modify the AVO attributes;
change viewing and listening points
anywhere in the scene, and so on.

MPEG-4 addresses the description of

the relationship between the audio-
visual objects that constitute a scene. [4]
The relationship is described at two
main levels: the binary format for scenes
(BIFS) and object descriptors (ODs).
The BIFS describes the spatiotemporal
arrangements of the objects in the
scene. You may interact and modify
the object’s attributes (i.e., rearrange
them on the scene). The ODs define
the relationship between the elemen-
tary streams pertinent to each object.

The scene description builds on sev-

eral concepts from the virtual reality
modeling language (VRML) in terms
of both its structure and the function-
ality of object composition nodes, and
extends it to allow streaming and
other features that I will discuss. The
rest of the article explains the MPEG-4
visual, profiles, and file format.

MPEG-4 VISUAL

The MPEG-4 visual standard allows

the hybrid coding of natural images
and video together with synthetic
scenes. It comprises tools and algo-
rithms supporting the coding of natu-
ral still images and video sequences as
well as tools to support the compres-
sion of synthetic 2-D and 3-D graphic
geometry parameters. These tools pro-
vide standardized core technologies
allowing efficient storage, transmis-
sion, and manipulation of textures
and images and video data for multi-
media environments.

MPEG-4 supports bit rates between

5 kbps and 10 Mbps, and uses progres-
sive as well as interlaced video trans-
mission. Content-based coding of
images and video allows separate
decoding and reconstruction of arbi-
trarily shaped video objects.

V.2 of the MPEG-4 systems extends

V.1 to cover issues like extended BIFS
functionalities and Java (MPEG-J) sup-

Wael Badawy

Streaming Multimedia

To keep pace with
ever-changing video
standards, Wael gives
us some details about
MPEG-4 and how to
get the most out of it.
He covers everything
from how the standard
was formed to the file
formats that are com-
patible. Anyone look-
ing for the latest info
won’t be disappointed.

The MPEG-4 Approach

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

example of a VO is a talking person
(without background), which then can
be composed with other AVOs to cre-
ate a scene. Conventional rectangular
imagery is handled as a special case.

Shape coding provides coding arbi-

trarily shaped video objects as shown
in Figure 1. The shape is coded using
a binary alpha plane, which defines
whether or not a pixel belongs to an
object. A gray scale plane offers the
possibility to define the exact trans-
parency of each pixel.

ERROR RESILIENCE

Error resilience is supported to

assist the access of image and video
over a wide range of storage and trans-
mission media. This includes the use-
ful operation of image and video com-
pression algorithms in error-prone
environments at low bit rates (less
than 64 Kbps). Tools are provided that
address both the limited band nature
and error resiliency aspects for access
over wireless networks.

FACE ANIMATION

The face animation part of the stan-

dard allows sending parameters that
calibrate and animate synthetic faces.
The face models themselves are not

standardized by MPEG-4,
only the parameters are.
Figure 2 shows some of the
control points for a face.
The facial animation object
can be used to render an ani-
mated face. Facial definition
parameters (FDPs) and facial
animation parameters
(FAPs) control the shape,
texture, and expressions of
the face. Initially, a face
object contains a generic
face with a neutral expres-
sion. Then, the face is ren-
dered and receives the ani-
mation parameters from the
bitstream, which will pro-
duce animation of the face
(expressions, speech, etc.).
The systems binary format
for scenes provides features
to support facial animation.

FDPs provide model data

that you may download.
You use the data to config-

images) allows a maximum of 11
levels. An AVO is coded and a subset
of the total bitstream can be used to
reconstruct and display textures,
images, and video objects at reduced
spatial resolution (see Photo 1).

The temporal scalability allows a

maximum of three levels and a subset
of the total bitstream can be used to
reconstruct and display an AVO at
reduced temporal resolution. The qual-
ity scalability depends on the number
of layers. You can use the subset of
the bitstream to reconstruct and display
an AVO at lower quality. The quality
can be measured by the signal-to-
noise ratio (SNR), as shown in Photo 2.

The view-dependent scalability

enables you to stream texture maps. It
involves taking into account the view-
ing position in the 3-D virtual world in
order to transmit only the most visible
information. Depending on VO geome-
try and viewpoint displacement, the
visual information will be sent. This
scalability can be applied both with
Wavelet- and DCT-based encoders.

SHAPE CODING

These tools allow the decoding and

representation of VOs, atomic units
of image, and video content. An

port. V.2 also specifies a file format to
store MPEG-4 content (I’ll return to
this topic later).

In order to achieve the broad goal

rather than a solution for a narrow
set of applications, functionalities
common to several applications are
clustered. Therefore, the visual part
of the MPEG-4 standard provides
solutions in the form of tools and
algorithms for efficient compression
of the following: images and video,
textures for texture mapping on 2-D
and 3-D meshes, implicit 2-D mesh-
es, and time-varying geometry
streams that animate meshes. It also
provides efficient random access to
all types of visual objects,
extended manipulation func-
tionality for images and
video sequences, content-
based coding of images and
video, content-based scalabil-
ity of textures, images and
video, spatial, temporal, and
quality scalability, and error
robustness and resilience in
error-prone environments.

SCALABILITY

Scalability allows coding

and decoding a scene at dif-
ferent levels of details and
generates valid and meaning-
ful bitstreams for an AVO. [2]
Scalability allows progressive
transmission in which an
AVO can be transmitted
using a different level of
details. MPEG-4 supports
spatial, temporal and quality
scalability. The spatial scala-
bility (for textures and still

Video object plane

Bounding box

Shape

block

(BAB)

Figure 1—The video object shape coding provides
coding for arbitrarily shaped video objects.

5.4

10.10

10.8

11.1

11.4

11.5

11.2

11.3

4.4

4.6

4.2

4.1

4.3

4.5

10.2

10.4

10.6

5.2

2.14

2.12

2.1

2.11

2.13

2.10

5.1

5.3

10.5

10.7

10.3

10.9

10.1

Figure 2—The facial animation object may be used to render an animated face
using control points. Only the face model parameters are standardized by MPEG-4.

ments of the node points
into triangular patches in
the reference frame. The
texture inside each patch
in the reference frame is
warped onto the current
frame using parametric
mapping, defined as a func-
tion of the node point
motion vectors.

For triangular meshes,

the affine mapping is a
common choice. Its linear
form implies texture map-
ping with low computa-
tional complexity. Affine
mappings can model trans-
lation, rotation, scaling,
reflection, shear, and pre-
serve straight lines. The
degrees of freedom given
by the three motion vec-

tors of the vertices of a triangle
match the six parameters of the affine
mapping. This implies that the
motion of the node points, from
which a continuous, affine motion
field defined by pieces can be recon-
structed, can compactly represent the
original 2-D motion field.

Now that I’ve covered 2-D meshes,

let’s move on to 3-D meshes. MPEG-4
V.2 provides a suite of tools for coding
3-D polygonal meshes. It compresses
the connectivity, geometry, and prop-
erties such as shading normals, col-
ors, and texture coordinates of 3-D
polygonal meshes.

Coding of generic 3-D polygonal

meshes enables the efficient encoding
of 3-D polygonal meshes. The incre-
mental representation enables the
reconstruction of a number of faces
in a mesh proportional to the num-
ber of bits in the bitstream that have
been processed. The error resilience
enables a decoder to partially recover
a mesh when subsets of the bitstream
are missing or corrupted. And, the
level of detail (LOD) scalability
enables reconstruction of a simplified
version of the original mesh using a
subset of the bitstream.

PROFILES

MPEG-4 provides a large and rich

set of tools for coding audio-visual
objects. The MPEG-4 systems, visual,

Issue 137 December 2001

www.circuitcellar.com

CIRCUIT CELLAR

ure a baseline face model
stored in the terminal into
a particular face before
FAP decoding or to install
a specific face model at the
beginning of a session
along with the information
about how to animate it.

The face animation table

(FAT) provides a functional
mapping (may be down-
loaded) from incoming
FAPs to feature control
points in the face mesh. It
provides linear mappings
by the piece of incoming
FAPs for controlling facial
movements.

The face interpolation

technique (FIT) provides a
definition (may be down-
loaded) of mapping of
incoming FAPs into a total set of FAPs
before their application to feature
points. This is accomplished by rated
rational polynomial functions invoked
by conditional evaluation of a face
interpolation graph. It can be used for
complex cross coupling of FAPs to link
their effects or to interpolate FAPs
missing in the stream using the FAPs
that are available in the terminal.

BODY ANIMATION

V.2 adds body animation to the face

animation. The body is an object
capable of producing virtual body
models and animations in the form of
a set of 3-D polygonal meshes ready
for rendering. Two sets of parameters
are defined for the body: body defini-
tion parameter (BDP) and body anima-
tion parameter (BAP). Figure 3 shows
the location of the control point to
the lower part of the body.

The body animation standard has

been developed by MPEG in concert
with the Humanoid Animation Working
Group within the VRML Consortium.
The objective is to achieve consistent
conventions and control of body mod-
els, which are being established by
humanoid animation.

2-D AND 3-D MESHES

2-D mesh includes 2-D Delaunay

or regular mesh 0. The 2-D meshes
are used for tracking synthetic

objects. [3] A 2-D mesh is a partition
of a 2-D planar region into polygonal
patches. The vertices of the polygonal
patches are referred to as the node
points of the mesh. MPEG-4 consid-
ers only triangular meshes where the
patches are triangles.

A 2-D dynamic mesh refers to 2-D

mesh geometry and motion informa-
tion of all mesh node points within a
temporal segment of interest. Triangular
meshes have long been used for effi-
cient 3-D object shape (geometry)
modeling and rendering in computer
graphics. 2-D mesh modeling may be
considered as projection of such 3-D
triangular meshes onto the image
plane. A dynamic mesh is a forward-
tracking mesh; the node points of the
initial mesh track image features are
forwarded in time by their respective
motion vectors (see Figure 4).

The initial mesh may be regular or

may be adapted to the image content,
which is called a content-based mesh.
2-D content-based mesh modeling
then corresponds to nonuniform sam-
pling of the motion field at a number
of salient feature points (node points)
along the contour and interior of a
video object. Methods for selection
and tracking of these node points are
not subject to standardization.

In 2-D mesh-based texture mapping,

triangular patches in the current
frame are deformed by the move-

pelvic_tilt

r_hip_flexion

pelvic_torsion

l_hip_flexion

r_hip_twisting

l_hip_twisting

r_knee_flexion

l_knee_flexion

r_knee_twisting

l_knee_twisting

r_ankle_flexion

r_toe_flexion

r_ankle_twisting

l_ankle_twisting

l_ankle_flexion

l_toe_flexion

pelvic_torsion

knee_twisting

Ankle

ankle_twisting

Heel

Mid-foot

Toe base

Toe end

Subtalar

Toe

Zoom on foot

hip_twisting

hip_abduct

pelvic_roll

Figure 3—You may use the body to render an animated human-like shape using the
body control points, shown here using a lower level.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

that provide rela-
tively simple con-
tent inter-activities.

The fourth is the

main visual profile,
which supports
coding of inter-
laced, semitrans-
parent, and sprite
objects. Note, inter-
active and enter-
tainment-quality
broadcast and DVD
applications are
enhanced by the
main visual profile.

The fifth profile for natural video

content, N-bit visual, supports coding
video objects having pixel depths
ranging from 4 to 12 bits to the core
visual profile. This profile is suitable
for surveillance applications.

The profiles for synthetic and syn-

thetic/natural hybrid visual content
are the simple facial animation visual
profile, scalable texture visual profile,
basic animated 2-D texture visual
profile, and hybrid visual profile.

First on the synthetic and hybrid

list, the simple facial animation visu-
al profile provides a simple animated
face model and is suitable for applica-
tions such as audio/video presenta-
tion for the hearing impaired.

and audio tool sets are used for specific
applications. These subsets are called
profiles, and limit the tools to be
implemented. For each of these pro-
files, one or more levels have been
set, restricting the computational
complexity. The approach is similar
to MPEG-2, where the most well-
known profile/level combination is
“Main Profile @ Main Level”. Profiles
exist for various types of media con-
tent (audio, visual, and graphics) and
for scene descriptions. [4]

The visual part of the standard pro-

vides profiles for the coding of natu-
ral, synthetic, as well as synthetic/
natural hybrid visual content. There
are five profiles for natural video
content. [2–7]

First, the simple visual

profile provides efficient,
error-resilient coding of rec-
tangular video objects, suit-
able for applications on
mobile networks.

Second, the simple scalable

visual profile supports coding
of temporal and spatial scala-
ble objects in addition to the
simple visual profile. This is
useful for applications that
provide services at more than
one level of quality caused by
bit rate or resource limita-
tions, such as Internet use
and software decoding.

Third in this group, the

core visual profile supports
coding of arbitrarily shaped
and temporally scalable
objects. You’ll find this pro-
file useful for applications

The scalable texture visual profile

provides spatial scalable coding of
still image and texture objects useful
for applications needing multiple
scalability levels, such as mapping
texture onto objects in games and
high-resolution digital still cameras.

The basic animated 2-D texture

visual profile provides spatial scala-
bility, SNR scalability, and mesh-
based animation for still image and
textures objects and simple face
object animation.

And, the last profile on this list is

suitable for various content-rich mul-
timedia applications. The hybrid
visual profile combines coding arbi-
trarily shaped and temporally scalable
natural video objects with coding sev-
eral synthetic and hybrid objects,
including simple face and animated
still image objects.

Also note that V.2 adds three pro-

files for natural video. The advanced
real-time simple (ARTS) profile pro-
vides advanced error resilient coding
techniques of rectangular video
objects using a back channel and
improved temporal resolution stability
with the low buffering delay. You
may use the ARTS profile for real-
time coding applications, such as the
videophone, teleconferencing, and
remote observation.

Internet, mobile, and

broadcast applications use
the next profile, core scalable
profile. This profile supports
coding of temporal and spa-
tial scalable arbitrarily
shaped objects. The main
functionality of this profile is
object-based SNR and spa-
tial/temporal scalability for
regions or objects of interest.

The advanced coding effi-

ciency (ACE) profile supports
coding efficiency for both
rectangular and arbitrarily
shaped objects. The ACE pro-
file is suitable for applica-
tions such as mobile broad-
cast reception, acquisition of
image sequences, and other
applications where high cod-
ing efficiency is requested
and a small footprint isn’t

the prime concern.

Photo 1—Here, the spatial scalability used to reconstruct and display textures,
images, and video objects is shown at reduced spatial resolution.

Photo 2—The

quality scalability depends on the number of the layers. Use a

subset of the bitstream to reconstruct and display a video object at lower

quality.

REFERENCES

[1] International Organization for

Standardization/International
Electrotechnical Commission,
“MPEG-4 requirements
document,” ISO/IE
JTC1/SC29/WG11 N2723,
Geneva, Switzerland, March
1999.

[2] ———, “Coding of Audio-Visual

Objects: Systems,” 14496-1, I
SO/IEC JTC1/SC29/WG11
N2501, November 1998.

[3] ———, “Coding of Audio-Visual

Objects: Visual,” 14496-2,
ISO/IEC JTC1/SC29/WG11
N2502, November 1998.

[4]———, “Coding of Audio-Visual

Objects: Delivery Multimedia
Integration Framework,” 14496-
6, ISO/IEC JTC1/SC29/WG11
N2506, November 1998.

[5] ———, “Generic Coding of

Moving Pictures and Associated
Audio: Systems,” 13818-1, 1994.

[6]———, “Coding of Audio-Visual

Objects: Audio,” 14496-3,
ISO/IEC JTC1/SC29/WG11
N2503, October 1998.

[7]———, “The Virtual Reality

Modeling Language,” ISO/IEC
14772-1, 1997.

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

V.2 profiles for synthetic and syn-

thetic/natural hybrid visual content
comprise the final three profiles.

The first of this list, the advanced

scalable texture profile, supports
decoding of arbitrarily shaped texture
and still images including scalable
shape coding, wavelet tiling, and error
resilience. This works well for fast
random access as well as multiple
scalability levels and arbitrary shaped
coding of still objects (e.g., fast con-
tent-based still image browsing on the
Internet, multimedia-enabled PDAs,
and Internet-ready, high-resolution
digital still cameras).

Second, the advanced core profile

provides the ability to decode arbi-
trarily shaped video objects and arbi-
trarily shaped scalable still image
objects. You may use it for various
content-rich multimedia applica-
tions, like interactive multimedia
streaming over Internet.

The third and final profile on the

list is the simple face and body ani-
mation profile. This profile is a set of
the simple face animation profile
adding, obviously, body animation.

MPEG-4 FILE FORMAT

The MP4 file format is designed to

contain the media information of an
MPEG-4 presentation in a flexible,
extensible format, which facilitates
interchange, management, editing,
and presentation of the media. The
design is based on the QuickTime for-
mat from Apple.

The MP4 file format is composed of

object-oriented structures that are
called atoms. A unique tag and length
identify each atom. Most atoms
describe a hierarchy of metadata giv-

ing information such as index
points, durations, and pointers
to the media data. This collec-
tion of atoms is contained in an
atom called the movie atom.
The media data is located else-
where; it may be in the MP4
file or located outside the MP4
file and referenced via URLs.

ROLL THE CREDITS

This article presents an

overview for the multimedia
streaming using the MPEG-4

approach. MPEG-4 video offers tech-
nology that covers a large range of
existing applications as well as new
ones. The low bit rate and error-
resilient coding allow for robust
communication over limited rate
wireless channels, mobile video-
phones, and space communication.
There also may be roles in surveil-
lance data compression considering
that it’s possible to have a low or
variable frame rate.

At high bit rates, MPEG-4 tools are

available to allow transmission and
storage of high-quality video suitable
for the studio and other demanding
content creation applications. It’s
likely that the standard will eventual-
ly support data rates well beyond
those of MPEG-2.

One major application area is inter-

active web-based video. Software that
provides live MPEG-4 video on a web
page has already been demonstrated.
There is room for applications to
make use of the object-based charac-
teristics of MPEG-4. When choosing
applications, also keep in mind the
flexibility of video coding, which
offers numerous possibilities.

Editor’s Note: The following is a
partial list of references. You may
download the complete list from
Circuit Cellar’s web site.

Figure 4—The node points of the initial mesh track image fea-
tures are forwarded in time by their respective motion vectors.

RESOURCE

Moving Picture Experts Group
www.mpeg.org

Author’s Note: I would like to
thank the Natural Sciences and
Engineering Research Council of
Canada, the Canadian Foundation
for Innovations, URGC, Micronet,
Alberta Innovation and Science,
and Research Excellence Envelope
for supporting this research.

Dr. Wael Badawy is a professor in
the Department of Electrical and
Computer Engineering at University
of Calgary, Canada. Some of his

interests include video coding for
low bit rate applications, digital
video processing, video library,
water-marking, and spatial data-
base. Wael was honored with the
2001 Micralyne Microsystems
Design Award and 1998 Upsilon Pi
Epsilon Honor Society and IEEE
Computer Society Award for
Academic Excellence in Computer
Disciplines. You may reach him at
badawy@enel.ucalgary.ca.

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

ou know the

old saying, “if it

looks like a duck,

walks like a duck, and

quacks like a duck, it must be a
duck?” For hunting retrievers it only
needs to sound like a duck, and they
believe there is a duck out there. OK,
so I don’t really know what dogs
think, but my Quacker gets their
attention so they look at the mark
and see it to the ground. (I’m using
some dog training jargon here, so you
may want to refer to my article
“Pigeons, Pooches, and PICS,”
(Circuit Cellar 134)).

Recently I was training with two

friends and we were trying to set up a
triple mark. Because one of the three-
some needs to handle a dog, it isn’t
practical for that person to also throw
a mark. Therefore, we were using a
launcher (similar to the one shown in
Photo 3 of “Pigeons, Pooches, and
PICs”) to throw the third mark.
However, unlike my former project,
this unit had no ability to make sound.

After tripping the launcher twice

and walking out to reload and cock it
twice because my dog turned his head
the wrong way just prior to the
launch twice and never saw anything,
I gave up. This convinced me of the

FEATURE
ARTICLE

value of the Quacker, which was
being tested by a well-respected dog
trainer at the time.

THE FIRST ATTEMPT

Only a few of my projects get to the

prototype stage without serious redesign,
and this one was no exception. Either
the first attempt just doesn’t work or
by the time I get it working I discover
a far better way to do it.

My first attempt for this project

was to make an HC11 play wave
files. This was attractive at first
because I knew there were a large
number of bird sounds available on
the Internet as wave files. In addition,
a colleague had already done some of
the groundwork associated with the
wave file structure and played them
with a microcontroller.

However, getting the wave file data

available for the HC11 turned out to
be more troublesome than I expected.
There had to be a way to convert the
data into a form that could be used by
the HC11 because the wave file is a
file on the PC, and the HC11 wasn’t
intended to read files from a hard
drive. Another colleague helped out
here by creating UNIX code that
would read the wave file binary data
and convert it to ASCII so it could be
inserted as a table of data in HC11 code.

Because the HC11 board already has

a DAC on it, it didn’t take long to
connect an amplifier to the DAC out-
put. Then, I was ready to make some
noise from wave files. Unfortunately,
the first sound was disappointing. A
pitiful hardly recognizable squawk is
all you get from 16 KB worth of data?
Had I done some calculations ahead of

Gordon Dick

Does Your PIC Quack?

There’s always room
for improvement. After
Gordon wrote about
his Quacker a few
months ago, he contin-
ued revamping it. This
month, he shares his
newest modification,
adding sound to the
dog-training device.
He’s working with PICs
again and adds ISD
chips to the parts list.

Adding Sound to a Training Device

Photo 1—This is the sound chip programmer. An elec-
tret mic is visible below the speaker. So far, program-
ming has been done from the PC speaker, but there is
provision for feeding an audio signal in directly.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

idea to look at them more carefully.

The bandwidth of the low-end

record/playback chips is similar to a
phone line. That’s pretty low, but
maybe I could get by with that. And
even the smallest of the chips in
terms of storage time was almost big
enough for this project. These chips
can also stand alone, which means I
could evaluate one quickly without
creating any micro code. So, I ordered
some ISD1110s to evaluate.

Next, I visited the ISD web site and

downloaded the datasheets. [1, 2] Use-
ful app notes are on the site too. By the
time the parts arrived, I felt I knew how
to use the device and construct the
record/playback circuit from the app
notes (see Photo 1 and Figure 1).

After recording and playing back

various voice tests to verify the record/
playback circuit was working, I was
ready to record a duck call. After
plugging “duck calls” into a search
engine on the ’Net, I realized there are
a large number of folks in the U.S. who
build and sell duck calls. After playing
a few on my PC, I selected one and
recorded it onto the ISD1110. I was
surprised and pleased with the play-

time, the outcome wouldn’t have
been a surprise. Anyway, it was now
evident that too much EPROM was
going to be required to get the several
seconds of sound I wanted. So, it was
time to look for another way.

Figure 1—Programming of the sound chips is done with this board. Press the Record button, play the sound into
the electret mic, and press Play to hear what you’ve just recorded. It’s almost that simple.

PLAYBACK CHIPS

On numerous occasions I had seen

the voice record/playback chips from
ISD in Digi-Key’s catalog, but had
always dismissed them without seri-
ous consideration. Now it was a good

Figure 2—

The ISD1110 allows the first Quacker to be simple. Battery operation requires a charger, which is shown at the top. Below that, U3 makes the sound and U4 ampli-

fies it. ISO1 allows the Quacker to be driven from a range of voltages with either polarity.

ment than was possible on a wire
wrap board. The datasheet calls for
the external impedance from each
input to ground be 50 k

Ω

or less to

prevent oscillations. I had to reduce it
to 10 k

Ω

to completely stop the oscil-

lations and have a well-behaved
amplifier on the prototype.

I wanted to use the mute function

because it would reduce power con-
sumption, but the amplifier takes 2 or
3 s to make noise again, which is not
acceptable for this application. But
because the LM4755 is a stereo amp,
configuring it to accept differential
inputs and drive the speaker differen-
tially was easy. (Some manufacturers
refer to this as a bridge-tied load, or
btl.) This is a common trick in bat-
tery-powered equipment and theoreti-
cally increases the power delivered to
the load by a factor of four over what
could be delivered to a single-ended
load with the same supply voltage.
This makes it practical to use an 8-

Ω

speaker, which is more common than
4-

Ω

and still have high output power

(see Photos 2 and 3 and Figure 2).

Issue 137 December 2001

www.circuitcellar.com

CIRCUIT CELLAR

back quality. This chip was just what
my project needed! I couldn’t wait to
play this with some amplification.

That same evening, I pressed a

small servo amplifier into audio serv-
ice. The higher volume playback still
sounded fine, but now there is a nasty
pop at the start and end of playback.
This won’t do!

The noise didn’t show up on the

record/playback circuit because the
speaker was driven differentially.
Using the single-ended audio signal
from the ISD1110 (the way it was for
this test) allows the pop to feed
through. Later, I found a warning in
the application notes about this com-
plication; the application circuits
always use an amplifier with a differ-
ential input to produce more power.

Thus, I could play decent quacks

but needed an amplifier/speaker that
would function from batteries out-
doors. Maybe I could just…

MODIFY A MEGAPHONE?

This seemed like a clever idea until

I looked at the price. The least expen-

sive one I could find was still in the
$70 (US $) range. This is far too
expensive as the starting point.

At that moment, I began searching

for an audio power amplifier IC in the
10-W range with low quiescent cur-
rent, differential drive capability, good
availability, and low price. My search
stopped with the National LM4755; it
even has a mute function that may
further lower the quiescent current. [3]

I also required an outdoor horn

speaker. The least expensive one I
found is white, which isn’t the best
color for dog training because dogs see
white well. White will do for the pro-
totype but won’t be acceptable for
production versions.

A PICLESS QUACKER

After I bought the LM4755, I wire-

wrapped the prototype. The power
amplifier wanted to be a power oscil-
lator, but that wasn’t surprising
because I didn’t construct the proto-
type as the datasheet recommended.
National suggests heavy tracks for
power and a more compact arrange-

Figure 3—The PIC-based Quacker is shown
here minus the battery charger circuitry.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

tant considering someone
blowing a duck call often can’t
make enough noise (if its
windy, for example) to get the
dog’s attention. And field trial
workers do marking at dis-
tances up to 300 yd, so the dis-
tance alone attenuates sound
significantly.

During the course of the

next few weeks, the Quacker
made many friends, I was told
by my field tester. This was
good news! Well, there were a
few folks who complained
about the white horn. Hunt
test folks don’t like to give the
dog anything white to focus on
because this wouldn’t happen
in a real hunting situation.
Field trial folks play a different
game and never complained
about the white speaker. But,

as I said, I planned to get dif-
ferent color speakers after the
prototype was tested.

When I asked the field tester

if more than one sound would

be a desirable feature, she responded
emphatically, “Yes!” That’s when I
began working on Quacker 2.

A QUACKER WITH A PIC

To play three sounds with a 3- to

5-s duration, you need a different
model ISD chip. I chose the ISD1416,
which is similar to the ISD1110 but
has 16 s of recording time. Further-
more, in order to play three sounds, I
had to manipulate the address lines of
the ISD1416. I know every problem
doesn’t have to be solved with a
microcontroller, but this seemed like
a natural for a PIC. Because I wanted
to get rid of that volume control pot
and trade it for a digital version, the
decision was easy. In addition, I was
now familiar with the PIC16F84
from a previous project. For more
information about the PIC, read
Microchip’s datasheets. [4, 5]

The user interface needed to be

more than an on/off switch and a vol-
ume knob. My field tester cautioned
me repeatedly that the user interface
for dog folks had to be simple and
intuitive. She said, “They don’t want
to be trying to program a VCR while

As soon as I was sure the Quacker

was working reliably, I shipped it to
California for field testing. My field
tester is so pleased with it! She said
she’s never had anything sound so
realistic or loud. Loudness is impor-

Photo 2—

For the first Quacker, there’s simply a power switch,

indicator, volume pot, and cable to connect to a trigger source.
The C-clamp under the horn allows it to fasten to a stake (when
used with a bird box) or to some part of the frame of a large cata-
pult type of launcher (called a winger).

Photo 3—

The two 12-V, sealed lead acid batteries

(not shown) in the first Quacker easily provide in
excess of 100 quacks before recharging is required.

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

dog training!” I believe this user
interface will meet with her approval,
however, she hasn’t evaluated one yet.

Keeping the number of volume lev-

els to three allows three LEDs to show
the current volume or sound depend-
ing on whether sound or volume is
being changed. Two push buttons will
be used, one to change volume and
one to change sound. To change vol-
ume for example, you hold down the
volume button for 4 s. This will
cause one of the three LEDs to light
showing the current volume level.

Short button presses now will

advance through the three volume
levels in ring counter fashion. When
the desired volume setting is displayed,
another 4-s button press will store the
new volume setting for use. The process
is similar for changing the sound to be
played. In normal use, the three LEDs
function as a power on indicator by
blinking sequentially. A schematic of
the Quacker 2 is shown in Figure 3.

Although there are eight address lines

on the ISD chips to access the sound
memory, they don’t have to be driven

individually if the space is divided only
into three blocks as in this case. There’s
an app note that gives all the details. [6]
It’s a good thing that eight address
lines aren’t required, because I/O pins
are being used up quickly. Let’s see,
that was five for the user interface and
three for sound memory, out of 13.

A digital pot from Microchip has

the same value as the rotational one
used in Quacker 1. This device inter-
faces with a micro via an SPI type
serial link, and requires another three
I/O lines. That leaves two unused I/O
pins, maybe I’ll find a job for them later.

The schematic for Quacker 2 is

nearly as simple as for Quacker 1.
However, now there is some code to
create before things will work. None
of the code for this project gave me
any serious grief, but my burn-and-
learn development system is slow.

As various parts were completed

and tested, the size of the hex file
grew and I started to get concerned
about running out of memory. In the
end, only about a quarter of the avail-
able 1 KB was used. But that was good,

because there may need to be some
additions, which I’ll discuss next.
(The code for this project is available
on the Circuit Cellar web site.)
Photo 4 shows the double-sided PCB
version of a completed Quacker 2.

MORE FEATURES?

There are always ways to improve.

At the moment, volume and sound
selections are established out of reset.
However it would be nicer to have the
last settings used stored in EEPROM
and used during the next powerup. I
plan to do this for the next revision.

Presently, there is no way to acti-

vate the Quacker except to drive it as
usual by plugging it into an Rx unit
output and pressing the corresponding
Tx button. It may be useful to be able
to activate the Quacker from the front
panel of the unit as well. Rather than
adding another button, pressing both
buttons at once should work. More
code modifications for the next revision.

Currently, I record the sound onto

the ISD chips using a PC. The process
is cumbersome and would produce

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

Edmonton, Canada. He consults in
the area of intelligent motion control
and is usually working on some elec-
tronic project. You may reach him at
gordond@nait.ab.ca.

better quality sounds if the signal
were to be fed in directly rather than
from a speaker through a microphone.
There must be a way to program the
ISD chips similar to the way an
EPROM is programmed. Will this get
done for the next revision? Maybe.

My field tester tells me there can

never be too much volume. However,
adding more volume would drive up
the cost of this product considerably.
Potentially the operating voltage
would have to rise (another battery)
and the power stage would have to be
stronger (a new power amp). No,
those things won’t happen.

What about letting the customer

record his own sound? Maybe he
wants the Quacker to produce quacks
like his local ducks, not like the one I
happened to select. An electret micro-
phone would have to be added and
possibly a record button. Of course,
the code also would have to be modi-
fied. Interesting thought; I’ll have to
check with my field tester.

SOURCES

ISD1110/1416 Playback chips
Information Storage Devices (now
called Winbond Electronics Corp.)
(800) 677-0769
+886-3-5770066
Fax: +886-3-5792668
www.winbond-usa.com

LM4755 Amplifier IC
National Semiconductor Corp.
(408) 721-5000
www.national.com

PIC16F84 Microcontroller,
MCP41050 Digital Pot
Microchip Technology Inc.
(480) 786-7200
Fax: (480) 899-9210
www.microchip.com

REFERENCES

[1] Information Storage Devices,

“ISD1100 Series Single-Chip
Voice Record/Playback Device:
10- and 12-Second Durations.”

[2] ———, “ISD1400 Series Single-

Chip Voice Record/Playback
Devices: 16- and 20-Second
Durations,” April 1998.

[3] National Semiconductor Corp.,

“LM4755 Stereo 11W Audio
Power Amplifier with Mute,”
DS100059, August 15, 2000.

[4] Microchip Technology Inc.,

“MCP41xxx/42xxx: Single/Dual
Digital Potentiometer with SPI
Interface,” DS11195A.

[5] ———, “PIC16F84: 18-Pin

Flash/EEPROM 8-Bit
Microcontrollers,” DS30430C.

[6] Winbond Electronics Corp.,

“Stand-Alone/Parallel Interface
Products—Basic Addressing,”
http://www.winbond-usa.com/
products/isd_products/
chipcorder/applicationinfo/
apin07.pdf

SOFTWARE

A monthly magazine for the
electronics enthusiast, amateur
or professional.

Four fully

described and illustrated
projects in each issue, includ-
ing full p.c.b. layout and wiring
diagrams.

Plus

* Ingenuity Unlimited – read-

ers’ circuit ideas

*New Technology Update –

keeping you informed of
advances in technology

* Circuit Surgery – readers’

circuit problems answered.

* REGULAR SERIES AND
FEATURES describing how
electronics monitors and
controls the world around us.

FREE SAMPLE ISSUE

Download a sample issue free
of charge from our Online web
site or buy a one year Online
subscription for just

$9.99 (12

issues).

www.epemag.com

You can also order printed
issue subscriptions or buy a
wide range of electronics
books and CD-ROMs.

If your interest is electronics
check out

Gordon Dick (Professional Engineer)
is an instructor of Computer
Engineering Technology at Northern
Alberta Institute of Technology in

Photo 4a—

This is the component side of Quacker 2.

Only the PIC and ISD chip are socketed.

b—

Connectors,

switches, push buttons, and LEDs are mounted on the
foil side to reduce the wiring required for packaging.

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

utdoor sculpture

undergoes style

trends much like

everything else. For a

while, hunks of blowtorch art welded
from steel plate decorated municipal
lawns wherever I went. I always
thought it was a shame they didn’t
use all that steel and acetylene to
build something useful.

When I helped provide amateur

radio support for a fund-
raising bicycle tour in
North Carolina, part of
the route passed the (now
decommissioned) Voice of
America transmitter site
near Greenville. Finally
I’d found metal sculpture
that made sense: acres of
latticed steel pylons and
cable catenaries!

Antennas, whether you

regard them as sculpture
or eyesore, form a funda-
mental part of RF circuitry;
without an antenna you
don’t have a radio. You
won’t need a blowtorch
for the antenna sculptures
discussed in this article,
but a big, fat, 250-W sol-
dering gun will help.

Recently, I received an evaluation

kit from Lemos International with a
pair of Radiometrix BIM-2 UHF data
radios exercised by PIC microcon-
trollers. I immediately wondered how
the radios work in real life, as
opposed to datasheet space, and how
different antennas might change
their useful range. After all, Radio-
metrix has solved the problem of
transmuting bits into RF and return-
ing them unchanged, so we can do
some fun stuff here.

ANTENNA INTRO

Embedded radios such as the BIM-2

generally live inside devices that don’t
look like radios, have no room for
external antennas, and get used with
little consideration for RF. The simple
antennas I present here are better
than average because they’re visible,
out in the open, and awkward.

At first glance, an antenna violates

the common rule that you need two
conductors to make a circuit; juice
goes into the single conductor of an
antenna and vanishes. In reality, an
antenna converts between electrical
energy in a circuit and electromagnet-
ic energy in free space using rules that
don’t apply to low-frequency circuits.

The shape, size, and configuration

of an antenna’s conductors determine
how it reacts to energy of various fre-
quencies. Designing an antenna from

Although antennas
don’t qualify as art-
work, they are an
essential part of any
communication equa-
tion, especially radio
communications. This
month, Ed gives us a
backgrounder on the
ins and outs of anten-
na basics, as well as
covering a variety of
styles used today.

Ed Nisley

UHF Wire Sculpture

ABOVE THE
GROUND
PLANE

Photo 1—

The Radiometrix evaluation boards, with black and gold BIM-2

UHF data radios, wear a 433-MHz rubber duck antenna and a 50-

Ω

ter-

minator, respectively. The copper ground plane supports a second
(slightly bent) duck, with a 900-MHz stubby duck lying in the foreground.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

scratch requires deeper knowledge
than most engineers will ever have, so
we generally content ourselves with
applying and modifying existing
designs. Entire books have been writ-
ten about antenna design, so I have
room to present only the highlights.
Check the references for more details
and the theoretical background
behind what you see here.

All of the antennas I used descend

from the vertically polarized, quarter-
wave branch of the family tree.
“Quarter-wave” means their radiating
section measures roughly one quarter
of their operating wavelength, denot-
ed by the Greek lambda:

λ/4

. Note

that BIM-2 radios use 433.92 MHz
(

= 691 mm and

λ/4

= 173 mm).

Various geometric and parasitic
effects affect the actual length of the
wires, so you cut long and trim for
the best results.

“Vertically polarized” means the

antenna’s electric field is aligned ver-
tically. Although other applications
take advantage of other polarizations,
portable communications equipment
typically uses vertical polarization.

By virtue of their size,

λ/4

antennas

are resonant at their operating fre-
quency, which means, among other
things, that they present a nearly
pure resistance at their feedpoint.
The ideal feedpoint resistance match-
es the feedline, which is typically a
50-

Ω

coaxial cable.

If the antenna does not present an

exact impedance match to the cable,
it reflects RF energy back from its
feedpoint and sets up standing volt-
age waves along the cable. The volt-
age standing wave ratio (VSWR or,
more commonly, just SWR) meas-
ures this mismatch, with 1:1 being
perfect and unattainable and 2:1 being
usable. An SWR exceeding 3:1 means
you have more trimming and adjust-
ing to do or, alas, you’re one snip
over the line.

Because antennas and feedlines can

present reactive as well as resistive
impedances, you wind up using com-
plex numbers for the first time since
college. You also need instrumenta-
tion that can perform meaningful
measurements at UHF frequencies. I
decided to use an Autek Research
RF-5 VHF Analyst to measure the
feedpoint impedance and SWR while
trimming the antennas.

The Radiometrix eval boards

include six status LEDs to indicate
what’s going on, two of which are
useful for antenna work. The PIC
turns on the Signal LED when it
detects the preamble sequence at the
start of a received data packet and
lights OK if the entire packet has no
errors. Because BIM-2 radios don’t
produce an analog received signal

strength indicator (RSSI) output,
there’s no direct way to measure the
actual RF signal power.

However, even binary outputs mark

the edge of the coverage area, which
is pretty much all you need for a
quick evaluation. In my tests, OK
went off a few feet before Signal
dropped out, so range mapping
involved nothing more than a tape
measure, clipboard, and some hiking.

RUBBER DUCKIES

Hand-held portable radios generally

come with an antenna called a rubber
duck. A flexible steel spring covered
with rubber or plastic tubing forms
the radiating element, with a BNC or

SMA radio connector on the bottom.
Because they’re flexible, it’s difficult
to break the antenna or impale your-
self on it. Ducks are popular, which is
unfortunate because, in general,
they’re lousy antennas.

“Nisley’s Duckie Design Criterion”

explains why: Any antenna included
with a hand-held radio must be no
more than 1

″

taller than the radio. As

proof, note that if the antenna were
any taller, it wouldn’t fit in the box
beside the radio, which is packed in a
Styrofoam cradle with 0.5

″

of padding

on each end.

The BIM-2 evaluation kit includes

a pair of rubber duck antennas tuned
for 433 MHz. Photo 1 shows the
radios and antennas, which formed
the starting point for my investiga-
tions. I used the parking lot of a
nearby high school for my antenna
test range one summer morning. With
a rubber duck on each evaluation
board, I set one vertically atop a

Photo 2—

A UHF

λ/4

ground plane antenna is made

of no. 10 AWG copper wire. Two ferrite beads decou-
ple the coax feedline from the antenna. Five colorful
plastic beads help prevent eye injuries.

Photo 3—

A BNC panel connector through the copper

ground plane supports the center driven element of a
Yagi-Uda antenna. The brass tubes fine-tune the ele-
ment lengths. Yes, the copper plane is slightly warped.

Photo 4—

A directional discontinuity ring radiator

antenna is a

/4 length of wire bent in a loop parallel to

a copper ground plane.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

wooden stool in the middle of the lot
and walked away, watching the OK
and Signal LEDs on the hand-held
board. At 100 paces, about 300

′

, I’d

run out of parking lot space without
running out of signal.

Actually that wasn’t too surprising,

as UHF propagates nicely along line-
of-sight paths. I replaced the antenna
with a 50-

Ω

terminator and walked

back toward the stool. The LEDs
begin blinking merrily at about 60

′

which set the reference distance for
all of my other measurements.

Using a terminator as an antenna is

a great way to get high attenuation,
because the radio sees only the leak-
age from the radio’s antenna wiring.
Confining my measurements to
walking distance made things easy,
but you’ll get much greater range
with a real antenna.

The other antennas require a coaxi-

al cable between the evaluation board
and antenna base. In the RF domain,
cables must be an integral number of
half-wavelengths long to transfer the
antenna impedance unchanged to the
radio. We’ll discuss this in greater
detail later on, so just take it as a
given for now.

I set up several RG-58A cables for

use at 433.92 MHz and measured
their loss at about 3 dB. Obviously,
RG-58A is not the best cable for
UHF use, because half of the trans-
mitter’s power and half of the
received signal vanishes along the
wire. This doesn’t matter for our pur-
poses, because all of the antennas
were measured with approximately
the same losses. I mounted the duck
at the end of a cable, which dropped
the range to 24

′

Ducks require a decent ground

beneath them, which can be provided
either by the radio itself or a formal
ground plane, but a simple coaxial
cable doesn’t work well. Adding the
ground plane you see in Photo 1
pushed the signal out to 56

′

. Note

that the same antenna reaches the
same distance using half the power
simply by putting a better ground
plane underneath. The surface
beneath the antenna forms a key part
of the system; the better the ground,
the better the antenna.

Just to show that antennas should

be matched to the transmitter, the
900-MHz stubby duck illustrated in
the middle of Photo 1 reached only
22

′

from the middle of that ground

plane. That’s equal to the bare 433-
MHz duck on a cable, but demon-
strates that anything will radiate at
least a little bit.

WIRE GROUND PLANE

Photo 2 shows what’s called a quar-

ter-wave ground plane antenna, even
though you don’t see a solid copper
sheet. Each of the five copper wires
measures

λ/4

, with the vertical radiat-

ing element insulated from the four
lower wires. Note that, no matter
how you put it down, one spine always
sticks up. Long ago, iron caltrops
shaped like this crippled knights’ hors-
es on battlefields. When you build one,
you must put fat beads on the wire
ends to reduce the risk of eye injury.

The four lower wires are connected

to the coax shield and define a
ground plane for the antenna (think
of them as a skeletonized copper
sheet). The feedpoint impedance of
the vertical

λ/4

wire varies with the

angle below the horizontal of the
ground plane wires, such that a 45°
angle produces a 50-

Ω

impedance and

a nearly perfect SWR.

Ungainly as it may appear, this

antenna reaches out 75

′

. Again,

remember that the other radio had a
terminator for an antenna.

YAGI-UDA

All of the antennas so far have a

single radiating element and uniform
azimuthal response: an equal range in
all directions around the parking lot.
Although ideal for a portable radio,
sometimes you need more range in
one direction than another.

Professor Hidetsugu Yagi and his

student Shintaro Uda published a paper
in 1926 describing a new type of anten-
na that achieved directional radiation
using parasitic elements arranged near
a single radiating element. Typically,
Yagi antennas use a central boom
with the elements extending equally
on both sides. The signal polarization
follows the elements: vertical wires
produce vertical polarization.

Photo 3 shows a Yagi-Uda variant

with vertical elements above a copper
sheet; it’s effectively half a Yagi
antenna emerging from the ground
plane. The central element is a
(roughly)

λ/4

antenna, with the other

two acting to accentuate the response
toward the left.

A fellow ham operator (Jason,

WA2LJW) designed this antenna based
on my hand-waving description. He
used EZNEC, an antenna simulation
program found on the Internet, to
model various configurations. After
some twiddling, Jason picked one
with an SWR of about 2, 3 dBi gain to
the front and –8 dBi to the rear.

I built the unit on a big sheet of

double-sided circuit board with a grid
of plated-through holes and a bulk-
head BNC connector supporting the
center element. The short brass
tubes on the ends of the elements
allowed for some adjustment, howev-
er, I did not go through a careful
optimization process.

My field test produced ranges of

′

in the front and 16

′

in the rear.

When used as a receiving antenna, it
can suppress unwanted signals com-
ing from the back of the antenna
while still being as sensitive as the
rubber duck toward the front. Because
you must increase power by approxi-
mately 6 dB to double the range, the
numbers agree to within the resolu-
tion of my technique: a factor of
four range change for 11 dB of power
difference. It’s worth noting, how-
ever, that my measurements are not
good to much more than one signifi-
cant figure, so you cannot reach
solid conclusions.

DDRR

Although ground plane antennas

work well for mobile applications,
the radically different antenna shown
in Photo 4 has some significant
advantages. It’s omnidirectional, eye-
safe, vertically polarized, and (at UHF
frequencies) inconspicuous. However,
on the downside, it sports a jawbreak-
er of a name: directional discontinu-
ity ring radiator.

Different sources give different

explanations of its operation. It’s a
magnetic antenna, a transmission-line

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

I’m not a lawyer, I can pick out some
relevant sections with the help of
ARRL analysis. [3] You should not,
however, construe what follows as
binding legal counsel.

First, the good news for home con-

structors. Part 15.23(a) notes that
“equipment authorization is not
required for devices that are not mar-
keted, are not constructed from a kit,
and are built in quantities of five or
less for personal use.” [2] The devices
you build in your own shop must,
however, conform to the various
requirements in the subsequent hun-
dred-odd pages.

Now the bad news. Part 15.209

specifies a maximum field strength of
200 mV/m measured at 3 m for inten-
tional radiators in the UHF band.
Intentional radiators means anything
that deliberately emits RF, which
means anything you think of as a
radio for data or voice transmission.

Part 15.231 allows higher power for

intermittent, intentional radiators
that do not transmit voice or data
(examples include remote controls,
security sensors, and garage door
openers). The radio must transmit for
no more than 1 s, pause at least 10 s
between transmissions, and have a
duty cycle under 1/30.

Field strength depends on the trans-

mitter power, antenna gain, and dis-
tance from the transmitter. In free
space, transmitted power spreads out
from an isotropic antenna in a spheri-
cal wave front with a surface area
equal to 4

. Multiplying the trans-

mitter power by the antenna gain, G,
(as a numeric factor, not dB) and
dividing by the sphere’s surface area
at a given distance, r, produces the
power density in watts per square
meter at the receiver:

Converting from power density to

electric field strength involves Z

, the

characteristic impedance of free
space, the derivation of which is well
beyond the scope of this column. It’s
sufficient to say that Z

= 377

Ω

and

that the power density at the receiv-
er is related to the field strength by

antenna, a teeny vertical antenna
with a massive capacitance hat, or a
bent-wire dummy load. A QST article
by Robert Dome provides many of the
equations you’ll need to design and
evaluate a DDRR. [1] I boiled these
down into a Mathcad worksheet
which I’ll summarize here.

The DDRR consists of a roughly

/4 length of wire bent into a loop

parallel to a horizontal, metallic
ground plane. Its efficiency increases
as the vertical section becomes longer
and the loop shorter, up to the point
where it turns into a standard

λ/4

antenna. I used a 19-mm vertical sec-
tion to get decent efficiency, trimmed
the loop to 433.92 MHz, and found
the 50-

Ω

feedpoint on the vertical sec-

tion. I measured a 1.3 SWR, which is
the lower limit for my Autek analyz-
er, through a

λ/2

trimmed length of

RG-58A feedline with a 3-dB loss.

Surprisingly, it was the second-best

performer on the range, reaching 60

′

in a roughly circular pattern. Not bad
for an antenna you can barely see! A
Radiometrix app note describes how
to build a loop antenna with printed-
circuit board traces. I haven’t evaluat-
ed those designs, but they probably
don’t work as well as a moderately
elevated DDRR.

THE LAW ON POWER

Now, having measured some RF, we

must talk about the law. In general,
you may not simply turn on a trans-
mitter and begin sending voice or data
through the air, not even as part of a
test, not even for one single bit. The
Federal Communications
Commission controls the who, what,
where, when, how, and why of the
electromagnetic spectrum between
9 kHz and 300 GHz for nongovern-
mental users in the U.S. The FCC’s
word is, simply, the law of the land.

You’ll find the rules governing low-

power, unlicensed, civilian transmit-
ter operation in 47 CFR 15: Part 15 of
Title 47 of the Code of Federal
Regulations. [2] The American Radio
Relay League also presents the infor-
mation on its own web site
(www.arrl.org/tis/info/part15.html
and www.arrl.org/FandES/field/
regulations/news/part97/). Although

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

SOFTWARE

RF-5 VHF Analyst
Autek Research
(727) 397-8155
www.autekresearch.com

SOURCES

EZNEC software
Roy C. Lewallen (W7EL)
www.eznec.com

BIM-2 UHF data radios
Radiometrix Ltd.
44 20 8428 1220
Fax: 44 20 8428 1221
www.radiometrix.com

Lemos International, Inc.
(Distributor)
(508) 798-5004
Fax: (508) 798-4782
www.lemosint.com

the following equation:

Combining and solving for trans-

mitter power gives:

Cranking in the Part 15 limit of

200 mV/m at 3 meters and using an
isotropic antenna (G = 1, 0 dBi) gives
12 nW. That isn’t a misprint; you may
emit no more than 12 nW of RF. The
BIM-2 radios shown in Photo 1 pro-
duce 10 mW of power at their output
pin. That’s 59 dB, nearly one million
times too much power.

An isotropic antenna in free space

bears only a passing resemblance to
an actual device, so your results will
be different. You will probably discov-
er that your radio must emit even
less power when you consider the
gain of your antenna.

In short, BIM-2 data radios cannot

legally be used for voice or data trans-
mission under FCC Part 15 without
drastically attenuating their output,
to the point where there’s essentially
no power left. Surprised? You’re prob-
ably not alone. BIM-2 radios comply
with European UHF power limits,
which are significantly higher than
U.S. limits. Radiometrix provides an
application note that discusses power
outputs in various jurisdictions,
although the company uses the FCC’s
higher power limits applicable to
intermittent radiators.

Fortunately, you can also operate

UHF transmitters under 47 CFR 97,
the regulations for the Amateur Radio
Service. In order to transmit under
Part 97, however, you must have an
amateur radio license. You may then
bounce 1.5-kW UHF signals off the
moon, should you so desire.

If you recall, back in February I told

you to get a ham ticket. Now you
know why.

CONTACT RELEASE

Ham radio operators must identify

their transmissions every 10 min.
with their call signs. I used a small

Ed Nisley, PE, is an electrical engi-
neer and a ham radio geek
(KE4ZNU). You may contact him at
ed.nisley@ieee.org.

REFERENCES

[1] R. Dome, “A Study of the

DDRR Antenna,” QST (reprints
at www.arrl.org), July 1972.

[2] Federal Communications

Commission, Code of Federal
Regulations Title 47

, GPO,

Washington, D.C.

[3] The ARRL Antenna Book, 17

Edition, ISBN 0-87259-473-4.
Purchase online at www.arrl.org.

hand-held radio at 300 mW, 15 dB
higher than the data radios. This sat-
isfies Part 97.119 even though BIM-2
radios themselves weren’t transmit-
ting my call sign.

Part 97.307 sets emission standards

and Part 97.309 specifies coding
methods and bandwidths. I have not
done a complete analysis of BIM-2
radios as used in the eval kits, but I
believe they are not in compliance
when operated at their full 64-kbps
data rate and maximum FM devia-
tion. For voice communication, how-
ever, they should work just fine.

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

n occasional

pastime of mine

(and of a few friends

in my rural Georgia

locale) is to watch for satellites in the
early evenings as they pass over and
reflect the light of the sun. OK, you’re
right, it’s a little difficult to find
entertainment out here.

The North American Aerospace

Defense Command (NORAD) tracks
all known orbiting objects. As of
September 26, 2001, NORAD was
tracking 8998 orbiting bodies,
including payloads, rocket bodies,
and debris. Some of these objects are
far too small to be seen, but plenty
of them are highly visible with a tele-
scope. There are spectacular events
to watch, such as a Space Shuttle
trailing the International Space
Station by a few degrees as the shuttle
approaches for docking.

Quite a few programs and web sites

exist that predict the look angles
(azimuth and elevation) of these
objects. NORAD produces mathemat-
ical elements (known as Keplerian
two-line elements) that may be
plugged into an orbital prediction
algorithm to predict the locations of
the objects (the look angles). If you’re
unfamiliar with satellite tracking,

FEATURE
ARTICLE

there are many web sites with abun-
dant information. A couple to get you
started are www.satobs.org/satintro.
html and www.celestrak.com.

Being an amateur radio operator and

having an interest in satellites led me
a few years ago to design a rotor con-
troller to track the satellites. This
unit required a continuous stream of
data from a PC to instruct the rotor
where to point. There are numerous
tracking programs and several com-
mercial rotor controllers that perform
this same task. The main difference
in my design was that it used inex-
pensive TV rotors.

As it turned out, one of the side

benefits of the rotor controller was
that I could use it to point to visible
satellites to aid in locating them. I
soon began to ponder the possibility
of a portable version that could be
operated independently of the com-
puter, not requiring real-time data.
Then, the Design2K contest spon-
sored by Circuit Cellar and Philips
brought the incentive I needed to get
to work on the project.

The SatPoint, shown in Photo 1, is

a portable satellite-tracking device
with an illuminated pointer that
points toward satellites under the
direction of an 87LPC764 controller.
You connect the unit to a PC via RS-
232 to receive a download of up to
100 satellite passes.

SatPoint Project

Kenneth’s SatPoint
project probably won’t
resolve the mystery of
UFOs, but it does
make it easy to track
satellites as they orbit
above us. With the
help of a Philips
87LPC764 controller,
the SatPoint plots the
course and points out
satellites as they pass
over your location.

Kenneth Trussell

8051 (DS5000T)

87LPC764

1: P1.0

1: P0.0

2: P1.1

20: P0.1

3: P1.2

19: P0.2

4: P1.3

18: P0.3

5: P1.4

17: P0.4

6: P1.5

16: P0.5

7: P1.6

15: P0.6

8: P1.7

13: P0.7

10: P3.0 (RxD)

12: P1.0 (TxD)

11: P3.1 (TxD)

11: P1.1 (RxD)

12: P3.2

10: P1.2

13: P3.3

9: P1.3

14: P3.4

8: P1.4

15: P3.5

4: P1.5

16: P3.6

3: P1.6

17: P3.7

2: P1.7

21: P2.0

7: P2.0

Table 1—

I wired a 40-pin IC socket to a 20-pin IC

socket. A RAM-based Dallas Semiconductor DS5000T
was used for software development in the place of the
OTP 87LPC764.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

The LP3965 datasheets show that

the dropout voltage (V

OUT

– V

) is

approximately 150 mV at 600 mA, so
the supply can drop to an output of
approximately 5.15 V before you start
having problems. This doesn’t leave
much running room (another good
reason to design for 3.3 V). Based on a
quick review of the data from
data.energizer.com, I estimated that
alkaline batteries should last between
2 and 3 h. I use rechargeable NiMH
batteries, and have run them for 3 h
with no problems.

DESIGN METHODOLOGY

When I made the decision to enter

the contest about two months prior to
the deadline, I knew I would have to
be organized to complete my design
in time. I began by drawing a rough
block diagram and a few notes on
how the machine would operate. I
used Microsoft Project to produce a
Gantt chart to show myself how I
could meet the deadline. It looked
possible if I stayed focused. I have to
admit that I took a week vacation
from work at the end and slept little.
Am I the only person who tortures
himself to have so much fun?

The major challenge always is the

mechanical part of a design. I needed
a small, low-power device that would
move a pointer to all compass headings
and from 0° to 90° vertically. Searching
the Internet, I found a robotic claw
that uses two radio-controlled air-
plane servos strapped together at 90°
angles. I had found my mechanics.

Recently, I used wire wrap boards

for a project’s first prototype, but with
two-sided prototype PC boards so

along its length. The pointer is a
0.25

″

wooden dowel with holes

drilled in it for the LED leads (see
Photo 3). At night, the row of LEDs
provides just enough illumination
needed to sight along the pointer
toward a satellite.

An Epson 8593 I

C RTC chip keeps

time. An I

C 32-KB EEPROM stores

satellite data. I use an RS-232 port to
receive the data for upcoming satel-
lite passes. For the display, I use a 2 ×
20 LCD. A 74HC148 encoder is used
to encode the six-switch inputs into
three lines to the 87LPC764 to con-
serve CPU I/O lines. This design
requires 17 I/O pins (out of the 18 pins
available) on the 87LPC764. I used an
external oscillator to run the proces-
sor at 7.3728 MHz.

I based my design on 3.3 V at first

(except for the servo power, which
can be selected with a jumper to
come from before or after the voltage
regulator.) When I began ordering
parts, some of the 3.3-V parts (e.g.,
3.3-V RS-232 interface chip or 3.3-V
real-time clock chip) I wanted were
out of stock at the distributors I
checked. Therefore, I decided to
design for 5 V but tried to choose
components that could also operate at
3.3 V. As it stands, all components
except the 8593 RTC are available in
a 3.3-V version.

Four AA batteries or an unregulated

6-VDC wall wart provides power. An
LP3965-ADJ adjustable low dropout
regulator provides 5 V (3.3 V with a
resistor change). Current draw is
approximately 300 mA with no point-
er movement and the LCD backlight
turned off. It increases to approxi-
mately 400 mA with the addition of
full backlighting and 550 to 600 mA
when the pointer is moving.

The data may span several days.

The satellite records are stored in
nonvolatile memory permitting the
unit to be turned on and off as needed
without having to reload the tracking
data. The PC also sends the current
date and time to the SatPoint at the
beginning of each data set download.
A battery-backed, real-time clock pre-
serves the time so that the SatPoint
is ready to track real time at any
time. Push buttons and a 2 × 20 LCD
provide an operator interface.

THEORY OF OPERATION

A simplified block diagram of the

SatPoint is illustrated in Figure 1. At
the heart of the SatPoint is the
87LPC764 processor. The Philips
processor fits well in this application,
with 4 KB of EEPROM for the pro-
gram and an operating voltage of 2.7
to 6 V. It is well suited for battery
operation. Besides that, the 87LPC764
is dirt cheap. I paid $1.98 each for
small quantities. The worst disadvan-
tage to using the chip was the lack of
development tools, specifically a
hardware emulator, but that has
changed since the contest.

The SatPoint uses two RC airplane-

type servos in an azimuth/ elevation
configuration as shown in Photo 2.
The servos position an 18

″

pointer

with three dimly lit LEDs spaced

Photo 1—

The SatPoint is poised for a night of satellite

spotting. Four AA batteries on the rear power the unit
during portable operation.

Photo 2—

The azimuth servo is mounted through the

lid. The elevation servo is strapped to the azimuth
rotator with a hose clamp. This combination gives full
360° movement.

Photo 3—

Small holes are drilled in the pointer for the

LED leads. Wire wrap wire is used for interconnection.

I knew the burn-test-chunk-burn-

test-chunk… method would burn a
whole lot of $1.98 silicon. I began my
search for an emulator. I wanted one
specifically for the 87LPC764 to allow
emulation of the hardware I

C port.

At the time of the contest, the 51LPC
family was relatively new. Distributors
quoted deliveries from 12 to 143 weeks
for the Philips emulator. I was impressed
with the Ceibo product offering, but
Ceibo also had delivery problems,
expecting to have stock “any day now”
for weeks. Eventually, I canceled my
order, knowing it wouldn’t get to me
in time to help on this project.

The handiest tool was, of course,

the trusty oscilloscope. If you haven’t
debugged I

C live and in color (OK,

green) on an oscilloscope, you’re miss-
ing a treat. As you can see in Photo 5,
it’s interesting to see the textbook
waveforms come to life.

HOMEMADE EMULATOR?

When it was obvious that I would

not get an emulator in time to help
with testing, I had to scramble for a
development system. I used a Dallas
Semiconductor DS5000T that a friend
had recently given to me (you can
never have too many friends like
that!). I wire wrapped a 20-pin wire
wrap socket to a 40-pin wire wrap
socket so that the DS5000T (standard
8051 pinout) mapped to the 17 pins of
the 87LPC764 I planned to use. The
mapping is shown in Table 1.

This puts the RX and TX in the

right place (8051 has them on P3, and
87LPC764 has them on P1). And,
with C preprocessor constants used
throughout my program, only a few

Issue 137 December 2001

www.circuitcellar.com

CIRCUIT CELLAR

inexpensive these days, it’s faster to
take a chance on the PC board and
make modifications as necessary to
get the circuit working.

For the board artwork, I decided to

try using Eagle from Cadsoft. I’ve
never been pleased with the $600
package I purchased several years ago,
even after several upgrades. I had
heard positive things about Eagle on
comp.arch.embedded.

As a side note, comp.arch.embedded

is one of a few good newsgroups for
exchanging ideas and obtaining help
from other embedded engineers. If
you aren’t using this “other side” of
the ’Net, you’re missing a lot of
interesting discussion.

Eagle software is free for evalua-

tion from www.cadsoft.de. And, it
carries a reasonable price tag (as low
as $49 if you don’t mind being limited
to 3

″

× 4

″

boards).

After drawing the schematic in

Figure 2, I created a small PC board
layout, letting Eagle auto-route it. I
didn’t spend much time tweaking the
layout. I needed a board quickly and
Eagle did a good job with the routing.
The board was ordered via e-mail and
arrived two days later. Photo 4 is an
under-the-hood view of the board.

I mainly work as a hobbyist with

only an occasional commercial proj-
ect, so normally I cannot justify buy-
ing expensive tools. For full-size 8051
derivatives, I usually use a ROM
monitor with external RAM during
debugging. In this case, though,
because Philips produces only the
51LPC family in OTP parts, I thought
development would be greatly aided
with a hardware emulator.

Photo 4—

All ICs are DIP except for a surface-mount

8593 RTC that is hiding underneath the large after-
thought capacitor in the upper right corner. The two AA
cells form the battery backup for the RTC.

Photo 5—

The oscilloscope is invaluable in solving I

software problems. The top trace shown here is SDA,
and the bottom is SCL.

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

lines have to be changed in the source
to choose 8051 or 87LPC764 compila-
tion. I used the software I

C code

from G. Goodhue of Philips-Signetics
for the low-level I

C routines on the

DS5000T. I originally planned to use
the hardware I

C port found on the

87LPC764, but because of the
approaching contest deadline and the
lack of a hardware emulator, I chose
the software implementation for the
final code version, as well.

I inserted the 20-pin wire wrap

socket into the socket on the PC
board to connect the DS5000T into
the circuit. Though ugly, this emula-
tion method worked well. I was able
to postpone burning an OTP part
until the end when all was debugged.

SOFTWARE TOOLS

To get the most out of a compact

micro with limited program memory,
you need a good set of development
tools. I used Raisonance RC-51 and
the RIDE integrated environment.
The tools include a well-integrated
compiler, assembler, linker, simula-
tor, CodeCompressor51, and support
for ROM monitor.

CodeCompressor merits a word or

two. It is a new tool that performs the
same optimizations (peephole, factor-
ization, and in-lining) you would
expect from a good compiler, but it
does it at the post-linker level.
Performing the optimizations at this
level allows CodeCompressor to see
optimizations that a compiler opti-
mization step would miss. For exam-
ple, it will look for common code seg-
ments in the entire application,

including the library modules and
assembly modules, and combine
them into common functions.

After compiling my C source,

assembling the I

C assembly module,

and linking, I had a program size of
4132 bytes. But, that was a hair too
large for the 87LPC764). Then, after
running CodeCompressor, the size
dropped to 3856 bytes, comfortably
fitting in the 87LPC764 by saving
276 bytes (about 6.7%).

DRIVING AN RC SERVO

A radio-controlled airplane servo is

an interesting animal to control. It
has three wires, power, control, and
ground. Providing a series of pulses
on the control line operates the servo.
The position of the servo is deter-
mined by the pulse width it receives.
A typical servo will accept a pulse
width range of 0.5 to 2.5 ms for a
movement between –90° and 90°.
The off time generally should be
between 10 and 20 ms but is not crit-
ical, except that if it is too long, the

servo will go to sleep and may
drift from its position.

Obviously what I needed

here was a PWM output.
Unfortunately, the Philips
87LPC768, with PWM capabili-
ty, had not been released at the
time of the contest, so I created
the PWM outputs with a four-
step state machine implement-
ed in the Timer0 interrupt rou-
tine (see Listing 1). Each time
the interrupt routine is trig-
gered, the state variable,
istate, is incremented until it
reaches three at which time it

Photo 6—This is the main menu. By the way, that is a
tape-drive bezel surrounding the LCD.

Photo 7—During simulation and tracking, the azimuth and eleva-
tion are displayed below the satellite’s abbreviated name.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

is reset to zero. Table 2 states the
activity at each state. This scheme
causes the off time of each servo
output to be approximately 20 ms
plus the on time of the other servo,
which is acceptable.

DATA STORAGE

The satellite data records are stored

in SatPoint compactly to minimize
EEPROM requirements. The bits of

the date and time are also arranged
from MSB to LSB to allow fast com-
parisons when searching (and require
less code). Table 3 shows the satellite
name table that contains a 6-byte
abbreviation and a 2-byte pointer to
the start of the data records for each
satellite. Figure 3 shows the data
record format. The records are passed
to the SatPoint from the PC in this
same compact format.

As the SatPoint tracks or searches,

the real-time clock data is converted
to this format so that a simple left-
to-right memory comparison will
indicate whether the point is past,
present, or future.

GENERATING SATELLITE DATA

The SatPoint expects data to be

loaded in a compressed format. I
wrote a utility program that will post-
process the output of T.S. Kelso’s

Trakstar program to compress and
send selected data to the SatPoint.
Trakstar is a program that will
process a file of Keplerian elements,
generating satellite pass information
in tabular form. You may download it
from the Celestrak web site.

Celestrak also keeps a current

repository of Keplerian elements
grouped in useful categories. Trakstar
will generate individual data files for
each satellite. The file names repre-
sent satellite object numbers, making
it difficult to find the correct data for
a given satellite if you are more
familiar with the satellite names than
the satellite numbers.

The utility program

SATSEND.exe

will process these output files and
generate two data files,

AOS.txt and

ORDER.txt. The former contains one
line per satellite pass showing the
beginning time and position of the

LCD

Pointer

RS-232

RTC

EEPROM

Panel

switches

I C

Microprocessor

Figure 1—

The major subsystems of the SatPoint are

shown in this simplified block diagram.

Figure 2—This schematic shows the entire design except for front panel switches and power sources (battery and DC wall transformer).

Issue 137 December 2001

www.circuitcellar.com

CIRCUIT CELLAR

pass and the maximum elevation and
closest range that the pass will
achieve. This allows a quick glimpse
of what to expect from an upcoming
night of satellite spotting.

ORDER.txt

contains detailed chronological data
for each pass.

SATSEND.exe can filter the data to

include only points that meet a mini-
mum elevation angle and a maxi-
mum range (in kilometers). This fea-
ture is useful to cull the satellites that
are too far away or too near the hori-
zon to be visible.

As a general rule, satellites that

come within 1500 km are good tar-
gets. Satellites that are less than
1000 km away are the most likely to
be easily spotted. The primary pur-
pose of

SATSEND.exe is sending data to

the SatPoint. The program is also use-
ful for simply organizing the output of
Trakstar into a readable format.

To use Trakstar, you need to set up

an observer file, which contains your
latitude, longitude, height above sea
level, offset from UTC (do not include
the extra offset for daylight savings
time), and a flag that indicates whether
or not your area observes daylight sav-
ings time. Trakstar also has a configu-
ration file,

trakstar.cfg, that con-

tains information about where your
files are located.

SATSEND.exe uses a similar configu-

ration file, called

satsend.cfg, for

locating its data files (the output of
Trakstar and the Keplerian file). The
first line of the file should contain
the full path of the Keplerian element
file in double quotes (for example,

d:\trakstar\in\visual.tle

The second line must contain the full
path of the directory where Trakstar
will store its output files (for exam-
ple,

d:\trakstar\out

). Take note

that unlike the

trakstar.cfg file,

the

satsend.cfg file should not

include a trailing backslash following
the directory name.

There are five steps for preparing

the SatPoint for a night of satellite
spotting. The first step is to obtain
the latest Keplerian elements file.
Second, run Trakstar to generate
satellite tracking data files. For the
third step, connect the SatPoint to the
PC. The fourth step is to select Load
on the SatPoint. For the fifth and final
step, run

SATSEND.exe and instruct it

to send data to the SatPoint. When
“Load Complete” is displayed on the
LCD, the SatPoint is ready to track.

SATPOINT OPERATION

In order for the SatPoint to track, it

must be oriented properly. When the
device is turned on, it will rotate the
pointer toward what it expects to be
north at an elevation angle of 33°
(conveniently this marks the eleva-
tion of Polaris from my location).
The RC servos are not powerful, but
they move quickly. You should use
caution when the pointer is moving
to avoid being hit. The LCD will

istate Value

Action

Set timer0 to generate next interrupt in 10 ms
Set azimuth and elevation control lines to zero
Increment istate

Set timer0 period to generate the next interrupt at the proper time to give the pulse width

for the desired elevation angle (calculated elsewhere in the code)

Set elevation control line to one
Increment istate

Set timer0 to generate the next interrupt in 10 ms
Set the azimuth and elevation control lines to zero
Increment istate

Set timer0 period to generate the next interrupt at the proper time to give the pulse width

for the desired azimuth angle (calculated elsewhere in the code)

Set azimuth control line to one
Set istate to zero

Table 2—

The timer0 interrupt routine steps through a state machine to generate the pulse train for the servos.

Listing 1—

This code implements the state machine described in Table 2.

*****************************************************************

Depending on the istate state variable:

If istate = 0, time until next interrupt is set to that deter-

mined by PERIODH, PERIODL constants. This should be something

reasonable for the off time required by the servo.

If istate = 1, time until next interrupt is set to value needed

to give correct pulse width to servo

*****************************************************************

timer0() interrupt 1 using 2

{

if ((istate == 0) || (istate == 2)) /Normal timing pass

{

TH0 = PERIODH;

/reload the timer

TL0 = PERIODL;

ELPULSE=AZPULSE=0;

/set both pulse outputs to 0

++istate;

/goto next state

}

else if(istate == 1)

/EL Pulse Output Timing pass

{

TH0 = elpwhicnt;

TL0 = elpwlocnt;

ELPULSE=1;

/set output to 1 for servo

++istate;

/goto next state

}

else if(istate == 3)

/AZ Pulse Output Timing pass

{

TH0 = azpwhicnt;

TL0 = azpwlocnt;

AZPULSE=1;

/set output to 1 for servo

istate=0;

/back to beginning state

}

When the pass is over, the pointer

stops and the LEDs turn off. Then,
the SatPoint will resume searching its
database for another satellite. While
in Track mode, the Menu, Up, and
Down keys are active. The Menu but-
ton aborts the tracking and returns to
the menu. Pressing the Up button
causes the SatPoint to move to the
next satellite in memory. And the
third button, Down, causes the
SatPoint to move to the previous
satellite in memory. If two satellites
are passing simultaneously, the Up
and Down buttons allow you to
choose the one you wish to track.

The final operation, simulate, is

similar in operation to tracking,
except that the SatPoint tracks every
point in its database in quick succes-
sion. This mode is great for demon-
strations of how the SatPoint operates
when no satellites are passing.

DOES IT WORK?

Having the SatPoint greatly increas-

es the number of satellites I can see in
an evening of gazing. Without it, I
would look at a printout using a flash-
light and then guess at the correct
direction to look based on the printed
azimuth and elevation. After my eyes
adjusted from having turned on the
flashlight, chances were the satellite
had moved enough that I missed it.

Only the brightest
objects in the sky,
such as the Hubbell
Space Telescope and
International Space
Station are reliable tar-
gets. However, with
SatPoint, I can get all
the information I need
from its LCD and
pointer. I can adjust
the LCD brightness to

a comfortable level.

The magic of satel-

lite spotting is in the

prediction software written by T.S.
Kelso and others. The SatPoint is just
a tool to point out what their algo-
rithms predict. I can be sure that if
the SatPoint is pointing at it, it is
there. Some of the objects are too
weak to see with the naked eye, but a
pair of binoculars often will help you
verify that an object is indeed where
Trakstar says it should be.

Well, it’s getting dark now and the

moon is new. So, I have to go and
load up the SatPoint for some high-
tech sky gazing!

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

prompt you to point the
unit toward north and
then press Menu.

After pressing Menu,

you’re presented with
menu choices of Load,
Track, and Simulate, as
you can see in Photo 6.
You may use the Left
and Right buttons to
move the greater than
and less than symbols to
surround the desired
function and then select
the operation with the
OK button. The next paragraphs
describe these operations.

To load the SatPoint with satellite

tracking tables, first connect the RS-
232 port to a PC COM port, then
select Load on the SatPoint. The
SatPoint responds, “waiting for data.”
Third, run the download program on
the PC. Now, the SatPoint will display
“loading.” After the load completes,
you’ll see, “Complete. Press Menu.”

To begin tracking, select Track

from the menu. The SatPoint begins
searching through all satellites in its
memory looking for one that is cur-
rently passing over. As it processes, it
displays each satellite’s name and
whether its pass is “complete” or to
be handled in the “future.”

When the SatPoint finds a current

satellite, it immediately begins track-
ing. The display shows an abbreviated
name for the next upcoming satellite
and the time of the pass on the top
line. The bottom line shows the cur-
rent date and time.

When a currently visible satellite is

found, the pointer LEDs illuminate,
and the pointer moves to each of the
current satellite’s points in memory
at the precise time of each event.
While the SatPoint is tracking, the
azimuth and elevation angles are dis-
played under the satellite name, as is
illustrated in Photo 7.

SOURCES

87LPC764
Philips Semiconductor
(212) 536-0500
Fax: (212) 536-0559
www.philipsmcu.com

RC-51 and RIDE
Raisonance S.A.
33 4 76081816
Fax: 33 4 76080997
www.raisonance.com

Trakstar
T.S. Kelso
www.celestrak.com

Kenneth Trussell, PE, is manager of
information services at Thiele Kaolin
Co. He has 18 years of experience in
embedded systems, industrial con-
trols, networking, and computers in
general. He holds a BEE and MSEE
from Georgia Institute of Technology.
He has also been a ham radio opera-
tor since 1978 (call sign KT4X). You
may reach him at kenneth.trussell@
thielekaolin.com.

76543210

LPPYYMMM MDDDDDhh hhhmmmmm mssssssX eeeeeeea

aaaaaaaa

76543210

Set to one if this is the last record for this satellite

A priority value from zero to three (not implemented yet)

A zero, one, two, or three offset from current year

M...M

Represents month

D...D

Represents day of month

h...h

Represents

hours

m...m

Represents minutes

s...s

Represents

seconds

e...e

Represents elevation angle (zero to 90)

a...a

Represents azimuth angle (zero to 359)

Unused. Set to zero.

Figure 3—

In this compact format, each date/time/position record requires only 6 bytes of EEP-

ROM. As many records as required per satellite are allowed up to the full EEPROM space.

Record 1

Name 1 (6 bytes)

Number of first record in data table for Name 1 (2 bytes)

Record 2

Name 2 (6 bytes)

Number of first record in data table for Name 2 (2 bytes)

Record n

Name n (6 bytes)

Number of first record in data table for Name n (2 bytes)

ETX in first byte indicating end of table

Table 3—

The satellite names are stored in a table in which each satellite requires 8 bytes. Note that I made provi-

sion for 100 names.

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

ometimes

things go wrong in

the Florida room and

I break things. In my

defense, I’ve had some great teachers.
The WHO (especially Pete and Keith)
liked to smash and blow up their
instruments on stage, and Jimi
Hendrix always seemed to have a
light when his Fender Stratocaster
needed to “smoke.” Before I tell you
what went wrong, I want to tell you
I’m not destructive on purpose.

I have to be honest. It’s been tough

keeping my focus for the last couple
of weeks as Buck Owens and Roy
Clark (the Hee Haw guys) dropped by
the Florida room and left me a brand
new black, maple-necked Fender
Telecaster guitar. Needless to say, I
was (and am still) excited. The funny
thing is that thoughts of plugging into
something embedded and DSP-
equipped runs through my mind every
time I walk by that guitar. We’ll see
where that goes.

Anyway, here’s the what-went-wrong

news. I guess I was careless while fly-
ing some of the RTL8019AS pins on
my PICDEM.net demo board. Well, I
finally managed to break off one of
the pins of the RTL8019AS I wanted
to use for this project. That task alone

APPLIED
PCs

wasn’t a problem because I have an
ample quantity of RTL8019AS parts
in the Florida-room inventory. And
the PICDEM.net runs perfectly with-
out those pins anyway.

The real problem was that I was in

a hurry when working with the sol-
dering iron and pulled away some fine
traces that interconnect the RTL8019AS
of the PICDEM.net to the PIC16F877.
After carefully surveying the damage,
it turned out that all I really lost was
a trace or two to the activity LEDs. At
this point, I could have reinstalled a
new RTL8019AS IC and continued
on. Instead, I seized the moment to
install an EDTP Packet Whacker
module on my PICDEM.net.

Photo 1 shows the Packet Whacker

taking up holes on the PICDEM.net
breadboard area. For now, pretend I
didn’t mess up the PICDEM.net’s orig-
inal pads that support the RTL8019AS
and imagine the RTL8019AS still sol-
dered in place above the LCD. The
Packet Whacker stands in perfectly as
a double for the OEM RTL8019AS IC,
which will allow me to continue my
search from last month for the elusive
RTL8019AS documentation and theory.
I don’t want your PICDEM.net to suf-
fer the same fate as mine, so, for
background information about the
ways of the EDTP Packet Whacker/
PICDEM.net combination, read my
October and November articles in
Circuit Cellar Online

The parting shot last month in the

print magazine was a view of what is
to come this month. I left you with a
screen shot of the PICDEM.net spew-
ing raw Ethernet frames across the
Florida-room LAN. Since then, I’ve
been digging like a junkyard dog. This
time around, I’ll finish the RTL8019AS
reference guide and round out the rest
of the goodies on the PICDEM.net
demo board. So, don your pith hel-
mets and let’s get back to digging out
and dusting off stuff about the
RTL8019AS and PICDEM.net.

WHERE ARE WE?

Thus far, we have solid code and

documentation that will initialize the
RTL8019AS NIC and put it on an
active network using the support
services of the PICDEM.net. Judging

Fred Eady

When Problems Strike
Your PICDEM Project

When things go wrong,
finding out where the
problem is can be diffi-
cult. When it comes to
straightforward user
blunders, kicking your-
self doesn’t help. This
month, Fred suffers
setbacks but still man-
ages to get Ethernet
frames transferred
using the RTL8019AS
and a PIC.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

It’s important to cover the entire

NIC receive process as each piece of
the receive process lays groundwork
for procedures that will follow. I’ll
supplement words with working code
as I go along. As far as packet recep-
tion is concerned, everything begins
with an NIC having something to say,
listening for silence, and then generat-
ing a preamble on the network. The
listening NICs sense a carrier and
search the incoming preamble (alter-
nating ones and zeros) for two consec-
utive ones, otherwise known as the
start of frame delimiter (SFD).

Meanwhile, there isn’t much you

can do with the control registers of
the RTL8019AS to affect the carrier
sense/preamble parse operation. There’s
a carrier sense lost bit in the transmit
status register (TSR), but it’s used
only in the transmit phase to indicate
carrier loss during a packet transmis-
sion. Setting up LED 1 to display the
CRS signal state is one way to visual-
ly monitor carrier sense status, how-
ever, that doesn’t do the application
layer any good. You can also write a
zero to LED 1 and get CRS status via
LED 1, which, at this time, would be
configured as the RX LED.

At this point, the microcontroller

need not be concerned with the net-

The “only if it’s addressed to me”

or “only if I want to see it” behavior
is called filtering. The RTL8019AS
has many ways of filtering incoming
packets. In addition, it sports an effi-
cient packet management system that
moves data from the NIC to the PIC
after the selected packets are accepted.

by the final words from last month,
it’s safe to assume that I also came
upon a find that allows you to trans-
mit raw Ethernet frames using the
PICDEM.net’s microcontroller and
the onboard RTL8019AS NIC. Through
my research of the RTL8019AS NIC, I
found that receiving Ethernet frames
is a bit more involved than transmit-
ting them. So, let’s put together the
pieces that allow the NIC to take
packets from the network.

Although sometimes configured

physically as a star, Carrier Sense
Multiple Access/Collision Detection
(CSMA/CD) networks are normally
bus topology networks. The word
“bus” implies that everyone on the
network has the ability to ride the
entire route stop by stop. That is,
every node on the bus is capable of
receiving every bit that traverses wire
and transmitting to every node that
listens on the network.

As you might imagine, for the

’16F877 on the PICDEM.net it would
be foolhardy to attempt to receive
and process every bit of information
that comes by. To avoid overburdening
the CPU, the NIC has the capability
to pick out data packets that are
addressed to it, ignoring only data
destined for other NICs on the network.

Listing 1—This is a collection of associated code that isn’t necessarily contiguous in the main listing. The
idea here is to convey the logic behind a process without having to navigate all over the main listing.

*****************************************************************

Snippet one

*****************************************************************

char MYMAC[6] = { 0,'C','C','I','N','K' };

for(i=0;i<6;++i)

write_creg(PAR0+i, MYMAC[i]);

*****************************************************************

Snippet two

*****************************************************************

#define rcrval

0x00

#define tcrval

0x00

#define dcrval

0x58 // originally 0x48

#define imrval

0x00

#define txstart

0x40

#define rxstart

0x46

#define rxstop

0x60

write_creg(DCR,dcrval);

write_creg(TPSR,txstart);

write_creg(PSTART,rxstart);

write_creg(BNRY,rxstart);

write_creg(PSTOP,rxstop);

write_creg(CURR,rxstart);

ACTIVEB

Plug and play

RT Jumperless

Jumper

Mode

Bit 7

Bit 6

Bit 5

Bit 4

Bit 3

Bit 2

Bit 1

Bit 0

PWRDN

SLEEP

–

LEDS0

LEDS1

FUDUP

PNP

9346

–

9346

BS0

Plug and play

RT Jumperless

Jumper

Mode

Bit 7

Bit 6

Bit 5

Bit 4

Bit 3

Bit 2

Bit 1

Bit 0

BS1

BS2

BS3

BS4

BSELB

PL0

PL1

9346

IOS0

Plug and play

RT Jumperless

Jumper

Mode

Bit 7

Bit 6

Bit 5

Bit 4

Bit 3

Bit 2

Bit 1

Bit 0

IOS1

IOS2

IOS3

IRQS0

IRQS1

IRQS2

IRQEN

9346

Jumper

9346

CONFIG1

CONFIG2

CONFIG3

Figure 1—

The Packet Whacker is setup for Jumper mode. None of the jumper pins are connected and, hence, are

pulled low. Therefore, the jumper values and the 9346 values here all equal zero. So, for the PICDEM.net demo
board, Packet Whacker or no Packet Whacker, there’s no difference in the CONFIGx settings in either mode.

ULTRA-LOW-POWER FLASH MCU

DESIGN CONTEST

ULTRA-LOW-POWER FLASH MCU

DESIGN CONTEST

ULTRA-LOW-POWER FLASH MCU

DESIGN CONTEST

Got a cool gadget or practical application that
you've designed and want the world to know
about? Never mind late-night infomercials; the
Texas Instruments MSP430 Design Contest is
your opportunity to showcase your design skills
and win loads of great prizes, including a grand
prize of $5,000! Enter your project containing
an MSP430 ultra-low-power Flash MCU by
December 17, 2001, and show us how your design
(even if it's not a laser-wielding robot) could take
the world by storm.

For complete contest rules, prizes and entry form, visit

www.circuitcellar.com/msp430

www.circuitcellar.com

Issue 137 December 2001

Note that the MAC address begins

with zero, which denotes a physical
address. By making the first bit of my
MAC address a one, it’s possible to
use multicast addressing, which
would be setup in the MAR regis-
ters. Multicasting has its advantages
in certain situations and is most use-

CIRCUIT CELLAR

work’s activities anyway, because
there is absolutely no data that could
be recovered that would be important
to the microcontroller’s main applica-
tion. This is strictly a NIC thing and
that’s good because the PIC is merrily
humming along doing what PICs do,
blinking LEDs and controlling stuff.

If the incoming data is correctly

formatted within an Ethernet frame,
the first six bytes following the SFD

should be the destination address.
Check out the example in Listing 1, a
multi-snippet code listing.

The first snippet shows how and

where the MAC address is put into the
control register stack of the NIC. Within
the RTL8019AS, this MAC area consists
of the PAR0–5 registers on page 1. The
first six bytes following the SFD are
pulled into the NIC FIFO and checked
against the receive address filters. If a
match occurs, the packet is DMAed
from the FIFO into the receive buffer
ring. If there isn’t a match, no DMA
is performed, and the FIFO is reset.

Even if the destination address

matches your local MAC address, the
reception isn’t done until the CRC is
calculated and approved by the NIC.
If the CRC doesn’t compute or the
packet doesn’t end on a byte bound-
ary, bits inside the Receive Status reg-
ister (RSR) are set to indicate the
problem. In addition, depending on
the error, the appropriate tally coun-
ters CNTRX are incremented. In the
event of a failure, you can set bits to
either keep or reject the erred packet.

microsystems

Call 530-297-6073 Fax 530-297-6074

See our new site www.jkmicro.com

Intel 386EX

25MHz

DOS & Web server pre-installed

Realtime multitasking available with eRTOS

TCP/IP

10Base-T Ethernet

In-Circuit-Programmable Xilinx CPLD

512K SRAM, 512K Flash standard

Accepts M-Systems DiskOnChip

Many expansion board combinations

Photo 2—

This is a view of the RTL8019AS registers

immediately after initialization. This is a neat way to
test routines that affect registers and see what’s hap-
pening as the NIC runs.

Photo 1—

Notice that some resistors are missing from

various areas of my PICDEM.net demo board. That’s
how I isolated some of the I/O pins of the PIC for use
with the Packet Whacker. The photo of the RTL8019AS
you saw in last month’s article was put there for refer-
ence only (it wasn’t soldered down).

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

receive process, no matter what filter
technique is used, is the issuance of an
interrupt (if enabled) or setting 1 bit
signifying a good packet that’s ready
to be processed is in the receive ring.

THE QUEEN’S CHAMBER

After recognizing that the packet is

yours, the basic idea behind receiving
a packet is to get it into the micro-

ful when a single node needs to
send a packet to many nodes
simultaneously.

You must set up the destination

address so that when the CRC
logic is invoked and runs its
course, the first six MSBs of the
CRC generator are latched. The
six bits are then fed into a one of
64 decode (111111), which indexes
into one of the filter bits in the
MAR registers. If the selected MAR
filter bit is set, everything flows
like a match of the MAC address.
So, you could receive all multicast
packets by writing ones to every
MARX register bit or disabling all
multicast addressing by writing
zero to every MARX register bit.

Photo 2 is a register dump from the

PICDEM.net RTL8019AS. The MARX
registers start on page 1, register 8 and
end at register 0x0F. My code didn’t
touch the MARX registers, so you see
a random set of bit entries. If everything
was right, you could receive two valid
multicast addresses because 2 bits are
set in the matrix. The final step in the

controller RAM as quickly as
possible so it can be processed.
The second snippet in Listing 1
is the roundup of lines that are
the heart of the ring initializa-
tion code. Some of the pointers
in this snippet take care of fenc-
ing in the receive buffer ring,
and others point to the first
packet reception or transmission
page in the ring. The remaining
pointers keep up with the pages
as data packets are added to or

taken from the ring.

There are a couple ways to

determine if there’s any good data
that needs to be moved from the
ring into working storage. You

can check either the interrupt status or
the ring page pointers. Checking the
interrupt status can be done by
polling or sensing one of the INTX
lines of the NIC or by polling the
PRX bit in the RSR or Interrupt
Status Register (ISR).

Polling the RSR is risky as the con-

tents of the RSR may be leftover from
a previous packet. It’s better to poll
the ISR bit as its value is reflected in
real time. Normally, the INTX line
would trigger a microcontroller inter-
rupt, and the microcontroller would
interrogate the ISR to see what’s
knocking. One of the reasons I was
flying leads off the PICDEM.net
RTL8019AS was that I wanted to use
the INT0 line of the NIC to trigger
the packet-to-RAM process in the
PIC, because INT0 isn’t connected on
the PICDEM.net demo board.

Even though INT0 isn’t attached to

the ’16F877, the PICDEM.net’s hard-
ware design allows the RTL8019AS to
settle into a default mode that would
favor using INT0 if it were attached.
This is good because there’s no 9346
EEPROM (another reason for breaking
the NIC pins) to load the CONFIG1-3
registers to set this up. Judging from
the state of the LEDs, the absence of
the 9346 clocks in zeroes to the fields
in the CONFIG1-3 registers. You can
verify this by taking in the 0x00 value
of page 3, register 0x06. Page 3 takes
its values from the 9346 EEPROM.

The NIC JP pin of the PICDEM.net

is not connected. Thus, it’s pulled
low, internally putting the NIC in

Photo 3—

The Source and Destination Address fields crisscross to

show the echo that was performed by the PICDEM.net on data gen-
erated by the Sniffer on the tbird900 machine. This is a bogus packet
but it serves its purpose. The PICDEM.net received the packet from
the Sniffer and accurately returned it.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

Jumperless mode. Refer to Figure 1 as
I fill in the CONFIG 9346 bit patterns
beginning with bit 7. IRQEN is high at
powerup. And if it’s set, it determines
if the selected INTX line will signal a
high state on an interrupt request.
After taking the NIC’s RSTDRV pin
high or issuing an Auto-Load com-
mand, the NIC (in Jumperless mode)
attempts to get configuration data
from the 9346 EEPROM to fill values
in all of the CONFIG1-3 registers.

Because the PICDEM.net is in

Jumperless mode by default and there
is no EEPROM, the NIC clocks in
zeroes and fills the rest of the CON-
FIG1-3 bits with them. In CONFIG1,
IRQS0, IRQS1, and IRQS2 are set to
zero, enabling INT0 as the active NIC
interrupt line. The rest of the INTX
lines are tri-stated. The base I/O
address of the PICDEM.net is hard-
wired for 0x300; clearing all IOSX bits
from clocking and reading the nonex-
istent 9346 EEPROM reinforces this.

CONFIG2 is mostly concerned with

the boot ROM (BROM), which also
doesn’t exist on the PICDEM.net. As
you have already deduced, zeroes in
the BSX pins disable the BROM size
and address parameters. PL1 and PL0

select the network medium, and the
zero values put the NIC in Twisted
Pair/Coax Auto-Detect mode. Perfect.

CONFIG3 always gets its bits from

the 9346. In fact, CONFIG3 is the only
register that cannot be written to using
the remote DMA port of the NIC. The
full duplex (FUDUP) and LEDS1–S0
bits are of interest if the default values
don’t suit your environment. Putting
zeroes in these bit fields yields half-
duplex operation with the LED0 pin
representing collisions, LED1 blinking
while receiving, and the LED2 pin
blinking an LED during transmission.

There is a clever way to manipulate

CONFIG3 without the external 9346
EEPROM. Unless you’re handier with
a soldering iron than I am, you would
have to tear up your PICDEM.net like
I did to gain access to the pins. The
Packet Whacker allows you this func-
tionality without having to pull out
the magnifying glass and fine-tipped
soldering iron or walking your board
down the hall to the technicians.
Because the stock PICDEM.net works
fine the way it is, I’ll move on (check
for coverage of pin-pulling techniques
and an EEPROM emulation trick in
Circuit Cellar Online

OK, now you know that INT0 and

interrupts are available on the PIC-
DEM.net by default, but you can’t use
them right out of the box because of
the lack of wire between some of the
NIC pins and the PIC. That’s not a
bad thing. You can make use of the
tools you’ve been given by keeping an
eye on the ring pointers.

There are a couple schools of

thought on that, too. Because the
Boundary pointer follows the Current
Page pointer around the ring, when
the Boundary and Current pointers
are equal (Boundary catches up to
Current) the ring is empty. By simply
comparing the Current and Boundary
pointers, you can determine if a pack-
et is in the buffer ring. The NIC
knows when an overrun condition
(Current catches Boundary) occurs
and sets some bits to let you know.

Another method is to keep track of

the Current pointer. If the Current
pointer moves at all, it’s most likely
that a packet has been inserted into
the ring. So, you must keep up with
the boundaries of the ring and where
the Current and Boundary pointers
are in relation to the ring boundaries.
This method lets you take manual
control of the receive buffer ring
pointer mechanism.

I like the Boundary versus Current

pointer method because, if the built-
in functionally of the NIC is used, the
coder doesn’t have to keep up with
the moving ring pointers. As you look

n – 1

Boundary

pointer

Boundary

pointer

Status

cke

pointer

Receiv

yte

count (L)

Receiv

yte

count (H)

Remote DMA

removes packet

DMA Ends here

Remote byte

count 1

Remote byte

count 0

Registers loaded

by Autosend command

Boundary

pointer

Remote

start, add 1

Remote

start, add 0

Figure 2—

Even though the whole thing is automatic, you can still get the receive buffer header bytes in addition to

the packet. The catch is that the receive buffer header bytes are not counted in the receive byte count. So, you
read the buffer header and then clock in the number of bytes in the Receive Byte Count registers.

Transmit

Byte

Count

TBCR0, 1

6 bytes

2 bytes

46 bytes

Destination address

Source address

Type/length

Data

Pad (if data <46 bytes)

Destination address 0

Destination address 1

Destination address 2

Destination address 3

Destination address 4

Destination address 5

Source address 0

Source address 1

Source address 2

Source address 3

Source address 4

Source address 5

Figure 3—

This is standard Ethernet fare. The smaller

upper box is the global view of the packet. The lower
larger box lays out the bit and byte orientation.

assembles a packet in the transmit
SRAM area of the NIC. The packet
must be assembled as shown in
Figure 3. The topmost portion of
Figure 3 is a standard Ethernet
frame layout minus the preamble,
sync, and CRC fields.

The NIC will generate the pream-

ble, sync, and CRC for the frame
before transmitting the frame con-
tents. The Type/Length field is a
summation of all of the bytes in the
Destination Address, Source Address,
Type/Length field, and Data area,
and the final packet must be at least
64 bytes in length.

The Type/Length field is also used

to identify the protocol being carried
in the Data area. The NIC doesn’t
check this field for validity. If you’re
wondering where the IP and other
protocol stuff is, it’s buried inside the

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

at the second snippet in Listing 1,
notice that the

dcrval has been

changed from 0x48 to 0x58. When set,
bit 4 of the Data Configuration regis-
ter (DCR) enables the Auto-Initialize
Remote function. The physics of
auto-initialization are demonstrated
in Figure 2. This is a neat feature, and
it’s a sure bet I’ll be using the pointer
comparison method coupled with the
Auto-Initialize Remote function.

Listing 2 lays out the code I put

together to check for an overrun ring
buffer. The buffer check sequence is
immediately followed by a quick
comparison of the Boundary and
Current pointers. Hopefully, I’ll
never have to branch to the code to
service a buffer overrun. There is a
detailed procedure for buffer overrun
recovery in the DP83902A datasheet,
which I’ve translated to Microchip
speak in Listing 2. [1]

When using the Auto-Initialize

Remote and Send Packet commands,
the remote DMA channel of the NIC
may be used to pull a packet out of
the receive buffer ring. As you can see
in Figure 2, a 4-byte buffer header
prefaces each packet in the ring.
Writing a 0x1A (Send Packet com-
mand) to the CR register kicks off the
packet retrieval process. Instead of
manually loading the Remote Byte
Count registers and the Remote Start
Address registers, the counts are auto-
matically taken from the 4-byte buffer
header (see Figure 2).

I opted to keep the 4-byte buffer

header in slots of an array just in case
I need them for something else later.
The contents of the first byte of the
buffer header quartet are reflected in
the RSR after the packet is put into
the ring. If bit 0 (PRX) of the status
byte is set, the packet is fine and
ready to be removed from the ring.

At this point, the rest of the packet

can be DMAed into the PICDEM.net’s
microcontroller memory using the
services of the NIC remote DMA
port. Along the way, the NIC keeps
count of the bytes going by and termi-
nates the DMA when the Remote
Byte Count registers finally reach
zero. The Boundary pointer is then
automatically moved to reflect the
removal of the packet.

If, by chance, the DMA pointer

reaches and transcends the Page Stop
register value during the transfer, the
DMA pointer is reset to the Page Start
register value. When the Send Packet
procedure completes, the NIC is posi-
tioned to either receive another
incoming packet or repeat the auto-
matic remote DMA and remove yet
another packet from the ring.

THE KING’S CHAMBER

The dig is going well. So far, I have

discovered the secrets of RTL8019AS
initialization. In addition, while dis-
membering a PICDEM.net demo
board, I uncovered the mystery of the
ring. Sending a packet is less compli-
cated than receiving one. Using the
Transmit Page Start Address register
(TPSR) and the Transmit Byte Count
registers (TBCR0–1), the local DMA

Listing 2—The resend variable is used to inform the application about how to cope with overrun if a trans-
mission is in progress when the NIC is stopped. It isn’t used in this case, because you dump the packet and
rely on the upper layers to resend the unacknowledged data. This procedure must be performed in the
sequence laid out by the datasheet, or as the datasheet says, the NIC will act in an unpredictable manner. [1]

******************************************************************

Handles receive ring buffer overrun.

No packets are recovered.

******************************************************************

void overrun()

{

read_creg(CR);

scratch_L = byte_read;

write_creg(CR,0x21);

delay_ms(2);

write_creg(RBCR0,0x00);

write_creg(RBCR1,0x00);

if(!bit_test(scratch_L,2))

resend = 0;

else if(bit_test(scratch_L,2))

{

read_creg(ISR);

scratch_L = byte_read;

if(bit_test(scratch_L,1) || bit_test(scratch_L,3))

resend = 0;

else

resend = 1;

}

write_creg(TCR,0x02);

write_creg(CR,0x22);

write_creg(BNRY,rxstart);

write_creg(CR,0x62);

write_creg(CURR,rxstart);

write_creg(CR,0x22);

write_creg(ISR,0x10);

write_creg(TCR,tcrval);

}

Data area. When the protocol compo-
nents are in the Data area, the Type/
Length field is important for decoding
the data fields but the NIC still does-
n’t care about its contents. In other
words, the NIC doesn’t care what’s in
the truck, it just delivers the goods.

Before the packet can be sent, the

TPSR must be initialized. The TPSR
value normally will be the value that
points to the beginning of the trans-
mit SRAM area. There is no ring
here and the transmit area is one
contiguous block of memory. The
data is loaded into the transmit
buffer area using the remote DMA
port of the NIC.

After each field of the transmit

packet is DMAed in, the TBCR0 and
TBCR1 registers are loaded with the
length of the packet. The packet is
kicked out when a command setting
the TXP bit in the CR register is
issued. The TSR is cleared and the
RTL8019AS begins to fetch transmit
data. The transmission occurs if no
collisions occur, the inter-frame gap
timer has timed out the first 6.4 µs of
the inter-frame gap, and at least 1 byte
is in the FIFO.

SECRETS OF THE PYRAMIDS

Photo 3 stands as the proof of all of

our finds. The packet in Photo 3 rep-
resents the reason I organized this
dig. I’ve taken Ethernet frames that
lacked protocol across the ether suc-
cessfully using only an RTL8019AS
and PIC. Ancient pyramids are layers
of stone built from the ground up.
Our pyramid is the OSI stack, and
thus far we’ve dusted only around the
bottom of the pyramid.

The dig is not complete and has

moved to Circuit Cellar Online. There
the pyramid is climbed using tools of
the trade (PICDEM.net), tools we had
to invent (Packet Whacker), and tools
held in reserve (NetSock/100) to
prove once again that it doesn’t have
to be complicated to be embedded.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

SOURCES

8019AS Ethernet IC
Realtek Semiconductor Corp.
886 3 578 0211
Fax: 886 3 577 6047
www.realtek.com.tw

PICDEM.net Evaluation board
Microchip Technology Inc.
(480) 792-7200
Fax: (480) 899-9210
www.microchip.com

REFERENCE

[1] National Semiconductor, Inc.,

“DP83902A ST-NIC: Serial
Network Interface Controller for
Twisted Pair,” November 1995.

SOFTWARE

Fred Eady has more than 20 years of
experience as a systems engineer. He
has worked with computers and
communication systems large and
small, simple and complex. His forte
is embedded-systems design and

communications. Fred may be
reached at fred@edtp.com.

CIRCUIT CELLAR

www.circuitcellar.com

eceptionists

have it rough. To

answer the phone

with any intelligence, a

receptionist must not only have a
good grasp of the company’s product
to steer calls properly, but also keep
track of who is actually in the office
at any point in time. Transferring a
call and letting voicemail handle it is
a cop out. And yes, most phone sys-
tems allow a call to be forwarded to
another extension if you’re away from
your desk, but who uses that? Some
jobs require employees to spend as
much time out of the office as they do
at their desks. And then there’s lunch.
What’s a receptionist to do?

Here at Circuit Cellar world head-

quarters, we use a sophisticated tech-
nique to help our receptionist keep
track of transient personnel. We use
magnetic markers for each employee,
which are moved between an in and
out position to show current status
(see Photo 1). This is located in the
reception area, right by the door and
is easily updated as people come and
go. Now, this is fine for the reception-
ist who mans the phone within sight
of the status board, but what about
everyone else in the facility?
Wandering through the building’s

maze of offices, you can constantly
hear unanswered intercom calls to the
empty desks of Circuit Cellar’s work-
force. Could they be out of the build-
ing or just in the restroom?

Instead of the current system, con-

sider my thought. Everyone has a PC
sitting on his or her desk. Wouldn’t it
be nice if the status board could be
broadcast to everyone?

SITEPLAYER

Well, broadcast might not be the

right word. However, by using the
company LAN, there is now a cost-
effective solution. NetMedia offers
the SitePlayer (SP1) as a commercial
remedy. It boasts the SP1 as “the
world’s smallest Ethernet web server”
at roughly one inch squared.
SitePlayer allows your application to
be web enabled easily with just a seri-
al port on your device. But what does
this thing do, exactly?

The SitePlayer contains a micro-

processor with flash memory. This
allows its own firmware (web server
application) and your web’s files to be
quickly updated (even across the
LAN). Additionally, the SP1 includes
a 10baseT Ethernet controller, serial
device interface, and 8-bit I/O port.
The web server application handles
hosting your (dynamic) web pages
through the LAN using either its own
static IP address or a dynamic IP
address obtained through the DHCP
server. Let’s develop this project for a
clearer understanding of how this lit-
tle device makes it all possible.

ONE OF THREE

I want every employee on our LAN

to simply open their favorite browser
on their PC and access the SitePlayer’s
IP address, which will display the cur-
rent status of the magnetic board in
the reception area. The first step in
creating an interactive web site is to
define the SiteObjects that will be
dynamic. As you can see in Photo 1,
the board consists of a number of
employees and an indicator, which
visually shows whether the employee
is in or out of the facility.

When a physical message is taken

for an employee, the employee’s mag-
netic indicator is removed from the

Jeff Bachiochi

Desktop Status
from NetMedia

FROM THE
BENCH

Keeping
track of
people
is chal-
lenging.
A hard-

ware and software
solution from Net-
Media might reduce
the number of “away
from their desk” mes-
sages as well as
rounds of phone tag.

Issue 137 December 2001

www.circuitcellar.com

CIRCUIT CELLAR

in/out position and placed atop the
paper note holding it onto the board
but off to the side. Upon returning,
the employee finds his indicator miss-
ing, retrieves it from the associated
paper note, and replaces the indicator.
So, my project also needs to include
some sort of indicator for messages.
In all, I’ll have to define 18 employ-
ees, staff in/out status, and message
status variables to be maintained by
the SitePlayer.

The SitePlayer comes with the

SiteLinker software development pro-
gram. Launch the editor from
SiteLinker, and you can create an
.SDF text file (SitePlayer definition
file). This file has three sections. The
first section defines initial setup
parameters (i.e., the IP address, down-
load password,

.HTM files, and paths).

The next section defines the

SiteObjects, which are the variables
to display. They can be bits, bytes,
words, double words, or strings (see
Listing 1). From a browser point of
view, these can be set up as read-only
or read/write variables. A total of
768 bytes of RAM are available for
SiteObjects, but I’ll use less than
150 bytes for this project. In addition
to the user-defined SiteObjects locat-

ed in the RAM, there are a
few predefined SiteObjects,
which include addresses to
directly write and read to the
8-bit I/O port. Note: If eight
I/Os are enough for your
application, you can do it all
without additional circuitry.

The final part is the export

section. This section is respon-

sible for creating and saving
output files like the site’s
.INC (include) file, which
defines the SiteObjects for use
with your application .

ASM file.

TWO OF THREE

Now that I have defined the

SiteObjects, the second step is to cre-
ate a web site design. Using FrontPage
by Microsoft (you can
use any web site
design tool), I created a
form with a number of
objects on it to closely
resemble the magnetic
status board. You can
see this version in the
screen shot in Photo 2.
Three objects are
required for each
employee: the employ-
ee’s name (a text box)
and two check boxes.

The magnetic status

board uses two posi-
tions, one for in and
one for out. Check
boxes quickly show the in or out sta-
tus (the first check box) as well as
whether or not there is a message for
the employee (the second check box).
This improves the present system,
which can’t designate the in or out
status of employees who have mes-
sages waiting for them.

Each SiteObject defined in the pre-

vious

.SDF file must be associated

with an object on the web site form.
Let’s take a look at the basic block for
a single employee in Photo 2. I want
the employee’s name to appear in the
text box. Listing 2 lists the HTML
code for the first objects in Photo 2. I
had to add

value="^employee1"

into the string:

<input type="text"

name="employee1">

before the closing greater than sign.

Notice this value is the same name

as defined in the SiteObject in the
.SPD file (see Listing 1) except it has
a caret at the beginning of the vari-
able name. The caret tells the
SitePlayer to place the value of the
first employee SiteObject into the
text box (in this case, Kevin). The
resultant HTML string:

creates a box with the text “Kevin”
written inside it.

Check boxes work a bit differently.

Notice in the following string that the

value is one and the associated
SiteObject

^here1#1 is by itself:

The value of a check box can be

only a one (checked) or zero (not
checked). In this case,

value="1" is

the value to be passed back to the
SitePlayer when the box is checked by
the user.

^here1 is the associated

SiteObject, and the number one
tacked on the end of the variable
name instructs the SitePlayer to use
bit 1 of the variable here. Note that I
used byte variables for the check box
SiteObjects even though they require
only bit variables.

Issue 137 December 2001

Photo 2—FrontPage from Microsoft let me design a form that resembles the
original magnetic status board.

Photo 3—

Compiling the

.SPD

file and HTML file cre-

ates a

.SPB

binary file for downloading to the SitePlayer.

Photo 1—Employees at Circuit Cellar world headquarters are
responsible for moving their magnetic marker. The markers indi-
cate who is in and out of the building.

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

If the SiteObject

"here1" is one,

the SitePlayer interprets

^here1 as

the text that’s checked. The resultant
HTML string creates a box with a
check mark:

here1 is zero, the SitePlayer

interprets

^here1 as null text. The

resultant HTML string creates an
empty box:

The same is true for the second check
box for the SiteObject

message1.

Look at the following two lines:

It seems as though when a user
deletes the check from a box, nothing
gets returned. You must create a hid-
den object that will return

value=0

to the SiteObject. This is always sent,

however, because the following
line is

input type="check

box", a value=1 is sent to the
SiteObject when it’s checked
by the user. This value imme-
diately replaces the

value=0 in

the SiteObject variable (

here1

message1).

If you refer back to Photo 2,

you’ll see a Submit button.
After you alter any of the check
boxes, you need to click on this
button. Submitting updates all

of the SiteObjects and returns a
refreshed page to your browser. If you
use the browser’s Refresh button, all
changes will be lost because there
hasn’t been an update, and refreshing
the browser will return the
previous value, assuming
nothing has been changed by
other means (more on this
important comment later).

THREE OF THREE

Now, you have a single

page web site design finished.
The last step here is to use
SiteLinker to compile the
.SPD file along with your
HTML file into an

.SPB

binary file, which can be
downloaded into the
SitePlayer hardware. The
SiteLinker program indicates
this project requires about half of the
available 48 KB of flash memory web
space (see Photo 3).

Another function of SiteLinker is to

download this binary file into the
SitePlayer hardware. This can occur
through either the serial port or
Ethernet connection. After download-

ing and assuming you have
SitePlayer connected to your
LAN, you can call up your
browser (right from SiteLinker)
to access your web page running
on SitePlayer.

Referring to Photo 4, notice

how the employee names have
been placed into the text boxes.
You can click any of the check
boxes, and after clicking the
Submit button you’ll see those
changes reflected in the
SiteObjects, which have been
updated. It looks good, but how

does this reflect what is actually on
the magnetic status board located in
the reception area?

IT’S GOTTA GO

I wanted to take full advantage of

the original magnetic status board.
The most important reason to use the
original board was to prevent gasps of
horror if replaced by something com-
pletely different (read: user-unfriend-
ly). I worked with Hall effect sensors
to try and make use of the magnetic
pieces already existing. The flux lines
in the metal board were impossible to
work with without limiting the style
of magnetic indicators being used,
demanding a particular orientation of

the indicator, or completely revamp-
ing the board. So much for using the
existing magnetic properties.

My next approach was to place IR

emitter/sensor pairs within each status
position. As the indicator was moved
from in to out, one or the other of the
photo sensor pairs would register the
presence of the indicator covering the
sensor. This would have worked fine
except for the ambient room light.
Many of the uncovered sensors were
falsely triggering from light within
the IR spectrum radiating from the
office environment. Two strikes.

I began thinking simple. Toggle

switches would be the simplest.
Should I use an indicator light in
addition to show status? I needed to
show status for at least 18 employees.
That would be 36 inputs (18 employ-
ees × 2 switches) and outputs (18 × 2
status LEDs). Then I thought of how a

Photo 4—From the browser’s point of view, here’s your HTML
form from the SitePlayer. Notice that the dynamic variables are
substituted into the form.

Photo 6—The modular approach to the LED/button panels
made this assembly go together without a hitch.

Photo 5—Using metal panels next to the LED/button panel allows
the familiar magnetic name plates to be used.

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

Listing 1

—

This is a listing of variables held by the SitePlayer. There are three pieces of information for each

employee:

here

x (in/out status),

message

x (message status), and

exployee

x (employee’s name).

;OBJECT SECTION

org

$OutputOnly
$bidirectional
here1

message1

here2

message2

here3

message3

here4

message4

here5

message5

here6

message6

here7

message7

here8

message8

here9

message9

here10

message10

here11

message11

here12

message12

here13

message13

here14

message14

here15

message15

here16

message16

here17

message17

here18

message18

employee1

"Kevin"

employee2

"Val"

employee3

"Sally"

employee4

"Howard"

employee5

"Elaine"

employee6

"Jeff"

employee7

"Dan"

employee8

"Jeannette"

employee9

"Steve"

employee10

"Rob"

employee11

"KC"

employee12

"Mary"

employee13

"John"

employee14

"Jennifer"

employee15

"Jenn"

employee16

"Cindy"

employee17

"Debbie"

employee18

" "

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

actual state of the status LEDs will
not come directly from the push but-
ton switches, but rather from the
SitePlayer. It is the SitePlayer’s
SiteObjects that control the status;
and they can get input from both the
switches and browser (Submit button).
So, not only will the status of the
board be viewed from any PC, but also
the PC can be used to change the sta-
tus of the board just as if the employ-
ee had pressed one of the push but-
tons manually. How do the scanning
microprocessor and SitePlayer work
together to make all of this happen?

THE MISSING LINK

If I needed only eight I/Os, the

SitePlayer could control these directly
via its onboard I/O. For larger applica-
tions like this one, the SitePlayer has
a serial port allowing your circuitry to
share information with it. The serial
port defaults to 9600 bps, however,
rates from 110 to 115 Kb are possible.
The variables set up earlier using
SiteLinker hold the status informa-
tion. The SitePlayer recognizes a set

keypad could be scanned using row
(outputs) and column (inputs). Six
outputs and six inputs could address
36 push buttons. With an additional
six outputs, I could also address 36
LEDs by using the same row output
to enable the LEDs as well as push
button columns.

I would use a green LED for in sta-

tus and a red LED for out status.
Because both of the LEDs shouldn’t
be on at the same time (disregarding
split personalities of some of the
employees), only a maximum of three
of the six column LEDs would draw
current at any one time. The
PIC16F874 microprocessor can source
(or sink) 25 mA, so sourcing LED cur-
rent isn’t a problem. However, sink-
ing 75 mA by the row line is a no-no.
The six row signals will need transis-
tors, which can support sinking the
current of all the columns. For a visu-
al demonstration, see Figures 1a and b.

Two push buttons and two LEDs

are used for each employee. One but-
ton toggles the in/out status of the
employee and the second button tog-
gles the message status for that
employee. The two LEDs will display
the status of the employee, green indi-
cating in and red indicating out. To
avoid requiring additional LEDs for
the message status, I decided to blink
the illuminated LED to indicate a
message is available for the employee.
So, the in/out button toggles the
green and red LEDs, and the Message
button toggles the Steady-State/
Blinking mode of the LEDs.

Photo 5 shows the new status board

in operation. Photo 6 shows how the
PCB is wired to each set of switches
and LEDs. This all connects to the
LAN via the SitePlayer, the interface
transformer, and RJ-45 shown at the
bottom of the PCB.

Because the LEDs (and switches) are

controlled by a microprocessor, the
status is dynamic. This means the

Listing 2

—

FrontPage produces this HTML code. Text is added to allow the SitePlayer to control the content.

<tr>

<td><input type="text" name="employee1"

value="^employee1"></td>

<td align="center"><input type="checkbox" name="here1"

value="1" ^here1#1></td>

<td align="center"><input type="checkbox" name="mes

sage1" value="1" ^message1#1></td>

</tr>

</table>

</td>

</form>

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

of commands that allow the applica-
tion to read and write to the
SitePlayer’s RAM.

To prevent data communication

from tying up the scanning process and
reducing the one-sixth multiplexing
rate even further, only one employee’s
status will be updated each time all
the rows and columns are scanned.
The microprocessor’s scanning
process is threefold. First, you request
employee information from the
SitePlayer. This is done with a 2-byte
command,

0C1h, 0xxh, where 0xxh

is the RAM address (in the SitePlayer)
of the two bytes the

0C1h command

requests. In this case, it means the
herex and messagex variables.

One of the output files, which can

be created when compiling the web
site using SiteLinker, is an

.INC file

that lists all of the variables and their
addresses in the SitePlayer. Including
this file in the microprocessor’s
source file takes care of making sure
you’re asking for the correct address
from within the application code.

The SitePlayer returns the value of

the two addresses requested. These
bytes indicate the present status of
in/out and message for employees.
These values replace the values in the
microprocessor’s RAM.

The table in RAM is then used dur-

ing the push button/LED scan routine
as the present status for determining
which LED to turn on. During the
scan, any push button activity is
recorded and the appropriate RAM
location is updated with the new sta-
tus. If a button push is detected,
meaning someone manually changed

the status of some employee, a write
command is sent to the SitePlayer.

After that, all you need is for the

SiteObjects to hold the correct status
independent of whether the change
came from the manual status board or
via a change by the browser. The
write command to the serial port of
the SitePlayer is similar to the read
command, as you can see here:

081h, 0xxh, 0yyh, 0zzh

where

0xxh is the address of the first

SiteObject, and

0yyh and 0zzh are

the data values to replace. I’ve defined
the SiteObjects so the message status
(

messagex) byte follows the in/out

status (

herex) byte for each employ-

ee. This allows a 2-byte read or write
to be used for consecutive addresses.

Figure 1a—

The PIC enables LEDs as it scans push buttons. In addition, the micro must communicate with the SitePlayer, which plugs into the circuit via JP2 and JP3.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

SiteObjects in the RAM are also avail-
able to external circuitry via an
onboard serial port. This allows an
external application to access and
even modify the SiteObjects.

A low-cost development kit con-

tains all the necessary components to
fully prepare the SitePlayer for your
application. Sample web sites includ-
ed with the kit demonstrate its versa-
tility without having to add any addi-
tional hardware. Although a browser
is adequate for many applications, the
SitePlayer can communicate with any
TCP/IP application (e.g., Visual Basic).

LAST WORD

I can already think of improvements

for this project. I’d like to give the user
the ability to place live messages in the
system. Maybe give the system the
ability to send a message to a specific
user’s computer, either as a pop-up or
e-mail. I think the next step is to
investigate a personnel-tracking sys-
tem, which might locate an employee

within the facility. In which case, “Is
there anyone really here?” may
become “Where exactly are you?”

An in/out status byte of nonzero

indicates an in status and enables the
green LED. And a zero byte indicates
an out status and enables the red
LED. A nonzero message status byte
indicates a message is waiting.

A counter is enabled to indicate a

message is waiting. The counter tog-
gles a blink flag on decrement to zero.
The appropriate LED is then enabled
and disabled based on the blink flag
alternating at a slow rate of ~1 s.
Because the message status is inde-
pendent of the in/out status, message
indication is legal for employees who
are either in or out.

IN A NUT SHELL

The SitePlayer is a complete

Ethernet web server that, when
attached to a LAN, can send and
retrieve data via a LAN to any com-
puter running a standard Internet
browser. Dynamic data (SiteObjects)
can be displayed as text or graphical
icons within the web pages. The

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@circuitcel-
lar.com.

SOFTWARE

SitePlayer SP1
NetMedia Inc.
(520) 544-4567
www.siteplayer.com

SOURCES

PIC16F874
Microchip Technology Inc.
(602) 792-7200
www.microchip.com

Figure 1b—Here’s how the new electronic messaging system is accomplished. A row and six column signals (along with six push button inputs) may be multiplexed to enable
six LEDs and six push buttons. There are two of each per employee.

CIRCUIT CELLAR

www.circuitcellar.com

s I headed out

the door to the

2001 Embedded

Internet Conference, I

must say I was concerned about what
I might find on arrival. It’s no secret
the dot.bomb has hit hard, and it’s not
just the here-today, gone-tomorrow,
loft-dwelling start-ups. How about
WebVan, with $1 billion down the
tubes, and cable provider At Home
burning through cash at an astound-
ing $100 million-plus a month?

I’ve taken some comfort from the

fact that the traditional embedded
markets—industrial, automotive, con-
sumer, and so on—are far removed
from the crash-and-burn dot.com sec-
tor. Nevertheless, when literally bil-
lions of dollars disappear overnight,
the ripples are felt throughout the
entire food chain.

I suppose I wouldn’t have been sur-

prised if the conference was canceled.
Fortunately for all of us in the embed-
ded world, that wasn’t the case. It’s no
secret that the trade show business is
hurting. So, I’d say that the mere fact
the lights were on has to be consid-
ered as a positive.

Although it includes “Internet,”

now a curse word amongst the VCs
sipping espresso in their suddenly

affordable offices on Sand Hill Road,
the “Embedded” in EIC makes all the
difference. Notwithstanding the
Internet time trend, nothing—good or
bad—happens overnight in the
embedded world. Furthermore,
embedded outfits traditionally adhere
to quaint concepts like a company
should actually make something that
works and sell it for more than it
cost to make it.

By virtue of organizing a conference

session I was able to get up close and
personal with some of the key play-
ers. Despite all the turmoil, I’d say
progress is proceeding apace in
Embedded time terms. Check it out
and see if you don’t agree.

GROSS NETWORKING PRODUCT

The title of my session was

“Towards the $10 Web Connection.”
My thought is that the rate of adop-
tion and pervasiveness of embedded
Internet gadgets is pretty much an
Econ 101 situation. The cheaper it is
to incorporate connectivity features in
embedded products, the more design-
ers will and the faster they’ll do it.

Actually, when setting up the ses-

sion, the conference organizers had
suggested “Towards the $1 Web
Connection.” That title certainly has
a ring to it, but $10 is a much more
practical yet still aggressive target.
Indeed, in terms of silicon that han-
dles networking protocols, we’re get-
ting darn close. Choices are no longer
limited to a 32-bit desktop-computer-
in-drag with a big league OS and
megs of memory.

But one of the helpful lessons

learned in the session is that there are
other important cost factors that are
easy to overlook. Most obvious is
bridging the ultimate digital divide
between a web-savvy gadget and the
Internet itself. Chip suppliers like
iReady, Microchip, Ubicom, and
Rabbit have done an admirable job
delivering low-cost silicon, so much
so that the cost of making the physi-
cal connection looms ever larger.

Right now, the entry-level connect

options are pretty much limited to a
modem or Ethernet link. The silicon
wizards can suck much of that func-
tionality into their chips (e.g., modem

Tom Cantrell

Ready, Steady, Go

SILICON
UPDATE

Despite
the recent
dot.bomb
economic
trend,

when it comes to
“embedded Internet,”
it’s business as usual.
Tom’s trip to the 2001
EIC resulted in assur-
ance that the world of
embedded continues
to move forward.

Issue 137 December 2001

www.circuitcellar.com

CIRCUIT CELLAR

data pump or Ethernet MAC), but
there’s still a cost for the magnetics
and connectors to jack-in.

There are other alternatives on the

horizon with wireless options leading
the pack. Radio is all the rage with
802.11 ramping quickly and Bluetooth
ostensibly close behind. I also learned
powerline communications may final-
ly shed its oxymoronic X-10 legacy
with the emergence of HomePlug.

If embedded Internet lesson one is,

“don’t forget the connection,” a corol-
lary is to “take advantage of an exist-
ing connection.” It’s no coincidence
that communications gear (modems,
routers, and such) is among the first
to exploit ’Net-enabling for mainte-
nance, upgrades, and so on.

Also easy to overlook is

the fact that all these
Internet gadgets need an
ISP just like any other web
surfer. Whether handled
in-house or purchased,
there’s a cost in addition
to key security and relia-
bility issues to think about.

POTS PARTY

Connect One was one of

the first to deliver a think-
ing-outside-the-box
embedded Internet solu-
tion with their iModem
(for background details on
iModem, see my article
“EZ-Mail Engine,” Circuit
Cellar

115). Add a phone

line and a few lines of
code and voila`, instant
embedded Internet.

I suppose they must be both flat-

tered and concerned with the arrival
of similar units from Cermetek,
iReady, and eDevices (see Photos 1a
and b). Like the Connect One unit,
these all easily drop into existing
applications, masquerading as a tradi-
tional modem right down to psuedo-
AT commands.

Phone lines generally aren’t suitable

for always-on apps, and don’t forget
paying your local Ma Bell for the priv-
ilege. Furthermore, it’s always a has-
sle to deal with regulatory concerns
and technical foibles of different
countries phone systems. At the same
time, I think there are many remote
monitoring, diagnosis, and upgrade
applications for which a call every
now and then will more than suffice.

Even as I speak there’s a repair fel-

low from Sears investigating some
suspicious activity by our new refrig-
erator. Sure enough it turns out
there’s a cooling fan that’s not kicking
in when it’s supposed to. Of course,
now they have to order the spare part
and come back again to fix it later.

I’m not one of those people who

need a web-enabled refrigerator that
buys stuff for me or tattles on my
dietary habits. But I could certainly
see how plugging in a phone line tem-
porarily and punching a Service but-

ton beats sending out repair trucks
needlessly. There are big bucks to be
made by eliminating the myriad of
such duplicate and false service calls,
as well as turning emergency calls
into scheduled ones.

KEEP IT SIMPLE

I don’t know if anybody’s figured

out the literal cost of head scratching.
Maybe in a macroeconomics sense it
can be derived as some fraction of the
dollars spent for Grecian formula.

In any case, the last thing you need

is to get buried in the complexity that
surrounds networking as a whole. It’s
not germane to the task at hand and
everybody’s got plenty to think about
just getting the non-networking por-
tions of their applications squared
away. You want to send an e-mail,
and the next thing you know you’re
trudging through an alphabet soup of
protocols and reams of software.

Give Cermetek credit for staying

focused on the goal. With their parts
(see Figure 1), sending an e-mail can
be as simple as toggling a pin. They
even include a programmed ISP
account and password.

SOFT VS. HARD

If there’s one thing most suppliers

agree on, it’s that handling the net-

work protocols in software
is preferable to handling
them in hardware. Of
course, that’s no surprise,
considering that until
recently everyone (with the
notable exception of
iReady) was relying on
software stacks. As they
say, where you stand (i.e.,
what you advocate) is usu-
ally where you sit (i.e.,
what you’re selling).

More action is brewing

on the hardware stack front
though, with new suppliers
coming out of the wood-
work and getting ready to
launch products. I’ll defi-
nitely take a closer look as
details become available.

As usual when consider-

ing the hardware versus
software option, key trade-

Issue 137 December 2001

Photo 1—Both iReady (a) and eDevices (b) have
introduced second generation Internet modems that
combine network stack, modem, and easy-to-use com-
mand language on a single module.

Figure 1—

Like other Internet modem modules, the Cermetek iNet can accept high-

level commands from a host via a serial interface. However, in addition, sending an e-
mail can be as simple as toggling a pin, further easing retrofit into existing applications
and perhaps eliminating the need for any design changes or new software.

Modem

Modem interface

DAA

Serial

interface

V-24

BA-232-E

UART

Flash

ROM

Network protocols

POP3

SMTP

TCP

PPP

INPUT

SENSE

and

OUTPUT

pins

Interface

circuitry

RXD

RTS

DCD
DSR

CTS

TXD
DTR

E-mail

accepted

INPUT IN

INPUT 2

INPUT 1

Send E-mail

control

Tip

Ring

PSTN

RST SPK

+5 V

GND

...

Microprocessor

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

offs include flexibility versus efficien-
cy and performance. For instance, the
software stack provided by Rabbit
Semiconductor with their Ethernet-
based designs includes plenty of pro-
tocols: TCP, UDP, DNS, DHCP,
HTTP, FTP, SMTP, POP3, TFTP, seri-
al-to-Telnet gateway, PPP, and
PPPOE. [1] Don’t need them all? Cut
and paste to your heart’s content
because Rabbit not only wrote the stack
themselves, but delivers the source

code as well. Just
remember the KISS
comments above and
understand that fid-
dling with the innards
of a networking stack
isn’t something for
the faint of heart.

On the other hand,

recognize that an 8-bit
micro is typically
only going to be able
to deliver one or two

megabits per second
through a software
stack. That isn’t an

issue if you’re just sending a few
bytes of data via a 2400-bps modem
from time to time. On the other hand,
stack performance could be a critical
factor for a streaming A/V over
Ethernet application.

ARE WE THERE YET?

When you consider all the compo-

nents required and various soft costs,
the short answer is that the $10 web
connection isn’t quite a reality yet.

But we’re getting darn close. I’d say
you’re looking at something closer to
$20 in volume. Keep in mind though
that all the quotes are speculative
until high volume applications start
hitting the street.

For example, a press release from

Analog Devices states prices for their
DSP-based, single-chip modem with
the eDevices SmartStack TCP/IP
stack, software, licenses, and a two-
chip silicon DAA begin at $18.50 in
quantities of 10,000.

Rabbit Semiconductor sells their

Ethernet core module for $34 in quan-
tities of 1000, but points out that the
raw component BOM (i.e., CPU,
Ethernet chip, Ethernet magnetics,
connector, and memory) is less than
$20 at of quantities 25,000. Expect
the story to be about the same for the
other 8-bit MCU-based solutions from
Microchip and Ubicom.

Meanwhile, the NetMedia Site-

Player, based on a Philips ’51, takes
the quantity one pricing prize at $30,
though you’ve got to add your own
Ethernet magnetics and connector.
The SitePlayer is shown in Photo 2.

YOUR MOVE

There are a few things to keep in

mind while you’re window shopping
and contemplating your next move.
First, whatever the actual number, an
embedded Internet price floor will
eventually emerge. Silicon can work
miracles, but coming up with the
mythical free lunch isn’t one of them.
Instead, much as we’ve seen in the PC
market, at a certain point the trend
will be to start adding features rather
than cutting price (see Figure 2). [2]

Figure 2—After volume pricing is achieved, attention will turn to adding fea-
tures such as network physical interface and protocols, easier to use software,
and higher performance

. [2]

1.5

Years

3.0

$15

$10

$25

$35

Cost

Cost:
Features:

Photo 2—For silicon, quantity drives price. It’s difficult
to say when the $10 web connection will be realized,
but the $30 price tag for one Netmedia SitePlayer
bodes well for the future.

Issue 137 December 2001

CIRCUIT CELLAR

www.circuitcellar.com

SOURCES

Cermetek Microelectronics, Inc.
(800) 882-6271
(408) 752-5000
Fax: (408) 752-5004
www.cermetek.com

Connect One Semiconductors, Inc.
(408) 986-9602
Fax: (408) 986-9604
www.connectone.com

Tom Cantrell has been working on
chip, board, and systems design and
marketing for several years. You may

and 4 additional questions and
answers are posted at
www.circuitcellar.com
You may contact the quizmasters
at eq@circuitcellar.com

So, is it time to take the plunge and

decide to Internet-enable your embed-
ded design? Or is it better to wait for
the next round of chips and price
cuts? There’s no simple or single right
answer. The point is that each step on
the price/performance ramp enables a
new class of designs.

However, my take is that price is no

longer the daunting barrier for many
potential apps that it’s traditionally
been. Furthermore, given the long lead
and lifetimes of embedded designs, it
will be even less an issue by the time
the next generation of ’Net-savvy
products reaches full production.

If you’re even thinking there’s a

chance your design might be a candi-
date for upgrading with Internet fea-
tures, you’re probably right, and you
should probably get started doing
something about it right away.

REFERENCES

[1] O. Magee, Rabbit Semicon-

ductor, “Towards the $10
Internet Device,” Paper presented
at Embedded Internet
Conference 2001, August 14–16,
2001.

[2] H. Roskos, Cermetek, “Towards

a Sub-$10 iNET Appliance,”
Paper presented at Embedded
Internet Conference 2001,
August 14–16, 2001.

reach him by e-mail at tom.cantrell@
circuitcellar.com.

more EQ

questions

each month in

Circuit Cellar Online

Problem 1

—One of the problems with

converting a month-day into day-of-year
is the variable number of days in the
months, as shown in the following table:

There’s a relatively simple mathematical
expression (involving integer division)
that gives these numbers without using a
lookup table. What is it?

Contributed by David Tweed

Problem 2

—There’s one other value that’s

easy to find if you have the zeller() function
defined in Problem 1. What is it?

Contributed by David Tweed

Problem 3

—Building on the function devel-

oped in Problem 2, how can you calculate

the number of days between arbitrary

dates?

Contributed by David Tweed

eDevice, Inc.
(212) 856-0000
Fax: (212) 856-9339
www.edevice.com

HomePlug
(925) 275-6630
Fax: (925) 275-6691
www.homeplug.org

iReady Corp.
(408) 330-9450
Fax: (408) 330-9451
iready.org

Microchip Technology Inc.
(480) 786-7200
Fax: (480) 899-9210
www.microchip.com

NetMedia, Inc.
(520) 544-4567
Fax: (520) 544-0800
www.siteplayer.com

Rabbit Semiconductor
(530) 757-8400
Fax: (530) 757-8402
www.rabbitsemiconductor.com

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec

www.circuitcellar.com

CIRCUIT CELLAR

Issue 137 December 2001

51 East Campbell Ave

Campbell, CA 95008

....by using real-time emulators.

888-886-6428

Support for:

HC12, HC11
8051
C166
C500
ST10
Super10
Philips XA
68300 family
Ubicom

Scenix

"Nohau emulators show you what is really going
on inside your embedded system. Turn yourself
into a debugging expert and find bugs

” info see www.nohau.com/howto

408-866-1820

Insert-ready sub-mini SBCs (small as 47x55 mm.) supporting the
Philips

achieved via GND circuitry, 6 to 8 layer PCB, by-

pass capacitor grid and short signal traces achieved via small
footprint and use of 0402 SMD passive components

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

RS-232, RS-485, I

Controller signals extend to standard (2.54 mm.) or high-density
Molex (0.625 mm.) header pins on two sides of the board,
allowing the SBC to be plugged like a "big chip" into targets