Contents

Using Control Pins

Properties of Serial Port Control Pins

As described in Serial Port Signals and Pin Assignments, 9-pin serial ports include six control pins. The following table shows properties associated with the serial port control pins.

Control Pin Properties

Property NameDescription

DataTerminalReady

State of the DTR pin

FlowControl

Data flow control method to use

PinStatus

State of the CD, CTS, DSR, and RI pins

RequestToSend

State of the RTS pin

Signaling the Presence of Connected Devices

DTEs and DCEs often use the CD, DSR, RI, and DTR pins to indicate whether a connection is established between serial port devices. Once the connection is established, you can begin to write or read data.

To monitor the state of the CD, DSR, and RI pins, use the PinStatus property. To specify or monitor the state of the DTR pin, use the DataTerminalReady property.

The following example illustrates how these pins are used when two modems are connected to each other.

    Note:   All examples in this section are based on a Windows® 32-bit platform. For more information about other supported platforms, refer to Overview of a Serial Port Object.

Example — Connecting Two Modems

This example connects two modems to each other via the same computer, and illustrates how to monitor the communication status for the computer-modem connections, and for the modem-modem connection. The first modem is connected to COM1, while the second modem is connected to COM2.

  1. Create the serial port objects — After the modems are powered on, the serial port object s1 is created for the first modem, and the serial port object s2 is created for the second modem.

    s1 = serial('COM1');
    s2 = serial('COM2');
  2. Connect to the devices — s1 and s2 are connected to the modems. Because the default value for the ReadAsyncMode property is continuous, data is asynchronously returned to the input buffers as soon as it is available from the modems.

    fopen(s1)
    fopen(s2)

    Because the default DataTerminalReady property value is on, the computer (data terminal) is now ready to exchange data with the modems. To verify that the modems (data sets) can communicate with the computer, examine the value of the Data Set Ready pin using the PinStatus property.

    s1.Pinstatus
    ans = 
        CarrierDetect: 'off'
          ClearToSend: 'on'
         DataSetReady: 'on'
        RingIndicator: 'off'

    The value of the DataSetReady field is on because both modems were powered on before they were connected to the objects.

  3. Configure properties — Both modems are configured for a baud rate of 2400 bits per second and a carriage return (CR) terminator.

    s1.BaudRate = 2400;
    s1.Terminator = 'CR';
    s2.BaudRate = 2400;
    s2.Terminator = 'CR';
  4. Write and read data — Write the atd command to the first modem. This command puts the modem "off the hook," which is equivalent to manually lifting a phone receiver.

    fprintf(s1,'atd')

    Write the ata command to the second modem. This command puts the modem in "answer mode," which forces it to connect to the first modem.

    fprintf(s2,'ata')

    After the two modems negotiate their connection, verify the connection status by examining the value of the Carrier Detect pin using the PinStatus property.

    s1.PinStatus
    ans = 
        CarrierDetect: 'on'
          ClearToSend: 'on'
         DataSetReady: 'on'
        RingIndicator: 'off'

    Verify the modem-modem connection by reading the descriptive message returned by the second modem.

    s2.BytesAvailable
    ans =
        25
    out = fread(s2,25);
    char(out)'
    ans =
    ata
    CONNECT 2400/NONE

    Now break the connection between the two modems by configuring the DataTerminalReady property to off. To verify the modems are disconnected, examine the Carrier Detect pin value.

    s1.DataTerminalReady = 'off';
    s1.PinStatus
    ans = 
        CarrierDetect: 'off'
          ClearToSend: 'on'
         DataSetReady: 'on'
        RingIndicator: 'off'
  5. Disconnect and clean up — Disconnect the objects from the modems and remove the objects from memory and from the MATLAB® workspace.

    fclose([s1 s2])
    delete([s1 s2])
    clear s1 s2

Controlling the Flow of Data: Handshaking

Data flow control or handshaking is a method used for communicating between a DCE and a DTE to prevent data loss during transmission. For example, suppose your computer can receive only a limited amount of data before it must be processed. As this limit is reached, a handshaking signal is transmitted to the DCE to stop sending data. When the computer can accept more data, another handshaking signal is transmitted to the DCE to resume sending data.

If supported by your device, you can control data flow using one of these methods:

    Note:   Although you might be able to configure your device for both hardware handshaking and software handshaking at the same time, MATLAB does not support this behavior.

To specify the data flow control method, use the FlowControl property. If FlowControl is hardware, hardware handshaking is used to control data flow. If FlowControl is software, software handshaking is used to control data flow. If FlowControl is none, no handshaking is used.

Hardware Handshaking

Hardware handshaking uses specific serial port pins to control data flow. In most cases, these are the RTS and CTS pins. Hardware handshaking using these pins is described in The RTS and CTS Pins.

If FlowControl is hardware, the RTS and CTS pins are automatically managed by the DTE and DCE. To return the CTS pin value, use the PinStatus property. Configure or return the RTS pin value with the RequestToSend property.

    Note:   Some devices also use the DTR and DSR pins for handshaking. However, these pins are typically used to indicate that the system is ready for communication, and are not used to control data transmission. In MATLAB, hardware handshaking always uses the RTS and CTS pins.

If your device does not use hardware handshaking in the standard way, then you might need to manually configure the RequestToSend property. In this case, you should configure FlowControl to none. If FlowControl is hardware, then the RequestToSend value that you specify might not be honored. Refer to the device documentation to determine its specific pin behavior.

Software Handshaking

Software handshaking uses specific ASCII characters to control data flow. These characters, known as Xon and Xoff (or XON and XOFF), are described in the following table.

Software Handshaking Characters

CharacterInteger ValueDescription

Xon

17

Resume data transmission

Xoff

19

Pause data transmission

When using software handshaking, the control characters are sent over the transmission line the same way as regular data. Therefore, only the TD, RD, and GND pins are needed.

The main disadvantage of software handshaking is that Xon or Xoff characters are not writable while numerical data is being written to the device. This is because numerical data might contain a 17 or 19, which makes it impossible to distinguish between the control characters and the data. However, you can write Xon or Xoff while data is being asynchronously read from the device because you are using both the TD and RD pins.

Example: Using Software Handshaking

Suppose you want to use software flow control with the example described in Example — Reading Binary Data. To do this, you must configure the oscilloscope and serial port object for software flow control.

fprintf(s,'RS232:SOFTF ON')
s.FlowControl = 'software';

To pause data transfer, write the numerical value 19 to the device.

fwrite(s,19)

To resume data transfer, write the numerical value 17 to the device.

fwrite(s,17)
Was this topic helpful?