ADVENTURES IN PROPELLER PROGRAMMING
Post comments on this article and find any associated files and/or downloads at
if (outa[LED_26] == 1)
if (ledtimer.millis => 100)
if (ledtimer.millis => 900)
Propeller Activity Board Parallax #32910
Serial RFID Reader Parallax #28140
Servo Extender Cable Parallax #800-00120
EFX-TEK #805-00035 (short)
EFX-TEK #805-00175 (long)
if (ledtimer.millis => 500)
if (outa[LED_27] == 1)
if (led27tmr.millis => 333)
if (led27tmr.millis => 667)
In this case — where the timing changes from state to
state — using adjust() could be problematic, so the timer
is simply restarted.
What I'm doing here is not new or unique;
programmers have been coding like this for decades. Still,
in our “Keep It Simple, Sam!” world view, we often resort
to strategies that — while simple — are inefficient and can
limit what a program does. To the degree it's possible in
my projects, I'm banishing waitcnt and pause()!
In this case, we're going to set up each of the LED
pins (making them outputs and low) and start a timer for
each. Notice the simplicity of the loop in main: All it has
to do is call the methods that process each of the LEDs.
Is That You?
For the LED on P26, we want it to toggle every 125
milliseconds. By calling the millis() method, we can tell
when it's time to toggle. Note the use of => when
checking the timer versus ==. Why? Well, the world is an
imperfect place. If some other process takes a bit more
time that expected, we might not hit dead on the delay
value using ==; we've all seen this when missing a waitcnt
target. Using => ensures the toggle at or just after the
As I stated at the top, I've had recent interactions with
people that want to connect the Parallax serial RFID
reader to a Propeller. "No problem!" I told them — then I
thought I should review my own code.
When the switch time arrives, we back up the timer
with the adjust() method; this simplifies checking by not
having a moving target in the millis() value, and it also
allows the next change to take place when it should. The
In the past, I've written very simple code that only
demonstrates how to get data from the reader, display it,
and compare it to a list of known tags — the kind of thing
one might do for an access control system. The code
works fine, though I've improved on searching the list of
known tags. Still, I wanted to create a framework that was
a little more flexible, and my nifty time object helped out.
LED gets updated to the new state and we're out. Note
that each of the LED process methods are very short,
hence, won't take much time — this leaves time for the
main loop to do other things.
Here's where I'm going: When the RFID reader is
enabled, it draws a fair bit of current. Since the
presentation of tags is sporadic at best, there's no need to
leave the reader on all the time. The other side of that is
we don't want to have to do anything special to present
the tag — other than holding it up to the reader.
To me, all of this is a very low speed human activity.
In the past, I've used a specialty LED blinker cog to
provide a simple visual indication of a program's state. For
example: The LED is off when there's no problem; a short
blink for a small problem; and a long blink for a big
problem. Here's how we can tackle this requirement
without using a cog:
So, I decided that the reader — when waiting on a tag —
would be activated for one second, then deactivated for
another second. This will save energy and a one second
delay to a person with an RFID tag will cause no
problems. In fact, I think we're all used to holding an RFID
tag to the reader for a couple seconds before a response
Honestly, my first thought was to create a PASM
object to do the work of enabling the reader and waiting
for serial data. After a few cups of coffee and a walk
around the block to clear my head, I changed my mind.
We already have good serial code, so why re-invent that
wheel — especially when so many projects will use the
same serial object, anyway.
June 2015 15