serial communication

ron r · Post by **ron r** » Fri Mar 30, 2012 2:10 pm

Hello. I have tried wine with several open-source systems (Knoppix, PC-BSD, Ubuntu, Fedora), running a windows program that uses serial at 4800 baud to communicate with a measuring device. I notice that wine behaves a little differently with each operating system I run it on, using the exact same hardware (just a different hard drive each time). I also tried wine with 4 different computers, with the various operating systems.

What I see is generally poor or no operation of the serial COM port.
With PC-BSD and Fedora I get no serial operation. With Knoppix I see a slow operation on "fast" computers while older slower computers hang-up on the first attempts to communicate.
Wine on Ubuntu runs the best, almost as good as the program runs on Windows. But that happened when I installed wine using sudo (which I later learned is not recommended) AND copying the program's files directly into a sub-folder off the .wine folder. When I installed wine in Ubuntu (a new installation of Ubuntu) not using sudo, and installed the program "normally" from the CD, that same program would not communicate at all.

There may be a lot of variables going on here, but I wonder if anyone has any thoughts about any of this. Is there anything I could do in the wine configuration (or anywhere) to improve serial operation?

Thank you.

Martin Gregorie · Post by **Martin Gregorie** » Fri Mar 30, 2012 7:16 pm

On Fri, 2012-03-30 at 14:10 -0500, ron r wrote:

Hello. I have tried wine with several open-source systems (Knoppix,
PC-BSD, Ubuntu, Fedora), running a windows program that uses serial at
4800 baud to communicate with a measuring device. I notice that wine
behaves a little differently with each operating system I run it on,
using the exact same hardware (just a different hard drive each time).
I also tried wine with 4 different computers, with the various
operating systems.

What serial port hardware are you using? IME this matters a lot.

I use the Fedora distro. Many releases and 6 years ago, when I started
to run Windows apps that use a serial port to talk to external devices I
had no joy at all with attempts to use USB<->Serial adaptor and
installed a multiport serial board with real 16650 UARTS on it. This
'just worked' and I've had no problems with using it for the same app
over many Fedora and Wine upgrades. I've never needed to reinstall the
app: the automatic Wine prefix upgrades have also 'just worked'.

Recently I replaced the PC, transferring the multiport card into the new
box and upgrading from F13 to F16 at the same time. This app worked
first time when tried after the upgrade.

Martin

lahmbi5678 · Post by **lahmbi5678** » Fri Mar 30, 2012 7:42 pm

In most cases the user doesn't have permision to access serial ports, so you'd first need to add the user to group dialout or take similar action depending on the underlying system. Then you'd add symbolic links like "ln -s /dev/ttyS0 com1", if not already present. With this solution you usually won't need to run as root. For the remaining issues you should file bugs.

Martin Gregorie · Post by **Martin Gregorie** » Sat Mar 31, 2012 5:33 am

On Fri, 2012-03-30 at 19:42 -0500, lahmbi5678 wrote:

In most cases the user doesn't have permision to access serial ports,
so you'd first need to add the user to group dialout or take similar
action depending on the underlying system. Then you'd add symbolic
links like "ln -s /dev/ttyS0 com1", if not already present. With this
solution you usually won't need to run as root. For the remaining
issues you should file bugs.

Access permissions are a good point, which I should not have missed.

In fact the symlinks aren't needed IME (I don't use them at all), but
the symlinks don't affect the access permissions: you need to change the
permissions of the device files, /dev/ttyS*. This used to be something
that you could do at boot time by adding a chmod command
to /etc/rc.d/rc.local but since then device management has moved to the
UDEV system which is more dynamic. These days I simply create a file
that local adds a local access permission rule to UDEV:

======== /etc/udev/rules.d/99-local.rules ========
#
# Give world read/write access to ttyS* and ttyUSB* serial devices
#
KERNEL=="tty[A-Z]*", GROUP="uucp", MODE="0666"
======== /etc/udev/rules.d/99-local.rules ========

The file content is the four lines between the lines starting with
"========". Make sure you keep a copy of this file in a safe place and
remember to reinstate it after a distro reinstall.

