Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Serial comunication over USB (Linux)

216 views
Skip to first unread message

Gerhard Reithofer

unread,
Sep 27, 2017, 2:57:36 PM9/27/17
to
Hi TCLers,
I woud like to communicate with my new 3d printer using the existing USB
interface. The hardware is proprietary and no detailed information
exists about the USB interface, except the serial line configuration
values.

TCL's "open" manpage: "Valid values for fileName to open a serial port
are generally of the form /dev/ttyX, where X is a or b, but the name of
any pseudo-file that maps to a serial port may be used ..."

Using the device information I can find the USB device path and I tried
it to open it as serial device:

$ lsusb -d 2b71:
Bus 002 Device 027: ID 2b71:0001

$ ls -l /dev/bus/usb/002/027
crw-rw-rw- 1 root root 189, 154 Sep 27 16:31 /dev/bus/usb/002/027

$ tclsh
% set conn [open /dev/bus/usb/002/027 {RDWR}]
file3
% fconfigure $conn -mode "115200,8,n,1" -handshake "none"
bad option "-mode": should be one of -blocking, -buffering, -buffersize,
-encoding, -eofchar, or -translation

My question is: How does TCL recognize that this pseudo-file is no
serial device?

And further: Any ideas to make this access possible?

TIA,
Gerhard

--
Gerhard Reithofer - Techn. EDV Reithofer - http://www.tech-edv.co.at

Harald Oehlmann

unread,
Sep 27, 2017, 4:11:30 PM9/27/17
to
Am 27.09.2017 um 20:56 schrieb Gerhard Reithofer:
> And further: Any ideas to make this access possible?

% set conn [open /dev/ttyACM0 {RDWR}]
% fconfigure $conn -mode "115200,8,n,1" -handshake "none"

Just a guess,
Harald

undro...@gmail.com

unread,
Sep 27, 2017, 4:16:01 PM9/27/17
to
Am Mittwoch, 27. September 2017 20:57:36 UTC+2 schrieb Gerhard Reithofer:

> My question is: How does TCL recognize that this pseudo-file is no
> serial device?

The system call isatty(...) returns 0.

> And further: Any ideas to make this access possible?

searching for USB vendor ID 2b71, product ID 0001 yields nothing, unfortunately.
Thus, poor Linux can't associate a driver.

mango

unread,
Sep 27, 2017, 4:41:02 PM9/27/17
to
I usually use dmesg(1) to see which serial device was attached. For example,
if I plug in an FTDI based device I see:

[ 190.364625] usb 1-3.1.4: new full-speed USB device number 9 using xhci_hcd
[ 190.483545] usb 1-3.1.4: New USB device found, idVendor=0403, idProduct=6001
[ 190.483552] usb 1-3.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 190.483558] usb 1-3.1.4: Product: FT232R USB UART
[ 190.483562] usb 1-3.1.4: Manufacturer: FTDI
[ 190.483566] usb 1-3.1.4: SerialNumber: A503PXN6
[ 190.514728] usbcore: registered new interface driver usbserial
[ 190.515028] usbcore: registered new interface driver usbserial_generic
[ 190.515101] usbserial: USB Serial support registered for generic
[ 190.518183] usbcore: registered new interface driver ftdi_sio
[ 190.518202] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 190.518352] ftdi_sio 1-3.1.4:1.0: FTDI USB Serial Device converter detected
[ 190.518450] usb 1-3.1.4: Detected FT232RL
[ 190.518736] usb 1-3.1.4: FTDI USB Serial Device converter now attached to ttyUSB0

And /dev/ttyUSB0 is now available. Note that you may need to deal with permissions to
write to the device:

$ ls -l /dev/ttyUSB0
crw-rw-r-- 1 root dialout 188, 0 Sep 27 13:30 /dev/ttyUSB0


I solve the permissions problem by adding myself to the "dialout" group.
The old modem reference is quaint.

Andrew Mangogna

Robert Heller

unread,
Sep 27, 2017, 5:14:08 PM9/27/17
to
At Wed, 27 Sep 2017 20:56:41 +0200 Gerhard Reithofer <gerhard....@tech-edv.co.at> wrote:

>
> Hi TCLers,
> I woud like to communicate with my new 3d printer using the existing USB
> interface. The hardware is proprietary and no detailed information
> exists about the USB interface, except the serial line configuration
> values.
>
> TCL's "open" manpage: "Valid values for fileName to open a serial port
> are generally of the form /dev/ttyX, where X is a or b, but the name of
> any pseudo-file that maps to a serial port may be used ..."

