RFID Projekt und EEPROM Speicherung

Hi zusammen!

Ich bin dabei ein RFID Projekt zu verwirklichen zwecks Alarmanlage für die Haustür.

Dafür habe ich mir einen handelsübliche RFID Reader und ein paar Chips besorgt, angeschlossen und das folgende Tutorialscatch verwendet.

#include <SPI.h>
#include <MFRC522.h>
#define SS_PIN 10
#define RST_PIN 9
MFRC522 mfrc522(SS_PIN, RST_PIN);

void setup()
{
Serial.begin(9600);
SPI.begin();
mfrc522.PCD_Init();
pinMode (2, OUTPUT); // Der Pin 2 ist jetzt ein Ausgang (Hier wird eine LED angeschlossen)
}

void loop()
{
if ( ! mfrc522.PICC_IsNewCardPresent())
{
return;
}

if ( ! mfrc522.PICC_ReadCardSerial())
{
return;
}

long code=0;

for (byte i = 0; i < mfrc522.uid.size; i++)
{
code=((code+mfrc522.uid.uidByte[i])*10);
}

Serial.print("Die Kartennummer lautet:");

Serial.println(code);

// Ab hier erfolgt die erweiterung des Programms.

if (code==1031720) // Wenn der Zahlencode 1031720 lautet...

{ // Programmabschniss öffnen

digitalWrite (2, HIGH); // ...dann soll die LED an Pin 2 leuchten...

delay (5000); // für 5 Sekunden

digitalWrite (2, LOW); // … und danach wieder aus gehen.

} // Programmabschnitt schließen

} // Sketch abschließen

Bisher funktioniert alles dem Tutorial entsprechend gut.

Nun benötige ich zum Aufbau euer Fachwissen.

Zunächst macht es Sinn, das ich die RFID IDs nicht immer manuell in den Code mit ein programmiere, so wie im Code Beispiel oben, sondern in einem Codeabschnitt per Button und Authorisierung mit MASTER RFID Chip plus dran halten der neuen RFID Chips zum hinzufügen.

Die sollen dann im EEPROM gepeichert werden, vermutlich wenn möglich über ein 2 Zeilen Display im Adminmodus auswähl und löschbar sein. Hat der Nano überhaupt ein EEPROM?

Um das alleine zu bewerkstelligen fehlt mir leider das Know How, vielleicht könnt Ihr mit entsprechende Tipps und Codes aus euren Projekten ans Herz legen die euch schon geholfen haben.

Wäre sehr schön. :slight_smile:

Hat der Nano überhaupt ein EEPROM?

Yes!

Noch nicht mal die Boardbeschreibung gelesen?
Oder das Datenblatt des µC?
Damit schon überfordert?

Tipp:
Stelle dich nicht dümmer als du bist.

Lesetipp

Jain. Hab eigentlich vorrausgesetzt das alle Arduino Boards einen EEPROM haben. xD

Ich kenns vom Due aus dem 3D Drucker bereich. Ich lese mir deinen Link definitiv durch.

Jain. Hab eigentlich vorrausgesetzt das alle Arduino Boards einen EEPROM haben. xD

Tipp:
Der Weg in die Hölle, ist mit falschen Annahmen gepflastert!

mrzortrax:
Um das alleine zu bewerkstelligen fehlt mir leider das Know How, vielleicht könnt Ihr mit entsprechende Tipps und Codes aus euren Projekten ans Herz legen die euch schon geholfen haben.

das ist schon ambitioniert. Das "einfachste" könnte sein:

10 Speicherplätze im EEPROM reservieren.
Schreiben mit EEPROM.put weils (mindestens) eine 4 Byte Variable ist. Ob es wirklich eine long ist wie in deinem Code, würde ich mich nicht darauf verlassen. Schaue dir die Lib an, was du da wirklich zurückbekommst, nicht dass du da auch mal 7 Byte als UID bekommst.
Auslesen mit EEPROM.get
"löschen" einer UID durch überschreiben mit 0
Bei der Auswahl von anzuzeigenden UIDs die "Speicherplätze" mit UID=0 quasi überlesen.
beim Hinzufügen den ersten Speicherplatz suchen, der eben UID=0 hat,
Vorsehen, dass das auch fehlschlagen kann (wenn schon alle 10 belegt sind) und nicht speichern lassen.

