PICAXE PRIMER
memory and the three built-in
variables available for use with it
(hserinflag, hserptr, and ptr). As we
mentioned, the scratchpad contains
128 locations, so there's plenty of
room to capture all our SIRC remote
key-presses. (Actually, the capturing
of the serial input data occurs
automatically in the background.)
Even in our previous setup, all the
data was automatically stored in the
28X1's scratchpad; we just didn't access
it. In order to be able to do so, we
need to understand a bit about how
the two pointer variables (hserptr and
ptr) function. Essentially, hserptr can be
thought of as a "write" pointer and ptr
can be thought of as a "read" pointer.
Hserptr always contains the
address of the scratchpad location in
which the next received byte will be
stored. When the 28X1 is set up for
background serial receive, hserptr
is automatically initialized to 0 so
the first byte received is stored in
location 0 of the scratchpad. Hserptr
is then automatically incremented to
1 in preparation for the reception of
the next byte. In this way, once we
have issued the appropriate setup
command ("hsersetup B1200_ 4,
%01"), up to 128 bytes can be
automatically stored in the
scratchpad without our having to
do anything else.
Retrieving the data is a little
more involved and requires an
understanding of the ptr pointer
and of a concept called "indirect
addressing." If you have done any
assembly language programming,
you're probably already familiar with
indirect addressing; if not, here goes!
If ptr = 0 and we write "sertxd (ptr)"
a value of 0 would be sent to the
terminal window. This is usually
referred to as "direct" addressing and
is something with which we are all
familiar. In contrast, "indirect" addressing (which is often signified with the
use of the "@" symbol) functions as
follows: If ptr = 0 and we write
"sertxd (@ptr)" then the contents of
scratchpad location 0 (not the value
0 itself) would be sent to the terminal
window. Therefore, @ptr is said to
"point to" the value we want. It is a
little confusing at first, but it's an
extremely powerful
concept that actually
saves us considerable
programming effort. In
order to clarify how all
this works, let's take a look at how
the "GetNewData" subroutine
functions in the "Hserin TestAll.bas"
program. To make it easier to
understand the following discussion,
open Hserin TestAll.bas in the
Programming Editor and/or print out
a copy. As you can see, the
GetNewData subroutine is called
once each time through the main
programming loop. Since the LED is
on for five seconds and off for one
second, there's enough time for
several keys to have been pressed on
the remote before the GetNewData
subroutine is called. Since the
program has already been set up for
background serial receive ("hsersetup
B1200_ 4, %01), all the key-presses
have been captured in the scratchpad
while the LED was blinking. The
function of the GetNewData
subroutine is to access all the data
that has been captured during the
previous blink. If no key has been
pressed during any one pass through
the loop, then hserinflag is still 0 and
GetNewData isn't called that time
around.
Let's take a look at how
GetNewData accomplishes its task.
To understand the first statement
("lastDataLoc = hserptr - 1"), remember
that hserptr always automatically points
to the location in which the next byte
will be stored so "hserptr - 1" is the
location in which the last received
byte has already been stored. Since
the background storage always starts
at location 0, we have both limits that
we need for a simple for…next loop.
Each time through the loop the
value of ptr is appropriately updated
and the "sertxd (@ptr)" statement
indirectly accesses the next stored
value pointed to by ptr and sends it
to the terminal window for display.
The final three statements before
returning from the subroutine simply
re-initialize the three scratchpad
variables so that the background
storage will again begin at location 0
the next time through the main loop.
8 Chars X 2 Lines
No BackLight HDM08216H-3-S00S
BackLight HDM08216L-3-L30S
16 Chars X 2 Lines
HDM16216H-5-S00S
HDM16216L-5-E30S
■ FIGURE 2. Hantronix LCD displays
for upcoming projects.
That's enough theory for now —
let's see how all this works in practice.
As we mentioned earlier, the physical
setup is identical to the one we used
last time so all you need to do is
download IRMBrxSIRC.bas to your
IRMB peripheral and Hserin TestAll.bas
to your 28X1 Master Processor. You
may have already discovered that it's
a good idea to download the two
programs in that order because it
leaves the Terminal Window open for
the 28X1 to use.
Also, don't forget that most (if not
all) TV remotes repeat their key-press
data fairly quickly; any extra data you
see displayed probably comes from
holding down a button a little too long.
So, fire up your system and see if you
can capture every key-press you make.
ESTABLISHING A SERIAL
DATA LINK
Once you can successfully
display all the IR data received by the
system, we're ready to move on to
our goal of establishing an IR serial
data link. To keep things reasonably
simple, we're going to focus on a
one-way link but the same principles
could be used to develop a two-way
link, as well. This time around, we're
going to shift from using the SIRC
protocol to the standard serial protocol.
Of course, the main advantage of this
approach is that we will be able to
transmit and receive the full ASCII
character set which can be very
useful in a wide range of projects.
There's nothing new in the hardware we will be using. On the receiving
end of the link, we'll use the same setup
we just used in our SIRC approach
while data transmission will be carried
out by the same battery-powered
IRMB setup we used in the previous
installment of the Primer. This time,
of course, we'll need three pieces of
software for the three processors
February 2009 17
