Perché del codice scritto per un chip si rompe su un altro dello stesso tipo?
Perché il tipo di tag fissa i comandi, non la mappa di memoria. Due tag di tipo 2 rispondono allo stesso READ e mettono la loro configurazione in pagine diverse, e un indirizzo fissato nel codice che andava bene su uno finisce nella memoria utente dell'altro. Leggi invece quello che il tag dichiara.
Quello che il tipo fissa
Un tipo di tag del NFC Forum è un contratto sui comandi: quali un lettore può mandare, come si indirizza la memoria, come si trova un messaggio NDEF. La pagina del tipo 2 e la pagina del tipo 4 espongono quei due contratti.
Quello che non fissa è tutto ciò che un chip aggiunge: quante pagine esistano, dove viva la configurazione, se ci sia un contatore, un rispecchiamento o una password, e quali comandi in più rispondano. Quelli appartengono al chip, e questo sito li lascia alle schede tecniche dei chip, come fa la pagina della configurazione per le pagine che vengono dopo l'area dati.
Quello che il tag dichiara
La maggior parte di quello che serve al codice si legge invece di darsi per scontata. Su Android, Ndef risponde a tre domande senza toccare la radio: getType() rende il tipo del NFC Forum, getMaxSize() il messaggio più grande che il tag accetta, e isWritable() se prenda ancora una scrittura. MifareUltralight.getType() distingue un Ultralight da un Ultralight C, e rende sconosciuto quando non sa dirlo.
Più sotto, risponde il tag stesso. Il contenitore di capacità di un tag di tipo 2 dà la dimensione dell'area dati e la sua condizione di accesso, e Get System Information su un tag ISO/IEC 15693 dà la dimensione e il numero dei blocchi, cosa che la pagina della 15693 legge prima di ogni altra cosa. A un programma che interroga queste tre fonti resta ben poco da dare per scontato.
La stessa famiglia, due mappe
Il caso più chiaro è una sola famiglia. Un NTAG213 ha 45 pagine, i suoi byte di blocco dinamico nella pagina 40 e la sua configurazione nelle pagine da 41 a 44; un NTAG215 ha 135 pagine e tiene le stesse impostazioni nelle pagine da 130 a 134, come descrivono le loro schede tecniche su wakdev.com. La pagina 41 è configurazione su uno e memoria utente ordinaria sull'altro.
Il codice che scrive una configurazione per numero di pagina rovina quindi il contenuto sul chip sbagliato, in silenzio, e il tag continua a leggersi come se non fosse successo niente. Ed è per questo che la pagina della configurazione chiede che il chip venga identificato prima che la sequenza parta.
Prima leggere, poi scrivere
Rileva le funzioni invece dei modelli. Chiedi al tag cosa sia e cosa offra, adattati, e rifiuta di continuare quando la risposta non è una che il tuo codice conosce: un rifiuto esplicito è una segnalazione di difetto, una scrittura silenziosa è una serie rovinata.
E tieni un tag di ogni chip nell'insieme di prova, che la pagina dei tag da tenere chiede comunque. Un tag di una seconda dimensione nella stessa famiglia trova questa classe di difetti in un minuto, e niente altro la trova prima della produzione.
Domande frequenti
Il tipo di tag non basta a scrivere codice portabile?
Per l'NDEF sì. Per tutto quello che sta sotto no: pagine, dimensioni e indirizzi di configurazione appartengono al chip e non al tipo.
Cosa posso leggere invece di darlo per scontato?
Il tipo, la dimensione massima e la scrivibilità dalla piattaforma, il contenitore di capacità su un tag di tipo 2, e le informazioni di sistema su un tag ISO/IEC 15693.
Perché la mia scrittura di configurazione ha rovinato il contenuto?
Il numero di pagina apparteneva a un altro chip della stessa famiglia. Su un chip più grande quell'indirizzo è memoria utente.
Come lo colgo prima della produzione?
Tieni due chip dello stesso tipo e di dimensioni diverse nell'insieme di prova, e fai girare la sequenza su tutti e due.