ja so in etwa würde ich das machen.

beim Hinzufügen den ersten Speicherplatz suchen, der eben UID=0 hat

Wobei unbenutzter Eprom Speicher üblicherweise den Wert 0xFF bzw. -1 hat.

noiasca:
das ist schon ambitioniert. Das "einfachste" könnte sein:

10 Speicherplätze im EEPROM reservieren.
Schreiben mit EEPROM.put weils (mindestens) eine 4 Byte Variable ist. Ob es wirklich eine long ist wie in deinem Code, würde ich mich nicht darauf verlassen. Schaue dir die Lib an, was du da wirklich zurückbekommst, nicht dass du da auch mal 7 Byte als UID bekommst.
Auslesen mit EEPROM.get
"löschen" einer UID durch überschreiben mit 0
Bei der Auswahl von anzuzeigenden UIDs die "Speicherplätze" mit UID=0 quasi überlesen.
beim Hinzufügen den ersten Speicherplatz suchen, der eben UID=0 hat,
Vorsehen, dass das auch fehlschlagen kann (wenn schon alle 10 belegt sind) und nicht speichern lassen.

ja so in etwa würde ich das machen.

Klingt schonmal sehr gut. Das würde mir doch schon reichen. Den Umgang mit dem EEPROM hab ich jetzt aber noch immer noch nicht so richtig durchblickt. Ich müsste also 10 Variabeln im EEPROM anlegen?

nein. können auch 9 oder 11 sein. Hängt von dir ab.
Wie viel Byte kannst im Arduino speichern?

Wieviel Byte musst du pro Chip vorsehen?

Eigentlich alles was du dir selber beantworten sollst.
Ich finde halt 10 eine schöne runde Zahl.

Ich müsste also 10 Variabeln im EEPROM anlegen?

Nein! (vermute ich mal)

Sondern:
Ein Array mit Strukturen.

Die andere Frage die sich generell stellt ist, ob die EEPROM variante in meinem Fall überhaupt Sinn macht (jetzt vom Aufwand her) oder ob die RFID manuell reinprogrammieren schneller und einfacher funktioniert als überhaupt die EEPROM variante überhaupt aufzubauen?

Wieviel Byte ich vorsehen muss? Da sprichst du sicherlich von der Nummer die hinter dem Chip steht?

Es gibt zwei Varianten zum Auslesen... irgendwie kommen da unterschiedliche werte raus.

Wo besteht der Unterschied zwischen

MFRC522 rfid(SS_PIN, RST_PIN); // Instance of the class

und

MFRC522 mfrc522(SS_PIN, RST_PIN);

?

Der Bezeichner der Instanz unterschneidetet sich.

hm ok...

Versuchen wir das mal etwas systematischer abzufrühstücken...

ich habe bislang 3 Karten und 3 Chips. Die Nummern die auf meinem Code basieren lauten wie folgt:

2526XXX
126XXX
1668XXX
921XXX
655XXX
1061XXX

Die letzten 3 stellen spare ich bezüglich des Datenschutzes aus... Ich denke das sind dann eher 4 bit oder?

Das ganze mit dem anderen Tutorial code ausgelsen gibt:

249 35 01 XXX
09 20 145 XXX
83 69 22X XX
163 17 21X XX
99 64 7X XX
57 70 138 XXX

also im Prinzip verglichen mit oben total unterschiedliche IDs?

Was isn da jetzt richtig oder falsch oder anders?

dein Sketch aus dem Eröffnungspost macht aus den gelesenen BYTES folgendes

