circuit cellar2001 05

www.abidata.be for details.

PARALLEL PORT VERSION

NEW - PCI VERSION!

RS232 <> USB easily!!

DrDAQ plugs into a PC for useful
datalogging at school, college,
industry. Built-in sensors for light,
sound, temp. or add pH sensor and
run one of the many

power & information on 2-wires!

CANbus

Starter Packs

Boards for PCI/ISA/PCMCIA/PC104/VME/compPCI

Drivers for WIn95/98/NT,VxWORKS, pSOS, Lynx,

Linux, OLE, HPVee, LabView, etc.

DrDAQ

Educational

Datalogger

built-in sensors!

www.drdaq.com

Customer list inc: Intel,

Compaq, Philips, NEC,

Kodak, Nokia, US military,

Microsoft, Dell, Xerox,

universities, T.I., Lucent,

Dalsa,

Harris, Litton,

Sony, J&J, Thomson, etc.

new!

Issue 130 May 2001

CIRCUIT CELLAR

www.circuitcellar.com

nize the micro-
controller with
the DDS chip.

The TTL I/O

signals (Keying,
Square Output,
FSK/PSK, and
so on) are
buffered and
shifted to stan-
dard TTL levels
by Philips’
74LVT245 (U6).
These 3.3-V
transceivers
have 5-V, TTL-
compatible I/O
signals and an
impressive 2.4-
ns propagation
delay. Last but
not least, a
small
TL7705ACP pro-
vides a clean
reset pulse to
the DDS chip and microcontroller.

The main microcontroller is an

87LPC764, interfaced to the DDS chip
through 5-to-3.3-V converters. For
more information, check out the
datasheet. [2] The microcontroller is
clocked from the main 20-MHz sys-
tem clock. Its I

C port is used to con-

trol the user interface and plug-in
boards. The UART is configured as an
SPI controller, and drives the DDS,
external A/D converter, and plug-in
boards with distinct chip selects.

The last part of the design is the

analog stuff (see Figure 6), which is
the difficult part for firmware-orient-
ed types. To work with frequencies
above 100 MHz you need experience.

First of all, each complementary

output of the main DAC is fed
through a passive 120-MHz elliptic
filter to get out of the band frequen-
cies. I borrowed the filter design from
Analog Devices. [1] I modified the coil
values to be integer multiples of a sin-
gle value (just try to buy eight differ-
ent SMD coil values in small quanti-
ties and you’ll understand why I did it
that way). I checked the frequency
response, which still looked good (see
Photo 1). The two complementary
and filtered sine waves go back to the

AD9852’s internal high-speed com-
parator to generate the square output.

For the analog output, a pair of

high-frequency relays selects either
the sinus output (one of the two fil-
tered signals from the AD9852 DACs)
or the output of one of the plug-ins’
slots. The selected signal is amplified
and DC is offset by an AD8002 high-
speed current amplifier.

This amplifier has a gain bandwidth

of 600 MHz at –3 dB and provides 0.1-
dB flatness from 0 to 60 MHz. That
isn’t perfect for this application, but
it’s a good performance versus price
trade-off. Moreover, the 1200-V/µs
slew rate makes it adequate for your
pulse generator applications.

Last, the exter-

nal modulation
input (used for
AM/FM/PM
modes) is first
scaled and DC off-
set by a standard

LM324 (U14) in order to give a 0- to
5-V signal from the ±5-V input. This
signal is then fed into a small TI
TLV1572. This 10-bit A/D converter
is serially connected to the microcon-
troller through the shared SPI bus.

PROTOTYPE CONSTRUCTION

All but the user interface fits on a

7.4

″

× 6.7

″,

double-sided PCB, includ-

ing the power supply and its trans-
former (see Photo 2). The user inter-
face is mounted behind the front
panel. The high-frequency analog
parts are EMC-protected by a metallic
can (see Photo 3).

In order to maximize performance,

all high-frequency components are

Photo 1—

A simulation of

the transfer function of the
150-MHz low-pass filter
shows a 70-dB rejection
above cutoff frequency. This
simulation was done using
SpiceAge software.

Figure 6—

In the analog section, two

150-MHz elliptic passive filters elimi-
nate unwanted harmonics from the
DDS chip outputs. A pair of high-fre-
quency relays selects the relevant sig-
nal and directs it to an integrated high-
frequency amplifier (AD8002).

Issue 130 May 2001

CIRCUIT CELLAR

www.circuitcellar.com

Photo 2—

The DDS-GEN prototype shows that the

C-MMI board is behind the front panel. The main

transformer and filtered power plug are in the back.
The power supply components are in the back right
corner and the plug-in slots are visible in the front right
corner. The high-frequency parts are to the left
between the front panel plugs and transformer.

surface-mounted. And, a large ground
plane is integrated on both sides of
the PCB (an analog ground plane on
the topside for the HF areas and a dig-
ital ground plane on the bottom for
the digital parts). But, a full four-layer
PCB is a must. A metallic enclosure
and a filtering power socket are also
mandatory to limit the spurious emis-
sions and meet UL/CE specifications.

ON THE SOFTWARE SIDE

The complete listing of DDS-GEN

software is on the Circuit Cellar web
site. Like the I

C-MMI software, this

code is mainly written in C, thanks
again to the good freeware SDCC-
optimizing cross-compiler. Some in-
line assembler code is used, however,
mainly for interrupt handling routines
and code-space optimization.

And, as always, I check the Internet

to see if what I need is already out
there. I used, without modification,
the C code I

C handler library written

by Sandeep Dutta (thanks, Sandeep!)
and interrupt-handling code from the
SDCC accompanying files. [3]

The dynamic structure of the DDS-

GEN embedded software is classic
(field-proven) and interrupt-driven (see
Figure 7). After initializations, the
main program manages the user inter-
face and stores all parameters that
need to be loaded into the DDS chip
in a shared RAM buffer.

The interrupt routine, executed

each time the DDS chip asks for new
values with its “I/O update” signal,

executes an A/D conversion of the
external modulation signal. And if a
modulation is requested, it recalcu-
lates the frequency, amplitude, and
phase on the fly. It then uploads the
modified parameters into the DDS
chip one block at a time to limit
interrupt latency.

In order to define a precise interrupt

frequency, the DDS chip is pro-
grammed in Internal Update mode. In
Internal Update mode, the update of
its internal registers is automatic and
executed at a preprogrammed refresh
rate. The I/O update signal is an out-
put that generates an interrupt on the
microcontroller.

The shared RAM buffer maps exact-

ly the AD9852 register set. This array
is then segmented in blocks, corre-
sponding to the AD9852 serial trans-
fer blocks; each block is the set of
parameters that should be down-
loaded in one individual operation.
Every time a parameter change is
needed, the relevant registers are
updated by the main program in the
shadow array and a flag is sent to
indicate that the corresponding block
must be downloaded to the DDS chip
during the next interrupt.

DDS-GEN menus are managed by

a generic software menu engine,
which is based on a table of menu
targets stored in ROM. Each menu
target corresponds to a specific LCD
mask, and defines the static text to
be displayed and the numerical for-
mat of the value to be edited (num-
ber of digits before and after the dec-
imal). Each menu target also defines
a pointer to a pre-processing proce-
dure (

func_enterxxx). This procedure

is usually in charge of converting
the value to be edited from internal
to human form.

And, lastly, it defines a pointer to

a post-processing procedure
(

func_selectxxx). This procedure

usually controls conversion of the
value just edited from human to
internal form and updates the shad-
ow DDS parameter array in RAM.

The main menu engine is straight-

forward. Thanks to the onboard
intelligence of the I

C-MMI periph-

eral module, every value displayed
can be modified with the keyboard,

rotary encoder, or from a host com-
puter connected to the serial port
without specific code in the applica-
tion software.

DESIGN METHODOLOGY

As I explained in Part 1 last month,

I prefer spending time doing simula-
tion steps rather than burning a zil-
lion OTP chips. In order to get the
DDS-GEN working as quickly as pos-
sible, I settled on the following four
development steps:

Step 1: The full main program was

developed and simulated on my PC
under Bill’s classic Visual C++ envi-
ronment. The I

C-MMI peripheral was

fully simulated with software rou-
tines and the shadow DDS register
parameters were displayed with the
debugger as required. This step
allowed me to debug all of the user
interface and menu software (80% of
the total code) without having to get
onto the target chip;

Step 2: An emulation of the inter-

rupt handling code was developed in
C, and the target DDS chip was con-
nected to the PC through a hacked
LPT parallel port. This step was like a
homemade ICE (on the hardware side,
no more than a DB25-to-87LPC764
socket and some C lines), and allowed
me to fully debug the DDS chip regis-
ter issues (register mapping, trunca-
tion errors, etc.);

Photo 3—

The AD9852 is under the big heatsink, a

converted TO3. The shield that holds the two high-fre-
quency filters (with their 20 CMS coils) and the AD8002
amplifier are on the top side. On the bottom, you can
see the two 74LVT245 buffers and the 87LPC764. The
two metallic components left of the transformer are the
high-frequency relays.

Robert Lacoste lives near Paris,
France. He has 10 years of experience
in real-time software, embedded sys-
tem developments, and now business
management. He still loves building
innovative, microcontroller-based
devices after hours. Currently, he
works for Nortel Networks. You can
reach him at robert_lacoste@yahoo.fr.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 130 May 2001

Step 3: The specific target code was

added (mainly I

C-related stuff), the

interrupt routine was optimized, and
everything was cross-compiled to the
target 87LPC764. Then, everything
was debugged on the target;

Step 4: This step wasn’t planned,

but I had a memory space issue. The
first cross compilation ended with a
RAM and ROM requirement about
twice as large as 87LPC764 chip capa-
bility. A full iteration from Step 1 and
a lot of simplifications and optimiza-
tion were needed.

WHAT’S NEXT?

It wasn’t easy, but the DDS-GEN

prototype works (see Photo 4). The
hardware worked 99% flawlessly dur-
ing the first run, even if I still have
HF unwanted cross-talk and occasion-
ally a microcontroller randomly resets
at HF output. A new four-layer PCB
probably will be required to solve
them. The software still needs work,
mainly on the AM/FM/PM code,

which is crude because of lacking
space. And, I still have a list of left-
over bugs taped on the prototype.

Soon, I want to build an arbitrary

signal generator plug-in that will dra-
matically extend the possibilities of
the DDS-GEN. Basically, this board
will include another 87LPC764, I

EEPROM to store waveforms, cache
RAM chip, some kind of EPLD, and a
DAC. I also have firmware extensions
in mind, like an integrated, 1-kHz
pseudo-sinus modulation generator.

Well, I have some interesting nights

ahead, unless Circuit Cellar readers
want to take over part of the job…

Start

Initialization

Display current

menu entry and value

Wait for a user

action (new value)

Update DDS

parameters

Select the new

menu entry

DDS

parameter

and current

mode

I/O Update

interrupt

Modulation?

Get an ADC value
and calculate new

frequency, amplitude, and phase

New DDS

parameters?

Download first modified

parameter block to DDS

RTI

Photo 4—

The DDS-GEN generated these examples.

(a)

is a ramped 300- to 1200-Hz FSK signal with a 3.6-ms ramp time.

(b)

is a 200-kHz signal with 90° PSK modulation.

Finally,

(c)

is a 5-kHz signal in Shaped Keying mode with a 0.6-ms ramp up/down delay.

Figure 7—

A main program

waits for a user event, man-
ages menus, and updates a
parameter array in shared
memory. And, an interrupt
routine refreshes the DDS
chip registers and manages
modulation tasks.

REFERENCES

[1] Analog Devices, Inc., “CMOS

300 MSPS Complete-DDS,” 1999.

[2] Philips Semiconductors, “Low

power, low price, low pin count
(20 pin) microcontroller with 4
kbyte OTP,” January 8, 2001.

[3] S. Dutta, “Anatomy of a

Compiler: A Retargetable ANSI-C
Compiler,” Circuit Cellar 121,
August 2000.

SOURCES

AD9852
Analog Devices, Inc.
(800) 262-5643
(781) 329-4700
www.analog.com

Visual C++
Microsoft Corp.
(425) 882-8080
www.microsoft.com

