# Communicate through serial cable

## rawbeefman

I am starting a giant project based around communicating with a device through a serial cable.

I want to open the port, send data on the TXD and receive on the RXD, then close the port.

I want to use cat to send / receive the data.  I want to use stty to set the baud rate.

Can somebody kindly help me and point me in the right direction?

Thank you very much.

----------

## roarinelk

stty /dev/ttyS0 115200

echo "blabla" >> /dev/ttyS0

cat /dev/ttyS0

however cat won't return unless the other end sends an EOF.  Better you write

a small C program to do communications, google has enough examples on how

to use serial ports on unix systems.

----------

## rawbeefman

Thank you for the quick response.

```
stty /dev/ttyS0 115200 
```

So this would set the baud rate at 115200 bps?  Simple enough.

```
echo "blabla" >> /dev/ttyS0 
```

This will send the bytes for blabla on the TXD line?

```
cat /dev/ttyS0 
```

This will read in the bytes.  As it is, I have RXD and TXD linked together at the other end of the line, so it should just echo blabla back?

This seems pretty simple.  I was reading that each serial cable has one or more device files.  Do I need to worry about this, or for my simple activities, I only need to worry about one device file?

Thanks!

----------

## NeddySeagoon

rawbeefman,

You may need to set up the handshake, start bits, parity and stop bits too. 8n1 is popular.  Thats 8 data bits, no parity and 1 stop bit.  There are lots of other options too.

The echo command will not send EOF, it will only send the text.

minicom is a better tool to play with serial ports with.  Its also easier to debug if you send from one serial port and receive at another, as if you send or receive with minicom you can be pretty sure its doing the right thing so any problems are with your code.

Lastly, you must not use software handshaking if you want to send binary data over the serial link as the start and stop characters will be legal characters in your data stream.

----------

## roarinelk

run cat on one terminal and echo on another and yes, you should see

on the first what you pipe in on the second (or try minicom / putty).

the "standard" serial port (i.e. everything 8250 compatible and most other)

have only one device file, usually /dev/ttyS* (for uarts on a bus), or ttyUSB*

for USB-to-serial converters.

----------

## rawbeefman

Thanks for the quick replies.

So Minicom is the way to go?

Through some tutorials I was able to configure the serial port, and run the program, but am lost past that.  To get myself started, I just want to loop a message through the TXD and back through the RXD.  I have the wires connected.

What kind of handshaking needs to occur?  I am pretty lost past this point.

Thanks anyone for any help.

----------

## NeddySeagoon

rawbeefman,

The requirement for handshaking depends on the amount of data you expect to send and receive and how quickly your application will collect it from the serial port.

For small amounts of data (<16 bytes) no handshaking is required under any circumstances. The serial port buffer holds that much data.

For more data, provided you can collect it from the serial port before the buffer overflows, no handshaking is needed either.  This has to work in both directions.

For text (ASCII) data you can use software handshaking, also known as X-on/Xoff.  Two control characters, usually Ctrl-S and Ctrl-Q are sent to the transmitter by the receiver to tell the transmitter to stop sending and start sending again. This has the advantage of not needing any extra wires but your valid data cannot contain X-on and X-off.

If you need to transmit binary data and cannot service the serial port fast enough, you must use hardware handshaking. This link is a reasonable explaination of how RS-232 works.

The kernel has two serial port interfaces, the /dev/ttyS*, which allows you to send and receive characters, after you have set it up the way you want and a lower level interface that allows you to send and receive characters and control the handshaking lines yourself. 

You probably want to use the higher level interface, with the serial port setup and wiring that suits your application.

----------

## ewaller

You should probably not set out to reinvent the wheel.  With Open Source, you can build on the hard work of others (As someone said, stand on the shoulders of giants.)

Look for prepackaged solutions that might make your job a lot easier.  For example: http://qextserialport.sourceforge.net/.  I have used that one and it works like a charm.  There are others out there as well.

----------

## cwr

I'd avoid software handshaking if I were you - it can be pretty flakey.  If you can

get at both ends of the link, I'd run kermit (as a server on one end).  Simply

dumping and collecting data can work, but not easily for two-way communication,

particularly fast two-way communication.  When I dealt a lot with RS232 I

generally disabled hardware handshaking as well, and used some sort of

higher-level protocol - eg: kermit, xmodem, whatever occurred to me.

For a large project,  I'd get the comms reliable first of all, or it will bug you

endlessly.

Will

----------

## rawbeefman

Thanks everyone, this is certainly building my confidence.  I was not looking to handshake if I didn't have to, since I will be simply sending 1 to 3 bits max at a time.  This is what I have gathered thus far.