for (byte i = 0; i < mfrc522.uid.size; i++)
{
code=((code+mfrc522.uid.uidByte[i])*10);
}

warum auch immer. Aber so stehts halt da.

einen anderen Sketch hast du nicht gezeigt. Aber da blank zwischen den Zahlen sind, nehme ich an, der andere gibt die gelesenen Bytes einfach Byteweise mit blank aus.

also im Prinzip verglichen mit oben total unterschiedliche IDs?

Was isn da jetzt richtig oder falsch oder anders?

Wo ist da was unterschiedlich, gleich, oder anders?

Ich sehe da nur absichtlich verstümmeltes Zeugs, mit dem man nix mehr anfangen kann.
Schon gar nicht vergleichen.

Vermutlich unterscheidet sich nur die Darstellung.
Also untersuche die Darstellende.

Hi

Das Speichern der gültigen IDs macht durchaus Sinn, wenn man 'Mal eben' IDs hinzufügen oder entfernen will - wenn die Tochter den Chip im Schwimmbad hat liegen lassen.
Dann ist's einfacher (und schneller), die Türen abzugehen und die eine ID rauszuwerfen, als die Chips (pro Tür halt) neu aufzuspielen.

Wie die ID dabei gespeichert wird, ist eigentlich egal - Hauptsache, Du verkrüppelst die Information nicht, also nicht nur die letzten drei Ziffern der ID speichern, sondern die Ganze.

MfG

noiasca:
dein Sketch aus dem Eröffnungspost macht aus den gelesenen BYTES folgendes

for (byte i = 0; i < mfrc522.uid.size; i++)

{
code=((code+mfrc522.uid.uidByte[i])*10);
}




warum auch immer. Aber so stehts halt da.

einen anderen Sketch hast du nicht gezeigt. Aber da blank zwischen den Zahlen sind, nehme ich an, der andere gibt die gelesenen Bytes einfach Byteweise mit blank aus.

Da könntest du natürlich recht haben, das in der zweiten Variante die Bytes direkt angezeigt werden... UPS ich sehe grade ein Update vom Hauptpost hat die Tage nicht funktioniert. Das hole ich direkt mal nach.

#include <SPI.h>
#include <MFRC522.h>
#define SS_PIN 10
#define RST_PIN 9
MFRC522 rfid(SS_PIN, RST_PIN); // Instance of the class



MFRC522::MIFARE_Key key;



int code[] = {249,35,01,185}; //This is the stored UID (Unlock Card)

int codeRead = 0;

String uidString;

void setup() {



  Serial.begin(9600);

  SPI.begin(); // Init SPI bus

  rfid.PCD_Init(); // Init MFRC522



  Serial.println(F("Arduino RFID tutorial"));



}



void loop() {

  if(  rfid.PICC_IsNewCardPresent())

  {

      readRFID();

  }

  delay(100);



}



void readRFID()

{



  rfid.PICC_ReadCardSerial();

  Serial.print(F("\nPICC type: "));

  MFRC522::PICC_Type piccType = rfid.PICC_GetType(rfid.uid.sak);

  Serial.println(rfid.PICC_GetTypeName(piccType));



  // Check is the PICC of Classic MIFARE type

  if (piccType != MFRC522::PICC_TYPE_MIFARE_MINI &&

    piccType != MFRC522::PICC_TYPE_MIFARE_1K &&

    piccType != MFRC522::PICC_TYPE_MIFARE_4K) {

    Serial.println(F("Your tag is not of type MIFARE Classic."));

    return;

  }



   

    Serial.println("Scanned PICC's UID:");

    printDec(rfid.uid.uidByte, rfid.uid.size);



    uidString = String(rfid.uid.uidByte[0])+" "+String(rfid.uid.uidByte[1])+" "+String(rfid.uid.uidByte[2])+ " "+String(rfid.uid.uidByte[3]);



    int i = 0;

    boolean match = true;

    while(i<rfid.uid.size)

    {

 

      if(!(int(rfid.uid.uidByte[i]) == int(code[i])))

      {

           match = false;

      }

      i++;

    }



    if(match)

    {

      Serial.println("\n*** Unlock ***");

 

    }else

    {

      Serial.println("\nUnknown Card");

    }

   Serial.println("============================");



    // Halt PICC

  rfid.PICC_HaltA();



  // Stop encryption on PCD

  rfid.PCD_StopCrypto1();

}



