PUTTING THE SPOTLIGHT ON BASIC STAMP PROJECTS, HINTS & TIPS
■ BY JON WILLIAMS
About four years ago, Ken Gracey — the crazy cat who runs Parallax — decided
that it would be a good idea to provide a free BASIC language compiler for the
SX microcontroller family. The BASIC Stamp had been around for some time
and there were a lot of power users — myself included — that would benefit
from such a beast. The goals were pretty simple: Make it PBASIC-like (though
not necessarily source compatible), easy to use in the SX-Key IDE, and allow it
to be a useful learning tool for those wanting to explore Assembly language
(the dark side!).
You know what? It all happened. SX/B is quite a lot like
PBASIC which makes the transition from Stamps to
the SX fairly straightforward. It has been integrated right
into the SX-Key IDE so you have a choice between
Assembly and BASIC, and it uses a single-pass, compile-in-place strategy that allows us to see how every line of SX/B
code is translated into Assembly language. And given
Parallax’s great relationship with its customers, SX/B has
steadily grown considerably, becoming a very useful tool
for hobbyists and professionals alike.
Of course, many will rightfully point out that I’m a
little biased as I was working for Ken at the time and am
one of the three amigos responsible for SX/B. That said,
now that I don’t work for Parallax I’m free to use anything
I want. Trust me, I’ve tried a bunch of neat chips and yet
I still go back to the SX and do my coding in SX/B (with
Assembly sprinkled in where it’s useful). You can too.
Listen, for the price of a BASIC compiler for another chip
you can buy yourself an SX-Key, an SX protoboard, and a
very nice meal for yourself and a friend.
The latest incarnation of SX/B is 2.0 and it has a
whole host of nice updates and improvements, but two
really big ones that we’ll explore here: improved variables
use and task management.
The SX — like many chips of similar design — uses a
banked memory architecture which means that the
program has access to global variables (much of this
consumed by I/O and system variables) plus one bank of
16 bytes. In the end, this means that the SX28 — the
device most of us will tend to use — allows SX/B just 19
bytes of general-purpose RAM that we can use without
having to do anything special. There’s nothing more
22 November 2008
surprising to the new SX/B user than to “run out of
variable space” after reading the SX datasheet and
knowing how much RAM exists.
Part of the problem — and I’m partially responsible
for this — is that many of us declare a set of temporary
variables for use in subroutines and functions. These
temporary variables eat into those 19 bytes of general-purpose RAM. In SX/B 2.0, we can define a [memory]
stack that allows subroutines and functions to have local,
temporary variables, i.e., they’re only used during the
execution of the subroutine or function and do not
consume any of the general-purpose RAM space.
To use locals, we need to declare a stack; in the SX28,
that declaration will look like this:
DEVICE SX28, OSCTX2, BOR42
For the SX28, the maximum stack size is 16. For the
SX48, the stack can be as big as you like within the
practical limits of the RAM. In case I wasn’t clear, this
chunk of RAM is used as needed and recovered when a
subroutine or function is terminated.
Something to keep in mind: If a subroutine calls
another and both are using local variables, we need to
ensure that the stack is big enough to handle the
requirements of both. Let’s say that subroutine A uses
three bytes of stack space and subroutine B uses four
bytes of stack space. If subroutine A calls subroutine B,
then we will need a stack of at least seven bytes. If RAM
is tight in your project, you can analyze stack use and set
it as required; if not, use 16 (for the SX28) and you’ll
probably never have to worry about it.
Declaring local variables is just like regular program