Skip to main content
added 345 characters in body
Source Link
Ale..chenski
  • 12.9k
  • 4
  • 35
  • 48

The RS232 devices are usually FS devices, with USB protocol running at 12Mbps. When plugged into a hub, USB2 or USB3, the communication goes over special communication processor called "Transaction Translator", or "TT", which is embedded into every USB hub. There are two kinds of hubs, the ones that have only one TT for all ports, and the ones that have individual TT for each downstream port.

If you have several FS devices connected to a single-TT hub, the buffering resource will be starved, and FS bandwidth (12Mbps) will be shared between connected devices. To get full FS bandwidth over each downstream connection you need to have so-called "Multi-TT" hub.

Also, the handling of FS transactions over TT requires special approach on host side, called "split transactions".

Modern computers have native FS support through XHCI (USB 3.0) host controllers, so direct connection is handled naturally by XHCI driver. Older computers have the FS support inside their hardware, and muliplex ports to older OHCI or UHCI controllers, so they also have direct support for FS traffic rates.

However, if a hub is in between, the FS traffic must be handled by split-transaction technique, which is solely software-based. The split rules are horribly complicated, and covered by about 150 pages of USB specifications. If your robot driver has poor (or no) support for split transactions, FS and LS devices would fail to work behind a hub, specially if there are many of these devices.

Addition: Orico hub uses VL812 controller IC, which has only one TT in HS path. With (presumably FS) 422-USB device configured for 500,000 bauds and other FS devices, it likely has no bandwidth left, and host has problem with transaction scheduling and barfs on something.

The RS232 devices are usually FS devices, with USB protocol running at 12Mbps. When plugged into a hub, USB2 or USB3, the communication goes over special communication processor called "Transaction Translator", or "TT", which is embedded into every USB hub. There are two kinds of hubs, the ones that have only one TT for all ports, and the ones that have individual TT for each downstream port.

If you have several FS devices connected to a single-TT hub, the buffering resource will be starved, and FS bandwidth (12Mbps) will be shared between connected devices. To get full FS bandwidth over each downstream connection you need to have so-called "Multi-TT" hub.

Also, the handling of FS transactions over TT requires special approach on host side, called "split transactions".

Modern computers have native FS support through XHCI (USB 3.0) host controllers, so direct connection is handled naturally by XHCI driver. Older computers have the FS support inside their hardware, and muliplex ports to older OHCI or UHCI controllers, so they also have direct support for FS traffic rates.

However, if a hub is in between, the FS traffic must be handled by split-transaction technique, which is solely software-based. The split rules are horribly complicated, and covered by about 150 pages of USB specifications. If your robot driver has poor (or no) support for split transactions, FS and LS devices would fail to work behind a hub, specially if there are many of these devices.

The RS232 devices are usually FS devices, with USB protocol running at 12Mbps. When plugged into a hub, USB2 or USB3, the communication goes over special communication processor called "Transaction Translator", or "TT", which is embedded into every USB hub. There are two kinds of hubs, the ones that have only one TT for all ports, and the ones that have individual TT for each downstream port.

If you have several FS devices connected to a single-TT hub, the buffering resource will be starved, and FS bandwidth (12Mbps) will be shared between connected devices. To get full FS bandwidth over each downstream connection you need to have so-called "Multi-TT" hub.

Also, the handling of FS transactions over TT requires special approach on host side, called "split transactions".

Modern computers have native FS support through XHCI (USB 3.0) host controllers, so direct connection is handled naturally by XHCI driver. Older computers have the FS support inside their hardware, and muliplex ports to older OHCI or UHCI controllers, so they also have direct support for FS traffic rates.

However, if a hub is in between, the FS traffic must be handled by split-transaction technique, which is solely software-based. The split rules are horribly complicated, and covered by about 150 pages of USB specifications. If your robot driver has poor (or no) support for split transactions, FS and LS devices would fail to work behind a hub, specially if there are many of these devices.

Addition: Orico hub uses VL812 controller IC, which has only one TT in HS path. With (presumably FS) 422-USB device configured for 500,000 bauds and other FS devices, it likely has no bandwidth left, and host has problem with transaction scheduling and barfs on something.

Source Link
Ale..chenski
  • 12.9k
  • 4
  • 35
  • 48

The RS232 devices are usually FS devices, with USB protocol running at 12Mbps. When plugged into a hub, USB2 or USB3, the communication goes over special communication processor called "Transaction Translator", or "TT", which is embedded into every USB hub. There are two kinds of hubs, the ones that have only one TT for all ports, and the ones that have individual TT for each downstream port.

If you have several FS devices connected to a single-TT hub, the buffering resource will be starved, and FS bandwidth (12Mbps) will be shared between connected devices. To get full FS bandwidth over each downstream connection you need to have so-called "Multi-TT" hub.

Also, the handling of FS transactions over TT requires special approach on host side, called "split transactions".

Modern computers have native FS support through XHCI (USB 3.0) host controllers, so direct connection is handled naturally by XHCI driver. Older computers have the FS support inside their hardware, and muliplex ports to older OHCI or UHCI controllers, so they also have direct support for FS traffic rates.

However, if a hub is in between, the FS traffic must be handled by split-transaction technique, which is solely software-based. The split rules are horribly complicated, and covered by about 150 pages of USB specifications. If your robot driver has poor (or no) support for split transactions, FS and LS devices would fail to work behind a hub, specially if there are many of these devices.