Issue
163 February 2004
The
Growth of the Atmel AVR Family
TALK
AND LISTEN TO XPORT
The
thermostat conversion protocol is based on a serial
data rate of 9600 bps using a data format of 8N1. The
ASCII commands for this protocol make debugging simple.
For the most part, every time something changes (e.g.,
the temperature), a command is sent to the XPort. All
commands are two or three characters (see Table 1).
E-mail notices can be enabled and disabled only through
the XPort.
| Table
1—The thermostat sends these commands whenever
a change occurs (i.e., you change the heat set point
or the temperature falls below the heat set point). |
The
XPort is responsible for passing on thermostat commands
to anyone on the Ethernet who has opened a connection
with it. This might be you and your browser. After all,
you might want to adjust the heat set point of the thermostat
from work so it’s toasty when you get home. Or, this
might be the XPort located at the furnace/air conditioner
in the basement where a command from the thermostat
to warm up the house could be carried out.
The
thermostat must not only send changes as commands to
the XPort; it must also respond to commands from the
XPort (or the Ethernet). Many commands are similar to
those the thermostat may send itself (see Table 2).
These commands can change variables in the thermostat
like a user when thermostat buttons are pushed. Five
additional commands also change variables in the thermostat,
but they do not have similar local input (see Table
3).
| Table
2—These commands are sent to the thermostat
whenever a change occurs via Ethernet (i.e., you
change the heat set point from a browser). |
| Table
3—These commands can be sent to the thermostat
via Ethernet. They adjust variables that cannot
be changed via local control (i.e., the e-mail triggers
are only enabled and disabled through the Ethernet).
The thermostat has no local control over this function,
although it is responsible for sending an Ex command
if e-mail triggers are enabled. |
The
Sx command
updates the variable STATE
to enable/disable the thermostat’s ability to request
heat/cool from the furnace/air conditioner. The IN
command requests that the thermostat send the status,
mode, fan, heat set point, cool set point, and actual
temperature.
The
low and high temperature thresholds are similar to the
heat set point and cool set point; however, instead
of requesting heat/cool from the furnace/air conditioner,
e-mails can be automatically sent by the XPort to signify
that the thermostat has reached an unsafe temperature.
The thermostat indicates this to the XPort using the
Ex command
(0 = safe, 1 = high temperature warning, and 2 = low
temperature warning). The Nx
command updates the TRIG variable to enable/disable
the reporting of Ex
e-mail commands.
Only
USART interrupts are used in this application. Although
the normal program flow can place data to be sent in
a ring buffer, it must set the USART data register empty
bit to allow the transmit interrupt routine to empty
the buffer. The receiver, however, is always enabled,
and fills a second ring buffer with received characters
until a <cr>
is received. The ring buffer is searched for the first
character less than ASCII zero. The next three or four
characters are placed in temporary variables and verified
for legal data. If all passes muster, then interrupt
routine branches to handle each command. Most of these
commands just update a variable, but the IN
command requests information. I wanted to leave this
interrupt routine to handle that, so I tagged the need
for this using the T bit (user bit) in the status register.
Normal
program execution proceeds as follows. Do an ADC loop
for temperature conversion and do a table look-up of
the conversion result to degrees Fahrenheit. Then, based
on the selected mode and current temperature, make any
changes necessary and send any command changes to the
XPort. Next, look for button pushes, make any changes
necessary, and send any command changes to the XPort.
Finally, update the LCD and check the T bit in the status
register to see if the XPort has requested information
(IN).
If necessary, send the XPort all of the commands indicating
the current status and go back to begin the loop once
again.
