![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
Max
Joined: 15 Dec 2003 Posts: 51 Location: Italy
|
Reading a lot of data EEPROM external |
Posted: Fri Sep 30, 2011 2:18 am |
|
|
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. ![Very Happy](images/smiles/icon_biggrin.gif) |
|
![](templates/subSilver/images/spacer.gif) |
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Fri Sep 30, 2011 4:45 am |
|
|
Quote: | This requires too much time and I would not go that route. | My initial thought too was that serial reading is not very intelligent, but have you tried the timing maths?
500 id's * 5 bytes each = 2,500 bytes = 20,000 bits
Let's take a PIC at 4MHz, you can go to 40MHz but 4MHz saves some energy and gives room for improvement when later in the project things turn out worse than expected (happens me often). Then the SPI-bus is clocked at 4MHz / 4 = 1 MHz.
Reading all bits takes: 20,000 / 1MHz = 0,020 sec = 20ms.
Seems fast enough to me for a door lock.
Note that a good relay takes about 10 - 40ms to actuate, link.
I recommend to use SPI bus because this is much quicker than I2C. I2C has a maximum speed of 400kHz where SPI is only limited by the CPU clock and tops at 10MHz for a 40MHz PIC.
Keeping it simple like this has several advantages:
- EEPROM and FRAM chips have a special sequential read command, they can do this at maximum speed without the overhead of you sending the address for every byte you want to read.
- A simple algorithm means you are quick finished writing the program.
- A small program has fewer bugs, important in your safety lock device!
- Adding new codes can be just appended to the end of the list. You don't need complicated (PC) software to sort the new codes in an efficient way.
I was thinking about suggesting more 'fancy' code by using an interrupt routine to read the SPI bus data in the background, but that would actually slow your application a lot. Interrupts on a PIC16 have about 60 instruction cycles overhead, even more on a PIC18, so on your 4MHz PIC that means 16,600 or less interrupts per second. Not the way to go.
Last edited by ckielstra on Fri Sep 30, 2011 2:27 pm; edited 1 time in total |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Fri Sep 30, 2011 9:49 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Max
Joined: 15 Dec 2003 Posts: 51 Location: Italy
|
|
Posted: Fri Sep 30, 2011 2:17 pm |
|
|
[quote="ckielstra"] Quote: |
I recommend to use SPI bus because this is much quicker than I2C. I2C has a maximum speed of 400kHz where SPI is only limited by the CPU clock and tops at 10MHz for a 40MHz PIC.
|
I had not thought to SPI, it is faster,I'll try 'a 23k256.
[quote="Ttelmah"] Quote: |
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),....
|
I understood the way around the tables
but in my case I would need to 255x255 tables?
Data is 5 bytes.
assume FD 5B 55 0A 3E:
The first table read the numbers that I find to 'address 0A, assuming BB to find now in the table to BB' address 55 find the 'address of the next table, etc. ..
And 'so'? |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Fri Sep 30, 2011 2:32 pm |
|
|
No. You would only need tables for paths that exist.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9170 Location: Greensville,Ontario
|
|
Posted: Fri Sep 30, 2011 6:17 pm |
|
|
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! |
|
![](templates/subSilver/images/spacer.gif) |
gpsmikey
Joined: 16 Nov 2010 Posts: 588 Location: Kirkland, WA
|
|
Posted: Sun Oct 02, 2011 10:01 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Max
Joined: 15 Dec 2003 Posts: 51 Location: Italy
|
|
Posted: Mon Oct 03, 2011 1:33 am |
|
|
@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. |
|
![](templates/subSilver/images/spacer.gif) |
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Mon Oct 03, 2011 8:21 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Max
Joined: 15 Dec 2003 Posts: 51 Location: Italy
|
|
Posted: Mon Oct 03, 2011 10:10 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Tue Oct 04, 2011 1:56 am |
|
|
Max wrote: | 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. |
As you are using EEPROM there's no reason not to construct the data table on the PIC. But here we need to get modestly serious in computer science terms. There are a number of ways of representing an ordered list of data, in particular linked and doubly linked lists. These allow you, at the expense of a little more memory, to construct your list in the PIC. Even without such simple data structures you can fairly easily sort a list after you receive a new code. Much computing brain power, not to mention computing power was expended on this sort of problem in the 50's and early 60's, possibly more than any other single problem. Computing then suffered from just the problems we have to deal with on PICs: very limited RAM, small non-volatile memories, slow processors, and sluggish I/O.
There's little point in re-inventing the wheel. I certainly wouldn't expect to have a neatly ordered table dumped dow to my PIC at each change. I'd expect a supervisor to go along with their tag, log in, and then present the new tag/s for "learning" by the lock. Swipe, bleep, press, swipe, bleep, bleep. Test, Buzzzzzzz... Done. Simples.
RF Developer |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|