serial y paralelo SUBIR

Regional Distrito CapitalCentro de Gestión de Mercados, Logística y

Tecnologías de la Información

MANTENIMIENTO DE HARDWARE

Centro Gestión Comercial y MercadeoPrograma de Teleinformática

2008

Sistema de Gestión de la Calidad




Fecha: 12 marzo 2008

Para ensamblar los cables serial y paralelo utilizamos los siguientes materiales:

Cable UTP 4 Pares (serie) 6 Pares (paralelo)2 conectores DB-92 conectores DB -25Tapas para cada uno de los conectoresCautín EstañoPasta para soldar PinzasDestornillador

Para empezar a ensamblar los conectores debemos retirar el encauchetado para poder ver los hilos en el interior del mismo, luego de esto debemos pelar la punta de cada uno de los hilos para proceder a soldar, debemos tener en cuenta la ubicación del cable en cada Pin de la siguiente manera:

Para serial:

Para paralelo:






Luego de haber soldado en el orden correcto los cables






Procederemos medir su continuidad con el multimetro para evitar los errores de soldadura.

Después de terminar el paso anterior podemos empezar colocar las tapas como lo muestra la imagen.






(Cable paralelo)






(Cable Serie)

Cable paralelo

Cable paralelo es el cable de conexión para computadores definido por el estándar IEEE 1284 para la conexión de periféricos mediante el puerto paralelo. Se utilizaba frecuentemente para la conexión de impresoras con computadores compatibles PC. Se considera una conexión heredada y definitivamente ha sido reemplazada por el USB.

Características

Contrario a la creencia popular, no hay tal cosa como un cable de paralelo de impresora "estándar". Comúnmente se habla del ensamblado con un conector DB25 macho en un extremo y un conector de 36 pines tipo Champ del otro. Internamente, los cables tienen de 18 a 25 conductores, y de 1 a 8 alambres de tierra, y pueden tener aislamiento individual, o trenzado, y posiblemente un conductor aterrizado. Con este tipo de armado, no hay manera de controlar la impedancia del cable, la interferencia entre conductores, la capacitancía y el

http://es.wikipedia.org/wiki/USB

http://es.wikipedia.org/wiki/Ordenador_personal

http://es.wikipedia.org/wiki/Impresora

http://es.wikipedia.org/wiki/Puerto_paralelo

http://es.wikipedia.org/wiki/Puerto_paralelo

http://es.wikipedia.org/wiki/IEEE_1284






rendimiento. Este ensamblado está bien para operar a 10K Bytes por segundo a 6 pies, pero no opera confiablemente a 2M Bytes por segundo en cables de 30 pies.

Algunos parámetros para cumplir con el estándar IEEE 1284 de ensamblado incluyen:

Todas las señales van por un par trenzado con un conductor de señal y uno de tierra de retorno.

Cada par trenzado tiene una impedancia característica desbalanceada de 62 +/- 6 ohms sobre la banda de frecuencia de los 4 a los 16 MHz.

La interfencia de alambre a alambre no debe ser más grande del 10%. El cable deberá tener una cubierta óptica trenzada de 85% mínimo

cobre el recubrimiento. El blindaje del cable deberá ser conectado al cascarón del conector. Los cables que cumplan con las especificaciones deberán ser

marcados con: IEEE Std 1284-1994 Compliant.

Conectores IEEE 1284

El estándar IEEE 1284 va más allá de describir nuevos modos de transferencia de datos, y de hecho define la interfase mecánica y las propiedades eléctricas de un puerto paralelo compatible. Muchos de los problemas asociados con los dispositivos conectados al puerto paralelo surgen del hecho de que no existe un estándar para la interfase eléctrica para el puerto paralelo. El conector hembra DB25 se ha vuelto el estándar para la PC o el conector anfitrión, pero ha habido diferentes implementaciones de los controladores, resistores, capacitores, etc., para la interfase eléctrica. El comité IEEE 1284 sintió que era prioritario definir estas propiedades para cumplir con los siguientes objetivos:

Asegurar la compatibilidad eléctrica entre todos los dispositivos compatibles con IEEE 1284.

Asegurar que las interfases IEEE 1284 operarían con los periféricos, adaptadores y puertos existentes.

Asegurar la operación y la integridad de los datos a las radios de transferencia más altos.

Extender la operación a 30 pies, o 10 metros.

Para cumplir estos objetivos, el estándar define los conectores, interfase eléctrica, y los requerimientos de cableado.






El estándar identifica 3 tipos de conectores:

