Decodificando el protocolo ABA Track 2Un protocolo usado desde que la electrónica era poco mas que magia.
Como complemento ideal a nuestro artículo anterior sobre los
Fundamentos de la Transmisión Síncrona qué mejor que un ejemplo real como la vida misma. Me propongo ahora que veamos juntos un protocolo, usado por las antiguas lectoras de tarjetas magnéticas, que lleva decenas de años en uso y aún hoy viene implementado en la gran mayoría de lectores de tarjetas modernas, Chip, Proximidad, Mifare ... etc como emulación de aquellas para mantener cierta compatibilidad entre los distintos dispositivos a los que están conectados.
Este protocolo
ABA Track 2 es un invento de la American Banking Association (de ahí lo de ABA) y todos y cada uno de sus detalles aparecen absolutamente descritos hasta su último detalle en la norma
ISO-7813.
No es nuestro propósito describir esta
ISO-7813 como si en ello nos fuese la vida, sino mas bien acercarnos a ella desde un punto de vista mucho mas práctico y útil para Picmaníacos de pro que lo único que desean es poder leer e interpretar uno de estos aparatos con protocolo ABA Track 2.
Empecemos pues manos a la obra y demos un primer vistazo a lo que se nos viene encima, y que no es mas que un "
cronograma". O sea una representación gráfica del estado de un par de líneas en función del tiempo:
Supongamos que tomamos las dos líneas de salida de un dispositivo que transmite en
ABA Track II y somos capaces de monitorizarlas en algún tipo de visualizador de líneas digitales (en mi caso he usado mi anterior proyecto
Analizador lógico) No es necesario pero para que veáis qué ocurre nos viene pero que muy bien.
Tened en cuenta que lo que describimos en el anterior artículo es únicamente el cómo se transmite la información, y no dijimos ni una sola palabra del qué se está transmitiendo, del significado de lo que se transmite ni de la interpretación que podíamos hacer de lo que recibimos de esa transmisión.
Un protocolo nos obliga a más cosas que al simple método a usar para ser capaces de recibir o emitir una información. Nos dice también qué se va a transmitir y qué significado tiene eso que es transmitido y/o recibido. Es lo que coloquialmente conocemos como "trama". La trama es lo que realmente aplicamos a lo recibido para obtener una interpretación válida de los datos. El protocolo pone de acuerdo al emisor y al receptor en todos y cada uno de los detalles para conseguir una completa, eficaz y coherente transmisión y recepción de los datos.
Con lo aprendido en el artículo sobre la Transmisión Síncrona podemos dar un paso más con solo interpretar nuestro cronograma anterior.
En aquél veíamos cómo una línea de reloj (
CLOCK) nos indicaba cuando debíamos mirar, sensar, catar, leer la otra línea, la de datos (
DATA). De manera tal que al recibir un pulso del CLOCK si la línea DATA estaba en alto, a nivel de VCC, lo interpretábamos como que habíamos recibido un bit 0, y si por el contrario la línea DATA estaba en bajo, a nivel de GND, lo leíamos como un bit 1.
Con esta simple norma íbamos recibiendo toda un ristra de bits, uno a uno sobre la línea de
DATA, y cada uno de ellos al golpe de batuta de nuestra línea de
CLOCK.
Con lo cuál estamos en disposición de añadir a nuestro cronograma la interpretación en Bits de lo que significa:
Quedémonos por ahora con los quince primeros bits recibidos:
000001101000001.
¿Significan algo? Es difícil de decidir con la sola vista de esos bits. Podríamos intentar decidir si se ajustan a los patrones de la tabla ASCII, pero parece complicado ya que no son divisibles por 8, que son los bits que tiene un byte y que la tabla ASCII nos dice qué significan, o si por el contrario los dividimos en bloques de 4 bits ... o de cinco ... o ... Así que vamos a concluir que: ¡No! No significan nada salvo que digamos mas cosas.
Y entonces viene en nuestro salvamento el Séptimo de Caballería, que a nuestros efectos es nuestro viejo amigo el
Protocolo ABA Track II, y que dice en primer lugar, como Dios hablándole a Moisés con voz profunda y sentenciosa cu Primer Mandamiento:
Primero recibirás un montón de ceros, de cinco a quince, pero no más ... ni menos. Ni cuatro, ni tres, ni dos, ni uno, sino cinco o mas.
¡Hombre! y vemos que en verdad así ocurre en nuestra ristra de bits, primero nos llegan un montón de ceros (originalmente venían quince pero los he dejado en cinco, editando la imagen del cronograma y dejándolos en cinco hasta que no inventen una pantallas realmente panorámicas, simplemente no caben a lo ancho).
Y sigue nuestro ABA Track 2 con su segundo mandamiento: A continuación
cada Byte de información llegará con cinco bits, los
cuatro primeros definen el
dato a enviar y el
quinto es la
paridad. Que porque me da la gana va a ver
Impar. El Primer bit de los cinco es el Menos Significativo.
¡Ea! pues ya tenemos un poco mas de información y podemos empezar a intentar descifrar la "trama". A partir del primer 1 que encontremos vamos a dividir nuestro "churrete" de bits en bloques de 5, de los cuales los 4 primeros son "el dato" y el quinto se calcula en función de los anteriores.
Troceando, que es gerundio, tomamos nuestro afilado cuchillo ritual y nos quedan dos pequeños bloques:
11010 y
00001 .... y ya sabemos que ambos son "datos+paridad_impar" Luego el primero vamos a escribirlo en la forma
1101-0 y el segundo como
0000-1.
Como hemos visto el -0 del primero y el -1 del segundo nos dicen que es la Paridad Impar. Esto significa que nos sirve para ajustar en cada bloque de 5 bits el número de unos que aparecen en él, y que por definición debe ser un número impar. Así 1101 son tres bits a 1, que es número impar donde los haya, por lo que el bit de paridad impar debe ser 0 para que no se nos convierta en par, por manos del demonio. Y el segundo dato recibido es 0000 que no tiene ningún 1 y por ello debemos poner el bit de paridad a 1 para que en ese bloque también haya un número impar de unos.
Y ahora otro palito mas a la burra. San ABA TKII, santo virgen y mártir, nos dijo que los primeros serán los últimos en el Reyno de los Bytes, así que tenemos la obligación de darle la vuelta a los Bits recibidos y ponerlos como dios manda
1101 es en verdad
1011, o escrito en hexadecimal resulta que es el número '
Bh', y que el 0000 es 0000, o sea el hexadecimal '
0h', como no podía ser de otra forma.
Resumiendo: Recibimos un montón de
ceros, recibimos el dato '
Bh', recibimos el dato '
0h' ...
Y continúa esta feria de vanidades. El ABA Track 2 nos dice muchas mas cosas. Sus mandamientos no acaban en los dos primeros sino que se añaden por lo menos cuatro mas a la lista.
Tercer mandamiento:
Tras la recepción del dato '
Bh', recuerda que era 11010 en binario sin darle la vuelta como un calcetín, Recibirás
mas datos en la misma forma que los anteriores, hasta un máximo de 79, pero que pueden ser 78 ó 77 ó 76 ... o ... ¡Yá!
Tras el tercero ha de venir un Cuarto Mandamiento:
Los datos se acaban del todo cuando recibas un dato 'Fh', o sea una tira de bits de la forma 11111 (Nota que son 4 unos, número par de unos, por lo que la paridad debe ser también un 1 para que sean 5 unos, impar y no violemos la paridad impar)
Con esto ya podríamos leer todos los datos completos de una transmisión ABA Track II pero ... San ABA es persona quisquillosa y metódica que quiere dejar todo atado y bien atado. Y como no podemos tener un pez sin cola, ni una vaca sin rabo, ni un hombre sin ... ¡vamos a dejarlo aquí, haya paz hermanos!
Nuestro amantísimo protocolo nos dice que tras enviarnos el 'Fh' aún nos ha de enviar una dato más para que seamos capaces de saber si todo lo anterior que nos envió es correcto o no. Para ello nos envía un dato especial (especial pero no tanto, son cuatro bits mas paridad también) que no es cualquiera sino el resultado de calcular los sucesivos
OR EXCLUSIVOS de todos los anteriores que nos ha enviado, empezando por el 'Bh' y terminando por el 'Fh'. A esto se les ocurre llamarlo el
LRC o sea el
Longitudinal Redundancy Chek o Comprobación Longitudinal Redundante o Redundancia de la Comprobación Longitudinal o .... ¡Yá!
Y como no, por último, como traca final fin de fiesta, como estertor de una celebración de altura, otro sano, largo y completo
montón de ceros final, diciendo hasta aquí hemos llegado, amigos.
O sea esto:
(Decodificación original realizada por
Chaly)
Aquí tenemos toda una transmisión (real) de una serie de datos en Protocolo Serie Asíncrono ABA Track 2 que consiste en:
- * Una serie de 10 ceros.
- * Start Character 'Bh' también conocido como "Sentinel"
- * Los datos 0321215679127
- * End Character 'Fh'
- * LRC o dato calculado para comprobar transmisión
- * Otra serie de 9 ceros.
que podemos representar de esta forma:
Y para que la inclusión de este pequeño artículo en el Foro de C para Microcontroladores tenga todos los aditamentos necesarios no puede faltar su código en CCS C.
Aquí tenéis las tres funciones necesarias para una correcta transmisión Data & Clock ABA Track 2:
void Transmite_Bit_ABATK2(char c)
{
// Data
if((c&0x01)==0){
output_high(OUT_DATA);
}
else{
output_low(OUT_DATA);
}
// Clock
delay_us(250);
output_low(OUT_CLOCK);
delay_us(250);
output_high(OUT_CLOCK);
}
void Transmite_Byte_ABATK2(char c)
{
int i;
char bt,paridad=0;
for(i=0;i<4;i++)
{
bt=(c>>i)&0x01;
Transmite_Bit_ABATK2(bt);
paridad+=bt;
}
bt=~(paridad&0x01);
Transmite_Bit_ABATK2(bt);
}
void output_Code_ABATK2(void){
int i;
char c,LCR=0x0B;
// transmite cabecera de 10 ceros
for(i=0;i<10;i++) Transmite_Bit_ABATK2(0);
// identificador de TX pista2
Transmite_Byte_ABATK2(0x0B);
// bytes de code
for(i=0;i<nextCodeChar;i++)
{
c=(Code[i]-'0') & 0x0F;
LCR=LCR^c;
Transmite_Byte_ABATK2(c);
}
// identificador fin
Transmite_Byte_ABATK2(0x0F);
LCR=LCR^0x0F;
// transmite LCR
Transmite_Byte_ABATK2(LCR);
// transmite cola de 10 ceros
for(i=0;i<10;i++) Transmite_Bit_ABATK2(0);
}
Y eso esto (por ahora)
