Warum bricht Code für einen Chip auf einem anderen desselben Typs?
Weil der Tag-Typ die Befehle festlegt und nicht den Speicherplan. Zwei Type-2-Tags beantworten dasselbe READ und legen ihre Konfiguration auf verschiedenen Seiten ab, und eine fest eingetragene Adresse, die auf dem einen arbeitete, landet auf dem anderen im Nutzerspeicher. Lesen Sie stattdessen, was der Tag meldet.
Was der Typ festlegt
Ein Tag-Typ des NFC Forum ist eine Abmachung über Befehle: welche ein Lesegerät senden darf, wie der Speicher adressiert wird, wie eine NDEF-Nachricht gefunden wird. Die Seite zu Type 2 und die Seite zu Type 4 legen diese zwei Abmachungen dar.
Was er nicht festlegt, ist alles, was ein Chip hinzufügt: wie viele Seiten es gibt, wo die Konfiguration lebt, ob es einen Zähler, eine Spiegelung oder ein Passwort gibt, und welche zusätzlichen Befehle antworten. Die gehören dem Chip, und diese Website überlässt sie den Datenblättern der Chips, wie die Seite zur Konfiguration es für die Seiten nach dem Datenbereich tut.
Was der Tag meldet
Das meiste von dem, was Code braucht, ist lesbar statt annehmbar. Unter Android beantwortet Ndef drei Fragen, ohne den Funk zu berühren: getType() gibt den Tag-Typ des NFC Forum zurück, getMaxSize() die größte Nachricht, die der Tag annimmt, und isWritable(), ob er noch einen Schreibvorgang annimmt. MifareUltralight.getType() unterscheidet einen Ultralight von einem Ultralight C und gibt unbekannt zurück, wenn es das nicht kann.
Darunter antwortet der Tag selbst. Der Capability Container eines Type-2-Tags gibt die Größe des Datenbereichs und seine Zugriffsbedingung an, und Get System Information auf einem Tag nach ISO/IEC 15693 gibt die Blockgröße und die Blockzahl an, was die Seite zur 15693 vor allem anderen liest. Einem Programm, das diese drei Quellen fragt, bleibt sehr wenig anzunehmen.
Dieselbe Familie, zwei Pläne
Der deutlichste Fall ist eine einzige Familie. Ein NTAG213 hat 45 Seiten, seine beweglichen Sperrbytes auf Seite 40 und seine Konfiguration auf den Seiten 41 bis 44; ein NTAG215 hat 135 Seiten und hält dieselben Einstellungen auf den Seiten 130 bis 134, wie ihre Datenblätter auf wakdev.com beschreiben. Seite 41 ist auf dem einen Konfiguration und auf dem anderen gewöhnlicher Nutzerspeicher.
Code, der eine Konfiguration nach Seitennummer schreibt, beschädigt daher auf dem falschen Chip den Inhalt, lautlos, und der Tag liest sich weiter, als wäre nichts geschehen. Deshalb verlangt die Seite zur Konfiguration, dass der Chip erkannt wird, bevor die Abfolge läuft.
Erst lesen, dann schreiben
Erkennen Sie Merkmale statt Modelle. Fragen Sie den Tag, was er ist und was er anbietet, passen Sie sich an, und weigern Sie sich fortzufahren, wenn die Antwort keine ist, die Ihr Code kennt: Eine ausdrückliche Weigerung ist eine Fehlermeldung, ein lautloser Schreibvorgang eine beschädigte Charge.
Und behalten Sie einen Tag je Chip im Satz zum Testen, den die Seite zum Satz Tags ohnehin verlangt. Ein Tag einer zweiten Größe in derselben Familie findet diese Art von Fehler in einer Minute, und nichts sonst findet sie, bevor die Fertigung es tut.
Häufige Fragen
Genügt der Tag-Typ nicht für übertragbaren Code?
Für NDEF ja. Für alles darunter nein: Seiten, Größen und Adressen der Konfiguration gehören dem Chip und nicht dem Typ.
Was kann ich lesen, statt es anzunehmen?
Den Typ, die größte Größe und die Beschreibbarkeit von der Plattform, den Capability Container auf einem Type-2-Tag, und die Systemangaben auf einem Tag nach ISO/IEC 15693.
Warum hat mein Schreibvorgang der Konfiguration den Inhalt beschädigt?
Die Seitennummer gehörte zu einem anderen Chip derselben Familie. Auf einem größeren Chip ist diese Adresse Nutzerspeicher.
Wie fange ich das vor der Fertigung?
Behalten Sie zwei Chips desselben Typs mit verschiedenen Größen im Satz zum Testen, und fahren Sie die Abfolge auf beiden.