This rule sets the permissions to allow all users to access the serial
ports on the motherboard as well as those on my multiport card and
serial USB connections.

A chmod command in /etc/rc.d/rc.local will probably work for serial
ports on the motherboard and multiport adapter cards but will never work
for USB access because it is only run at boot time while these ports
(/dev/ttyUSB*) are only created when a USB device is plugged in and
destroyed when its unplugged. The UDEV rule works because it is run as
part of the port creation.

Martin

ron r · Post by **ron r** » Mon Apr 02, 2012 10:01 pm

Thanks for the replies.

The serial hardware is what is on the motherboard(s) - I don't know any more detail.

I tried "ln -s /dev/ttyS0 com1" and there was no error message, but there was no difference either.
I was going to try entering "chmod 777 ." in the /etc/rc.d/rc.local folder, but I did not find that folder while carefully using the file manager. And I tried this with Ubuntu, Fedora and PC-BSD, each one did not have that exact folder.

I still wonder why one disk installation of ubuntu and wine runs the serial program well, while another disk installation of ubuntu and wine will not see the serial port.

Thank you for any continued suggestions.

Martin Gregorie · Post by **Martin Gregorie** » Tue Apr 03, 2012 5:11 am

On Mon, 2012-04-02 at 22:01 -0500, ron r wrote:

Thanks for the replies.

The serial hardware is what is on the motherboard(s) - I don't know
any more detail.

OK, that's a real UART. If you run the following:

<code>
for f in /dev/ttyS*
do
setserial -a $f
done
</code>

from the terminal you'll see details of all your serial ports. Type it
in in line by line: you'll get a prompt for successive lines up to
'done'. Don't try running it as a single line with semicolon separators:
this just causes syntax errors. Or you can make it into a shell script -
of course. But I digress:

Please post the result of running the command "ls -l /dev/ttyS*". I
think you're seeing a permissions problem.

What version of Fedora did you try this on? If it was F15 or F16 I'm not
altogether surprised that you can't find /etc/rc.d/rc.local because
these and all later releases have replaced the old "System V init"
service management subsystem with the new "systemd" service management
subsystem. This only uses the contents of /etc/rc.d for controlling
legacy daemons, i.e. those still controlled by a script
in /etc/rc.d/init.d. Those that have been converted are now controlled
by *.service recipes in /etc/systemd/system and /lib/systemd/system.

Martin

I tried "ln -s /dev/ttyS0 com1" and there was no error message, but
there was no difference either.
I was going to try entering "chmod 777 ." in the /etc/rc.d/rc.local
folder, but I did not find that folder while carefully using the file
manager. And I tried this with Ubuntu, Fedora and PC-BSD, each one
did not have that exact folder.

I still wonder why one disk installation of ubuntu and wine runs the
serial program well, while another disk installation of ubuntu and
wine will not see the serial port.

Thank you for any continued suggestions.

ron r · Post by **ron r** » Thu Apr 05, 2012 2:25 pm

I am using Fedora 16. Using "ls -l /dev/ttyS*" shows 4 "devices" with "crw-rw----" for each one. So then I looked on google for setting serial permissions, and entered "chmod a+rw /dev/ttyS0" as root and the serial port now works!
That was a nice victory, but the line must be entered at each boot. (Is there a solution to that?)

Thank you, Martin, for the suggestions. I would never have known how to begin to fix the problem.

John Drescher · Post by **John Drescher** » Thu Apr 05, 2012 2:32 pm

That was a nice victory, but the line must be entered at each boot. (Is there a solution to that?)

Put that command in your OS startup scripts. I do not know Fedora so I
can't help with the details..

John

Martin Gregorie · Post by **Martin Gregorie** » Thu Apr 05, 2012 3:18 pm

On Thu, 2012-04-05 at 14:25 -0500, ron r wrote:

I am using Fedora 16. Using "ls -l /dev/ttyS*" shows 4 "devices"
with "crw-rw----" for each one. So then I looked on google for
setting serial permissions, and entered "chmod a+rw /dev/ttyS0" as
root and the serial port now works!
That was a nice victory, but the line must be entered at each boot.
(Is there a solution to that?)