87LPC764, 74LVT245
Philips Semiconductors
(212) 536-0500
Fax: (212) 536-0559
www.philips.com

TL7705ACP, TLV1572
Texas Instruments, Inc.
(800) 336-5236
www.ti.com

SOFTWARE

The source code is available on the
Circuit Cellar

web site. This code is

copyrighted but can be used freely
without any guarantee, as long as
it’s not included in any commercial-
ly sold product.

Issue 130 May 2001

CIRCUIT CELLAR

www.circuitcellar.com

hen designing a

control algorithm

and analyzing its per-

formance, it is often

helpful to develop a software simula-
tion of the plant. The usual method is
to describe the plant by a set of first-
and second-order differential equa-
tions that are translated to discrete
time difference equations and solved
iteratively. These equations are usual-
ly based on idealized rather than real-
world physical behavior. It is possible
(but difficult) to model nonideal real-
world effects mathematically, but at
the cost of greatly increasing the com-
plexity of the model.

Another simulation method you

can use is to develop a behavioral
model of the plant. In this type of
model, the physical states of the sys-
tem’s components and resulting
behavior are directly represented and
computed iteratively at discrete time
increments, or time slices.

It is simple to modify the simula-

tion for different component charac-
teristics and nonideal effects to chal-
lenge the robustness of the controller
algorithm. You’ll find that it is also
simple to model mechanical and elec-
trical fault conditions. A stuck valve,
empty tank, or incorrect flowmeter

measurement can be easily simulated
to test the controlling software’s fault
handling.

The example I present here is a

simple fluid rate control system con-
sisting of a pump or pressurized tank
and a fluid line with a control valve,
cutoff valve, and flowmeter (see
Figure 1). The intent of this article is
not to show how to design a con-
troller for such a system, but to
demonstrate some of the techniques
and concepts of behavioral simulation
using this system as an example.

GENERAL SIMULATION

PRINCIPLES

Any computer-based simulation of

physical behavior is necessarily a dis-
crete time, discrete value approxima-
tion of a continuous time, real value
process, so unavoidably there will be
sources of inaccuracy in the simula-
tion. The first source of error is
numerical—the round-off and quanti-
zation error caused by using discrete
(not necessarily integer) numbers to
represent physical quantities.

Another source of error comes from

approximating physical continuous
time behavior with discrete time
models. It is a tacit assumption that
the physical process being approxi-
mated linearly interpolates between
two simulation times. (Interpolation
doesn’t have to be linear, but that’s
the simplest way.) That assumption
will not be correct to an infinite level
of precision, but the error can be
reduced to a negligible amount with
the appropriate time increment.

A more pernicious source of error is

what is known in chaos theory as sen-
sitive dependence on initial condi-
tions. In a complex set of higher order
nonlinear difference equations, two
slightly different initial conditions
lead to divergent results in the future,
and both diverge from the physical
process they represent. This prevents
the three-body gravitational problem
from being solvable numerically for
an arbitrarily long length of time, and
also makes weather impossible to pre-
dict more than a few days in advance.

In the types of systems normally

controlled by embedded processors or
simple control algorithms, mathemat-

FEATURE
ARTICLE

Simulation can be a

great tool for analyz-

ing performance.

However, unless you

follow some basic

principles, your model

can become too sim-

ple to reflect real-

world behaviors or too

complex to be practi-

cal. As youll see,

somewhere in

between is just right.

Kenneth Baker

Behavioral Plant

Simulation for Testing a

Control Algorithm

www.circuitcellar.com

CIRCUIT CELLAR

Issue 130 May 2001

ical chaotic behavior
isn’t a problem unless
the controller fails to
control. However, in a
large, complex system
with many compo-
nents, such as a large
automated manufac-
turing process or
power grid, it may
become a problem.
These systems require
far more sophisticated
simulation techniques
and are, as we have
read so often in textbooks and jour-
nals, beyond the scope of this article.

The first two questions to be

addressed are: How should physical
variables be represented and what
should the simulation time increment
be? A non-real-time simulation is not
computationally constrained by exe-
cution time and processor power, as is
often the case with an embedded con-
trol algorithm. Therefore, you are free
to use any data types and mathemati-
cal functions available.

Physical phenomena typically do

not take integer values, so the obvi-
ous choice is to use floating point for
all variables representing physical
states. Single precision is probably
sufficient for most cases to reduce the
quantization and round-off errors to a
negligible amount.

In order to minimize the time quan-

tization error the time increment
should be smaller than both the
shortest time constants in the system
and the sample period of the control
algorithm. In the system described
here, the time constants are in the
order of hundreds of milliseconds and
the controller sample period will be
100 ms. A simulation time increment
of 1 ms is two orders of magnitude
smaller so it’s a good choice.

In the following sections, I will

describe the simulation algorithms for
the individual components and then
show you how they piece together
and link to the control algorithm.

THE CONTROL VALVE

The rate control valve is the most

complex component with respect to
simulation in this system. In this

simulation, the valve is assumed to be
a butterfly valve with mechanical
stops at the fully open and fully
closed positions with 90° of motion.
The valve motor controls are PWM
DC signals that turn the valve plate
one way or the other at a constant
speed. At fully open, the plate is par-
allel to the pipe. A cross section of
the valve is shown in Figure 2.

The plate has to turn a few degrees

from the fully closed position before
an orifice opens. If the plate turns less
than this, fluid flow stops except for a
small amount of leakage caused by an
imperfect control valve seal. Two
other minor effects to note are the
starting and stopping delays for the
plate motion.

When power is applied it usually

takes a few milliseconds before
motion actually starts. Likewise,
when power is removed, inertia keeps
the valve moving for a few more mil-
liseconds. These two effects can be
important if the controller is trying to
make fine adjustments with short
pulses. For example, if the power
pulse is too short, the valve may not
move at all or the inertia may make it
move a little too far.

Valve motion is simulated by func-

tion

sim_valve() found in file valve.c.

The parameters of this function are
the valve number, or id, and the con-
trol command. The control command
tells the valve to open, close, or stop.
All of the local state and parameter
variables in file

valve.c are arrays

that the valve number indexes into.
This allows one function to simulate
any number of similar valves, which
have the same general properties but

may have different
characteristics and,
more importantly, can
be in different states. In
this project, I’m using
the same function to
simulate both the con-
trol valve and the shut-
off valve even though
they have different
characteristics.

The logical structure

sim_valve() is sim-

ple. It is to be called at
each time slice for each

valve, and it opens, closes, or stops
the valve, depending on the control
parameter and whether it needs to
delay or has a fault. The amount it
turns is defined by the valve rotation
parameter

prm_valve_rotation. This

parameter indicates how many
degrees the valve plate turns in one
time slice. If a valve takes 750 ms to
turn 90° from fully closed to fully
open or vice versa and the time slice
is 1 ms, then the valve rotation is
90

°/750 ms, or 0.12° ms. In this simu-

lation, the valve opens and closes at
the same speed. But, that doesn’t have
to be the case; the function easily can
be modified to provide separate
parameters for each direction.

After the valve plate position is set,

the resulting valve orifice is calculat-
ed. Because there are no assumptions
about the size of the valve at this
point, the orifice value is normalized
to 1.0 at the fully open position. At
some point during the simulation,
this normalized value (and others
described later) will have to relate to
an actual physical value. That will
come together when the simulation is
integrated with the control algorithm.

The calculation of the orifice is

based on the geometry of the valve, as
shown in Figure 2. Some valves have
a small amount of leakage when the
valve is nearly closed, and this leak-
age is represented as a fraction of the
normalized fully open orifice.

The important point here is not the

exact area of the valve opening at a
particular valve position. Rather, it is
the fact that the orifice, and thus flow
rate, are nonlinear functions of the
valve position. Some types of valves

Fluid flow

Pump or

pressurized

tank

Flowmeter

Control

valve

Cutoff

valve

Nozzle

Controller

Figure 1In a simple fluid dispensing system, the flowmeter and a control valve close the feed-

back loop with the controller. The cutoff valve operates in Switching mode, either fully open or

closed with no leakage.

Issue 130 May 2001

CIRCUIT CELLAR

www.circuitcellar.com

are more linear and others,
such as ball valves, are high-
ly nonlinear. Consequently,
a control algorithm that
assumes a linear plant
response will control with
different degrees of effective-
ness depending on the valve
position.

In this model, it appears

that many assumptions
about general behavior and
estimates of likely parame-
ter values were tossed out
without validation, but the general
behavior is justifiable on physical
principles. Typical valves do indeed
rotate at nearly constant speeds. Valve
motion cannot start nor stop instanta-
neously because of friction, momen-
tum, or capacitive and inductive
delays in the motor windings.

As for the parameter values, none of

the valve characteristics in this model
need to be known exactly for the sim-
ulation to be useful. Obviously closer
is better. If you have good ballpark
estimates, many simulations are exe-
cuted with different combinations and
ranges of parameters, and the control
algorithm is effective in simulation,
then you can be confident that the
algorithm will be robust enough to
perform acceptably regardless of the
physical parameters.

THE CUTOFF VALVE

The cutoff valve, as I stated earlier,

uses the same simulation code as the
control valve but with a different set
of parameters. Most importantly the
cutoff valve is assumed to have zero
leakage at the fully closed position,
otherwise it would be useless as a
cutoff valve.

A cutoff valve in a system like this

is also typically faster than the con-
trol valve. However, the cutoff valve
is nearly always fully open or closed,
so within limits the rotation speed is
not critical.

THE FLOWMETER

The flowmeter simulation is sim-

pler than the valve, but is not without
complications. It generates a pulse
train with a frequency proportional to
the fluid velocity. There are two non-

ideal effects modeled here. The first is
the response time. Flowmeters typi-
cally respond quickly to changes in
fluid velocity, but no flowmeter can
respond instantaneously. So, the fre-
quency at each time slice is modeled
as an auto-regressive function of the
previous frequency and the current
fluid velocity scaled by a constant:

f(t) = Awr(t) + (1 – w)f(t – 1)

where f is the frequency, A is a pro-
portionality constant between the
fluid velocity and frequency, and w is
the auto-regressive filter coefficient,
or weighing factor. A large value of w
means the current time slice is more
heavily weighted, causing the flow-
meter to respond faster to a change in
fluid velocity.

The flowmeter response is simulat-

ed by function

sim_flowmeter() in file

flowmtr.c. Like sim_valve(), this
function takes an identifier as a
parameter so that multiple flowme-
ters can be simulated with the same
code, but here only one is used.

The other parameter is the flow

rate, which represents the fluid veloc-
ity. Like the orifice in

sim_valve(),

this flow rate is assumed to be nor-
malized to 1.0 for a value that results
in a frequency numerically equal to
A

. And, this normalized value also

does not yet need to be related to a
physical value.

The second nonideal effect is

caused by both the temporal and
numeric quantization of the frequen-
cy measurement. In a typical embed-
ded system, the frequency of a pulse
train is measured by counting pulses
over a predetermined interval or by

measuring the interval
between two pulses (e.g.,
the pulse accumulator hard-
ware in the 68HC11 series
of microcontrollers).

The pulse accumulator

can either count external
pulses directly or, with the
addition of an external flip-

flip that toggles on every
pulse, can measure the
pulse interval in Gated
Time Accumulation mode.
Both of these functions are

included in

sim_flowmeter().

The problem is figuring out when

the pulses should occur. It is not as
easy as simply inverting the frequen-
cy. For example, if the gated counting
interval is 100 ms and the pulse fre-
quency is 333 Hz (i.e., an interval of
about 3 ms), then the counting period
may contain either 33 or 34 pulses.
This temporal quantization would
cause the calculated frequency to
alternate between 330 and 340 Hz, a
difference of about 3%. If the count-
ing interval were 20 ms, the calculat-
ed frequency would toggle between
300 and 350 Hz.

If this difference is too great for a

given application, a wise control engi-
neer would include some filtering of
the flow rate in the control algorithm
or increase the counting interval. The
tradeoff is increased controller
response time. This simulation would
allow you to determine the counting
interval or filter coefficients that
allow accuracy and response time
requirements to be met.

For the best simulation accuracy,

