er, the BS2. It’s
with OEM parts),
and is worth considering for a
low-cost, access-control system.
recorded our tag
IDs, we can put
them into a simple
table for storage. Here’s what my table looks like:
Figure 3. Connecting the reader
to a terminal.
Now, you’ll see what I was just talking about with the BS1
not being quite as convenient as the BS2. There is no STR
modifier with the BS1, and its memory cannot be treated
like an array. Everything must be done one byte at a time.
SERIN RX, T2400, ($0A),
➔ tag0, tag1, tag2, tag3, tag4,
➔ tag5, tag6, tag7, tag8, tag9
Note that the SERIN line is really long, but needs to be
on one line to make sure that all 11 bytes (header plus 10)
are received properly. For publication, I’ve split the line, but
you’ll find it all together in the downloadable version of the
code. With the tag ID stored in the BS1’s RAM, we can
compare it to our table entries to determine whether the
tag presented is a match or not. Admittedly, this looks a little hairy, but it’s really not that bad. To keep things concise,
I’m only showing the first and last bytes, but the same code
is required for all 10 elements of the RFID tag string.
Remember that your table will be different, as the
RFID tag strings are unique. By using the Memory Map
feature of the Stamp IDE, I found I had room for five tags.
Since I only had three to work with, I padded the table for
the unused positions. A program constant will prevent us
from searching past the known tag strings.
The next step is to set up our control outputs. For this
security program, we’ll turn off the reader and lock the door.
After basic setup, we drop into the heart of the program
where the reader is activated and wait on a tag ID string.
FOR tagNum = 0 TO LastTag
pntr = tagNum 10 + 0
READ pntr, char
IF char <> tag0 THEN Bad_Char
‘ removed for clarity
pntr = tagNum 10 + 9
READ pntr, char
IF char <> tag9 THEN Bad_Char
Figure 4. Tag strings displayed in a terminal.
As you can see, comparing each byte of the RFID string
against a table entry requires three steps that are placed in
a loop: 1) We create a pointer to the corresponding position
of the table entry, 2) we read the character from the table,
and then 3) we compare the two bytes. If they don’t match,
the program jumps to the label called “Bad_Char” and we’ll
either move to the next table entry or, if we’re at the end of
the table, we’ll fall through the loop. Let’s say we do have a
match. When that occurs, we will jump to the label called
“Tag_Found” and execute the door-opening code:
NUTS & VOLTS
DEBUG “Entry: “, #tagNum, CR
SOUND Spkr, (114, 165)
The latch is activated (to allow entry) and a beep is
played through a piezo speaker of the amplifier circuit to
alert the user. The beep stops after two seconds and the
door relocks. Then, we go back to the top of the program.
When the tag presented does not match any of our table