IEEE 1284 Tipo A: 25 pines DB-25 IEEE 1284. IEEE 1284 Tipo B: 36 Conductores, Conector tipo Champ de Línea

central de 0.085 con seguros (Centronics). IEEE 1284 Tipo C: 36 Conductores, Conector tipo mini Champ de Línea

central de 0.050 con seguros de clip (mini Centronics).

Cable Serie

El ordenador controla el puerto serie mediante un circuito integrado específico, llamado UART (Transmisor-Receptor-Asíncrono Universal). Normalmente se utilizan los siguientes modelos de este chip: 8250 (bastante antiguo, con fallos, solo llega a 9600 baudios), 16450 (versión corregida del 8250, llega hasta 115.200 baudios) y 16550A (con buffers de E/S). A partir de la gama Pentium, la circuiteria UART de las placa base son todas de alta velocidad, es decir UART 16550A. De hecho, la mayoría de los módems conectables a puerto serie necesitan dicho tipo de UART, incluso algunos juegos para jugar en red a través del puerto serie necesitan de este tipo de puerto serie. Por eso hay veces que un 486 no se comunica con la suficiente velocidad con un PC Pentium... Los portátiles suelen llevar otros chips: 82510 (con buffer especial, emula al 16450) o el 8251 (no es compatible).

Para controlar al puerto serie, la CPU emplea direcciones de puertos de E/S y líneas de interrupción (IRQ). En el AT-286 se eligieron las direcciones 3F8h (o 0x3f8) e IRQ 4 para el COM1, y 2F8h e IRQ 3 para el COM2. El estándar del PC llega hasta aquí, por lo que al añadir posteriormente otros puertos serie, se eligieron las direcciones 3E8 y 2E8 para COM3-COM4, pero las IRQ no están especificadas. Cada usuario debe elegirlas de acuerdo a las que tenga libres o el uso que vaya a hacer de los puertos serie (por ejemplo, no importa compartir una misma IRQ en dos puertos siempre que no se usen conjuntamente, ya que en caso contrario puede haber problemas). Es por ello que últimamente, con el auge de las comunicaciones, los fabricantes de PCs incluyan un puerto especial PS/2 para el ratón, dejando así libre un puerto serie.

Mediante los puertos de E/S se pueden intercambiar datos, mientras que las IRQ producen una interrupción para indicar a la CPU que ha ocurrido un

http://es.wikipedia.org/wiki/DB-25






evento (por ejemplo, que ha llegado un dato, o que ha cambiado el estado de algunas señales de entrada). La CPU debe responder a estas interrupciones lo mas rápido posible, para que de tiempo a recoger el dato antes de que el siguiente lo sobrescriba. Sin embargo, las UART 16550A incluyen unos buffers de tipo FIFO, dos de 16 bytes (para recepción y transmisión), donde se pueden guardar varios datos antes de que la CPU los recoja. Esto también disminuye el numero de interrupciones por segundo generadas por el puerto serie.

El RS-232 puede transmitir los datos en grupos de 5, 6, 7 u 8 bits, a unas velocidades determinadas (normalmente, 9600 bits por segundo o más). Después de la transmisión de los datos, le sigue un bit opcional de paridad (indica si el numero de bits transmitidos es par o impar, para detectar fallos), y después 1 o 2 bits de Stop. Normalmente, el protocolo utilizado ser 8N1 (que significa, 8 bits de datos, sin paridad y con 1 bit de Stop).

Una vez que ha comenzado la transmisión de un dato, los bits tienen que llegar uno detrás de otro a una velocidad constante y en determinados instantes de tiempo. Por eso se dice que el RS-232 es asíncrono por carácter y sincrono por bit. Los pines que portan los datos son RXD y TXD. Las demás se encargan de otros trabajos: DTR indica que el ordenador esta encendido, DSR que el aparato conectado a dicho puerto esta encendido, RTS que el ordenador puede recibir datos (porque no esta ocupado), CTS que el aparato conectado puede recibir datos, y DCD detecta que existe una comunicación, presencia de datos.

Tanto el aparato a conectar como el ordenador (o el programa terminal) tienen que usar el mismo protocolo serie para comunicarse entre si. Puesto que el estándar RS-232 no permite indicar en que modo se esta trabajando, es el usuario quien tiene que decidirlo y configurar ambas partes. Como ya se ha visto, los parámetros que hay que configurar son: protocolo serie (8N1), velocidad del puerto serie, y protocolo de control de flujo. Este ultimo puede ser por hardware (el que ya hemos visto, el handshaking RTS/CTS) o bien por software (XON/XOFF, el cual no es muy recomendable ya que no se pueden realizar transferencias binarias). La velocidad del puerto serie no tiene por que ser la misma que la de transmisión de los datos, de hecho debe ser superior. Por ejemplo, para transmisiones de 1200 baudios es recomendable usar 9600, y para 9600 baudios se pueden usar 38400 (o 19200).