you have to calculate the times at
which pulses occur with greater preci-
sion than the simulation time incre-
ment. Greater precision is accom-
plished by accumulating the fraction
of the pulse-to-pulse interval that
accrues during each time slice, based
on the instantaneous frequency. For
example, if the current frequency is
200 Hz (5 ms between pulses) and the
time slice is 1 ms, then 20% of the
time between two pulses will elapse
in the current time slice. This incre-
ment is simply the time slice divided
by the pulse period, or in other words,
multiplied by the frequency.

Fully closed position

Fully open position

Minimum open position

min

d = cos(

min

) – cos(

)

Figure 2Check out the butterfly valve geometry and orifice calculation. The plate

rotates a few degrees from fully closed before it reaches the minimum open posi-

tion.

min

is the minimum open position,

q is the valve plate position, and d is the

normalized orifice.

Issue 130 May 2001

CIRCUIT CELLAR

www.circuitcellar.com

This increment is accumulated

until it exceeds 1.0, and concurrently
the elapsed time since the last pulse
is accumulated. When the accumulat-
ed increment exceeds 1.0, it indicates
that a pulse has occurred. Exactly
when the pulse occurred is the accu-

mulated time plus the portion of the
time slice between the previous accu-
mulated increment and 1.0. This con-
cept is confusing even to this humble
author, so I’ll try to make it more
understandable with a concrete
numerical example.

Assume for simplicity a constant

frequency of 230 Hz and a time slice
of 1 ms. During each time slice, the
increment between pulses advances
by 0.23, or 23%, of the way from the
last pulse to the next. After 4 ms, the
accumulated increment is 0.92.
During the next time slice, the accu-
mulated increment advances to 1.15,
meaning a pulse occurred. The exact
time the pulse occurred is calculated
geometrically, as shown in Figure 3,
by:

which is the same as

This time is added to the accumu-

lated time of 0.004 to get 0.004348,
which is the period of 230 Hz. Now,
because the pulse occurred some time
before the current simulation time,
the pulse-to-pulse increment and

Figure 3For

accurate pulse

interval simulation,

flowmeter pulses

may not occur

exactly at the sim-

ulation time slices,

so the pulse times

must be interpo-

lated between

time slices. Right

here, the pulse

frequency (F) is

230 Hz, period (P)

is 1/F = 4.3478

ms, and the simu-

lation time slice

(T) is 1 ms.

T = 1 ms

0.00

0.23

0.92

1.00

0.15

0.38

0.0000

1.0000

4.0000

4.3478

0.6522

1.6522

I = T

= Tf

Pulse

Accumulated

time (ms)

Accumulated

increment

between pulses

Time A: The first pulse occurs and accumulated time and increment are pre-loaded with 0.

Time B: At the next time slice, accumulated time advances by 1 ms and accumulated increment
advances by 0.23, or 23%, of the way to the next pulse.

Time C: At this time slice, accumulated increment advances to 1.15, indicating a pulse occurred.
The time of pulse is 4.000 + t

, which is calculated by

In this example, f = 230, i

= 1.00 – 0.92, and t

= 0.3478 ms. So the pulse occurs 4.3478 ms after

the previous pulse.

Now, the accumulated time is pre-loaded with t

= T – t

= 0.6522 and the accumulated increment

is pre-loaded with i

= I – i

= 0.15.

,which gives

480-837-5200 / fax: 480-837-5300 / info@embeddedx86.com

www.embeddedx86.com

Issue 130 May 2001

CIRCUIT CELLAR

www.circuitcellar.com

accumulated time must be pre-loaded
with values from the pulse that just
occurred to the current time slice so
that the next pulse-to-pulse interval
can be correctly calculated. In the
example used here, the increment is
pre-loaded with 1.15 – 1.00 = 0.15 and
the accumulated time is pre-loaded
with 0.001 – 0.000348 = 0.000652.

This may seem like a lot of work

for little value when the true frequen-
cy of a pulse stream is the inverse of
the period. However, if the controller
uses a poor choice of interval for
accumulating pulses, the results of
this temporal quantization will be
evident in the simulation, and the
problem can be addressed.

One thing to note here is that the

pulse accumulator in the 68HC11 is
only 8 bits, yet this simulation deals
with values larger than 255 bits. How
does this work? The assumption is
that there is an interrupt handler
behind the scenes that correctly han-
dles the pulse accumulator overflow
interrupt and uses it to construct val-
ues larger than 8 bits.

PLANT SIMULATION

The plant simulation is where all of

the component simulations come
together. Function

plant_simulate()

in file

plant.c calls functions to simu-

late the flowmeter, both valves, and
the PWM power supplies for each
valve. The latter behaves like typical
PWM outputs provided on a micro-
controller such as the 68HC11.
plant_simulate() also calls a function
to simulate to fluid flow rate.

All of the component simulations

for a given time slice conceptually
take place simultaneously. Obviously,
they take place sequentially in any
nonconcurrent computer simulation,
so the order in which they occur may
be important. The principle for deter-
mining the order is that a physical
system can’t respond instantaneously
to changing stimuli. This means the
flowmeter does not respond instanta-
neously to flow rate, and the flow rate
does not respond instantaneously to
valve position.

Consequently, the flowmeter must

be simulated before the flow rate is

recalculated so that the current
flowmeter frequency is based on the
flow rate from the previous time slice.
Likewise, the flow rate must be recal-
culated before the valve motion is
simulated. Realistically, however,
when the time slice is several orders
of magnitude smaller than the time
constants of the system, things
change so insignificantly from one
time slice to the next that the order
makes little difference.

Another available approach is to

keep two sets of state variables, one
for the results of the current time
slice and one saved from the previous
time slice. Only the previous vari-
ables are used to calculate the current
results, so the order of simulation is
arbitrary. This is a more theoretically
correct approach, but the resulting
differences should be negligible for a
small time slice.

The flow rate calculation in func-

tion

calculate_flow_rate() is the link

between the valve and flowmeter sim-
ulations. The flow rate, or fluid veloc-
ity, is a function of the two valve ori-

Painless

PCI Bus Designs!

To order, visit our web site or call

1-800-247-6553

FREE! PCI Bus Quick Reference Guide
Visit

www.pcibusdemystified.com

Visit

for the latest technical

books and eBooks on embedded systems design,
wireless telecommunications, DSP, and more!

Your PCI bus designs will be a
breeze with this concise but
comprehensive new guide. You’ll
find up-to-the-minute info on:

Hot Plug and Hot Swap

$49.95 print version
ISBN 1-878707-54-X
Includes CD-ROM

$37.50 downloadable
Deluxe eBook

version also available

Our books are available at

bookstores everywhere.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 130 May 2001

fices and pressure. The pressure vari-
able represents the pressure of the
tank, or pump, feeding the fluid line.
But in this simulation, it is never
linked to a physical quantity because
it is neither measured nor influenced
by the controller.

A factor in the flow rate calculation

proportionately modifies the flow
rate. And, this can be used to make
the flow rate response change over
time. Like the valve orifices, pressure
and flow rate are normalized. When
both orifices are 1.0 and the pressure
is 1.0, the resulting normalized flow
rate is 1.0. For a given pressure, the
flow rate varies with valve orifice the
same way current through a resistor
varies with conductance.

Thus, the equation for fluid rate

through two valves takes the same
form as current through two series
resistors, using conductance rather
than resistance. The equation is
(without the noise term):

where r is the flow rate, p is the pres-
sure, and v

and v

are the valve ori-

fices. A factor of 2 normalizes r to 1
when p, v

, and v

all are 1. Note that

and v

are limited to 1 because the

valves can’t be more than fully open.
But, p is not limited to 1, and there-
fore f is not limited to 1.

A random (actually pseudo-random)

noise term is added to the flow rate
you just calculated. This represents
random variations in the flow rate
caused by turbulence, variations in
the pump output, transient obstruc-
tions at the nozzle, and so on.

During each control time, a new

random number is calculated and the
noise term between control times is
interpolated between each pair of ran-
dom numbers. This allows the ran-
domness to vary on a time scale that’s
significantly longer than the time
slice. This way the noise looks more
like turbulence rather than Brownian
motion. The amplitude of the noise
term is scaled to a percentage of the
full-scale flow rate using the constant
RAND_MAX provided along with the
pseudo-random function in the stan-
dard C library.

THE CONTROLLER

Function

control_rate() in file con-

trol.c implements a basic PID con-
trol algorithm and converts the con-
trol signal to a pulse width and direc-
tion for the control valve. This is
intended to be representative of an
algorithm that will be in an embedded
controller. This is where you can test

different algorithms, different varia-
tions of the same algorithm, different
control periods and parameters, fault
handling algorithms, and execute each
test algorithm with different plant
characteristics.

The control algorithm is also where

the normalized simulated physical
quantities finally get linked, although
still in an abstract way, to a physical
quantity. In function

control_rate(),

a call to

get_flowmeter_period()

returns the flowmeter period quan-
tized by a 31,250-Hz clock, which is a
typical clock rate for the gated time
accumulator in the 68HC11. This
quantized period is converted to a fre-
quency by:

where f is the frequency and P

is the

measured flowmeter period. The
clock frequency of 31,250 Hz is the
inverse of the flowmeter period reso-
lution set by a call to
set_flowmeter_parameters() in
plant_initialize(). This calculated
frequency is the actual rate, which is
compared to the target rate in the
control algorithm. How this frequen-
cy depends on the actual flow rate
depends on the size of the pipe and
response of the flowmeter.

Time (ms)

Event

Data

Description

Set P coefficient

Varies

Set the coefficients for the PID controller. In these scenarios, I and D are constant but P changes

Set I coefficient

0.001

to obtain different response times and overshoot. In scenarios 0, 1, and 2, P is 0.2, 1.0, and

Set D coefficient

0.005

1.8. In scenarios 3 and 4, P is fixed at 1.0 and the valve speed varies. In scenarios 4 and 6,

P is fixed at 0.2 and the valve delay compensation varies.

Set delay

Varies

Valve delay compensation is fixed at 10 ms for all scenarios except 5 and 6, which are 0 and 20

compensation

to test under and over compensation.

Set valve speed

Varies

The valve speed is fixed at 0.12°/ms, or 750 ms, for full motion, except scenarios 3 and 4, which

are 0.06 and 0.24 to test slower and faster valves.

150

Target rate

Step from 0 to the mid range

3600

Target rate

172

Step from mid to high rate

6400

Target rate

Step from high to low rate

9000

Set pressure

0.66

Reduced valve pressure, actual rate should drop

9050

Set valve fault

Valve is stuck in position

9100

Set flowmeter noise

0.15

Flowmeter noise amplitude increases to 15% of the current actual rate

10100

Target rate

141

New target rate, valve is still stuck, so theres no response

12200

Clear valve fault

Off

Valve is able to respond, but the pressure is too low for the target rate to be reached.

19100

Target rate

Mid-range target rate can be reached at a lower pressure

24000

Target rate

Full stop

25000

Set pressure

1.00

Nominal pressure and no noise to get a clear view of the step response time and overshoot. Both

Set flowmeter noise

0.0

low to high and high to low pressure.

26000

Target rate

150

Step from 0 to high rate

29000

Target rate

Step from high to low rate

32000

End simulation

Terminate program

Table 1To simulate a test protocol, a sequence of target rates is executed multiple times with varying controller parameters and plant characteristics to analyze the perform-

ance of the controller.

Issue 130 May 2001

CIRCUIT CELLAR

www.circuitcellar.com

Assume the cross-sectional area of

the pipe is Acm

and the response (f)

of the flowmeter is a constant (C)
multiplied by the fluid velocity (v).
The answer is given in hertz:

The flow volume (R) is the area

multiplied by velocity. So for a given
area (A) and flowmeter response (C),
the frequency corresponding to a
given flow volume (r) is

Ultimately it is this flow volume

that is being controlled using the
measured frequency as a proxy. You
set the target frequency for a desired
flow volume based on this equation,
but as far as the control algorithm is
concerned, the frequency is the only
important quantity, not the flow vol-
ume. This is why it is reasonable to
use normalized simulated quantities
for the flow rate and valve openings.
The constant, which is the flow coef-
ficient set in

