ascii conversion help needed

[Darrel Taylor]

What? Now you have five.

... and receive a string of 10 hex characters something like: 0,F,0,2,0,2,A,9,B,1 ...
... Quite obviously, the ascii characters are not necessarily numbers, or even letters for that matter.

Well, if they are HEX characters, then they will always be letters or numbers.

Are you saying that you want to convert 0F,02,02,A9,B1 into the decimal number 64,458,238,385 ??

Or do you want to have a 40-bit binary number in 5 bytes like 0F:0202:A9B1 ??

or is it something else ??
<br>

[muddy0409]

G'day Darrel,
I have done a bit more on this, and finally got some on screen debugging done.
What actually comes in is: 0,4,1,4,3,B,B,C,E,6 which I am sending off to EEPROM as 30,34,31,34,33,42,42,43,45,36 which is the ascii of the first lot, correct??
I have wondered how to send off to EEPROM 0,4,1,4 etc as 04,14, etc making only 5 bytes in EEPROM rather than 10 with half the space used.
Ending up with 04,14,3B,BC,E6 the decoded ascii for which are all sorts of things. Thus getting back to my first question, getting some sort of decimal number formula that could be used with pretty much any 10 input characters to produce unique values for each.
I am reading the serial numbers off RFID tags and want to be able to say that card with serial number 04143BBCE6 is user number 356 (or something easily digested)
As a follow up to that, it would be real good to say that card serial 3BBC67467C is user 1, card 0414BCCD65 is user 2 etc, up to only 7 users for each system.
Is this confusing you as much as it is me??
I have played with placing the data in fixed locations in EEPROM, like this. To program the cards in to the thing at first use: Location 1 holds the card serial number in the full 30,34,31, etc format. Location 2 which is 16 further down the eeprom holds the second card's serial. Location 3, another 16 further down holds the third card's serial etc...right down to Location 14 or so, which is the eeprom's maximum space.
If I could use the half length serial numbers, then I could hold twice the number of cards and therefore users as well as making it easier to compare a newly read card with memory to see if a valid card was read.
Boy, I'm starting to waffle now, it's getting late.
PM

[Darrel Taylor]

OK, not a prob.

Just let the SERIN2 or HSERIN do the work for you...

SerNum  VAR BYTE[5]

SERIN2 Dpin, Dmode, [HEX2 SerNum(4), HEX2 SerNum(3), HEX2 SerNum(2), _
                     HEX2 SerNum(1), HEX2 SerNum(0)]

Now the SerNum array holds the "half length serial numbers".

From there you can write it to EEPROM, test it against what's already there, or whatever.

HTH,

[muddy0409]

Hmmmm...
Sort it as it comes in, rather than once it is in..makes sense. I'll give it a try.
After having slept on it, If I use the known location as the user number, as long as a card reading matches what's in the EEPROM then I can use the location as the ID number. It doesn't really matter what's in there, as long as it is a match.

Thanks heaps Darrel,
PM

[Darrel Taylor]

It doesn't really matter what's in there, as long as it is a match.

Sure, as long as everyone has the same security level. But if there are restrictions like giving access to certain people at certain times of the day, then you'll need to know who they are.

I'm sure you could do this on your own, but here's a possible search routine. Might save you some time. Haven't thoroughly tested it, but it should be close.

<font color="#000000"><b>Record </b><font color="#008000"><b>VAR BYTE     </b></font><font color="#0000FF"><b><i>; Start of each Record
</i></b></font><b>Ptr    </b><font color="#008000"><b>VAR BYTE     </b></font><font color="#0000FF"><b><i>; Points to each byte in the record
</i></b></font><b>TempB  </b><font color="#008000"><b>VAR BYTE     </b></font><font color="#0000FF"><b><i>; Temp var
</i></b></font><b>MaxEE  </b><font color="#008000"><b>CON </b></font><b>250      </b><font color="#0000FF"><b><i>; Start addr of Last available record
</i></b></font><b>SerNum </b><font color="#008000"><b>VAR BYTE</b></font>[<b>5</b>]  <font color="#0000FF"><b><i>; The S/N to search for
</i></b></font><b>UserID </b><font color="#008000"><b>VAR BYTE     </b></font><font color="#0000FF"><b><i>; Resulting User ID

</i></b></font><b>SearchUser</b>:
    <font color="#008000"><b>FOR </b></font><b>Record </b>= <b>0 </b><font color="#008000"><b>TO </b></font><b>MaxEE </b><font color="#008000"><b>STEP </b></font><b>5
        </b><font color="#008000"><b>FOR </b></font><b>Ptr </b>= <b>0 </b><font color="#008000"><b>TO </b></font><b>4
            </b><font color="#008000"><b>READ </b></font><b>Record </b>+ <b>Ptr</b>, <b>TempB
            </b><font color="#008000"><b>IF </b></font><b>SerNum</b>(<b>Ptr</b>) &lt;&gt; <b>TempB </b><font color="#008000"><b>THEN </b></font><b>RecNotMatch
        </b><font color="#008000"><b>NEXT </b></font><b>Ptr
        </b><font color="#008000"><b>GOTO </b></font><b>MatchFound
 RecNotMatch</b>:
    <font color="#008000"><b>NEXT </b></font><b>Record
    UserID </b>= <b>0    </b><font color="#0000FF"><b><i>; returns 0 if no match found
    </i></b></font><font color="#008000"><b>RETURN
    
 </b></font><b>MatchFound</b>:
    <b>UserID </b>= <b>Record </b>/ <b>5 </b>+ <b>1 </b><font color="#0000FF"><b><i>; returns UserID starting at 1
</i></b></font><font color="#008000"><b>RETURN
</b></font>

<br>

[muddy0409]

G'day Darrel,
The things you suggested about sorting worked a treat.
I'm not really interested in 'all the bells and whistles' as far as time zones, access levels etc. as that is already being done by the dozen by everyone else.
I got a project for just a simple 'valid card = access' type thing, which is pretty hard to find out there.
Apart from that all the discussion with you has been great. It sure helps to have someone and an excellent forum, to bounce things around in.
I had the matching already done with the 16 byte data that I had and just gotta change that to 8 byte version.
I'll be back (probably) when I'm stuck for something else. (probably)
Thanks again.
PM

[Darrel Taylor]

Ummm, Why 8 bytes?

If the idea was to store more users in the limited EEPROM space, and you don't need to have other security settings per user. Why not have a 5 byte record size? That's a 60% increase in users. 51 vs 32. (assuming 256 EEPROM)
<br>