I have this file:
==============File 99-local.rules start===============
#
# Locally defined rules.
#

#
# Give world read/write access to ttyS* and ttyUSB* serial devices
#
KERNEL=="tty[A-Z]*", GROUP="uucp", MODE="0666"
===============File 99-local.rules end================
installed in /etc/udev/rules.d/

There was no file with that name installed by default in my system but
check your system before dropping it in so you don't accidentally
clobber anything. I use the 99 prefix because these rules files are
applied in name sort order and I want to be sure that the device files
have been created before trying to override their access permissions.

Another thing to check: the group assignments for serial port devices
may have changed since I wrote that file, which was for the first Fedora
that used UDEV serial port management, possibly Fedora 12 but could be
earlier. Before you install it, run "ls -l /dev/ttyS*" and, if the group
isn't "uucp" (it may be "tty"), replace that string with the group name
F16 is using.

I know that this time round I just dropped 99-local.rules in without
checking the group name and appended " 8250.nr_uarts=5" to the
GRUB_CMDLINE_LINUX parameter in /etc/default/grub so the kernel knew it
was dealing with five serial ports: I have one on the motherboard and
another four on a multiport serial card. Then I rebooted so the kernel
parameter took effect and it all worked.

Martin

Martin Gregorie · Post by **Martin Gregorie** » Thu Apr 05, 2012 3:35 pm

On Thu, 2012-04-05 at 15:31 -0400, John Drescher wrote:

That was a nice victory, but the line must be entered at each boot. (Is there a solution to that?)

Put that command in your OS startup scripts. I do not know Fedora so I
can't help with the details..

What I've described in my last post should work for any Linux system
using UDEV device management.

It used to be possible to add a chmod command to /etc/rc.d/rc.local BUT:

- I'm not sure that works for any distro that uses systemd service
management instead of System V Init. I think that may be all kernel
3.x systems but don't quote me since I only use Fedora. Fedora
introduced systemd with Fedora 15.

- Since /etc/rc.d/rc.local was only executed at boot time it never did
work for USB adapters and any other hotplugged devices, but the UDEV
rules are applied whenever a device file for a hotplugged device is
created as well as at boot time.

Martin

Usurp · Post by **Usurp** » Thu Apr 05, 2012 7:10 pm

ron r wrote:I am using Fedora 16. Using "ls -l /dev/ttyS*" shows 4 "devices" with "crw-rw----" for each one. So then I looked on google for setting serial permissions, and entered "chmod a+rw /dev/ttyS0" as root and the serial port now works!
That was a nice victory, but the line must be entered at each boot. (Is there a solution to that?)

Thank you, Martin, for the suggestions. I would never have known how to begin to fix the problem.

As lahmbi5678 pointed out, access to the serial port only requires your user to be member of the "dialout" group,
which has read & write access to the ports.
Close your session after adding your user to the group, you should be fine.

Usurp

R3mco · Post by **R3mco** » Sun Jan 13, 2013 4:20 pm

I followed some threads concerning some issues with serial ports,
wine and/or linux (ubuntu).

I use the program 'echolink' (HAM radio application) in conjunction with wine.
It works well, but for whatever reason I am not able to use the
'CTS' pin on one of the ttyS*-ports as PTT (push to talk) input.

What I did:
- create a symbolic link 'com2' in ~/.wine/dosdevices pointing towards /dev/ttyS1
(owner:group of that link is myself, perhaps this has to be changed to e.g. root:dialout ?)

- changed the permissions of /dev/ttyS1 to 666:
crw-rw-rw- 1 root dialout 4, 65 2013-01-12 15:47 ttyS1

- changed access to /dev directory to 777

setserial -a /dev/ttyS1 results in the following output:
/dev/ttyS1, Line 1, UART: 16950/954, Port: 0xe880, IRQ: 17
Baud_base: 4000000, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test

Perhaps it might be an 'unusual' baudbase, but the port is only used to
poll the CTS-pin.

/dev/ttyS1 works well under linux as I am able to program a hand held
transceiver with Chirp succesfully using the ttyS1-interface.

What did I do wrong?

Kind regards,

Remco