set_flowmeter_parame-

ters() called by plant_initialize(),
indicates the frequency that will
result when both valves are fully
open. And it indicates that the fluid
pressure is at an arbitrary value that’s
normalized to 1.0 in the simulation.

THE TESTBENCH

The

main() function contains the

testbench where the plant simulation
is linked to the control algorithm
along with facilities for executing pre-
defined test scenarios and recording
the results. The logical structure of
the testbench is simple. It contains a
loop that represents 1 ms per itera-
tion. The plant simulation is called
once per iteration and the controller
is called once per control period,
which is a constant number of itera-
tions (in this case 100). Each time the
controller is called, the target and
actual rates are stored as text in a file
that can later be loaded into an appli-
cation such as Microsoft Excel and
graphed and processed to determine
response times and overshoot.

The testbench also has an event list

processor that reads data from an
event list in

ev_scen.h and uses that

data either to change the target rate or
a parameter in the plant or controller.
This provides a simple way to design
a set of repeatable tests that can be
executed against variations in the
control algorithm.

Each element of the event list is a

structure that contains the time at
which the event is scheduled to
occur, a code indicating what type of
event it is, and three different types of
data elements. The use of the data
elements is code-specific.

I designed seven simple test scenar-

ios that exercise the basic functionali-
ty of the plant and controller. You can
download these tests (file

EV_Scen.h)

and the results (labeled scenario zero
through six) from the Circuit Cellar
web site. All seven scenarios have the
same sequence of target rates, but
with varying controller parameters or
valve speed. The scenarios follow the
sequence of events shown in Table 1.

Scenarios 0, 1, and 2 vary the P

coefficient while other parameters are
held constant. In scenario 0, with a P
equal to 0.2, you see slow response
times and minimal overshoot in the
first several steps. At about 9 s, the
rate falls because of the pressure drop.
When the target rate jumps up again,
the response does not follow until the
valve is free; and then it isn’t able to
reach the target rate because of the
lower pressure. Also, by this time the
higher noise amplitude is evident.
The last two steps are pure step
responses with no noise or faults.

In scenario 1, P is 1.0, and you see

faster response times and only slight-
ly more overshoot. In scenario 2, with
P equal to 1.8, the response time is
about the same as for scenario 1 but
the overshoot is higher.

Scenarios 1, 3, and 4 hold P con-

stant at 1.0 and vary the valve speed.
Scenario 3 has a valve speed twice as
fast as scenario 1 and consequently
the overshoot is dramatically higher.
In scenario 4, the valve speed is half
as fast and the response is sluggish.

Scenarios 1, 5, and 6 hold P con-

stant at 0.2 and vary the valve delay
compensation. Scenario 5 has no

Programming Microcontrollers
in C, Second Edition

by Ted Van Sickle
ISBN 1-878707-57-4

“I get a constant stream of queries
for introductory texts to the
embedded systems world. This is
the book.” –EDN

Completely updated
and packed with
practical info on how
to use C to fully
exploit the power of
today’s micro-
controllers. The CD-
ROM contains the
listings of all programs in the book, C
compilers, a full set of Motorola’s
microcontroller documentation in
searchable pdf format, and a Deluxe
eBook version of the text. All for only
$59.95! (Downloadable Deluxe
eBook

version, only $44.95.)

For more info on this title and the

author, visit

www.a-sync.com

Embedded
Controller
Hardware Design

by Ken Arnold

ISBN 1-878707-52-3

Offers a great
overview of micro-
controller architecture, design
analysis, memory technologies,
interrupt handling, hardware
interfacing, designing for reliability,
and much more. The CD-ROM
contains useful design tools and a
Deluxe eBook version of the complete
text. Only $49.95! (Downloadable
Deluxe eBook

version only $37.50.)

For more info on this title and author,
visit:

www.embeddedcontrollerhardwaredesign.com

To order, call

1-800-247-6553

or visit

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

www.circuitcellar.com

CIRCUIT CELLAR

Issue 130 May 2001

delay compensation, so valve motion
is reduced and the response is more
sluggish. The valve compensation is
doubled in scenario 6, with results
similar to increasing P.

These are not the only useful

testable scenarios, or even the best.
This set of tests merely demonstrates
the method of varying one parameter
while holding all others constant in
order to isolate the effects of changing
a particular parameter.

CONCLUSION

If the system simulated here is

actually built and tested, it almost
certainly will not behave exactly like
the simulation. But the question is
whether or not the simulation is real-
istic and accurate enough to be useful.
A control valve obviously will have a
finite speed, will probably leak a little
when it is closed, and probably delay
or keep moving for a few milliseconds
when power is applied or removed.
Moreover, the flowmeter will respond
predictably to fluid velocity, other-
wise it is useless, and there probably
will be small stochastic variations in
the measured fluid flow rate.

If I test my control algorithm

against ranges of likely plant charac-
teristics, then when the system is
built, I should be able to pick a set of
control parameters from among the
test set that worked well the first
time. This may not eliminate, but at
least reduces the time and expense of
testing the controller on the system.
If it turns out that the valve or
flowmeter characteristics differ too
much from what I simulated, I deter-
mine the new characteristics (approxi-
mately). Then I go back to my simula-
tor and, perhaps with a different con-
trol period, execute a set of test sce-
narios again to find the control
parameters that work.

The control algorithm and test sce-

narios presented here are obviously
not the only meaningful choices. I can
imagine, for example, designing a con-
trol algorithm that measures response
time and overshoot and uses that
information to adjust the plant
parameters. In that case, you could
design a scenario that reduces pres-
sure either gradually or in steps while

the target rate steps up and down, to
see if the controller can adjust appro-
priately and maintain the same
response. A fault detection algorithm
could be designed to recognize when
the rate fails to respond and take
appropriate fault recovery action. This
type of simulation also could be used
to test experimental algorithms. For
example, a learning algorithm that
remembers how much valve motion
from a given position produces a
given rate, and uses that knowledge to
bypass the PID algorithm and move
the valve directly to the right place.

As I stated earlier, it’s not necessary

for this simulation to be exact to be
useful. The machinery won’t behave
exactly the same way twice. But if the
simulation is realistic and program-
mable, and an experimental control
algorithm is tested against likely
ranges of simulated characteristics
and meets requirements, then you can
be confident your control algorithm
will take control.

Kenneth Baker earned a B.S. in
Electrical Engineering from Illinois
Institute of Technology in 1985 and
an M.S. in Electrical Engineering from
University of Minnesota in 1993. He
has designed and programmed
embedded computers for various
industries including defense, agricul-
ture, traffic control, and medical.
Currently, he works for Guidant
Corp., a manufacturer of implantable
cardiac rhythm management devices.
You may reach him at martkenn
@megsinet.net.

SOURCES

Excel
Microsoft Corp.
(425) 882-8080
www.microsoft.com

SOFTWARE

The code and seven simulation
graphs are available on the Circuit
Cellar

web site.

Issue 130 May 2001

CIRCUIT CELLAR

www.circuitcellar.com

f you’re like me,

you frequent your

local Radio Shack as

though it were a book-

store. I’m always in there checking
out what’s new. Remember when
they used to give away free flash-
lights? Radio Shack sold lots of batter-
ies through this successful marketing
move. Free isn’t a word you see used
much today, unless it’s an enticement
to subscribe to a long-term contract
for cell phones.

The days of freebies (i.e., no strings

attached) have returned. Radio Shack
has been handing out free scanning
devices from Digital:Convergence.
D:C believes that if it puts one of
these in the hands of every user, swip-
ing every bar code in sight will
become a simple alternative to key-
boarding your way through the infor-
mation superhighway. D:C’s bar code-
scanning :CueCat is capable of con-
necting you with an associated prod-
uct’s web site without as much as a
single keystroke.

The :CueCat is a mouse-sized bar

code-scanning wand shaped like a cat
who looks ready to pounce on those
unsuspecting zebra stripes. There is a
registration process you must go
through to unlock the :CRQ (see our

cue) software. This is used to link you
to the embedded serial number of
your :CueCat. Some people get nerv-
ous when they find they are being
checked for identification, but others
welcome the idea of having informa-
tion filtered to their preferences,
removing any unwanted fluff. In this
way, you get only the information
that interests you.

VISIT THE CAT

Radio Shack sells the :CueCat. Or,

you can find out where to get it for
free (there’s that word again), or have
one sent to your door for only the
shipping and handling fees at
www.:CueCat.com/getcat. html.

:CueCat was designed to look like a

keyboard to your PC. Its output is the
same format as the PC keyboard.
Each keystroke produces more than
just one byte of data. There are at
least three bytes sent each time you
hit a key. A key code is sent whenev-
er a key is pushed, and a break code
and key code are sent whenever a key
is released. To be compatible with the
keyboard, the :CueCat must send all
characters using this format. A suc-
cessful scan consists of five parts: pre-
fix, unique serial number, code type,
scan data, and suffix.

Each of the five parts of a :CueCat’s

transmission is separated by a period.
An <ALT F10> sequence is sent as a
prefix and a <CR> sequence is used as
a suffix. This leaves the middle three
groups as the actual data. If you take a
look at the PC’s key codes, all possi-
ble 8-bit bytes are not represented by
keys, so sending 8-bit data is not easi-
ly accomplished through using key-
strokes. One way to accomplish this
would be to send an 8-bit data byte as
two hexadecimal nibbles (0–9 and
A–F). To pack data more closely
together, D:C uses the lowest 6 bits of
each byte to send data (a–z, A–Z, 0–9,
and two characters). This format
requires four bytes (6 bits at a time) to
send three 8-bit data bytes, however,
D:C uses a simple XOR of each data
byte (with C) to further complicate or
encrypt the data.

Humans are a strange bunch.

Curiosity is one of the traits that has
allowed us to become dominant over

FROM THE
BENCH

Fact or
fiction—
nothing
is free
and the
Internet

is getting harder to
navigate. Jeff found a
device that’s freely
distributed and can
make navigating the
Internet as easy as
scanning a bar code.

Jeff Bachiochi

Taking a Cue from a Cat

Hardware Cleanup with :CueCat

www.circuitcellar.com

CIRCUIT CELLAR

Issue 130 May 2001

other creatures. For every product
that is created, there are millions who
will use it for its intended purpose.
There are also a bunch who wonder,
“How’d they do that?” Out of this
group, some will grab their screw-
drivers based on the need to find out
how it was actually done. It still
amazes me how quickly this last
group shares their findings with oth-
ers who have the same interests. For
the most part, this crowd is not in it
to prevent marketing companies from
obtaining the fruits of their labors.

Bar coding is on all kinds of prod-

ucts now. Bar codes provide vendors
with a way to control inventories.
Checkout lines are automated using
product pricing information. Letters
and packages are routed via bar cod-
ing. It only makes sense that we use
these markings to make our daily
lives easier.

There are a few approaches you can

take to use the :CueCat for other
applications. You can alter the
:CueCat to output data in a more
usable format. You can write a driver
program to translate the :CueCat’s
data into a more usable format, or you
can use a black box to accept the
:CueCat’s keyboard codes and trans-
late them directly into usable data.

I opted for the last choice for a

number of reasons. I didn’t want to
prevent the :CueCat from being used
as it was intended. In translating the
:CueCat’s output into universal serial
transmissions (9600 bps), it can be
used as input to many different types

of equipment, including PCs, PDAs,
or embedded systems.

CAT’S BOX

Using a hunk of hardware to per-

form :CueCat translation may not
seem cost-effective, but this is not an
expensive approach. The cat’s box
schematic in Figure 1 shows what
was used to complete this task. This
circuit’s PS-2 mini din receptacle
mates with the :CueCat’s keyboard
connector and supplies 5-V power to
the :CueCat. The remaining signals
(besides the power and ground) are
reset, clock, and data. These are all
TTL-level signals and do not require
any level conversions. The clock and
data lines are open-collector outputs
from the keyboard (cat) and inputs to
the microprocessor (the keyboard is
normally in charge of handling these).
The microprocessor can request a
wait state by pulling the clock line
low if it requires processing
time in-between the reception
of characters.

At the Other end of the Cat’s

