¿Cómo se leen los bloques de una etiqueta ISO/IEC 15693?

Cómo se construye una petición

Una petición ISO/IEC 15693 es un byte de marcas, un código de comando, y después parámetros. La referencia de NfcV pide al código de Android exactamente esas tres partes y añade ella misma el CRC. Core NFC construye la petición de cada comando normalizado y toma las marcas como un conjunto de opciones, NFCISO15693RequestFlag.

Cuatro marcas importan al leer, con los valores que les dan las definiciones del código abierto de la pila NFC de Android:

Sin la marca de dirección ni la de selección, todas las etiquetas del campo que reciben la petición la ejecutan, lo que es inofensivo con una etiqueta y ambiguo con dos. Core NFC pone la marca de dirección por omisión y envía el identificador de la etiqueta con el comando, y poner la marca de selección desactiva el direccionamiento, según la referencia de readSingleBlock.

El orden de bytes del identificador es donde se rompen los traslados. Apple da identifier en orden de mayor a menor, así que empieza por 0xE0, el byte con el que empieza todo identificador ISO/IEC 15693 según las definiciones de la pila de Android. Un código que construye una petición dirigida a mano, o que compara identificadores leídos en las dos plataformas, mira en qué extremo está el 0xE0 antes de usarlos.

Pregunta antes su tamaño a la etiqueta

Get System Information, 0x2B, devuelve un byte de marcas de información, el identificador, y después campos opcionales, entre ellos el tamaño de la memoria. Ese campo da el número de bloques y el tamaño del bloque, codificados los dos como uno menos que su valor, el tamaño del bloque en sus cinco bits más bajos; la pila de Android suma uno a cada uno antes de usarlos.

En iOS, getSystemInfo devuelve los valores ya descodificados, y desde iOS 14 systemInfo(requestFlags:) los devuelve como NFCISO15693SystemInfo, con blockSize y totalBlocks.

La respuesta cambia con el chip. La pila de Android trata bloques de 4, 8, 16 y 32 bytes, y un ICODE SLIX2 tiene 80 bloques de cuatro bytes, el último con un contador, según su ficha en wakdev.com. Algunos chips dejan fuera el tamaño de la memoria, y la pila de Android recurre entonces a tamaños que conoce para referencias concretas, una tabla que una aplicación tendría que llevar también.

Un bloque o varios

Read Single Block, 0x20, toma un número de bloque, de 0 a 255 en la forma normal, como declara la referencia de Apple. Read Multiple Blocks, 0x23, toma el primer bloque y una cuenta codificada como uno menos que el número de bloques, así que 0x00 lee un bloque.

Una etiqueta con más de 256 bloques necesita los comandos extendidos, cuyos números de bloque ocupan dos bytes: Extended Read Single Block es 0x30, de la especificación de la etiqueta de tipo 5 del NFC Forum según la referencia de extendedReadSingleBlock de Apple, y 0x33 lee varios.

Read Multiple Blocks es opcional. En una etiqueta formateada para NDEF, el bit 0 del cuarto byte del contenedor de capacidad, en el bloque 0, dice si la etiqueta admite el comando, y la pila de Android lee ese bit antes de usarlo. Sin él, lee un bloque cada vez.

Errores y comandos propios

Una etiqueta que rechaza una petición responde con el bit de error, 0x01, puesto en sus marcas de respuesta, seguido de un código de error: 0x03 para una opción que la etiqueta no admite, 0x13 para un bloque que no pudo escribir, entre los códigos que nombra la pila de Android. Core NFC declara una respuesta así como un error cuya información de usuario lleva NFCISO15693TagResponseErrorKey y el código de la norma.

Los códigos de comando 0xA0 a 0xDF son comandos propios, definidos por cada fabricante de chips. La referencia de customCommand de Apple inserta el código del fabricante detrás del byte de comando, y los comandos mismos, como los que gestionan las contraseñas de un chip, salen de la ficha de ese chip.