Este es el diagrama de transmisión de un dato con formato 8N1. El receptor indica al emisor que puede enviarle datos activando la salida RTS. El emisor






envía un bit de START (nivel alto) antes de los datos, y un bit de STOP (nivel bajo) al final de estos.

Lo bueno

Que aprendí a conectar dos PCs sin utilizar cable de red.

Lo malo

Es dispendioso de hacer.Es costoso.

Lo feo

Los quemones por lo pequeño de los pines.Se derriten fácilmente los conectores.Que el profesor los jala y se pierde la soldada.

El puerto serie en Windows

Generalidades:






En Windows no es posible acceder a los dispositívos físicos directamente, a través de las direcciones de sus puertos. Por el contrario, todos los accesos (salvo que estemos programando un driver) deben hacerse a través de funciones del API.

Los puertos serie, por tratarse de dispositivos incluidos como parte de los PC desde sus comienzos, están muy bien integrados en el API de Windows, por lo tanto, tenemos un amplio repertorio de funciones para manejarlos.

El presente artículo no pretende estudiar en profundidad todas las funciones y opciones del API de Windows con referencia al puerto serie, sólo intentaré que aquellos que necesiten usar estos puertos en sus programas tengan unas nociones más precisas sobre como lograrlo.

Windows trata los puertos serie (y también el paralelo), como si se tratase de un fichero de entrada y salida más. La única peculiaridad es que su comportamiento es asíncrono, y esta característica influye mucho en el modo en que tenemos que programar nuestras aplicaciones cuando usen uno de estos puertos.

El comportamiento asíncrono se debe a varias características de este tipo de comunicación, para empezar, los datos se envían secuencialmente, a una velocidad relativamente baja. El sistema tiene que estar preparado para recibir los datos en el momento en que están disponibles, ya que si no actúa así, se perderán irremisiblemente.

En los ficheros normales, somos nosotros los que decidimos cuándo y cómo leemos o escribimos los datos. Y como la velocidad de respuesta de estos ficheros es bastante buena, generalmenten no notamos que el programa se para mientras se procesan estas órdenes de lectura y escritura.

Esto no pasa cuando se lee o se escribe de un puerto serie. Los datos que se reciben por uno de estos canales hay que leerlos cuando llegan, casi nunca sabremos cuándo el dispositivo que tenemos conectado al otro extremo del cable va a decidir enviarnos datos. En cuanto a la escritura, pasa algo parecido, no podemos preveer con precisión si el dispositivo al que enviamos los datos los va a procesar con la velocidad a la que se los enviamos, o si está o no preparado para recibirlos.

Aunque el sistema operativo dispone de un buffer para almacenar los datos que se reciben, ese buffer es finito, y si nuestro programa no retira esos datos con cierta frecuencia, los perderá.

En cuanto a las transmisiones hacia afuera, pasa algo parecido. El dispositivo receptor puede tener una capacidad limitada para procesar los datos, de modo que el sistema






debe estar preparado para esperar mientras el receptor procesa los datos y nos avisa de que está preparado para recibir más.

Estas características hacen que nuestro programa se complique un poco más de lo que en principio pudiéramos esperar. Pero como veremos, tampoco es para tanto.

Abrir un canal asociado a un puerto serie

Lo primero que necesitamos es un fichero asociado a nuestro puerto serie. Para eso usaremos la función del API CreateFile. CreateFile es una función con muchas opciones y que sirve para muchas cosas, pero ahora nos centraremos en el puerto serie.

Veremos ahora los valores posibles de los siete parámetros que necesita esta función:

1. LPCTSTR lpFileName: nombre del fichero. Se trata de una cadena que contiene el nombre del puerto que queremos abrir. Los valores posibles son "COM1", "COM2", "COM3" y "COM4".

2. DWORD dwDesiredAccess: tipo de acceso. En general querremos leer y escribir en el puerto, por lo tanto especificaremos los valores GENERIC_READ | GENERIC_WRITE.

3. DWORD dwShareMode: modo en que se comparte el fichero. En nuestro caso, un puerto serie no puede ser compartido, de modo que usaremos 0 para este parámetro.

