7
9
25274 75349
1 1>
CIRCUIT
CELLAR
®
www.circuitcellar.com
T H E M A G A Z I N E F O R C O M P U T E R A P P L I C AT I O N S
$4.95 U.S. ($5.95 Canada)
#172 November 2004
INTERNET & CONNECTIVITY
Ethernet Interface for
Embedded Systems
Network Video Server
Wi-Fi-Enhanced Data Logger
VGA Monitor Controller
Digital Oscilloscopes
•
2 Channel Digital Oscilloscope
•
100 MSa/s
max single shot rate
•
32K samples per channel
•
Advanced Triggering
•
Only 9 oz and 6.3” x 3.75” x 1.25”
•
Small, Lightweight, and Portable
•
Parallel Port
interface to PC
•
Advanced Math options
•
FFT Spectrum Analyzer options
DSO-2102S
$525
DSO-2102M
$650
Each includes
Oscilloscope
,
Probes, Interface Cable, Power
Adapter, and software for
Win95/98, WinNT, Win2000
and DOS.
•
40 to 160 channels
•
up to 500 MSa/s
•
Variable Threshold
•
8 External Clocks
•
16 Level Triggering
•
up to 512K samples/ch
•
Optional Parallel Interface
•
Optional 100 MSa/s Pattern Generator
LA4240-32K (200MHz, 40CH)
$1350
LA4280-32K (200MHz, 80CH)
$2000
LA4540-128K (500MHz, 40CH)
$1900
LA4580-128K (500MHz, 80CH)
$2800
LA45160-128K (500MHz, 160CH)
$7000
Logic Analyzers
• 24 Channel Logic Analyzer
• 100MSa/S max sample rate
• Variable Threshold Voltage
• Large 128k Buffer
• Small, Lightweight and Portable
• Only 4 oz and 4.75” x 2.75” x 1”
• Parallel Port Interface to PC
• Trigger Out
• Windows 95/98 Software
LA2124-128K (100MSa/s, 24CH)
Clips, Wires, Interface Cable, AC
Adapter and Software
$800
All prices include Pods and Software
S
ecurity is one of the topics that always remains popular among
authors and readers alike. Security is vital not just to your networked
embedded systems, but also to your homes and businesses. With secu-
rity—albeit of a different nature—at the forefront of the news in correla-
tion with the presidential election this month, it seems apropos that we
would feature this topic in this month’s Internet & Connectivity issue.
To get you started, we have “Network Security for Small Systems,” by
Jan Axelson (p. 62). Security is a chief concern when you decide to hook
up your system to the Internet.You worry about exposing your system to
potential threats.This article will interest anyone who has a small embed-
ded system with a network connection. Everything from firewalls to
encryption is discussed. Jan’s thorough analysis of security measures
will arm you with the knowledge you need to protect your data and code.
This month, we’re also featuring a home security application that
won’t exceed your budget. Eric Gagnon designed a highly sophisticated
surveillance system for only a few hundred dollars (p. 16). Instead of
building a typical system with cameras and a VCR, he decided to build
his own Ethernet-enabled, four-channel network video server and couple
it with common NTSC cameras. The result is a high-tech solution without
the expense of a commercial video server. External clients are allowed
only TFTP write access, which helps protect the system from other peo-
ple on the local network.
Securing your system can be the most important aspect of any design.
These articles provide a solid basis for understanding the various meth-
ods of protection. In addition to these practical security-related articles, I
want to mention a couple of the other notable articles that are in this
issue. For those of you interested in Ethernet projects, we also have an
impressive combination of a high-speed Ethernet and an embedded sys-
tem. Using an FPGA, Eddie Insam harnessed the power of a 100-Mbps
Ethernet at full speed (p. 44). The system is built around an Altera ACEX
EP1K50 chip. It is ideal for collecting data from a CCD camera or high-
speed data converter. Eddie’s step-by-step article tells you everything
you need to know to optimize Ethernet for your next embedded system.
Ingo Cyliax is back this month with an interesting project that’s
designed to help you determine where to install solar panels (p. 24). If
you’re thinking about using solar power for your home, you’ll want to
know exactly how much sunlight exposure your home gets. This Rabbit
Semiconductor RCM3400-based logger generates the data you need to
know to design the most effective and efficient solar energy system. The
Sunlogger itself is solar-powered, eliminating the need for an external
power supply and cables. By using Wi-Fi, Ingo also eliminated the has-
sle of having to retrieve the Sunlogger to collect its data, which is espe-
cially beneficial if the logger is placed somewhere difficult to access, like
a roof. Ingo also uses the Sunlogger to monitor the efficiency of his main
solar collectors.
And there’s more. This issue is jam-packed with projects that should
keep you busy for a while. Enjoy!
4
Issue 172 November 2004
www.circuitcellar.com
CIRCUIT CELLAR
®
EDITORIAL DIRECTOR/FOUNDER
Steve Ciarcia
MANAGING EDITOR
Jennifer Huber
TECHNICAL EDITOR
C.J. Abate
WEST COAST EDITOR
Tom Cantrell
CONTRIBUTING EDITORS
Ingo Cyliax
Fred Eady
George Martin
George Novacek
Jeff Bachiochi
NEW PRODUCTS EDITOR
John Gorsky
PROJECT EDITORS
Steve Bedford
Ken Davidson
David Tweed
ADVERTISING
PUBLISHER
Dan Rodrigues
E-mail: dan@circuitcellar.com
ASSOCIATE PUBLISHER/DIRECTOR OF SALES
Sean Donnelly
Fax: (860) 871-0411
(860) 872-3064
E-mail: sean@circuitcellar.com
Cell phone: (860) 930-4326
ADVERTISING REPRESENTATIVE
Rachel Humphrey
Fax: (860) 871-0411
(860) 872-3064
E-mail: rachel@circuitcellar.com
ADVERTISING COORDINATOR
Valerie Luster
Fax: (860) 871-0411
(860) 875-2199
E-mail: val.luster@circuitcellar.com
ADVERTISING ASSISTANT
Deborah Lavoie
Fax: (860) 871-0411
(860) 875-2199
E-mail: debbie.lavoie@circuitcellar.com
CONTACTING CIRCUIT CELLAR
SUBSCRIPTIONS:
INFORMATION: www.circuitcellar.com or subscribe@circuitcellar.com
To Subscribe: (800) 269-6301, www.circuitcellar.com/subscribe.htm, or subscribe@circuitcellar.com
PROBLEMS: subscribe@circuitcellar.com
GENERAL INFORMATION:
TELEPHONE: (860) 875-2199 Fax: (860) 871-0411
INTERNET: info@circuitcellar.com, editor@circuitcellar.com, or www.circuitcellar.com
EDITORIAL OFFICES: Editor, Circuit Cellar, 4 Park St., Vernon, CT 06066
NEW PRODUCTS: New Products, Circuit Cellar, 4 Park St., Vernon, CT 06066
newproducts@circuitcellar.com
AUTHOR CONTACT:
E-MAIL: Author addresses (when available) are included at the end of each article
CIRCUIT CELLAR®, THE MAGAZINE FOR COMPUTER APPLICATIONS (ISSN 1528-0608) and Circuit Cellar Online are published
monthly by Circuit Cellar Incorporated, 4 Park Street, Suite 20, Vernon, CT 06066 (860) 875-2751. Periodical rates paid at Vernon,
CT and additional offices. One-year (12 issues) subscription rate USA and possessions $21.95, Canada/Mexico $31.95, all
other countries $49.95. Two-year (24 issues) subscription rate USA and possessions $39.95, Canada/Mexico $55, all other
countries $85.
All subscription orders payable in U.S. funds only via VISA, MasterCard, international postal money order, or check
drawn on U.S. bank.
Direct subscription orders and subscription-related questions to Circuit Cellar Subscriptions, P.O. Box 5650, Hanover, NH
03755-5650 or call (800) 269-6301.
Postmaster:
Send address changes to Circuit Cellar, Circulation Dept., P.O. Box 5650, Hanover, NH 03755-5650.
For information on authorized reprints of articles,
contact Jeannette Ciarcia (860) 875-2199 or e-mail jciarcia@circuitcellar.com.
Circuit Cellar® makes no warranties and assumes no responsibility or liability of any kind for errors in these programs or schematics or for the
consequences of any such errors. Furthermore, because of possible variation in the quality and condition of materials and workmanship of read-
er-assembled projects, Circuit Cellar® disclaims any responsibility for the safe and proper function of reader-assembled projects based upon or
from plans, descriptions, or information published by Circuit Cellar®.
The information provided by Circuit Cellar® is for educational purposes. Circuit Cellar® makes no claims or warrants that readers have a right to
build things based upon these ideas under patent or other relevant intellectual property law in their jurisdiction, or that readers have a right to
construct or operate any of the devices described herein under the relevant patent or other intellectual property law of the reader’s jurisdiction.
The reader assumes any risk of infringement liability for constructing or operating such devices.
Entire contents copyright © 2004 by Circuit Cellar Incorporated. All rights reserved. Circuit Cellar and Circuit Cellar INK are registered trademarks
of Circuit Cellar Inc. Reproduction of this publication in whole or in part without written consent from Circuit Cellar Inc. is prohibited.
CHIEF FINANCIAL OFFICER
Jeannette Ciarcia
CUSTOMER SERVICE
Elaine Johnston
CONTROLLER
Jeff Yanco
ART DIRECTOR
KC Prescott
GRAPHIC DESIGNER
Mary Turek
STAFF ENGINEER
John Gorsky
QUIZ COORDINATOR
David Tweed
Cover photograph Chris Rakoczy—Rakoczy Photography
PRINTED IN THE UNITED STATES
Get Secure
jennifer.huber@circuitcellar.com
TASK MANAGER
6
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
November 2004: Internet & Connectivity
TASK MANAGER
Get Secure
Jennifer Huber
FEATURES
COLUMNS
DEPARTMENTS
16 Simple Four-Channel Network Video Server
30 Math Coprocessor for Robotics Applications
38 Build a VGA Monitor Controller
44 Interface Ethernet and Embedded Systems
62 Network Security for Small Systems
TCP/IP Stack Solution
A Detailed Look at the CMX-MicroNet
Fred Eady
8
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
NEW PRODUCT NEWS
Edited by John Gorsky
Now available with one full watt of output power, the
ConnexLink transceivers can talk over distances of 20 miles
line-of-sight. Units can be set up
in minutes for cable-free commu-
nication between industrial RS-
232/422/485 devices, providing
reliable data transmissions of up
to 115.2 kbps.
ConnexLinks are small and eas-
ily portable for use in mobile and
temporary settings, as well as for
fixed installations. They can be
used as direct cable replacements,
requiring no special host software
for communication. Optional
drivers enable custom configura-
tions based on your needs.
Any number of remote
ConnexLinks can be set up in
point-to-point or point-to-multipoint configurations.
Unique networks can be co-located on-site. A unique
embedded protocol (RF232)
manages over-the-air concerns,
such as interference rejection,
error detection, addressing, secu-
rity, and link verification.
ConnexLinks operating in the
900-MHz frequency band are
approved for use in portable appli-
cations in the U.S., Canada,
Australia, and South America. To
suit the global marketplace, 2.4-
GHz modems are also available.
The modems cost $99 per
unit.
MODEMS SIMPLIFY LONG-RANGE WIRELESS CONNECTIVITY
RUGGED ETHERNET SWITCHES
The rugged ADAM 652x 10/100BaseT Ethernet switches
accept any voltage between 10 and 30 VDC with surge pro-
tection to 3,000 VDC. They are ideal for any DC environ-
ment.
The ADAM 6521 lets you interconnect four copper (RJ-45)
and one fiber-optic (SC) networks. The ADAM 6520 provides
five RJ-45 Ethernet ports. Both new ADAM modules are suit-
able for production lines, inventory systems, and conveyor
control. They automatically sense 10 or 100 Mbps speeds and
provide full- and half-duplex flow control. Their RJ-45 ports
connect to any 10/100BaseT Ethernet network. The modules
can also interconnect PCs that have Ethernet cards. For even
greater flexibility, the SC fiber-optic port on the ADAM 6521
makes it easy to connect 10/100BaseT copper networks to a
100Base-FX fiber-optic network.
The modules can mount on DIN rails, walls, and piggy-
back. Diagnostic LEDs on the front panel indicate power sta-
tus and networking status.
The module prices start at $150.
CAN BUS CHOKES
Suitable for ambient temperatures up to 150°C, the
new B82789XX series CAN bus chokes can be used in
demanding automotive applications including in the
immediate vicinity of the engine, gearboxes, engine
control units, and ABS or power steering systems. The
chokes minimize spurious emissions from automotive
electrical systems and suppress interference with on-
board electronics. Broadband damping of common-
mode noise can be set as needed with the various
choke inductances. Chokes with sectoral coils and
higher leakage inductance affect differential-mode
noise in the data signal and, as a result, any associated
interference with the RF signal. The CAN bus chokes
cover the inductance range from 11 to 100 µH.
The chokes are priced at $0.38 in 50,000-piece quantities.
10
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
NEW PRODUCT NEWS
INDUSTRIAL COMMUNICATIONS GATEWAY
The Medallion 38-000010-xxx is a compact industrial com-
puter designed for various communications concentrators,
translators, data loggers, and other applications. It integrates
a variety of communications interfaces with interchangeable
32-bit RISC processor modules running the Linux operating
system.
Multiple high-
efficiency switch-
ing power supplies
and a rugged, all-
aluminum packag-
ing make the
Medallion 38-
000010-xxx ideal
for communica-
tions rooms, pro-
duction floors, and
fleet vehicles.
This device is
designed to inte-
grate a variety of
legacy devices and
connect them to the Internet for remote data access, monitor-
ing, and control. Power consumption is less than 2 W. The
Medallion also supports most communication standards via
standard-based hardware interfaces and a Linux operating sys-
tem. So, the Medallion can handle both legacy and mod-
ern communications protocols.
By employing the Linux OS, you have access to almost
every communications protocol in use, including various
serial, multi-drop, Ethernet, 802.11, and even cellular
radios. You
can modify
the software,
extend it, add
applications,
and even cre-
ate a personal
encryption
scheme.
A develop-
ment kit is
available to
speed up the
development
of custom
software. The
Medallion 38-
000010-xxx costs less than $900 in single quantities.
12
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
NEW PRODUCT NEWS
The R108 HyperCore microprocessor core module is based
on the Silicon Laboratories 8051 System-on-a-Chip proces-
sor. It combines 64 KB flash memory, 128-KB SRAM, and a
vast array of I/O, serial communications capabilities, and
connectors to enhance integration with most controller proj-
ect designs.
The HyperCore comes standard with up to 16 precision
analog channels with up to 12-bit resolution. Two 12-bit
analog outputs are also avail-
able. The HyperCore is readi-
ly adaptable into the produc-
tion platforms of many proj-
ects because of its small
footprint, low cost, and the
high performance of the 25-
MIPS microprocessor.
Communications capabili-
ties include two serial ports,
one RS-232, and one TTL. SPI
and I
2
C are also supported. A
JTAG port is provided for
connecting to a PC for pro-
gramming in C language.
BASIC programming is
accomplished through the
serial port. The HyperCore operates at 5 to 9 VDC and
consumes less than 0.25 W. Power monitoring and Sleep
mode functions are supported.
Two HyperCore module development kits are available.
The basic development kit, which is used for program-
ming in BASIC, includes a development board, a R108
HyperCore core module, a power transformer, a serial
cable, and a CD with the BASIC interpreter software, the
API, the operating instruc-
tions, and sample programs.
The celuxe development kit
contains all of these compo-
nents, plus a programming
adapter and cable, which
enable the R108 HyperCore
to be programmed in C.
The basic development kit
costs $169. The deluxe devel-
opment kit costs $229. The
R108 HyperCore micro-
processor core module costs
$79.
HIGH-PERFORMANCE MICROPROCESSOR CORE MODULE
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
13
NEW PRODUCT NEWS
cations with an embedded VPN gateway throughput of
50 Mbps. The combination of the standard Linux ker-
nel, integrated drivers, and communication utilities
means the development kit can be used to quickly cre-
ate remote monitoring systems, security appliances,
and wireless industrial network gateways.
The development kit includes the IXP425-based MER-
CURY PC/104 SBC fitted
with 16 MB of AMD
MirrorBit flash memory
and 256 KB of SRAM. The
board is housed in a com-
pact enclosure (MER-
CURY-ICE) with breakout
cables and a tamper detec-
tion switch. The kit also
includes an AC PSU,
cables to connect to your
host system, and a com-
prehensive information/
software CD.
The development kit
costs $1,295.
An embedded Linux Development Kit for Arcom’s
IXP425 Xscale-based network processor board is now
available. The Intel IXP425-based MERCURY board
includes two 100baseTx Ethernet ports, four high-speed
USB 2.0 ports, three RS-232 ports, and one RS-422/485
port. The board is fitted with 64 MB of soldered DRAM
and 16 MB of flash memory, along with a CompactFlash
port and a PC/104 expan-
sion bus.
The development kit is
a ready-to-run embedded
Linux system with full
support for all on-board
peripherals. The operating
system also supports the
Ethernet-based hardware
accelerated encryption
(AES, DES, 3DES) and
authentication (SHA-1,
MD5) capabilities of the
IXP425 device. By using
its integrated network
processor engines, the
MERCURY provides
secure, high-performance,
Ethernet-based communi-
LINUX DEVELOPMENT KIT FOR Xscale-BASED SBC
ty gateway. The server is a serial-to-Ethernet converter con-
nected to remotely located serial-enabled equipment. The
client is software that creates a virtual serial port on your
PC. The gateway is a Wavetrix-managed communications
service that facilitates connections between clients and
servers. It functions as the administrative control point.
To use the system, you log into the gateway via the
client. You are presented with a list of his authorized
servers. After selecting the desired server, you have estab-
lished a real-time connection and are ready to go.
A starter kit includes a con-
nectivity server and client,
and a three-month subscrip-
tion to the connectivity gate-
way. The introductory price
for the Traversix Connectivity
System starter kit is $499.95.
14
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
NEW PRODUCT NEWS
REAL-TIME CLOCKS HAVE BROAD FEATURE SET
The DS139x is a new family of three-wire, four-wire, and
SPI-bus real-time clocks. These clocks feature automatic power
switching, trickle-charge output, alarm, microprocessor reset,
and square-wave output or periodic interrupt. The DS139x ICs
are available in a small 10-pin SOP package—the smallest foot-
print in the industry when compared to other real-time clocks
with an SPI or three-wire interface. These new RTCs are ideal
for hand-held equipment applications.
The DS1390 and DS1391 use the four-wire or SPI bus
interface. The DS1392 and DS1393 use the three-wire inter-
face. All four parts monitor V
CC
and, when a power-failure
occurs, they write-protect the internal registers and switch to
back-up power to prevent data corruption. In Low Power
mode, the oscillator maintains timekeeping down to 1.3 V,
consuming less than 1 µA of current. A built-in, trickle-
charging circuit backs
up the DS139x ICs
with a super capacitor
or rechargeable bat-
tery. The remaining
available pins are con-
figured in a combina-
tion of microprocessor
reset, square-wave out-
put, or periodic inter-
rupt for even more
added value in the
small 3 mm × 5 mm
package.
The DS139x ICs are rated for operation over the industrial
temperature range of –40° to 85°C. Pricing starts at $1.25 for
quantities of 1,000.
3.5
″″
EBX CPU BOARD
The AR-B1551 is a tightly designed 3.5” EBX CPU
board with an on-board, low-power, fan-less NS
GeodeT 300-MH processor. The NS GeodeT GX1 inte-
grated 2-D graphic accelerator supports CRT, single-
channel, 18-bit LVDS panels (up to 1,024 × 1,280). The
on-board AC97 audio chip paired with the audio board
provides microphone in, CD audio in, and line-in and
line-out capabilities.
The AR-B1551 has a build-in Realtek 8139C
10/100BaseTx fast Ethernet port, two COM ports, two
USB ports, one parallel port, and one IrDA port.
The on-board CompactFlash slot provides a highly
reliable and cost-effective storage solution in extreme
shock, vibration, temperature, and harsh environmen-
tal conditions. The AR-B1551 also has a stackable PC-
104 expansion slot for extra PC-104 peripherals or ana-
log/digital I/O devices.
The AR-B1551 costs $280.
The Traversix Connectivity System is the first managed
service offering secure, seamless access to remotely located
assets. The Traversix Connectivity System is a “no touch”
solution to securely connect a customer at his PC through
the Internet to remotely located serial devices anywhere in
the world. Unlike standard serial-to-Ethernet products, the
Traversix Connectivity System initiates only outbound con-
nections from remote locations to a central gateway using
communication links secured by SSL and 128-bit AES encryp-
tion. In addition, the Traversix Connectivity System central-
izes system administration and
authentication, providing a sin-
gle point of control and manage-
ment for your remotely located
assets.
The Traversix Connectivity
System consists of three compo-
nents: the TCS-1002 connectivi-
ty server, the TCC-1000 connec-
tivity client, and the connectivi-
SYSTEM ENHANCES SECURITY, SIMPLIFIES REMOTE ACCESS
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
15
You may contact the quizmasters at eq@circuitcellar.com
CIRCUIT CELLAR
—
T e s t Y o u r E Q
Problem 3
—What is a limited-weight
data code?
Problem 4
—What are good applica-
tions for limited-weight codes?
Contributed by David Tweed
Edited by David Tweed
Problem 1
—You’re building a basic 5-VDC
power supply that will have a maximum load of
1 A. You have a 10-VAC transformer, a bridge
rectifier, and a 7805 three-terminal regulator.
You need to select the primary filter capacitor
that sits between the rectifier and the regulator.
How large should it be: 400, 2,000, 10,000 µF?
Problem 2
—Using a capacitor that’s larger than
necessary will reduce the input ripple to the
regulator, and will therefore reduce the output
ripple by a small amount as well (although the
line regulation of a three-terminal regulator is
pretty good). However, there are drawbacks to
using an oversize capacitor. Can you name
some?
16
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
a device that allows for the web enabling
of a number of inexpensive NTSC cam-
eras. The price tag, however, is still
above the $1,000 mark.
Alas, there was only one (legal) solu-
tion: I had to design my own. In this
article, I’ll show you how I did it for a
few hundred dollars.
CAMERAS VS. SERVERS
The fundamental downside of IP
W
hen mysterious holes
started appearing overnight
in the flower bed in front of
my house, I decided to set up
a video surveillance system.
No, I am not referring to
alien crop circles. It seemed
as though a local cat or dog
had developed an interest in
digging up fresh mulch. (Or
could it have been a mischie-
vous prankster?)
Of course, I could have
gone to my local Radio
Shack, picked up some cam-
eras, and hooked them up to
a conventional VCR. But
seriously, that would have
been way too easy! Besides, regular VCR
tapes last only eight hours. Time-lapse
VCRs can do better, but they are much
more expensive. In both cases, the same
tape is recycled over and over again,
and the image quality quickly suffers.
Clearly, I needed something better.
At the time, I had recently undertaken
the painstaking task of running Ethernet
cabling throughout my house. The house-
wide network called for a high-tech solu-
tion: IP cameras. A quick trip to the ’Net
revealed a number of options. One of
the IP camera market leaders, Axis
Communications, offers a range of IP
cameras priced between $200 and $2,000
depending on the options. Unfortunately,
when I considered the number of required
cameras, this quickly added up to an
expensive proposition. Several thousands
of dollars is way more than I was willing
to spend! A cheaper alternative is a mul-
tichannel network video server, which is
cameras is that their
internal IP network cir-
cuitry and protocol have
to be replicated in each
camera. This inherently
increases the cost. The
multichannel network
video server is a simpler
alternative (see Figure 1).
Unlike an IP camera, a
video server allows for the
network enabling of a num-
ber of inexpensive conven-
tional NTSC surveillance
cameras. You can even use
inexpensive board cameras,
or, for that matter, anything
that outputs a video signal,
as a video source. Essentially, the video
server contains a single IP network stack
and circuitry shared amongst the multiple
video inputs. When you do the math, this
approach is more economical per channel.
A few companies offer stand-alone
network video servers. Unfortunately,
to reduce the competition for their IP
camera products, these companies tend
to price video servers in the $1,000 to
$2,000 range for four channels.
FEATURE ARTICLE
by Eric Gagnon
PIR Sensor 1
Camera 1
10/100BaseT Ethernet network
Optional video monitor
Remote file
server PC
Camera 4
PIR Sensor 4
Camera 3
PIR Sensor 3
Camera 2
PIR Sensor 2
Network video server
1
4
2
3
Figure 1—
In this network video server system, four conventional NTSC video cameras
connect directly to the video server. The server web-enables the video cameras and pro-
vides a standard Ethernet network interface. The images are transferred over the network
to a central image repository. Optional triggers also may be used to trigger image capture.
Eric recently built a video surveillance system to monitor his property when he isn’t home.
He saved a lot of money by incorporating a four-channel network video server rather than
expensive IP cameras. The video server, which Internet-enables four conventional NTSC
cameras, provides a standard Ethernet network interface.
Simple Four-Channel Network Video Server
Analog
mux
Analog video
inputs
Analog-to-digital
converter
Frame
grabber
Compressor
Ethernet
interface
Ethernet
Video decoder
Figure 2—
Internally, a multichannel network video server typically includes an analog input multiplexer, a frame
grabber, a video compression system, and an Ethernet interface. Integrating these functions in a cost-effective
manner is the key to success.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November
2004
17
The circuitry inside a single multi-
channel network video server is sub-
stantially similar to that of a single IP
camera (with the exception of high-
performance servers that provide par-
allel circuitry to digitize and process
multiple incoming video signals). For
most applications, however, a simple
regular or low-performance multi-
plexed server is adequate.
Figure 2 shows the guts of a typical
multichannel network video server.
The internals usually consist of an ana-
log input multiplexer, a frame grabber,
a video compression system, and an
Ethernet interface usually powered by a
high-performance MCU running an OS
with a network stack. The goal for this
project is to integrate these various
elements in a cost-effective manner.
SERVER ARCHITECTURE
In my last article, I intro-
duced you to my microcon-
troller frame grabber
(µCFG), which is a com-
pact, versatile, stand-alone
frame grabber module with
a simple serial interface
(“Full-Field Color Video
Frame Grabber,” issue 168,
July 2004). The module can
capture images from up to
four video signals and
download the digitized
samples through a simple
UART interface (see Photo
1). A simple video com-
pression algorithm speeds
up serial transfers. The
inexpensive module is a
perfect fit for this low-
cost video server. The full
evaluation kit includes a
frame grabber module, a
small motherboard host-
ing various connectors,
and an RS-232 level
shifter.
Because the frame grab-
ber handles the video digi-
tization process, all you
need now is a way to
interface to the module
using a simple UART
while also serving out the
data over Ethernet. Enter
the eZ80Acclaim!
Zilog has made waves this past year
with the introduction of its eZ80F91
8-bit microcontroller with built-in
10/100BaseT MAC, as well as its free
ZTP networking stack and operating
system. This 50-MHz miniature work-
horse boasts impressive specifications:
256 KB of on-board flash memory, 16
KB of SRAM, two UARTs, a full exter-
nal memory bus, I
2
C, IrDA, an SPI,
and an internal real-time clock with
external backup!
The folks at Zilog also have been
extra busy making sure that all the
support software is right. Zilog offers a
comprehensive free C compiler tool
suite. The ZDS-II IDE has a built-in
debugger and, most importantly, a roy-
alty-free ZTP networking stack. To
start development, I simply bought a
$99 development kit (see Photo 2).
All the elements including the C
compiler and network stack are pro-
vided in the kit. The development
board conveniently provides two
buffered RS-232 ports, one for a user
console to send status messages and
one for interfacing to the frame grab-
ber evaluation kit.
The video server’s architecture is
shown in Figure 3. Essentially, the
frame grabber evaluation kit is con-
nected directly to the eZ80F91 devel-
opment kit’s COM1, which is labeled
as the modem port on the kit. This is
done with a straight through male-to-
female DE-9 cable because COM1 is
wired as a DTE. External trigger inputs
signals are also wired to the
frame grabber evaluation kit.
In this case, an array of pas-
sive infrared (PIR) motion
detectors was hooked up.
Four surveillance cameras
were connected, one to each
of the four channels, with
one PIR sensor associated
with each camera. Finally, a
live video out monitor was
also connected to the video
output for live viewing and
setup of the cameras.
GRABBING FRAMES
The frame grabber mod-
ule allows for the digitiza-
Photo 1—
The frame grabber module is on the left. It provides four ana-
log video inputs (or two S-Video), one live video preview output, and a
simple LVTTL serial UART interface to download a captured image. On
the right is the frame grabber motherboard included in the evaluation kit.
It hosts various connectors as well as an RS-232 level shifter for the
frame grabber module.
Photo 2—
The Zilog eZ80F91 development kit
(eZ80F910200ZCO) comes complete with a develop-
ment board, an Ethernet-enabled emulator (ZPAK-II), a
network switch, patch cables, manuals, and a number
of DC adapters. It’s a real trick to fit everything in the
box. In fact, after you do open the box and remove any
of the items, good luck trying to close it back up!
Live video
preview output
External triggers
Digital Creation Labs
µCFGEVAL kit
RS-232 M/F
straight-
through
cable
SERIAL 1
Zilog eZ80F91
evaluation kit
SERIAL 0
Ethernet
RS-232 Console
(for debugging)
Analog video
inputs
Figure 3—
The overall network video server architecture involves interfacing a frame
grabber evaluation kit with the eZ80F91 evaluation board through an RS-232 straight-
through cable. It couldn’t be simpler! But don’t be deceived by the apparent simplicity;
a lot is going on inside each of these modules. External trigger inputs are provided to
trigger the frame grabber evaluation kit by PIR intrusion sensors.
18
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
tion of a single field of color video into
an on-board field buffer. Following the
field capture, the image data can be read
out over the serial interface. Four analog
composite video inputs are provided
that support both NTSC and PAL.
To control the frame grabber, a sim-
ple ASCII command set is used. For
example, to select video channel 1, the
CSEL 1 command is sent. Channel 1 is
immediately selected and also simulta-
neously displayed on the live preview
output channel. To acquire the next
odd video field, the
GRAB O command
is issued.
[1]
The frame grabber also can be
optionally triggered externally through
one of four external trigger pins. Each
of the triggers is associated with a corre-
sponding video input. For instance, if a
PIR intrusion sensor connected to trig-
ger 1 detects the presence of a person, it
will trigger the capture of an image on
camera 1. It’s then possible to poll the
frame grabber trigger status using the
trigger read command.
To make things even simpler and to
prevent overwriting the image buffer
during an image download, a simple
trigger latch mechanism is also provid-
ed. Using this mechanism, only the
first trigger will capture a video field
into the buffer. Any subsequent triggers
will be ignored until the trigger latch
clear command (TRLC) is issued. The
trigger latch read command (TRLR) can
poll the trigger latch. This latch holds
the identity of the last trigger activated,
whose acquired image is currently
waiting in the video buffer. Following
the downloading of the image data with
a series of
SEND commands, the trigger
latch can be cleared for the process to
start again.
The frame grabber has many config-
urable options that can be set using the
set-up/viewing utility included in the
kit. These options are stored in EEP-
ROM onboard the frame grabber. For
this project, the one-shot trigger latch
option was enabled, and the start-up
data rate was set to 57.6 kbps. Even
though the frame grabber can support
data rates up to 230.4 kbps, the Zilog
ZTP stack currently supports data
rates only up to 57.6 kbps. By the time
this article sees print, however, the
new ZTP 1.4 should be out including a
new real-time operating system called
RZK. It should greatly improve sys-
tem performance and allow faster
UART data rates.
RIDE ON THE ETHER
Commercial network video servers
typically offer various options to serve
out images over a network. For exam-
ple, one way to view image data is by
using the HTTP protocol through a
web browser interface. (This approach
also can be used to set up the unit.)
Another option is to have the server
automatically “push” acquired images
onto a dedicated FTP server in response
to an external trigger signal (or simply
at a predetermined periodic update
interval). In addition, the server may
also automatically send e-mail notifica-
tion to a fixed e-mail address to indi-
cate that a trigger was detected. Finally,
it is also possible to use proprietary
techniques to stream the video over
UDP with custom viewing software.
My requirements for this simple net-
work video server system were to have
four PIR motion sensors distributed
around the house (each located next to
its own camera). After detecting a trig-
ger, the video server acquires an image
and automatically pushes it onto a cen-
tral file repository on my local home
network (in this case, my PC). As well,
I wanted to be able to arbitrarily soft-
trigger any of the cameras over the
network at any time.
To fulfill these requirements, I
closely examined the Zilog ZTP pro-
tocol stack documentation. I noticed
that FTP was not yet supported. (It
should be in ZTP 1.4.) Instead, the
simpler trivial file transfer protocol
(TFTP) was supported. TFTP is a
lightweight file transfer protocol based
on UDP (instead of TCP). It is not
nearly as full-featured as the FTP pro-
tocol; but as such, the reduced over-
head also results in faster data trans-
fers on a local network. A caveat: The
TFTP protocol uses packet-level
acknowledgement from the remote
server, so performance is reduced if
you send images over the Internet as
compared to FTP, which uses sliding
window acknowledgments. On a local
network (like my house LAN), TFTP
should be faster.
To be able to arbitrarily trigger my
cameras, I decided to use the Telnet
protocol. ZTP offers the ability to open
a Telnet session and provides a full-
featured user shell with a number of
useful network diagnostic commands.
Listing 1 shows how I managed to add
four unique commands to this shell by
adding a few lines of code to the ZTP
demonstration program provided in
the kit.
Be sure to correctly reflect the num-
ber of new commands in the
getmem()
call during the allocation of the
mycmds array, and also in the
shell_add_commands() call. That’s
all there is to it. By opening a Telnet
shell and typing
HELP, my four new
commands instantly appeared and were
ready to be used! I now had the ability
to remotely trigger a frame grab on any
of the four cameras!
The final part of the implementation
involved interfacing with the frame
grabber over UART1 on the eZ80F91
development board. Fortunately, I did-
n’t need to spend too much time writ-
ing buffered UART drivers because the
Zilog OS already provides a standard
driver model that supports the UART.
Setting up UART1 was simply a matter
of modifying the serial_conf.c project
file to set up the default UART1
parameters (i.e., 57.6 kbps, 8N1, no
handshake). After that, I simply made
an
open(SERIAL1, 0,0) call, and the
UART was ready to be used with the
read(), write(), putc(), getc()
commands.
I did, however, come across one
stumbling block. Because these func-
tion calls are generic driver calls and
not specifically tied to serial ports,
they are all blocking by default. I
needed to be able to flush the incom-
ing UART1 buffer to clear it of any
garbage characters before being able to
correctly parse replies from the frame
grabber. Unfortunately, I didn’t find
such a command at first. I could have
also accomplished this with a com-
mand that told me if the incoming
queue was empty; then I could read
them out until empty. I didn’t find
any more information in the manuals.
Eventually, I sent an e-mail to Zilog’s
technical support staff. I got a reply
within 12 hours. There was an undoc-
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November
2004
19
Listing 1—
I managed to add four new commands (
trig1
through
trig4
) to the existing Telnet shell
command list to remotely trigger an image capture by adding only a few lines of code.
static char *mail_name=”mail”;
static char *tftpdemo_name=”tftpdemo”;
static char *trig1_name=”trig1”;
static char *trig2_name=”trig2”;
static char *trig3_name=”trig3”;
static char *trig4_name=”trig4”;
DID fd_uart1;
unsigned char soft_trigger;
void x_trig1_cmd(void)
{
soft_trigger = 1; // Telnet command to issue soft trigger 1
}
void x_trig2_cmd(void)
{
soft_trigger = 2; // Telnet command to issue soft trigger 2
}
void x_trig3_cmd(void)
{
soft_trigger = 3; // Telnet command to issue soft trigger 3
}
void x_trig4_cmd(void)
{
soft_trigger = 4;
// Telnet command to issue soft trigger 4
}
SYSCALL
main(void)
{
DID
fd;
struct cmdent
*mycmds;
char filename[30];
mycmds = (struct cmdent *) getmem( sizeof(struct cmdent) * 6);
/* Set up mail and tftpdemo commands */
mycmds[0].cmdnam = mail_name;
mycmds[0].cbuiltin = TRUE;
mycmds[0].cproc = (SHELL_CMD)x_mail;
mycmds[0].cnext=(struct cmdent *)NULL;
mycmds[1].cmdnam = tftpdemo_name;
mycmds[1].cbuiltin = TRUE;
mycmds[1].cproc = (SHELL_CMD)x_tftpdemo;
mycmds[1].cnext=(struct cmdent *)NULL;
mycmds[2].cmdnam = trig1_name;
mycmds[2].cbuiltin = TRUE;
mycmds[2].cproc = (SHELL_CMD)x_trig1_cmd;
mycmds[2].cnext=(struct cmdent *)NULL;
mycmds[3].cmdnam = trig2_name;
mycmds[3].cbuiltin = TRUE;
mycmds[3].cproc = (SHELL_CMD)x_trig2_cmd;
mycmds[3].cnext=(struct cmdent *)NULL;
mycmds[4].cmdnam = trig3_name;
mycmds[4].cbuiltin = TRUE;
mycmds[4].cproc = (SHELL_CMD)x_trig3_cmd;
mycmds[4].cnext=(struct cmdent *)NULL;
mycmds[5].cmdnam = trig4_name;
mycmds[5].cbuiltin = TRUE;
mycmds[5].cproc = (SHELL_CMD)x_trig4_cmd;
mycmds[5].cnext=(struct cmdent *)NULL;
/*
* Start the network and TCP/IP daemons
*/
netstart();
/* Make the network-related shell commands available to all shells */
shell_add_commands(netcmds, nnetcmds);
/* Add TFTP, SMTP demo commands */
shell_add_commands(mycmds, 6);
.
.
.
20
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
umented
SerPeek() function! I
quickly implemented my flush com-
mand and was back in business.
Sending serial commands to the
frame grabber is simple. Flush the
UART buffer first. Next, send an ASCII
string, and then parse the reply. In some
cases, the commands simply return an
*OK or *ERROR as a reply. The frame
grabber was configured to grab an image
automatically following an external
hardware (or software) trigger on a
respective camera channel. To detect
the trigger, the TRLR command is peri-
odically issued, and the binary-encoded
byte reply is checked. If no triggers have
been detected, a zero is returned; other-
wise, the bit position will indicate the
last trigger detected (whose image is
currently waiting in the image buffer).
The polling was set at a 1-s interval.
Because the Zilog OS is a multithread-
ed OS, the main thread of execution is
set up to simply poll the trigger latch
and then go to sleep for 1 s.
After trigger activation has been
detected, a series of
SEND commands
is issued to download the entire com-
pressed image data into a local SRAM
buffer for the subsequent call to the
TFTP command. It probably would
have been possible to send the data on
the fly directly from the frame grabber
to the network for faster performance,
but the default TFTP implementation
simply provides a local memory start
address and the buffer length as
parameters, so I opted to simply oper-
ate out of internal memory.
After the entire image is buffered in
local memory, basic file header infor-
mation is added to the image data, and
the TFTP command is called with the IP
address of the TFTP server. In the blink
of an eye, the entire image is transferred!
I devised a simple filename generator in
the firmware to ensure that the images
didn’t get overwritten on the file server.
When the system is started, the naming
convention is “TRn_0001.DCL,” where
n
corresponds to the trigger/camera
number, and the sequence number incre-
ments by one each time. Of course,
each image file is also automatically
assigned a timestamp when written on
the TFTP server.
Following an image transfer, the
TRLC trigger latch clear is issued to
resume operation. The Telnet
trig1
through
trig4 commands also cause
the
TRIG n soft trigger commands to be
issued. This has the same effect as a
hardware trigger, and it allows for the
remote triggering of the cameras over
the network at any time. Listing 2
shows the main thread of execution.
TFTP SERVER
On the PC side, TFTP server software
is required to answer the network video
server requests and store the image files.
After a quick ’Net search, I came across
SolarWinds.Net, which offers a freeware
multithreaded TFTP server with a lot
of great features (www.solarwinds.net).
Photo 3 is the main screen.
Setting up the software was easy.
First, I simply indicated the target direc-
tory on my PC where the image files
would be saved. Second, I chose to
allow only TFTP write access to exter-
nal clients. This offers a bit of security
against someone else on the local net-
work gaining access to the images. For
even more security, you can specify the
IP addresses of clients who are allowed
to access the server. The TFTP server’s
control panel also features a user-read-
able log that shows file transfer activi-
ty, which is extremely useful for debug-
ging. When it’s set up, just let it run!
PC SOFTWARE
At this stage, I had a system capable
of automatically pushing images in
response to soft or hard triggers from up
Listing 2—
This is the main thread of execution of the network video server. First, a check is performed to
see if a soft trigger request was issued over the Telnet interface. The trigger latch on the frame grabber is
then polled for activity. If triggers are detected, the image is buffered locally and then sent to the remote file
server via TFTP.
video_server_init();
// Initialize the video server
soft_trigger = 0;
// No soft triggers issued
for (;;)
// Main thread
{
if (soft_trigger)
// If a user issued a soft trigger command
{
// through telnet
ucfg_soft_trigger(soft_trigger);// Send soft trigger command
kprintf(“Soft trigger command issued\n”);
KE_TaskSleep10(1);
// Sleep 100 ms to give frame
// grabber a chance to grab a frame
soft_trigger = 0;
// Clear soft trigger
}
if (video_server_triggered()) // If a trigger on uCFG was latched
{
kprintf(“Trigger latch: %d\n”, trigger);
// Transfer image from uCFG to local mem
video_server_buffer_ucfg_image();
// Generate a sequential filename
video_server_generate_filename(filename);
// Push image to TFTP repository server
video_server_push_image_tftp(filename);
ucfg_clear_trigger_latch();
// Clear trigger latch to re-enable uCFG
}
KE_TaskSleep(1);
// Sleep for 1 s
}
Photo 3—
Take a look at the SolarWinds.Net freeware
TFTP server. The setup is easy, and it provides a lot of
flexibility such as controlling read/write access as well
as restricting the source IP addresses of the clients.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November
2004
21
to four cameras onto a specific directory
located on a remote file server PC. All
that was left to implement was a file-
based image viewing utility. To do so,
I simply modified the frame grabber
viewer software source code that comes
with the frame grabber evaluation kit.
The code is implemented in Visual
C++ 6.0 with MFC. The new function-
ality involved adding a Load File but-
ton on the GUI. The implementation
of this button callback simply opens a
file dialog that prompts you to select a
file from the image repository. After
that’s done, the .dcl file is read in and
decoded as usual with the frame grab-
ber routines and displayed as a bitmap
on the screen (see Photo 4).
CAUGHT ON CAMERA!
Well, time to put this system to the
test. Photo 5 shows the final system
setup with the cameras, trig-
gers, and development kits
hooked up. I installed the
PIR sensors and cameras at
my front door and kitchen
window. Others monitor my
hallway and the back door.
The system runs on its
own, grabbing images as
people walk up to the doors.
All the images are automati-
cally collected on my PC.
Photo 4 shows a screen shot
of the PC file-based viewer
utility reviewing some fresh-
ly acquired pictures of the
front door entrance.
Using the Telnet utility, I
can also remotely trigger an image
capture at any time. The time delay
between a trigger activation and an
image fully written to the server is
approximately 36 s for full color, 2:1
compression 720 × 240. Most of this
time is spent buffering the video
image from the frame grabber to the
eZ80F91’s local SRAM buffer over the
serial port. The TFTP image transfer
itself takes approximately 1 s on my
local network.
UPGRADE AWAY
Hopefully, this article has given you
some insight into the inner workings of
a simple four-channel network video
server. Will you set out on your own
quest to build a sophisticated Ethernet-
based home alarm system? (HCS III?)
There are a number of improve-
ments that could speed up the sys-
tem’s performance. The
first improvements could
stem from enhancements
in the new ZTP 1.4
release. This should
increase the maximum
UART data rate from the
current 57.6 kbps to a
higher rate. By removing
the need to buffer the
frame grabber video
image in local eZ80F91
memory first, faster
transfers also can be
achieved.
The new ZTP release
will support FTP, which
would be useful for viewing
Eric Gagnon, M.A.Sc., P.E., has been
hooked on electronics since the age of
12. He earned both his degrees in elec-
trical engineering from the University
of Ottawa. Eric has more than 10 years
of embedded design experience. He has
worked on projects related to the
International Space Station, industrial
robotics, 3-D machine vision, and
embedded video. Eric currently runs
Digital Creation Labs (www.digital
creationlabs.com). You can contact him
at egagnon@digitalcreationlabs.com.
PROJECT FILES
To download the code, go to ftp.circuit-
cellar.com/pub/Circuit_Cellar/2004/172.
REFERENCE
[1] Digital Creation Labs, Inc. “µCFG
Full Datasheet,” rev 1.0, 2004,
www.digitalcreationlabs.com/
support.htm.
SOURCES
IP cameras and network video servers
Axis Communications
www.axis.com
Freeware TFTP server
SolarWinds.Net
www.solarwinds.net
eZ80F91 Development kit
Zilog
www.zilog.com
Photo 4—
Here you see the PC-based file viewing utility reviewing a
picture of the front door entrance. The frame grabber viewer source
code was modified to add a Load File button to load and display the
.dcl compressed image files.
Photo 5—
In the final network video server setup, the frame grabber eval-
uation kit is connected to the eZ80F91 development kit, four external
cameras of various shapes and sizes, and a live preview video monitor for
easy camera adjustment. PIR motion detectors (not shown) are also used
to trigger image capture.
images over the Internet instead of
using the TFTP approach. FTP also
adds password protection. An HTTP
web browser interface could be added
for viewing images or parameter set up.
Finally, note that e-mail trigger notifi-
cation also would be a useful feature.
Well, after setting up the video sur-
veillance system, I must confess I didn’t
capture an image of the hole-digging
culprit. As the saying goes: a watched
kettle never boils. But then again, one
day the holes disappeared as quickly
as they had started appearing. Ah,
well, on to the next project!
I
24
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
protocol in order to read the data out of
the unit. You also need to build a base
station for your PC or laptop that needs
to be compatible with the RF modula-
tion in your modem. These modems are
advantageous because they are relatively
low-powered. Because I can design my
own protocol, there is a lot of flexibility.
In the end, I settled on Wi-Fi. Although
not particularly low-powered, Wi-Fi has
other advantages. Off-the-shelf Wi-Fi
cards cost about as much as a nice duplex
900-MHz modem module. They are stan-
dard and can interoperate with any other
Wi-Fi card or access point. Also, many
people already have a Wi-Fi network at
home, so the cost of integrating a Wi-Fi-
based data logger in your network is pret-
ty much zero in comparison to running
cables or using proprietary RF modems.
Let’s dive into the details by review-
ing some information about solar pan-
els. Later I’ll describe the data logger
design and implementation.
SOLAR PANELS
Designing a solar-powered project can
be a challenge. The objective is to collect
enough solar power to power the device.
I
moved to California because of some
economic changes that have occurred
during the last few years. The sunny area
in which I currently live has little rainfall
between April and November. Thus, it’s
kind of fitting that I would consider build-
ing a solar-powered data collector whose
main job is to record sunlight exposure.
Many people in these parts have solar
collectors (or are planning on installing
them). My Sunlogger is a device that
helps you decide where to install solar
panels. In addition, you can use it to
monitor the efficiency of your main
solar collectors.
SUNLOGGER SCHEMES
The Sunlogger must be placed outside,
so it makes sense to make it rugged and
as self-sufficient as possible. After con-
sidering several design ideas, I settled
on using a waterproof plastic enclosure
(see Photo 1a). To reduce the risk of
leakage, there shouldn’t be a physical
connection between the electronics
inside and outside the enclosure.
It’s easy to conceive that the unit
should be solar-powered so that exter-
nal power supplies and, more impor-
tantly, cables aren’t needed. But how do
you get the data out of the unit? In one
scheme, the unit would collect data for
a long time, until it is retrieved, opened
up, and read out via a cable. Although
this would be an easy solution, imagine
if the unit is on the roof of your house.
It would be a hassle to climb a ladder
each day to get the data.
Another scheme would be to use
some kind of wireless connection. I have
looked into using 900-MHz RF modems
(like those from Linx Technologies), but
although certainly usable, they require a
Approximately 1 kW of solar power irra-
diates each square meter of earth when
the sun is directly overhead on a clear
day. This is a lot of power. Harnessing
it, however, turns out to be tricky.
The best photovoltaic solar panels
can convert approximately 20% of solar
power into electrical power. These are
expensive panels used in applications
where efficiency is more important
than cost. Satellites and space probes
are one example.
Affordable panels can convert at less
than 10% efficiency. The flexible solar
panels I used (made by Iowa Thin Film)
come in a variety of sizes and configura-
tions. I chose a 74 mm × 150 mm panel
that has an operating current of 100 mA
and an operating voltage of 3.6 V. I made
this decision because I needed a panel
that outputs 3.6 V (you’ll learn why
later) and fits in the clear enclosure
without wasting too much unused area.
Photo 1b shows what this looks like.
The power density for this panel
works out to be the following:
P
=
mA 3.6 V
mm
150mm
= 32 W/m
DENSITY
2
100
274
×
×
FEATURE ARTICLE
by Ingo Cyliax
Wi-Fi Sunlogger
Photo 1a—
A clear case like this is designed to be waterproof. A Gortex membrane blocks water while passing air in
order to let the case breathe when there are pressure changes. b—The solar panel fits perfectly in the selected case.
a)
b)
Ingo’s Wi-Fi Sunlogger is a solar-powered data collector that records sunlight exposure.This
RCM3400-based device is the perfect tool to have on hand when scouting out sites for solar
panel installation.
which works out to be
3.2% when the sun is
shining directly overhead.
I expect approximately
360-mW peak power out-
put from this panel when
the sun is shining over-
head. The output power
of the panel is further
derated by the conditions
in Table 1.
Furthermore, the
amount of sun available
varies depending on the
location and average cloud
coverage. The solar power industry has
collected data for various localities in
the world called insolation tables. Refer
to the Resources section at the end of
this article for links to the tables. The
values given are the equivalent (kilo-
watt-hours per day) for both peak (sum-
mer) and low (winter) periods, as well
as the yearly average. These figures
help you design power budgets for solar
systems based on your location.
Here are some sample entries.
Although sunny Davis, California
receives an average of 5.1 kWh per day,
it pales in comparison to places like
Phoenix, Arizona and Death Valley,
California (see Table 2). Anyone who
has ever been to either of these places
knows what it feels like (see Photo 2).
If you want to design a system that
can be solar powered year round, choose
the low value and derate it with the effi-
ciency of the panel as well as the collec-
tion area. The following is my energy
budget for Davis.
CHARGE NiMH BATTERIES
One strategy would be to run the sys-
tem only when there is enough power
to power it directly. However, that
P
day
= 3.31 kWh 3%
74 mm 150 mm =
110 mWH
day
×
×
×
( )
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
25
doesn’t provide much run time, and it
won’t allow you to collect data when
the sun isn’t near its peak capacity.
Another strategy is to use a buffer bat-
tery to store energy when the sun isn’t
out. I chose a 3.6-V NiMH battery with
1,200-mAH capacity. The main reason I
chose a 3.6-V system is so I can power
3.3-V electronics directly from the bat-
tery without using a regulator. I use a
Schottky diode to drop about 0.3 V from
the battery system. Most 3.3-V electron-
ics actually have a wide operating range.
For instance, the processor I use has a
range between 2.8 and 3.6 V. However,
the CompactFlash wireless card can
only operate within 10% of its nominal
3.3 V. Nevertheless, the operating range
is suitable for a 3.6-V battery system.
We can safely charge a NiMH battery
with a trickle charge of C/10. The
charging efficiency is around 66%, so it
would need about 15 h to charge com-
pletely. Because the battery is rated at
C = 1200 mAH, the maximum charge
current of 100 mA from the solar panel
is extremely safe. The battery’s capacity
size depends on the type of duty cycle
you expect from your system. The aver-
age solar insolation values give you an
averaged value. It’s entirely possible that
on some days the actual solar insolation
is less than the average. The battery
capacity then dictates how long the sys-
tem can still manage to run. In my case,
the battery could bridge the following:
or approximately 25 sunless days, which
seems more than adequate. A smaller
battery with this panel would suffice.
Because the panel’s maximum current
3 6
. V 1,200 mA
0.66/110 mWh/day
× ×
output is 100 mA, it’s safe
to charge a 1,200-mA bat-
tery directly from the panel.
The maximum charge time
is limited by the length of
the day. It’s less than 13 h
in most cases. I use a
Schottky diode to protect
the panel from reverse cur-
rent when the battery is
powering the circuit.
The processor core is
powered from the battery
through a 2.8-V regulator,
while the CompactFlash
adapter is driven directly from the bat-
tery through a diode to drop voltage from
the nominal 3.6 to 3.3 V (see Figure 1).
POWER CONSUMPTION
The system’s power consumption
needs to be on the average less than the
solar production minus the inefficiency
of charging the battery (66%). This
leaves an average power consumption:
or approximately 72 mWh per day. At
3.6 V, this works out to be approximately
20 mAh per day. If your system needs to
run 24 h per day, this comes out to be
less than 0.833 mA of constant current
draw, which is not very much.
My system consists of a processor,
A/D converter, and wireless commu-
nication system. The Wi-Fi card alone
uses 300 mA when transmitting. How
can you make this work? The answer
is by reducing the duty cycle. The sys-
tem is in one of three states: it’s low-
power Sleep mode, it’s collecting data
and storing, or it’s bringing up the
communication system to talk.
0 66
.
110 mWh
day
×
Table 1—
Any of these conditions will affect the conversion efficiency of the solar panel.
Condition
Intensity (percentage of full sun)
Full sun panel square to sun
100%
Full sun panel at 45° angle to sun
71%
Light overcast
60–80%
Heavy overcast
20–30%
Inside window, single pane, double-strength
91%
glass, window, and module square to sun
Inside window, double pane, double-strength
84%
glass, window, and module square to sun
Inside window, single pane, double-strength
64%
glass, and window module at 45° angle to sun
Indoor office light (at desk top)
0.4%
Indoor light (store lighting)
1.3%
Indoor light (home)
0.2%
Table 2—
Compare the irradiation data for where I live
to places with more sun like Death Valley (Inyokern).
Global sun hours (kWh/day)
High
Low
Average
Davis, CA
6.09
3.31
5.10
Phoenix, AZ
7.13 5.78 6.58
Inyokern, CA
8.70 6.87 7.66
Photo 2—
Death Valley! At the time the picture was taken,
the ambient temperature was 116°F at 6:30 p.m. It’s obvious
why it has the highest solar irradiance in North America.There
are no clouds and it rains there every 10 years or so.
26
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
You can reduce the amount of time
needed to communicate by communi-
cating only when absolutely necessary
(i.e., when downloading the data that
has been collected). If you communi-
cate 30 s per day [30/(3,600 × 24)], the
following is true:
You have to make sure the system uses
less than 0.729 mA of constant current
for the rest of the day. Or, to put it
another way, running the Wi-Fi card
for 30 s per day uses up more than
12.5% of the available power.
These types of calculations are nec-
essary for any kind of solar-powered
system, including the Mars rovers.
Communication is expensive and only
allowed for short bursts or at low data
30
3 600
20
24
s
s
300 mA = 2.49 mAh
mA 2.49 mAh
= 0.72
,
~
×
−
9
9 mA
rates to conserve power, especially if
you plan on doing other useful work.
So, now you have a rough idea about
what the power budget is going to be.
Let’s look at ways to make this work.
PROCESSOR
The data logger’s processor is an
RCM3400 core module. It contains a
Rabbit 3000 processor, SRAM, flash
memory, and an eight-channel, 12-bit
ADC. The RCM3400 is interfaced to a
CompactFlash memory connector that
ues a Wi-Fi card for communication.
A 14.7-MHz crystal clocks the proces-
sor. The crystal oscillator is internally
multiplied by two to arrive at a 29-MHz
internal processor clock. In this configu-
ration, the core module will draw approx-
imately 70 mA, which is clearly more
than you want to spend. You must find
a way to reduce power consumption.
In CMOS logic there is a linear power
relationship to the clock speed it’s run-
ning and the power it consumes. This
relationship is demonstrated by turning
off the internal clock doubler. Sure
enough, the power consumption drops to
approximately 37 mA. Turning off the
ADC reduces the internal clock rate
(i.e., divide by 8) and reduces the
power consumption down to approxi-
mately 20 mA. Turning off the oscillator
and running the CPU from the 32-kHz,
real-time clock oscillator reduces the
power consumption to less than 10 mA.
Furthermore, there is a V
2
relationship
between the voltage and power consump-
tion. A circuit that consumes 1.6 mW at
3.6 V only consumes 0.8 mW at 2.8 V.
A diode can be used instead of a low-
power regulator to reduce the voltage.
The diode, of course, will dissipate
power (0.36 mA × 0.8 V = 0.3 mW) for
the voltage drop, but there’s a net sav-
ings of 0.3 mW.
Figure 1—
The data logger’s power section includes the battery, panels, regulator, and diodes. Signal conditioning consists of voltage dividers and the thermistor interface.
28
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
Making sure I/O pins are in a
static state can reduce power
consumption even more. On the
RCM3400, there are many
unconnected I/O pins. Using an
R3000 processor, I got a quiescent
current of 0.8 mA at 2.8 V in Sleep
mode. However, when I inserted a
CompactFlash card in the socket,
the current consumption went up
to 10 mA, even when the power to
the socket was disconnected with
an FET switch. I discovered that
some of the pins were held in a stat-
ic high condition, which sources
current into the card. Setting all
outputs to a low condition ensures
that no current can be sourced into
the card. After further examination,
however, it turns out that the core mod-
ule has pull-up resistors connected to port
A (the I/O data bus). When these are held
low, they actually source the following:
As an experiment, I removed the resis-
tor packs for these pull-ups to reduce
the current consumption even more.
The RCM3400 I experimented with
contained an R3000 processor when I
started. The current model uses an
R3000A processor. This version has an
internal Schmitt trigger for the 32-kHz
oscillator that allows a more power-
efficient implementation of the oscil-
lator when the processor is in Low-
Power mode.
In summary, the power-saving meas-
ures provide a low clock rate (32 kHz/8 =
4,096 Hz) and static I/O pins to reduce
input transitions from floating inputs.
In addition, they eliminate pull-ups
and pull-downs, which pull the wrong
way, and they make sure all the outputs
that drive unpowered CMOS circuitry
are low. They also provide an R3000A
processor and put the on-board ADC
into Low-Power mode.
The system can draw as little as
100 µA at 2.8 V. You get lower voltage
if the brownout reset chip is replaced
with a lower threshold value to reduce
the operating voltage of the processor
in Low-Power mode.
DATA COLLECTION
The module measures the voltage
8
100
2.8 V
k
= 224 µA
×
Ω
before and after the current sense resis-
tors. This way it can measure the cur-
rent provided when the panel is charging
the charge/discharge rate of the battery.
One input is also connected to a ther-
mistor to measure the temperature inside
the enclosure. Figure 2 shows the details.
CompactFlash WI-FI
I wanted to use Wi-Fi (802.11b) to
communicate with the outside world. I
was hoping to take advantage of a widely
implemented wireless standard that sup-
ports TCP/IP communications. To do
this, I used a Linksys Wi-Fi Compact-
Flash module, which is based on the
Intersil PRISM chipset. This card was
designed to be used mainly in PDAs.
Although low power is desired, this
proves consumption isn’t critical,
because most PDSAs are charged at the
end of the day in the cradle. Wi-Fi is a
good solution for PDAs because it’s rea-
sonably low-powered, has a medium
speed, and has good range. Compare this
to Bluetooth, which has a potentially
high speed but suffers from low range
and high power consumption.
The first CompactFlash card I used
consumes approximately 300 mA at
3.3 V when transmitting and 200 mA
when actively receiving. It consumes
approximately 90 mA when in Standby
mode. Clearly, this wasn’t going to work
because it would drain a 1,200-mAh bat-
tery in about 13 h, which isn’t enough
for the system to survive a day when
solar power is low.
My first attempts at reducing power
Sunlogger output
5
4.5
3.5
3
2.5
2
1.5
1
0.5
0
V
oltage
4
1
1001
2001 3001 4001
5001
Sample number (1/15 s)
Battery voltage
Panel voltage
Internal temperature
45
40
35
30
25
20
15
10
5
0
Te
mper
ature (Celsius)
Figure 2—
Here you see the solar output for one day (7 a.m. to
7 a.m.).The solar output (panel voltage) rises in the morning, and
then dips during the day when the house occludes the logger. So,
obviously this isn't a good location for a solar panel or collector.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
29
consumption when not transmitting
involved adding a MOSFET transistor to
cut off power from the battery. If there
is no power from the battery, then no
power should be consumed by the card.
Well, doing this, I still had a power con-
sumption of approximately 8 mA by the
CompactFlash card, which I tracked
down to having some of the outputs to
the card actually driven to a high state
(V
CC
). This caused a current path through
the protection diodes of any inputs on
the CF to ground, because V
CC
on the
card was now floating. Changing the
output state in Idle mode to all low
reduced the current consumption to
what I expected.
SOFTWARE
The data logger’s basic strategy is to
consume as little power as possible.
Most of the time is spent in Sleep mode
with the CompactFlash adapter in Off
mode and the I/O in the low-power
state. However, the system needs to col-
lect data. In order to do this, it restores
the state to a configuration it needs to
communicate with the ADC controller
to take a reading. The processor can do
this in Slow Clock mode in order to
conserve some power.
After enough data has been collected
and you want to send it, check the bat-
tery condition to see if it is sufficiently
charged in order to communicate via
Wi-Fi. Make sure the battery voltage is
over 3.6 V. Now you’re set to bring the
I/O pins in a state to communicate
with the CompactFlash adapter and
turn on the power to the CompactFlash
adapter. Then, reset the card and con-
figure the network up. This network
configuration will use DHCP to
dynamically configure its IP address,
DNS server, and router address. After
the network is up, compose an e-mail
message that contains the data you
want to send.
The e-mail message is delivered
directly to the SMTP server, which
hosts the e-mail recipient. With all of
the SPAM, this turned out to be the
easiest way for an embedded system to
send e-mail. Using a relay server
involves adding the embedded system’s
IP number to its allowed list. Of course,
because you don’t know what your IP
address is (remember you dynamically
allocated it) this is not always easy.
A better way would be to add SMTP
server authentication. In this way, an
e-mail client will send login/password
information to a relay server that
authenticates the client. This is the
way you set up your e-mail on a PC
when you want to send e-mail via your
ISP’s outgoing e-mail server. However,
this would potentially involve adding
SSL or AES encryption, which is an
entire article in itself.
After the system has sent the e-mail,
it shuts down the TCP/IP stack by
unconfiguring its interface, and turns
off the power to the CF adapter. The
system is now ready to enter Sleep
mode until the next time it needs to
send an e-mail.
The logger does mostly nothing. It
has a spurt of activity at high speed in
order to reduce the amount of time
the CompactFlash adapter is powered
up. This behavior (dynamic power
management) is typical of low-powered
devices. Even laptops and cell phones
use this strategy to maximize battery
life.
I
Ingo Cyliax received a B.S.C.E.E. from
Purdue University. He has worked for
universities and small companies, and he
has been consulting and writing for many
years. He currently works as an applica-
tion engineer at Z-World, Inc. Ingo is
interested in embedded systems, wireless
networking, and hardware design. You
may reach him at cyliax@ezcomm.com.
PROJECT FILES
To download the code, go to ftp.circuit
cellar.com/pub/Circuit_Cellar/2004/172.
RESOURCES
Solar insolation for major U.S. cities,
www.solar4power.com/solar-power-
basics.html.
SOURCE
RCM3400 RabbitCore
Rabbit Semiconductor
www.rabbitsemiconductor.com
30
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
Robot kit (see Photo 1a). I also used it
in my GearBot robot (see Photo 1b).
MATH COPROCESSOR
What is a coprocessor? In its simplest
form, a coprocessor acts as a slave proces-
sor to aid a master microcontroller. It
performs basic floating-point arithmetic
that involves standard functions (addi-
tion, subtraction, multiplication, and
division), trigonometric, and scientific
functions. The coprocessor calculates
these functions after receiving requests
from host controllers that don’t normally
support floating-point math or are too
busy doing other kinds of processing.
Several features differentiate my
PIC18F8720-based Math Coprocessor from
others: digital I/O, analog I/O (an A/D con-
verter for reading sensors and PWM for
motor control), MSSP, USART, and timers.
The Math Coprocessor isn’t intended
to be a replacement for a coprocessor such
as an Intel 8087 (see Figure 1). Instead,
think of it as an assistant to a host con-
troller, whose function is to handle time-
consuming floating-point expressions
while collecting data using the analog I/O
E
ach year, designers race to build fast
fire-fighting robots to enter in the
Trinity College Fire Fighting Robot
Contest in Hartford, Connecticut.
Designing a fire-fighting robot for the
contest is more than a great way to win
exciting prizes, it’s also a noble endeavor
that can benefit mankind. I’d like to see
new designs for robots that can go where
firefighters can’t. Using robots to fight
large building and forest fires could save
lives and property. How about designing
a wall-climbing robot that can drag a
rope ladder to people trapped on the top
floors of buildings? Such a design isn’t
beyond the realm of possibility. Take a
look at the SLOTH Rope Climbing
Robot featured on the Seattle Robotics
Society’s web site (www.seattlerobotics.
org/encoder/200210/prj5/sloth.htm).
Navigating a fire-fighting robot
through the corridors of an unfamiliar
burning building is analogous to having
a robot solve an obstacle-ridden maze in
record time. But developing a maze-solv-
ing robot can be a difficult task. What if
your prototype doesn’t execute maze tra-
versal algorithms fast enough because of
noisy IR sensor readings? You can use
a simple median filter to obtain better
readings, but then your processor will be
overburdened with control and naviga-
tion tasks. What you need is a floating-
point coprocessor to offload the addition-
al processing. This will improve your
robot’s response time and algorithm
evaluation, thus enabling it to solve
algorithms faster.
If you have limited design space and
you find yourself in need of more pro-
cessing horsepower, drop my Math
Coprocessor in your application. I did
this when working on my Sumo
or sending PWM commands to motors.
WHY THE PIC18F8720?
Although there are numerous reasons
to use the PIC18F8720 microcontroller in
a project, I chose it primarily for its low
cost, small size (14 mm × 14 mm in a
TQFP80 SMT package), and rich set of
on-chip hardware features. The 128 KB of
flash memory, 4 KB of SRAM, and 1 KB
of EEPROM allow me to develop large
applications using the PIC18 C compiler.
When choosing a microcontroller,
clock speed is another consideration.
Other members of the PIC18Fxxxx
family top out at clock speeds of up to
40 MHz, or 10 MIPS. The PIC18F8720,
on the other hand, has a 25-MHz clock
that delivers 6-MIPS performance. In a
package not much bigger than a Stamp
mounted on a carrier board, the coproces-
sor should fit in tight spaces because
it measures only 4.5 cm × 4.5 cm.
The PIC18F8720’s gargantuan 2-MB
memory address space and abundance of
hardware peripherals (e.g., timers, PWM,
capture registers, and USART) put it at
the top of the 8-bit microcontroller class.
FEATURE ARTICLE
by Daniel Ramirez
Math Coprocessor for Robotics Applications
Photo 1a—
I’m modifying my Sumo Robot so I can use the Math Coprocessor board. I plan to use it for processing
navigation, obstacle detection, and line-following algorithms. The coprocessor is connected to a Parallax Stamp
BSX MCU that’s designated as the robot’s main controller. b—I use my GearBot robot as a test platform.
Need more processing horsepower for your robot? This design provides additional function-
ality to microcontrollers that don’t support floating-point math and to those that are too
bogged down with other functions.
a)
b)
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
31
COMMUNICATION INTERFACES
There are four communication pro-
tocols supported by the PIC18F8720’s
on-chip peripherals: the serial commu-
nication interface (SCI), the Motorola
serial peripheral interface (SPI), the
Philips inter-IC (I
2
C) interface, and the
Microchip parallel slave port (PSP)
interface (see Figure 1).
I selected the high-performance SPI
interface for several reasons. First, note
that the SPI interface provides the fastest
rates (over 1 Mbps). The second reason
is that SPI is easy to connect to other
microcontrollers, and even can be simu-
lated on microcontrollers that do not
directly support the SPI interface.
Networking using the SPI interface is
possible by tying multiple SPI devices
to the SPI bus and connecting the
slave SELECT pins of each SPI device
to those of the host SPI processor.
The PSP interface provides the high-
est throughput (more than 1 MBps)
because of its 8-bit parallel bus nature.
The downside of PSP is that it uses up
to 12 I/O pins and cannot be easily
networked unless connected to a PC or
laptop IEEE-1284 ECP parallel port
(LPT1). So, I ruled it out
for this application.
COPROCESSOR
BOARD
Figure 2 shows the
schematic of the
coprocessor. First you
must purchase a
TQFP80 SMT prototype
adapter board from
Bellin Dynamic
Systems. You get three
adapter boards for $50,
which allows you to
build a host SPI con-
troller whose sole func-
tion is to send and
receive messages from
the coprocessor. To do
this, apply the same instructions and
schematics used for making the coproces-
sor. (This step is unnecessary if you are
using another kind of host SPI controller
such as a Parallax Stamp BSX.) Next, sol-
der the PIC18F8720 on one of the adapter
boards using the toaster oven technique.
[1]
The remaining components include
resistors and bypass capacitors, which
are mounted directly on the board
using spare through holes. A standard
20-pin DIP allows you to mount a
MAX233 IC for the high-speed serial
link by connecting TX, RX, and ground
to the MAX233 IC (see Figure 2). Look
at the connection diagram posted on
the Circuit Cellar ftp site to see how
to connect these signals to the host.
Two USART
peripherals
Host
RS-232
Five timers
MSSP
Peripheral
Host
SPI
I
2
C
120-KB
Flash memory
4-KB
SRAM
Microchip
25-MHz PIC18F8720
microcontroller
core with 8 × 8
single-cycle multiplier
Sixteen
10-bit
analog A/D
channels
Nine
8-bit
ports
A
B
C
D
E
F
G
H
J
1-KB
Serial
EEPROM
Five
PWM/capture
peripherals
Figure 1—
The on-chip communications hardware, available memory, and dig-
ital and analog I/O are among the PIC18F8720-based Math Coprocessor’s
most important hardware features.
Figure 2—
The Math Coprocessor schematic shows the ICD2, SPI, I
2
C jumpers, and the connections to a MAX233 serial driver used for the SCI serial interface.
32
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
This will allow you to provide serial
RS-232 communication with a PC
using Hyperterminal.
ICD2 and ICSP connections are made
directly to the corresponding pin headers
on the prototype board using the RJ11
socket for convenient hookup to the
ICD2. All other connections are wire-
wrapped or point-to-point soldered as
shown in the coprocessor schematic.
Photo 2 shows the external compo-
nents including the oscillator and
MAX233 mounted with DIP sockets
that are soldered to the board using spare
through-holes. An optional 24LC32 seri-
al I
2
C EEPROM shown in the schematic
allows you to read from and write to a
24LC32 serial I
2
C EEPROM.
POWER SUPPLY (JP1)
The power requirements for the
coprocessor board are modest because I
designed this board to be used for small
mobile robot applications. Jumper JP1
connects the external 5-V power supply
board (see Figure 3). This is all you need
to power the coprocessor board. A sepa-
rate 5-V regulated power supply con-
nected to the V
SS
and V
DD
pins also may
be used.
The power LED connected between
V
DD
and V
SS
uses a 220-
Ω
resistor in
series to limit the current. It provides
an indication of when the coprocessor
board is powered up.
I
2
C INTERFACE (JP2)
Although the Philips Inter-IC (I
2
C)
interface is easy to connect (only two
wires required), it turns out to be the
hardest to use on the PIC18F8720, and
it’s slower than the SPI or PSP inter-
faces. The real advantage of I
2
C is its
networking capability. Up to 128 nodes
of I
2
C master or slave devices can be
connected via the I
2
C bus, as long as
each node has its own node address.
Both the 7-bit and the enhanced 10-bit
modes are supported.
The coprocessor board provides access
to the I
2
C interface by using jumper JP2
(see Figure 2). It connects the SCL, SDA,
and GND signals to an I
2
C slave device.
It also uses the master synchronous seri-
al port peripheral (MSSP) hardware to
support the I
2
C 7-bit and 10-bit commu-
nication protocols in both master and
slave configurations. The I
2
C interface is
handy for reading and writing to serial
I
2
C EEPROMs and various I
2
C devices
commonly found in robotics such as
sensors and controllers.
The biggest advantage that makes
I
2
C devices appealing for robotics appli-
cations is that they can be networked via
a two-wire bus using only two pull-up
Photo 2—
Here you see the Math Coprocessor board
with a MAX233 serial driver and a 20-MHz oscillator
mounted on two separate DIP wire-wrap sockets.
Notice the remaining I/O pin headers that can be used
for interfacing to other boards.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
33
resistors. With appropriate pull-up resis-
tors ranging from 2.2 to 10 k
Ω
, you can
connect almost any I
2
C serial EEPROM
or any I
2
C slave device to the coproces-
sor, using only the SCL and SDA I/O
signals. The I
2
C library functions are
accessed using the i2c.h C header file.
SPI (JP3)
Next in communication performance
is the Motorola SPI interface. Although
faster than the I
2
C and SCI interfaces, it
requires one or two extra wires. I used
the SPI bus to tie together the host with
a coprocessor board. It requires three or
four signals including the serial clock
line (SCK), the master out slave in
(MOSI), the master in slave out (MISO),
and the slave select (SS_BAR). Each SPI
device connected to the network must
be exclusively selected in order to pre-
vent contention on the SPI bus.
The SPI interface is accessed using
jumper JP3 located on the coprocessor
board that connects the MOSI, MISO,
SS_BAR, SCK, and GND signals to an
SPI host. It uses the MSSP on-chip
peripheral to connect to various slave
devices using the four standard SPI
communication modes. This interface
is also handy for reading and writing
to serial SPI EEPROMS and real-time
clocks. It’s also the primary communi-
cation channel to the coprocessor.
The SSPSTAT register may be con-
figured for various SPI master and
slave options. These options include
combinations of clock phase (CPHA)
and clock polarity (CPOL) that deter-
mine the idle state for the clock line
(SCK). They also determine when the
data bit is transmitted, either on the
rising or falling edge of the SCK. In
addition, in the Master SPI mode, the
sample bit (SMP) may be cleared or set
to input data sampled at either the
middle or the end of the data output
time slot. In SPI Slave mode, the SMP
bit must be cleared at all times.
SPI MASTER MODE
The PIC18F8720 fully supports the
SPI interface via its MSSP on-chip
peripheral. Because of the bidirectional
nature, any write to an SPI device auto-
matically triggers an SPI read, which
means that data can be read at the
same time that it is written, or the data
read may be ignored if desired by just
assigning it to a dummy variable.
The SPI
open statement in Listing 1
shows how the MSSP peripheral is
configured as an SPI master by passing
it the appropriate mode and clock
speed (OSC/4, OSC/16, or OSC/64).
These constants are defined in the
spi.h header file. The coprocessor can
be connected via the SPI interface to
an SPI host using any commercial
microcontrollers as long as the corre-
sponding connections to the SPI port
are made correctly and the firmware is
modified accordingly.
Figure 3—
The optional 5-V power supply can be used to
power the Math Coprocessor board, or a separate 5-V lab
power supply can be connected to V
SS
and V
DD
in its place.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
35
SPI SLAVE MODE
Some SPI applications concentrate
on the master modes while neglecting
the slave modes. This is understand-
able because the slave modes are more
difficult to implement. They require
an interrupt service routine (ISR) to
handle MSSP interrupts asynchronous-
ly when incoming bytes have been
received in the SSPBUF register and the
SSPIF Interrupt flag has been set. This
happens as soon as the master device
selects the slave by holding the SS_BAR
signal low while sending a byte.
The MSSP is used to handle required
handshaking and byte reception/trans-
mission operations over the SPI bus. It
accomplishes this by shifting in data
from the bus directly into the SSPBUF
and setting a buffer full flag (BF) that
generates an interrupt when completed.
As with the master modes, the corre-
sponding four signals—SCK, MOSI,
MISO, and SS_BAR—are all that are
required to connect a master device to
an SPI slave. If there is only one slave
connected to the SPI bus, the slave
select SS_BAR signal is optional because
there isn’t another SPI device connected
that could cause bus contention. To use
the Math Coprocessor, it’s necessary
to connect the host to the coprocessor
(see Figure 4).
ICSP/ICD2 CONNECTOR (JP4)
The ICSP/ICD2 connector (JP4 in
Figure 2) connects the coprocessor
board to the in-circuit debugger (ICD2)
connector to program and debug your
coprocessor applications. This is much
easier to use than the older method of
removing the microcontroller to erase
and program it. The connector simply
attaches to the ICSP pin headers on
the TQFP80 board, while ensuring
that pin 1 is aligned correctly.
SCI (JP9)
Communication between a PC and
the coprocessor is done using an 8-
data-bits, 1-stop-bit serial link con-
nected to jumper JP9. This jumper
enables a host microcontroller or a
PC to communicate with the
coprocessor so that it can display
messages and enable you to send
commands. This is accomplished
using the on-chip addressable univer-
sal synchronous asynchronous
receiver transmitter (USART) hard-
ware, otherwise known as SCI on
other brands of microcontrollers.
SOFTWARE DESIGN
Firmware is the magic that makes the
coprocessor work. Without the firmware,
the hardware is a handful of useless com-
ponents. For convenience when devel-
oping the firmware, I used Microchip’s
PIC18 C demo compiler along with
MPLAB and the ICD2. The SPI library
functions used to develop the coprocessor
application are accessible by including
the spi.h header file. Refer to the Circuit
Cellar
ftp site for more information about
the high-level structure of the software.
The coprocessor includes numerous
software modules that use up most of
the PIC18F8720’s memory resources.
By partitioning the software modules
in this way, I have been able to reuse
most of the code for my SPI host appli-
cation (coprocm_spi.c), which runs on a
PIC18F8720 that’s designated as the
host controller. The application was
used to test the coprocessor application
by sending it a stream of 32-byte mes-
sages containing various RPN expres-
sions (coprocs_spi.c). It also received
the results from the coprocessor and
displayed them using the to a PC using
Hyperterminal.
ADVANCED SOFTWARE
You might want to process advanced
coprocessor functions such as FFT and
filter algorithms. Financial and unit
conversion functions like those used in
physics, astronomy, electronics, and
mechanics are easy to add. For more
information, read W. H. Press et al.’s
book Numerical Recipes in C—a classic
that would make an excellent addition
to your bookshelf. The book includes
examples of reliable algorithms for
advanced mathematics. You can study
algorithms in both Fortran and C for var-
ious applications: least square fit, FFT,
Listing 1—
The SPI master initialization uses the
OpenSPI
function from the Microchip SPI library.The Math
Coprocessor SPI slave is configured in a similar manner, with the SPI parameters corresponding to the SPI master.
******************************************************************
// InitializeSPIMaster - Initialize the SPI Master hardware for
// SPI Clock of Fosc/16, clock Idle low (SPI Mode 0,0), and
// sample data after the falling edge of SCK.
******************************************************************
void InitializeSPIMaster(void)
{
// Configure port A for all digital inputs
OpenADC(ADC_0ANA, ADC_INT_OFF);
// Configure PORTB interrupt with interrupt on change off and
pull-up resistors enabled
OpenPORTB(PORTB_CHANGE_INT_OFF & PORTB_PULLUPS_ON);
EnablePullups();
// Configure PORT E for 8 Bits Digital I/O
PSPCONbits.PSPMODE = 0;
// Initialize the SPI master pin directions
SPI_SCL_DIR = OUTPUT;
// Set SPI clock direction output
SPI_SI_DIR = INPUT;
// Set SPI input direction input
SPI_SO_DIR = OUTPUT;
// Set SPI output direction output
SPI_CS_DIR = OUTPUT;
// Set SPI slave select direction
BUSY_FLAG_DIR = INPUT; // Set SPI slave busy flag direction
SPI_CS = DISABLE;
// Ensure SPI memory device
(disable it first)
// Chip Select is reset
OpenSPI(SPI_FOSC_64, MODE_00, SMPEND);
// Select this mode if using
// slave select
}
Figure 4—
The SPI connection diagram uses a
PIC18F8720 as the SPI master and the PIC18F8720-
based Math Coprocessor board as the SPI slave.
36
Issue 172 November 2004
CIRCUIT CELLAR
®
Issue 172 November 2004
36
interpolation, integration, and so on.
IEEE 754 FLOATING POINT
A word on floating-point processing is
in order. Microchip’s floating-point math
libraries currently support single preci-
sion 32-bit IEEE 754 floats using only
the standard floating-point arithmetic
functions: addition (+), subtraction (–),
multiplication (×), and division (/). To
evaluate complicated floating-point
expressions containing trigonometric
and scientific functions, I referred to
Jack Crenshaw’s book Math Toolkit for
Real-Time Programming
. I converted his
math libraries from C++ to PIC18 C to
make them available to the coprocessor
because they were not available in the
PIC18 C libraries.
I highly recommend this book if you’re
tasked with writing a floating-point
package for an embedded microcontroller
that normally doesn’t support floating-
point math. I have already described the
development of these functions (“Build
Your Own Four-Function Calculator,”
issue 157, August 2003). The remaining
unfinished scientific functions are left
for you.
MATH MESSAGES
To communicate effectively with the
coprocessor, I designed a message-pass-
ing scheme that’s common to all four-
communication interfaces defining a set
of 32-byte data messages that are inde-
pendent of the communication proto-
col. The messaging scheme feeds the
coprocessor the mathematical expres-
sions for evaluation and obtains the
results from the calculations. Various
messages are used to send the coproces-
sor commands and receive the corre-
sponding results in a flexible manner.
Using this scheme, up to seven floating-
point responses or three double-precision
floating-point results can be returned
in one message.
The messaging structure must be
reproduced regardless of the programming
language and the microcontroller plat-
form. The host and coprocessor applica-
tions build these predefined messages
using the PIC18 C functions shown in
the coproc.h file. If you chose an ’F8720
for the master and the C language, then
use the example in Listing 2.
Messages to the coprocessor include
messages for passing a set of expressions
to be evaluated, messages for status
request, and messages to obtain the
results from the computed expressions.
This process is not unlike a mainframe
computer operating in Batch mode,
where decks of cards are fed to the main-
frame for processing, and the results
appear later in a sorting bin. Messages
returned from the coprocessor include
the actual results from an expression set
evaluation request, where up to seven
32-bit, floating-point answers are
returned in one message. The coproces-
sor messages posted on the Circuit
Cellar
ftp site are available to the master
controller that uses the coprocessor,
although I have not completed all the
message processing.
COPROCESSOR EXPRESSIONS
The coprocessor firmware is based
on an HP-45 calculator using RPN as
the parser for evaluating arithmetic
expressions. If you happen to know
Forth language, then RPN should also
look familiar to you. This enabled me
to simplify the software more than I
could have if I had used AOS or BASIC
language. Complex expressions are
simply evaluated by manipulating a
four-level stack. By doing so, I devised
a shorthand notation for entering com-
plex RPN expressions for the
coprocessor to evaluate. I used the
character set and simple list of tokens
posted on the Circuit Cellar ftp site.
You can modify the table as long as
single ASCII characters are used as
Listing 2—
This PIC18 C example shows you how to initialize a
Calculate
message and a
GetResults
message using a PIC18F8720 for the SPI master and another PIC18F8720 as the slave Math Coprocessor.
******************************************************************
// Send various arithmetic expressions to the Math Coprocessor
// for evaluation
******************************************************************
while (1)
{
// Test 1—Send the coprocessor command message that evaluates
the RPN expression: sqrt(25.0)*3.0 + 2 = 17.0
SendCalculateCommand (“25.0H^3*^2+;”);
// Get Results into the floating point Results array where
TheResults[0] is the answer to the first expression, etc.
GetResults(TheResults);
// Test 2—Send the coprocessor command message that evaluates the
RPN expression: sin(radians(30)) = 0.5
SendCalculateCommand (“30.0RA;”);
// Get Results into the floating point Results array where
TheResults[0] is the answer to the first expression, etc.
GetResults(TheResults);
// Test 3—Send the coprocessor command message that evaluates
// theRPN expression: (3+4)/(8+6) = 0.5
SendCalculateCommand (“3^4+8^6+/”);
// Get Results into the floating point Results array where
// TheResults[0] is the answer to the first expression, etc.
GetResults(TheResults);
// Test 4—Send the coprocessor command message that evaluates
// the RPN expression: (8-2)*(6+3)= 54.0
SendCalculateCommand (“8.0^2.0-^6.0^3.0+*”);
// Get Results into the floating point Results array where
// TheResults[0] is the answer to the first expression, etc.
GetResults(TheResults);
// Test 5—Send the coprocessor command message that evaluates
// multiple RPN expressions from Test 1 and Test 3: combined.
SendCalculateCommand (“25.0H^3*b2+;3^4+8^6+/;”);
// Get Results into the floating point Results array where
// TheResults[0] is the answer to the first expression, etc.
GetResults(TheResults);
}
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
37
PROJECT FILES
To download the code and additional
figures, go to ftp.circuitcellar.com/pub/
Circuit_Cellar/2004/172.
REFERENCE
[1] K. Maxon, “Have You Seen My New
Soldering Iron?” Encoder,
www.seattlerobotics.org/encoder
/200006/oven_art.htm.
Daniel Ramirez is a senior software
engineer with more than 10 years of expe-
rience working on real-time embedded
systems. His interests include robotics,
travel, golf, and treasure hunting. You may
contact Daniel at mgatron@aol.com.
RESOURCES
J. Crenshaw, Math Toolkit for Real-Time
Programming
, CMP Books, 2000.
Microchip Technology, “AN575: IEEE
754 Floating Point Routines,” DS00575B,
1997.
W. H. Press, et al., Numerical Recipes
in C: The Art of Scientific Computing
,
Cambridge University Press, 1993.
SOURCES
TQFP80 SMT prototype adapter board
Bellin Dynamic Systems, Inc.
www.beldynsys.com
PIC18F8720 Microcontroller
Microchip Technology, Inc.
www.microchip.com
BASIC Stamp BSX microcontroller
Parallax, Inc.
www.parallax.com
tokens. The “^,” “<,” “>,” and “~”
characters are the set of special opera-
tors for the shorthand I developed to
input RPN expressions. They are dif-
ferent than C and BASIC operators.
The
SendCalculateCommand func-
tion is used to construct the 32-byte
message from the RPN expression
string passed as a parameter. The
results from the coprocessor are
returned by invoking the
GetResults
function with the answers contained in
the floating-point
TheResults[] array,
where
TheResults[0] is the answer to
the first expression,
TheResults[1]
is the answer to the second expression,
and so on.
Let’s look at an example. Evaluate
the following expression:
Use the following C function call to
format and send the coprocessor com-
mand message that evaluates the RPN
expression:
SendCalculateCommand
(“25.0H^3*^2+;”);
A list of the coprocessor’s functions is
posted on the Circuit Cellar ftp site.
You get the answers into the floating-
point
TheResults array by calling the
following:
GetResults(TheResults);
IMPROVEMENTS
Improved processor communica-
tion—using token passing or data
packets similar to TCP/IP on the
Internet using Ethernet, CAN, or
I
2
C—would allow true parallel pro-
cessing and multiprocessing for small
robots. In addition, developing small
versions of massively parallel com-
puting and neural networks will
allow you to experiment with con-
cepts such as fault-tolerant systems,
reconfiguration, and image and pat-
tern recognition, which are currently
delegated to commercial and univer-
sity research. Another performance-
boosting improvement would be to
upgrade it to a 30 MIPS Microchip
dsPIC30F6014, a high-end Motorola
68HC12, or a Renesas H8 microcon-
troller.
25 3 + 2 = 17
×
ROBOTICS SOLUTION
Now you’re familiar with the hardware
design and firmware required to make the
Math Coprocessor perform useful mathe-
matical functions, including the basic
floating-point arithmetic and scientific
and trigonometric functions. The
coprocessor also provides added function-
ality to micros that don’t have floating
point or are too busy performing other
functions. You can use the RPN calcula-
tor language to enter complicated expres-
sions for evaluation by the coprocessor.
Now it’s your turn to put the
coprocessor to use. It’s perfect for
robotics projects like my GearBot.
I
38
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
why old monitors with slow
scan rates flicker.
Figure 1 shows that the scan-
ning starts from row 0, column 0
in the top left corner of the
screen and moves to the right
until it reaches the last column.
When the scan reaches the end
of a row, it retraces to the begin-
ning of the next row. When it
reaches the last pixel in the bot-
tom right corner of the screen,
it retraces back to the top left
corner and repeats the scanning
process. In order to reduce flick-
er on the screen, the entire screen must
be scanned 60 times per second (or more).
During the horizontal and the vertical
retraces, all the pixels are turned off.
FIVE CONTROL SIGNALS
The VGA monitor is controlled by five
signals: red, green, blue, horizontal syn-
U
nderstanding video signals and
building video controller circuits is
always a challenge. But things are getting
easier. I recently took another look at the
VGA video signal and realized that I
could build a VGA monitor controller
with just two binary counters, four flip-
flops, and 11 AND gates. Yes, that’s
right, just two 10-bit binary up counters,
four SR flip-flops, and 11 AND gates!
Now, of course, this isn’t a replacement
for your high-end graphics card in your
PC, nor is it even a low-end video card,
but it’s capable of displaying images on a
standard VGA monitor. Most important-
ly, this simple VGA monitor controller
circuit allows you to easily understand
how the VGA monitor works and how to
control it. When I presented this to my
introductory digital logic design class,
the students were totally amazed that it
could be this simple.
PIXELS ON SCREEN
To begin, you need to under-
stand how a VGA monitor
works. The monitor screen for
a standard VGA format con-
tains 640 columns by 480 rows
of picture elements called pix-
els (see Figure 1). An image is
displayed on the screen by
turning on and off individual
pixels. Turning on one pixel
doesn’t represent much, but
combining numerous pixels
generates an image. The moni-
tor continuously scans through
the entire screen, rapidly turn-
ing individual pixels on and
off. Although pixels are turned
on one at a time, you get the
impression that all the pix-
els are on because the moni-
tor scans so quickly. This is
chronization, and vertical synchroniza-
tion. The three color signals, collectively
referred to as the RGB signal, control the
color of a pixel at a given location on
the screen. They are analog signals with
voltages ranging from 0 to 0.7 V.
Different color intensities are obtained
by varying the voltage. For simplicity,
your circuit could treat these
three color signals as digital
signals, so you could just turn
each one on or off. As Figure
2a demonstrates, such a cir-
cuit would be capable of dis-
playing only eight colors (2
3
=
8). Figure 2b shows a slightly
enhanced digital-to-analog
converter circuit that can
display up to 64 colors (2
6
).
The horizontal and verti-
cal synchronization signals
are used to control the tim-
ing of the scan rate. Unlike
the three analog RGB sig-
nals, these two sync signals
are digital signals. In other
words, they take on either a
logic 0 or a logic 1 value.
The horizontal synchro-
nization signal determines
FEATURE ARTICLE
by Enoch Hwang
Build a VGA Monitor Controller
Column 0
Column 639
Row 0
Row 479
480 pixels
per column
Horizontal
retrace
Horizontal
scan
VGA Monitor
screen
Vertical
retrace
Figure 2—
D/A converter circuits drive the RGB signals.You can use them to produce
eight colors (a) or 64 colors (b). The VGA monitor controller controls the digital signals.
The analog signals are connected to the VGA monitor via a 15-pin D-Sub connector.
Figure 1—
Scanning starts from row 0, column 0 and moves to the
right and down until reaching row 479, column 639.
a)
b)
Enoch built a VGA monitor controller with just two 10-bit binary up counters, four SR flip-flops,
and 11 AND gates.The result is an impressive solution for displays.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
39
the time it takes to scan a row, while
the vertical synchronization signal
determines the time it takes to scan
the entire screen. Understanding how
to control a VGA monitor simply boils
down to understanding the timings for
these two synchronization signals. By
manipulating these two sync signals
and the three RGB signals, images are
formed on the monitor screen.
SYNC TIMINGS
The horizontal and vertical synchro-
nization signal-timing diagram is shown
in Figure 3. When inactive, both synchro-
nization signals are at a logic 1 value. A
row scan begins with the horizontal sync
signal going low for 3.77 µs (region B). A
1.79-µs high on the signal follows this
(region C). Next, the data for the three
color signals is sent, one pixel at a time,
for the 640 columns for 25.42 µs. Finally,
after the last column pixel, there is anoth-
er 0.79 µs of inactivity on the RGB signal
lines for the horizontal retrace before the
horizontal sync signal goes low again for
the next row scan. The total time to
complete one row scan is 31.77 µs.
The timing for the vertical sync signal is
analogous to the horizontal one. The 64-µs
active low vertical sync signal resets the
scan to the top-left corner of the screen
(region P). A 1,020-µs high follows this on
the signal. Next, there are the 480 31.77-µs
row scans, giving a total of 15,250 µs
(480 × 31.77), as shown in region R.
Finally, after the last row scan, there is
another 450 µs before the vertical sync
signal goes low again to start another
complete screen scan in the top left cor-
ner. It takes a total of 16,784 µs to com-
plete one full screen scan.
To get the monitor operating properly,
simply get the timing correct for the hori-
zontal and vertical sync signals and then
send out the RGB data for each pixel at
the right column and row position. For
example, if you want to turn on the red
pixel at row 13 and column 48, wait for
the scan to reach row 13 and column 48
and then set the red signal to logic 1. To
accomplish this, you need to generate the
horizontal and vertical sync signals
correctly based on the timing dia-
grams shown in Figure 3. You also
must keep track of the current row
and column counts so that you
know where the scan is. It turns out
that you can do both of these things
using the same component, which is
the binary up counter. You need two
counters. One is for generating the
horizontal sync and keeping tract of
the column count. The second is for
generating the vertical sync and
keeping track of the row count.
COUNTING CLOCK CYCLES
Getting the correct timing for
the two synchronization signals
is simple if you use the correct
clock frequency. To obtain the
480
×
640 screen resolution, use a
clock with a 25.175-MHz fre-
quency. A higher clock frequency is
needed for a higher screen resolution.
For the 25.175-MHz clock, the period
is the following:
or approximately 0.0397 µs per clock
cycle. For region B of the horizontal syn-
chronization signal, you need 3.77 µs,
which is approximately 95 clock cycles
(3.77/0.0397). For region C , you need
1.79 µs, which is approximately 45 clock
cycles. Similarly, you need 640 clock
cycles (region D) for the 640 columns of
pixels and 20 clock cycles for region E.
The total number of clock cycles needed
for each row scan is 800 clock cycles (95 +
45 + 640 + 20). Notice that with a 25.175-
MHz clock, region D requires exactly
640 cycles, generating the 640 columns
per row. If you use a different clock speed,
you will get a different screen resolution.
The number of clock cycles required by
the four regions in the horizontal sync
signal is summarized in Table 1.
Because the vertical sync signal is
analogous to the horizontal sync signal,
you can perform the same calculations
as with the horizontal sync regions to
obtain the number of cycles needed for
each vertical region. However, instead of
using the number of periods of a 25.175-
MHz clock, the times for each vertical
region are multiples of the horizontal
cycle. For example, the time for a hori-
1
25 175
.
10
6
×
640 column pixels
Red, green, blue
Horizontal sync
D
25.42 µs
640 cycles
31.77 µs
800 cycles
Time and number of
25.175-MHz clock cycles
480 horizontal cycles
Red, green, blue
Vertical sync
R
15,250 µs
480 cycles
16,784 µs
528 cycles
Time and number of
horizontal cycles
B
3.77 µs
95 cycles
C
1.79 µs
45 cycles
E
0.79 µs
20 cycles
P
64 µs
2 cycles
Q
1,020 µs
32 cycles
S
450 µs
14 cycles
Figure 3—
The horizontal and vertical synchronization signal timing diagram uses a 25.175-MHz clock. Each of the two sig-
nals has four regions: B, C, D, and E for the horizontal sync, and P, Q, R, and S for the vertical sync. Controlling the VGA
monitor involves getting the correct timing for the regions.
Table 1—
Take a look at the number of cycles needed for the different regions of the horizontal and vertical sync signals.
B
C
D
E
Total
Time
3.77 µs
1.79 µs
25.42 µs
0.79 µs
31.77 µs
Number of 25.175-MHz
95 cycles
45 cycles
640 cycles
20 cycles
800 cycles
clock cycles
P
Q
R
S
Total
Time
64 µs
1,020 µs
15,250 µs
450 µs
16,784 µs
Number of horizontal cycles
2 cycles
32 cycles
480 cycles
14 cycles
528 cycles
40
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
zontal cycle is 31.77 µs, and region P
requires 64 µs, which is approximately
two horizontal cycles (2 × 31.77). Region
Q requires 1,020 µs, which equals 32 hor-
izontal cycles (1,020/31.77). The calcula-
tion for region R is 480 horizontal cycles
(15,250 µs/31.77 µs). Of course, it has to
be exactly 480 times, because you need
to have 480 rows per screen. The num-
ber of horizontal cycles required by the
four regions in the vertical sync signal is
also summarized in Table 1.
If you use a 25.175-MHz clock to drive
a counter so that it increments at every
clock cycle, all you have to do to get the
correct horizontal sync signal is count
the correct number of cycles for each
region. Starting the count at zero, set the
horizontal sync signal (H_SYNC_OUT)
to zero (for low). When the count reaches
95, set H_SYNC_OUT to one (for high).
When the count reaches 140 (95 + 45),
keep H_SYNC_OUT at one. When the
count reaches 780 (95 + 45 + 640), con-
tinue to keep H_SYNC_OUT at one.
Finally, when the count reaches 800
(95 + 45 + 640 + 20 ), set H_SYNC_OUT
to zero, and reset the counter to
zero. This completes one period of the
H_SYNC_OUT signal.
Similarly, you can use another counter
for the vertical sync signal. The clock for
this counter is derived from the horizon-
tal counter so that the vertical counter
counts once for each horizontal cycle.
VGA CONTROLLER CIRCUIT
Two 10-bit binary up counters are
needed for the horizontal and vertical
sync signals. A 9-bit counter can only
count up to 512 (2
9
), but you need to
count up to 528 and 800 for the verti-
cal and horizontal sync signals respec-
tively. A 10-bit counter can count up
to 1,024 (2
10
). A 10-input AND gate is
used for comparing the count with a
constant. Figure 4 shows the connec-
tion of a 10-input AND gate for com-
paring with the constant 95. Because
95 equals 0001011111 in binary, bits
6, 8, 9, and 10 (starting from the LSB)
of the 10-input AND gate are invert-
ed. Four such comparators are used for
the four horizontal regions, each con-
nected according to the ending count
value that is to be tested.
Within each region, you need to main-
tain the value of the horizontal sync sig-
25.175-MHz Clock
COUNT
“0000000000”
LOAD
CLEAR
CLOCK
1
Clear
D
9–0
10-bit Up counter
with load
Q
9–0
(H_CNT = D)
640 = 1010000000
660 = 1010010100
755 = 1011110011
800 = 1100100000
10
ROLL _OVER
COLUMN_OUT
(H_CNT = D+E)
(H_CNT= D+E+B)
(H_CNT= D+E+B+C)
10
ROLL_OVER
COUNT
“0000000000”
LOAD
CLEAR
CLOCK
1
CLEAR
D
9–0
10-bit Up counter
with load
Q
9–0
10
480 = 0111100000
494 = 0111101110
496 = 0111110000
528 = 1000010000
(V_CNT = R)
(V_CNT = R+S)
(V_CNT = R+S+P)
(V_CNT = R+S+P+Q)
ROW_OUT
10
HCOUNT
CLOCK
CLEAR
(H_CNT = D)
(H_CNT = D+E)
(H_CNT = D+E+B)
(H_CNT = D+E+B=C)
ROLL _OVER
Q
9–0
(V_CNT = R)
(V_CNT = R+S)
(V_CNT = R+S+P)
(V_CNT = R+S+P+Q)
Q
9–0
VCOUNT
CLOCK
CLEAR
S
CLK
R
CLEAR
Q
S
CLK
R
CLEAR
Q
S
CLK
R
CLEAR
Q
S
CLK
R
CLEAR
Q
H_SYNC_OUT
H_DATA_ON
V_SYNC_OUT
V_DATA_ON
RED_OUT
GREEN_OUT
BLUE_OUT
COLUMN_OUT
ROW_OUT
10
10
RESET
RED
GREEN
BLUE
RESET
25.175-MHz CLOCK
V_SYNC_OUT
H_SYNC _OUT
RED_OUT
GREEN_OUT
ROLL _OVER
9–0
RED
GREEN
BLUE
BLUE_OUT
COLUMN_OUT
9–0
VGS Monitor
controller
25.175-MHz Clock
Figure 5—
The VGA monitor controller circuit contains the following: a horizontal counter circuit for generating the horizontal sync and column count signals (a); a vertical count-
er circuit for generating the vertical sync and row count signals (b); a complete VGA controller circuit (c); and a logic symbol for the controller circuit (d).
a)
b)
d)
c)
(= 95)
LSB
Figure 4—
A 10-input AND gate is connected to test
whether or not a number is equal to 95 (0001011111 in
binary). If the input is 95, the AND gate outputs a one; oth-
erwise, it outputs a zero.
42
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
nal. For example, at count zero, set
H_SYNC_OUT to zero; but between
counts zero and 95, H_SYNC_OUT must
be kept at zero. An SR flip-flop is used to
keep the signal steady. Recall that the SR
flip-flop sets the output Q to a one when
the input set is asserted with a one. It
resets the output Q to a zero when the
input reset is asserted with a one. If both
set and reset inputs are deasserted with a
zero, then the output Q will maintain its
current value. Hence, to obtain the hori-
zontal sync signal, you can assert the
reset input when the count is zero (or
800), and assert the set input when the
count is 95. The Q output of the SR flip-
flop is now the H_SYNC_OUT signal.
You can do one of three things to keep
track of the column count from zero to
639 in the D region. The first solution
is to use another counter that counts
from zero to 639 using the same clock
frequency as the horizontal sync counter,
but this counter counts only when the
horizontal sync counter is in region D.
This solution requires an extra counter.
The second solution is to subtract the
offset for the B and C regions, so that
when the horizontal sync counter
reaches 140 (95 + 45), you will subtract
140 to get a zero. Then, 141 minus 140
will produce a one, 142 minus 140 will
produce a two, and so on. This solu-
tion requires an extra subtraction unit.
The last solution is the best. Simply
offset the horizontal sync counter so
that you start the count at the begin-
ning of region D instead of starting it at
the beginning of region B. At the begin-
ning of region D, the count is reset to
zero. At the end of region D, the count
will be at 639. This way, when the
counter is counting in region D, the
count will also represent the correct
column count. Hence, the counter will
reach 800 at the end of region C.
Putting everything together, you get
the circuits shown in Figure 5. Figure 5a
shows the horizontal counter with the
four AND gates for testing for the four
horizontal region values D, D + E, D +
E + B, and D + E + B + C. The output
of the counter is the column count.
The circuit also outputs a ROLL_OVER
signal, which is used to reset the hori-
zontal counter to zero and is also the
clock signal for the vertical counter.
This signal is asserted each time the
counter reaches 800. When the signal
is a one, it asserts the counter’s LOAD
input. When this happens, the 10-bit
counter input value D[9-0], which is a
constant 0, is loaded into the counter.
Note that this actually gives a total of
801 counts per line, which is one
more than intended. Fortunately,
VGA monitors are forgiving enough
to tolerate this tiny error. The
Photo 1—
The VGA monitor screen shows a red border,
two blue letters, and a green square.The UP2 development
board, which contains the FPGA chip with the VGA monitor
controller circuit, outputs the video signals to the monitor.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
43
Enoch Hwang has a Ph.D. in comput-
er science. He is currently an associ-
ate professor of computer science at
La Sierra University and a lecturer at
the University of California, Riverside.
He is interested in embedded micro-
processor systems, automation, and
robotics. You may reach him at
ehwang@lasierra.edu.
COUNT input is tied high for continu-
ous counting, the CLEAR input is tied
to a reset switch, and the clock input
is connected to the 27.175-MHz clock.
Figure 5b shows the vertical counter.
It is almost identical to the horizontal
counter circuit, except for the clock and
the values tested for by the four AND
gates. The clock for this counter is the
ROLL_OVER signal from the horizontal
counter. The values tested for by the
AND gates are the vertical region values
R, R + S, R + S + P, and R + S + P + Q.
The complete VGA monitor con-
troller circuit is shown in Figure 5c. The
H_DATA_ON and V_DATA_ON signals
are generated in a similar fashion to the
H_SYNC_OUT and V_SYNC_OUT sig-
nals, except they’re set to a one when
the counters are in the D and R regions.
Outside these regions, they’re set to a zero.
The H_DATA_ON signal is set to a
one when the horizontal counter is at
zero (800). It’s reset to a zero when the
counter is at 640. The V_DATA_ON
signal is set to a one when the vertical
counter is at zero (528). It’s reset to a
zero when the counter is at 480.
These two DATA_ON signals are used
to enable the output of the RBG sig-
nals. The RGB signals connected to
the monitor must be turned on only
when the two sync signals are in
regions D and R. Three AND gates,
one for each of the three color signals,
are used to enable the color signals.
The H_DATA_ON and V_DATA_ON
signals are the enabler lines to the
AND gates.
The logic symbol for the VGA
controller is shown in Figure 5d. The
H_SYNC_OUT, V_SYNC_OUT,
RED_OUT, GREEN_OUT, and
BLUE_OUT signals connect directly
to pins 13, 14, 1, 2, and 3 of the VGA
connector. You can optionally connect
a switch to the Reset input. The clock
source is a 25.175-MHz clock. To dis-
play something on the screen, you need
to check the values of COLUMN_OUT
and ROW_OUT, and set the RED,
GREEN, and BLUE signals accordingly.
CONTROLLER TEST
To turn on a particular pixel, you need
to test the values of the column and row
counts from the controller. If they are
equal to the location of the pixel you
want to turn on, then you assert any of
the color signals, and that pixel will be
turned on with that color. For example,
if you want the pixel at column 3, row 5
to be blue, then you need to check
the values of COLUMN_OUT and
ROW_OUT from the controller to see if
they are equal to three and five respec-
tively. If they are, set the BLUE input sig-
nal to a one; otherwise, set it to a zero.
Figure 6 shows the circuit for dis-
playing a red border around the moni-
tor using the VGA monitor controller.
Four AND gates are used to test for
the column and row border values.
Because the screen resolution is 480 ×
640, the four border values to test are
column = 0, column = 639, row = 0,
and row = 479. If one of these tests is
true, then set the red signal to a one.
Instead of using discrete ICs for con-
structing the controller circuit, I imple-
mented the controller on an FPGA chip
using Altera’s UP2 development board.
The board has a built-in VGA connector
with the five signal pins connected to the
FPGA chip. The VGA monitor controller,
along with a demonstration test circuit
for creating a screen image, is imple-
mented in the FPGA chip on the board.
Photo 1 shows the UP2 board having
the controller circuit and a demonstra-
tion test circuit implemented in the
FPGA. The demonstration test circuit
generates a red border, two blue letters,
and a green square on the monitor screen.
Rather than manually connecting the
numerous AND and OR gates needed for
comparing with the various column and
row values to turn on the RGB signals, I
have written a VHDL code for the test
circuit. The complete test circuit code for
generating the image is posted on the
Circuit Cellar
ftp site. After synthesizing
the code, the resulting netlist, along with
the monitor controller circuit, is down-
loaded to the FPGA chip. The result is
shown on the monitor in Photo 1.
In order to display more complex
images, memory is used to keep track of
which pixel should be turned on or off
and for which color (instead of using
numerous AND gates as comparators to
check for the current column and row
values). If you have one memory loca-
tion for each color of each pixel, you can
use the column and row counts from the
controller as the address for the memory.
The content of the memory location
will be the value for the color signals.
I
SOURCE
UP2 Development kit
Altera Corp.
www.altera.com
RESET
25.17-MHz CLOCK
RED
GREEN
BLUE
V_SYNC_OUT
H_SYNC_OUT
RED_OUT
GREEN_OUT
BLUE_OUT
COLUMN_OUT
9–0
ROW_OUT
9–0
VGA Monitor
controller
VERT_SYNC (pin 14)
HORIZ_SYNC (pin 13)
RED (pin 1)
GREEN (pin 2)
BLUE (pin 3)
Reset button
25.17-MHz Clock
‘0’
‘0’
Row = 0
Row = 479
= 0111011111
Column = 0
Column = 639
=1001111111
To
VGA monitor
connector
Figure 6—
Use this circuit to display a red border around the VGA monitor using the VGA monitor controller.
PROJECT FILES
To download the code, go to ftp.circuit-
cellar.com/pub/Circuit_Cellar/2004/172.
44
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
I’ll bet that more than one FPGA
enthusiast out there will suggest that you
need nothing more than one big FPGA.
Get rid of the microcontroller, get rid
of all the other ICs, and put everything
inside the FPGA. Get rid of the Ethernet
controller too (that will fit inside the
FPGA no problem), and you might as well
add the kitchen sink. Of course, enthusi-
asts like that might just forget to tell you
that you’ll need to spend the rest of your
youthful years designing such a system.
Returning to real life, you’re probably
wondering if there is a line to be drawn.
How much should you put in the FPGA?
Do you need a supporting microcon-
troller? How much should it be doing? Do
you really need an Ethernet controller?
Won’t that mean the FPGA will be doing
A
nother article about Ethernet and
embedded systems? Well, yes, but here
I’m talking about 100 Mbps. Yes, the fast
version, not the 10-Mbps sloggers usual-
ly associated with small embedded sys-
tems. Who wants high-speed Ethernet
anyway? I thought you might ask. If you
need to feed data from a fast source such
as a CCD camera, voice, or high-speed
data converter, you’ll need to use a high-
speed method of getting it into your PC.
FireWire and USB2 are possibilities, but
Ethernet remains one of the comfiest
methods for packing fast data into a PC.
It also means your peripheral can be
sited a long way away, something you
just can’t do with FireWire and USB.
Mind you, it’s difficult enough to get
a 10-Mbps Ethernet controller working
anywhere near full speed when paired
with a small microcontroller. These
cronies can take an eternity to move
data in and out of the line, and they do it
mostly 1 byte at a time. Slap in a faster
microcontroller? It won’t necessarily
help. You will need a pretty powerful
32 bitter plus a good helping of side IC
condiments before anybody notices the
difference. This article is about modesty
anyway. How can you stay below the
clouds and still get the performance by
using relatively cheap hardware?
HELP FROM FRIENDS
Chances are you’ve been peeking at
the captions before reading this. You may
have noticed that FPGAs are mentioned.
Aha, that’s how you do it. You slap in a
fancy FPGA to do the fast work, and let
the MCU fulfill its existence by doing the
boring tasks such as housekeeping and
flashing the LEDs. Well, that’s the gist.
But how do you design such a system?
little? And the bottom-line question to
cap it all: How can I finish this project
while doing as little work as possible?
Those were the questions I was grap-
pling with when designing a specialist
high-speed interface for a PC. In the end,
my old friend the wizard Gandalf showed
me the way. Well, he wasn’t really a wiz-
ard, just a colleague who used to work for
Gandalf, at least he had a grayish beard.
He impressed upon me that one of the
karmas of life enjoyment is to use as
much off-the-shelf technology as possible,
even if it costs more. This brilliant piece
of logic assumes, of course, that you are
not slaving for a mass-market toy manu-
facturer where the opposite applies and
life appreciation issues are not an option.
Delving into this obvious reinvent-the-
wheel type of advice, I decided to find the
best route. Not so much in terms of min-
imum parts cost, but in terms of value
for my money and peace of mind.
Seasoned electronic designers and
microcontroller software designers can
look at a project and quickly visualize
the amount of effort required for develop-
ment. Not so with FPGAs, especially
where you may be hitting their hidden
performance walls. Development and
testing time for these things can be pret-
ty heavy in terms of manpower and gen-
eral aggravation. On a par-to-par compar-
ative basis, software development for a
microcontroller is more result-effective
than low-level development for an FPGA.
So I should resist the geek’s temptation
to put everything under the sun in the
FPGA, and accept old Gandalf’s advice.
The FPGA only needs to do what is
minimally required of it. All of the
unused ICs and facilities can go uncon-
nected and unused. For this project,
FEATURE ARTICLE
by Eddie Insam
Interface Ethernet and Embedded Systems
Photo 1—
As you study the prototype layout, note the
Ethernet LAN controller at the top and FPGA in the
middle of the board.
Fast Ethernet and small microcontrollers do not mix, or so they say. In this article, Eddie
shows you how to add full-speed, 100-Mbps Ethernet to an embedded system. Read on to
learn about the supporting hardware that will help you get the job done.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
45
only the extremely fast payload data
transfers need to be implemented using
fast logic. This is where the FPGA
comes in. The rest of the job is handled
with an off-the-shelf microcontroller
and a standard Ethernet controller.
WHAT DOES WHAT?
You have a microcontroller, an
Ethernet interface chip, and an FPGA.
Photo 1 is the general prototype PCB
layout. The general block arrangement
is shown in Figure 1.
Note how the FPGA sits between the
microcontroller and the Ethernet con-
troller. Within the FPGA, a data multi-
plexer steers control to the Ethernet
chip between the microcontroller and
the rest of the processing subsystem.
This is an extremely convenient
arrangement. The microcontroller can
drive the Ethernet chip directly for ini-
tialization purposes and for handling
low-speed protocols such as ARP and
ping. The multiplexer switch is flipped
over to the FPGA only when there is
fast data that needs to be moved
across. This data is input in 16-
bit parallel form directly from
the external hardware device (a
fast A/D converter in this case).
A similar kind of logic
applies to the transmission of
data. Input data is shifted to
the Ethernet chip when it is
ready to transmit the payload,
and after the microcontroller
has preinitialized all of its reg-
isters. Although the FPGA’s job
is simple, it still needs to per-
form some semi-skilled jobs
(e.g., calculating Internet check-
sums on the fly), so it
isn’t completely dumb. In
fact, in this design, I used
a custom CPU core to
perform these functions.
This multiplexed arrange-
ment is good for develop-
ment. The FPGA can be
programmed out of the way.
In other words, I can write
a simple FPGA program
to connect the microcon-
troller’s pins directly across
to the Ethernet controller
chip. This means I can
develop software and test
the board without the added complexity
of having an FPGA program to deal
with as well.
I used a T89C51RD2 microcontroller,
which is an 8052 clone with a couple of
interesting features. It can be programmed
directly via the serial port using standard
Intel hex files. In addition, it has 64 KB of
EEPROM program space, which I found
nifty for holding the FPGA fuse bit file.
ETHERNET CONTROLLER CHIP
If you have done embedded Ethernet
work before, you know that a limited
number of Ethernet controller chips are
suitable for direct interfacing to embed-
ded systems. The most popular are the
Realtek 8019 and the Cirrus 8900.
The choice is also limited for 100-Mbps
controllers. This is a more complicated
choice because the standard design has a
physical split between the digital man-
agement functions (MAC) and the analog
physical interface (PHY). Sometimes
these functions are implemented as two
separate interconnected chips; some-
times they’re implemented in one chip.
The interface between these two func-
tions is a standard bus denoted MII.
The PHY side—which handles all
the analog functions, buffering, ampli-
fying, and collision detection—pres-
ents the data to the digital chip as four
parallel bits clocked at 25 MHz. The
MAC side of the pair is purely digital. It
consists of an engine that implements
the relevant parts of the IEEE 802 stack
protocol functions in firmware. The
resulting Ethernet frames are stored in
the chip’s DMA memory. They are
ready for collection by the microcon-
troller via the bus interface.
A rather convenient chip to use is
the SMSC LAN91C111. Figure 2 is a
simplified layout of its internals. The
chip combines 10- and 100-Mbps trans-
ceivers and offers full MAC functionali-
ty with PHY line management all in the
one chip. The MII interface is also
brought to the outside world, so only
half the chip can be used if required (e.g.,
when used with a separate optical PHY
interface module). This chip supports
10BaseT and 100BaseTX half or full
duplex, either switchable or selectable,
via an internal automatic Sense mode.
The host interface to the controller
is via a standard I/O-mapped space
arranged as 16 registers over three banks.
Banks are selected in the normal way
via a byte write to one of the registers,
which is mirrored into all the banks. The
data interface with the host is 32-, 16-, or
8-bit format. The internal FIFO buffer
can be allocated dynamically on the fly
for payload transmission or reception. A
hardware DMA interface facility is also
available for fast I/O transfers. However,
I found that in practice standard
I/O transfers at 16 bits managed
full 100-Mbps throughput well.
Reading and writing data to
transmit and receive buffers is
straightforward. To receive,
just sense a pin in the receive
status register, which also can
be arranged to generate an
interrupt. To read the DMA
data, allocate a pointer, and
read consecutive bytes/words
as required. The first two
words in the buffer are an error
status and size of the data
available in bytes.
10/100
Ethernet
controller
SMSC
LAN91C111
External A/D converter (data source)
LAN
Interface
8951
Microcontroller
RS-232 (External control
and device programming)
FPGA internal CPU
core and state engine
Data FIFO
FPGA
data[8]
addr[16]
ale/rd/wr
data/address/ctl
MPX
Figure 1—
Fast data is steered away from the microcontroller and into the
FPGA internals for further processing. The multiplexed arrangement conve-
niently allows the FPGA to be masked off the system during development.
Medium
interface
MAC
Handler
10BaseT
PHY
Handler
100BaseTX
PHY
Handler
Host
8-/16-/32-bit
interface
Inside the smsc LAN Ethernet controller
MAC-PHY Interface
MII
PHY Handler
MUX
MUX
Figure 2—
Take a look at the LAN Ethernet controller. The LAN91C111 per-
forms both MAC and PHY functions within one package. It also contains sep-
arate paths for 10- and 100-Mbps operation. It can interface to microcon-
trollers via 32-, 16-, or 8-bit interfaces.
46
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
To transmit data, you first need to
allocate a memory buffer. This can take
some time, so the transmit function
will wait for a short time in a loop. The
data block must be preceded with two
16-bit words, a status word, and the
number of bytes to be sent. Even if you
don’t know how many bytes you are
going to transmit at this stage, you can
always reset the write pointer and fill
this location just before actual trans-
mission. Following this operation, you
can now input the payload data sequen-
tially into the DMA register. When
you’re finished, command the MMU to
queue the data and transmit to line.
Lastly, release the memory allocated.
It’s all pretty simple stuff really, but
you need to transfer your data at inter-
vals of 80 ns or so per write to keep up
with the overall 100-Mbps rate. Apart
from this, the SMSC device is remark-
ably similar to its Realtek and Cirrus
10-Mbps counterparts.
So much for the overview. The
SMSC datasheet and the various appli-
cation notes contain pseudo-code list-
ings for initialization and for basic
data transfer procedures, so I won’t
delve into these matters here.
Ah, but I didn’t quite tell the full story.
Housekeeping functions in 100-Mbps
devices are more complex than those
in their simple 10-Mbps cousins. This
is reflected in the complexity of the
options required for setting up initial reg-
isters. For example, the chip can be set
for 10 Mbps, 100 Mbps, or Auto-negoti-
ate mode (where the chip negotiates
with the hub for best speed). Half and
Full Duplex modes are also available.
Oh, yes, the negotiation sequences at
power-on can take some time, and may
not always succeed (i.e., the hub may
not support the required functions), so
you need to take care of this as well.
And there’s more. Initializing the
chip is done by writing bytes into a
handful of I/O-mapped registers in the
MAC section. The PHY section of the
chip also needs to be initialized. But
guess what? There is no direct register
access to the PHY section. How does
SMSC do it? Via the MII interface, of
course, and by bit-banging a serial
stream via two dedicated lines.
Where do you come in? You have to
write the software in the host to bit-
bang this serial stream via bits in one
of the MAC registers. This is not such
a difficult thing to do, but it will add a
few more hours under the hammer.
Fortunately, examples are provided in
the application notes.
It is a bit annoying that that this is
not clearly explained in the datasheets.
Another point of confusion is that in
order to initialize certain functions
similar-sounding register names have to
be set in both the MAC and the PHY
sections. Again, it isn’t clearly docu-
mented. It can cause a bit of frustra-
tion. It did to me anyway.
FPGA
I used Altera’s ACEX EP1K50 fami-
ly for no reasons other than it was
available at the time and I’ve used it
in a number of previous projects. An
advantage is that its I/O pins are 5-V
tolerant when the chip is run from a
3.3-V supply. In a new design I would
be looking at a more up-to-date device
such as Cyclone. For FPGA develop-
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
47
ment, I used the Quartus II develop-
ment environment, which is free on
Altera’s web site. (It’s also available as
a CD-ROM if you ask nicely.)
The FPGA talks to the microcon-
troller via I/O parallel data pins, making
use of the ALE, RD, and WR lines in
old, standard 8051 Access mode. In this
context, the FPGA looks to the micro-
controller just as a standard outboard
peripheral. The FPGA appears to the
software as a collection of read/write
registers, some read only, some write
only. Other registers are directly mapped
to the FPGA’s internal RAM. The FPGA
RAM is used to store the core CPU
program as well as input and output
payload data.
If you have never used FPGAs before,
it is not all that difficult to get started.
The learning curve is steep but worth-
while. You don’t even need to spend
vast amounts of money. The circuit in
Figure 3 and the free downloadable IDE
are all you need (and plenty of spare
time too). The simplest way to get
started is to download the IDE and fol-
low the built-in tutorial. You don’t even
need the programmer or any hardware
while you are learning. Results are sim-
ulated and displayed on your PC screen
as waveforms.
TRICKS OF THE TRADE
Almost all FPGAs need start-up boot-
ing. This means transferring a fuse file
from an external permanent memory
such as EEPROM into the FPGA at
power-on. Even though specialist config-
uration devices are available, I
decided to use the micro-
processor itself to store the
fuse file and to provide the pro-
gramming timing pulses. With
the Atmel 8051 having 64 KB
of code space, there should be
plenty to spare. The timing
requirements and file formats
are all well documented and
simple to implement. It also
saved me from having to
include an extra EEPROM
device on the board and to pro-
vide an extra program pod
interface. In other words, I
don’t need the circuit shown in
Figure 3 to program the FPGA.
The microcontroller does that.
Quartus can generate a binary image file
(.RBF), representing a bit-for-bit image of
the mask to be loaded into the FPGA.
The only thing I needed to do was write
a bit of PC code to convert this to a
standard hex file and download it to the
8051 somewhere near the top of the
64-KB memory space. One thing I didn’t
realize at the time was that the RBF file
generated by Quartus was about 98-KB
long, far more than the 64-KB memory
space available in the 8051, bother!
Before heading for the bottle and
summoning my friend the wizard, I did
a quick visual check of the binary file.
This revealed a lot of redundancy in the
form of long strings of zero bits. Based
on my years of experience, I figured that
a simple run length compression algo-
rithm would reduce the size of the file,
at least to within the size of the 8051’s
code area. The encoding method has to
be simple in order to allow the micro-
controller to decode the file fast enough
as it ditches the bits into the FPGA.
A crude statistical analysis showed
that repeated strings of zeros are com-
mon, but repeated strings of other
bytes are not. The encoding method I
eventually used is simple. Strings of
zeros that are 2 to 255 bytes long are
encoded as a 2-byte sequence:
<55hex><nnhex>
where nn is the number of zeroes in the
string. A single zero byte is not encoded
as a byte pair; it’s kept as a single byte
because there are a lot of them. Any
occurrences of the 55hex byte, or the
escape byte, in the file are encoded as
the <55><00> byte pair. The escape
byte, 55hex, was chosen because it does
not occur too often in the file.
A better alternative might have been
to move up to Cyclone, with its own
built-in program compression. But at
this late stage, I decided I wouldn’t be
starting over!
HOW’S IT WORK?
Oh gosh, here comes the boring bit.
At power-on, the microcontroller dumps
the uncompressed RBF bit file into the
FPGA. After this, the microcontroller
performs a simple test by reading back
one of the registers from the FPGA on
the following assumption: if it can read
it, the FPGA must be working.
After the FPGA is loaded, the micro-
controller initializes various FPGA reg-
isters, including the CPU core program.
Next, the microcontroller takes direct
control of the Ethernet controller by
switching the multiplexer over to its
data pins. It then proceeds to initialize
the Ethernet controller, its buffers, MAC
addresses, and mode selection. The
Ethernet chip is then instructed to go
into “speed auto negotiate,” which can
take a few seconds. If the chip cannot
negotiate 100 Mbps, or if it cannot find
the hub, it notifies the software, which
enters Sulk mode.
After the initialization code is done,
the microcontroller goes into simple
Ethernet handling. This includes
receiving frames, handling ARP, and
Figure 3—
This simple FPGA programmer works with most Altera devices. Connected via the PC parallel port, it’s used in con-
junction with the Quartus IDE.
48
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
ICMP ping maintenance.
I didn’t use the FPGA at all during
most of the initial development. All
the code, including data transfers and
UDP connections, was initially done
on the microcontroller as function
placeholders. The FPGA simply acted
as a data feed through the device
between the microcontroller and the
Ethernet controller chip. I can tell you
that leaving the FPGA out of the way
during development made life a lot
easier!
Luckily, there are few differences
between writing IP code for a 10-Mbps
system and a 100-Mbps system. So,
the snippets of code I had already used
from a previous Realtek incarnation
came in pretty handy here. The SMSC
chip required a few changes to the
low-level drivers, but that was it.
BRING THE REINFORCEMENTS
When I was satisfied that it all
worked properly, it was time to start
the FPGA turbocharger. In normal
operation, the FPGA is brought into
play when a block of payload data is
available for transfer. The 8051 passes
control to the FPGA only at these
points.
Datagram transmission is initiated
when data in the input FIFO within
the FPGA has reached a certain size.
In this project, an external A/D con-
verter feeds continuous data into the
FIFO via its own parallel port. When
full, a flag is set, which starts a pro-
gram cycle. This causes the FPGA
CPU core to take over the Ethernet
controller chip and dump the contents
of the FIFO directly into the Ethernet
chip’s own DMA area.
In practice, the FPGA hardware
dumps three separate RAM buffers: one
containing the Ethernet header, anoth-
er containing the IP and UDP headers,
and a third (the FIFO) containing the
payload (the ADC data). The first two
RAM areas, which are preloaded by the
microcontroller during call setup, con-
tain relatively static information such
as MAC and IP addresses (source and
destination). I could have allowed the
microcontroller to dump the Ethernet
and IP/UDP headers from its own
internal program, and then pass con-
trol to the FPGA only when the actual
FIFO payload needs to be transmitted.
Well, maybe next time. A similar pro-
cedure is used to receive data, only in
reverse.
CPU CORE
Did I say I was going to implement
a CPU core within the FPGA? Isn’t
that over the top?
To keep things in perspective, the
FPGA data transfer processor needs to
do quite a few things. It has to wait
until it receives notification from the
FIFO that is full, run a fixed sequence
to modify some registers, and then cal-
culate checksums and dump the
words into the Ethernet controller.
When it’s done, it goes back into
limbo mode, until the next request is
received. The data receiver works in
the same way but in reverse.
A programmer would feel at home
writing computer code to perform these
tasks, however, in hardware, things are
slightly different. One option is to use
state-transition table machines. During
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
51
each state, the registers and
logic perform one function. At
the next state, a different func-
tion is performed, and so on.
When the complexity reaches a
given size, it is actually better to
implement these things using a
CPU core. After all, a CPU is
nothing but a collection of gates
and registers running a state
table, so why not use part of
the FPGA to emulate a known
CPU structure bit for bit?
I soon realized I was going to
need some custom instructions
(e.g., a one’s complement adder
to perform Internet checksums),
so I decided against using a ready-made
core (e.g., Nios). I chose to implement
my own, thus satisfying every engineer’s
boyhood dream of inventing his own
CPU. Figure 4 shows the results.
Being aware of the wizard’s warning
about reinventing the wheel, I realized
that the resultant CPU must be easy
to design and, more importantly, to
program. At the same time, I was
aware it would probably take me more
time to become conversant with an
existing off-the-peg CPU core, which
possibly would not run fast enough.
I had to make some decisions before
designing the core. I reached for my
book on CPU design to get some ideas.
To make life easy, all instructions run
in a single machine cycle. Making the
instruction size as wide as possible can
help this. I found that an 18-bit wide
instruction set was right for this job.
Placing instructions
and operands in sepa-
rate bit slots creates an
orthogonal instruction
set that’s easy to syn-
thesize and visualize
(albeit inefficient for
storage), but this didn’t
matter too much here.
The required applica-
tion program is small. I
allocated 256 words of
the FPGA’s dual-port
RAM for CPU program
memory. This allows
for up to 256 instruc-
tions of 18 bits each,
which is plenty for this
application. This pro-
gram memory area is written to by the
microcontroller once during power-on.
It is accessed as read-only by the CPU
core instruction counter. Extremely
simple so far.
The CPU cycle times are dictated by
the read and write set-up times of the
Ethernet controller chip. According to
the specifications, it requires a mini-
mum of 80 ns for reads and writes, with
a 100-ns rest time in between. The con-
troller also provides a signal (RDYON),
which is used to halt the CPU clock-
ing until the operation is performed.
The FPGA is clocked at 80 MHz.
Using a 16-clock cycle results in the tim-
ing sequence shown in Figure 5. The
main cycle time signal, which occurs
once per cycle, is used to increment the
program counter and to clock-enable all
of the internal registers, thus ensuring
that the registers are clocked at the same
time. An exception is the write
pulse to the Ethernet controller,
which must be somewhat nar-
rower to meet the specifica-
tions. A wider version of the
write pulse is used to manage
the data multiplexer between the
8051 and the Ethernet chip. This
is shown as nENA in Figure 5.
After an instruction clock
edge, and at the end of cycle 0,
the instruction will have been
fetched, all the registers will
have placed their value on the
bus, and the result of any opera-
tion will be available to the reg-
isters. The multiplexer will
take some time to settle (because of
the slow bus interface) before reading
or writing to the Ethernet controller.
The wait signal from the Ethernet
controller (IORDY) is connected to the
cycle counter’s enable input. When and
if the controller is waiting, the cycle
counter will stop until the Ethernet
controller is ready.
There is one direct interface to the
8051 via the general-purpose, 8-bit regis-
ter REGA. One of the bits (bit 7) is used
to reset the CPU core program. When the
8051 sets this bit, the CPU core starts
from program address zero. The reset
is performed asynchronously, which is
perfectly harmless in this context.
INSTRUCTION SET
I resisted the temptation to design a
full set of instructions and stuck only to
those necessary to run the program. As
you can see in Figure 4,
there are two I/O regis-
ters that the core can
read, three RAM data
areas, and three 16-bit,
general-purpose regis-
ters. The arithmetic unit
performs basic opera-
tions such as adding,
moving, and copying
data to and from the
Ethernet controller.
A number of special-
ist instructions give
the core its speed and
performance. For exam-
ple, one of the instruc-
tions performs several
operations in parallel. It
Figure 5—
The timing diagram and basic orthogonal instruction set are for the core CPU. This is a
basic design with all operations performed within one instruction cycle. I used a plain orthogonal
18-bit-wide instruction set for simplicity.
E
F
0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F
0
nWETH
nENA
PCE
One cycle
Instruction
MOVE OPCODE
Ethernet register address
Immediate value or GP register address
Logical condition
JUMP/BRANCH OPCODE
Relative/absolute address
MOVE/ARITHM OPCODE
Logical condition
Immediate value or GP register address
ACCB (8) ACCA (8)
ACCW (16)
ACCD (16)
ACCC (16)
ACCN (16)
PCNTR (8)
STACK (8)
FREGA (8) w/o
FREGB (8) r/o
FREGC (8) w/o
Static RAM
64 8-bit bytes
Static program ROM
64 16-bit words
Ethernet controller chip
16 x 16 bit data registers
CPU Core arithmetic unit 16-bit (wide) instructions
Dual-port RAM
1,024 words
of 16-bit FIFO
circular buffer
FIFO
hardware
controller
External input (16-bit A/D converters)
8051 Microcontroller
Figure 4—
The need for specialist instructions and the simplicity of the oper-
ation can make a customized core a better design option than a ready-
made, off-the-shelf one.
52
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
copies a block of 16-bit
words from the RAM area to
the Ethernet controller data
register. Register A contains
the starting address in the
RAM. Register B contains
the number of words to copy.
An Internet checksum is cal-
culated on the fly as the
transfers are made and
accrued into register C.
A nifty way to calculate
the Internet one’s comple-
ment checksum is by using a
full adder and feeding the
carry output back to the
carry input. When the 8051
kick-starts the transmit (or
receive) program, it runs the
relevant set of instructions until it
reaches the end. Then it stops. During
this time, it copies the RAM’s contents
to the Ethernet controller and updates
the IP datagram variable fields (check-
sums, the ID counter, and others as
necessary). The Ethernet controller is
then triggered for transmission. The
cycle is repeated as soon as there is
more data to transmit.
UDP CHECKSUM
Figure 6 shows the three data block
headers that the controller needs for a
typical UDP datagram transmission.
The first block is the Ethernet frame
header, which consists of source and
destination MAC addresses plus a pro-
tocol field. This data does not change
during a session; it’s transmitted
unchanged for every block transmitted.
The next two headers, IP and UDP,
are more complicated. These require
some fields, such as checksum, to
change for every transmitted frame.
How is this handled? Figure 6 provides
some answers. The 8051 handles setting
up a call (i.e., the original ARP requests
and any information requested by the
remote). This allows the microcontroller
to load session-dependent variables such
as remote MAC, IP, and port addresses
into the various unchangeable fields in the
corresponding headers. The fields won’t
change during a session. For all intents
and purposes, all the information in the
three headers is constant for the session.
To simplify things, all UDP datagrams
transmitted are the same size, and frag-
mentation isn’t provided. Option fields are
not included within the IP header. This
also makes other fields unchangeable.
At this point, there are only three
fields that need dynamic updating: the
IP header ID number, the IP header
checksum, and the UDP header check-
sum. The general rule is that the IP head-
er’s ID number has to change for every
datagram transmitted. In practice, it is
incremented modulo 2
16
. This also
means that the IP header’s checksum has
to be recalculated, because it is the sum
of all the IP header’s fields. Fortunately,
there is no need to recalculate the IP
header checksum every time. Its value
can be simply decremented by one as the
ID field is incremented by one, thus
maintaining a constant sum. Needless to
say, a special instruction in
the CPU core is used specif-
ically for this purpose.
The UDP checksum is
somewhat more complicated.
It must be calculated over the
payload data as well. In addi-
tion, it must be written into
the array before the payload
is entered. This is a difficult
thing to do because the pay-
load data arrives in real time.
One option is not to use UDP
checksums at all. But, I was
cleverer than that. In control
of the payload formats, I
decided to add an extra 16-bit
word at the end of the pay-
load field. This is to be
ignored by the receiver end, but it
allowed me to place a dummy checksum
at this point. The original checksum
entry in the UDP header is filled with a
constant value, and the last word is filled
with the accrued checksum as calculated
by the CPU engine. The important
thing here is that all the words in the
datagram must add to 0xFFFF, so it
doesn’t really matter where the check-
sum is placed.
POOR MAN’S ASSEMBLER
I decided to download the CPU core
instruction set to the FPGA from the
microcontroller during power-on
rather than hardwire the instruction
set during FPGA compilation. As the
CPU core program is fixed, either
Listing 1—
Only a few instructions are listed here. The orthogonal instruction set ensures that each part of
an instruction can be assembled separately.
// Data as stored in the microcontroller’s EPROM area
uint pdata fpgarom[]
{
0x1E00,
0x1080,
0x1002,
.. etc }
// The defines that describe the opcode sections:
// first the opcodes
#define
MOV_ETH_IMM
0x1000
#define
MOV_ACA_ETH
0x3000
// then the registers
#define
R00
0x0000
// register 0
#define
R01
0x0100
// register 1
#define
RBNK
0x0E00
// BANK register
// and a typical section of CPU core “source” code
// note the “or” statement to combine the separate
// elements of the orthogonal instruction set
MOV_ETH_IMM
| RBNK
| 0x00,
Destination MAC addr (fixed)
Source MAC addr (fixed)
0x800
Ethernet RFC894 header
ver(0x04) hlen(0x05)
TOS (0x00)
Total datagram length (fixed)
Identification (var)
Fragment information (0x0000)
TTL (0x80)
protocol (0x11)
IP header checksum (var)
Source IP address (fixed)
Destination IP address (fixed)
Options (none)
Source port (fixed)
Destination port (fixed)
UDP total length (fixed)
UDP checksum (var)
UDP payload (fixed length)
Figure 6—
The headers and payload data as queued for transmission. Some fields
are constant for the duration of the session. Others, such as the Internet checksum,
need to be calculated on the fly by the core CPU within the FPGA.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
53
method is equally suitable. The reason-
ing behind this is simple: saving time
during development. A typical FPGA
compilation program load cycle can
take several minutes, whereas a compile
run on Keil’s IDE takes just a few sec-
onds. The code is declared within the C
compiler source as a list of constant 16-
bit data values. The CPU core program
is stored in the 8051’s program ROM
space. When the 8051 fires, it copies
this to the FPGA’s program RAM.
In order to provide some sense of
proportion, I decided to implement a
rather crude CPU core assembler
using C language’s define instructions.
A crude method, but it works. It also
avoids me having to spend the rest of
the season writing an assembly trans-
lator for this CPU.
Listing 1 shows the results. I included
only a few of the instructions to show
the principle. The orthogonal instruction
set ensures that each part of an instruc-
tion can be assembled separately as an
OR combination of
#define statements.
The list of opcodes is one set of
#define
statements. The next is the list of regis-
ters. The next forms either a constant
or a source/destination combination.
NOT WITHOUT DIFFICULTY
Working with mixed-development
technologies can be a nightmare. At
all stages of development, the PC
screen showed the MSC IDE, Keil
microcontroller IDE, Quartus IDE, and
Acrobat reader. At times, small changes
to the design required a domino
sequence of recompilations for each of
the IDEs in turn. These were rather
lengthy operations, which resulted in
me drinking far more coffee and chew-
ing more sweets than I would have
liked. Nevertheless, it was reassuring
to see a complex design come out of
the box that actually worked.
I
Eddie Insam lives near the Thames in
southern England. He has more than 20
years of experience working on innova-
tive telecommunications and signal
processing designs. Specializing in
audio and image processing, he has
written several articles and a book on a
number of related subjects. He wastes
RESOURCES
FPGA information and downloadable
development IDE, Altera Corp., www.
altera.com.
E. Insam, TCP/IP Embedded Internet
Applications
, Newnes Publications, 2003.
SMSC-LAN91C111 Ethernet controller
chip information, SMSC, www.smsc.com.
SOURCES
EP1K50 (ACEX PLD) and Quartus II
Altera Corp.
www.altera.com
T89C51RD2 Microcontroller
Atmel Corp.
www.atmel.com
LAN91C111 Controller
SMSC
www.smsc.com
the rest of his time trying to stay in a
straight line rowing boats. You can
reach him at edinsam@eix.co.uk and
visit his web site at www.eix.co.uk.
54
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
the amount of RAM and program flash
memory contained in the ATmega16.
When moving from the PIC16F877 to
the PIC18F452, the Microchip
PIC18xxxx coder gains a little more than
1 KB of RAM while matching the Atmel
coder’s 32 KB of program flash memory.
I didn’t design the TCP/IP stack for
industrial use. The mini stack I wrote
is intended to show you that compli-
cated TCP/IP stuff can be done on the
cheap with simple code. My simplistic
TCP/IP stack works well both in a
local LAN environment and on the big
wire. However, I’ve seen many of you,
especially college students, make
modifications and add features to my
little garage-built TCP/IP-UDP stack
to improve its usability (and to finish
those senior projects).
For more demanding applications, it
may be advantageous to deploy a more
robust TCP/IP stack. However, in a
microcontroller environment, space is
always constrained, and you still will
be faced with squeezing in just enough
stack to support your application.
That means the stack you choose or
write must be modular. For instance,
if you don’t need FTP, there shouldn’t
be useless FTP code floating around
taking up space in your stack. Another
point to consider is the setting up and
tuning of the stack. The stack’s knobs
and buttons should be located in a log-
ical place. They also should be easy to
understand and use.
Writing a serious TCP/IP stack is
not child’s play. If you’re not into
rolling your own TCP/IP stack, and if
you need a bit more than a minimal
A
s many of you already know,
when I’m not putting words into
Circuit Cellar
magazine I’m moon-
lighting at EDTP Electronics, which is
focused on designing and marketing
inexpensive microcontroller-based
Ethernet devices from an Internet-based
storefront. As a Circuit Cellar colum-
nist and an electronic barkeep (I’m the
“support” behind support@edtp.com),
I’m in direct contact with many of you.
Aside from enjoying shooting the
breeze, I also like that I get to know
firsthand what you’re interested in and
what problems you’re facing.
Hopefully, that makes my Circuit
Cellar
columns interesting to you.
The line of Easy Ethernet devices
are all supported by a minimal home-
brewed TCP/IP-UDP implementation.
The baseline Easy Ethernet products are
powered by 40-pin PIC and Atmel
microcontrollers that contain between
368 (PIC16F877) and 1,024 bytes
(ATmega16) of RAM complemented by
8 (PIC16F877) and 16 KB (ATmega16) of
program flash memory. That means
the Easy Ethernet Internet protocol and
application code must be minimized to
leave enough program memory space
and RAM for your application code.
To accommodate those of you who
need a bit more application space, I
employed the services of Microchip’s
next generation of microcontrollers, the
PIC18xxxx series. Atmel coders were
also considered in the upgrade process
because an easy migration path up from
the ATmega16 used on the Easy
Ethernet AVR is provided by the pin-
compatible ATmega32, which doubles
TCP/IP stack for your application,
CMX Systems is a good place to start.
CMX-MicroNet
Like its name suggests, CMX-
MicroNet is a TCP/IP stack designed
for use with microcontrollers that
contain small amounts of program and
data memory. To be able to play in
this memory-constrained domain,
CMX-MicroNet provides the applica-
tion coder with a variety of configura-
tion options. CMX-MicroNet supports
up to 127 UDP or TCP sockets. All of
the sockets can be configured as
Ethernet, SLIP, or PPP sockets.
However, you can intermix Ethernet
and SLIP sockets or Ethernet and PPP
sockets, but you can’t build a combi-
nation of SLIP and PPP sockets.
The CMX-MicroNet configuration I
have is designed to work exclusively
with the HI-TECH PICC-18 C compil-
er. It includes an HTTP web server, an
SMTP client, and a DHCP client. For
those of you who need it and have
equipment that supports it, the
CMX-MicroNet TCP/IP implementa-
tion also supports an IGMP client.
TCP, UDP, Ethernet, and ping are
also integral parts of the CMX-
MicroNet product.
I chucked all of my experimental
dial-up accounts because I felt I was
being ripped off. So, I won’t be able to
show you any of the dial-up features
offered by CMX-MicroNet. However,
there is no doubt in my mind that the
PPP and SLIP features work as adver-
tised. So instead I’ve put together a
combination of an EDTP Electronics
TCP/IP Stack Solution
APPLIED PCs
by Fred Eady
If you need more than a minimal TCP/IP stack for your next application, consider using the
CMX-MicroNet, which is a stack designed for microcontrollers that have small amounts of data
and program memory. This month, Fred describes the CMX-MicroNet’s behavior.
A Detailed Look at the CMX-MicroNet
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
55
Easy Ethernet W/PIC18 and Packet
Whacker, a microEngineering Labs PIC
Proto 80, a brand new copy of HI-TECH
C for the PIC18 microcontrollers, and a
hockey puck (MPLAB ICD 2). The
point is to show you how I learned
about the way CMX-MicroNet behaves.
CMX-MICRONET & W/PIC18
The Easy Ethernet W/PIC18 is
shown in Photo 1a. The “W” is short
for Whacker because the Easy Ethernet
W/PIC18’s Ethernet hardware is based
on the classic Packet Whacker NIC
shown in Photo 1b. The Packet
Whacker consists of an RTL8019AS
Ethernet engine, a 20-MHz crystal, a
Bothhand LF1S022-34 integrated mag-
netics package, and a complement of
supporting power supply bypass
capacitors. The Packet Whacker is
designed to interface to almost any
microcontroller that can supply it
with a minimal set of address and data
I/O lines.
The Easy Ethernet W/PIC18 takes
the basic design of the Packet
Whacker and adds a PIC18F452 micro-
controller running at 20 MHz, a regu-
lated 5-V power supply, a program-
ming/debugging interface, a data latch
(74HCT573 transparent octal latch),
and a regulation RS-232 port. The
inclusion of the programming/debug-
ging interface allows the Easy
Ethernet W/PIC18 to be programmed
using the new Microchip PM3 pro-
grammer or debugged and pro-
grammed using the hockey puck and
the MPLAB IDE. The Easy Ethernet
W/PIC18’s hardware layout is depict-
ed in Figure 1.
Before you can load any CMX-
MicroNet firmware into the Easy
Photo 1a—
The EDTP Electronics Easy Ethernet W/PIC18 is actually a product of convenience. It’s basically a Packet
Whacker with all of the supporting circuitry on a single PCB. b—The Packet Whacker is a minimal implementation of the
RTL8019AS Ethernet engine IC. Despite its simplicity, the Packet Whacker is in service in every free country of the world.
Figure 1—
The Sipex SP233ACT-based RS-232 port is a luxury option. Only the PIC and the RTL8019AS with their associated support components are needed to put the
Easy Ethernet W/PIC18 on a LAN or the Internet. However, the RS-232 port comes in handy when the Easy Ethernet W/PIC18 is used as a serial-to-Ethernet converter.
a)
b)
56
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
Ethernet W/PIC18’s microcontroller,
you must first define your desired
TCP/IP operating environment and set
up the hardware. This is easily done
by modifying the contents of a couple
of CMX-MicroNet network compo-
nent files and setting some microcon-
troller fuses within the MPLAB IDE.
The hardware setup is straightfor-
ward. Using the Configure pull-down
menu in the MPLAB IDE, I set up the
microcontroller clock for high-speed
operation and turned off the watchdog
timer, brownout detect, low-voltage
programming, and anything that has
to do with code or memory area pro-
tection. At MPLAB IDE startup, the
hockey puck sensed the PIC18F452
microcontroller and informed the
MPLAB IDE that it had found a valid
PIC18F452 at the other end of its
interface cable. Because the CMX-
MicroNet contains its own
RTL8019AS driver, I also needed to
make sure that the Easy Ethernet
W/PIC18 I/O pin definitions matched
the CMX-MicroNet driver’s I/O pin
definitions. The mapping of the
RTL8019AS drive to the hardware I/O
structure is found in the rtlregs.h file
in the C:\MICRONET\netlib directory.
The code snippet that defines the I/O
structure that is used with the PICC-
18 C compiler and the Easy Ethernet
W/PIC18 is shown in Listing 1.
The CMX-MicroNet network file
source code components are found in
the C:\MICRONET\netlib directory.
The driver for the Realtek RTL8019AS
Ethernet engine IC also can be found
in the netlib directory. Each network
source code file is compiled and
archived into the netlib.lib library
file depending on the protocols
selected in the mnconfig.h file,
which is also located in the
C:\MICRONET\netlib directory.
Refer to the Circuit Cellar ftp site for
the code snippet taken from mncon-
fig.h. I selected the TCP and UDP pro-
tocols, which kick in TCP and UDP
sockets, and requested to use Ethernet
with a checksummed UDP protocol.
That pulls tcp.c, udp.c, and mn_csum.c
from the C:\MICRONET\netlib direc-
tory into the netlib.lib compilation
and archival process. I elected to
allow the Easy Ethernet W/PIC18 to
be pinged. Notice that I also turned
on the HTTP server, SMTP, ARP,
DHCP, and the CMX-MicroNet vir-
tual file system. That results in
including arp.c, http.c, smtp.c, and
so forth.
There are also other elements that
are automatically included that are
common to all of the protocols, such as
ip.c and socket.c. The RTL8019AS driv-
er is represented by rtl8019.c. Judging
from my list of protocols, it looked like
the PIC18F452 was going to be packed
as tight as a tube of deli bologna.
The next step in the configuration
process was to identify and specify the
IP addresses of the network players.
This is done to nail down hard-coded
IP addresses if DHCP is not being used.
My network includes a Windows
Listing 1—
The HI-TECH PICC-18 C compiler statements use the same naming convention as the Microchip
PIC datasheets. This makes it easy to read and write code with the PICC-18 C compiler. I didn’t have to
change a thing. The Easy Ethernet W/PIC18 I/O pin definitions are exactly what CMX-MicroNet wants to see
out of the box.
#elif (defined(HI_TECH_C))
#define NIC_CTRL_TRIS
(TRISE)
#define NIC_RESET_IO
(RE2)
#define NIC_IOW_IO (RE1)
#define NIC_IOR_IO (RE0)
#define NIC_ADDR_IO
(PORTB)
#define NIC_DATA_IO
(PORTD)
#define SET_NIC_READ()
(TRISD = 0xff)
#define SET_NIC_WRITE()
(TRISD = 0x00)
#define PORTA_RA5 (RA5)
#define LATA2 (LA2)
#define LATA3 (LA3)
#define INTCON2_RBPU
(RBPU)
#define NOP asm(“ nop”)
#endif
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
57
2000-based PC loaded with
packet-sniffing software, a
home-brewed Internet test
panel, and a web browser.
The gateway device
(192.168.0.1) is a Netgear
wireless router, which incor-
porates a four-port 10/100
wired switch and DHCP
server capabilities.
I pinged my ISP’s mail
server to get the mail serv-
er’s IP address (65.32.5.130)
and plugged that into the
SMTP IP address definition.
All of my IP ducks were in
a row at that point.
However, the CMX-
MicroNet installation set-
up documentation suggests
ensuring that the required
PICC-18 libraries, which
are included in the path
statement, are built, and
gives instructions on how
to make that happen.
Otherwise, the initial build
of the CMX-MicroNet
netlib.lib, which is a manda-
tory step in the CMX-
MicroNet stack generation
process, will not happen.
The library file netlib.lib
must be built before any
CMX-MicroNet stack servic-
es can be called and used.
Two batch files are included
with the CMX-MicroNet to
facilitate the construction of
a netlib.lib file: one supports
the RTL8019AS, and one
doesn’t include the
RTL8019AS driver. The
netlib.lib compilation and
archival process using PICC-
18 compiler and the CMX-
MicroNet network library
files was performed without
incident. Note that the CMX-
MicroNet installation process
had already correctly modified
the path statements.
Everything up to this
point pointed to “go” for a
test compile and load of the
example code included in
*****************************************************************************************************
a)
Easy Ethernet W/PIC18 with UDP functionality only
*****************************************************************************************************
UDP Client Mode
Program statistics:
Total ROM used
15,323 bytes (46.8%)
Total RAM used 1,130 bytes (73.6%)
Near RAM used 13 bytes (10.2%)
*****************************************************************************************************
b)
Easy Ethernet W/PIC18 with UDP and TCP functionality
*****************************************************************************************************
TCP Server Mode
Program statistics:
Total ROM used 23,708 bytes (72.4%)
Total RAM used 1,200 bytes (78.1%)
Near RAM used 13 bytes (10.2%)
*****************************************************************************************************
c)
Packet Whacker/PIC18F8621 with UDP, TCP, and DHCP functionality Server mode
*****************************************************************************************************
UDP Example Code
Program statistics:
Total ROM used 27,954 bytes (42.7%)
Total RAM used 1,836 bytes (47.8%)
Near RAM used 17 bytes (17.7%)
TCP Example Code
Program statistics:
Total ROM used 28,024 bytes (42.8%)
Total RAM used 1,836 bytes (47.8%)
Near RAM used 17 bytes (17.7%)
*****************************************************************************************************
d)
Packet Whacker/PIC18F8621 with everything turned on
*****************************************************************************************************
Program statistics:
Total ROM used 41,760 bytes (63.7%)
Total RAM used 2,281 bytes (59.4%)
Near RAM used 17 bytes (17.7%)
Figure 2a—
According to the stats, it looks like the Easy Ethernet W/PIC18 can run comfort-
ably as a UDP client. However, the RAM usage would put the binders on a large user appli-
cation. b—The package is pretty tight here. TCP consumes a lot of the PIC18F452’s ROM
and RAM. Despite that, you can still run a small but useful TCP and UDP application.
c—
DHCP was the gas guzzler when I was riding on the W/PIC18. With UDP, TCP, and
DHCP active plus an additional 478 bytes of receive buffer, I haven’t even reached the
halfway point in ROM or RAM usage on the LAN buggy’s PIC18F8621. d—Wow! Suppose
you only wanted to serve web pages.You could stuff the CMX-MicroNet HTTP service and
a bunch of HTML pages into the bologna tube and probably still have room to spare.
58
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
the CMX-MicroNet package. The
PICC-18 C compiler installed without
trouble. It successfully registered and
attached itself to the MPLAB IDE.
I decided to start with the CMX-
MicroNet UDP example code in
Client mode because I could instantly
test the operation of the code and
hardware using my trusty Internet test
panel, which enables a UDP echo port
on the PC at 192.168.0.2 on the
Florida room’s CMX-MicroNet LAN.
Server mode or Client mode for UDP
and TCP sockets is available by sim-
ply completing the
#define SERV-
ER_MODE statement in the example
code with a
0 for Client mode and a 1
for Server mode.
I performed a final check on the
PIC’s fuse settings and kicked off the
compile session. I could hear a TV
game show’s “loser” buzzer go off
loudly as the error-filled contents
rolled through the MPLAB IDE output
window. (Refer to the Circuit Cellar
ftp site for the code snippet.) I fired off
a quick note to the CMX-MicroNet
support folks describing my dilemma.
Photo 2—
The EDTP Electronics Internet test panel is a Visual Basic application that implements a simple UDP echo
function on well-known port 7. The test panel can also function as a UDP client that interacts with an Easy Ethernet
W/PIC18 acting as a UDP server.You can test drive the Internet test panel by checking out the EDTP web cam.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
59
The verdict: Stupid Fred was out of
PIC18F452 program and data memory.
So, I had to pull some of that bologna
out of the tube.
I turned off TCP, HTTP, DHCP,
SMTP, and the virtual file system by
modifying mnconfig.h. I kept the max-
imum number of sockets at two, and I
didn’t touch the default receive and
transmit buffer sizes. I also kept
Ethernet support and ping capability
enabled. The ping selection doesn’t add
any additional code to the final stack.
Turning the knobs and throwing
switches within the mnconfig.h file
requires a rebuild of the netlib.lib file.
Rebuilding the netlib.lib file is as simple
as making the changes in mnconfig.h,
saving the changes, and executing the
CMX-MicroNet’s mkphpice.bat batch
file. If Ethernet support is not required,
the mkphtpic.bat file can be used to
generate the new netlib.lib file. I com-
piled the UDP example code again.
This time I was rewarded with a
“BUILD SUCCEEDED” message and
the statistics you see in Figure 2a.
Photo 2 is a composite shot of the
Internet test panel talking UDP with
the Easy Ethernet W/PIC18 and the
Netgear router’s view of its attached
devices. Notice that because DHCP
is turned off, the Easy Ethernet
W/PIC18’s IP address is the IP address
I hard-coded into the CALLBACK.c
network file in the snippet posted on
the Circuit Cellar ftp site.
I also hard-coded the PC destination
address in the CMX-MicroNet exam-
ple code with the following statement:
byte my_dest_addr[IP_ADDR_LEN]
= {192,168,0,2};
In addition to bouncing UDP pack-
ets off the Internet test panel, I was
also able to ping the Easy Ethernet
W/PIC18-CMX-MicroNet pair from
the PC using the Easy Ethernet
W/PIC18’s hard-coded IP address of
192.168.0.150.
The next logical step was to turn on
TCP in Server mode and try to get to
the Easy Ethernet W/PIC18 using a
Telnet session and the CMX-MicroNet
TCP example code. A look at Figure 2b
shows that I was getting close to fill-
ing up that tube of bologna. There’s
nothing exciting about looking at a
drab Telnet window. So, I’ll just say
that the Telnet session worked. The
characters were echoed to the PC’s
Telnet window from the Easy Ethernet
W/PIC18-CMX-MicroNet combina-
tion as designed.
Now that I had the Easy Ethernet
W/PIC18 jumping through hoops, I
added some fire in the form of DHCP.
There went that loser buzzer again.
Check this out:
Error[000] //Can’t find 0x2C
words (0x2C with total) for
psect bss in segment RAM
Error[000] //Can’t find 0x18
words (0x18 with total) for
psect bss in segment RAM
It looked like I was out of gas in the
PIC’s RAM area. I turned off TCP to see
if I could regain some ground. However,
even with TCP turned off, the RAM
utilization was just above 97%. That
means you can run a TCP-based or
UDP-based Easy Ethernet W/PIC18
with DHCP, but you wouldn’t have
much trunk space. So, if you’re going to
soar with the Internet eagles, it’s time
to switch your LAN locomotion.
LAN BUGGY
My new LAN buggy is composed of
a 2 × 16 LCD, a Packet Whacker, a
programmer/debugger interface (for
the hockey puck), a regulated 5-VDC
supply, and a microEngineering Labs
PICProto 80 development board carry-
ing a PIC18F8621 running at 20 MHz.
My new form of LAN locomotion is
Figure 3—
It’s extremely uncharacteristic of me not to wire in a serial port. However, I won’t be exercising the CMX-
MicroNet PPP or SLIP functionality, so it would be a waste to include a serial port here. Here’s yet another micro-
controller that is supported by the ubiquitous Packet Whacker.
Photo 3—
No rocket science here. The Packet Whacker
is wired into the PIC18F8621 according to the I/O lay-
out specified in the CMX-MicroNet rtlregs.h file. I modi-
fied the hockey puck interface cable to accommodate
the microEngineering Labs PICProto 80 ICSP connec-
tor and added some code to drive the LCD.
60
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
posing in Photo 3. The PIC18F8621 is
an 84-pin part. As you can see in
Photo 3, I didn’t use all 84 pins. So,
only the active connections are shown
in Figure 3.
I’ve already test driven CMX-
MicroNet TCP and UDP functionality
with the Easy Ethernet W/PIC18. The
reason I built up this new LAN ride is
to provide extra space for the other
CMX-MicroNet components to run.
In addition to added headroom, the
LAN buggy sports more horsepower.
Although the LAN buggy is cruising
along at 20 MHz, the PIC18F8621 has
an engine that can run at 40 MHz. So,
I put the pedal to the floor and turned
on DHCP, TCP, and UDP.
The statistics for ROM and
RAM usage for the Packet
Whacker/PIC18F8621 LAN
buggy are shown in Figure 2c.
Although the LAN buggy
has plenty of legroom and lots
of horsepower, I had to do a
bit of engine tuning to get
DHCP to cooperate. The
Netgear router never granted
the LAN buggy an IP address
although it saw the LAN
buggy’s MAC address. Again, I
turned to the CMX-MicroNet
support team. Paul’s initial
site-unseen diagnosis was that
my receive buffer was probably too
small. Hmm. I slapped the sniffer into
action. The DHCP offers from the
router were 590 bytes in length. My
LAN buggy’s receive buffer size was set
for 122 bytes. As you can see in the
Photo 4 sniffer shot, the LAN buggy was
asking for an IP address but was unable
to swallow the 590-byte offer. After I
modified mnconfig.h and increased the
receive buffer size, my little LAN buggy
was granted a lease for 192.168.0.3.
It isn’t likely that you would ever
try to cram all of the CMX-MicroNet
functionality into an application.
However, I had to know if it could be
done. So, I turned on everything with
the exception of PPP and SLIP. The
usage statistics for the big PIC are
shown in Figure 2d.
Now that everything is loaded, let’s
take a look at some of the other func-
tionality the CMX-MicroNet offers
beginning with SMTP. I’ve already put
most of the pieces of SMTP into place.
Listing 2 is a summary of what I have
defined and where I defined it. The only
additional thing I had to do to get SMTP
online was set up the mail addresses and
put some words into the mail body.
After instructing the LAN Buggy to run
the CMX-MicroNet SMTP example
code, I ended up with what you see in
Photo 5.
I got really tired of not knowing
which portion of the CMX-MicroNet
example code I was running. So, I
decided to insert some choice code of
my own to drive the LCD and tell me
which piece of example code I had
selected. The PICC-18 C compiler
comes with an LCD code module that
can drive LCDs in 4- or 8-bit mode. All
of the necessary LCD commands are
also included in the source code mod-
ule. After studying the source code for
the LCD driver, I figured that all I had
to do was modify the lcd.h file and map
the LCD driver’s I/O scheme to the
LAN buggy’s I/O scheme. To preserve
the original I/O definitions, I copied the
original LCD include file, modified it to
suit the LAN buggy, and renamed it
freds_lcd.h. The PICC-18 C compiler
also contains a nice delay function that
I included and used with the modified
LCD driver code.
Putting the PICC-18 C compiler
code together to realize
my custom LCD utility
function was a piece of
cake. The modifications
and additions I made to
get the LCD module up
are shown in Listing 3.
IT’S YOUR TURN
Now that you see that
integrating CMX-MicroNet
and the PICC-18 C compil-
er is like falling off a log,
it’s time for you to put
these tools to use in a proj-
ect of your own. CMX-
MicroNet pricing starts at
Photo 4—
I can’t tell you how many times the sniffer has saved my bacon.
Photo 5—
This was easy to accomplish. After I had all of my IP ducks pointed in the right
direction, it was just a simple matter of filling in the blanks and kicking off the program.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
61
There’s only one more CMX-MicroNet
function I haven’t tested: HTTP. I’m
out of paper. So, I’ll use the CMX-
MicroNet html2c utility. The LAN
buggy acts as a web server. Photo 6
conveys my final comments.
I
Fred Eady has more than 20 years of
experience as a systems engineer. He
has worked with computers and com-
munication systems large and small,
simple and complex. His forte is
embedded-systems design and com-
munications. Fred may be reached at
fred@edtp.com.
SOURCES
ATmega16 and ATmega32
Atmel Corp.
www.atmel.com
CMX-MicroNet
CMX Systems
www.cmx.com
Easy Ethernet W/PIC18 and Packet
Whacker
EDTP Electronics
www.edtp.com
PICC-18 C compiler
HI-TECH Software
www.htsoft.com
PIC18F8621 Microcontroller, MPLAB
IDE, and MPLAB ICD 2
Microchip Technology, Inc.
www.microchip.com
PIC Proto 80 development board
MicroEngineering Labs, Inc.
www.microengineeringlabs.com
RTL8019AS Ethernet controller
Realtek Semiconductor Corp.
www.realtek.com.tw
PROJECT FILES
To download the code, go to ftp.circuit-
cellar.com/pub/Circuit_Cellar/2004/172.
$5,500. It is a one-time license fee that
includes the full source code, no royal-
ties on shipped products, and 180 days
of technical support and software
updates. Although you’ve graduated to
the higher-powered LAN buggy config-
uration, you’ll find that with some
tuning, you run CMX-MicroNet and
your application on the Easy Ethernet
W/PIC18 as well.
The technical support teams for
both CMX-MicroNet and the PICC-18
C compiler are responsive and knowl-
edgeable. After my experiences with
both products, I can pretty much
assure you that you won’t be calling
in bug reports to either support group.
Photo 6—
This says it all.
Listing 3—
I enjoy writing utility routines from scratch, but when there’s a better wheel already rolling, I tend
to jump on it. The PICC-18 C compiler comes with a ton of utility routines that are easily customized. I simply
matched the PICC-18 C compiler LCD driver’s I/O structure to the LAN buggy’s I/O pinout and added some
LCD commands to the existing example source code to get what I needed out of the 2 × 16 LCD module.
******************************************************************
// Modifications found in freds_lcd.h
******************************************************************
#define LCD_RS
LATD4
#define LCD_EN
LATA5
#define LCD_RW
LATD5
#define LCD_DATA
LATD
#define LCD_DATA_PORT PORTD
#define LCD_RS_TRIS
TRISD4
#define LCD_EN_TRIS
TRISA5
#define LCD_RW_TRIS
TRISD5
#define LCD_DATA_TRIS TRISD
Listing 2—
Super simple. All I had to do was fill in the blanks, specify that I wanted to run the SMTP example
code, and kick off the LAN buggy. Almost all of the groundwork necessary to support SMTP already had
been done in the initial CMX-MicroNet set-up phase.
******************************************************************
// From mnconfig.h
******************************************************************
/* SMTP */
#define SMTP 1
#define SMTP_BUFFER_LEN 64
******************************************************************
// From the CMX-MicroNet example code
******************************************************************
byte from[] = “fred@edtp.com”;
byte to[] = “support@edtp.com”;
byte subject[] = “PIC18F8621 SMTP Test”;
byte message[] = “The email sent from a PIC18F8621 using CMX
MicroNet.\r\n”;
byte attach[] = “CMX MicroNet sends attachments too!\r\n”;
byte fname[]
= “micronet.txt”;
******************************************************************
// From the CALLBACK.c
******************************************************************
byte gateway_ip_addr[IP_ADDR_LEN] = { 192,168,0,1 };
byte subnet_mask[IP_ADDR_LEN] = { 255,255,255,0 };
#if (SMTP)
/* replace the ip address below with the ip address of your SMTP
server */
byte ip_smtp_addr[IP_ADDR_LEN] = {65,32,5,130};
#endif /* (SMTP) */
62
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
challenge is to provide the needed pro-
tection without placing too high a bur-
den on the system’s limited resources.
DEFEND WITH A FIREWALL
A firewall is the first line of defense
for most networked computers. It pro-
tects by screening all communication
from outside the local network and
blocking anything possibly harmful.
An embedded system can obtain fire-
wall protection from its own firmware,
from a PC that protects the local net-
work, or from a dedicated firewall
device. Many embedded systems are
behind firewalls, even when they don’t
need one for protection, because they’re
in local networks that use firewalls.
The firewall’s configuration settings
determine which local resources are
available to outside computers. It can
also defend against denial-of-service
attacks, where one or more computers
try to overwhelm a server by bom-
barding it with requests that have
forged source addresses.
N
etwork security isn’t just for desk-
top computers and large servers. Even
the smallest embedded systems can ben-
efit from measures that protect data and
code from unauthorized viewing and
malicious or unintended changes.
On a system with a network con-
nection, anything that is stored in
writable memory or needs to remain
private can be at risk. Data may be
erased or overwritten. Changes to con-
figuration settings can keep a device
from operating properly or at all.
Firmware stored in flash memory or
battery-backed RAM may be erased,
altered, or replaced by another program.
Damage can be the result of innocent
mistakes or malicious intent.
Not every system needs every protec-
tion. If the device firmware is in
masked ROM or EPROM, you don’t
need to worry that incoming communi-
cations might overwrite the firmware.
A device that wants to make its data
available to any interested party doesn’t
need to restrict viewing of the data.
Small systems that don’t use
Windows are immune to the
scores of viruses, worms, and
other security threats targeted at
Windows-specific software. And
devices that access the Internet
via occasional, brief dial-up ses-
sions are in less danger than
devices that are online 24 hours a
day, seven days a week.
Where protection is needed,
small systems can use many of
the same security measures that
larger systems use, including fire-
walls, passwords, the validation
of user data, and encryption. The
A basic rule for implementing a fire-
wall is to block all communication
except that which is explicitly
allowed. Many embedded systems use
the network only for limited func-
tions, such as responding to requests
for web pages on a specific port or for
using a single e-mail account to send
and receive messages. Device firmware
that ignores communication to unsup-
ported ports may be the only firewall
protection needed for these systems.
A dedicated firewall device can pro-
tect multiple computers in a local net-
work. It also frees the device firmware
from the burden of implementing a fire-
wall. Firewall devices are available from
Linksys and others for less than $100.
A firewall device typically has mul-
tiple LAN ports and a single WAN
port (see Figure 1). The former con-
nect to the local computers protected
by the firewall. The WAN port con-
nects to the Internet or another exter-
nal network outside the firewall. In
smaller networks, the WAN port often
connects to a cable modem or a
DSL modem that connects to an
Internet service provider (ISP).
Every communication to or from
a computer outside the firewall
must pass through the firewall.
Many firewalls have addition-
al capabilities. Linksys’s
BEFSX41 is a firewall device
that also performs the functions
of a router with network address
translation (NAT) and a dynamic
host configuration protocol
(DHCP) client and server. NAT
enables multiple computers to
share a single public Internet
FEATURE ARTICLE
by Jan Axelson
Network Security for Small Systems
Computer
Computer
Computer
Hub
Computer
Computer
Computer
Computer
LAN
ports Firewall
WAN
ports
Internet
Figure 1—
A firewall protects a local network by examining all traffic
received from outside the local network. Configuration settings determine
what can pass through the firewall.
Nervous that someone might tamper with your embedded system? It’s a common concern,
but not too many designers have the know-how to secure a small system. In this article, Jan
walks you through the process of protecting a system’s code and data.
64
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
protocol (IP) address; it increases secu-
rity by hiding the local computers’ IP
addresses from the Internet. A DHCP
client can receive an IP address
assigned by an ISP thus eliminating
the need to enter an address manually.
A DHCP server can assign IP address-
es to computers in the local network.
Most firewall devices enable you to
configure the firewall via password-
protected web pages. In a common
default setup, the firewall assumes that
local computers will access the Internet
only as clients that request resources
from remote computers but don’t need
to accept incoming requests from
unknown sources. A computer function-
ing as a client can request web pages,
send and receive e-mail, exchange files
with FTP servers, and send and request
information for any purpose.
The firewall protects the local network
by examining each IP datagram received
from outside the firewall. Internet com-
munications typically use the transmis-
sion control protocol (TCP), user data-
gram protocol (UDP), or Internet control
message protocol (ICMP). The protocols
define standard formats for messages and
supplementary information such as a
destination ports, error-checking values,
and flow-control data.
For TCP communications, a firewall
may block incoming requests to open
connections by allowing only those seg-
ments whose ACK or RST bit is set. For
UDP and ICMP datagrams, a firewall
may limit traffic by specifying allowed
source IP addresses and destination ports
for incoming UDP and ICMP datagrams.
For more sophisticated filtering, a fire-
wall can determine whether or not the
information in the headers shows that
the source and destination addresses
match those of a valid, currently active
connection. To help decide if a connec-
tion is active, the firewall can maintain
and consult a table that contains an
entry for each connection.
When a local computer sends an IP
datagram containing a TCP segment
or a UDP datagram, the firewall can
create a table entry that allows incom-
ing traffic from that datagram’s desti-
nation IP address and port. For TCP
connections, the firewall can delete
the entry when the TCP connection is
closed, as indicated by the FIN or RST
flag in a TCP segment. Because UDP
doesn’t use formal connections, the
firewall can use a timeout to decide
when to delete the entry. TCP connec-
tions can also use a timeout as a back-
up in case a connection doesn’t close
properly. For ICMP messages, which
typically provide status and control
information, a firewall may block spe-
cific requests such as Echo (ping).
One client application that can have
problems communicating through a fire-
wall involves file transfers that use the
file transfer protocol (FTP). Each FTP
transfer requires two TCP connections—
a control channel for exchanging status
and control information, and a data
channel for the file being transferred.
The client requests to establish the con-
trol channel, but the server by default
requests to open the data channel.
Many firewalls will block the incom-
ing request to open the connection for
the data channel. To get around this lim-
itation without reconfiguring the fire-
wall, the client can send a PASV or EPSV
command to request the server to use
Passive or Extended Passive mode. These
modes enable the client to request to
open the data channel’s connection using
a port number provided by the server.
Most FTP servers support Passive mode.
Extended Passive mode, which is defined
in RFC 2428, can use 128-bit IPv6
addresses rather than 32-bit IPv4 address-
es, but it isn’t widely supported yet.
FIREWALL CONFIGURATIONS
Some systems must function as
servers that accept requests to commu-
nicate from outside the local network.
Most firewalls allow several options that
enable a server to receive these requests.
In a common scenario, an embedded
system might host a web server on
port 80, which is the default port for
HTTP communications. A variety of
firewall configurations allow the serv-
er to receive incoming HTTP requests.
The most secure option is to for-
ward incoming IP datagrams that
don’t belong to an established connec-
tion only if the datagram contains a
TCP segment that in turn contains an
HTTP request directed to port 80. Not
all firewall devices are capable of filter-
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
65
ing in this much detail. Also, additional
fragments in a fragmented datagram
won’t have a TCP or HTTP header to
examine, so the firewall may need a
mechanism that allows additional frag-
ments to pass through the firewall.
Another option is to forward an
incoming IP datagram that doesn’t belong
to an established connection only if the
datagram contains a TCP segment direct-
ed to port 80. The device firmware can
check for the HTTP request and ignore
the segment if the request isn’t present.
A third option is to forward to a spe-
cific host all incoming IP datagrams
that don’t belong to an established con-
nection. This option leaves the burden
of filtering to the device firmware.
A firewall may support other config-
uration options as well. Many fire-
walls enable you to specify the remote
IP addresses from which a local com-
puter can receive traffic. This option
is useful if your embedded system
communicates only with a specific IP
address or series of IP addresses.
Other options may allow only speci-
fied computers to communicate with
computers outside the firewall or may
block specified computers from commu-
nicating with computers outside the
firewall. This way you can enable an
embedded system to communicate on
the Internet while protecting other local
computers that don’t need Internet
access. The firewall may enable you to
identify the local computers by IP
address or Ethernet hardware (MAC)
address. Using hardware addresses can
be useful if the IP addresses are assigned
dynamically and thus can change.
A firewall may enable you to block
any outgoing communication where
the source address of the datagram isn’t
a local address. This option can prevent
some malicious software from using
local computers to access the Internet.
Embedded systems that don’t use popu-
lar operating systems are less likely to
run into this hazard, however.
A firewall may also allow a comput-
er behind it to communicate without
firewall protection at all. The computer
is said to reside in a demilitarized zone
(DMZ). The computer must have its
own public IP address, and is responsible
for providing its own firewall protection.
Another option for protecting local
computers, including embedded sys-
tems, is a PC running firewall soft-
ware. To function as a firewall that
protects a local network, a PC must
have two network interfaces. An
Ethernet interface connects the PC to
the local network protected by the
firewall. A second Ethernet interface
or a modem interface connects the PC
to the world outside the firewall. For
Windows XP’s firewall, the PC must
be configured to use Internet connec-
tion sharing (ICS) with the Internet
connection firewall enabled.
RESTRICTING ACCESS
A firewall can control which local
resources are available on the
Internet. But firewalls filter only on
the information in headers. They can’t
identify specific, authorized users who
may be using IP addresses the firewall
doesn’t know about ahead of time. A
solution is to provide authorized users
with passwords that they must enter
before accessing a resource. A username
66
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
tied to the password provides additional
security and identifies who is accessing
a resource. Different usernames can
have different access privileges.
The authorized passwords and user-
names can be hard-coded into the
firmware, or the firmware can author-
ize one or more users to add new users.
For some applications, a device may
allow any user to obtain access to a
resource by filling out a ’Net form
with a username and password.
Two words you’ll encounter relating
to password protection are authentica-
tion and authorization. If you want to
access a protected resource, you must
provide authentication, or proof that
you have permission to access the
resource. After receiving a valid user-
name and password, the server grants
authorization, or permission, to access
the resource. A system uses authentica-
tion to limit access to resources. A web
server can require a password before let-
ting you receive a web page. An FTP
server can identify users who can access
specific files, delete files, and send files
to the server. An embedded system that
uses e-mail will almost certainly
require a username and password for
access the e-mail account on the server.
There are three common options for
web page password protection. A basic
option is the password box on an
HTML form. A password box is like
an HTML text box except that the
type attribute of the input tag is
password. The following is an exam-
ple of HTML code for a password box:
<input type = “password”
name=mypassword maxlength=20>
The
name attribute identifies the pass-
word box to the server. The
maxlength
attribute specifies how many characters
you can enter. Browsers display a dot or
asterisk for each character you type in
the box.
When you click the form’s Submit
button, the browser sends an HTTP
POST request with the name and pass-
word in the data area of the TCP seg-
ment. For example, if the name is “user-
password” and the password is “circuit-
cellar,” the data area contains the text:
userpassword=circuitcellar.
The password is sent without encryp-
tion, so it’s available to anyone who can
view the network traffic. The server is
responsible for reading the received
password and taking appropriate action.
TYPES OF AUTHENTICATION
For resources that require greater
protection, a server can use either
basic authentication or digest authen-
Photo 1—
When you request a resource protected by
basic authorization, the browser displays this window
requesting a username and password.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
67
tication, both of which are defined in
RFC 2617. The methods require you
to provide a valid username and pass-
word before accessing a resource. The
username and password are encrypted
when traveling on the network.
Basic authentication, which is sim-
ple enough for small systems to sup-
port, prevents most casual snooping.
However, decrypting the usernames
and passwords is trivial for anyone
who can view the network traffic and
knows the encryption method.
When you request a web page protect-
ed with basic authentication, the server
returns a request for you to authenticate
or prove that the client has permission
to receive the resource. The server does
so by returning an HTTP header with
error code 401 (unauthorized) and a
WWW-Authenticate field that names
the type of authentication required:
HTTP/1.0 401 Unauthorized\r\n
Date: Mon, 19 Jan 2004 12:05:15
GMT\r\n
WWW-Authenticate: Basic
realm=”Embedded Ethernet” \r\n\r\n
The WWW-Authenticate field names
two values: the authentication scheme,
or method, to use (“Basic” in the exam-
ple) and the realm to which the scheme
applies (“Embedded Ethernet”). After
returning a valid username and pass-
word in the format required by the
named authentication scheme, you can
access resources within the named
realm. A server can support multiple
realms to allow access to a different
set of users.
After receiving a header requesting
basic authentication, your browser
typically displays a window that asks
you to enter a username and password
(see Photo 1). After you’ve entered the
information and clicked the OK but-
ton, the browser sends an authorization
request containing the password and
username. The request travels in an
HTTP GET request that includes an
authorization request line with the
encrypted username and password:
GET / HTTP/1.0\r\n
Authorization Basic
ZW1iZWRkZWQ6ZXRoZXJuZXQ=\r\n\r\n
After receiving the GET request, the
server decrypts the username and
password. If both are valid for the speci-
fied realm, the server returns the web
page originally requested. If not, the
server typically returns another response
with error 401 and a request to authenti-
cate. Most browsers display the authen-
tication window again, but after receiv-
ing a third request to authenticate, some
browsers give up and don’t redisplay the
window. Opening a new browser win-
dow typically allows you to try again.
To prevent a determined hacker
from trying different usernames and
passwords, a server can limit the num-
ber of tries within a short period from
a single IP address.
The encryption used in basic
authentication is the Base64 Content-
Transfer-Encoding method described
in RFC 1521, except for the specified
limit of 72 characters per line.
During the encryption process, the
data to transmit is first divided into
24-bit chunks. Each chunk is then
divided into four 6-bit values. A table
provided in the standard assigns a
character in the BASE64 alphabet to
each 6-bit value (0 to 63). The BASE64
alphabet includes uppercase and low-
ercase letters, numerals, and a few
additional characters.
In a request for basic authorization,
the client converts a string in the
user_name:password format to
BASE64. The resulting characters
transmit in the authorization field of
the HTTP header. For example, if the
username is “embedded” and the pass-
word is “Ethernet,” then the string to
encrypt is embedded:ethernet. Each
character is a byte, so this example has
17 bytes, which divide into 22 6-bit val-
ues with 4 bits left over. To obtain an
integral number of 6-bit values, pad the
end with two zeros. Encrypting the
username and password generates a
23-character string:
ZWliZWRkZWQ6ZXRoZXJuZXQ
The result must be an integral multi-
ple of 24 bits. When needed, add one
or two equal signs (=) to the end of the
string to lengthen it. This example
requires one equal sign.
Networking libraries for embedded
systems often include support for
basic authentication. An example is
Rabbit Semiconductor’s Dynamic C
language for its RabbitCore modules.
An HTTP library defines structures for
specifying a realm for web pages and
providing usernames and passwords to
gain access to a realm’s resources (see
Listing 1). For Java programmers, Shawn
Silverman’s Tynamo web server supports
basic authentication on Dallas Semi-
Listing 1—
Rabbit Semiconductor’s Dynamic C includes a library module that supports basic authentication
with structures that specify usernames and passwords for accessing a realm’s resources.
/*
An HttpRealm structure specifies the username and password
required to access resources in a realm. In this example, the
username is “embedded,” the password is “ethernet,” and the realm
is “Lakeview Research.”
*/
const HttpRealm myrealm[] =
{
{“embedded”, “ethernet”, “Lakeview Research”}
};
/*
An HttpSpec structure contains information about the files, vari-
ables, and structures the Web server can access.
On receiving a request for the file “index.html” or a request
with no file name specified (“/”), the Web server requests a user
name and password. On receiving a user name and password that
match those defined for the Lakeview Research realm, the server
serves the page.
*/
const HttpSpec http_flashspec[] = {
{ HTTPSPEC_FILE, “/”, index_html, NULL, 0, NULL, myrealm},
{ HTTPSPEC_FILE, “/index.html”, index_html, NULL, 0, NULL, myrealm}
};
68
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
conductor’s TINI modules and a vari-
ety of other Java-capable embedded sys-
tems (see Listing 2). Another option for
TINIs is Smart Software Consulting’s
open-source TiniHttpServer, which
also supports basic authentication.
An alternative to basic authentica-
tion is digest authentication, which is
more secure but more complex to
implement. To access a resource pro-
tected with digest authentication, the
client must provide a message digest,
which is a 32-character ASCII hex
string created from information pro-
vided by both the client and the server
hosting the resource. The information
that goes into creating the message
digest includes a nonce value that the
server returns in response to a request
for a protected resource, a username, a
password, a realm, and the request.
The default method for obtaining the
message-digest string is Message
Digest Algorithm #5 (MD5), which is
defined in RFC 1321.
The nonce value typically incorpo-
rates a time stamp and an ETag value
that identifies the resource being
requested. The time stamp enables the
server to allow access for a specified
time before requiring reauthentica-
tion. A server can use the ETag value
to prevent replay attacks, where an
unauthorized user requests an updated
version of a resource previously
returned to an authorized user.
The HTTP library for Dynamic C also
supports digest authentication. Some
older web browsers don’t support it.
Whatever form of password protec-
tion you use, be sure to limit access to
areas that store authorized usernames
and passwords. Otherwise, your attempt
at protection may be in vain. Also
remember that password protection only
limits who can request a resource. The
resource itself isn’t encrypted when
traveling on the network.
Change default passwords that allow
root or administrative access. Disable
guest accounts that have easily guessed
usernames that allow access to private
system resources.
You also may need to take precautions
to secure passwords and limit access to
small systems that use e-mail or FTP.
Usernames and passwords for accessing
e-mail and FTP servers often travel
unencrypted on the network and thus
are available to anyone spying on net-
work traffic.
A small system that receives e-mail
should have a username that spammers
aren’t likely to guess. Don’t use “info”
or “webmaster,” for example. And don’t
publish the e-mail address on a web
page where spammers can find it, or
your system may find itself spending
all of its time discarding received spam.
VALIDATING USER DATA
Another way a device’s resources can
be at risk is via received data such as
data submitted on an HTML form on a
web page. When a device enables you to
provide values to configure or control the
device, it’s a good idea to limit valid
inputs to a reasonable range. (This is true
whether or not the values travel on a
network.) For example, in a system that
controls heating and cooling, you might
want to allow inputs only between 50
and 72. Then if someone mistakenly
enters six instead of 60, the system can
return an error message instead of
attempting to implement the setting.
On an HTML form, input tags that
enable you to enter text should always
have a
maxlength attribute that limits
the number of characters a user can
enter. This line of HTML creates an
input box called “temperature.” It allows
you to enter up to three characters:
<input type= “text” name=”tem-
perature” maxlength=3>
Limiting the length helps ensure that
the received text doesn’t extend
beyond the memory reserved for the
value on the server.
Some web pages contain server side
include (SSI) directives, which ask the
server to perform an action before
serving a page. The directives use the
same delimiters as HTML comments
(
<!— and —>). Before serving a page
containing a directive, the server exe-
cutes the directive and replaces the
delimiters and everything between
them with the result of the directive.
A malicious user might enter an SSI
directive in a form field. If the server
returns a page that contains the entered
data, the server might attempt to exe-
cute the directive. A couple of the direc-
tives can have unwanted consequences.
The
#exec directive makes the server
execute program code. The
#include
directive requests the contents of a file
to be included in the requested resource.
If your server supports these direc-
tives but they aren’t needed by appli-
cations, it’s best to disable the directives
if possible. Another protection is to limit
which pages the server parses for SSI
Listing 2—
Shawn Silverman’s Tynamo web server and servlet engine support basic authentication for
resources served by Java servlets. A
getRealm()
method names the realm. An
isAuthorized()
method names a valid username and password for accessing the realm’s resources.
/**
* Returns the name of the realm. This method is required.
*
* @param request the HttpServletRequest object
*/
public String getRealm(HttpServletRequest request) {
return “Lakeview Research”;
}
/**
* Checks to see if the provided user name and password are
* authorized for the specified realm. This method is required.
*
* @param realm a requested resource’s realm
* @param username a received user name
* @param password a received password
*/
public boolean isAuthorized(String realm,
String username,
String password) {
return “Lakeview Research”.equals(realm) &&
“embedded”.equals(username) &&
“ethernet”.equals(password);
}
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
69
directives. Typically, pages that contain
SSI directives have the .shtml extension,
and the server ignores SSI directives on
other pages. In any case, to guard against
unauthorized execution of program code
or release of data, anything that should
remain private should be in an area
limited to authorized users.
ENCRYPTING PRIVATE DATA
Basic and digest authentication
enable you to encrypt usernames and
passwords. Some applications also need
to encrypt the data that travels on the
network. Encrypting and decrypting
large amounts of data can require more
resources than a small system can spare.
Two options suitable for small systems
are the encryption method described in
the advanced encryption standard (AES)
and firewall devices that support vir-
tual private networks (VPNs).
AES is the result of a 1997 search
launched by the U.S. National Institute
of Standards and Technology (NIST).
The goal was to find an encryption
method that was royalty-free, easy to
implement even on small embedded
systems, and able to withstand attack. In
2001, Federal Information Processing
Standard (FIPS) 197 announced the
Rijndael algorithm as the winner of the
search and dubbed the algorithm the
AES. The U.S. government uses AES
for sensitive but unclassified informa-
tion. Other entities are welcome to use
the algorithm as well.
AES defines a symmetric block cipher
that can encrypt blocks of 128 bits
using keys of 128, 192, and 256 bits.
(A cipher is symmetric if the keys for
encrypting and decrypting are the same
or easily obtained from each other.)
Dynamic C has an optional library
module that supports the AES cipher.
To implement authentication and
encryption without placing a burden on
the device firmware, you can use a fire-
wall device with support for a virtual
private network (VPN). The computers
in a VPN can be in the same local net-
work or anywhere on the Internet.
Desktop computers that communi-
cate with embedded systems can also
use VPNs. Windows XP includes an
IPSec security manager that enables
communicating over a VPN.
VPNs use IPSec protocols for
encryption and authentication. A vari-
ety of RFC documents cover the pro-
tocols. A good place to start is the
road map in RFC 2411.
A firewall device that supports
VPNs typically has a variety of config-
uration options. At the local network,
you can enable a single IP address, an
entire subnet, or a range of addresses
in a subnet to access the VPN. You
can specify that the local network will
accept VPN communications from a
specified IP address, domain name, or
any requesting host.
To use encryption, both ends of the
VPN must agree on the type of authen-
tication and encryption, and both must
share a key that enables each end to
encrypt and decrypt network traffic.
Encryption options include AES and
the older methods of data encryption
standard (DES) and triple DES (3DES).
Authentication options include the
128-bit MD5 and the more secure
160-bit secure hash algorithm (SHA).
When both ends have been config-
ured, the devices can communicate and
attempt to establish the VPN. When
the VPN has been established, the two
devices can transfer encrypted data.
Another encryption option is the secure
sockets layer (SSL) protocol, which is used
for encrypting data such as the credit card
numbers you send to on-line retailers. SSL
uses public-key cryptography, which
requires separate keys for encrypting and
decrypting. The computer requesting the
encrypted data generates a public key for
encrypting and a private key for decrypt-
ing. The sender uses the public key for
encrypting the data. Decrypting requires
the private key, which only the receiving
computer has access to.
SSL encryption is secure, but it
requires more resources than many
small embedded systems have available.
Netburner offers SSL support for its
MOD5282 development kit, which uses
Motorola’s 32-bit ColdFire processor.
PREVENT LOCAL SNOOPING
If preventing eavesdropping within a
local network is important to you, a
couple of additional steps can increase
security. An eavesdropper can monitor
signals in copper wire by tapping directly
into the cable or by coupling to the mag-
netic field induced by the current in the
wires. Neither of these methods works if
the network uses fiberoptic cable.
If your device communicates over a
wireless network, be sure to imple-
ment the recommended security prac-
tices for wireless networks. These
include changing the default adminis-
trative password, using encryption,
and, if possible, controlling which
Ethernet addresses can access the wire-
less network. For encryption, Wi-Fi pro-
tected access (WPA) is more secure than
wired equivalent privacy (WEP).
All in all, embedded systems have
plenty of options for keeping their
code and data secure. Taking time to
implement the appropriate security
measures for your devices can save
you time and trouble.
I
Jan Axelson, author of
Embedded
Ethernet and Internet Complete:
Designing and Programming Small
Devices for Networking, hosts a web
page dedicated to embedded network-
ing at www.lvr.com/ethernet.htm.
SOURCES
TINI modules
Dallas Semiconductor Corp.
www.dalsemi.com
BEFSX41 Firewall device
Linksys
www.linksys.com
MOD5282 Development kit
Netburner, Inc.
www.netburner.com
RabbitCore modules and Dynamic C
Rabbit Semiconductor
www.rabbitsemiconductor.com
Tynamo web server
Shawn Silverman
tynamo.qindesign.com
TinHttpServer
Smart Software Consulting
www.smartsc.com
PROJECT FILES
To download the code, go to ftp.circuit
cellar.com/pub/Circuit_Cellar/2004/172.
RESOURCE
70
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
manufacturers that not only integrate
USB in their hardware, but also pro-
vide some kind of software support
(i.e., support for those of you not will-
ing to spend the next year scratching
your heads over developing the neces-
sary Windows driver for a specific
project).
Beyond the 8051 hardware Silicon
Laboratories offers is the free
USBXpress development kit for this
purpose. The kit includes Windows
Y
ou may never need to connect
your widget to a PC. If you do, your
serial or parallel connection surely
will be adequate. When you look
around your lab, you most likely see
plenty of computers that have the
DE-9/DB-25 connectors. However,
next time a new PC arrives, notice
what types of connections are provid-
ed. After these familiar connectors
have disappeared, you might find your-
self scrambling to learn more about
how to design with USB. Because
I believe this is important, I will
continue to present USB projects
based on different manufacturers’
parts. Almost every major manu-
facturer supports USB somewhere
in its lineup.
FINDING SILABS
Cygnal Integrated Products is
known for designing, manufactur-
ing, and marketing advanced in-
system-programmable, mixed-sig-
nal System-on-a-Chip (SoC) prod-
ucts. In December 2003, Silicon
Laboratories—a leading designer
of high-performance, analog-
intensive, mixed-signal integrated
circuits—acquired Cygnal. Hence,
a visit to the Cygnal web site
becomes a visit to www.silabs.com/
products/microcontroller. Why
visit Cygnal? It offers an 8051
microcontroller with a USB inter-
face. I came across this product in
one of the industry magazines I
receive. In my quest for more
practical knowledge about USB, I
try to fully investigate those
device drivers, INF driver installation
files, a host interface function library
(host API) provided in the form of a
Windows dynamic link library (DLL),
and a device firmware interface func-
tion library (device API). Note that on
the microcontroller side, the Keil 8051
toolchain is required to use the device
firmware library, but a code-limited
compiler comes with the C8051F320DK
development kit ($229). This is suffi-
cient for many small projects. The
REGIN
5 V
Voltage
regulator
In
Out
Enable
Analog/digital
power
GND
/RST/
C2CK
C2D
Debug HW
RESET
POR Brown-Out
16-KB
Flash memory
256-byte
SRAM
1-KB
XRAM
SFR Bus
External
oscillator
circuit
XTAL1 XTAL2
12-MHz
Internal
oscillator
Clock
recovery
System
clock
×4
÷2
÷2
÷1,2,3,4
USB
Transceiver
USB
Controller
1-KB USB
SRAM
D+
5V
D–
5V
V
BUS
Port 0
latch
Port 1
latch
UART
Timer
0,1,2,3/
RTC
PCA/
WDT
SMBus
SPI
Port 2
latch
Port 3
latch
V
REF
V
REF
V
DD
10-bit
200-ksps
ADC
MUX
+
+
–
–
CP0
CP1
Temperature
V
DD
V
REF
AIN0-AIN16
P0.0
P0.1
P0.2/XTAL1
P0.3/XTAL2
P0.4
P0.5
P0.6/CNVSTR
P0.7/V
REF
P1.0
P1.1
P1.2
P1.3
P1.4
P1.5
P1.6
P1.7
P2.0
P2.1
P2.2
P2.3
P2.4
P2.5
P2.6
P2.7
P3.0/C2D
V
DD
USB
Clock
8051 Core
Crossbar
P0 Dr
v
P1 Dr
v
P2 Dr
v
P3 Dr
v
Figure 1—
Mixed-signal peripherals, a USB front-end, and flash memory added to an 8051 core provide you with a com-
plete single-chip solution for those applications that may require a PC interface.
USB DMX
FROM THE BENCH by Jeff
Bachiochi
Several months ago, Jeff interfaced a DMX receiver to a water fountain system. He used a
commercial serial DMX converter for that project. This month, he describes how he updat-
ed the device with a C8051F320-based USB interface.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
71
development kit includes an
IDE, target PCB, and JTAG
debugger.
OUT WITH SERIAL DMX
Last year I wrote about a
DMX receiver project that I
interfaced to a tabletop water
fountain display (“Tabletop
DMX Control,” issue 161,
December 2003). DMX is a dig-
ital control signal protocol that
was first used in the entertain-
ment lighting industry. A con-
troller application (usually run-
ning on a PC) is used to control
up to 512 variable or switched
devices all connected to one
bus. Some applications schedule cho-
reography for synchronized playback.
The PC application doesn’t speak
DMX but can update device levels in
an externally connected DMX con-
verter through the serial, parallel, or
(now) a USB port. The converter is
responsible for sending a DMX stream
of data via an RS-485 bus to all
DMX connected receivers. At
the time I was using a commer-
cially available serial DMX
converter for the project. Now
it’s time to update that device
with a USB interface based on
the C8051F320 microcontroller.
IN WITH USB DMX
Packing a USB interface
along with an 8051 into a 32-pin
LQFP means something has got
to give. A standard 8051’s
quad-8-bit ports are reduced to
three on the ’F320. Refer to
Figure 1 to see how even a 10-bit
A/D converter is included in
this mixed-signal flash memory MCU.
Although the CIP-51 core is fully
compatible with the MCS-51 instruc-
tion set, it executes up to 12 times
faster using the same clock
speed. Its internal 12-MHz oscil-
lator removes the need for an
external crystal and can be
increased four times by an internal
PLL. The 48-MHz clock is neces-
sary for the USB clock recovery
scheme. It is divided by two for a
24-MHz system clock allowing
the core maximum performance.
Programming and debugging
support are also part of the ’F320.
The two-wire development inter-
face used on the ’F320 is a JTAG-
style interface with internal
debug logic that supports the
inspection and modification of
memory, registers, setting break-
points, single stepping, and run
and halt commands. This nonin-
trusive hardware ensures that all
analog and digital peripherals are
fully functional while debugging.
This simple interface in conjunc-
tion with the IDE handles pro-
gramming the device as well as
interactive debugging.
Photo 1 shows the prototype
PCB holding the additional com-
ponents necessary to prototype
the schematic shown in Figure 2
(minus the optional DMX-IN).
The target PCB has a few push
buttons, LEDs, a potentiometer,
and additional A/D inputs. These
are worked into a sample applica-
Photo 1—
I’ve prototyped the necessary DMX interface hardware to Silicon
Laboratories’s C8051F320 development board. This allows the project’s
DMX controller to interface to a PC via USB.
Figure 2—
The schematic has plenty of configuration inputs and LED indicators making this platform a good one for
experimenting with DMX. An optional DMX input channel is shown when the board is used as a DMX receiver (or in antici-
pation of the new DMX input protocol). And there is still plenty of I/O left.
72
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
tion you can run out of the box
with the target board and a PC.
The device software is written
in C. The host software applica-
tion is provided in three envi-
ronments: Visual Basic, C, and
Visual Basic .NET. However,
without the provided USB driv-
er, .DLL, and .API, no data
would move between the PC
and the target device.
When a properly programmed
device is plugged into the USB
bus, the system tries to locate
the proper windows driver.
After it’s loaded, the USB
device can enumerate in prepa-
ration of data transfers.
On the host side, an API pro-
vides function calls to enable
the application to converse
with the USB windows driver. On
the device side, a second API lets
the device application communicate
with the USB interface within the
microcontroller.
I chose to use Visual Basic on the
PC side. On the device side, a simple
blinking LED application is given in
assembly to test the target board. But,
when it comes to making a USB con-
nection, only C is demonstrated. Most
of you know how I feel about C. So,
bear with me here, because I’m forced
to attempt to use it in this project.
USB CONTROLLER
USB transceiver hardware, USB
FIFO RAM, and a USB serial interface
engine (SIE) have been added to the
CIP-51 core to give this microcon-
troller full- and low-speed access to a
system’s USB. Two special function
registers in the CIP-51 core handle all
communication between the micro-
controller and the USB controller,
USBADDR, and USBDATA (see
Figure 3). The USBADDR register
is used to point to one of the con-
troller registers within the SIE.
The USBDATA register can be
used to place or retrieve data to
that referenced location.
The control registers can be
divided into three groups: com-
mon, interrupt, and indexed reg-
isters (see Table 1). In the com-
mon group, the CLKREC register
allows you to set the USB speed
as either low or full. FADDR
holds the current address for the
device (zero before enumeration).
POWER enables and disables
device-level functions. FRAMEL
and FRAMEH reflect the last
received frame number. Four
FIFO registers, one for each endpoint
(0–3), access the EPxIN (EndPoint#IN)
and EPxOUT FIFO buffers. Reading
one of these registers removes a byte
from the EPxOUT FIFO, while writing
to one of these registers places data
into the EpxIN FIFO. The last com-
mon register is the INDEX register.
The value in this register (0–3) indi-
cates which set of indexed registers
will be accessed. Each EP has its own
set of index registers consisting of six
EP control and status registers.
The six index registers are actually
three pairs of low- and high-byte reg-
isters: EINCSRL/EINCSRH
(EndpointINControlStatusRegisters),
EOUTCSRL/EOUTCSRH
(EndpointOUTControlStatusRegisters),
and EOUTCNTL/EOUTCNTH
(EndpointOUTCouNTRegisters).
Actually, EP0 has both its in and out
control registers combined into the
first set. These registers are used in
support of all EP transactions.
Finally, the six interrupt registers are
grouped as three interrupt-enable and
three interrupt-flag registers. These reg-
isters need to be checked when the core
USB0 interrupt routine is invoked to
determine the source of the USB inter-
rupt. The CMINT and CMIE interrupt
registers indicate SOF (start of frame),
RSTINT (ReSeTpendingINTerrupt),
RSUINT (ReSUmependingINTerrupt),
and SUSINT (SUSpendpending-
INTerrupt). IN1INT and IN1IE (in
Table 1—
All USB control registers are accessed via the core’s USBADDR and USBDATA registers. USBADDR is a
pointer to a USB register address. USBDATA is used to write to or read from that USB register address.
8051
SFRs
USB0DAT
USB0ADR
Interrupt
register
FIFO
Access
Common
registers
Index
registers
Endpoint 0 control/
status register
Endpoint 1 control/
status registers
Endpoint 2 control/
status registers
Endpoint 3 control/
status registers
USB Controller
Figure 3—
The USB serial interface engine handles all of the low-level
USB functions on its own and interfaces to the 8051 core via two regis-
ters. The four endpoint FIFOs also pass data through USBDATA when
USBADDR is loaded with one of their addresses.
Name
USB register address
Description
Interrupt registers
IN1INT
0x02
Endpoint 0 and endpoints 1–3 IN interrupt flags
OUT1INT
0x04
Endpoints 1–3 OUT interrupt flags
CMINT
0x06
Common USB interrupt flags
IN1IE
0x07
Endpoint 0 and endpoints 1–3 IN interrupt enables
OUT1IE
0x09
Endpoints 1–3 OUT interrupt enables
CMIE
0x0B
Common USB interrupt enables
Common registers
FADDR
0x00
Function address
POWER
0x01
Power management
FRAMEL
0x0C
Frame number low byte
FRAMEH
0x0D
Frame number high byte
INDEX
0x0E
Endpoint index selection
CLKREC
0x0F
Clock recovery control
FIFOn
0x20–0x23
Endpoints 0–3 FIFOs
Indexed registers
E0CSR
0x11
Endpoint 0 control/status
EINCSRL
Endpoint IN control/status low byte
EINCSRH
0x12
Endpoint IN control/status high byte
EOUTCSRL
0x14
Endpoint OUT control/status low byte
EOUTCSRH
0x15
Endpoint OUT control/status high byte
E0CNT
0x16
Number of received bytes in endpoint 0 FIFO
EOUTCNTL
Endpoint OUT packet count low byte
EOUTCNTH
0x17
Endpoint OUT packet count high byte
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
75
registers) and OUT1INT and OUT1IE
(out registers) reflect EP0-3 activity.
Any USB-enabled interrupt will trig-
ger the core’s USB0 interrupt (8) and
jump to its vectored address. The USB
interrupt service routine would nor-
mally handle these interrupts with
the appropriate low-level routines.
The USBXpress kit for the C8051F320
includes an application-programming
interface (API) that provides a high-
level interface for easy USB connec-
tivity.
As you can see in Table 2, the API
library gives you a set of high-level
device interface functions: USB_Init(),
Block_Write(), Block_Read(),
Get_Interrupt_Source(), USB_Int_Enable(),
USB_Int_Disable(), USB_Disable(), and
USB_Enable(). Besides handling the low-
level nitty-gritty, the API redirects the
core USB0 interrupt vector to interrupt
(16). Use this vector to point to a rou-
tine that calls the
Get_Int_Source()
routine. This routine returns nine pos-
sibilities: USB_RESET, TX_COMPLETE,
RX_COMPLETE, FIFO_PURGE,
DEVICE_OPEN, DEVICE_CLOSED,
DEV_CONFIGURED, and
DEVICE_SUSPEND (see Table 3). You
can choose to ignore or carry out
some activity based on the return.
’F320 APPLICATION
Assuming the USB connection is
made, there would be some applica-
tion on the CIP-51 core to make use
of it. This project’s application is to
provide DMX communication to
512 DMX slave ports. A DMX trans-
mission consists of a break (extended
start bit, minimum of 88 µs) fol-
lowed by a make (extended stop bit,
minimum of 8 µs) and then asyn-
chronous data at a rate of 250 kbps
(see Photo 2a). The data is 513 bytes
beginning with the 0 value, followed
by the values of DMX channels 0
through 511.
I cheated when developing this
application in C language. I wrote and
debugged the serial routines in assem-
bler to get things going. Then, I rewrote
them in C by incorporating the USB
API following the format used in the
demonstration program. This way I had
some faith that what I was trying to
accomplish in C language didn’t have
a stupid logic flaw. I had enough trouble
just getting the C language formatted
correctly. I have to admit there is
some bit-manipulating code that I had
to rewrite inefficiently just because I
couldn’t get it to work in a reasonable
amount of time (see Figure 4).
Starting a new project in any lan-
guage usually requires a good deal of
time going over a microcontroller’s
registers to determine the proper initial-
ized state of each according to the appli-
cation usage. Silicon Laboratories’s IDE
has a tool to help set these correctly.
The configuration wizard creates source
code in either assembler or C language
to reflect the choices you make (or don’t
make) for each function within the
microcontroller. Out of the seven
pages of C source code for this project,
the configuration wizard created five.
Of the eight functions within the
device API, I’ve used most of them:
USB_Init(), USB_Int_Enable(),
Get_Interrupt_Source(),
USB_Suspend(), and Block_Read(). This
application doesn’t send data. Nor
does it shut down functions during a
suspend. The API allows blocks of up
Table 2—
These high-level functions are available to the device through the USBXpress API. The API reduces the
amount of code you need to write for USB support.
API’s device interface functions
Description
USB_Init()
Enables the USB interface
Block_Write()
Writes a buffer of data to the host via the USB
Block_Read()
Reads a buffer of data from the host via the USB
Get_Interrupt_Source()
Indicates the reason for an API interrupt
USB_Int_Enable()
Enables the API interrupts
USB_Int_Disable()
Disables API interrupts
USB_Disable()
Disables the USB interface
USB_Suspend()
Suspends the USB interrupts
Table 3—
These values are returned by the
Get_Interrupt_Source()
function to determine the actual
source of the USB interrupt (if any).
Get_Interrupt_Source returned value
Description
0x00
No USB API interrupts have occurred
0x01
USB_RESET USB reset interrupt has occurred
0x02
TX_COMPLETE transmit complete interrupt has occurred
0x04
RX_COMPLETE receive complete interrupt has occurred
0x08
FIFO_PURGE command received (and serviced) from the host
to purge the SB buffers
0x10
DEVICE_OPEN device instance opened on host side
0x20
DEVICE_CLOSE device instance closed on host side
0x40
DEV_CONFIGURED device has entered configured state
0x80
DEV_SUSPEND USB suspend signaling present on bus
Photo 2a—
Here you see nine 64-byte blocks being moved from the FIFO into the ’F320’s XRAM. Although each
USB transfer requires only a small fraction of a 1-ms timeframe. Each 60-byte block requires 3.3 ms to move.
b—
The UART’s output shows a 90-µs break code (a 0x00 sent at 100 kpbs) followed by a start code (a 0x00 sent
at 250 kpbs) and then up to 512-bytes of DMX data (DMX buffer sent at 250 kpbs). The PC application’s sliders
have updated the DMX buffer via the established USB link.
a)
b)
76
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
to 64 data bytes (the maxi-
mum packet size for a high-
speed interrupt transfer pack-
et) to be transferred. Because
this application requires
512 bytes of data (represent-
ing DMX channels 0–511),
you need some way to deter-
mine which 64 bytes of the
512 are being received. The
simplest approach is to
include an address for the
data. Two bytes are necessary
to do this, so the first 2 bytes
of any packet hold the address
of the data in the third byte,
with the address incremented
for each of the next 61 bytes.
Because 62 bytes don’t divide
evenly into the 512 buffer
size, some overlap occurs.
The
Block_Read() func-
tion simply moves data from
the USB FIFO to a 64-byte
buffer you assign to it (see
Photo 2b).
Following the return of this
function, the data in my 64-byte
buffer can be evaluated and
moved to its proper place in
the 512-byte DMX buffer
using my
UnloadDMXBuf()
function. The UART continu-
ally sends DMX communica-
tions to the DMX bus as a sep-
arate interrupt task always
getting the latest data from
the 512-byte DMX buffer.
PC APPLICATION
After the project device is
programmed, it can be
plugged into the USB port on
your PC. The PC should respond with
a “Found New Device” message and
allow you the install the USBXpress
driver (SiF32x.sys and SiLIB.sys) using
the SiF32x_USB.inf file. When the PC
has finished with the driver installa-
tion, any application can use the USB
connection.
Your application might be a lighting
console for stage performance, a foun-
tain controller, or any device requiring
an analog control value. To test this
project’s device hung on the USB, I
designed a simple application with
eight sliders (see Photo 3). Each slider
can be configured as a specific DMX
channel number 0–511. Each slider’s
8-bit value can be sent to update its
corresponding DMX array value indi-
vidually or all eight at once. A period-
ic timer is used to transmit the 512-
byte DMX array to the DLL, the USB
driver, and on to the USB bus, finally
ending up in the attached USB device.
The application written in Visual
Basic begins by opening the DLL (sup-
plied by Silicon Laboratories). The DLL
provides the host with 12 API functions
(similar to the ones used to communi-
cate with the USB hardware on the exter-
nal device). Refer to Table 4
for more information.
The first function,
F32x_GetNumDevices(),
returns the number of ’F32x
USB devices connected to
the system’s USB. Each of
these devices can be further
identified by the
F32x_
GetProductString()
function. The product string
and the serial number string
can be defined and will
default to those defined
within the device API. If
more than one device is
found, you must choose one
and then open communica-
tion with it using the
F32x_Open() function. The
application is now free to
start sending and receiving
data.
As I stated earlier, this
application will only trans-
fer data to the USB device,
so the
F32x_Read() func-
tion isn’t used. Because I’ve
established the communica-
tion protocol as 64-byte
blocks (which happens to be
the data limit within each
USB packet), it doesn’t make
sense to create a single 576-
byte
F32x_Write() (even
though low-level USB func-
tions can handle breaking
the block down at the
transmission end and mak-
ing sure it gathers at the
receiving end without los-
ing any data). Instead, it’s
easier to send the DMX
channel data as 64-byte blocks creat-
ed on the fly. In fact, my application’s
function,
WriteUSBOutBuf2USB,
moves the data from the 512-byte
DMX channel array (DMXOutBuf)
into the 64-byte block buffer (
IOBuf)
of the
F32x_Write() function nine
times. Each time, the block buffer is
loaded with the most significant byte
and the least significant byte of the
DMXOutBufPtr and 62 data bytes
(starting with the data pointed to by
DMXOutBufPtr).
There is little code in the applica-
tion that doesn’t have to do with the
Initialization
USB_Init()
USB_Int_Enable()
wait
UART0 ISR
(TX_Empty)
Clear interrupt
Flag = 0 ?
Data rate = 100 kHz
SBUF0 = 0×00
FLAG = 1
Flag = 1 ?
Data rate = 250 kHz
SBUF0 = 0×00
FLAG = 2
Ptr = 0
SBUF0 = DMXBuf(Ptr)
Ptr = Ptr + 1
Ptr = 512 ?
Flag = 0
Return from
interrupt
USB0 ISR
Get_Interrupt_Source()
RX_COMPLETE ?
Block_read(USBOutBuf,0×40)
Ptr = USBOutBuf(0) × 256 + USBOutBuf(1)
BufCtr = 0
BufCtr = 0×40 ?
Ptr = 0×200 ?
Ptr = 0
DMXBuf(Ptr) =
DMXBufOut(BufCtr)
Ptr = Ptr + 1
BufCtr = BufCtr + 1
Return from
interrupt
Figure 4—
The device application requires only two interrupt routines after some
initialization. The USBXpress API lets you obtain USB connectivity without any
low-level concerns.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
77
USB communication. The remaining
code gives you a simple interface for
setting DMX channel values with the
DXMOutBuf array. A slider is defined
as having minimum and maximum
values (0–255). The PC screen would
become congested with 512 sliders all
vying for a place in the application
window. Eight sliders are used to sim-
plify the interface. However, each slid-
er can be associated with any DMX
channel.
Any eight channels can be defined
at once; in fact, all eight could be
defined for the same channel. Each
slider also has a Send button associat-
ed with it. When the Send button is
pushed, the slider will update its
DMXOutBuf array channel with the
value of the slider. By setting all slid-
ers to the same channel, adjusting the
sliders to particular levels, and hitting
the Send buttons, you can alter a sin-
gle DMX channel’s output value
instantaneously to any of those eight
particular settings. On the other hand,
with each slider set to different DMX
channels, you can update those chan-
nels individually with their Send
buttons, or all at once with the Send
All 8 button.
MESSAGE RECEIVED
It looks like manufacturers have
gotten the message: if you want your
parts used in new designs, provide good
documentation and tools.
Silicon Laboratories has made a good
strategic play by acquiring Cygnal.
This product places them at the fore-
front of those supporting USB as a
micro peripheral. The USB interface is
clean and easy to use thanks to the
USBXpress. The IDE is complete with
programming and debugging capabili-
ties. Who knows, I might even learn C
one day!
I
Jeff Bachiochi (pronounced BAH-key-
AH-key) has been writing for
Circuit
Cellar since 1988. His background
includes product design and manufac-
turing. He may be reached at
jeff.bachiochi@circuitcellar.com.
SOURCE
C8051F320 USB mixed-signal MCU
Silicon Laboratories, Inc.
www.silabs.com
PROJECT FILES
To download the code, go to ftp.circuit
cellar.com/pub/Circuit_Cellar/2004/172.
Photo 3—
This Visual Basic application gives you
access to the DMX project via a USB connection. Any
of the 512 DMX channels may be updated with an 8-bit
value selected via the application’s slider controls. Each
slider can be assigned to any DMX channel using the
Channel buttons. Data can be sent on an individual
channel basis using the Send buttons or all together
using the Send All 8 button.
Table 4—
The host’s application communicates with the Windows USB driver through these 12 functions via a second API.
API’s host interface functions
Description
F32x_GetNumDevices()
Returns the number of ’F32
x USB devices connected
F32x_GetProductString()
Returns a descriptor for each ’F32
x USB device
F32x_Open()
Opens an ’F32
x USB device and returns a handle
F32x_Close()
Cancels pending I/O and closes a ’F32
x device
F32x_Read()
Reads a block of data from an ’F32
x USB device
F32x_Write()
Writes a block of data to an ’F32
x USB device
F32x_FlushBuffers()
Flushes the TX and RX buffers for a device
F32x_SetTimeouts()
Sets read and write block timeouts
F32x_GetTimeouts ()
Gets read and write block timeouts
F32x_ResetDevice()
Resets an ’F32
x USB device
F32x_CheckRXQueue()
Returns the number of bytes in a device’s RX queue
F32x_DeviceIOControl()
Interface for miscellaneous device control functions
78
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
After all, there is the overall trend
toward high-level languages (e.g., C),
which are at least semi-impervious to
underlying architectural changes.
More importantly, despite arguable
interest in the concept so far, there
just isn’t a huge installed base of Nios
(or any other soft core) assembly lan-
guage programs and ROM codes to
worry about. There’s no denying Altera
is switching horses, but at least they’re
doing it before getting midstream.
As I was studying the Nios II docu-
mentation, I was struck by a feeling of
déjà vu. Sure enough, Nios II is a classic
implementation of a 32-bit RISC, much
as described in Computer Architecture:
A Quantitative Approach
, the seminal
work of RISC pioneers John Hennessy
and David Patterson. Notably, there are
many striking similarities (e.g., the
32 32-bit semi-general-purpose register
files, three-operand instruction format,
and simple-minded interrupt scheme)
with early-’80s RISC processors such
as the MIPS R3000 (see Figure 1).
L
ast month I covered the new line-
up of FPGAs from Altera: MAX II,
Cyclone II, and Stratix II. As with
each wave before, higher density,
speed, pin count, and lower price per
gate are all factors that position
FPGAs for migration into ever-more
mainstream designs. But as the old-
timers say, “You can lead a chip to
solder, but that don’t make it think.”
Look at it this way: Moore’s law’s
days may be numbered, but for now
the march of silicon continues apace.
That means system designs continue
to get sucked into fewer and fewer
chips. Meanwhile, virtually every
electronic gadget has a microprocessor
or microcontroller. QED, FPGAs must
ultimately incorporate micros in order
to penetrate the unwashed masses of
blue-collar applications.
The potential payoff is huge. For
example, Altera rightfully brags that
Cyclone run rates now approach
500,000 units per month.
[1]
Yes, that
may be a lot when it comes to FPGAs,
but the fact is that 500,000 embedded
micros get shipped each and every
hour 365 days a year!
CHIPS OF FUTURE PASSED
Enter the Nios II, Altera’s new entry
in the CPU-on-board fray. As you’ll
see, it’s a completely different CPU
architecture than the company’s origi-
nal Nios design.
Normally, such a radical change
would inspire much hand wringing.
But as a practical matter, in this case
the switch to a new architecture just
doesn’t seem like such a big deal.
Although a full-blown 32-bit proces-
sor, in comparison to today’s trinket-
laden RISC architectures, the Nios II is
lean and mean. Bloatier features (such
as superscalar multi-instruction-per-
clock capability) are left for the big-
ticket CPUs in favor of an architecture
that will actually fit in an FPGA with
room left to do something useful.
With 32-bit, fixed-length instruc-
tions, code density can be a concern.
Yes, external flash memory and
DRAM chips are incredibly cheap, but
not so for on-FPGA memory. Thus,
Nios II eschews the delay slot scheme
found on the early pedagogical RISCs.
With delay slots, the idea is to rely
on the compiler to move instructions
into cycles that would otherwise stall,
such as those after a taken branch or
between load and use of a register.
That sounds good in principle. But in
practice, there are many times that a
useful instruction can’t be found to
fill the delay slot, so code-bloating
NOPs have to be added.
Hardware
assisted
debug module
Program
controller
and
address
generation
Exception
controller
Interrupt
controller
General-
purpose
registers
r0 to r31
Control registers
ct10 to ct14
Instruction
cache
Arithmetic
logic unit
Data
cache
Custom
instruction
logic
Nios II processor core
RESET
CLOCK
JTAG
interface to
software
debugger
irq[31..0]
Custom
I/O signals
Instruction
master port
Data
master port
Figure 1—
The Nios II embodies a classic RISC with fixed-length instructions, pipelining and cache, and little else.
Easy to Be Soft
SILICON UPDATE
by Tom Cantrell
Although FPGA-based processors won’t ever completely replace dedicated processor chips,
the FPGA soft-core option is becoming increasingly attractive to designers. In this column,
Tom examines the soft core concept by focusing on Altera’s new chips and the Nios II core.
www.circuitcellar.com
Issue 172 November 2004
79
C
IRCUIT CELLAR
®
By ditching delay slots, the Nios II
trades off a bit of performance in favor
of improved code density—a fair trade-off
as far as I’m concerned. It also makes
debugging easier for mere mortals,
because instructions don’t
get moved around and pro-
gram flow is easier to trace.
Some might complain
about the exception scheme,
or rather the lack of same (see
Figure 2). In response to an
interrupt, the Nios II simply
sets a bit in a register that
identifies the interrupt source,
stores the PC and PSW in a
one-level stack, and vectors to
a single global exception han-
dler. The global exception
handler must determine the
cause and transfer to the
appropriate routine.
Although that’s simple and
fast, critics might say it’s
another case of keep-it-sim-
ple gone overboard because
software has to handle real-
world embellishments such
as priority, nested interrupts,
reentrancy, etc. But don’t for-
get this is an FPGA after
all. If you want a fancy
interrupt controller with
all the trimmings, just
design your own!
HAVE IT YOUR WAY
In contrast to dedicated
processor chips, there’s
little more to say about
the Nios II architecture
per se. That’s because
so many implementa-
tion-specific features
and attributes that
would be hardwired in a
dedicated chip are soft
in the Nios II.
Programmability
starts at an extremely
low level with the basics
of the pipeline itself.
Three implementations
of the Nios II are defined:
the so-called “e” (econo-
my), “s” (standard), and
“f” (fast), which incorpo-
rate zero-, five-, and six-
stage pipelines respectively. Other dif-
ferences between the three versions
include cache (none, instruction, and
instruction and data) and branch pre-
diction (none, static, and dynamic).
As for the instruction set, the archi-
tecture itself supports MUL and DIV
instructions, but a specific implemen-
tation may not actually include the
arithmetic hardware, either by choice
(to save silicon) or necessity (the hard-
ware option is only available in parts
with DSP blocks like Stratix, Stratix II,
and Cyclone II). In that case, the MUL
and DIV instructions generate an excep-
tion and are emulated in software.
Similarly, the architecture defines
multi-bit shift instructions. On a Nios II
implementation with barrel shifter hard-
ware, a multi-bit shift executes in a sin-
gle clock, but a clock per bit otherwise.
For Nios II versions that support cache
(i.e., I-cache for the “s” and I- and D-
cache for the “f”), you’re free to choose
the size of each (up to 64 KB). But even
cached systems need a way to force
uncached access for I/O. The Nios II
accommodates with special I/O load
and store instructions (LDIO, STIO) that
bypass the data cache. Furthermore, the
address space is split in half with
accesses to the upper portion (address
bit 31 high) performed as uncached.
Although the cache size is program-
mable, I was surprised at the inflexible
spec for the cache organization—direct-
mapped with fixed line size (eight
words for instruction and one word for
data) period. But now I’m
thinking the possible gains
from a custom cache strategy
probably wouldn’t justify the
extra implementation com-
plexity, not to mention the
impact on software portabili-
ty (i.e., cache management).
As it is, programs can be eas-
ily written to run correctly
on any Nios II no matter the
size (or absence) of caches.
Custom instructions may
represent the ultimate when
it comes to delivering on the
soft core promise. In earlier
incarnations, the interaction
between the soft-core CPU
and on-chip custom logic
might have been limited to
a rather loosely coupled
arrangement requiring soft-
ware overhead to coordinate
activity. Of course, the Nios II
has that option as well, but it
ienable Register
31
0
IENABLE2
IENABLE1
IENABLE0
irq3
irq2
irq1
irq0
…
ipending Register
31
0
IPENDING3
IPENDING2
IPENDING1
IPENDING0
…
PIE bit
Generate
hardware
interrupt
External hardware
interrupt request
input irq[31..0]
…
Figure 2—
Reflecting the keep-it-simple concept, the Nios II exception pro-
cessing scheme is little more than a big OR gate. If you want more, have it
your way in software, hardware, or both.
Photo 1—
The Nios II comes with architectural and toolchain hooks that support the
creation of custom instructions. In this case, the software inner loop of a leading-zero
search was replaced with an HDL
Case
statement for a significant speed-up.
80
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
goes further by allowing custom logic to
cozy right up to the pipeline, registers,
and ALU. Although not something
everyone needs, adding custom instruc-
tions to the heart of the CPU is a power-
ful capability, one that could prove piv-
otal in certain applications (see Photo 1).
TOOL CHAINED
The bits and bytes of the Nios II
architecture and implementation are
important to be sure. But although a
good processor design is necessary, it
isn’t sufficient to further the cause of
the soft core concept.
Soft cores have been around for a
decade or more, but two problems
have held them in check.
[2]
First, the
required silicon historically has been
pricey, a situation exacerbated by the
programmable logic suppliers’ high-
end ASIC replacement marketing
strategy and patent-enforced barriers
to entry for would-be competitors.
Prospects are good, and destined to
get even better, regarding the price.
FPGA suppliers are realizing there’s
more to life than $1,000 chips, so now
they’re getting aggressive with parts
under $10. Furthermore, the barriers
to entry are invariably eroding as
patents expire and historic licenses are
acquired or otherwise dusted off and
brought out of the closet. Even as
Altera focuses on taking the lead from
Xilinx, both of them had better keep an
eye on competitors like Actel (flash
memory FPGAs) and
Cypress (PSoC).
Ultimately, Moore’s law
will work its magic to
bring soft-core silicon cost
down even further. When
it comes to the Price is
Right challenge, thanks to
the march of silicon, the
answer is not a matter of
if, but rather when.
The second challenge is
tools, which now must
handle entire system
designs from top to bot-
tom. Links in the toolchain
include the base FPGA
design suites, the entire
collection of software
development tools for the
processor, libraries of use-
ful predefined hardware and software
functions, and system debug and inte-
gration utilities that pull it all togeth-
er. That’s a lot of tools, and a lot of
opportunities to get it right—or
wrong.
In particular, the software develop-
ment tools for soft-core processors
have never fully matched their stand-
alone CPU counterparts. In the old days
you were lucky to get a hacked assem-
bler. It’s only relatively recently that
you could even get a C compiler.
[3]
In
any case, no soft core had the fancy
GUIs, IDEs, and debuggers that soft-
ware developers have come to expect.
With ever better chips and the new
Nios II soft-core CPU, Altera is tack-
ling the challenges of cost and tools
head-on. Let’s kick the tires and I
think you’ll see what I mean.
BUT FIRST…
From a marketing perspective, the
success of the soft-core concept
depends on getting legions of design-
ers to board the FPGA bandwagon. I’m
talking 10 to 100 times the traditional
FPGA designer base, with the majori-
ty of them newbies having little or no
experience with FPGAs.
In this light, the good news is that
FPGAs are more accessible than ever.
But that doesn’t mean making the
leap isn’t scary. Getting up to speed
with FPGAs isn’t a casual exercise,
and the time, expense, and head
scratching are nontrivial. Here are a
few tips to keep in mind, especially
for first-timers. When it comes to
hosting FPGA and soft-core tool-
chains, the PC catchphrase is “Go big
or go home.” If your box isn’t the lat-
est and greatest, chances are you
won’t even be able to install the soft-
Photo 2—
The Cyclone-based Nios II evaluation board comes fully
loaded with memory and I/O add-ons. Even the LCD and flash memory
card are included. The kit also bundles all the software you need to get
started (Quartus II, SOPC Builder, and the GNU-based software tool-
chain), as well as the new and improved USB Blaster download cable.
Photo 3—
Say bye-bye to the simple serial/parallel port command line monitors of yore. The Nios II evaluation
board matches traditional hard core MCU competitors in all respects, including a built-in Ethernet web server.
Schematic and PCB Layout
• Powerful and flexible schematic capture.
• Auto-component placement.
• Rip/entry PCB routing.
• Polygonal gridless ground planes.
• Library of over 8000 schematic and 1000 PCB foot prints.
• Bill of materials, DRC reports and more.
Mixed Mode SPICE Circuit Simulation
• Berkeley SPICE3F5 simulator with custom extensions for
true mixed mode and interactive simulation.
• Six virtual instruments and 14 graph based analysis types.
• 6,000 models including TTL, CMOS and PLD digital parts.
• Fully compatible with manufacturers’ SPICE models.
Proteus VSM - Co-simulation and debugging for
popular Micro-Controllers
• Supports PIC16 & PIC12, AVR, 8051, HC11 and ARM micro-
controllers.
• Co-simulate target firmware with your hardware design.
• Includes interactive peripheral models for LED and LCD
displays, switches, keypads, virtual terminal and much,
much more.
• Provides source level debugging for popular compilers
and assemblers from HiTech PICC, Crownhill, IAR, Keil
and others.
R4
EASY TO USE CAD TOOLS AT FANTASTIC PRICES
MicroChip PIC 18
• Supported models of the PIC 18 includes PIC18F242,
PIC18F252, PIC18F442, PIC18F452, PIC18F248, PIC18F258,
PIC18F448 and PIC18F458.
Basic Stamp BS1 and BS2
• Proteus VSM for BASIC Stamp contains everything you
need to develop and simulate designs based around the
BASIC Stamp.
• See examples in downloadable Demo at
www.labcenter-electronics.com
“I finished my first design, schematic and PCB in one day.”
“What a great tool! I love it.”
DAN GILL
“For the cost of the software compared to the productivity gains,
I consider Proteus to be pivotal in the commercial viability
of my company and by far represents the best value for money
of anything Tempus possesses.”
ROB YOUNGS, Tempus Consulting
“PROTEUS stands out as the best all-round program in this review.
Other programs reviewed have strengths in the pcb design process,
Proteus maintains a constant high level of capability throughout.
Whether a schematic, user-friendly interactive routing, config-
urable autoplacing, competent autorouteing, or a combination
of the above, PROTEUS handles everything very well.”
Electronic & Wireless World CAD Review Roundup
FREE
DOWNLOADABLE
DEMO
Save Time. Save Money.
Proteus Starter Kit – $199 • Complete Systems from $449
“This is clearly superior in every respect.”
Virtual System Modelling
SYSTEMS
INC
.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
83
ware, much less get it to run accept-
ably. Notably, these packages suck up
RAM like a dry sponge, and you need
to ante up at least a gigabyte or two
just to get in the game. A big screen is
also a must in order to keep track of
an entire System-on-a-Chip’s worth of
activity without going crazy. Patience
is a virtue, because compile time for a
real chip is measured in hundreds of
LEs per minute.
Upgrading to a new PC is never
easy, unless you have a nice IT depart-
ment that does it for you. But if you
want to be an FPGA player, get used
to it. After all, chances are you’ll have
to do it again a rev or two down the
road. You’ve got to pay (for new PCs)
to play (with FPGAs).
As for tools themselves, full com-
mitment will quickly take you beyond
the limitations of the freebie evalua-
tion versions, so expect to be cough-
ing up some bucks from time to time
for upgrades and maintenance sub-
scription plans.
Perhaps a byproduct of the historic
ASIC replacement strategy, FPGAs
still carry licensing baggage like big-
ticket EDA software. Having grappled
with balky, complicated, user-
unfriendly license schemes over the
years, I can assure you it’s almost
never painless. Even though I man-
aged to finagle a prelicensed version
from the friendly folks at Altera, I still
had to pull tech-support strings to get
past some licensing hiccups.
HANDS ON
Lots of third parties offer Altera
Stratix and Cyclone-based SBCs (no
doubt soon to be joined by the Stratix II
and Cyclone II versions as well),
which can host the Nios II. However,
although it isn’t cheap at $995,
Altera’s own Nios II evaluation kit is
a great way to get started (see Photo 2).
The evaluation board includes a
Cyclone FPGA, all the usual outboard
trimmings (memory, RS-232, buttons,
and LEDs), and then some (Ethernet, a
CompactFlash slot, and a plug-in, two-
line LCD). Naturally, the kit includes
all the software you need as well as a
USB blaster cable (a big speed and
ease-of-use improvement over the old
parallel port version) for downloading
and debugging.
Having covered the original Nios
introduction four years ago, I was
immediately impressed with the fit and
finish and out-of-the-box experience of
the new Nios II setup (“Excalibur
Marks the Spot,” Circuit Cellar
Online
, August 2000). For instance,
instead of some measly monitor pro-
gram, the board comes preloaded
with a sophisticated application that
exploits the RTOS (MicroC/OS-II
from Micrium) and TCP/IP stack
included in the kit for instant gratifi-
cation (see Photo 3).
Next, a series of well-executed tuto-
rials guide you through the development
process, starting from Hello World and
moving up all the way to adding cus-
tom instructions. The first step in a
Nios II project is just like any other
embedded design (i.e., characterizing
the requirements and choosing a
processor). Because this is a soft core,
choosing a processor is a matter of
selecting options and peripherals using
the SOPC Builder tool (see Photo 4).
For all of you who’ve struggled to
squeeze an extra port or pin out of a
dedicated MCU, believe me when I
say that after you’ve point-and-clicked
add-ons to your hearts content, you’ll
never want to go back.
One key choice is the how much
on-chip debug logic to include, rang-
ing from none to fancy hardware
breakpoints and real-time trace. The
ability to use sophisticated debugging
aids during prototyping and then
remove them to reduce cost for pro-
duction is a key advantage for soft-
core processors.
After the processor is defined, you
drop the output of SOPC Builder (i.e.,
a VHDL or Verilog hardware descrip-
tion of your customized Nios II) into
the main FPGA design tool, Quartus II.
As with all chip design software, the
Quartus II is an immensely deep and
complicated tool, but the tutorials
thoughtfully insulate you from a lot of
the complexity. You don’t have to be a
chip design expert or FPGA guru to
get started with the Nios II.
The Quartus II combines your Nios II
processor with the other custom logic
(or third-party IP) that comprises your
System-on-a-Chip and compiles the
entire chip (see Photo 5). Now’s a good
time to take a coffee break because
even the fastest PC will take a while
(5 to 10 min. for the tutorials) to
crunch a chip definition into a bit-
stream for downloading to the FPGA.
The final phase, software develop-
ment, is where the Nios II shows off its
biggest breakthrough by packaging the
GNU toolchain with an Eclipse-based
GUI IDE (see Photo 6). Gone are the
primitive command line-based tools of
Photo 4—
As soon as you ante up for a stash of gates it’s time to start filling them. The first step is selecting the
basic price/performance trade-off by choosing between one of three pre-defined cores, specifying the cache size
and adding debug options.
84
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
yore. Instead, for the first time, a soft-
core toolchain can hold its head high,
matching the best of the integrated envi-
ronments offered for traditional MCUs.
KEEP ON KEEPING ON
Have we reached soft core nirvana
yet when FPGA-based processors
replace all dedicated processor chips?
Nope. Never have and never will. By
virtue of cost, power consumption,
and chip count, FPGAs simply can’t
replace the optimized MCU in single-
chip applications, nor at the other
extreme of performance-at-any-price,
gigahertz-and-beyond processors.
However, there’s a huge middle
ground of few-chip applications for
which the FPGA soft core option is
becoming ever more viable.
Altera’s new chips and Nios II core
are a big step in the right direction.
However, the weaknesses of yesterday’s
soft-core tools were a showstopper, one
that even the power of Moore’s law
never could have overcome. Thus,
beyond the silicon itself, it’s the huge
advance in development tool capability
and friendliness that represents a pivotal
turning point for the soft core concept.
Sure, there’s still a lot more to be
done. Besides continuing to march
down the price curve, FPGAs probably
need on-board flash memory to move
to the next level. Throwing in some
key analog functions and a dab of glue
logic would be a nice touch. The
libraries of standard peripheral func-
tions and software (both in-house and
third-party), though now well seeded,
need time to blossom. Tool refinement
is a never-ending task, perhaps start-
ing with a friendlier licensing regime
and lower-price subscription and
maintenance options. But whatever the
objections, my gut feeling is that I’ve
seen the future, and it looks real soft.
I
Photo 6—
Beyond the processor itself, a compelling feature of the Nios II is the software development environment.
The latest open-source software (GNU C compiler and Eclipse GUI IDE) comprises a powerful toolchain every bit
the match of traditional competitors.
Photo 5—
After you’ve defined your Nios II CPU, Quartus works its magic (albeit a bit slowly) and maps your
design onto the FPGA hardware. As you can see, even this relatively powerful Nios II 32-bit processor (i.e., with
cache and debug logic) leaves plenty of room to spare on the FPGA for the rest of your application-specific logic.
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.
SOURCE
REFERENCES
[1] J. Hennessy and D. Patterson,
Computer Architecture: A
Quantitative Approach
, Morgan
Kaufman, San Francisco, CA, 1996.
[2] T. Cantrell and P. Freidin, “Roll
[3] J. Gray, “Building a RISC System In
An FPGA,” Circuit Cellar 116–118,
March–May 2000.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
85
IDEA BOX
THE
DIRECTORY
OF
PRODUCTS AND
SERVICES
AD FORMAT: Advertisers must furnish digital submission sheet and digital files that meet the specifications on the digital submission sheet.
ALL TEXT AND OTHER ELEMENTS MUST FIT WITHIN A 2
″″ ××
3
″″
FORMAT. Call for current rate and deadline information. Send your disk and digital submission
sheet to: IDEA BOX, Circuit Cellar, 4 Park Street, Vernon, CT 06066 or e-mail kc@circuitcellar.com. For more information call Sean Donnelly at (860) 872-3064.
The Suppliers Directory at www.circuitcellar.com/suppliers_dir/
is your guide to a variety of engineering products and services.
86
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
87
88
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
89
90
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
91
92
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 172 November 2004
93
94
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
Embedded Security Design (Part 1): Product Enclosure
FPGA Experimenter’s Board
H8/38024F-Based Programmable Timer
Artificial Life Display (Part 1): Design Basics
Visualizing History: Record and View High-Level Software Behavior
Reference Generation: Make 60 Hz the NCO Way
ABOVE THE GROUND PLANE
Building Boxes
APPLIED PCs
RabbitWeb HTTP Server
FROM THE BENCH
Light-to-Frequency Conversion (Part 1): TSL230R-Based Pulse
Oximeter
SILICON UPDATE
Position Statement
89
Abacom Technologies
88
All Electronics Corp.
85
Animated Lighting, L.C.
90
AP Circuits
42
Arcturus Networks
7
Atmel
91
Bagotronix, Inc.
28
Bellin Dynamic Systems, Inc.
89
BusBoard Prototype Systems
32
CadSoft Computer, Inc.
37
Capital Automation
87
Carl’s Electronics
37
CCS-Custom Computer Services
92
Conitec
11
Cypress PSoC Contest
1
Cypress MicroSystems
65
CWAV
91
DataRescue
85
Decade Engineering
66
DesignCon 2005
88
Digital Creation Labs, Inc.
92
Digital Products Co.
85
DLP Design
12
Earth Computer Technologies
90
EE Tools
(Electronic Engineering Tools)
53
EMAC, Inc.
33
ExpressPCB
The Index of Advertisers with links to their web sites is located at www.circuitcellar.com under the current issue.
Page
85
FDI-Future Designs, Inc.
92
Front Panel Express
93
Futurlec
28
General Assembly
90
Grid Connect
86
Hagstrom Electronics
73
HI-TECH Software, LLC
89
IMAGEcraft
74
Imagine Tools
88
Information Analytics
89
Intec Automation, Inc.
91
Intrepid Control Systems
90
Intronics, Inc.
41
Jameco
64, 86
JK microsystems, Inc.
77
JR Kerr Automation & Engineering
56
Keil Software
77
LabJack Corp.
77
Lakeview Research
91
Lawicel HB
89
Lemon Studios
29
Lemos International
2
Link Instruments
13, 46
Linx Technologies
58
MaxStream
88
MCC (Micro Computer Control)
89
Mental Automation
63
Microchip
93
MicroControls
92
microEngineering Labs, Inc.
88
MJS Consulting
90
Mosaic Industries, Inc.
50
Mouser Electronics
95
MVS
86
Mylydia, Inc.
C2
NetBurner
37
Nurve Networks LLC
88
OKW Electronics, Inc.
92
Ontrak Control Systems
58
PCB123
49
PCBexpress
87
PCB Fab Express
C4 Parallax, Inc.
85
Phytec America LLC
87
Phyton, Inc.
90
Picofab, Inc.
93
Pulsar, Inc.
86
Quality Kits & Devices
86
Quantum Composers, Inc.
87
R2 Controls
82
R4 Systems, Inc.
57
R.E. Smith
10,34
Rabbit Semiconductor
87
Radiotronix
Page
Page
Page
10
Reach Technology, Inc.
48
Remote Processing Corp.
93
Rogue Robotics Corp.
81
Saelig Company Inc.
89
Scidyne
3
Scott Edwards Electronics, Inc.
88
Sealevel Systems
88
Senix
5
Sierra Proto Express
9
Silicon Laboratories, Inc.
91
Softools
93
TAL Technologies
C3
Tech Tools
22, 23
Technologic Systems
87
Technological Arts
90
Tern, Inc.
86
Trace Systems, Inc.
91
Triangle Research Int’l, Inc.
53
Trilogy Design
19
Tri-M Systems Inc.
93
Weeder Technologies
13
World Educational Services
28
Zagros Robotics
91
Zanthic Technologies, Inc.
15
Z-World
27
Zilog, Inc.
January Issue 174
Deadlines
Space Close: Nov. 10
Material Due Date: Nov. 17
Theme:
Embedded Applications
B
ONUS
D
ISTRIBUTION
: DesignCon West
A
TTENTION
A
DVERTISERS
e-mail: sean@circuitcellar.com
INDEX OF ADVERTISERS
Preview of December Issue 173
Theme: Embedded Development
96
Issue 172 November 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
W
hen you buy a new car, you think about gas mileage, right? When you notice that one of your faucets drips constantly, you fix it, right? If
there are lights on all over the house, you go around and turn them off, right?
I’d like to think we do all these things because we’re conservationists who want to save the planet, but I know the real reason is a bit more
selfish. Certainly, if you don’t have a large family, or if you feel an incessant need to know you can squash other cars like bugs, there are saner
and more economical transportation choices than a Hummer. Similarly, the dripping faucet gets fixed when the water bill suggests that using
bottled water from the grocery store would have been cheaper than the city water utility.
I’m probably a bad example for the rest of the world, and I certainly can’t quite see myself roller skating or biking to work. In fact, if it weren’t
for the electric bill, I could go on in ignorant bliss forever. Unfortunately, I made the mistake of asking how much it was. (My wife handles the
personal finance stuff.)
The question was prompted after I walked out into the corridor behind the Circuit Cellar. It was 2 a.m., and I didn’t even need the lights to
see where I was going. There were so many backlit LCDs, LEDs, pilot lights, and shimmering indicators and displays that the entire place
glowed. There are a hundred LEDs on the HCS II I/O boards alone. Obviously, 20 years of tacking displays and LEDs on all my projects has
caught up with me. As I walked back upstairs, the home control system switched lights on and off in each room. Eventually, I stood in the kitchen
and looked around. Inside the house, the HCS II had a half-dozen bulbs dimmed to half brightness. Outside the house, it looked like a Wal-
Mart parking lot. Whether for security, mood lighting, or just so our dog Katy doesn’t get lost in the dark, my home is what you’d call “well lit.”;-)
Of course, long ago, I replaced the incandescent floods (that consumed thousands of watts) with more efficient sodium vapor lights, but there
are still at least 10 outside floodlights on various duty cycles.
Just for the heck of it, the next morning I asked how much our average electric bill was, and my wife said, “It peaks a little more during the
summer with air conditioning, but it averages about $300 a month!” Needless to say, I was shocked. We don’t have an electric water heater,
electric stove, or electric heating. Should I get Katy a miner’s light, kill the floods, and tell her to fend for herself?
Electronic living is certainly more expensive than I thought. Even with electricity billed at 10.5 cents a kilowatt-hour in Connecticut, a few
floods and corridor lights shouldn’t be doing all this. I could see maybe $50 a month for all these “nite” lights. Where was everything else com-
ing from?
I decided to do a test. My house isn’t really a house; it’s more like a compound with five buildings (garages, greenhouse, etc.). Because it
is so spread out, I actually have two utility service entrances (two bills totaling $300 and, as if that isn’t complicated enough, seven electric
service panels). I decided to see what the quiescent current was for all this mess. At 4 p.m. (in late September), the heating and air condition-
ing systems weren’t running, and the inside and outside lights were off. I clipped my trusty AC ammeter on each leg of the 220-V service feed-
ing the outside garages. It read approximately 1.5 A on each leg. I proceeded to the house and repeated the process. This time I read 3 A on
one leg and 6 A on the second. Neglecting power factor issues, it looks like I’m burning over $100/month in Shutdown mode!
I started looking around for the culprits.You’d be surprised how many there are. Down in the Circuit Cellar, the desktops were off, but every-
thing else was plugged in and ready. The DSL modem and Wi-Fi sat there flashing away, and the router was consuming enough power to be
at 106°. (It’s a long story why I know the temperature.) Without ripping out a bunch of power cords, I could easily presume that the HCS II stuff
was good for a couple hundred watts with all the displays, indicators, and powered peripherals all over the network. When I turned around, I
could see at least a dozen wall-wart power supplies for various electronic gadgets. Another power supply “growth culture” clogged more AC
outlets a few feet away. Add to that all the battery chargers, humming UPSs, webcams, satellite receivers, and security systems—arrrgh! I had-
n’t even gone beyond one room, and I could see a major problem with wasted power.
Obviously, there isn’t an immediate and easy resolution. For sure I have to do some triaging to prioritize my power leaks, but I can’t simply
unplug everything without ending up back in the Stone Age. Life today demands that everything be connected, and by necessity, a lot of it is
powered all the time. In my case, it just means I need a much heavier power cord than most people.
Feel the Heat
PPRRIIOORRIITTYY IINNTTEERRRRUUPPTT
steve.ciarcia@circuitcellar.com
by Steve Ciarcia, Founder and Editorial Director
Wyszukiwarka
Podobne podstrony:
circuit cellar1996 11
circuit cellar1993 11
circuit cellar1994 11
circuit cellar1997 11
circuit cellar2000 11
circuit cellar1995 11
circuit cellar2002 11
circuit cellar2001 11
circuit cellar2003 11
circuit cellar1996 11
circuit cellar1993 11
circuit cellar1995 11
circuit cellar1996 11
circuit cellar2003 11
circuit cellar1997 11
circuit cellar1993 11
więcej podobnych podstron