Note: What Tcl calls a "Serial Port" is a RS232 or RS485 port, what on an
"old" PC would have been a DB-25 (really old PC) or a DB-9 (moderatly old PC).
These ports would be commonly connected to something like a telephone modem
(remember those?) or even a teletype device (usually a "glass" successor to a
Model 33, eg a VT52, VT100, or something like that). There were (back in the
day) other devices that used the RS232 interface: some serial printers, serial
mice, and other things (I have a EPROM programmer that uses the RS232
interface, a DCC interface that uses RS232, and several C/MRI SuperMini boards
that use the RS485 interface).

The USB interface is something *completely different* and bears absolutely no
relation to a "Serial Port". A USB "port" is NOT a "Serial Port".

There is a "class" of USB devices that bind to psuedo RS232-ish "serial
ports". These are either devices that have a good old DB-9 connector (just
like on those moderately old PCs) or they have the RS232 "pins" 'wired' into a
uProcessor (this is what the Arduino does, as is also the case for some USB
connected modems and various other interesting devices (like all of the USB
connected DCC devices, the CTI Acela, the RR Cirkits LCC Buffer-USB, to name a
few). All of these devices show up as either a /dev/ttyACMn (if they are
using a modem-flavored chip) or /dev/ttyUSBn (otherwise -- basicly it is the
driver's choise). All of these devices can be treated just like a real live
RS232 device and Tcl is happy to open them up and do all of the Serial Port
things with them. Note: not all "Serial Port" chips are supported in all
Linux kernels. If this thing really is a "Serial Port", you might need to get
a kernel driver module for it. What verison of Linux are you running? What
does 'uname -a' spit out?

>
> Using the device information I can find the USB device path and I tried
> it to open it as serial device:
>
> $ lsusb -d 2b71:
> Bus 002 Device 027: ID 2b71:0001
>
> $ ls -l /dev/bus/usb/002/027
> crw-rw-rw- 1 root root 189, 154 Sep 27 16:31 /dev/bus/usb/002/027
>
> $ tclsh
> % set conn [open /dev/bus/usb/002/027 {RDWR}]
> file3
> % fconfigure $conn -mode "115200,8,n,1" -handshake "none"
> bad option "-mode": should be one of -blocking, -buffering, -buffersize,
> -encoding, -eofchar, or -translation
>
> My question is: How does TCL recognize that this pseudo-file is no
> serial device?

Short answer wrong driver interface. (See above for the long answer.)

>
> And further: Any ideas to make this access possible?

1) beg, borrow, or steal a copy of the Mess-Windows device driver or SDK:
You may be able to get away with the "SDK" for this device -- *some*
companies offer a free SDK package that you can use to reverse engineer a
"driver". You can then write a user-mode driver in C/C++ using libusb and
create a Tcl interface binding with SWIG. I did this with the PI
Engineering Raildriver (later rewrote things to use the HID API, because
that was a more cross-platform option). (I also did this with the Azatrax
MRD2 devices -- there I was approached by the designer for just that
purpose and he provided detailed docs.) (All of the code for this is
available on GitHub: https://github.com/RobertPHeller/ModelRRSystem and
there are pure Tcl coded "drivers" for various serial port flavered devices
as well.)

2) you could get lucky: check what dmesg blathers about when you plug the
device in:
a) unplug the device
b) type in a terminal window:
'tail -f /var/log/dmesg'
(alternitively, type 'dmesg | tail -30' *after* pluging in the device).
Then plug the device in. There will be blather about a 'new' USB device.
*If* the blather talks about /dev/ttyACM<mumble> or /dev/ttyUSB<mumble>,
you have a shot of accessing the device directly from Tcl without
resorting to the C/C++ compiler, libusb, and fun with the likes of SWIG.
Note: you will still need to know or figure out the "protocol" used to
talk to the device (control character fun? Lines of ASCII text? Async
fun? etc.), so it might be worth the beg/borrow/steal game
mentioned above.

>
> TIA,
> Gerhard
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

Gerhard Reithofer

unread,
Sep 28, 2017, 7:08:05 AM9/28/17
to
Thank you all for so much feedback.

I will anwser all replied in this thread only, so it'l getting an bit
long.

@Harald Oehlmann

> % set conn [open /dev/ttyACM0 {RDWR}]

The only "user-writable" device in /dev is the node /dev/tty. There are
also some ttyS[0-3] which are group writable for "dialout", these are
"real serial" devices.
The /dev/tty entry matches the udev-rule in
/etc/udev/rules.d/99-flashforge.rules:
SUBSYSTEM=="tty",ATTRS{idVendor}=="23c1",MODE="0666"
Same filemode (crw-rw-rw-) as in my example and same reaction, i.e. bad
option "-mode".

