# serial port problem

## WWWW

Hello,

I need to hook up a couple devices that communicate via serial port. For this I use real serial port and usb to serial port adapter for which module is loaded properly.

The module loads right but I am unable to communicate with the devices.

These devices did work properly with windows and testings done with m$$$ hyperterminal also confirmed success.

When trying with linux the serial ports appear to look fine with stty even able to change settings succesfully.

I've used stty with both on-board serial port and a usb adapter.

```
/dev/ttyS0

/dev/ttyUSB0

```

One of the devices is a printer which I tested a usb version (not  serial port), that creates a /dev/usb/lp0 port.

With this printer I performed a basic test:

```

echo abcd > /dev/usb/lp0

```

And it did print succesfully.

With this I eliminate any error with environment or mismatch of locale/encoding that would be a problem with this printer.

Some further testings I am facing a random behavior.

The usb-serial adapter does work with the printer, tested with the following:

```

echo abcd > /dev/ttyUSB0

```

For some reason after passing through the serial-usb adapter to qemu it works afterwards under linux. But it does a jerky job. The data that needs to be communicated is not in a consistent manner unlike windows. I am not sure why is not picking up the data properly.

Furthermore the real serial port with identical settings that off the usb-serial adapter silently fails completely. 

Here is my question, is there a setting or parameter in kernel or module loading or to be done with stty/etc that I might have overlooked?

SERIAL SETTINGS

Now question about serial port settings.

I am confused about what 'flow control' does. This device is working with any of these:

```
-crtscts ixon --> SOFTWARE FLOW CONTROL

crtscts -ixon --> HARDWARE FLOW CONTROL
```

(puzzingly the stty ixoff settings has nothing to do with flow control according to internet, which is in contradiction to m$$ xon/xoff drop down option in the serial driver)

It would help to know whether the m$$ driver setting of XON/XOFF means software flow control, because hyperterminal program doesn't have an option for XON/XOFF but instead "SOFTWARE"

Does "software/hardware flow control" have anything to do with data quality transmition? This question is to rule out the inconsistent behavior of the device.

Which one of the two is better or preferable?

And now the last question about baud rate. The setting on the program 4800 baud rate. Which I can change in source code and up it to 9600.

I am thinking that upping it to 9600 will make it more reliable, perhaps.

Well in the source code I can change the following settings:

```

8-o-1

baud rate

```

^^ those parameters can be change to anything I want to.

My question is whether there's a specific combination that make data transmition more reliable.

The data transmitted is no a big deal nor life-critical, only kilograms, lol. But still I need it to transmit it reliably to make a sell.

I'd would also like to know how to use minicom under linux to perform the exact same test with hyperterminal on m$$.

The most frustating thing having absolutely zero feedback during testing because it's makes it hard where to diganose further the issue.

I wonder whether there's a way to capture data of a serial device. The data is only a few characters in ascii I believe. So is not as complex as TCP/IP at all.

In fact is this: 

```

<stx><st><pppp.ppp><cr><ext>

```

 *Quote:*   

> 
> 
> "value of the weight in ascii and with 8 bytes, including the weight's decimal point and the '-' sign when the net weight is negative. The weight field is left-justified with blank spaces (0x20, 32d). When the weight is out of range, dashes are sent (character 0x2d, 45d) occupying all 8 bytes of the weight field.

 

Thank you.

----------

## Roman_Gruber

you may change your topic title to something else.

it seems you want to know, suggestion for title: how do i use minicom in linux??

second: you may check what lsusb says.

than you may install the required drivers and than you may 

choose a terminal with serial capabilities.

please note 

kernel + userspace (you may call it drivers, but i wont recommend it), + settings and it may works

what i remember on those rs-232 buggers only a few really works other claim to work. just try another dongle 

and you need to set the right protocol on both ends.

and i think the mighty monster called wireshark should be able to watch your serial communications. as wireshark can do so many things(wild guess)

you may check waht you have with lsusb and than google for the related configs... rs-232 was kinda used a lot for microcontrollers in the past and therefore how to use a terminal should be covered when you found what chip you use. e.g. fddi XXXX, ... ...

personal expierence with infineon cr167-lm regarding your baud. higher baud gives more stress to your micronctroller. i would go as low as possible when you have a not important task to handle. 9600 baud, 8 data bits, no parity, was kinda standard in the old days. higher baud rates can cause troubles and break things. i got the best results with 9600 baud.

if you do not have any requiremend for speed, go for 2400 baud, that was the lowest which usually worked. windows 2000 on pentium 3 liked the most 9600 baud. yes it is not technical and yes it is just a statement without much proof but that is / was my expierence. 

you can check for anything which monitors your serial communications, which should be able if you configure your hardware properly.

yuo may check out putty

* net-misc/putty

     Available versions:  0.63_p20141002 **9999 {doc +gtk ipv6 kerberos}

     Homepage:            http://www.chiark.greenend.org.uk/~sgtatham/putty/

     Description:         A Free Telnet/SSH Client

