locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO


Dale Ghent
 

You don't seem to want to go into any detail other than referencing some vague notion. USB2 devices are no different than any other in this area. Devices with bad-actor USB logic are going to cause the issues just like a bad-actor device on any kind of bus is going to cause, including ethernet, and I certainly have some camp fire stories from there.

What you're doing is taking a single example of a particular device's bad or faulty implementation of a USB protocol and holding it up as if it were a problem with the protocol design itself. At the least, this is a misunderstanding. Any bus technology is reliant upon its constituent devices operating within the defined electrical and protocol specifications that define its standards in order to maintain a stable environment. This goes for PCI(e), ethernet, SAS, SPI, i2c - you name it, it requires it. Some bus designs do provide either electrical or protocol-based isolation of such faulty components, but these methods are not really common in practice and have other consequences which are often undesirable.

On Nov 24, 2020, at 2:18 PM, Bill Long <bill@outlook.com> wrote:

The reset event can cause issues with connected devices that are USB2 protocol. You are talking about ideal situations, real world situations on the bus are different. You can test this yourself. Write a bad actor driver that issues constant resets and see what happens.

Dont ask me how I know this though. 😉

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@elemental.org>
Sent: Tuesday, November 24, 2020 11:09 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO


I think you've misunderstand what "USB bus reset" signaling is. Bus resets happen only between the host and a device. Other devices on the same controller are not a party to such an event. Bus resets are normal components of USB host->device signaling and signal the device to enter a quiescent state. These events are largely abstracted away and masked by higher levels of any modern USB stack, and are not bad things.

In my experience, USB problems are almost always the result of poor cabling quality, noisy operating environments (which poor cabling will exacerbate), or mechanical failure of a connector. Overburdening of bus power can also present itself as a "USB problem" in the case where a user connects too many devices that draw more power than the bus can provide. This is why the recommendation for quality powered hubs, versus unpowered hub, is always made.


On Nov 24, 2020, at 1:49 PM, Bill Long <bill@outlook.com> wrote:

It takes one bus reset call from a connected device to cause problems. You know this.

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@elemental.org>
Sent: Tuesday, November 24, 2020 10:45 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO


I've had no problems with USB that can't be traced to a bad or poorly-designed cable. USB is fine so long as you know its limits.

On Nov 24, 2020, at 12:56 PM, Bill Long <bill@outlook.com> wrote:

If they want to update the mount, they will either need serial ports on the machine (not likely) or ethernet. USB is not recommended for reasons I am sure you know as a developer.

USB to ethernet adapters are not advised for the same reason USB connections themselves are not advised to update the mount as needed. So while your solutions here solve the usage short-term, the better advise to the user is to have more of a long term solution to the problem at hand.












Join main@ap-gto.groups.io to automatically receive all group messages.