Come si leggono i blocchi di un tag ISO/IEC 15693?

Com'è costruita una richiesta

Una richiesta ISO/IEC 15693 è un byte di contrassegni, un codice di comando, poi i parametri. Il riferimento di NfcV chiede al codice Android esattamente queste tre parti e aggiunge da sé il CRC. Core NFC costruisce la richiesta per ciascun comando normalizzato e prende i contrassegni come un insieme di opzioni, NFCISO15693RequestFlag.

Quattro contrassegni contano per la lettura, con i valori che danno loro le definizioni della pila NFC libera di Android:

Senza il contrassegno di indirizzo o di selezione, ogni tag nel campo che riceve la richiesta la esegue, cosa innocua con un tag e ambigua con due. Core NFC mette il contrassegno di indirizzo per impostazione predefinita e invia l'identificatore del tag con il comando, e mettere il contrassegno di selezione spegne l'indirizzamento, secondo il riferimento di readSingleBlock.

L'ordine dei byte dell'identificatore è dove si rompe il codice portato da una piattaforma all'altra. Apple dà identifier in ordine big endian, quindi comincia con 0xE0, il byte con cui comincia ogni identificatore ISO/IEC 15693 secondo le definizioni della pila di Android. Il codice che costruisce a mano una richiesta indirizzata, o confronta identificatori letti sulle due piattaforme, verifica da che parte sta lo 0xE0 prima di usarli.

Chiedi prima al tag la sua dimensione

Get System Information, 0x2B, rende un byte di contrassegni di informazione, l'identificatore, poi campi facoltativi, fra cui la dimensione della memoria. Quel campo dà il numero dei blocchi e la dimensione di un blocco, codificati tutti e due come uno in meno del loro valore, la dimensione del blocco nei suoi cinque bit più bassi; la pila di Android aggiunge uno a ciascuno prima di usarli.

Su iOS, getSystemInfo rende i valori decodificati, e da iOS 14 systemInfo(requestFlags:) li rende come NFCISO15693SystemInfo, con blockSize e totalBlocks.

La risposta cambia con il chip. La pila di Android tratta blocchi di 4, 8, 16 e 32 byte, e un ICODE SLIX2 ha 80 blocchi di quattro byte, l'ultimo dei quali porta un contatore, secondo la sua scheda su wakdev.com. Certi chip lasciano fuori la dimensione della memoria, e la pila di Android ripiega allora sulle dimensioni che conosce per riferimenti precisi, una tabella che anche un'applicazione dovrebbe tenere.

Un blocco o diversi

Read Single Block, 0x20, prende un numero di blocco, da 0 a 255 nella forma normale, come dichiara il riferimento di Apple. Read Multiple Blocks, 0x23, prende il primo blocco e un conto codificato come uno in meno del numero dei blocchi, quindi 0x00 legge un blocco.

Un tag con più di 256 blocchi vuole i comandi estesi, i cui numeri di blocco prendono due byte: Extended Read Single Block è 0x30, dalla specifica Type 5 Tag del NFC Forum secondo il riferimento di extendedReadSingleBlock di Apple, e 0x33 ne legge diversi.

Read Multiple Blocks è facoltativo. Su un tag formattato per il NDEF, il bit 0 del quarto byte del contenitore di capacità, nel blocco 0, dice se il tag lo sostiene, e la pila di Android legge quel bit prima di usare il comando. Senza di esso, leggi un blocco alla volta.

Errori e comandi propri

Un tag che rifiuta una richiesta risponde con il bit di errore, 0x01, acceso nei suoi contrassegni di risposta, seguito da un codice di errore: 0x03 per un'opzione che il tag non sostiene, 0x13 per un blocco che non è riuscito a scrivere, fra i codici che la pila di Android nomina. Core NFC segnala una risposta del genere come un errore le cui informazioni portano NFCISO15693TagResponseErrorKey e il codice della norma.

I codici di comando da 0xA0 a 0xDF sono comandi propri, definiti da ciascun costruttore di chip. Il riferimento di customCommand di Apple inserisce il codice del costruttore dopo il byte del comando, e i comandi stessi, come quelli che gestiscono le password di un chip, vengono dalla scheda di quel chip.