Half Duplex Serial Communications

NETMF & Gadgeteer
1

I am developing an application where I need to receive serial communications from an Xbee, interpret the data and then send a message out on a RS485 line.

The XBee part is working fine and is connected to COM1 on my Domino.

I plan to use an RS485 breakout board from Sparkfun to do the RS485 driving, but before this I wanted to test the COM2 port.

So I have looped RxD and TxD on the UEXT port back to each other and I can loop the data through COM2 fine.

However when I turn on hardware handshaking, it still works even if I do not connect RTS and CTS. As far as I can tell, in fact, the hardware handshaking option on the comm port does not do anything.

My question is: Is hardware handshaking enabled on COM2 on the Domino or do I have to implement the RTS/CTS logic in code myself?

The following is my VERY sloppy check code for all this. XBee is on COM1 and COM2 is looped back and characters typed on my PC go through the XBees, loop through COM2 and come back to my PC just fine, even without RTS and CTS connected.

namespace Fez_Domino_Serial_Port_Tester
{
    public class Program
    {

            public static int read_count1 = 0;
            public static int read_count2 = 0;
            public static byte[] rx_data1 = new byte[10];
            public static byte[] rx_data2 = new byte[10];

            public static SerialPort UART1 = null;
            public static SerialPort UART2 = null;

            public static void Main()
            {
                UART1 = new SerialPort("COM1", 9600);
                UART1.Open();
                UART1.DataReceived += new SerialDataReceivedEventHandler(UART_DataReceived);

                UART2 = new SerialPort("COM2", 9600);
                UART2.Handshake = Handshake.RequestToSend;      //This setting appears to have no effect
                UART2.Open();
                UART2.DataReceived += new SerialDataReceivedEventHandler(UART2_DataReceived);

                Thread.Sleep(Timeout.Infinite);
            }

            private static void UART_DataReceived(object sender, SerialDataReceivedEventArgs e)
            {
                read_count1 = UART1.Read(rx_data1, 0, UART1.BytesToRead);
                String receivedDataAsString = new String(Encoding.UTF8.GetChars(rx_data1));
                Debug.Print("Received1: " + read_count1.ToString() + " " + receivedDataAsString);
                Debug.Print("Wrote2: " + UART2.Write(rx_data1, 0, read_count1).ToString());
            }

            private static void UART2_DataReceived(object sender, SerialDataReceivedEventArgs e)
            {

                read_count2 = UART2.Read(rx_data2, 0, UART2.BytesToRead);
                String receivedDataAsString = new String(Encoding.UTF8.GetChars(rx_data2));
                Debug.Print("Received2: " + read_count2.ToString() + " " + receivedDataAsString);
                Debug.Print("Wrote1: " + UART1.Write(rx_data2, 0, read_count2).ToString());
            }
    }

Thanks

2

I guess if you need to do hardware handshaking you need to implement it on both sides right…?

3

Yes. You can very well shake hands with only one hand can you? :slight_smile:

4

use only COM2 and connect TX to RX, but then connect CTS to any other IO.
Change the IO to high and send data, see if you receive it back
Change the IO to low and send data, see if you receive it back

5

Just to close this thread out:

If you set Handshake to Handshake.RequestToSend then the RTS pin gets pulsed at the start of each byte. CTS appears to be ignored in all cases. I gather this is correct but not what I expected. So I have now been corrected.

For those who thought the whole question funny, looping back RxD to TxD and RTS to CTS (and as far as that is concerned DTR to DSR and DSR also to CD (sometimes callled RLSD)) is an old trick back from the days of real half duplex modems for doing sanity testing on your com port (yes I am that old). In those days RTS was left asserted until the whole byte was sent and CTS was required to enable the transmitter. My mistake was to think that this was still the way these lines operate.

6

I’m that old too :slight_smile: , this threads illustrates the general PITA of ‘simple’ serial communications. Every device would have its own take on how things should be implemented. So you had to carry around a RS232 breakout board and spend loads of time studying the docs for each device to guess at which combinations you should try; all of this just for the wiring. Then you have all the fun of ‘hoping’ you got the wiring correct whilst hoping that both devices will support a compatible set of COM parameters. Then you lather, rinse and repeat until the thing works :smiley:

Ah, the ‘good’ old days…