it used to handle rs-232c too afaik, on any os

----------

## szatox

You can also spawn stty and have a terminal attached to that serial port. Just go to /etc/inittab and uncomment this line:

#s0:12345:respawn:/sbin/agetty -L 115200 ttyS0 vt100

or perhaps this, if you have multiple serial ports.

#s1:12345:respawn:/sbin/agetty -L 115200 ttyS1 vt100

This would let you control your computer with a serial console. Roughly the opposite to what minicom is for  :Smile: 

----------

## NeddySeagoon

WWWW,

A few serial comms basics

There are lots of wires in a serial port.  To start with you only need three.  Thats Tx Data Rx Data and ground.  Tx= Transmit  Rx= Receive.

From memory, thats pins 2,3 and 7 in a 9 pin real serial port.

As a test, you can connect pins 2 and 3 together and perform a loopback test.  Keep reading - handshake matters.

With three wires, you have a choice of no handshaking or software handshaking. 

No handshaking means you close your eyes and send data anyway. If the receiving end isn't ready, the data is lost.

On a PC, this works up to about 9600 baud with an unbuffered UART.  I'll avoid going into why.

You won't find unbuffered UARTs in PCs after the XT but you can turn the buffer off if you are not careful.

To go faster than 9600 baud requires a buffer and handshaking.

Software handshaking reserves two characters, X-On and X-Off for the handshake.  This means that you cannot use softmare handshaking if you have a binary data stream as whatever is defined as X-On and X-Off  cannot appear in the data.  The idea is that you can use any data rate the two ends have in common and when the buffer is part full the receiver sends X-Off, which stops the transmitter and avoids dropped caracters.

When the receiver has processed some or all of the buffer, it sends  X-On and the transmitter sends data again.

Thats as good as it gets with only three wires on the interface.

If you add more wires you can do hardware handshaking.  The idea is the same as software handshaking but because there are no reserved symbols you can trasmit binary data.

For loopback testing, you can't type fast enough to get dropped chracters, so no handshake or software handshake will always work.  With hardware handshaking, you must have the handshake pins wired so that data transmission is permitted.  By default, hardware handshaking defaults to sending is not permitted.

Ensure that hardware handshaking is off and play with loopback.  In this state, every character that is tranmitted is received.  

If you have local echo on, each typed character will appear twice. The local echo and the looped back transmit/receive.

Until loopback works, nothing else matters.

Baud rates, start bits, data bits stop bits and parity.

Due to the brain dead design of the PC you cannot set these parameters differently for transmit and receive.  That's glossing over a few points but it does mean you don't care about these settings for loopback testing as they are always the same for transmit and receive.

The baud rate is the data rate on the serial link.   There is no useful default.

Start bits are transmitted on the link before your data and are used to synchronise both ends of the link.

Your data bits follow,

Then there is a paritfy bit (or not)

At the end of the byte are the stop bits.

It doesn't matter much to data transmission reliability what values you use as long as both ends are set to the same thing.

It the PC world, 8 data bits, No parity and 1 stop bit is common.  That's written 8n1, at any baud rate you like, with some form of handshake over 9600 baud. 

Using you favourite terminal emulator, make loopback work and lets take it from there.

One word of warning, RS232 has been around a long time, the various versions will not interoperate without some form of voltage translation.

Indeed the older higher voltage standards will cause the newer lower voltage stanads to self destruct.

Real PC serial ports use +/-12v

USB to serial usually uses +/-5v.

Embedded devices, like ARM SoC often use +/-3.3v

----------

## WWWW

Thanks for the reply.

The explanation about the flow control was really helpful.

My problem here is two pronged:

1- serial not working

2- minicom to troubleshoot

More mysteries. I performed the loopback test by doing the following:

Bridge pins 2 and 3

Terminal A

```

cat /dev/ttyS0

```

Terminal B

```

echo 1234 > /dev/ttyS0

```

The results is complete failure with everything, two different systems with both on-board serial and usb-serial adapter.

Further complicating the issue is that the program does work, (not very reliably), only with usb-serial adapter.

Tried, with identical settings with stty, using /dev/ttyS0 but fails completely.

I even checked BIOS/UEFI , but there was enabled all the time.

My suspicion is in some obscure settings with stty.

I am total loss now. The device is recognize and stty does see it in /dev/ttyS0, because if I try with /dev/ttyS1 fails with input/output error.

I remember doing the loopback test some time age just for fun and it did work.

Any hints for where to look at would be greatly appreciated.

thanks.

----------

## NeddySeagoon

WWWW,

Did you test as root or an unprivilidged user?

It matters as unprivilidged users dont get serial port access.

```
$ ls -l /dev/ttyS0

crw-rw---- 1 root uucp 4, 64 May 12  2013 /dev/ttyS0
```

In my case unprivilidged users need to be in the uucp group.  Look at your omn system, this group has changed over the years.

As I said, on a PC, loopback works without any special settings as its not possible te set up Tx and Rx on the same port differently

----------

