TODOPIC

Microcontroladores PIC => Lenguaje C para microcontroladores PIC => Mensaje iniciado por: RedPic en 08 de Diciembre de 2007, 12:06:05

Título: Decodificando el protocolo ABA Track 2
Publicado por: RedPic en 08 de Diciembre de 2007, 12:06:05
Decodificando el protocolo ABA Track 2
Un 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 (http://www.todopic.com.ar/foros/index.php?topic=19587.0) 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:

(http://picmania.garcia-cuervo.net/images/ABATK2_Cronograma.GIF)

   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 (http://www.todopic.com.ar/foros/index.php?topic=8109.0)) 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:

(http://picmania.garcia-cuervo.net/images/ABATK2_Cronograma_Con_Ceros_y_Unos.GIF)

 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:

(http://picmania.garcia-cuervo.net/images/DATA_CLOCK_Bits_leidos.jpg)
(Decodificación original realizada por Chaly (http://www.todopic.com.ar/foros/index.php?action=profile;u=459))

 Aquí tenemos toda una transmisión (real) de una serie de datos en Protocolo Serie Asíncrono ABA Track 2 que consiste en:


que podemos representar de esta forma:

(http://picmania.garcia-cuervo.net/images/ABATK2_Cronograma.JPG)

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:

Código: C++
  1. void Transmite_Bit_ABATK2(char c)
  2. {
  3.    // Data
  4.         if((c&0x01)==0){
  5.            output_high(OUT_DATA);
  6.    }
  7.         else{
  8.            output_low(OUT_DATA);
  9.    }
  10.    // Clock
  11.    delay_us(250);
  12.    output_low(OUT_CLOCK);
  13.    delay_us(250);
  14.    output_high(OUT_CLOCK);
  15. }
  16.  
  17. void Transmite_Byte_ABATK2(char c)
  18. {
  19.         int i;
  20.         char bt,paridad=0;
  21.  
  22.         for(i=0;i<4;i++)
  23.         {
  24.                 bt=(c>>i)&0x01;
  25.                 Transmite_Bit_ABATK2(bt);
  26.                 paridad+=bt;
  27.         }
  28.         bt=~(paridad&0x01);
  29.         Transmite_Bit_ABATK2(bt);
  30. }
  31.  
  32. void output_Code_ABATK2(void){
  33.  
  34.         int i;
  35.         char c,LCR=0x0B;
  36.  
  37.    // transmite cabecera de 10 ceros
  38.    for(i=0;i<10;i++) Transmite_Bit_ABATK2(0);
  39.    // identificador de TX pista2
  40.    Transmite_Byte_ABATK2(0x0B);
  41.    // bytes de code
  42.    for(i=0;i<nextCodeChar;i++)
  43.    {
  44.         c=(Code[i]-'0') & 0x0F;
  45.         LCR=LCR^c;
  46.         Transmite_Byte_ABATK2(c);
  47.    }
  48.    // identificador fin
  49.    Transmite_Byte_ABATK2(0x0F);
  50.    LCR=LCR^0x0F;
  51.    // transmite LCR
  52.    Transmite_Byte_ABATK2(LCR);
  53.    // transmite cola de 10 ceros
  54.    for(i=0;i<10;i++) Transmite_Bit_ABATK2(0);
  55. }



Y eso esto (por ahora)  :mrgreen: :mrgreen: :mrgreen:

Título: Re: Decodificando el protocolo ABA Track 2
Publicado por: Nocturno en 08 de Diciembre de 2007, 13:57:22
Aún recuerdo aquellos tiempos en los que, cuando aún creíamos en la magia, te asomabas por el foro preguntando por la codificación de esa ristra de bits  :mrgreen:
Título: Re: Decodificando el protocolo ABA Track 2
Publicado por: RedPic en 08 de Diciembre de 2007, 14:35:55
Muy cierto, amigo Nocturno. En esa época en la que las palabras ABA Track 2 no nos decían nada y solo teníamos las lista interminable de bits y una idea de que debían ir los datos en bloques de cinco bits. Por cierto debajo de la penúltima imagen, la de los bits y su decodificacion, aparecen los créditos de la misma: Que no puede ser otro que el gran Chaly29.

Así que al César lo que es del César, y lo que el Foro me dió, al Foro se lo devuelvo.  :mrgreen:

Título: Re: Decodificando el protocolo ABA Track 2
Publicado por: PalitroqueZ en 08 de Diciembre de 2007, 16:05:06
Eso se llama sacarle provecho a los equipos. asi es que amigo, saquele hasta la última función   :-/ :-/ :-/
Título: Re: Decodificando el protocolo ABA Track 2
Publicado por: elfrancho en 27 de Agosto de 2013, 04:16:21
Uffff cuanto tiempo pasó de este post.. pero que útil me fué esta info !!!

Amigos, estoy trabajando con un lector de tarjetas magnéticas y he encontrado que trabaja con el Protocolo ABA Track 2. !!!

Tengo unas preguntidas para hacerles !!!!

El lector tiene los siguientes pines:

- GND
- 5V
- Switch de tarjeta 1 (apenas introducimos la puntita de la tarjeta)
- Switch de tarjeta 2 (cuando la tarjeta llega al tope del lector)
- Clock
- Dato

Nunca he trabajado con conexiones sincrónicas y es por esto que no tengo idea de como configurar mi PIC 18F1320

Estoy casi seguro que debo utilizar SYNC_SLAVE dentro de #use_rs232.
También debería usar BITS=5 ?
Y debería usar PARITY=O ?
Usando SYNC_SLAVE funciona la interrupción int_rda ?

Alguien tiene un ejemplo de como sería la recepción de este protocolo ?  

Desde ya muchas gracias y espero haber sido claro....

SALUDOS !!! :-/