Como ya os he contado en diversas ocasiones y con cierto tono de humor os dejo este corto.

Creo que los puertos serie y los puertos paralelo son de las pocas electrónicas incombustibles que han sobrevivido a los tiempos. Es evidente que como cualquier otra electrónica al servicio de las comunicaciones ha evolucionado con el tiempo, adaptándose y aumentado prestaciones, aunque esto último parezca mentira pues estamos hablando de comunicaciones a bajas velocidades. Para los que consideréis que estoy exagerando, os contare que soy uno de los privilegiados que hace mas de 25 años tuve en las manos un “Zapatofono”, el tal zapatofono no era más que un adaptador del auricular/micrófono del teléfono, que a través de unas ventosas retransmitía los sonidos recibidos en el micro demodulándolos, para posteriormente generar las respectivas ondas del espectro audible modulandolas por el auricular para que el otro extremo las demodulara. Esto claro que se convirtió en el precursor de lo que hasta ahora hemos conocido como MODEM’s. Lo increíble es que la señal entre el teléfono y el modem se transmitía por el sonido generado o captado, o sea analógicamente y su velocidad rascaba el vértigo de 300Bauds… que no Bits por segundo J, que distan mucho de las velocidades de hoy en día… En fin…

En aquellos tiempos existían una serie de chips que implementaban por ‘hardware’ la funcionalidad de UART, pudiendo transmitir y procesar datos recibidos a través de un interface serie, pero sin posibilidad de implementar ninguna pila que les permitiera tener una cierta programabilidad por software. Llegado este punto entenderéis que no disponían de un buffer de recepción o proceso ilimitado, este era el caso de teletipos, impresoras o ese tipo de dispositivos que simplemente solo eran receptores de información. El problema surgía cuando por esos misterios de lo asíncrono los bytes enviados por el transmisor llegaban con una cadencia superior a la que el dispositivo era capaz de procesar. Es evidente que ello provocaba un desbordamiento de los ‘buffers’ con la consecuente pérdida de información, así que al enviar “donde dije diego” a la impresora o el dispositivo en cuestión, solo recibía… por poner un ejemplo “dodidi”.

En este mundo de avispados ingenieros enseguida conseguimos la solución en la especificación del RS232 incluimos las señales RTS/CTS con ellas podríamos conseguir controlar el flujo de información entre el DCE (Data Computer Equipment) y el DTE (Data Terminal Entry) de forma que cuando el DTE estaba agotando la capacidad en su ‘buffer’ de recepción ponía la señal de “Listo para recibir” o CTS en Bajo de esa forma l DCE sabia debía detener el envió de información para evitar su perdida. En el momento en que el DTE estaba aliviado volvía a levantar la señal CTS para que el DCE pudiera restablecer el envió de información. Simultáneamente el DCE debería adaptar su señal RTS o “Petición de envío” para que el DCE supiera de las intenciones de este ultimo..

Todo era un mar de felicitaciones, pues trabajando estas señales de “hardware” podíamos controlar el flujo, hasta que alguien se dio cuenta de que determinados dispositivos carecían de la posibilidad de trabajar estas señales, pues implementaban el nivel más bajo de la especificación que es cablear los pines del 2 al 3 en un extremo y del  3 al 2  en el otro así como cablear la masa. En esta configuración de ‘hardware’ continuábamos con el mismo problema y la única posibilidad que disponíamos era la implementación de ese control de flujo a través de protocolo por “software” … e volia… apareció el nuestro entrañable xON xOFF.
Cuando el dispositivo estaba a punto de desbordarse enviaba el código xOff, ello indicaría al transmisor la eminente necesidad de detenerse en el envío de información, una vez desahogado volvería a mandar un xOn con lo que el transmisor continuaría mandando la información pendiente.

Aunque xOn e xOff corresponden concretamente a un carácter ASCII, su implementación acostumbra a ser por protocolo, con lo que no es necesario perpetuar acción alguna. Me explico si en nuestro “apretón de manos” o “handshaking” configuramos la opción de xOn/xOff, automáticamente la operación de escritura se detendrá al recibir un “DC3” sin necesidad de que nuestra aplicación tenga que efectuar ninguna opción adicional, igualmente al recibir un “DC1” reanudara automáticamente el envío de los ‘bytes’ del ‘buffer’ pendientes de ser enviados.

 

Finalmente para los que en su dia trabajábamos detrás de un terminal de un Cyber, podremos recordar la pulsación de [CTRL+S] / [CTRL+Q], que nos permitían controlar cuando y como deteníamos el paso de las líneas lanzadas desbocadamente desde el sistema, para con ello darnos un respiro y tener tiempo de leerlas… sin ir más lejos estábamos utilizando xOn/xOff.

Los mas incrédulos podrán contrastar esta información, fijaros si fue importante que aun hoy en día, se encuentra implementada en la consola del sistema pues su salida virtualiza un TTY y por supuesto aun hoy en día mantiene la funcionalidad xOn / xOff… para rememorar viejos tiempos podéis ejecutar una instancia del “símbolo de sistema”, buscaros un archivo ‘log’ con el suficiente tamaño para que ocupe varias pantallas y copiároslo al directorio en el que trabajéis, finalmente lanzar la orden “C:\Type NombreDelArchivo.log”… manteniendo el CTRL pulsado y alternando S y Q veréis como el desplazamiento de líneas recibidas se detiene y reanuda al ritmo que marquéis con el xOn y xOff… que sin dudar aun existen!

Espero que esto venga en primer lugar a distraeros y en segundo lugar a responder alguna que otra cuestión que desde la opción de [Contacto] recibo a menudo.

Por cierto ¿Cómo se implementa en System.IO.Ports?

        Dim SerialPort1 As New IO.Ports.SerialPort
        SerialPort1.Handshake = IO.Ports.Handshake.XOnXOff

Cuidaros mucho.