Shop OBEX P1 Docs P2 Docs Learn Events
RFID Tag Reader code - where did the bytes go? — Parallax Forums

RFID Tag Reader code - where did the bytes go?

Brian RileyBrian Riley Posts: 626
edited 2006-02-27 07:04 in BASIC Stamp
In addition to some other goodies I recently bought an RFID reader on which to experiment. When I went to interface it with some existing code I found that the 'entry fee' was prohibitive, that is to say the TEN BYTE BUFFER for non SPRAM chips made it a non starter for anything complex. Now that bugged me ... so I did some thinking and came up with this solution. I tried it first on a second copy of the RFID_basic.BS2 code, a simple recognition and display card ID, and then on the recognition and comparison program.

They key to this fix is this line

    SERIN RFIDLine, T2400,200, Look4Tone, [noparse][[/noparse]WAIT($0A),   HEX2 buf(0), HEX2 buf(1),
                                                                 HEX2 buf(2), HEX2 buf(3), HEX2 buf(4)]

' used instead of

    SERIN RFIDLine, T2400,200, Look4Tone, [noparse][[/noparse]WAIT($0A),   buf\10]



The buffer now becomes 5 bytes not 10 (when you only have 26 bytes available, salvaging 5 is THE WORLD!) each EEPROM DATA statement for Tag IDS is 5 bytes not 10 bytes

TagA            DATA    $0F, $32, $95, $98, $9D            '
TagB            DATA    $0F, $32, $95, $36, $6B            '

' used inStead of
TagA            DATA    "0F3295989D"            '
TagB            DATA    "0F3295366B"            '




The search loops become "0 TO 4" instead of "0 TO 9" etc. The code worked clean the first time I tried it. In terms of data structures it is much more compact, in strict terms you can double the number of tags to store. What I don't know is how much extra prgram space the new SERIN statement takes versus the old. Because of formatting the read may be a bit slower, though as someone said on the forum recently, "2400 baud is very forgiving." The program evaluation and comparison is quicker by half as many loops times how many tags you can store.

So now the RFID Reader code RAM requirements are less stringent and it 'plays well with others' much better! I hope this is of use to you all.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont

Comments

  • Jon WilliamsJon Williams Posts: 6,491
    edited 2006-02-24 05:13
    That's a clever solution, Brian. Congrats.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-02-24 05:14
    Brian,

    ·· Very nice.·· 'Nuf said.· =)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • GotenGoten Posts: 70
    edited 2006-02-24 16:31
    Thank You VERY much.turn.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

    Best Regards from Chile
    Goten
    www.chilebot.cl




    ·
  • Brian RileyBrian Riley Posts: 626
    edited 2006-02-24 16:34
    Thanks guys, I was wondering though, can you comment on the code size of the two SERIN statements? That is the difference between SERIN for buf\10 versus SERIN for the five "HEX2 buf(index)" specifications.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    cheers ... brian riley, n1bq, underhill center, vermont
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2006-02-24 17:44
    Brian,

    The easiest way is to check the Memory Map -- that's part of the reason it's there. Of course, the version using HEX modifiers will probably require a bit more space, but that is probably less of an issue than variable consumption. And since the RFID reader transmits at 2400 baud, there is plenty of time (during the stop bit) for the BASIC Stamp to handled the conversion.

    [noparse][[/noparse]Update] Okay, my Stamp editor was open so I did a quick test with just the SERIN statement.· When receiving 10 raw bytes into the array the program takes 17 bytes; when the program is updated to receive five hex values the program consumes 43 bytes.· Don't panic, this only happens in one location and if your program is struggling for variable space this is definitely worth doing.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax

    Post Edited (Jon Williams (Parallax)) : 2/24/2006 5:50:57 PM GMT
  • Brian RileyBrian Riley Posts: 626
    edited 2006-02-27 07:04
    Jon, thanks. I was going to do that tomorow. But you know the 17 bytes versus 43 bytes, is a difference of 26 bytes. If you were storing 5 IDs, there is 25 bytes of EEPROM space bought back and you are only down 1 over the other way. Plus, of course the fabulous wealth of 5 more bytes of RAM!

    At the risk of getting a kink in my wrist (patting myself on the back!) It is even more 'valuable' than I though it might be. I did a demo of a system I put togther this past weekend at a local hamfest forum. I am going to write it up with pix and code this week and post it to the projects section. It marries a BS2, Emic speech unit, an RC-4, RFID reader, an 8870 DTMF decoder and a DS1302 RTC. I am proud to say that every single I/O pin got used (I had to tie the RFID enable to ground!)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    cheers ... brian riley, n1bq, underhill center, vermont
Sign In or Register to comment.