Issue
163 February 2004
The
Growth of the Atmel AVR Family
SECURITY
FOR SMARTCARDS
As
we become more comfortable with a cashless society,
the risk of identity theft continues to rise. We dislike
being held captive by a simple multidigit number. In
the future, transactions will be based on more than
just this fragile key. Smartcards are becoming the new
cache. Without knowledge of the data held securely within,
it becomes useless to everyone but the owner. Thus,
the security of a smartcard is its most valuable asset.
The AVR architecture becomes the hidden strength of
the new plastic via ISO 7816 external interfacing.
Security
features must protect data from not only direct software
access but also from hardware probing. The secure AVR-based
micros employ voltage and frequency control, secure
layout, and bus encryption security features. Atmel’s
commitment to support is reflected in the application
development tools they make available for all of the
AVR products.
USB
CONTROLLERS
Atmel
understands the importance of USB to the future of computing.
It has an extensive line of USB hubs, microcontrollers,
and hosts. This guarantees that the company will be
part of that future.
Many
products are based on AVR microcontrollers offering
low- and full-speed USB peripherals. Low-power AVR micros
can run directly from the USB bus thanks to internal
3.3-V regulators. The array of on-board peripherals
simplifies designing even the most I/O-intensive user
devices.
Software
support includes the USB library and applications Wizard.
This tool produces code, based on user input, including
USB descriptors, reports, and even complete applications.
LCD
CONTROLLERS
Almost
every product that requires a user interface takes advantage
of an LCD for rendering important information. Whether
the display has graphic glyphs or alphanumeric characters,
it’s just a mater of segment control. Empowering an
AVR core controller with an LCD controller simplifies
your job. This peripheral can driver up to 25 segments
and four back planes. To support the necessary multiplexing,
the controller supports various duty and biasing, as
well as flexible frame frequency control.
Atmel’s
ATSTK500/502 starter kit is a great platform for helping
you design applications for an AVR microcontroller with
a built-in LCD peripheral controller. As I was working
on last month’s column, I thought virtual peripherals
were fine for demonstrating a point, but I’m the kind
of guy that likes hardware. So naturally I was looking
for an alternative to the virtual thermostat used to
demonstrate an application of the Lantronix XPort Ethernet-to-serial
’Net-enabling device. The ATmega169 has the right features
to demonstrate a true hardware application of last month’s
virtual thermostat.
STARTS
WITH THE DISPLAY
The
display supplied on the ATSTK502 has many glyphs as
well as seven characters as seen in Photo 1a. I chose
to use a subset of this (see Photo 1b). The up- and
down-pointing arrowheads indicate various enabled modes
and functions, while only four characters are needed
to show temperature.
|
a)
b)
(Click
here to enlarge)
|
Photo
1a—The LCD used on the STK502 adapter has a number
of glyphs as well as 12-segment alphanumeric digits.
b—I used the arrowheads as function indicators and
only four of the available digits. |
The
LCD controller is first initialized for quarter duty,
3.0-V contrast, with a 54-Hz refresh rate (based on
a 3.58-MHz system clock). This allows the proper output
signals to be generated for the LCD’s segments and four
back planes (commons). Segments are mapped into 20 data
registers (LCDDR0–19), with five registers for each
common (LCDDR0–5 for COM0, etc.). Only 25 bits are needed
(one for each segment output) in each group. That’s
three full bytes and the LSB of the fourth byte. (The
remaining bits are unused.)
Character
data consists of 16 segments (14 for character segments
and two for glyph segments), with 4 bits in each of
the four back plane groups. This puts the same 4 bits
for character 1 and 2 into LCDDR0, 3 and 4 into LCDDR1,
and 5 and 6 into LCDDR2. Therefore, the look-up table
data can be masked directly into 1 of 3 bytes (with
the data nibble swapped for even characters).
When
a bit in one of these registers is written with a one,
the corresponding LCD segment is enabled (masking the
reflectivity of the background and showing up as black).
Bits written with a zero allow the segment to remain
transparent. The glyphs share bit locations with character
segments with the same byte, which requires masking
bits when updating data. This means that updating the
data for a character must not alter the data for any
glyphs and vice versa.
The
LCD_Update
routine tests variables to determine which glyphs and
characters need to be updated. The mode byte has four
possibilities: H (heat), C (cool), A (auto), and O (disabled).
The Fan byte indicates whether the fan is a one (on)
or a zero (auto). A byte value for HVACSTATUS is dependent
on mode, temperature, and set point; it indicates when
the furnace/air-conditioner is required to run. The
values are “H” (call for heat), “C” (call for cool),
“I” (idle), and “O” (disabled). Although the character
data comes from a look-up table consisting of characters
0 through 9 followed by “-,” “H,” “C,” “degree sign,”
and “F,” one of three displays can be requested.
The
DISPLAYMODE byte can be one of three values: 0x00 (temperature),
0x01 (heat set point), and 0x02 (cool set point). The
temperature (DISPLAYMODE) displays the measured temperature
of a thermistor displayed as “## °F” (more on this later),
while the set point (DISPLAYMODEs) display “H- ##” (heat
set point) and “C-##” (cool set point).
