Cómo solucionar problemas de puerto de comunicaciones QuickBasic común

Exención de responsabilidades de contenido KB retirado

Este artículo se refiere a productos para los que Microsoft ya no ofrece soporte técnico. Por tanto, el presente artículo se ofrece "tal cual" y no será actualizado.

Resumen

En este artículo se describe sugerencias para solucionar problemas para utilizar comunicaciones serie en Microsoft QuickBasic versiones 4.0, 4.0b y 4.5, en las versiones de Microsoft Basic Compiler 6.0 y 6.0b para MS-DOS y MS OS/2 y en Microsoft Basic Professional desarrollo sistema (PDS) las versiones 7.0 y 7.1.


Este artículo proporciona un ejemplo de instrucción OPEN COM que debería funcionar correctamente. También se dan sugerencias de solución de problemas de comunicaciones adicionales. Un artículo relacionado, consulte el artículo siguiente en Microsoft Knowledge Base:
39386 error explicaciones de los mensajes al usar COM1: y COM2:

Más información

Si tiene problemas al utilizar "COM1:" o "COM2:", pruebe la siguiente instrucción abierta, lo que hace tan tolerante a errores como sea posible de los problemas relacionados con el hardware de Basic:
ABRIR "COM1:300, N, 8, 1, BIN CD0, CS0, DS0, OP0, RS, TB2048, RB2048" COMO #1
(Abra es acceso para aleatorio). La siguiente es una explicación de cada parámetro recomendado utilizado en esta instrucción OPEN:


  1. Cuanto mayor sea la velocidad en baudios, más posibilidades de problemas; por lo tanto, 300 baudios no suele dar problemas. 2400 baudios es la velocidad más alta posible en la mayoría de las líneas de teléfono, debido a su capacidad limitada de alta frecuencia. 19200 baudios, que requiere una conexión de cable directo, es más probable que causa problemas. (Baudios posibles para QuickBasic son 75, 110, 150, 300, 600, 1200, 1800, 2400, 4800, 9600 y 19200.)
  2. Paridad normalmente no ayudarle considerablemente; por este motivo, resulta no conveniente paridad (N).


    Para los dispositivos que requieren la paridad, debe utilizar la opción de PE (habilitar la paridad) en la instrucción OPEN COM, que es necesario para activar la comprobación de paridad. Cuando la opción PE activa la comprobación de paridad, se produce un "error de E/S de dispositivo" si los dos programas de comunicación tienen dos paridades diferentes. (Puede ser la paridad par, impar, ninguno, espacio o marca). Por ejemplo, se produce un "error de E/S de dispositivo" cuando dos programas intentan comunicarse entre sí a través de una línea serie utilizando las siguientes dos instrucciones OPEN COM diferentes:
          OPEN "COM1:1200,O,7,2,PE" FOR RANDOM AS #1
    y
          OPEN "COM2:1200,E,7,2,PE" FOR RANDOM AS #2
    Si se quita la opción de PE de las instrucciones OPEN COM anteriores, aparece un mensaje de error.
  3. En el ejemplo anterior se utilizan 8 bits de datos y 1 bit de parada. Ocho bits de datos no requiere paridad (N), debido al límite de tamaño de trama de datos de comunicaciones de Basic (10 bits).
  4. El BIN (modo binary) es el valor predeterminado. Nota: La opción ASC no admite el protocolo XON/XOFF, y los caracteres XON y XOFF se pasan sin un tratamiento especial.
  5. Omitiendo protocolo de enlace hardware a menudo corrige muchos problemas. Por lo tanto, si la aplicación no requiere el apretón de manos, debe intentar desactivar la siguiente línea de comprobación de hardware:
    Cd0 = activa desactivar tiempo de espera para la línea de portadora de datos (DCD, Data Carrier Detect)
    CS0 = activa desactivar tiempo de espera para la línea Listo para enviar (CTS)
    DS0 = activa desactivar tiempo de espera para la línea conjunto de datos preparado (DSR)
    OP0 = activa desactivar tiempo de espera para un éxito abierto
  6. RS suprime la detección de solicitud para enviar (RTS).
  7. Para problemas relacionados con el búfer, pruebe a aumentar la transmisión y tamaños de búfer anteriormente el valor predeterminado de 512 bytes de recepción:
    TB2048 = aumenta a 2048 bytes del tamaño del búfer de transmisión
    RB2048 = aumenta a 2048 bytes del tamaño del búfer de recepción
    Un búfer de recepción puede ayudarle a evitar básicas retrasos causados por instrucciones como PAINT, que utilizan el procesador de forma intensiva.