box, a DB9 outputs asynchro-
nous data to any serial port.
The RS-232 signals should have
a positive/negative voltage
swing. Most PCs will accept a
TTL-level signal. I’ve designed
the microprocessor to output an
inverted serial format, which
presents the format normally
seen at an RS-232 connection.
The MAX232 in the schematic
is used to invert the signal

twice and present RS-232 levels (in
place of the TTL levels) if needed.
The LED was originally put on to
indicate when the :CueCat was send-
ing a transmission, however I inverted
its function so that it acts as a power
LED, turning off briefly when it sees a
transmission. Configuration jumpers
allow you to eliminate any of the
:CueCat’s output functions—serial
number, code type, or bar data. A
forth jumper enables the raw output
to be sent out the serial port for
debugging purposes.

CAT’S KEYBOARD EMULATION

To look like a PC keyboard, the

:CueCat must emulate the output of
the keyboard. A PC’s keyboard trans-
mission consists of a clock and data
line. Data is available to be read from
the keyboard on each of the clock
line’s falling edges. To indicate the
beginning of a transmission, the data
line must be low on the clock’s first
falling edge (i.e., the start bit). The
next eight falling edges of the clock
line indicate keyboard data (LSB to
MSB). Following the eight data bits,
an odd parity bit is sent. This gives a
small amount of insurance that the
data was received correctly. Finally,
the data line must be high for the
next falling edge (stop bits).

As I stated earlier, a minimum of

three data bytes are sent for each key-
stroke. A character code is sent while
you press a key, and a release code
and character code are sent when you
release the key. When the release code
F0 (240-decimal) precedes a character
code, it indicates that the character

Keyboard codes received from :CueCat (hex):
12 21 F0 21 F0 12 26 F0 26

31 F0 31

1A F0 1A

Four bytes of character data translated from keyboard codes (hex):
C 3

Look-up translation (6-bits):
xx011100

xx110111 xx001101 xx011011

Packing four 6-bit bytes into three 8-bit bytes:
01110011 01110011

01011011

Decode by XOR with ASCII C (43 hex, 01000011):
00110000

00110000

0011000

ASCII printable characters:
30 hex, 0

30 hex, 0

Figure 2

— These keyboard codes translate into four charac-

ters. The lower six bits of each character are reformed into
three 8-bit bytes. These bytes are XORed with "C" to give
three printable ASCII characters (in this case, "000").

Figure 1

— The circuit needs only 40 mA with the :CueCat connected. The micro spits out inverted serial data so

the data needs to be double inverted when using the optional MAX232 for RS-232 swings.

Issue 130 May 2001

CIRCUIT CELLAR

www.circuitcellar.com

and suffix characters can be dis-
carded.

When receiving the :CueCat’s

transmission, your primary duty
is to receive and verify (via the
parity bit) that the data is good.
Your secondary duty is to keep
track of which of the five parts
you are currently processing.
This is handled by keeping track
of the periods received.

If this application converted

the three inner parts as a single
entity, a single routine would
have been used to convert and
output the data. But, using the
configuration jumpers to indicate
whether or not to output each of
the three inner parts requires the
program to handle each of these
groups separately. The program
flow is routed to individual rou-
tines to determine if it should
output the data (based on the
configuration jumpers).

Prior to outputting data, the

data received from the :CueCat

must be translated. The PC must
translate the keyboard’s key code into
the key’s actual character code.
Remember, the :CueCat uses 64 char-
acters to represent 6-bit data. The
received characters must be translated
into the 6-bit data (a = xx000000).
These two translations are combined
into a single look-up routine.

Note that when you’re using the

PC’s keyboard you may hold down
the Alt, Ctrl, or either of the Shift
keys along with any character key.

code’s key has been released. You can
dump each release code and the fol-
lowing character code into the bot-
tomless bit bucket because they are
unnecessary in this application. This
simplifies the data throughput.

There are other transmissions that

can be tossed out as well. If you
remember, the :CueCat’s transmis-
sion consists of five parts, each sepa-
rated by the period character. Because
you are only interested in the inner
three groups of characters, the prefix

Prototype board from Radio Shack (data is the catalog number):
.000000002406506101.C39.276-147.

Ziggy Marley CD:
.000000002406506101.UPA.075679087829.

UPS shipping label:
.000000002406506101.128.420060660000.

Digi-Key shipping label:
.000000002406506101.ITF.00080736460000100098162177.

IR remote from Radio Shack:
.000000002406506101.UPA.040293112417.

Maxtor hard drive:
.000000002406506101.C39.B10P6CKS.

Bag of junk food:
.000000002406506101.UPA.028400012669.

Circuit Cellar magazine:
.000000002406506101.UA2.72527475349902.

Multiple labels from a Nokia cell phone package:
.000000002406506101.UPA.758478621028.
.000000002406506101.C39.23511914259.
.000000002406506101.C39.0068830.
.000000002406506101.C39.EBB5CC13.

Text book:
.000000002406506101.IB5.978192962911454995.

Three :CueCat cues:
.000000002406506101.CC!. # ".
.000000002406506101.CC!. # "<.
.000000002406506101.CC!. # ">.

Figure 3

— Here is the Cat's box output I got when scanning

a number of bar codes. The format is ".(:CueCat's serial
number).(bar code type).(coded information)."

Photo 1

— The

:CueCat bar code
reader is ready to
pounce on the
Cat's box proto-
type PCB.

MSP-FET430x110 development

tool for only

$49

or a free

MSP430x11x1 data sheet.

The red/black banner is a trademark of Texas Instruments. 39-6800

Mixed-Signal Controllers

Join in the latest revolution: ultra-low-power Flash MCUs at ultra-low prices from

Texas Instruments. The MSP430 is the ultra-low-power solution for mixed-signal processing.

The F1101, a Flash MCU with a modern 16-bit RISC architecture, combines TI’s expertise in

analog and digital signal processing. Its ultra-low power consumption makes the F1101 ideal

for battery-powered applications such as utility metering, intelligent sensing and portable

measurement. On-chip emulation simplifies application development. Best of all, all of the

MSP430 devices, including the F1101, are source code compatible.

www.ti.com/sc/f1101

MSP430F1101: a 16-bit RISC
Flash MCU for only $0.99

■ Ultra-low power consumption –

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

■ Integrated analog comparator ideal for

precise mixed-signal measurement

■ 16-bit RISC architecture enables new

applications at a fraction of the code size

■ 16-bit PWM timer allows highly flexible

multichannel capture and compare

■ In-system programmable Flash

permits last-minute code changes and
field upgrades

■ The MSP-FET430x110 complete

integrated development environment
available for only $49

1-800-477-8924, ask for ext. F1101

Issue 130 May 2001

CIRCUIT CELLAR

www.circuitcellar.com

The keyboard sends these keystrokes
just like any other key. What does
that mean for this project, you ask?
Well, you must keep track of these
keys as well as the character keys in
order to tell the difference between a
lowercase and uppercase alpha charac-
ter. When these characters are
received, there is no translation nec-
essary, you just need to set a flag to
indicate that the key has been
received. The reception of any other
character resets these flags.

The flags are used in the look-up

routine to determine if the received
character is one you are interested in,
or if you can just toss it out. For
instance, the :CueCat sends out an
Alt F10 as its prefix. In this case, you
recognize the Alt character in the
look-up routine, set the Alt flag, and
leave. The F10 character falls through
the lookup as an unwanted character
(resetting the Alt flag). The next char-
acter will be the period. This look-up
routine recognizes this and incre-
ments the mode variable, indicating
which part of the transmission you
are currently processing (0–5). The
mode value routes wanted characters
to the appropriate output routine—
serial number, code type, or bar data.

This is where the 6-bit data is

packed into 8-bit bytes for output
through the serial port (if the appro-
priate configuration jumper calls for
it). One more variable is needed. The
code variable tells this routine how
many 6-bit codes have been received.
When the first 6-bit code is received,
you can’t make a complete 8-bit byte
yet because you’re still missing 2 bits.

So, when the value of code equals
zero, you must save this data but
leave without sending out any data.
The next three times through this
routine, as code is incremented, an 8-
bit data byte is created by packing the
appropriate bits together from the
new 6-bit data and the last saved 6-bit
data. To see how all this translation
works, take a look at Figure 2.

Anytime an 8-bit byte has been

assembled it is sent out the serial port
(based on the configuration jumper
settings). When the mode changes
(i.e., a period has been received), the
code variable is reset to zero and any
leftover bits are discarded. If the con-
figuration jumper indicates that this
group of characters is to be sent out of
the serial port, this routine marks the
beginning of a new group by sending
out a period. When the mode switches
to the suffix group, a period (and CR
LF) is also sent out. This closes out
the last group and prepares to output
the next bar code swipe data on a new
line. If for some reason all the config-
uration jumpers are set to disable seri-
al output, the last period (and CR LF)
will be output so there is an indica-
tion that something is happening.

BAR CODE TYPES

There are many more bar code for-

mats, and :CueCat was designed to
handle most of them. Following the
:CueCat’s serial number, a three-digit
code indicates which of the formats
:CueCat thinks it’s reading. Let’s take
a look at some output produced by
the Cat’s box used in conjunction
with my :CueCat (see Figure 3).

Photo 1 shows the circuit built on a

small prototype board. I added a DC
power jack for a wall-wart power sup-
ply and measured the operating cur-
rent as less than 40 mA (with the
:CueCat attached). Certainly the
majority of that current is the LEDs.
Actually, the small plastic box I
designed for is large enough to include

a 9-V battery.
That spares me
the hassle of using
an additional AC
outlet.

Serial number

Code type

Data

000000002406506101

C39

FTB: Issue 130

Table 1

— The bar code printed on my LaserJet can be read via the :CueCat. The

Cat's box will convert its output into data in serial form, which can be easily import-
ed by most applications.

Photo 2

— This bar code was printed with a bar coding

demo program found on the Internet. See Table 1 for
the Cat's box scanned output of this printed bar code.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 130 May 2001

codes, as well as companies producing
bar coding equipment and applica-
tions. Many of these will have demo
programs available for you to experi-
ment with. Some shareware is also
available for printing codes. Now you
can catalog your DVDs, CDs, VHS
tapes, and vinyl disks. (Are you old
enough to remember vinyl?) You can
code virtually anything.

Gather data from the Cat’s box

using your PC’s serial port. I scanned
the bar code in Photo 2 using the
:CueCat and box connected to my
PC’s serial port. Using a terminal pro-
gram, I logged the data to create a file
from the input. Next, I simply
imported the file into Microsoft
Access using the period as a delimiter.
Access separated the input into multi-
ple columns, which I categorized as
serial number, code type, and data
(see Table 1). Voilà!

This input closes the loop. A PC

bar code application created the zebra
stripes and this project read them into
a spreadsheet. Are the wheels begin-
ning to turn in your head? The code

for the Cat box easily fits in the 1-KB
space of the 16F84A, although I have
to admit, I started out trying to use a
higher-level language for this project.
I couldn’t come anywhere near fitting
it into this package. Some things just
have to be written in assembler.

Special thanks to those who have

shared their knowledge of the
:CueCat with others on the web.

DIGITAL:CONVERGENCE’S :CRQ

The :CRQ software from

Digital:Convergence comes free with
the :CueCat and setup is a snap. It’s
difficult to conceive of myself run-
ning to my computer every time I
find a bar code on a product that
looks interesting. I think the Cat is
meant more for easily locating addi-
tional information on subjects you
want to know more about. These
:Cues are more likely to be found in
advertising. Knowing that the print
medium is not the only advertising
avenue, Digital:Convergence has
included the ability to accept audio
:Cues from television and radio out-
puts. Cabling these audio sources into
your PC’s sound card will allow audio
:Cues to be received from any broad-
cast cue partners. No doubt the com-
bination of these media will have an
affect on future multimedia equip-
ment.

BEHIND BARS

You can search the ’Net to find

more information on specific bar

SOURCES

:CueCat and :CRQ software
Digital:Convergence Corp.
www.digitalconvergence.com

16F84A
Microchip Technologies Inc.
(480) 786-7200
Fax: (480) 899-9210
www.microchip.com

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.

iTrex

Better Inventory Management

