|
Serial COM port communications has always been one of my favorite topics. Ever since I was 15 I was writing code to communicate with electronics my Dad or I made.
Unfortunately VS.NET does not have a serial communications framework in place. So this tutorial explains how to easily communicate through a serial port using the MSComm OCX that is included with VB in Visual Studio 6 (and previous versions). You must have at least the ActiveX components of VS6 installed in order to use MSComm because it is a licensed control.
Required: MSComm.ocx installed with Visual Studio 6.
Note: To obtain MSComm.ocx and it's associated licensing, you can do a custom install of Visual Studio 6 and just install the ActiveX components (about 5MB).
|
Adding the MSComm Control
|
|
|
You must add the control to a form instead of just instantiating the control straight from code because it requires special OCX state information and a developing license be included in your program's assembly. By drawing it onto a form, VS.NET handles these for you.
- Create a new Windows Form
- Add the MSComm COM/OCX Control to your "Windows Forms"
- Right Click on the Toolbox
- Choose "Customize Toolbox..."
- Select and add the "Microsoft Communications Control"
- Draw the new control onto your form (Telephone icon)
|
Properties and Event Info
|
|
|
Here is a quick overview of some important properties of the MSComm control.
- com.CommPort
Sets or gets the computer's serial port to be used.
- com.PortOpen
Opens or closes the serial port.
- com.RThreshold
Sets how many characters should be received before firing the OnComm event. Set to 0 to disable event calling. Set to 1 to fire OnComm every time a character is received.
- com.InputMode
On of the MSCommLib.InputModeConstants constants to specify either sending/receiving text strings or byte arrays. Defaults to text which is easier to work with but not as reliable as byte arrays.
- com.Settings
Used to setup the port in the format "baud,p,d,s" where baud = baud rate, p = parity, d = # data bits, and s = # stop bits. Ex: com.Settings = "9600,n,8,1"
- com.Handshaking
On of the MSCommLib.HandshakeConstants constants to specify the type of handshaking: none, RTS/CTS hardware hs, and/or XOn/XOff software hs
- com.InBufferCount
Returns the number of characters waiting in the receive buffer.
- com.Input
Returns and removes a stream of data from the receive buffer. Used to check for data waiting. Returns a string if in text mode or byte array if in binary/byte mode.
- com.Output
Writes a stream of data to the transmit buffer. Ex: com.Output = "Hello" sends "Hello" through the serial port.
- com.CommEvent
Returns a MSCommLib.CommEventConstants, MSCommLib.ErrorConstants, or MSCommLib.OnCommConstants constant representing the most recent error or event that occurred. Check this in the OnComm event.
- com.NullDiscard
If true, the serial control will ignore all 0x00 (null) characters come in. You will usually want to disable this so you can receive 0x00 since it may be important.
- com.InputLen
The number of characters the Input property reads from the receive buffer. Setting InputLen to 0 reads the entire contents of the receive buffer when com.Input is used.
OnComm Event
The one single event that the com control calls is the OnComm event whenever something happens. To use this, be sure to set RThreshold = 1 and check the InBufferCount inside your event. Use com.CommEvent for more information as to why the OnComm event was fired. Example:
|
public MyForm()
{
InitializeComponents(); // Initialize Form Components
com.RThreshold = 1; // Fire OnComm event after any data is received
com.OnComm += new System.EventHandler(this.OnComm); // Assigns the event handler
}
private void OnComm(object sender, EventArgs e) // MSCommLib OnComm Event Handler
{
if (com.InBufferCount > 0) ProcessData((string) com.Input);
if (com.CommEvent == MSCommLib.OnCommConstants.comEvCTS)
Console.WriteLine("CTS Line Changed");
}
|
If you are making your own serial interface/protocol, you really must have a good standard in place. Serial data flows into the com port byte by byte and must be buffered and parsed correctly. Think of it this way, if a terminal sent your computer "Hello World" it may come in as four OnComm triggers: "H", "ello", " Wo", and "rld"
The best protocols are usually a mix of these methods.
Here are three simple protocol techniques:
- Beginning and Ending ("Start" & "Stop") Codes
This is good for sending text as it lets everybody know when text starts and ends. You simply tack on a non-normal byte at the beginning and end of the text. For example, you'd use '---' to signify the start of the string and '===' to signify the end. So you would use: com.Output = "---Hello World===";
- Fixed Length Codes
Used for specific commands. You can create your own codes to send and specify what they mean. Say I want to control the lighting in a house, I'd setup a protocol of commands like this:
1st byte = House Code, 2nd byte = Light Code, 3rd byte = On or Off (0 for off, 1 for on)
So to turn on the 11th light in my house (house code #3) I'd use:
com.Output = new byte[] {3, 11, 0};
- Prefixed Data Packet
This is probably the most common and flexible but requires the most coding. Just prefix your data packet with the length of the data. The prefix must be a fixed size, such as two bytes which would allow a data packet of up to 65,535 bytes. Then the receiver knows how much data is in the packet because it always takes the first two bytes and uses the rest as the data packet.
Example: com.Output = ((char) 00) + ((char) 11) + "Hello World";
|
Physical
Port Layout and the Null Modem
|
|
|
Pin Assignments
|
9-pin
|
25-pin
|
Assignment
|
|
Sheild
|
1
|
Case Ground
|
|
1
|
8
|
DCD (Data Carrier Detect)
|
|
2
|
3
|
RX (Receive Data)
|
|
3
|
2
|
TX (Transmit Data)
|
|
4
|
20
|
DTR (Data Terminal Ready)
|
|
5
|
7
|
GND (Signal Ground)
|
|
6
|
| |