ADVENTURES IN PROPELLER PROGRAMMING
■ BY JON WILLIAMS
Discuss this article in the Nuts & Volts forums at http://forum.nutsvolts.com.
TRACK ‘EM DANNO!
While many are uncomfortable with the fast pace of technology, for
hobbyists like you and me the speed at which things change means that
more interesting components become available for us to experiment with.
Take the trackball, for example. Now, trackballs have been around for a very
long time — remember the monsters used in arcade games? At the leading
edge of the smart phone revolution, miniature trackballs were installed in
Blackberrys and similar devices. Now, they’re available for us to use, too.
In the last Spin Zone column, we did a bit of a reboot and set up some guidelines for writing PASM code that
will play nicely with Spin and other languages that run on
the Propeller — PropGCC, for example. In this column, I’m
going to show you a very practical example of that code
style to create a nice little driver for a miniature trackball
module. I’m using the module from Parallax (#27908), but
the code should run with simple modifications for the
button and LED(s) if you’re using the SparkFun (COM-
Figure 1 shows my test setup: a Parallax trackball
module inserted into the groovy new Propeller Board-of-Education (a fantastic, fully-loaded, yet small platform). The
connections for the Parallax trackball are illustrated in
Figure 2. Note that the direction outputs are labeled OPA,
OPB, etc. They map to finger movement on the trackball
TRACKIN’ THE BALL
The way the trackball works is actually very simple:
When there is motion on an axis, the
corresponding direction pin will
toggle between high and low. I put a
‘scope on the pins and found that the
delay between edges was never any
less than about 2 ms. Could we write
a driver in Spin? Probably, but the
PASM code for this driver is so easy
that we might as well do it that way
and take advantage of the speed.
Before we get into the details,
though, let’s talk about goals. My
thought is that a trackball can be
treated like an upside-down mouse,
and as there is a mouse driver in the
Propeller standard library I had a look
to see what methods we might want
to support. It makes sense to keep
the method calls as close as possible
to simplify switching between similar
devices for an application. Starting
with the obvious, we would want to ■ FIGURE 1.