Microsoft KB Archive/39342
Article ID: 39342
Article Last Modified on 8/16/2005
- Microsoft QuickBasic 4.0
- Microsoft QuickBASIC 4.0b
- Microsoft QuickBasic 4.5 for MS-DOS
- Microsoft BASIC Compiler 6.0
- Microsoft BASIC Compiler 6.0b
- Microsoft BASIC Professional Development System 7.0
- Microsoft BASIC Professional Development System 7.1
This article was previously published under Q39342
This article outlines troubleshooting advice for using serial communications in Microsoft QuickBasic versions 4.0, 4.0b, and 4.5, in Microsoft Basic Compiler versions 6.0 and 6.0b for MS-DOS and MS OS/2, and in Microsoft Basic Professional Development System (PDS) versions 7.0 and 7.1.
This article gives a sample OPEN COM statement that should work correctly. Additional communications troubleshooting hints are also given. For a related article, see the following article in the Microsoft Knowledge Base:
39386 Error Message Explanations When Using COM1: and COM2:
If you have problems using "COM1:" or "COM2:", try the following OPEN statement, which makes Basic as tolerant as possible of hardware-related problems:
OPEN "COM1:300,N,8,1,BIN,CD0,CS0,DS0,OP0,RS,TB2048,RB2048" AS #1
(This OPEN is FOR RANDOM access.) The following is an explanation of each recommended parameter used in this OPEN statement:
- The higher the baud rate, the greater the chances for problems; thus, 300 baud is unlikely to give you problems. 2400 baud is the highest speed possible over most telephone lines, due to their limited high-frequency capability. 19,200 baud, which requires a direct wire connection, is most likely to cause problems. (Possible baud rates for QuickBasic are 75, 110, 150, 300, 600, 1200, 1800, 2400, 4800, 9600, and 19,200.)
Parity usually does not help you significantly; because of this, you should try No parity (N).
For those devices that require parity, you should use the PE option (Parity Enable) in the OPEN COM statement, which is required to turn on parity checking. When the PE option turns on parity checking, a "Device I/O error" occurs if the two communicating programs have two different parities. (Parity can be Even, Odd, None, Space, or Mark). For example, a "Device I/O error" occurs when two programs try to talk to each other across a serial line using the following two different OPEN COM statements:
OPEN "COM1:1200,O,7,2,PE" FOR RANDOM AS #1
OPEN "COM2:1200,E,7,2,PE" FOR RANDOM AS #2
If the PE option is removed from the OPEN COM statements above, no error message displays.
- The above example uses 8 data bits and 1 stop bit. Eight data bits requires No parity (N), because of the size limit for Basic's communications data frame (10 bits).
- The BIN (binary mode) is the default. Note: The ASC option does NOT support XON/XOFF protocol, and the XON and XOFF characters are passed without special handling.
- Ignoring hardware handshaking often corrects many problems. Thus, if your application does not require handshaking, you should try turning off the following hardware line-checking:
CD0 = Turns off time-out for Data Carrier Detect (DCD) line
CS0 = Turns off time-out for Clear To Send (CTS) line
DS0 = Turns off time-out for Data Set Ready (DSR) line
OP0 = Turns off time-out for a successful OPEN
- RS suppresses detection of Request To Send (RTS).
- For buffer-related problems, try increasing the transmit and receive buffer sizes above the 512-byte default:
TB2048 = Increases the transmit buffer size to 2048 bytes
RB2048 = Increases the receive buffer size to 2048 bytes
The following are additional important hints for troubleshooting communications problems:
- You should use the INPUT$(x) function in conjunction with the LOC(n) function to receive all input from the communications device (where "x" is the number of characters returned by LOC(n), which is the number of characters in the input queue waiting to be read. "n" is the file number that you OPENed for "COM1:" or "COM2:").
Avoid using the INPUT#n statement to input from the communications port because INPUT#n waits for a carriage return (ASCII 13) character.
Avoid using the GET#n statement for communications because GET#n waits for the buffer to fill (and buffer overrun could then occur).
Also, avoid using the PUT#n statement for communications, and use the PRINT#n statement instead. For example, in QuickBasic 4.0b and 4.5, in Basic Compiler 6.0 and 6.0b, and in Basic PDS 7.0 and 7.1, using the PUT#n,,x$ syntax for sending a variable-length string variable as the third argument of the PUT#n statement sends an extra 2 bytes containing the string length before the actual string. These 2 length bytes sent to the communications port may confuse your receiving program if it is not designed to handle them. No length bytes are sent with PUT#n,,x$ in QuickBasic 4.0. (QuickBasic versions earlier than 4.0 don't offer the feature to use a variable as the third argument of the PUT#n statement.)
- For an example of data communications, please refer to the TERMINAL.BAS sample program that comes on the release disk for QuickBasic versions 4.0, 4.0b, and 4.5, for Microsoft Basic Compiler versions 6.0 and 6.0b, and for Microsoft Basic Professional Development System (PDS) versions 7.0 and 7.1. Many communications problems may actually be due to inappropriate source code design and flow of control.
- Many communications problems can only be shown on certain hardware configurations and are difficult to resolve or duplicate on other computers. We recommend experimenting with a direct connection (with a short null-modem cable) instead of with a phone/modem link between sender and receiver to isolate problems on a given configuration.
- The wiring schemes for cables vary widely. Check the pin wiring on your cable. For direct cable connections, a long or high-resistance cable is more likely to give problems than a short, low-resistance cable.
- If both "COM1:" and "COM2:" are open, "COM2:" will be serviced first. At high baud rates, "COM1:" can lose characters when competing for processor time with "COM2:".
- Using the ON COM GOSUB statement instead of polling the LOC(n) function to detect communications input can sometimes work around timing or buffering problems caused by delays in Basic. Delays in Basic can be caused by string-space garbage collection, PAINT statements, or other operations that heavily use the processor.
- Make certain that the appropriate hardware handshaking lines (i.e. CS, DS, CD, etc) are being checked by Basic. Although disabling these timeouts (setting the corresponding value in the Basic OPEN statement to zero) is useful for determining what lines your hardware uses, it should not be considered a general purpose method for establishing serial communications, since ignoring hardware handshaking may increase the possibility of a timing problem that could lead to a hang.
Many commercial communications programs use sophisticated techniques not found in Microsoft Basic and may give better performance.
If you need better communications performance than you are getting through Basic, you may want to try Microsoft C. (You can call Microsoft C routines from Microsoft QuickBasic 4.0, 4.0b, and 4.5, from Microsoft Basic Compiler 6.0 and 6.0b, and from Microsoft Basic Professional Development System (PDS) versions 7.0 and 7.1.) The following is an excellent reference:
"C Programmer's Guide to Serial Communications" by Joe Campbell, published by Howard W. Sams & Company.
QuickBasic 3.0, 4.0, 4.0b, and 4.5 implement communications by direct interrupts to the IRQ3 and IRQ4 input lines on the 8259 controller chip (instead of invoking ROM BIOS interrupts).
The following book gives an excellent technical, hardware-level description of serial communications for the IBM PC:
"8088 Assembler Language Programming: The IBM PC" Second Edition by Willen & Krantz, published by Howard W. Sams & Co. (1983, 1984). Pages 92-93, and Chapter 7 (Pages 166 to 188).
Additional query words: QuickBas BasicCom 4.00 4.00b 4.50 6.00 6.00b 7.00 7.10