The other lsusb-matching entry is:
SUBSYSTEM=="usb",SUBSYSTEMS=="usb",DRIVERS=="usb",ATTRS{idVendor}=="2b71",MODE="0666"
This only exists exists as /dev/usb/usb/002/029 (last number individualy
assigned by the system). Anything else does not allow direct user
accesss and the suid bit isn't set on the executable.


@undroidwish@...
> The system call isatty(...) returns 0.

Thanks, I will take a look into this call.

> searching for USB vendor ID 2b71: ... unknown ...
I know, but it is used by 2 programs on my system - see also dmesg info
below.


@mango
The dmesg info is:
Sep 28 10:59:31 mecano kernel: [851647.142305] usb 2-2: USB disconnect,
device number 27
Sep 28 10:59:42 mecano kernel: [851657.497205] usb 2-2: new full-speed
USB device number 28 using xhci_hcd
Sep 28 10:59:42 mecano kernel: [851657.806258] usb 2-2: New USB device
found, idVendor=0315, idProduct=0001
Sep 28 10:59:42 mecano kernel: [851657.806261] usb 2-2: New USB device
strings: Mfr=1, Product=2, SerialNumber=3
Sep 28 10:59:42 mecano kernel: [851657.806262] usb 2-2: Product:
FlashForge Dreamer 3D Printer
Sep 28 10:59:42 mecano kernel: [851657.806263] usb 2-2: Manufacturer:
Flashforge
Sep 28 10:59:42 mecano kernel: [851657.806265] usb 2-2: SerialNumber:
00000000050C
Sep 28 10:59:42 mecano mtp-probe: checking bus 2, device 28:
"/sys/devices/pci0000:00/0000:00:1c.2/0000:02:00.0/usb2/2-2"
Sep 28 10:59:42 mecano mtp-probe: bus: 2, device: 28 was not an MTP
device

Can't interprete the information :-(


@Robert Heller
That's really much information :-)
I will also take a look at you GIT repo.

All what I know:
The device can be used by the delivered software (3d-printer
manufacturer) on Linux, even if the SW quality is not very well it does
what I need.
Another 3rd party program is also able to use that USB interface.
Therefore I think, that it could also be used within TCL.

I also investigated the already existing WLAN interface which is a
simple TCL-socket connection and it can be used from TCL easily. But as
it is not guarranteed that I have LAN/WLAN environment I would like the
use the direct connection via USB to be ore flexible.
The same protocol (Lines of ASCII text and binary blocks) is used by the
USB comminication, some people have sniffed it on Windows.

This is the main reason why I also would like to use my hardware using
TCL as it could be possible.


Thank you for all your time and effort to help me to solve my problem.
Please do not invest more time except you have very detailed and
promisingly information for the USB access.

I will keep you informed if I will be successful.

