Turning USB into a terminal
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
I have a hardware device that connects via USB without creating a specific /dev/something. It does change the time on /dev/ptmx and /dev/char but that's about it. All I know are the VID:PID of the device and the documentation says that the USB (should) act as a serial device at 921600 8N1. If I were able to connect I should be able to send simple text commands (SCSI) to it, like on a serial interface.
I'm pretty sure I can use libusd or libhid to connect to it, but it's time consuming writing communication code from scratch. Isn't there some linux trick to create a /dev/ttySomething so I can communicate with minicom or simple C programs ?
$ dmesg
usb 1-2: new full-speed USB device number 7 using xhci_hcd
usb 1-2: New USB device found, idVendor=104d, idProduct=3001
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: ESP301 Motion Control
usb 1-2: Manufacturer: NEWPORT Corp.
usb 1-2: SerialNumber: 0000000000000000
$ lsusb -v
Bus 001 Device 007: ID 104d:3001 Newport Corporation
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x104d Newport Corporation
idProduct 0x3001
bcdDevice 1.01
iManufacturer 1 NEWPORT Corp.
iProduct 2 ESP301 Motion Control
iSerial 3 0000000000000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 2
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 1
Device Status: 0x0001
Self Powered
usb c serial-port minicom
|
show 2 more comments
up vote
0
down vote
favorite
I have a hardware device that connects via USB without creating a specific /dev/something. It does change the time on /dev/ptmx and /dev/char but that's about it. All I know are the VID:PID of the device and the documentation says that the USB (should) act as a serial device at 921600 8N1. If I were able to connect I should be able to send simple text commands (SCSI) to it, like on a serial interface.
I'm pretty sure I can use libusd or libhid to connect to it, but it's time consuming writing communication code from scratch. Isn't there some linux trick to create a /dev/ttySomething so I can communicate with minicom or simple C programs ?
$ dmesg
usb 1-2: new full-speed USB device number 7 using xhci_hcd
usb 1-2: New USB device found, idVendor=104d, idProduct=3001
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: ESP301 Motion Control
usb 1-2: Manufacturer: NEWPORT Corp.
usb 1-2: SerialNumber: 0000000000000000
$ lsusb -v
Bus 001 Device 007: ID 104d:3001 Newport Corporation
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x104d Newport Corporation
idProduct 0x3001
bcdDevice 1.01
iManufacturer 1 NEWPORT Corp.
iProduct 2 ESP301 Motion Control
iSerial 3 0000000000000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 2
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 1
Device Status: 0x0001
Self Powered
usb c serial-port minicom
If it should act as a serial device, it likely implements one of the standard USB classes. First step is to uselsusb -v
etc. to find out if the descriptors say that it actually does, second step is to checkdmesg
after plugin to find out if the correct modules get loaded. Depending on the outcome, you know where the problem is (device providing non-standard descriptors, kernel modules not present etc.).
– dirkt
Nov 29 at 10:27
I added lsusb to my question
– dargaud
Nov 29 at 10:41
As you can see, it's a vendor specific class. So either there is a vendor specific way to switch the USB interface to a standard class (did you get any Windows programs for the device?), or you do have to implement the vendor specific protocol (whatever it is) yourself, via libusb or otherwise. In the current configuration, it's also not a HID device (though HID devices are not usually used for serial devices in the first place).
– dirkt
Nov 29 at 11:31
1
Googling finds this manual with a code example at the end, usingNewport.ESP301.CommandInterface.dll
, which seems to implement a virtual Windows COM-port. In your place I'd run this example in a VM and monitor USB traffic to see how the protocol works, and if it switches to a standard USB configuration first.
– dirkt
Nov 29 at 11:35
OK, thanks, I can use libusb or even more simply a direct physical serial cable on another port of the device; so I guess I was wrong that there was a simple linux way to turn a USB into a pseudo-serial terminal.
– dargaud
Nov 30 at 9:46
|
show 2 more comments
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have a hardware device that connects via USB without creating a specific /dev/something. It does change the time on /dev/ptmx and /dev/char but that's about it. All I know are the VID:PID of the device and the documentation says that the USB (should) act as a serial device at 921600 8N1. If I were able to connect I should be able to send simple text commands (SCSI) to it, like on a serial interface.
I'm pretty sure I can use libusd or libhid to connect to it, but it's time consuming writing communication code from scratch. Isn't there some linux trick to create a /dev/ttySomething so I can communicate with minicom or simple C programs ?
$ dmesg
usb 1-2: new full-speed USB device number 7 using xhci_hcd
usb 1-2: New USB device found, idVendor=104d, idProduct=3001
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: ESP301 Motion Control
usb 1-2: Manufacturer: NEWPORT Corp.
usb 1-2: SerialNumber: 0000000000000000
$ lsusb -v
Bus 001 Device 007: ID 104d:3001 Newport Corporation
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x104d Newport Corporation
idProduct 0x3001
bcdDevice 1.01
iManufacturer 1 NEWPORT Corp.
iProduct 2 ESP301 Motion Control
iSerial 3 0000000000000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 2
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 1
Device Status: 0x0001
Self Powered
usb c serial-port minicom
I have a hardware device that connects via USB without creating a specific /dev/something. It does change the time on /dev/ptmx and /dev/char but that's about it. All I know are the VID:PID of the device and the documentation says that the USB (should) act as a serial device at 921600 8N1. If I were able to connect I should be able to send simple text commands (SCSI) to it, like on a serial interface.
I'm pretty sure I can use libusd or libhid to connect to it, but it's time consuming writing communication code from scratch. Isn't there some linux trick to create a /dev/ttySomething so I can communicate with minicom or simple C programs ?
$ dmesg
usb 1-2: new full-speed USB device number 7 using xhci_hcd
usb 1-2: New USB device found, idVendor=104d, idProduct=3001
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: ESP301 Motion Control
usb 1-2: Manufacturer: NEWPORT Corp.
usb 1-2: SerialNumber: 0000000000000000
$ lsusb -v
Bus 001 Device 007: ID 104d:3001 Newport Corporation
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x104d Newport Corporation
idProduct 0x3001
bcdDevice 1.01
iManufacturer 1 NEWPORT Corp.
iProduct 2 ESP301 Motion Control
iSerial 3 0000000000000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 2
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 1
Device Status: 0x0001
Self Powered
usb c serial-port minicom
usb c serial-port minicom
edited Nov 29 at 10:41
asked Nov 28 at 13:55
dargaud
2211310
2211310
If it should act as a serial device, it likely implements one of the standard USB classes. First step is to uselsusb -v
etc. to find out if the descriptors say that it actually does, second step is to checkdmesg
after plugin to find out if the correct modules get loaded. Depending on the outcome, you know where the problem is (device providing non-standard descriptors, kernel modules not present etc.).
– dirkt
Nov 29 at 10:27
I added lsusb to my question
– dargaud
Nov 29 at 10:41
As you can see, it's a vendor specific class. So either there is a vendor specific way to switch the USB interface to a standard class (did you get any Windows programs for the device?), or you do have to implement the vendor specific protocol (whatever it is) yourself, via libusb or otherwise. In the current configuration, it's also not a HID device (though HID devices are not usually used for serial devices in the first place).
– dirkt
Nov 29 at 11:31
1
Googling finds this manual with a code example at the end, usingNewport.ESP301.CommandInterface.dll
, which seems to implement a virtual Windows COM-port. In your place I'd run this example in a VM and monitor USB traffic to see how the protocol works, and if it switches to a standard USB configuration first.
– dirkt
Nov 29 at 11:35
OK, thanks, I can use libusb or even more simply a direct physical serial cable on another port of the device; so I guess I was wrong that there was a simple linux way to turn a USB into a pseudo-serial terminal.
– dargaud
Nov 30 at 9:46
|
show 2 more comments
If it should act as a serial device, it likely implements one of the standard USB classes. First step is to uselsusb -v
etc. to find out if the descriptors say that it actually does, second step is to checkdmesg
after plugin to find out if the correct modules get loaded. Depending on the outcome, you know where the problem is (device providing non-standard descriptors, kernel modules not present etc.).
– dirkt
Nov 29 at 10:27
I added lsusb to my question
– dargaud
Nov 29 at 10:41
As you can see, it's a vendor specific class. So either there is a vendor specific way to switch the USB interface to a standard class (did you get any Windows programs for the device?), or you do have to implement the vendor specific protocol (whatever it is) yourself, via libusb or otherwise. In the current configuration, it's also not a HID device (though HID devices are not usually used for serial devices in the first place).
– dirkt
Nov 29 at 11:31
1
Googling finds this manual with a code example at the end, usingNewport.ESP301.CommandInterface.dll
, which seems to implement a virtual Windows COM-port. In your place I'd run this example in a VM and monitor USB traffic to see how the protocol works, and if it switches to a standard USB configuration first.
– dirkt
Nov 29 at 11:35
OK, thanks, I can use libusb or even more simply a direct physical serial cable on another port of the device; so I guess I was wrong that there was a simple linux way to turn a USB into a pseudo-serial terminal.
– dargaud
Nov 30 at 9:46
If it should act as a serial device, it likely implements one of the standard USB classes. First step is to use
lsusb -v
etc. to find out if the descriptors say that it actually does, second step is to check dmesg
after plugin to find out if the correct modules get loaded. Depending on the outcome, you know where the problem is (device providing non-standard descriptors, kernel modules not present etc.).– dirkt
Nov 29 at 10:27
If it should act as a serial device, it likely implements one of the standard USB classes. First step is to use
lsusb -v
etc. to find out if the descriptors say that it actually does, second step is to check dmesg
after plugin to find out if the correct modules get loaded. Depending on the outcome, you know where the problem is (device providing non-standard descriptors, kernel modules not present etc.).– dirkt
Nov 29 at 10:27
I added lsusb to my question
– dargaud
Nov 29 at 10:41
I added lsusb to my question
– dargaud
Nov 29 at 10:41
As you can see, it's a vendor specific class. So either there is a vendor specific way to switch the USB interface to a standard class (did you get any Windows programs for the device?), or you do have to implement the vendor specific protocol (whatever it is) yourself, via libusb or otherwise. In the current configuration, it's also not a HID device (though HID devices are not usually used for serial devices in the first place).
– dirkt
Nov 29 at 11:31
As you can see, it's a vendor specific class. So either there is a vendor specific way to switch the USB interface to a standard class (did you get any Windows programs for the device?), or you do have to implement the vendor specific protocol (whatever it is) yourself, via libusb or otherwise. In the current configuration, it's also not a HID device (though HID devices are not usually used for serial devices in the first place).
– dirkt
Nov 29 at 11:31
1
1
Googling finds this manual with a code example at the end, using
Newport.ESP301.CommandInterface.dll
, which seems to implement a virtual Windows COM-port. In your place I'd run this example in a VM and monitor USB traffic to see how the protocol works, and if it switches to a standard USB configuration first.– dirkt
Nov 29 at 11:35
Googling finds this manual with a code example at the end, using
Newport.ESP301.CommandInterface.dll
, which seems to implement a virtual Windows COM-port. In your place I'd run this example in a VM and monitor USB traffic to see how the protocol works, and if it switches to a standard USB configuration first.– dirkt
Nov 29 at 11:35
OK, thanks, I can use libusb or even more simply a direct physical serial cable on another port of the device; so I guess I was wrong that there was a simple linux way to turn a USB into a pseudo-serial terminal.
– dargaud
Nov 30 at 9:46
OK, thanks, I can use libusb or even more simply a direct physical serial cable on another port of the device; so I guess I was wrong that there was a simple linux way to turn a USB into a pseudo-serial terminal.
– dargaud
Nov 30 at 9:46
|
show 2 more comments
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f484668%2fturning-usb-into-a-terminal%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
If it should act as a serial device, it likely implements one of the standard USB classes. First step is to use
lsusb -v
etc. to find out if the descriptors say that it actually does, second step is to checkdmesg
after plugin to find out if the correct modules get loaded. Depending on the outcome, you know where the problem is (device providing non-standard descriptors, kernel modules not present etc.).– dirkt
Nov 29 at 10:27
I added lsusb to my question
– dargaud
Nov 29 at 10:41
As you can see, it's a vendor specific class. So either there is a vendor specific way to switch the USB interface to a standard class (did you get any Windows programs for the device?), or you do have to implement the vendor specific protocol (whatever it is) yourself, via libusb or otherwise. In the current configuration, it's also not a HID device (though HID devices are not usually used for serial devices in the first place).
– dirkt
Nov 29 at 11:31
1
Googling finds this manual with a code example at the end, using
Newport.ESP301.CommandInterface.dll
, which seems to implement a virtual Windows COM-port. In your place I'd run this example in a VM and monitor USB traffic to see how the protocol works, and if it switches to a standard USB configuration first.– dirkt
Nov 29 at 11:35
OK, thanks, I can use libusb or even more simply a direct physical serial cable on another port of the device; so I guess I was wrong that there was a simple linux way to turn a USB into a pseudo-serial terminal.
– dargaud
Nov 30 at 9:46