Visit www.xelosproducts.com

for a free DEMO

Or call us at (415)898-7902

Part Master, BOMs, Purchase Orders, Work
Orders, Sales Orders, Receiving, Invoicing,
Stockroom, Address Book,
and Security Modules

Integrated inventory and
manufacturing control

Affordable

Multi-user

Xelos

Issue 130 May 2001

CIRCUIT CELLAR

www.circuitcellar.com

emember the

Artist Formerly

Known as Prince?

Name changes are pretty

prevalent in the entertainment biz.
When searching the web, I found that
his mother used to call him “Skipper”
of all things. Anyway, AFKAP
arguably went a bit overboard when
he changed his name to an unpro-
nounceable icon.

Suppose he’d chosen an exclama-

tion point or an asterisk, or perhaps
most fitting, a dollar sign (something
with an ASCII code), maybe then it

wouldn’t have seemed so goofy. As it
was, the pictograph representing his
new name caused the ever-growing
electronic engines of publishing and
commerce to vapor lock.

What to do? According to

www.prince.org, O(+> is the proper
ASCIIfied version of his icon.

Not that I do a lot of field reporting,

but this thread prompts me to head
over to the local music emporium.
Where does this glyph fit in the col-
lating sequence, just after ABBA or
around ZZ Top? Would you file it
under A for AFKAP or O for O(+>?

I guess neither seems quite right

because there he sits, stubbornly
stuck under P for Prince with the rest
of the plain old “P” plebes. Oh well.

IT’S ALL IN A NAME

Some of you may have noticed that

the company formerly known as
Scenix (CFKAS) recently changed its
name, too.

Scenix didn’t go for the icon ploy,

although I imagine it’s only a matter
of time before another company does.
The new moniker is Ubicom, six ordi-
nary ASCII characters that won’t
upset anybody’s database. Better yet,
for no-nonsense types, the new name
actually says something about what it
does and clearly indicates its new
goal: ubiquitous communications.

The SX is a SeXy chip, but there are

lots of those around. Instead of being
small-fish Scenix in a big MCU pond,
Ubicom wants to be the shark in the
embedded Internet aquarium.

SILICON
UPDATE

What’s in a
name? In
showbusi-
ness a
name (or

at least what people
call you) can be the
catalyst for success,
or disaster. This
month, Tom peels off
the Ubicom label to
see how much Scenix
is left underneath.

Tom Cantrell

The Company Formerly
Known as Scenix

Port A

Port B

Port C

Port D

Port E

Port F

Port G

Timer 1

(T1)

Edge det.

Timer 2

(T2)

Parallel

slave

peripheral

Timer 0

(T0)

Interrupt

(2) Serializer

deserializer

ADC

Analog

comparator

SxCLK

Reset

Brown-

out

POR

*RST

Watchdog with

post-scaler

Internal

watchdog

clock

ISD

ISP

Writeback

Execute

Decode

Fetch

64-KB Flash

program
memory

16-KB RAM

program
memory

4-KB Data

memory

ALU

Real-time

timer

RTCLK

Divider

Multiplexer

Real-time

clock driver

CPU Core

clock

Divider

Multiplexer

PLL

Divider

OSC

driver

System

clock

Figure 1—

It may sound familiar, but with rockin’ memory and techno SerDes (serializer/deserialer), the IP2022 is

no SX cover band.

www.circuitcellar.com

CIRCUIT CELLAR

Issue 130 May 2001

You’ve heard my take on this sub-

ject before. When it comes to adding
Internet functionality to embedded
applications, there are a few basic
ways to go.

First, there’s the “Honey, I shrunk

the PC” approach, which can be
described as a 32-bit CPU (typically
’x86, MIPS, or ARM) running a con-
ventional big-ticket OS (Windows,
Linux, or RTOS) with lots of memory.
The good news is that this scheme is
conceptually easy, boiling down to
packaging and marketing issues more
than hardware and software design
innovation. The bad news is that it
calls for a prodigious amount of sili-
con, which limits design-in to higher
priced products. Yes, thanks to the
march of silicon, it gets cheaper all
the time, but every penny counts in
embedded apps.

Specialized hardware solutions such

as Seiko and iReady chips (“’Net-in-a-
Chip,” Circuit Cellar 111) or turnkey
modules from the likes of Connect
One (“EZ-Mail Engine,” Circuit
Cellar

115) make much more efficient

use of silicon than desktop-in-drag 32-
bit solutions. On the other hand, they
sacrifice a degree of flexibility and
aren’t cheap because lower production
volume gives up some of the gate
count advantage.

Another option that offers you the

potential for both low-cost and flexi-
bility is shrink-wrapping Internet
functionality inside conventional
MCUs or DSPs. Both silicon efficien-
cy and high production volume cut
the price tag and software still gets to
call the shots.

Which “Mini-Me” web chip is

poised to climb the charts? Glad you
asked. Tap your feet to the latest tune
from CFKAS.

VARIATION ON A THEME

Unlike the company name, the

IP2022 (see Figure 1) is more than a
cosmetic change from its SX predeces-
sor. It still has the look and feel of
that chip, but it’s by no means identi-
cal, especially when you start poking
around under the hood.

Architecturally, you can still see

vestiges of the past in the W accumu-
lator, register file, pages, and so forth,
but it underwent a makeover (see

Figure 2). A 16-bit instruction yields
enough elbowroom to deliver more
ways (address registers and modes) to
easily get at larger chunks of memory.

The nonvolatile program memory is

a 64-KB (32K × 16) flash memory
organized into 8-KB pages (the range
of a branch without a page instruc-
tion) and 512-byte blocks (erase gran-
ularity). For data, there’s the 4-KB
RAM, as shown in the data and pro-
gram memory maps (see Figure 3).

A dedicated 16-level hardware

stack stores return addresses for sub-
routine calls. Program access to this
stack is made possible by mapping the
top entry into the software-accessible
CALLH and CALLL registers.
Exploiting this hook, you can use
push and pop instructions to imple-
ment an arbitrarily deep stack in data
RAM if necessary.

Another hallmark of the SX, blazing

jitter-free interrupt response, is car-
ried forward with the IP2022. It’s
enhanced with two sets of on-chip
shadow registers that allow one level
of interrupt nesting automatically
without the need for software inter-
vention. However, you should expect
to spend a few cycles figuring out
where the interrupt came from
because all 20 sources come home to
roost on a single interrupt vector.

As a Harvard design, the program

and data memories each have their
own bus. That works well if the only
accesses to program memory are
instruction fetches. However, espe-
cially in embedded apps, it’s a must to
store static data (i.e., constants, look-
up tables, text strings, and so on) in
the nonvolatile program memory.

Fortunately, the IP2022 makes it

easy to use the flash memory for not
only static data, but also dynamic

W Register

STATUS Register

MULH Register

SPDREG Register

INTSPD Register

XCFG Register

PCH/PCL Register

Interrupt register

IPCH/IPCL Register

INVECH/INTVECL Register

IPH/IPL Register

DPH/DPL Register

SPH/SPL Register

Program memory interface register

ADDRH/ADDRL Register

DATAH/DATAL Register

Address register

Figure 2—

The IP2022 is positively new age with mod-

ern niceties like address registers (IP, DP, and SP) and
a single-cycle multiplier.

Table 1—

Thanks to the SerDes, there’s more than one way— make that about half a dozen ways— for the IP2022 to shift a bit.

Mode

Encoding method

Differential or

Synchronization

EOP

Bit

Pre-emphasis

single-ended

register enabled

generation/detection

stuffing/unstuffing

outputs enabled

Disabled

None

10BaseT

Manchester

Single-ended

Yes

USB bus

NRZI

Differential

Yes

UART

None

Single-ended

None

Single-ended

SPI/

None

Single-ended

microwire

Figure 4—

Thanks to

an on-chip PLL, no
need to fuss with get-
ting a finicky 100-MHz
clock to work. Just bolt
on a 4-MHz crystal
and crank up the
speed instruction.

data updated at run time. It’s like hav-
ing an extra data EEPROM for pass-
words, calibration data, and more.
The ADDR(H/L) and DATA(H/L) reg-
isters along with simple FREAD,
FWRITE (16-bit words), and FERASE
(512-byte block) instructions and a
built-in charge pump make flash
memory access straightforward.

However, note that the guaranteed

write and erase endurance is only
1000 cycles. Avoiding burnt-out bits

Issue 130 May 2001

www.circuitcellar.com

CIRCUIT CELLAR

requires software to utilize techniques
such as wear leveling for frequently
written data.

SPEED FREAK

Between the 32K × 16 flash memo-

ry and 4-KB RAM is something new,
an extra 8K × 16 RAM. What’s that all
about, you ask?

Here’s the story. Although the

IP2022 carries forward the SX aggres-
sive, triple-digit-clock-rate-capable,
(100-MHz) four-stage pipeline imple-
mentation, the capability to run at
full speed out of flash memory has
been conceded to the realities of IC
fabrication.

It turns out that designing a flash

memory cell with a few nanosecond
access time is no amazing feat, calling
for a highly tuned and tweaked cus-
tom design. Unfortunately, as a fab-
less IC company, Ubicom is much
better off relying on the standard flash
memory cell offered by its foundry to
facilitate easy migration to each new
process generation.

So, the IP2022 only runs at up to 40

MHz out of flash memory, which
admittedly is right up there with the
fastest 8-bit chips. Fully exploiting
the MIPS on tap is accomplished by
moving speed-critical routines into
the aforementioned 8K × 16 RAM,
which runs at full speed.

In essence, it’s kind of a roll-your-

own cache in which software deter-
mines what gets cached and when.
For your embedded applications, this
is much improved over a real cache
that comes with all kinds of baggage
in the form of timing uncertainties
(hit or miss) and overhead (cache line

OSC1

OSC2

OSC

Driver

Pre-

scaler

50X PLL

clock

multiplier

Post-

scaler

PLL Bypass

SPDREG

Divider

RTCLK1

RTCLK2

RTCLK

Driver

CPU

core

ADCLK

TMR0

(+DIV)

RTCLK

(+DIV)

TMR1

(+DIV)

TMR2

(+DIV)

Serial

PLL clock

0×000

0×080

0×100

0×FFF

128

Special-purpose

registers

128

Global registers

3840 Bytes of

data memory

Figure 3—

On-chip memory includes 32K × 16 flash

memory, 4K × 8 data RAM (including the general-pur-
pose and special function registers) and a unique 8K ×
16 high-speed program RAM.

Word

address

0×0000

0×2000

0×8000

0×A000

0×C000

0×E000

0×FFFF

Byte

address

0×0000

0×4000

0×10000

0×14000

0×18000

0×1C000

0×1FFFF

Program RAM

Reserved

Flash memory

fills and spills). The RAM can also be
used for data, although access (via
dedicated IREAD and IWRITE
instructions) is much slower (four
clocks) than for the single-cycle, 4-KB,
data-only RAM.

Clocking (see Figure 4) starts with

two oscillator inputs, one that is high-
speed (4-MHz), feeding an on-chip
50X PLL multiplier, and one that is
low-speed (32-kHz watch crystal). The
new speed instruction not only
accommodates the memory hierarchy,
but also serves as the basis for power
management. It selects the clock
source, enables and disables the oscil-
lator and PLL, and sets a 16-stage,
power-of-two clock divisor, yielding a
system clock range covering 780 kHz
to 100 MHz.

There’s also an INTSPD register

that automatically does the same
thing as a speed instruction when an
interrupt occurs. A likely scenario is
to have background software run at
low speed to save power, automatical-
ly shifting into high gear when an
interrupt occurs. Upon return, there’s
an option to leave the speed instruc-
tion as is or restore it to the pre-inter-
rupt setting.

THE USUAL SUSPECTS

The IP2022 includes a healthy com-

plement of built-in glue logic and I/O
functions. After all, when it gets on
the ’Net, presumably it’s supposed to
do something useful besides just
yakking with other computers.

Although the chip runs on a 2.3- to

2.7-V supply, the I/O pins are 5-V tol-
erant and four of them (Port A) fea-

ture a whopping 24-mA drive capabil-
ity. Eight pins (Port B) can be used as
external interrupt inputs with pro-
grammable edge detection. A nice
touch is that the Port B logic is asyn-
chronous, which means that an exter-
nal interrupt can be used to wake up
the chip even if the clock is disabled.

With a traditional watchdog timer

and 8-bit timer with an 8-bit prescaler
running off the 32-kHz oscillator, the
latter is a natural for use as a real-

time (HH:MM:SS) clock. In addition,
there’s also an 8-bit timer with a 15-
bit prescaler and two sophisticated
16-bit timers with 8-bit prescalers,
the latter gussied-up with timer,
PWM, and Capture and Compare
modes with programmable rising-,
falling-, or any-edge trigger.

These days, it’s hard to find an

MCU that doesn’t offer some analog
capability, and the IP2022 is no excep-
tion. There’s an eight-channel, 10-bit

Receive polarity

reversal bit

SxRXP

Input

Serial PLL clock

OSC clock

RTCLK

Clock/data
separation

and
start

condition
detection

Synchronization

pattern

(SxRSYNC)

SxRXP

Input

SxRXM

Input

EOP

Detection

UART Clock

divider

Clock

Data

Receive data

SxCLK

Receive

clock

Transmit

clock

EOP

www.circuitcellar.com

CIRCUIT CELLAR

Issue 130 May 2001

EOP

Receive

count

(SxRCNT)

Receive

data

Receive

clock

Receive

count

(SxRCNT)

Receive

interrupt

Data bus

Transmit

configuration

(SxTCFG)

Transmit
interrupt

Transmit

buffer

(SxTBUF)

Transmit

clock

Data

encoder

Pre-

emphasis

EOP

Generator

Data bus

SxOE

SxTXM

SxTXP

SxTXME

SxTXPE

Figure 5—

Each of the SerDes units consists of transmit and receive shifters plus protocol-specific logic. The hardware does the hard part, software handles the rest.

480-837-5200 / fax: 480-837-5300 / info@embeddedx86.com

www.embeddedx86.com

Issue 130 May 2001

CIRCUIT CELLAR

www.circuitcellar.com

ADC (Port G) with 48-kHz through-
put and right- or left-justification
along with an analog comparator with
optional 50-mV hysteresis. All super-
visor chip functions are there, includ-
ing watchdog timer, brownout detec-
tion, and power-on reset.

The IP2022 would make an excel-

lent coprocessor, off-loading the real-
time dirty work that tends to bring
big-ticket CPUs to their knees. To
that end, Port C and Port D are sup-
plemented with a Parallel Slave
Peripheral mode utilizing dedicated
control lines *CS, R/W, and *HOLD.
From the perspective of a host CPU,
the IP2022 easily mimics a regular 8-
or 16-bit peripheral without imposing
critical timing or software gyrations
on either chip.

BREAKFAST OF CHAMPIONS

Completing the com-centric

makeover, the IP2022 incorporates a
pair of intriguing serializer/deserializ-
er (i.e., SerDes) units. Just think shift
registers on steroids, and take a look
at Figure 5.

By now, we’re all familiar with the

arguments related to hardware versus
software. It’s not a new concept;
somewhere I’ve got an Intel “Software
UART” app note from 20 years ago, a
cute trick that legions of designers
have exploited in the years since.
Indeed, the original SX marketing
strategy was based on the idea of
replacing dedicated hardware with
software virtual peripherals.

However, doing serial ports purely

in software does have its disadvan-
tages and frustrations. The grunt
work simply gets in the way of doing
more important things and can
become a surprisingly big hassle,
especially as the data rate increases.

Sure, it’s possible to pull off a

UART or other simple interface in
software, but what about upping the
ante? With 100 MIPS, it’s possible to
contemplate going further with, for
example, USB or Ethernet. However,
it’s not going to be pretty, and remem-
ber, all it takes is one critical timing
spec to be a showstopper.

I’ve often thought that what the

world needs is an approach some-
where in-between pure hardware and

pure software solutions. The goal is
something more transistor-efficient
and flexible than hardwired logic, but
less burdensome than doing every-
thing in software.

Well, that’s exactly what the SerDes

is all about. I’ve seen the bit processor
strategy employed on some of the
high-end network processor super-
chips, but now it’s come to the MCU
on your block. Thanks to the SerDes,
the IP2022 doesn’t even work up a
sweat over stuff like UART, SPI, or
I

C, and realistically has a chance of

handling USB and even Ethernet. You
can see proof in Table 1.

The shift registers cut the drudge

work by a factor greater than eight,
but there’s more to it than that. To
handle the critical timing aspects of
Ethernet and USB, the SerDes also
incorporates a dash of protocol-specif-
ic hardware that takes care of the
most difficult tasks like detecting the
start and end of packets and encoding
or decoding the data.

Each SerDes includes eight pins to

accommodate the variety of differen-
tial data- and protocol-specific signals.
For example, USB requires a couple of
extra pins to detect the EOP condition
and Ethernet needs an enable line for
the external magnetics.

The scheme doesn’t get software

totally and completely off the hook.
In the case of USB, you have to form
the packets, handle CRCs, and check
for certain special conditions such as
bus suspend or reset. Ethernet calls
for a little bit more hand-holding,
such as dealing with collisions and
other link problems (polarity reversal
and jabber detection), but it is still
well within reach.

GNU DAY YESTERDAY

It’s ironic that the hot setup is a

chip with roots that go way back, run-
ning a tool chain that’s no spring
chicken either.

The fact is, the GNU tool chain (C

compiler, assembler, debugger, and
IDE) is becoming a major player in
embedded apps, and not just for 32-
bits. The announcement that the
IP2022 will be supported with Red
Hat GNUPro tools certainly rein-
forces the trend.

www.circuitcellar.com

Now all of the great

editorial, advertising, and

information you get in

Circuit Cellar is available in

a digital format each

month. With the electronic

edition of Circuit Cellar, the

latest issue is available

worldwide in a

matter of minutes.

So, whether you’re an

international subscriber

who wants to avoid

shipping delays, or you

just prefer pixels to paper

when it comes to reading

material, go to

www.circuitcellar.com to

find out more about the

electronic edition of

Circuit Cellar.

Only

$15

NO MATTER WHERE YOU

ARE, WE‘RE ALWAYS AT

YOUR FINGERTIPS.

• Intel PIII Processor
• 256MB 133MHz SDRAM
• 40GB UDMA Hard Drive
• 3.5" 1.44MB Floppy Drive
• 50X CD-ROM
• ATX Professional Tower Chassis
• 1 Parallel, 2 Serial, 2 USB ports
• 32MB AGP Video Adapter
• Yamaha Sound System

• Intel Pentium III Processor
• 256MB 133MHz SDRAM
• 40GB UDMA Hard Drive
• 3.5" 1.44MB Floppy Drive
• 50X CD-ROM
• 1 Parallel, 2 Serial, 2 USB ports
• 17" .27 1280x1024 Monitor
• ATI Xpert 2000 32MB AGP Video Adapter
• ATX Professional Tower Chassis
• Yamaha Sound System & 120WATT Speakers
• Windows 2000, Logitech PS/2 Mouse & Keyboard
• Netgear 10/100 PCI Ethernet Card

• Intel Pentium III Processor
• 128MB 133MHz SDRAM
• 30GB UDMA Hard Drive
• 3.5" 1.44MB Floppy Drive
• Creative Labs CD-RW
• ATX Professional Tower Chassis
• 1 Parallel, 2 Serial, 2 USB ports
• ATI Xpert 2000 32MB AGP Video Adapter
• Yamaha Sound System & 120 WATT Spkrs
• Windows '98, Logitech PS/2 Mouse & Keyboard
• 56K v.90 Lucent PCI Modem w/Fax & Voicemail

• Intel Pentium III Processor
• 128MB 133MHz SDRAM
• 20GB UDMA Hard Drive
• 3.5" 1.44MB Floppy Drive
• 50X CD-ROM
• ATX Professional Tower Chassis
• 1 Parallel, 2 Serial, 2 USB ports
• 17" .27 1280x1024 Monitor
• ATI Xpert 2000 32MB AGP Video Adapter
• Yamaha Sound System & 120 WATT Spkrs
• Windows '98, Logitech PS/2 Mouse & Keyboard
• 56K v.90 Lucent PCI Modem w/Fax & Voicemail

• Intel Pentium 4 Processor
• 128MB PC800 RAMBUS
• 40GB UDMA Hard Drive
• 3.5" 1.44MB Floppy Drive
• 50X CD-ROM
• 1 Parallel, 2 Serial, 2 USB ports
• 32MB AGP Video Adapter
• P4 Industrial Tower & 300W PS
• Windows 2000, Logitech PS/2 Mouse & Keyboard
• Netgear 10/100 PCI Ethernet Card

• Intel Pentium III Processor
• 256MB 133MHz SDRAM
• 40GB UDMA Hard Drive
• 3.5" 1.44MB Floppy Drive
• DVD CD-ROM
• Hewlett Packard 32x CDRW
• 1 Parallel, 2 Serial, 2 USB ports
• 19"KDS .26 V195 Monitor
• ASUS GeForce II 32MB DDR Video Adapter
• ATX Professional Tower Chassis
• SoundBlaster Live value & 520 WATT Speakers
• Windows ME, Microsoft Intellimouse & Keyboard
• 56K v.90 Lucent PCI Modem w/Fax & Voicemail

(510) 353-1800

OR FAX (510) 353-0990

Experience your Dream Computer

www.dreamtech.com

SINCE 1983

RELIABLE, POWERFUL WORKSTATION AT
AN UNBELIEVABLY LOW PRICE. WITH 20GB
HD & 17” MONITOR.

• Intel Celeron® Processor
• 64MB SDRAM
• 20GB UDMA Hard Drive
• 3.5" 1.44MB Floppy Drive
• 50X CD-ROM
• 1 Parallel, 2 Serial, USB & PS/2 Port
• 17" Monitor & Integrated Graphics
• Sound System & 120 WATT Speakers
• Windows '98, Logitech PS/2 Mouse & Keyboard
• 56K v.90 Lucent PCI Modem w/Fax & Voicemail
• ATX Professional Tower Chassis

19” MONITOR, DVD CD-ROM, 40GB HD, 32MB
GEFORCE II, SOUNDBLASTER LIVE & 520 WATT
SPEAKERS WITH SUBWOOFER MAKE THIS THE
ULTIMATE ENTERTAINMENT SYSTEM!

• Intel Pentium III Processor
• Configurable Flash BIOS & APM
• 256K L2 Cache
• Supports RAM up to 1GB
• 1.44MB 3.5" Floppy Disk Drive
• UDMA 100 4HD & 2FD controller
• 5 32-bit PCI, 1 ISA, & 1 4X AGP slot
• 2 Serial, 1 Parallel, 2 USB & PS/2 port
• Professional ATX Tower Case
• 250 WATT ATX Power Supply
• 104-Key PS/2 keyboard
• Integrated Audio

$219

DesignerDreams

NEW WITH INTEL PENTIUM 4 PROCESSOR &
D850GB MAINBOARD. ENJOY FAST DIGITAL MUSIC, MIND-
BLOWING GRAPHICS & INTENSE 3D GAMING. NETWORK-
READY WITH WINDOWS 2000 PROFESSIONAL &
NETWORK ADAPTER FOR UNBEATABLE BROADBAND
PERFORMANCE. EXPERIENCE THE NEXT GENERATION OF
HIGH-PERFORMANCE DREAM COMPUTERS.

40950 Encyclopedia Circle

Fremont, California 94538

Dream Generation

3YR WARRANTY

on select products

WITH CASE, POWER SUPPLY, MAIN BOARD, CPU, FLOPPY DRIVE &
KEYBOARD. A SOLID FOUNDATION FOR YOUR DREAM COMPUTER.

e-mail sales@dreamtech.com

• Intel Celeron Processor
• Configurable Flash BIOS & APM
• 128K Cache
• Supports RAM up to 512MB
• 1.44MB 3.5" Floppy Disk Drive
• UDMA 4HD & 2FD controller
• 3 32-bit PCI slots
• 2 Serial, 1 Parallel, 2 USB & PS/2 port
• Professional ATX Tower Case
• 250 WATT ATX Power Supply
• 104-Key PS/2 keyboard
• Integrated Audio & Video

CREATE AUDIO & DATA CDs WITH EASE!
CREATIVE LABS CDRW & 30GB HD DELIVERS
HIGH PERFORMANCE ON A BUDGET.

Add an HP DeskJet 840C

WITH WINDOWS 2000 PROFESSIONAL, THIS
EXPERT CONFIGURATION DELIVERS STATE OF
THE ART POWER TO ANY DESKTOP. COMPLETE
WITH 17” MONITOR, 40GB HD & 256MB RAM.

NOW WITH 256MB RAM, 40GB HARD
DRIVE, & 32MB VGA.
A POWERFUL SYSTEM WITHOUT
UNNECESSARY EXTRAS. PERFECT FOR
TODAYS DEMANDING APPLICATIONS.

mouse, speakers,

name brand components

Issue 130 May 2001

CIRCUIT CELLAR

www.circuitcellar.com

+972-9-766-0456
Fax: +972-9-766-0461
www.connectone.com

i1000 ichip
iReady Corp.
(408) 330-9450
Fax: (408) 330-9451
www.ireadyco.com

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

’7600A ichip
Seiko Instruments, Inc.
Semiconductor Products Group
(408) 433-3208
Fax: (408) 433-3214
www.seiko-usa-
ecd.com/intcir/html/whatsnew

IP2022 Internet processor
Ubicom, Inc.
(650) 210-1500
Fax: (650) 210-8715
www.ubicom.com

SOURCES

CO560AD-S/P ichip
Connect One

Tom Cantrell has been working on
chip, board, and systems design and
marketing for several years. You may
reach him by e-mail at
tom.cantrell@circuitcellar.com.

As I write this, I don’t yet have the

IP2022 tools in hand. It will be inter-
esting to see how well the compiler
handles the relatively small footprint.
No doubt the debugger will take
advantage of the IP2022 serial debug
and programming port.

Getting on the ’Net is the prime

directive. Ubicom has all of the virtu-
al peripheral drivers for Ethernet,
USB, UART, and the TCP/IP stack
you’ll need. The price (free) is defi-
nitely right. I also hear talk of a free
RTOS in the works. They’re giving
away all the razors to sell you $13 (at
10K) IP2022 blades.

2001, A ’NET ODYSSEY

Connecting real-world stuff like

cars, homes, and appliances is what’s
going to push the ’Net beyond being
little more than a glorified BBS.

I recently saw a report about a gadg-

et designed to help consumers moni-
tor and budget energy use in the
home by establishing two-way com-
munication with the power company
over the ’Net. Judging from the head-

lines about the lights going out, I may
need one of those myself before long.

The bad news is that the unit’s 32-

bit CPU and megabytes of memory
undermine its turnkey consumer pre-
tensions. That’s just what you need,
another power-sucking 24/7 bloat box
to remind you not to waste power.

The dot-coms may have crashed,

but the real ’Net fun is just beginning.
Chips like the IP2022 with Ethernet
and USB will help embedded apps get
online. Communication, computa-
tion, and control all in one low-cost,
low-power chip is music to my ears.

I can’t remember the artist’s name,

but hey, it’s got a good beat and I can
dance to it.

CIRCUIT CELLAR

Test Y

Your E

What’s your EQ?

—The answers

and 4 additional questions and
answers are posted at
www.circuitcellar.com
You may contact the quizmasters
at eq@circuitcellar.com

more EQ

questions

each month in

Circuit Cellar Online

see pg. 4

Problem 1

— Given the following prototype:

int compact (int *p, int size);

write a function that will take a sorted array
with some elements duplicated, and com-
pact the array by removing the duplicates,
returning the new length of the array. For
example, if p points to an array containing
1, 3, 7, 7, 8, 9, 9, 9, 10, when the function
returns, the contents of p should be: 1, 3,
7, 8, 9, 10, with a length of 6 returned.

Contributed by Wael Badaway

Problem 2

— What are the basic functions

provided by a computer file sys

tem?

Contributed by Dave Tweed

Problem 3

— We know that both silicon and ger-

manium are semiconductors used in discrete
devices. But why is silicon alone used in IC fab-
rication and not germanium?

Contributed by Naveen PN

Problem 4

— How can a 555 timer IC be used

as an inverter? What are its advantages?

Contributed by Naveen PN

www.circuitcellar.com

CIRCUIT CELLAR

Issue 130 May 2001

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

including Development Board,

Available in

Rapid Development Kits

AC adapter, serial cable and SPECTRUM CD with eval software tools
(Keil, TASKING), FlashTools, electronic documentation and demos

www.phytec.com

phyCORE Modules:

phyCORE Modules:
NEW GENERA

NEW GENERA

NEW GENERATION

TION

SINGLE BOARD COMPUTERS

PHYTEC America LLC

■ 255 Ericksen Avenue ■ Bainbridge Island, WA ■ USA 98110

(800) 278-9913

IDEA BOX

THE

DIRECTORY

PRODUCTS AND

SERVICES

AD FORMAT

: Advertisers must furnish digital submission sheet and digital files that meet the specifications on the digital submission sheet.

ALL TEXT AND OTHER ELEMENTS MUST FIT WITHIN A 2

″″ ××

″″

FORMAT

. Call for current rate and deadline information. Send your disk and digital submis-

sion sheet to: IDEA BOX, Circuit Cellar, 4 Park Street, Vernon, CT 06066 or email kc@circuitcellar.com. For more information call Kevin Dows at (860) 872-3064.

Suppliers Directory now available online. Check out our web site

www.circuitcellar.com to see who has what and how to get it!

Issue 130 May 2001

CIRCUIT CELLAR

www.circuitcellar.com

CIRCUIT CELLAR

Issue 130 May 2001

Scottsdale, Arizona
Ph: 480.998.3503
Fx: 480.998.3504

Resistance Substitution Device

Order
on-line for
FREE shipping!

PIC and PICmicro are registered trademarks of Michrochip
Technology Inc. in the USA and other countries.

Need to quickly get up to speed with the
PICmicro

family? We’ve made our

award-winning PICmicro development
system even better. The new PMDS 2
microcontroller development system
includes everything you need for program
development, education, experiments, or control
applications
using PIC
microcontrol-
lers. Get
started with
complete
systems
from $349.

172 Harvard Road
Waterloo, ON, N2J 3V3
Canada
519.886.4462
519.886.4253(fax)

www.siriusmicro.com

PMDS 2 Professional Pack Features:

• PIC16F84, PIC16F876, programmer, cables, power supplies
• 2X16 LCD, keypad, analog pots, analog reference adjust,
buffered port probe, RS-232 port, 2 4k serial EEPROMs,
2 servo outputs, IR receiver, & in-circuit programming port

Issue 131 June 2001

CIRCUIT CELLAR

www.circuitcellar.com

For acquisition and control of digital and analog signals.

High speed Serial Port Interface

24 digital I/O (TTL compatible)

11 Analog Channels with 12 bit ADC

4 channels with signal conditioning

Embedded stepper motor controller
32 bit DLL

Control up to 16 stepper motors simultaneously

using a “SINGLE SERIAL PORT”.

Up to 8500 Steps/sec with linear Accel/Decel.

Chopper driver up to 48V/2A for 4,5or 6 wire motors.

Software Winding Current Setup.

Shaft encoder input , external driver capabilities.

Internal FIFO for linear, cubic or spline Interpolation.

24 digital I/O,2 SPI, 11 analog channels on-board.

32 bit DLL with examples in VC++,VBasic and Delphi.

ST400-NT

67(33(5 02725 &21752/

SPORT232

Less than US$100/axis!

9 Channel Data
Loggers from
US$400. Ask us, or
visit our web site.

Control up to 16 stepper motors simultaneously

using a “

DATA ACQUISITION & CONTROL

RMV Electronics Inc.
230-2250 Boundary Rd.
Burnaby, BC, Canada V5M 3Z3
Tel: (604) 299-5173 Fax: (604) 299-5174
Web site: www.rmv.com

www.circuitcellar.com

CIRCUIT CELLAR

Issue 131 June 2001

CIRCUIT CELLAR

www.circuitcellar.com

Books by engineers,

for engineers.

Check out our ever-expanding
list of technical books, eBooks,
ePapers, eLectures, and
eCourses on embedded
systems design, DSP, wireless
communication, PCI bus, and
much more!

For a

FREE

ePaper on PICs and

PICBASIC, link to

www.LLH-publishing.com/FREEePaper.htm

Books by engineers,

for engineers.

RS232/RS422 Converter

www.circuitcellar.com

CIRCUIT CELLAR

Issue 131 June 2001

• Full duplex
• 422 or 485 4 wire
• Short haul modem

up to 5000 feet

• Supports up to 40

RS422 devices

$84.00

quantity 1. OEM discounts.

Connecticut microComputer, Inc.

PO BOX 186, Brookfield,CT 06804
(203)740-9890 Fax:(203)775-4595

code CC60

Easy to use converter adapts any

RS232 computer to RS422 or 4 wire
RS485. Using two twisted pair wire the
ADA422L will support up to 40 devices
at distances up to 5000 feet. Power is
obtained from the RS232 signal lines.

www.2cmc.com

New

Port
powered

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

Issue 131 June 2001

CIRCUIT CELLAR

www.circuitcellar.com

NuDAQ.

com

PC Based Data Acquisition & Control Products

PCI-9812, 20 MHz Simultaneous
4-Ch Analog Input Card

PCI-7300A, Ultra-High Speed 32-Ch
Digital I/O Card

LABView,

HP-VEE,

IF Software, DLL’s, InTouch,

AILS. Much broader selection online!

Circuit Specialists, Inc.

1-800-528-1417/ Fax: 480-464-5824

since 1971

www.circuitcellar.com

CIRCUIT CELLAR

Issue 131 June 2001

Email: sales@picofab.net

Issue 131 June 2001

CIRCUIT CELLAR

www.circuitcellar.com

Integrated Development Systems:

Compilers, Simulators, Programmers,

In-Circuit Emulators

Non-intrusive, with trace feature, hardware unconditional & complex

breakpoints, triggers, programmable clock, memory mapping &

banking, full project & source level support for C compilers…

2900-1 Crescent Drive
Tallahassee, FL 32308

850-942-7905 phone & fax

Easy Software Development: Use your C/C++ or Basic com-
piler to produce DOS EXE. Download EXE to flash disk via serial
port. EXE runs on power up.

Standard Features: BIOS & DOS-ROM, 128K flash disk,
512K SRAM, 40 MHz AM188ES CPU, 16 digital I/O (opto rack
interface), 2 RS-232, 2 timer/counters, simple bus interface,
real-time clock with timed power-up

Options: 8-ch 12-bit ADC, flash disks up to 288 MB, 1 RS-485

Tiny Size, Low Power: 2”x2.6”, 5V @ 200 mA at full speed.

Visit http://www.bagotronix.com for info, prices, and FAQs

• Free TCP/IP, PPP,

Mini-server

• Easy to Use
• Low Cost
• Low Power
• Tiny Size
• High Speed
• DOS Environment

www.circuitcellar.com

CIRCUIT CELLAR

Issue 131 June 2001

CIRCUIT CELLAR

www.circuitcellar.com

7HO

)D[

6LJJ,QGXVWULHV,QF

+LJK3HUIRUPDQFH0LFURVWHS0RWRU

'ULYHU&RQWUROOHU$9%LSRODU

56&RQWUROOHGRU&DQQHG&\FOHG&RQWUROOHG

+LJK&XUUHQWGULYLQJXSWR

$PSVDW9'&SHUSKDVH

8SWRPLFURVWHSVSHUUHYROXWLRQ

6KRUW&LUFXLWDQG2YHU7HPS3URWHFWLRQ

3URJUDPPDEOHELWRSWLFDOO\LVRODWHGLQSXWV

&KDQQHO3URJUDPPDEOHIRU9$QDORJ

,QSXWVRU77//HYHO2XWSXWV

-R\VWLFNFRQWUROODEOH

%XLOWLQ$FFHOHUDWLRQ'HFHOHUDWLRQUDPSLQJ