4. LPSECURITY_ATTRIBUTES lpSecurityAttributes: atributos de seguridad, especifican el modo en que el fichero se puede heredar por procesos hijos. En nuestro caso no queremos que eso ocurra, de modo que usamos el valor NULL.

5. DWORD dwCreationDistribution: modo de creación. Los puertos serie son dispositivos físicos, por lo tanto, existen. El modo de creación será OPEN_EXISTING.

6. DWORD dwFlagsAndAttributes: atributos del fichero. Por ahora no nos interesa ninguno de estos atributos, usaremos el valor 0.

7. HANDLE hTemplateFile: plantilla de fichero. Se puede especificar un fichero existente del cual se copirarán los atributos. En nuestro caso no usaremos esta opción, y usaremos el valor NULL para este parámetro.

idComDev = CreateFile("COM1", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);

http://winapi.conclase.net/curso/funcion.php?CreateFile






Modificar los parámetros de transmisión

En general, necesitaremos establecer los parámetros de la línea serie que vamos a usar. Tendremos que fijar la velocidad de transmisión, el número de bits de datos, la paridad, y los bits de stop. Y a veces algunos parámetros más.

Para hacer esto, primero recuperaremos los parámetros del canal que acabamos de abrir, los modificaremos y actualizaremos la coniguración del canal.

Para recuperar los parámetros usaremos la función GetCommState. Esta función nos devuelve una estructura DCB, que contiene la configuración actual del puerto serie.

fSuccess = GetCommState(idComDev, &dcb);

De todos los valores que incluye la estructura DCB, de momento sólo nos preocuparemos por unos pocos:

1. DWORD BaudRate: velocidad en baudios. Este parámetro puede tener los siguientes valores: CBR_110, CBR_300, CBR_600, CBR_1200, CBR_2400, CBR_4800, CBR_9600, CBR_14400, CBR_19200, CBR_38400, CBR_56000, CBR_57600, CBR_115200, CBR_128000 y CBR_256000.

2. BYTE ByteSize: tamaño de los datos en bits. Tradicionalmente 7 u 8.3. BYTE Parity: valor de paridad. Se admiten los valores EVENPARITY,

para paridad par; MARKPARITY; NOPARITY, para no paridad y ODDPARITY, para paridad impar.

4. BYTE StopBits: Bits de stop. Admite los valores ONESTOPBIT, 1 bit de stop; ONE5STOPBITS, 1.5 bits de stop y TWOSTOPBITS, 2 bits de stop.

Una vez que hemos actualizado la estructura de datos podemos configurar el puerto enviándosela mediante la función: GetCommState.

SetCommState(idComDev, &dcb);

Monitorización de eventos

Podemos especificar qué eventos de los que se pueden producir en el puerto serie nos interesa procesar o monitorizar. De este modo, el sistema operativo nos avisará cada vez que se produzca uno de esos eventos. El modo de especificar los eventos de interés es mediante una máscara, y para hacerlo usaremos la función SetCommMask.

http://winapi.conclase.net/curso/funcion.php?SetCommMask

http://winapi.conclase.net/curso/funcion.php?GetCommState

http://winapi.conclase.net/curso/estructura.php?DCB

http://winapi.conclase.net/curso/funcion.php?GetCommState






Se pueden especificar varios eventos, pero generalmente nos interesararán sólo dos de ellos, al menos en la aplicaciones normales:

1. EV_RXCHAR: se ha recibido un carácter y se a colocado en el buffer de entrada.

2. EV_TXEMPTY: de ha enviado el último carácter del buffer de salida.

Para nuestro ejemplo sólo monitorizaremos el evento EV_RXCHAR.

SetCommMask(idComDev, EV_RXCHAR);

Ahora ya tenemos el puerto serie en condiciones de transmitir o recibir información.

Escribir en el puerto serie

Para enviar caracteres al puerto serie se usa la función WriteFile.

Sin embargo, como ya hemos explicado, no basta con enviar los caracteres al puerto serie, el destinatario puede interrumpir la transmisión si no es capaz de procesar los datos a la misma velocidad que se los enviamos, de modo que los datos que intentamos enviar pueden no ser enviados por completo.

Para estar seguros de que enviamos toda la información que queremos, usaremos uno de los parámetros que devuelve la función, y que nos dice cuántos caracteres se han enviado.

Colocando la función WriteFile en un bucle, podemos enviar los caracteres que aún están pendientes hasta que todos hayan sido enviados.