PS: Did I say that this is real, real great forum? ;-)
PPS: Did I say that I dislike closed source software more and more ;-)
:-(

Bye,

Robert Heller

unread,
Sep 28, 2017, 7:34:37 AM9/28/17
to
It just says it is not a Serial Port device, nor is it a Line Printer device.

Or if it is a Serial Port device, it is not a known one. This means you
either need a kernel driver module OR you need to hack an existing kernel
driver module.

>
>
> @Robert Heller
> That's really much information :-)
> I will also take a look at you GIT repo.
>
> All what I know:
> The device can be used by the delivered software (3d-printer
> manufacturer) on Linux, even if the SW quality is not very well it does
> what I need.
> Another 3rd party program is also able to use that USB interface.
> Therefore I think, that it could also be used within TCL.

Probably not directly. You will probably need to write a libusb driver, in C
or C++ and then use SWIG to interface that to Tcl.

>
> I also investigated the already existing WLAN interface which is a
> simple TCL-socket connection and it can be used from TCL easily. But as
> it is not guarranteed that I have LAN/WLAN environment I would like the
> use the direct connection via USB to be ore flexible.
> The same protocol (Lines of ASCII text and binary blocks) is used by the
> USB comminication, some people have sniffed it on Windows.
>
> This is the main reason why I also would like to use my hardware using
> TCL as it could be possible.
>
>
> Thank you for all your time and effort to help me to solve my problem.
> Please do not invest more time except you have very detailed and
> promisingly information for the USB access.
>
> I will keep you informed if I will be successful.
>
> PS: Did I say that this is real, real great forum? ;-)
> PPS: Did I say that I dislike closed source software more and more ;-)
> :-(
>
> Bye,
> Gerhard
>

--

Rich

unread,
Sep 28, 2017, 11:45:43 AM9/28/17
to
Gerhard Reithofer <gerhard....@tech-edv.co.at> wrote:
> Thank you all for so much feedback.
>
> I will anwser all replied in this thread only, so it'l getting an bit
> long.
>
> @Harald Oehlmann
>
>> % set conn [open /dev/ttyACM0 {RDWR}]
>
> The only "user-writable" device in /dev is the node /dev/tty. There are
> also some ttyS[0-3] which are group writable for "dialout", these are
> "real serial" devices.
> The /dev/tty entry matches the udev-rule in
> /etc/udev/rules.d/99-flashforge.rules:
> SUBSYSTEM=="tty",ATTRS{idVendor}=="23c1",MODE="0666"
> Same filemode (crw-rw-rw-) as in my example and same reaction, i.e. bad
> option "-mode".

This /dev/tty device is from vendor 23c1.

> The other lsusb-matching entry is:
> SUBSYSTEM=="usb",SUBSYSTEMS=="usb",DRIVERS=="usb",ATTRS{idVendor}=="2b71",MODE="0666"
> This only exists exists as /dev/usb/usb/002/029 (last number individualy
> assigned by the system). Anything else does not allow direct user
> accesss and the suid bit isn't set on the executable.

This usb device is from vendor 2b71 (different from 23c1), therefore
this appears to be two different devices.

As well, the /dev/usb/usb/002/029 device is a low level exposure of the
USB device (not a serial port as in 16550 UART serial port) but the raw
USB device itself. Which is why Tcl has issues with it, it is not a
"serial port".

> @undroidwish@...
>> The system call isatty(...) returns 0.
>
> Thanks, I will take a look into this call.
>
>> searching for USB vendor ID 2b71: ... unknown ...
> I know, but it is used by 2 programs on my system - see also dmesg info
> below.

Programs that know how to use specific USB devices can do so using the
/dev/usb/usb/002/029 device files without needing a kernel driver
loaded for the specific hardware. It is likely that the two programs
are making direct USB access to the hardware, not going through a
kernel driver.

>
>
> @mango
> The dmesg info is:
> Sep 28 10:59:31 mecano kernel: [851647.142305] usb 2-2: USB disconnect,
> device number 27
> Sep 28 10:59:42 mecano kernel: [851657.497205] usb 2-2: new full-speed
> USB device number 28 using xhci_hcd
> Sep 28 10:59:42 mecano kernel: [851657.806258] usb 2-2: New USB device
> found, idVendor=0315, idProduct=0001
> Sep 28 10:59:42 mecano kernel: [851657.806261] usb 2-2: New USB device
> strings: Mfr=1, Product=2, SerialNumber=3
> Sep 28 10:59:42 mecano kernel: [851657.806262] usb 2-2: Product:
> FlashForge Dreamer 3D Printer
> Sep 28 10:59:42 mecano kernel: [851657.806263] usb 2-2: Manufacturer:
> Flashforge
> Sep 28 10:59:42 mecano kernel: [851657.806265] usb 2-2: SerialNumber:
> 00000000050C
> Sep 28 10:59:42 mecano mtp-probe: checking bus 2, device 28:
> "/sys/devices/pci0000:00/0000:00:1c.2/0000:02:00.0/usb2/2-2"
> Sep 28 10:59:42 mecano mtp-probe: bus: 2, device: 28 was not an MTP
> device
>
> Can't interprete the information :-(

Was that the end of the kernel messages from plugging in the device?
If so, then the kernel recognized it as a device from vendor 0315 but
did not find any Linux kernel driver to associate it against. So you
won't have a /dev/tty??? or /dev/lpt??? device for it. You'll only
have the raw USB /dev/usb/usb/002/029 item instead.

> All what I know:
> The device can be used by the delivered software (3d-printer
> manufacturer) on Linux, even if the SW quality is not very well it does
> what I need.
> Another 3rd party program is also able to use that USB interface.
> Therefore I think, that it could also be used within TCL.

If the delivered software uses the /dev/usb/usb/002/029 device to
access the raw USB interface, then that is why it 'works' with the
installed software, even without a proper kernel driver loaded for the
unit.

Robert Heller

unread,
Sep 28, 2017, 1:08:23 PM9/28/17
to
Right. That is what libusb is for. There exists a "Generic USB driver" module,
that libusb talks to with lowlevel kernel io calls (and yes, it is possible to
do your own lowlevel kernel io calls, but why re-invent the wheel?). Tcl can't
do that, but it is not hard to write a "user mode driver" in C or C++ using
libusb and then using SWIG to make that driver library callable from Tcl.
It is highly likely that the working software is in fact using libusb.
0 new messages