Minicom - This is the terminal program I will be using.

Kermit, Xmodem - These are the protocols to use inside Minicom.  Is there a best one for small, non-handshaking, bit sending?  Am I getting this right?

QextSerialPort - Serial port class that will facillitate in my coding.  I will read about it later, but it will remove my need to pick a protocol?  It will pick its own?

My goal right now is to be able to send some bits out my TXD wire, and back through my RXD wire by twisting them together.  By looking into these items, am I on my way to figuring that out?

I know how it can be trying to explain something to someone who is lost on the topic they are trying to understand.  So I really appreciate the help you guys are giving me.

----------

## NeddySeagoon

rawbeefman,

For three bits you can abuse the serial port and send the bits over the data and handshake wires. You would control the signals directly and it would be up to your software what the various states of the signals meant.

When you encode your 3 bits into a serial data stream, you will always send bytes* over the serial link.

*Its only bytes if you set the serial link up for 8 data bits.  Values from 5 to 8 data bits are permitted.

Kermit is a program for sending and receiving files over a serial port. It provides a lot of protocols for ensuring error free transfer over a noisy line.

X-Modem is one such protocol. Data is sent in 64 byte blocks with a checksum, if the checksum fails at the receiving end, the receiver discards the data block and asks for it to be sent again. For three bits this is overkill.

You can just echo the received data back to the sender and ask if it was right.  The noise that was the bane of serial port communications was introduced by telephone lines (POTS). You won't need noise checks over shorter distances as RS-232 is robust.

Minicom will quite happily talk to itself over Tx/Rx on your serial port provided you turn handshaking off.

Depending on how you set local echo, you may see two copies of everything you type.  Thats the local echo (optionally) provided by minicom and the data sent/received over your serial port.

Think about how you will encode your 3 bits of data.  Using bits 0, 1 and 2 and setting the other bits to 0 would be a really bad idea. I won't say why just now. Look at the ASCII character set for the corresponding characters.

----------

## osator

 *rawbeefman wrote:*   

> I am starting a giant project based around communicating with a device through a serial cable.
> 
> I want to open the port, send data on the TXD and receive on the RXD, then close the port.
> 
> I want to use cat to send / receive the data.  I want to use stty to set the baud rate.
> ...

 

I have been writing something like this in java. But I didn't reinvented the wheel. I have used modbus protocol to write/read data, RXTX and jamod library. Communication aspects were very easy. This solution works well on gentoo. But I don't know purpose of your project so I can't help you more. I have used modbus protocol to read/write data to Siemens S7-1200 PLC. Maybe this is worth to consider ?

----------

## rawbeefman

That's really interesting.  Java is my forte, but I am trying to develop in different technologies to expand my horizon.

I am interfacing with an omnistat2 programmable thermostat.

Thanks.

----------

## cwr

Kermit and Xmodem are both programs and protocols - the protocols are often implemented

by other comms programs.  However, if you are just sending and receiving single bytes

loopback on the Tx/Rx lines should work (with hardware handshaking disabled).  I can't

remember off the top of my head the exact configuration, but the idea is to use DTR to

trick the other control inputs into believing the port is always available.  Google is your

friend here.

Good luck - Will

----------

## rawbeefman

I am using minicom with the kermit protocol (correct me if I am using the wrong terminology) to receive the bits (in 8n1).  Whether I send data out with echo, or the c code I found online and tweaked:

```

fd1 = open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY);

fcntl(fd1, F_SETFL,0);

wr = write(fd1,"ATZ\r",4);

```

Either way, I dont see stuff coming back to me in minicom.  Is it because I am not sending proper stop bits?  The fact that the line is not ready to send/receive?  Can someone point me toward what I am doing wrong?

Thanks.

----------

## rawbeefman

This is real simple.  The issue was a bad cable.  First, I shorted pins 2 and 3 with my girlfriends earring -- but paperclips, needles, forks, bottle openers will all work.  When that worked, I went to radio shack, bought a serial bracket and some solder.  Soldered a cat5 cable to the bracket.  Bottom line, everything works.  Thank you everyone for your suggestions.  I really appreciate it!

----------

## rawbeefman

Can anyone tell me how to get qextserial port going?  I have it downloaded and extracted.  How do I build it into a library?

----------

## 1clue

You might want to take a look at chat scripts as well.  Minicom probably supports that.  It lets you set up canned responses for certain prompts.  That was done in the modem days with PPP and similar, to handle logging in to the ISP.  Still done today but less in-your-face.

While everything may be foreign to you, you're really doing something fundamentally simple.  It's kinda fun once you get the hang of it.

----------

