Wie liest man die Blöcke eines ISO/IEC-15693-Tags?

Wie eine Anfrage gebaut wird

Eine Anfrage nach ISO/IEC 15693 ist ein Flags-Byte, ein Befehlscode, dann Parameter. Die Referenz zu NfcV verlangt von Android-Code genau diese drei Teile und fügt den CRC selbst hinzu. Core NFC baut die Anfrage für jeden genormten Befehl und nimmt die Flags als Menge von Möglichkeiten, NFCISO15693RequestFlag.

Vier Flags zählen beim Lesen, mit den Werten, die ihnen die Festlegungen des quelloffenen NFC-Stacks von Android geben:

Ohne das Address- oder das Select-Flag führt jeder Tag im Feld die Anfrage aus, der sie empfängt, was bei einem Tag harmlos und bei zweien mehrdeutig ist. Core NFC setzt das Address-Flag voreingestellt und sendet die Kennung des Tags mit dem Befehl, und das Select-Flag zu setzen schaltet die Adressierung ab, so die Referenz zu readSingleBlock.

Die Byte-Reihenfolge der Kennung ist die Stelle, an der Portierungen brechen. Apple gibt identifier in der Reihenfolge Big-Endian, sie beginnt also mit 0xE0, dem Byte, mit dem laut den Festlegungen des Stacks von Android jede Kennung nach ISO/IEC 15693 beginnt. Code, der eine adressierte Anfrage von Hand baut oder auf beiden Plattformen gelesene Kennungen vergleicht, prüft vor der Benutzung, an welchem Ende das 0xE0 steht.

Fragen Sie den Tag zuerst nach seiner Größe

Get System Information, 0x2B, liefert ein Flags-Byte der Angaben, die Kennung, dann wahlfreie Felder, darunter die Speichergröße. Dieses Feld gibt die Zahl der Blöcke und die Blockgröße an, beide kodiert als eins weniger als ihr Wert, die Blockgröße in ihren untersten fünf Bits; der Stack von Android zählt zu jedem eins hinzu, bevor er sie benutzt.

Unter iOS gibt getSystemInfo die dekodierten Werte zurück, und ab iOS 14 gibt systemInfo(requestFlags:) sie als NFCISO15693SystemInfo zurück, mit blockSize und totalBlocks.

Die Antwort wechselt mit dem Chip. Der Stack von Android behandelt Blöcke zu 4, 8, 16 und 32 Bytes, und ein ICODE SLIX2 hat 80 Blöcke zu vier Bytes, deren letzter einen Zähler trägt, laut seinem Datenblatt auf wakdev.com. Manche Chips lassen die Speichergröße weg, und der Stack von Android greift dann auf Größen zurück, die er für bestimmte Bauteile kennt, eine Tabelle, die eine Anwendung ebenfalls halten müsste.

Ein Block oder mehrere

Read Single Block, 0x20, nimmt eine Blocknummer, von 0 bis 255 in der gewöhnlichen Form, wie Apples Referenz festhält. Read Multiple Blocks, 0x23, nimmt den ersten Block und eine Anzahl, kodiert als eins weniger als die Zahl der Blöcke, sodass 0x00 einen Block liest.

Ein Tag mit mehr als 256 Blöcken braucht die erweiterten Befehle, deren Blocknummern zwei Bytes nehmen: Extended Read Single Block ist 0x30, aus der Spezifikation zum Type-5-Tag des NFC Forum, so Apples Referenz zu extendedReadSingleBlock, und 0x33 liest mehrere.

Read Multiple Blocks ist wahlfrei. Auf einem für NDEF formatierten Tag sagt Bit 0 des vierten Bytes des Capability Container, in Block 0, ob der Tag den Befehl unterstützt, und der Stack von Android liest dieses Bit, bevor er den Befehl benutzt. Ohne das lesen Sie einen Block nach dem anderen.

Fehler und eigene Befehle

Ein Tag, der eine Anfrage verweigert, antwortet mit gesetztem Fehler-Bit, 0x01, in seinen Antwort-Flags, gefolgt von einem Fehlercode: 0x03 für eine Möglichkeit, die der Tag nicht unterstützt, 0x13 für einen Block, den er nicht beschreiben konnte, unter den Codes, die der Stack von Android benennt. Core NFC meldet eine solche Antwort als Fehler, dessen Angaben NFCISO15693TagResponseErrorKey und den Code aus der Norm tragen.

Die Befehlscodes 0xA0 bis 0xDF sind eigene Befehle, von jedem Chiphersteller festgelegt. Apples Referenz zu customCommand fügt den Herstellercode nach dem Befehlsbyte ein, und die Befehle selbst, etwa die, die die Passwörter eines Chips verwalten, stammen aus dem Datenblatt dieses Chips.