void printDec(byte *buffer, byte bufferSize) {

  for (byte i = 0; i < bufferSize; i++) {

    Serial.print(buffer[i] < 0x10 ? " 0" : " ");

    Serial.print(buffer[i], DEC);

  }

}

combie:
Wo ist da was unterschiedlich, gleich, oder anders?

Ich sehe da nur absichtlich verstümmeltes Zeugs, mit dem man nix mehr anfangen kann.
Schon gar nicht vergleichen.

Vermutlich unterscheidet sich nur die Darstellung.
Also untersuche die Darstellende.

Vielleicht verstehst du das momentan nicht. Aber noiasca hat das soweit schon ganz gut erkannt und verstanden.

Ich bitte um etwas Verständnis, dass ich nicht die kompletten IDs zeigen möchte, schließlich möchte ich die ja noch verwenden.

Die ersten 6 IDs sind auf den im Hauptpost enthaltenen Code zurückzuführen.

Die nachfolgenden 6 IDs darunter ergeben sind aufgrund des hier nachgereichten Codes.

Die Reihenfolge der abgerufenen RFID Chips ist natürlich gleich. Daher eigentlich egal was hinten im XXX Bereich steht. Es ging ja nehm ich mal an um die Anzahl der maximalen Stellen der ID oder?

Dann ergibt sich erstmal die Frage, welche der Code-Varianten ist für mein Vorhaben ausreichend bzw. auf welche kann/sollte ich am Besten mein Projekt aufbauen? Egal?

postmaster-ino:
Hi

Das Speichern der gültigen IDs macht durchaus Sinn, wenn man 'Mal eben' IDs hinzufügen oder entfernen will - wenn die Tochter den Chip im Schwimmbad hat liegen lassen.
Dann ist's einfacher (und schneller), die Türen abzugehen und die eine ID rauszuwerfen, als die Chips (pro Tür halt) neu aufzuspielen.

Wie die ID dabei gespeichert wird, ist eigentlich egal - Hauptsache, Du verkrüppelst die Information nicht, also nicht nur die letzten drei Ziffern der ID speichern, sondern die Ganze.

MfG

Na das die komplette ID gespeichert wird ist doch wohl klar. :smiley: Und um die grundsätzliche Frage, wie speicher ich das im EEPROM darum gehts mir. Aber soweit hab ich mich noch nicht vorgearbeitet das ich das schon beantworten könnte muss ich leider sagen.

um die grundsätzliche Frage, wie speicher ich das im EEPROM darum gehts mir. Aber soweit hab ich mich noch nicht vorgearbeitet das ich das schon beantworten könnte muss ich leider sagen.

Dafür gibt es EEPROM.put . Du musst "nur" die Datenstruktur kennen, die du speichern willst... (long code; ist es eventuell nicht).

Mit der EEPROM.put bin ich grade auch dran... die EEPROM memory specified life of 100,000 write/erase cycles sind ganz schön abschreckend. Wenn da irgendwas mal nicht richtig mit funktioniert schreibt der loop innerhalb kürzesterzeit den EEPROM tot? Ist das so? O.o

Wie kommst du darauf das es nicht long ist? Man kann doch unsigned long nehmen oder nicht?

Wenn da irgendwas mal nicht richtig mit funktioniert schreibt der loop innerhalb kürzesterzeit den EEPROM tot? Ist das so? O.o

Natürlich!
Steht doch da, und im Datenblatt.

Einfach mal ein wenig konzentrieren und mit Sorgfalt und Disziplin, die Sache angehen, dann klappt das schon!