Consejos importantes adicionales para solucionar problemas de comunicaciones son los siguientes:


  1. Debe utilizar la función INPUT$(x) junto con la función LOC(n) para recibir todos los datos introducidos desde el dispositivo de comunicaciones (donde "x" es el número de caracteres devuelto por LOC(n), que es el número de caracteres en la cola de entrada esperando para ser leído. "n" es el número de archivos que ha abierto para "COM1:" o "COM2:").


    Evitar el uso de la instrucción INPUT #n a la entrada del puerto de comunicaciones porque INPUT #n espera un carácter de retorno del carro (ASCII 13).


    Evite utilizar la instrucción GET #n para comunicaciones porque GET #n espera el búfer rellenar (y, a continuación, podría producirse la saturación del búfer).


    Además, evite el uso de la instrucción de PUT #n para comunicaciones y utilice en su lugar la instrucción #n de impresión. Por ejemplo, en la sintaxis de QuickBasic 4.0b y 4.5, en Basic Compiler 6.0 y 6.0b y en básica de PDS de 7.0 y 7.1, con el #n PUT,, x$ para el envío de una variable de cadena de longitud variable como el tercer argumento de las PESQUERÍAS #n instrucción envía un extra 2 bytes que contiene la longitud de la cadena antes de la cadena real. Estos bytes de 2 longitud enviados al puerto de comunicaciones pueden confundir el programa receptor si no está diseñada para controlarlos. No hay bytes de longitud se envían con PUT #n,, x$ en QuickBasic 4.0. (QuickBasic versiones anteriores a la 4.0 no ofrecen la característica para utilizar una variable como el tercer argumento de la instrucción de PUT #n.)
  2. Para obtener un ejemplo de comunicaciones de datos, consulte el TERMINAL. Programa de ejemplo BAS que viene en el disco de la versión para las versiones 4.0, 4.0b y 4.5 de QuickBasic, para las versiones de Microsoft Basic Compiler 6.0 y 6.0b y para las versiones de Microsoft Basic Professional desarrollo sistema (PDS) 7.0 y 7.1. Muchos problemas de comunicaciones realmente pueden ser debido al diseño de código de origen inapropiado y flujo de control.
  3. Muchos problemas de comunicaciones sólo pueden mostrarse en ciertas configuraciones de hardware y son difíciles de resolver o duplicar en otros equipos. Se recomienda experimentar con una conexión directa (con un cable de módem nulo corto) en lugar de con un enlace de teléfono o módem entre remitente y receptor para aislar los problemas en una configuración determinada.
  4. Los esquemas de cableado para cables varían ampliamente. Compruebe el cableado de pin en el cable. Las conexiones directas por cable, un cable largo o resistencia alta es más probable que da problemas que un cable corto, de baja resistencia.
  5. Si ambos "COM1:" y "COM2:" están abiertos, "COM2:" se prestará en primer lugar. A altas velocidades, "COM1:" puede perder caracteres cuando compite para obtener tiempo del procesador con "COM2:".
  6. Utilizando la instrucción GOSUB de COM ON en lugar de sondear la función LOC(n) para detectar las comunicaciones entrada puede a veces evitar la sincronización o el almacenamiento en búfer problemas causados por retrasos en Basic. Retrasos en Basic pueden deberse a la recolección de espacio de cadena, instrucciones de pintura u otras operaciones que utilizan intensivamente el procesador.
  7. Asegúrese de que las líneas de enlace de hardware apropiado (es decir, CS, DS, CD, etc.) se han comprobado Basic. Aunque es útil para determinar qué líneas utiliza su hardware deshabilitar estos tiempos de espera (el valor correspondiente en la instrucción básica OPEN a cero), no se debe considerar un método de propósito general para establecer comunicaciones serie, ya que omitiendo protocolo de enlace hardware puede aumentar la posibilidad de un problema de temporización que podría conducir a un bloqueo.
Uso de programas de comunicaciones comerciales muchos sofisticadas técnicas que no se encuentra en Microsoft Basic y podría ofrecer un mejor rendimiento.


Si necesita mejor rendimiento de las comunicaciones que se reciben a través de Basic, es aconsejable probar Microsoft C. (puede llamar Microsoft C rutinas de Microsoft QuickBasic 4.0, 4.0b y 4.5 de Microsoft Basic Compiler 6.0 y 6.0b y de las versiones de Microsoft Basic Professional desarrollo sistema (PDS) 7.0 y 7.1). La siguiente es una excelente referencia:
"Guía del programador de C para comunicaciones en serie" por Joe Campbell, publicado por Howard W. Sams & Company.
3.0, 4.0, 4.0b y 4.5 de QuickBasic implementar comunicaciones por interrupciones directas a las líneas de entrada IRQ3 y IRQ4 en el chip de controlador 8259 (en lugar de invocar las interrupciones de BIOS ROM).


El siguiente libro proporciona una excelente descripción técnica, nivel de hardware de comunicaciones serie para PC de IBM:
"Programación en lenguaje ensamblador 8088: IBM PC" segunda edición por Willen & Krantz, publicado por Howard W. Sams & Co. (1983, 1984). Páginas 92-93 y el capítulo 7 (páginas 166 a 188).
Propiedades

Id. de artículo: 39342 - Última revisión: 01/17/2017 - Revisión: 1

Comentarios