Hello!

I'm trying to make a BASH script that will communicate with a device over the serial port ttyS0 or ttyS1.

The problem is that when I start the script I do not now whether the device will be connected to S0 or S1. How can I check where it is?
Is there a way to check if something is plugged to the serial port?

Thanks in advance

Hello,

You should be able to run the tty command: it will tell you what tty you are connecting through.

--jason

0 members found this post helpful.

First of all, bash is a really really poor way to do serial communications. Almost anything else would be better.

If you don't know which port is connected to the device, then the only alternative would be to issue queries to the device on both ports, and see which query results in the expected response. This may have undesirable side effects, like putting the device in an undesired state, adversely affecting some other device on the other port, and prolonged timeouts waiting for a reply that will never arrive.
The other alternative is to prompt the user for the information.

--- rod.

1 members found this post helpful.

Can you create a udev rule for the device that creates a symlink with a specific name? Is it possible for the script to have more than one target device connected at a time?
Kevin Barry

theNbomr, I just hoped to hear something different of what I was afraid of
thanks

ta0kira, what did you mean by using udev and symbolic links? I don't understand you. In my script I do not connect to multiple devices, but only one target device... Do you have any idea? I'd like to hear it...

If the physical device is always the same, you can create a rule for the udev daemon such that when it sees an attached device with a certain property (e.g. a serial number) it creates a symlink of your choice. For example, you could set it up so that no matter if the device is mapped to ttyS0 or ttyS1 there would be a symlink such as /dev/my-serial-dev to whichever ttyS? it is. This is entirely independent of your script; you would have your script check for /dev/my-serial-dev rather than ttyS?.

This is a good reference for udev rules, and it's good to know in general. You need udevadm instead of udevinfo (as is shown in the guide), however.
http://reactivated.net/writing_udev_rules.html

They're really easy to set up once you get the hang of it.
Kevin Barry

But really, isn't that the same problem & solution, but just transferred to a boot-time script?

--- rod.

Not really; this solution solves the problem of figuring out which special file in /dev is the right one to use regardless of what type of script or program is to access it. The difference is that udev is specialized for detecting devices based on specific criteria. It merely restates the question from "which device is it?" to "is the device connected?" A simple [ -e /dev/my-serial-dev ] from bash or stat from C can answer the second question, then OP can move on to the issue of accessing the device.

As an example of how simple it is, relative to the work it would require in bash or C, I use this rule (in /etc/udev/rules.d) to create a symlink for a USB backup drive when it's connected:The ATTRS check came directly from udevadm info --attribute-walk --path=/sys/block/sdb (where sdb was the USB drive at the time).
Kevin Barry

I don't see how that answers the original question:It sounds like the OP is trying to establish whether or not some kind of instrument is connected (where the definition of 'connected' can probably mean a few different things) to a serial port. Are you saying that udev possesses some special ability to make that determination? If so, what is it that makes udev uniquely capable? I do agree that moving the problem away from the application domain may have some benefit.

Or, are we talking about two distinct problems?

--- rod.

Honestly, I don't know how udev works for serial-port devices. In the case of USB devices, the answers to your questions are "yes" and "because that's what it's designed to do". It should work so long as udevadm provides information that can discriminate between a valid device and an invalid device. That should be the case unless the kernel itself has no information about the device that's connected.

Here are the assumptions I've made:

1. The sysfs information for /dev/ttyS? changes if something is plugged into or unplugged from the respective serial port.
2. That information is enough to decide if the connected device is the "correct" one.

These assumptions can be tested if OP does the following:

1. Plug in the "correct" device and determine manually which ttyS? it belongs to.
2. Post the output of udevadm info --attribute-walk --path=/sys/class/tty/ttyS? with "?" replaced with the correct digit.
3. Unplug the device and wait 10-15s, then post the output of the same command.

If the two outputs are the same then udev will fail. If something in the output of 2. allows the device to be uniquely identified over "incorrect" devices, a udev rule should do the trick.
Kevin Barry

I agree with theNbomr that udev will not work and that "devices" and "connected" have slightly different meanings. udev will not detect if there is something plugged into the serial port connector. I do not know of another method then to probe the ports to see what responds.

On the other hand why do you not know which port the device is plugged into?

ta0kira, I think your assumptions are flawed:

• The sysfs information for /dev/ttyS? changes if something is plugged into or unplugged from the respective serial port

  Serial ports are somewhat like ethernets. There is no way to know what is attached whithout querying in some way.

• In the case of USB devices, the answers to your questions are "yes" and "because that's what it's designed to do".

  USB and serial are two completely different animals. If serial ports or their drivers could determine what was attached to them, we wouldn't need things like the terminfo database. USB is designed with PNP functionality in mind.

You suggest 'Plug in the "correct" device and determine manually which ttyS? it belongs to'. This sounds like the OPs original question, which I interpret to be the part about making a manual determination.

In my work, it is not unusual for devices to be connected to serial ports without knowing which one. People connect & disconnect instruments at random, and the computers are often in remote locations. It is often difficult to make appropriate guesses about whether a device is disconnected, connected but off-line, connected and active, etc. Some devices respond to standard queries (like *IDN?) about their nature. Modems that implement the Hayes standard can usually be queried reliably. The SCPI protocol used by many test and measurement instruments helps with this problem, but sadly most devices don't implement that protocol, or only use it on GPIB interfaces.

--- rod.

Excuse me for vamping this thread, I just wanted to thank you for your help and opinion, and to leave conclusion for future reference.

Rod, you were right. What you said in your last post is just what was bothering me. So! Checked conclusion:
ttyS? (win COM) port need to be probed in order to determine if it's connected(plugged in).

Reason:
udev is waiting for interrupt to be detected.
ttyS? (aka WinCOM port) is not generating interrupts when it is plugged in. Therefor udev is not appropriate to detect it's presence, and need to be probed.

Sorry it took me so long to respond, I simply had no time to check ta0kira's statements. Nevertheless, ta0kira thank you
Greetings,
Vladimir

Hi.

Just curious, is there are serial port (a DE-9 connector) on modern computers? As a pampered laptop user I thought they are quite rare. I use a usb-to-serial converter (junk nokia data cable) to talk to serial devices because
0) there are no serial port on my laptop;
1) every modern computer have usb port;
2) udev allows to detect if the cable is plugged in or not (see here for example).