Issue
142 May 2002
Taking
a Swim with Atmel's STK500
by
Fred Eady
Ready
to dive in and take a closer look at a few of the
ATmegaxxx offerings from Atmel, Fred found no better
place to start than with the starter kit. He found
that there’s plenty of processing power and before
long, he was into the deep Atmel-blue realm of embedded.
Start
•
The Atmel STK500 • Imagecraft
AVR C Compiler •
Sources
& PDF
Like
a shark, I am constantly on the prowl. Sharks are
at home in the water. I swim the oceans of technology
hoping to find yet another interesting and useful
embedded device. Shark food comes in a wrapper of
scales. My sustenance is contained inside anti-static
bags packed in cardboard boxes adorned with UPS
and FedEx labels. If your fins and teeth look like
mine and your food comes from the back of a delivery
truck, you’ll definitely want to join me as I venture
into Atmel-blue waters.
IN
THE BEGINNING
Most
manufacturers offer a starter kit and as the name implies,
it’s a good place to start if you’re not familiar with
the company’s products. It just so happens that I have
an Atmel STK500 starter kit here on the Florida room
bench. Since I began employing the services of small
microcontrollers on the Internet, I’ve been constantly
looking for microcontrollers with ample amounts of RAM
and program memory that can house a robust C-based Internet
application.
A
lot of people talk about how they’re able to stuff Internet
protocol stacks into tiny microcontroller memory spaces.
Even though the protocol stack can exist and work in
the confined memory spaces, the dynamic data payload
that’s transferred from these micro-sized protocol stack
implementations is relatively small. There just isn’t
enough SRAM payload buffer area to build a large dynamic
message and just as little space left in the program
memory to "can" a set of similar messages. The simple
fact is that you need substantial microcontroller SRAM
resources if you want to dynamically send more than
a few characters per packet.
You
may be thinking that I’ve lost it and that you can write
code to push the message into the pipe on the fly or
conjure up a code-decode data compression scheme and
thus erase the buffer memory constraint. That’s nice,
but keep in mind that nothing is free in the world of
embedded computing. To build those dynamic messages
in an SRAM-constrained microcontroller, you’ll use more
program memory bytes to compensate for the lack of buffer
SRAM bytes. And that’s why my eyes are on the Atmel
ATmega16 and the ATmega163.
Both
devices contain 16 KB of self-programmable flash program
memory and 1 KB of internal SRAM. Another feature that
tickles my shark senses is the ATmega’s affinity for
applications written in the C language. The ATmega16
and ATmega163 are medium-sized fish, but in deeper waters
lurks the ATmega128 with 128 KB of program flash memory
and 4 KB of SRAM. Right now I’m fishing with light tackle
in a johnboat, so we’ll only concern ourselves with
the ATmega16, ATmega163, and AT90S8515.
The
AT90S8515 comes mounted on the Atmel STK500 and is loaded
with a blink-the-LEDs test program. You may be familiar
with the AT90S8515 because it’s the microcontroller
that powers iReady’s µInternet device.
My
immediate goal is to bring full C-based Atmel microcontroller
capability to the table and bring you along for the
ride. As I get deeper into Atmel waters, I’ll trade
in the flat-bottom boat for an ocean-going model to
go after the really big fish.
