Understand RS232 port configuration

B

blackhole

I have working serial ports, via an installed PCI-e card and USB to serial adapters (FTDI and Prolific chips) which are for use with serial connected printers. Comms are established on all devices and works as expected - however.

When issuing the following in an attempt to configure the ports:

Code: 
% stty -f /dev/cuaU0 raw pass8 -echo -hup clocal 115200
% stty -f /dev/cuaU0.init raw pass8 -echo -hup clocal 115200
stty: tcsetattr: Operation not permitted
The first succeeds, but attempting the same on the *.init device node will not allow configuration (except as root). This would not be an issue, but the change to the *.init device is not persistent.

Code: 
% ls -al /dev/cua*
crw-rw----  1 uucp  dialer  0x2a1 Nov 16 15:21 /dev/cuaU0
crw-rw---- 1 uucp dialer 0x2a2 Nov 16 15:19 /dev/cuaU0.init
crw-rw---- 1 uucp dialer 0x2a3 Nov 16 15:19 /dev/cuaU0.lock
crw-rw---- 1 uucp dialer 0x3e Nov 16 11:05 /dev/cuau0
crw-rw---- 1 uucp dialer 0x3f Nov 16 11:05 /dev/cuau0.init
crw-rw---- 1 uucp dialer 0x40 Nov 16 11:05 /dev/cuau0.lock

Code: 
% cat /etc/devfs.rules
[system=10]
add path 'unlpt*' mode 0660 group operator
add path 'ulpt*' mode 0660 group operator
add path 'lpt*' mode 0660 group operator
add path 'usb/X.Y.Z' mode 0660 group operator
add path 'dri/*' mode 0666 group operator
add path 'drm/*' mode 0666 group operator
add path 'cuau*' mode 0660 group dialer
add path 'cuaU*' mode 0660 group dialer

After hotplugging:

Code: 
% stty -f /dev/cuaU0
speed 9600 baud;
lflags: echoe echoke echoctl
oflags: tab0
cflags: cs8 -parenb clocal
It reverts to defaults.

I'm sure I'm missing something obvious here, or should I be configuring the lock device?

Thanks
 
cynwulf said:
which are for use with serial connected printers
Click to expand...
Do those still exist? Last serial printer I saw was well over 25 years ago. And even back then printers tended to use "Centronics" parallel connections. And those have pretty much disappeared too. It's all USB or network connected nowadays.
 
Yes, these are thermal barcode printers manufactured by e.g. TSC, Toshiba, Datamax, Citizen, Zebra, etc. Some of the machines are very old, but well made and still serviceable and rather than throw them away I connect them via USB to serial adaptors and put them to good use. Even the newer machines often still come with RS232 ports.

Some of the machines also have parallel ports but those ports have vanished from modern PCs and some of the newer printers - and the adaptors are not the most robust or reliable (although they actually behave far better under FreeBSD or Linux than when used in MS Windows).
 
The devfs.rules files says that the devices should be owned by group operator. They are owned by group dialer. Something is wrong here. What does the line [system=10] in your devfs.rules file mean? I don't know; maybe check whether these rules are even being applied.

Read the handbook chapter about serial ports, it explains the difference between .init and .lock devices, and points at the correct man pages. I don't know why the .init device is refusing certain settings. But it makes sense that after hotplugging, the settings vanish, since unplugging a USB device causes it to vanish, and when you replug it, a new one (with the same name) will be created. Where would the old settings be stored?
 
ralphbsz, "system" is the name of the ruleset. It's loaded via rc.conf. I followed the man page for devfs.rules(5) but called it "system". I can't recall why its set to 10, but again the man page suggests this. The call out devices are defined as dialer group in devfs.rules (right at the bottom). I can configure those as a normal user, but not the *.init devices.

Martin, yes I've seen that and I think ralphbz is correct that hotplugging clears any parameters as the device is recreated. That makes sense to me, but I'll have find another solution. Thank to all for the advice.
 
cynwulf said:
Martin, yes I've seen that and I think ralphbz is correct that hotplugging clears any parameters as the device is recreated. That makes sense to me, but I'll have find another solution. Thank to all for the advice.
Click to expand...
You could create a few custom devd.conf(5) rules for these devices. That could apply the settings as soon as the device is plugged in.
 
What is happening is that every time you insert the USB device the files are created (devices, .init .lock), when you remove it the files are deleted and therefore the initial configuration is lost
 
Created two devd.conf(5) rules for both types of devices and works perfectly:

Code: 
# FTDI
attach 100 {

device-name "uftdi0";
action "stty -f /dev/cuaU0.init raw pass8 -echo -hup clocal 115200";
};

# Prolific
attach 100 {

device-name "uplcom0";
action "stty -f /dev/cuaU0.init raw pass8 -echo -hup clocal 115200";
};

Thanks to all.

(note: I will only install one of either device, so catering for sequential device nodes, or both being plugged in at the same time, but only cuaU0 being configured, is not so important in my case)
 
Ok so it bugged me and I decided to redo it so that at least two USB to serial adapters are configured when plugged in and don't have to be matched to any particular vendor/chip:

This is in my /usr/local/etc/devd/some_rules.conf
Code: 
notify 0 {
        match "cdev" "cuaU0";
        action "stty -f /dev/cuaU0.init raw pass8 -echo -hup clocal 115200";
};

notify 0 {
        match "cdev" "cuaU1";
        action "stty -f /dev/cuaU1.init raw pass8 -echo -hup clocal 115200";
};
 
You must log in or register to reply here.
Back
Top