WriteFile puede retornar con valor false si se ha producido un error. Sin embargo, uno de los errores no es tal, el error ERROR_IO_PENDING en realidad sólo nos informa de que no se ha completado la operación de escritura. En caso de recibir ese error, debemos continuar enviado datos al puerto serie.

void EscribirSerie(char *buf){ char Buffer[1024]; DWORD n, l, p, err; strcpy(Buffer, buf); l = strlen(Buffer); // Longitud de los datos p = 0; // Posición actual de los datos a enviar while(l) {

http://articulos.conclase.net/winapi/curso/funcion.php?WriteFile






if(!WriteFile(idComDev, &Buffer[p], 1, &n, NULL)) { err = GetLastError(); if(err != ERROR_IO_PENDING) { Comunicacion = false; return; } } l -= n; p += n; }}

Esperar a que haya algo para leer

Por la misma naturaleza de las transmisiones, y debido a que nuestro ordenador normalmente será muy rápido en comparación con las velocidades de transmisión, la mayor parte del tiempo no estaremos recibiendo nada por el puerto serie.

Ya hemos definido la máscara de eventos que queremos recibir del puerto serie. Para saber si se ha producido uno de esos eventos tenemos que llamar a la función WaitCommEvent.

Pero, tal como hemos configurado el puerto serie, esta función no regresa mientras no se produzca uno de los eventos que hemos definido. Esto nos impide que nuestro programa realice otras tareas, como por ejemplo, enviar información al puerto.

Necesitamos un mecanismo que avise a nuestro programa cuando existan datos para leer, pero no debemos bloquear el sistema preguntando constantemente si hay algo preparado. Ni siquiera debemos bloquear nuestro programa, a menudo hay otras cosas que hacer además de esperar la llegada de nueva información.

La mejor forma es introducir la función WaitCommEvent en un hilo distinto del de nuestro programa principal. Podemos hacer que ese hilo espere a que se produzca un evento, y cuando eso ocurra, que lo procese.

En nuestro caso, sólo se puede producir un evento, de modo que una función posible para procesarlo es:

// Hilo de escucha del puerto serie:DWORD Hilo(LPDWORD lpdwParam){ DWORD dwEvtMask;

do { if(WaitCommEvent(idComDev, &dwEvtMask, NULL))

http://winapi.conclase.net/curso/funcion.php?WaitCommEvent






if(dwEvtMask & EV_RXCHAR) LeeSerie(); } while(true); return 0;}

Esta función coloca la función WaitCommEvent en un bucle infinito, y cuando detecta el evento EV_RXCHAR, hace una llamada a la función LeeSerie(), que procesa los datos recibidos.

Por supuesto, en algún lugar del programa, debemos lanzar el hilo, esto se hace con la función CreateThread.

hHilo = CreateThread(NULL, 0, Hilo, &param, 0, &id);

Leer desde el puerto serie

Lo primero que necesitamos saber es cuantos caracteres hay en el buffer de entrada. Para eso podemos usar la función ClearCommError. Esta función nos actualiza una estructura COMSTAT, uno de cuyos miembros es cbInQue, que nos dice cuantos caracteres hay en el buffer de entrada.

Con ese dato podemos llamar a la función ReadFile, y leer todos los caracteres que haya en el buffer.

// Leer datos del puerto serie:void LeeSerie(){ int i, j, k; DWORD x; COMSTAT cs;

// Actualizar COMSTAT, sirve para // averiguar el número de bytes en el buffer de entrada: ClearCommError(idComDev, &x, &cs); // Leer cs.cbInQue caracteres: ReadFile(idComDev, cad, cs.cbInQue, &x, NULL); // Actualizar el fin de cadena: cad[x]=0; // Mostrar caracteres leídos: cout << cad; return;

http://winapi.conclase.net/curso/funcion.php?ReadFile

http://winapi.conclase.net/curso/estructura.php?COMSTAT

http://winapi.conclase.net/curso/funcion.php?ClearCommError

http://winapi.conclase.net/curso/funcion.php?CreateThread






Control del Documento

Nombre Cargo Dependencia Firma Fecha

AutoresJavier Martínez

Alumno

Centro de Gestión de Mercados, Logística y Tecnologías de la Información

Javier Martínez 16-04-08

Revisión Ing. José Méndez Instructor

Centro de Gestión de Mercados, Logística y Tecnologías de la Información

16-04-08

serial y paralelo SUBIR

Documents

Transcript of serial y paralelo SUBIR