Ich Interpretiere die Code Variante1 von oben nach etwas lesen jetzt so, dass durch Berechnung der Bytes eine Nummer generiert wird, die der größenordnung einer long variablen entspricht. Die wird jedenfalls im Code ja auch verwendet.
Ob das auf alle nutzbaren RFIDs die es so gibt zutrifft keine Ahnung, aber meine IDs müssten damit abgedeckt sein denn der höchste den ich habe hat den Wert 2526951. Mit unsigned long könnt mans ja auch verlängern.
Variante 1 finde ich einen Schmarren. Da kommen Werte im Bereich 0..255 (weil Byte) und dann wird mit 10 Multipliziert um bevor die nächste Stelle hinzu kommt.
Behandle einfach die 4 Bytes so wie es Variante 2 tut
bau dir in ein uint32_t (4byte) die 4 Byte zusammen und speichere das ganze mit EEPROM.put.
nur so als Idee, geht schöner, funktioniert aber auch:
uint32_t cardid = uid[0];
cardid <<= 8;
cardid |= uid[1];
cardid <<= 8;
cardid |= uid[2];
cardid <<= 8;
cardid |= uid[3];
Und ich frage mich:
Warum überhaupt verwursten?
Die Daten liegen doch in einem Array vor.
Werden die irgendwie schöner, vom konvertieren, oder besser, reicher, jünger?
Vielleicht verstehst du das momentan nicht.
Das kann natürlich sein!
Ja, ich bin offensichtlich manchmal zu blöd um jede Verrücktheit zu kapieren.
Muss ich ja auch nicht.
Finde ich noch nicht mal sonderlich schade.
ist einfacher für Anfänger zu verdauen, combie.
sonst kannst dich gleich auf die Frage vorbereiten, wie man arrays vergleicht...
Nö, ist nicht einfacher. Das wird einfach kopiert und fertig.
Dann wird halt erklärt, wie man Arrays vergleicht.
Gruß Tommy
ist einfacher für Anfänger zu verdauen, combie.
sonst kannst dich gleich auf die Frage vorbereiten, wie man arrays vergleicht...
Einerseits hört sich das wie eine Drohung an.
Diese ist aber leicht auszuhebeln:
memcmp()
Andererseits, halte ich es für ***** Anfängern erst komplizierte Umwege aufzudrücken, mit der Begründung, dass diese die einfachen schnellen Wege nicht verstehen werden.
Ich wusste nicht was ich statt ***** einsetzen sollte.
:o Such dir selber was aus... :o
Bedenke:
Lernen ist, stetig das Neue anzunehmen.
Die Balance am Rand der Überforderung.
Wir lernen, in dem wir es tun.
Beispiel:
Du darfst erst lernen Fahrrad zu fahren, wenn du Fahrrad fahren kannst.
(das wird doch keiner)
In Wirklichkeit dauert es Jahre der Übung, bis aus den ersten wackeligen Versuchen eine sichere Bewegung im Straßenverkehr wird. Radrennprofi? Jahrzehnte.
Aber ohne den ersten Schritt, das langsame Vorwärtswackeln, geht nix.
Und die stete Übung, macht dann den Meister.
In diesem konkreten Fall, scheint es zwei verschiedene Methoden zu geben, das Array zu einer Zahl zu konvertieren...
Ich frage mich: Wozu?
Welcher Sinn steckt dahinter?
Falls da keiner hintersteckt, dann lässt man es doch besser.
Einfach sowas zu übernehmen, nur weil es ein anderer nicht besser wusste, oder ganz andere Anforderungen hat, ist aus meiner Sicht nicht besonders klug.
Aber ok...
Auch hier: Des Menschen Wille, ist sein Himmelreich!
Und es bin nicht ich, der hier die Entscheidungen treffen muss.
Übrigens, bei der MFRC522 Lib, bei mir auf dem Rechner ist ein Authentifizierungsbeispiel dabei.
Incl. Vergleiche und Daten im EEPROM
Finde ich auch nicht schön gelöst, aber immerhin ein klares und deutliches Beispiel mit Erklärungen
Wie vergleicht man denn Arrays? 
Ich frage mich generell warum diese beiden Tutorialbeispiele so unterschiedlich aufgebaut sind. Ich meine, in irgendeiner weise funktionieren tun sie ja beide. In Variante 1 wird immer die selbe Nummer angezeigt, sobald der Chip drangehalten wird.
Verstehe nur nicht warum das in Variante 2 so anders ist und wo zwischen beiden Vor und Nachteil sind.
noiasca:
Variante 1 finde ich einen Schmarren. Da kommen Werte im Bereich 0..255 (weil Byte) und dann wird mit 10 Multipliziert um bevor die nächste Stelle hinzu kommt.Behandle einfach die 4 Bytes so wie es Variante 2 tut
bau dir in ein uint32_t (4byte) die 4 Byte zusammen und speichere das ganze mit EEPROM.put.
nur so als Idee, geht schöner, funktioniert aber auch:
uint32_t cardid = uid[0];
cardid <<= 8;
cardid |= uid[1];
cardid <<= 8;
cardid |= uid[2];
cardid <<= 8;
cardid |= uid[3];
Mir ist aufgefallen, das ich momentan noch nicht verstehe, wie und was da genau passiert und das fuchst mich son bisschen. Diese byte Geschichte ist mir noch ein bisschen unklar...
4 byte = 32 bit hab ich grade gegoogled, war mir auch nicht so klar...
Verstehe ich den Codeabschnitt hier richtig?
uidString = String(rfid.uid.uidByte[0])+" "+String(rfid.uid.uidByte[1])+" "+String(rfid.uid.uidByte[2])+ " "+String(rfid.uid.uidByte[3]);
Hier wird jeder byte ausgelesen? 0, 1, 2, 3 = 4 byte?
Jeder byte kann einen Wert von 0-255 aufweisen?
So kommt z.B. zusammengesetzt eine Zahl raus von 45, 125, 85, 50 und das ergibt sozusagen dann die ID?
Funktioniert das so wie ich es verstehe? Oder interpretier ich das falsch?
Mit deinem Code muss ich gleich auch nochmal genau gucken wie und an welcher stelle du das angedacht hattest...
So kommt z.B. zusammengesetzt eine Zahl raus von 45, 125, 85, 50 und das ergibt sozusagen dann die ID?
Es werden Text-Schnipsel zusammengesetzt, sonst ja.
Arrays kann man Element-weise vergleichen oder mit memcmp.
Dein Beispiel 1 kann 101010*256 = 256000 Tags unterscheiden. Manche verschiedene Tags könnten theoretisch die gleiche ID haben. Der Code wird in einem long gespeichert, in dem man auch die komplette ID speichern könnte. (Wie noiasca vorschlägt)
Die UID liefert bei dir offenbar 4 Bytes.
1 Byte kann wie du erkannt hast Werte von 0..255 aufnehmen
Hast du ein Array mit 4 Bytes, dann kannst das mit einem anderen Array vergleichen. Lies dazu noch mal ganz genau Post 25, combie hat versucht es dir zu erklären.
Oder du stopfst diese 4 Bytes eben in eine Variable die 4 byte groß ist, z.B. ein uint32_t ... (4 Byte --> 32 bit daher).
Wenn du vor einem Windows-PC sitzt dann rate ich dir mal den calc.exe zu starten und mit den unterschiedlichen Darstellungsformen hex, dec, binär rumzuspielen, damit du mehr Sicherheit mit deren Umgang bekommst.
der Codeschnippsel
uidString = String(rfid.uid.uidByte[0])+" "+String(rfid.uid.uidByte[1])+" "+String(rfid.uid.uidByte[2])+ " "+String(rfid.uid.uidByte[3]);
macht ein Arduino-String Objekt aus den 4 Bytes und fügt auch noch blanks ein. Für die lesbare Ausgabe ok, aber zum weiterverwenden imho eine schlechte weil resourcenfressende Variante.
uidString = String(rfid.uid.uidByte[0])+" "+String(rfid.uid.uidByte[1])+" "+String(rfid.uid.uidByte[2])+ " "+String(rfid.uid.uidByte[3]);
Da sieht man schon dran, dass da jemand was ganz wichtiges nicht verstanden hat.
Oder ihm die Systemlast am Arsch vorbei geht.
Macht das gleiche, nur erheblich sparsamer:
uidString = String(rfid.uid.uidByte[0])+" "+rfid.uid.uidByte[1]+" "+rfid.uid.uidByte[2]+" "+rfid.uid.uidByte[3];
Die Konvertierung in ein String Objekt, ist wohl die teuerste vorstellbare, und dann auch gleich 4 mal, wo doch einmal ausreichen würde.
Schön, dass es die String Klasse gibt.
Aber man kann sie auch gut und gerne links liegen lassen, da wo es keine Notwendigkeit gibt.
Denn die unerwünschten Seiteneffekte können einem derbe Streiche spielen. (z.B. Speicher Fragmentierung)
Puuuuuuuuh...
Ich habe mir jetzt das AccessControl Beispiel angesehen. Ein guter Tipp übrigens, hab ich nicht gesehen das es dafür Beispiele gibt.
Aber ganz ehrlich, da kack ich total ab. Trotz Erklärungen sind soviele Elemente oder auch Schleifen drin, mit denen ich nicht genug vertraut bin, das ich fast denk es besser sein zu lassen.
Ich versteh ja nichtmal richtig die Funktionsweise der For schleifen auf das Beispiel bezogen.
Ich brauch anscheinend einfach nen anständigen C++ Kurs um das mal richtig machen zu können.
Da gibt es auch Bücher, z.B. Der C++.Programmierer
Gruß Tommy
Ach bei Büchern ist das immer so blöd das konkrete Beispiele nur schwer ausprobiert werden können, weil z.B. der Code entweder mühsam abgetippt werden muss, oder teilweise je nach alter mitterlweile einfacher programmiert wird etc... Da hab ich damals schon beim Raspberry das Handtuch geworfen...
Ich beschäftige mich mit den letzten Posts noch ein wenig vielleicht bekomm ich ja doch noch was hin.
Ach bei Büchern ist das immer so blöd das konkrete Beispiele nur schwer ausprobiert werden können, weil z.B. der Code entweder mühsam abgetippt werden muss, oder teilweise je nach alter mitterlweile einfacher programmiert wird etc...
Wer will, findet Wege.
Wer nicht will, Gründe.
Das machts natürlich schwer, wenn man die Sprachgrundlagen ausblendet....
Eigentlich sollte man das Werkzeug schon kennen, was man da benutzt.
Das blinde stochern im Nebel, ist auf Dauer meist recht frustrierend.
Die Beispiele zum Buch gibts online. Aber wie combie schon sagt ... .
Ich bin mit diesem Buch sehr zufrieden.
Gruß Tommy
mrzortrax:
Puuuuuuuuh...Trotz Erklärungen sind soviele Elemente oder auch Schleifen drin, mit denen ich nicht genug vertraut bin, das ich fast denk es besser sein zu lassen.
Ich versteh ja nichtmal richtig die Funktionsweise der For schleifen auf das Beispiel bezogen.
Ich brauch anscheinend einfach nen anständigen C++ Kurs um das mal richtig machen zu können.
Nunja, das kann man alles lernen. Es sein zu lassen führt jedenfalls absolut nicht zum Ziel.
Ich bin zurzeit selber dabei, mit nem RFID-System was aufzubauen. Bei mir hab ich eine bestimmte Anzahl Karten in nem Array drin, deren UIDs im Programmcode schon fix drin sind. Dazu können dann aber auch noch zusätzliche Karten, ebenfalls mithilfe einer Mastercard hinzugefügt werden. oder bestehende karten auch gesperrt werden. Die neuen Karten sowie evt. Sperrvermerke werden im EEprom hinterlegt und dann beim Programmstart, oder nach Änderungen / Neueintrag jeweils ins bestehende Array das die Karten verwaltet, eingelesen.
Leider kann ich Dir meinen Code nicht, oder besser gesagt noch nicht zur Verfügung stellen, da besonders die Funktionen, die sich mit dem Sperren/Hinzufügen von Karten befassen noch nicht getestet sind. Ich komme momentan leider auch nicht zum Testen, da ich zuzeit mit der Hardware des betreffenden Projektes beschäftigt bin. Die RFID-Geschichte ist da nur ein Teil des gesamten Projektes. Da ist noch einiges an Elektronik und an CNC-Fräsarbeiten, die mich zurzeit beschäftigen.
LG Stefan
Deltaflyer:
Nunja, das kann man alles lernen. Es sein zu lassen führt jedenfalls absolut nicht zum Ziel.Ich bin zurzeit selber dabei, mit nem RFID-System was aufzubauen. Bei mir hab ich eine bestimmte Anzahl Karten in nem Array drin, deren UIDs im Programmcode schon fix drin sind. Dazu können dann aber auch noch zusätzliche Karten, ebenfalls mithilfe einer Mastercard hinzugefügt werden. oder bestehende karten auch gesperrt werden. Die neuen Karten sowie evt. Sperrvermerke werden im EEprom hinterlegt und dann beim Programmstart, oder nach Änderungen / Neueintrag jeweils ins bestehende Array das die Karten verwaltet, eingelesen.
Leider kann ich Dir meinen Code nicht, oder besser gesagt noch nicht zur Verfügung stellen, da besonders die Funktionen, die sich mit dem Sperren/Hinzufügen von Karten befassen noch nicht getestet sind. Ich komme momentan leider auch nicht zum Testen, da ich zuzeit mit der Hardware des betreffenden Projektes beschäftigt bin. Die RFID-Geschichte ist da nur ein Teil des gesamten Projektes. Da ist noch einiges an Elektronik und an CNC-Fräsarbeiten, die mich zurzeit beschäftigen.LG Stefan
Ja sicher, genau so versuche ich es ja, learning by doing. Aber hier scheitert es sozusagen ja bereits daran, das offensichlich 2 Tutorial Codes, die solches Know How vermitteln sollen, nicht optimal gelöst sind.
Ich könnte dir wenn du 3D gedruckte ABS teile benötigst unter die Arme greifen.
Vielleicht sollt ich mir doch mal das Buch ansehen.
Ja sicher, genau so versuche ich es ja, learning by doing. Aber hier scheitert es sozusagen ja bereits daran, das offensichlich 2 Tutorial Codes, die solches Know How vermitteln sollen, nicht optimal gelöst sind.
Das siehst du falsch!
Beide Tutorials machen das aus einem ganz bestimmten Grund so, wie sie es tun.
Warum weiß ich nicht.
Und du offensichtlich auch nicht.
Aber nur weil sie nicht das tun, was dir hilft, sind doch nicht die Tutorials falsch, oder falsch gelöst.
Ja sicher, genau so versuche ich es ja, learning by doing.
"learning by doing" hat schon was. Ist wichtig.
Aber die Grundregeln lernt man so nicht.
Ist ein bisschen wie in der Fahrschule.
Erst die Theorie, dann erst auf die Straße.
Mein Vorschlag:
Etwas lesen, dann ein Dutzend Experimente zu dem Thema.
Dann wieder ein paar Seiten lesen, und das Interessante ausprobieren.
Hallo mrzortrax,
danke für Dein Angebot wegen der 3D-Teile. Ich habe jedoch bereits alle Zeichnungen und Fräsdateien fertig, so dass ich mich nur noch an die CNC-Fräse setzen und an meine Drehbank stellen muss, um diese Teile fertigzustellen.
Momentan benötige ich da also keine Hilfe mehr. Mit programieren mache ich gegen Ende April weiter, so nichts meinen Zeitplan durcheinander bringt.
LG Stefan
Deltaflyer:
Hallo mrzortrax,
danke für Dein Angebot wegen der 3D-Teile. Ich habe jedoch bereits alle Zeichnungen und Fräsdateien fertig, so dass ich mich nur noch an die CNC-Fräse setzen und an meine Drehbank stellen muss, um diese Teile fertigzustellen.Momentan benötige ich da also keine Hilfe mehr. Mit programieren mache ich gegen Ende April weiter, so nichts meinen Zeitplan durcheinander bringt.
LG Stefan
Gern geschehen. Eine CNC Fräse fehlt mir auch noch, xD nächstes großes Projekt was irgendwann kommt... mal sehn.
Tommy56:
Da gibt es auch Bücher, z.B. Der C++.ProgrammiererGruß Tommy
Hm ich hab mir jetzt mal besagtes Buch als E-Book besorgt. Soll ja auch für Menschen ohne Programmiererfahrung gedacht sein. Die ersten Seiten waren ja gut erklärt, aber ein Stück weiter, wo die Variablen erklärt werden und es nur noch um Bits und Bytes geht, wird ja schon mit sehr speziellen Rechenoperationen um sich geworfen wo ich mir denke, wer oder wofür braucht man das?
Ansich ist das Buch bestimmt recht gut, wenn man direkt alles daraus können muss.
Vielleicht kann ich zwischenzeitlich die Frage Stellen, mit welcher Möglichkeit ich ein zweites RFID Modul an meinen Nano anschließen kann, ohne zuviele PINS zu verbrauchen. Ich hab alles momentan an einem Steckboard und versucht ein zweites einfach parallel genau gleich anzuschließen, scheint aber so allein nicht zu funktionieren...
Hat sowas jemand schonmal gemacht? Geht das überhaupt? Laut Scatch wird dort nur Pin 9 und Pin 10 definiert. Der Rest scheint über die Bib vorbelegt zu sein. Heißt das im Umkehrschluss ich muss die Bib Kopieren und anpassen um ein zweites Modul zu verwenden?