Con el CRC8 sería la forma más rápida.
Si tienes 4 bytes de un rfid seguido de un byte con un CRC8 calculado sobre esos 4 bytes entonces la búsqueda solo la haces en los crc8’s y no en toda la eeprom.
Por ejemplo:
Meten una tarjeta. Su rfid es 1234567890. ....
Gracias por tu respuesta, por ultimo antes de tirarme al ruedo,,
lo ideal seria antes de empezar a escribir el la eeprom colocar todo en FF? para saber donde escribí la ultima vez, o que seria lo adecuado para ir escribiendo en orden?
Gracias por la paciencia.
Efectivamente la eeprom la inicializas a FF una sola vez. Por ejemplo, mediante un menú o una opción de inicialización, esto sería “formatear”
Esto se puede plantear de muchas formas. Yo te sugiero imitar un poco a un sistema de archivos y estructurar la eeprom para trabajar de forma similar.
Puedes hacerlo parecido a como funciona el sistema de archivos FAT32 que usa un sector llamado FSINFO donde almacena entre otros, cuál es la última entrada que ha sido ocupada y por lo tanto, para buscar una entrada libre lo harás a partir de la siguiente que indica fsinfo. Pues aquí lo puedes hacer igual. Esto FAT32 lo usa solamente para acelerar la búsqueda de entradas libres en una unidad que puede tener 32 Gb. Se hace muy necesario. Pero en tu caso en una eeprom que puede tener 255 bytes o 2 Kb no vas a acelerar mucho, pero la idea en este caso no es acelerar nada sino controlar en forma secuencial por orden ascendente el registro y eliminación de tarjetas como explicó más abajo.
En adelante, llamo “entrada” al conjunto de 5 bytes (4 para tu rfid y 1 para crc o byte de atributos) como sugiere el compañero que es también muy buena idea por que puedes indicar muchísimas cosas en ese byte relativos a la entrada de la que forma parte o al rfid en si o a todo.
Te reservas por ejemplo la última posición o las dos últimas posiciones de la eeprom según la cantidad de eeprom disponible para poner ahí tu “fsinfo”. Cuando grabes una tarjeta nueva, te vienes aquí e indicas el índice de entrada de esa tarjeta entendiendo como índice, el que apunta al quinto byte de la entrada (que es el que contiene el crc o los atributos) Así siempre sabes donde se grabó la última tarjeta y no tienes que escanear toda la eeprom.
Cuando una tarjeta es eliminada, sus 5 bytes pasan a FF.
Cuando vas a grabar una nueva consultas tu “fsinfo” para saber por donde se grabó la última y empezar a buscar una entrada libre para la nueva tarjeta. Cuando fsinfo llegue al final de la eeprom empieza a cero otra vez.
Escanear solo los bytes 4,9,14,19 como ya sugerí. Si están en FF significa que esa entrada es posible que esté libre. Aún hay que comprobarlo.
Ahora tocaría leer la entrada completa, los 5 bytes. ¿Están todos a FF? , entrada libre encontrada. La tomas, la usas y te vas al fsinfo y lo indicas. Ya siempre sabrás a partir de donde empezar a buscar la siguiente vez.
Como ves, las operaciones de registro y eliminación de tarjetas siempre va a ir en forma secuencial en orden ascendente a lo largo de toda la eeprom y cuando llegues al final comienza a cero de nuevo.
Esto presenta de antemano una ventaja, y es que las operaciones de grabación en las entradas disponibles se automatiza.
Pero presenta una desventaja, y es que los índices ya no van a estar necesariamente organizados por orden. Por lo que cuando metes una tarjeta y lees el rfid y obtienes su índice tienes que ir a buscar ese índice en la eeprom. Escaneando de nuevo los bytes 4,9,14,19,24,29, etc de principio a fin hasta que lo encuentres.
De nuevo, en el arranque del programa lo podrías indexar. Leyendo todos los índices y haciéndote un array en ram de donden están todos y así la localización es prácticamente instantánea.
Un saludo.
