Reading a lot of data EEPROM external

[Max]

Hello Everyone.
I would like to help to build an access control system.
I read an RFID tag No 5 bytes and I want to enable a relay 'only if this identifier
5 bytes is present in a memory.
I thought about using a fram or i2c eeprom and enter starting from 'address 0 the first set of 5 bytes, starting from' address 5 the second series of 5 bytes .... and so 'until you have entered all those who are qualified.
The bytes of 5 group are many 5, 500 or more (ie 500 x 5 = 2500 bytes).
I think I'll have are reading and then will perform a sequential read of the entire EEPROM to determine whether the series is 5 bytes and then turn on the relay.
This requires too much time and I would not go that route.
Do you have any idea to manage in other ways?
Type organizing the memory in another way?
Discard the 'idea of ​​parallel memories for problems of insufficient number of pins.
Thanks in advance.

[ckielstra]

[Ttelmah]

One other suggestion, is to alter the way the data is stored.

Imaging you had 11213, and 23456 as two entries you wanted to look for.
You start with a table of ten entries (assuming the values are numbers), which reads:

0120000000

Then have tables:

0300000000
0040000000
0050000000
0006000000


When you receive the first byte, you load the entry in the first table corresponding to this byte's value. So for '1', you get '1', while for '2' you get '2' (fluke). If the value is '0', then there is no possible match. The values in the table are 16bit.
Then when you receive the second byte, you load the entry in the table addressed by the number you have already retrieved. So (assuming the first table is number '0'), for the first number you find yourself at entry '1' in table 1, and retrieve '3'. If the second number is anything else, you get '0', saying 'no match'. Then for the next byte, you now look at table 3, and if you have received '2', you find '5', while again any other number returns '0'.

The point is that you 'walk' a set of tables, each containing either the address of the table for the next digit, or '0' to say that the code has failed at this point. For each digit, you only have to retrieve two bytes (the table entry corresponding with the digit, in the table addressed by the last value). A 'valid' code, will reach the final column, and have a flag to say what you want to do (allowing multiple results if needed, or just a '0'/'1' for an K if this is all you want.
The hard part here would be building the tables - lends itself to a small PC program - you feed in the required numbers, and it generates the tables. The saving in work would be massive on checking the values, but at the cost of having to build the array of tables.

Best Wishes

[Max]

[quote="ckielstra"]

[Ttelmah]

No. You would only need tables for paths that exist.

Best Wishes

[temtronic]

if I'm reading it right...
Another possible way is to have the valid access card numbers presorted (say low to high) in the eeprom. This would be done during the initial data entry.
A simple binary search only needs 8 or 9 attempts to find if the tag in question is valid. If found it's valid, if not don't open the door!

[gpsmikey]

Another consideration - if it is not a requirement now, it will undoubtedly get added when they think of it - most RFID systems for people not only store the tag, but the times that tag is valid as well. Some people have access 24 hours/ 7 days a week, others only during regular business hours, so you might want to keep that in mind in your tables (as well as a RTC on the board).

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[Max]

@Ttelmah
Hello,
Sorry but I do not understand how many tables I need and how to configure.
For example I have 5 byte:
A0 FE C5 DF 08

How many tables I need?
Composed of 256 bytes?
During construction of tables with the way that I fill?
Sorry, the thing I'm very interested because I think my solution
Thanks for your time.

[ckielstra]

So far three different solutions have been suggested, each with their strong and weak points.

1) Linear search:
Pro:
* Easy to understand and implement
* On the PC you can create a simple text file and send this to PIC for updating.
Con:
* Relative slow: 20ms on a 4MHz PIC for 500 IDs but acceptable when compared to the relay actuation time of 40ms.

2) Ttelmah's table search
Pro:
* Lightning fast, only 5 reads (of 2 bytes each) for a 5 byte ID.
Con:
* Uses lot of memory per ID. 10 bytes each when ID numbers are close together but then less safe system. More likely 1500 - 2000 bytes each when IDs are spread evenly, that is 1Mbyte for 500 entries!
* Requires a complicated program on the PC to create the tables.

3) Temtroniç's binary search
Pro:
* Well documented search method, fairly easy.
* Reasonable fast: 512 IDs require 9 read operations (5 bytes each) and 1024 IDs require 10 read operations.
Con:
* Requires a relative simple PC program to sort the list (ascending or descending).

Think about your project and what is important to you. Is this a hobby project for learning then other things will be important to you then when it is a commercial project where the boss demands a quick and reliable solution. If it is for school then priorities change again.

[Max]

After an explanation so 'complete. Thank you so much
I think the solution of the binary search is the simplest. Unfortunately, every time you add / remove a tag must always use the PC to prepare the sorted file and then send it to the pic.
Thank you very much

[RF_Developer]