FUNDAMENTOS de la TRANSMISIÓN SÍNCRONA

• Fundamentos de la Transmisión Síncrona
  Una visión general de qué es, para qué sirve y cómo se utiliza.

• Decodificando el protocolo ABA Track 2
  Un protocolo usado desde que la electrónica era poco mas que magia.

   Para intentar acercarnos de forma clara a qué es una transmisión Síncrona voy a utilizar mi habitual forma indirecta de atacar las cosas y vamos a empezar por su antagonista por naturaleza: la transmisión Asíncrona.
 

   Primero démosle un vistazo a su propio nombre y veamos qué significa esa palabreja de Asíncrona. Etimológicamente significa exactamente "sin reloj" o sea que no hay ninguna señal que marque los tiempos en que los datos deben leerse o están disponibles.
 

   Las funciones para Transmitir de forma Síncrona que vamos a implementar son dos: Transmite_Bit_Clock_and_Data y Transmite_Byte_Clock_and_Data. La primera de ellas coloca el estado de un bit en la línea Data y genera un pulso en Clock, la segunda se encarga de extraer, bit a bit, el contenido de un byte (de 8 bits) y llamar a la función anterior.

   Para las funciones de recepción Síncrona vamos a usar el recurso de la Interrupción Externa de los PIC's, eligiendo estratégicamente el PIN del reloj (CLOCK) de forma que tengamos disponible una de estas interrupciones.
 

   La interrupción externa la configuramos para detectar los flancos de bajada (ved la nota anterior sobre la "lógica negativa") De esta forma cada vez que se dispara la interrupción sabemos que tenemos disponible un bit en la línea de los datos (DATA). Lo recogemos sobre nuestro recByte y contamos uno más. Cuando lleguemos a 8 bits recogidos tenemos nuestro Byte completo y podemos indicarlo convenientemente poniendo a uno el flag reccomplete.
 

   Cuando en main detectamos este reccomplete lo monitorizamos por el puerto serie y reiniciamos todo para recoger el siguiente byte.

   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 RR Logical Analyzer) No es necesario pero para que veáis qué ocurre nos viene pero que muy bien.
 

    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.
 

   ¿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.
 

   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á!
 

• 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.

void Transmite_Bit_Clock_and_Data(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_Clock_and_Data(char c){

  int i;
  char bt,paridad=0;

  for(i=0;i<4;i++){
    bt=(c>>i)&0x01;
    Transmite_Bit_Clock_and_Data(bt);
    paridad+=bt;
  }
  bt=~(paridad&0x01);
  Transmite_Bit_Clock_and_Data(bt);
}

void output_Code_clock_and_data(void){

  int i;
  char c,LCR=0x0B;

  // transmite cabecera de 15 ceros
  for(i=0;i<15;i++) Transmite_Bit_Clock_and_Data(0);
  // identificador de TX pista2
  Transmite_Byte_Clock_and_Data(0x0B);
  // bytes de code
  for(i=0;i<nextCodeChar;i++){
    c=(Code[i]-'0') & 0x0F;
    LCR=LCR^c;
    Transmite_Byte_Clock_and_Data(c);
  }
  // identificador fin
  Transmite_Byte_Clock_and_Data(0x0F);
  LCR=LCR^0x0F;
  // transmite LCR
  Transmite_Byte_Clock_and_Data(LCR);
  // transmite cola de 15 ceros
  for(i=0;i<15;i++) Transmite_Bit_Clock_and_Data(0);
}