1. Configuring LinuxCNC
  3. HAL
  5. Userspace serial communication, cleanup using comp

Userspace serial communication, cleanup using comp

More
11 Jul 2014 16:13 #48643 by DaBit
Replied by DaBit on topic Userspace serial communication, cleanup using comp
cfmakeraw() just resets a bunch of bits to zero and sets CS8. Just like you do in your code; that's exactly what cfmakeraw() does.
I am starting out with a fresh termios structure like everybody does in serial sample code and set CS8, so no need to reset only bits to zero.

I tried getting the current termios settings, cfmakeraw(), modify them to suit my needs (9600baud, 8 databits, even parity, 1 stopbit) and setting them, but that did not make a difference either.

The communication protocol to the VLT5000 VFD is also very simple BTW. You either send a 'shortform telegram' of 8 bytes and get 8 bytes back in return, or you send a 'longform telegram' of 16 bytes and get 16 bytes in return.

Please Log in or Create an account to join the conversation.

More
13 Jul 2014 14:31 #48711 by DaBit
Replied by DaBit on topic Userspace serial communication, cleanup using comp
Argl... :angry:

That usbreset thing worked once. At the next boot, nothing. But when the device was present at boot time and refuses to work unplugging and replugging does not bring it back to life either. It is there, it is recognised, data is tranmitted through it (judging from the Tx LED ont he device), but somehow it does not transmit properly.

The device only works properly when it is not available at boot time but plugged in at a later time.
If it is available at boot time, Linux sees it, does something with it, and my application cannot setup it properly anymore.

When pluggging the device in after boot, this appears in /var/log/syslog:
Jul 13 09:11:24 linuxcnc kernel: usbcore: registered new interface driver ftdi_sio
Jul 13 09:11:24 linuxcnc kernel: USB Serial support registered for FTDI USB Serial Device
Jul 13 09:11:24 linuxcnc kernel: ftdi_sio 2-1.5:1.0: FTDI USB Serial Device converter detected
Jul 13 09:11:24 linuxcnc kernel: usb 2-1.5: Detected FT232RL
Jul 13 09:11:24 linuxcnc kernel: usb 2-1.5: Number of endpoints 2
Jul 13 09:11:24 linuxcnc kernel: usb 2-1.5: Endpoint 1 MaxPacketSize 64
Jul 13 09:11:24 linuxcnc kernel: usb 2-1.5: Endpoint 2 MaxPacketSize 64
Jul 13 09:11:24 linuxcnc kernel: usb 2-1.5: Setting MaxPacketSize 64
Jul 13 09:11:24 linuxcnc kernel: usb 2-1.5: FTDI USB Serial Device converter now attached to ttyUSB1
Jul 13 09:11:24 linuxcnc kernel: ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

At boottime:
usbcore: registered new interface driver ftdi_sio
USB Serial support registered for FTDI USB Serial Device
ftdi_sio 2-1.5:1.0: FTDI USB Serial Device converter detected
usb 2-1.5: Detected FT232RL
usb 2-1.5: Number of endpoints 2
usb 2-1.5: Endpoint 1 MaxPacketSize 64
usb 2-1.5: Endpoint 2 MaxPacketSize 64
usb 2-1.5: Setting MaxPacketSize 64
usb 2-1.5: FTDI USB Serial Device converter now attached to ttyUSB1
ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

No difference.

Also after boot with the device plugged in 'sudo lsof' shows no uses for /dev/ttyUSB1 or it's udev-created symlink /dev/usb_serial_2-1


Now, what the heck is it that Linux does with it at boottime?

Please Log in or Create an account to join the conversation.

More
27 Aug 2014 23:36 #50350 by DaBit
Replied by DaBit on topic Userspace serial communication, cleanup using comp
Finally solved it. Somehow I really have to use the 'NAME=' option in udev rules instead of 'SYMLINK+='. Like this:
dabit@linuxcnc:~/linuxcnc/configs/SnSMill$ cat /etc/udev/rules.d/10-usbtoserial.rules 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", NAME="ttyTOUCH", MODE="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="FTWM00TS", NAME="ttyRS485", MODE="0666"

And then it still creates /dev/ttyUSB0 and /dev/ttyUSB1. Why this works and symlinking does not (works fine for the inputattach used to connect the touchscreen)? Who knows....

But I can connect to /dev/ttyRS485, have a stable and working link to the VFD, and it survives a reboot.

Please Log in or Create an account to join the conversation.

More
28 Aug 2014 02:17 #50360 by ArcEye
Replied by ArcEye on topic Userspace serial communication, cleanup using comp
Well done, the answer is usually found if you don't run out of stamina and interest first :laugh:

udev is a complete subject on its own, I have only ever scratched the surface and been glad to get done what I wanted and leave it alone.

regards

Please Log in or Create an account to join the conversation.

More
28 Aug 2014 03:54 #50369 by DaBit
Replied by DaBit on topic Userspace serial communication, cleanup using comp
Well, soon I will close up the front of the machine (with the PC mainboard in it and inaccessible without removing a panel), and then the 'unplug the USB plug, boot Linux, and plug it in'-sequence becomes a bit awkward. I also put checks around the communication with the VFD so LinuxCNC is going into a halt and the VFD brakes when the communication fails for more than a few packets. Even more awkward :laugh:


Unfortunately the above sequence was not troublefree; /usr/bin/inputattach started complaining about names not equal to kernel names, blah (more beh, actually).
So I changed it into:
KERNEL=="ttyUSB*", KERNELS=="2-1.6", NAME="ttyUSB2", MODE="0666"
KERNEL=="ttyUSB*", KERNELS=="2-1.5", NAME="ttyUSB3", MODE="0666"

Locking the adapters to a specific USB port on the mainboard is not a nice solution, but since these are fixed install, oh wel...
Survived multiple reboots and plugging in more USB devices. Fingers crossed...

I am not totally satisfied though. I cannot use NAME="ttyUSB0" and NAME="ttyUSB1" to force the order, symlinking still doesn't work (inputattach: cannot set line discipline while my vlt5000_vfd userspace component works fine) and now I have four ttyUSB devices. WTF, I am telling the thing how to name the device.... Oh well, it does the job.

Please Log in or Create an account to join the conversation.

  1. Configuring LinuxCNC
  3. HAL
  5. Userspace serial communication, cleanup using comp
Time to create page: 0.201 seconds
Powered by Kunena Forum