Pi vs BeagleBone-Black

Morgaine Dinova wrote:

 

mynameisJim wrote:

 

Morgaine Dinova wrote:

 

namely that USB compliance means automatic support for everything that is class-compliant or has a driver for the architecture.  Partial percentages don't enter into this.  If Pi is USB-compliant as a USB host then it will work with 100% of USB-compliant devices subject to power, bandwidth and driver requirements being met.  No per-device development is required.

 

 

This is a perfect definition of what the USB standard should be.  I've yet to see it be true for any USB host ever.  And it's not always because the the host manufacturer made a mistake, USB devices  don't always follow the rules either.

 

But when devices don't follow the rules (assuming you refer to USB), that's just another way of saying that they're "USB non-compliant" so they're not part of the topic.  Sure, developers can and do make mistakes and some probably take shortcuts on purpose, but we're not talking about those.  We're talking about USB-compliant devices, and I hope I made it plain multiple times that that was the proviso.  Nobody has ever suggested that Pi should support non-compliant devices, nor devices with other bugs.

 

When devices are USB-compliant, then a properly working host will support them all, in any combination, 100% of them subject to their power, bandwidth and driver requirements being met.  No extra work is needed, no special testing of each device individually is needed.  That's the entire point of adherence to specs, it reduces the workload of both host and device manufacturers immeasureably by working to a common fixed point.  And this process works well, throughout the entire space of technology, not only in USB.

 

With fully class-compliant USB devices, the situation is even simpler because there are fewer areas of doubt since no device-specific drivers are required.  Every class-compliant device on the planet can and should be expected to work on all Linux hosts (non-USB bugs excluded of course) for all USB classes that have been well exercised over the years.  Obviously the bug-rate will be higher in less-used class drivers, but keyboards, mice and hubs have exercised Linux class drivers so many billions of times that little doubt remains that they work fine.

 

And yet, keyboard data dropouts are reported on Pi continually, so clearly some work remains to be done.  These class-compliant devices are not the source of the problem.  Indeed, the source of the problem is well known and documented by Pi developers.

Actually that's very much my point, non-compliant devices are routinely given the stamp of approval.  And non-compliant devices are really advertised as such.  The end result is that people plug a USB device into the pi expecting it to work like it should having no knowledge that it's not following the standard and then discussions about them arrise.

Now on the flip side here, as your previous post says

>> There's a clear and reproduceable problem (no engineer denies it), the devs are working hard on solutions for it (nobody denies it), and with enough time and effort and expenditure it is very possible that it may be solved for good (nobody denies that either --- there are some very competent devs working on it).

With a more robust USB host the problem devices (the non-compliant devices) are less likely to cause problems and go unnoticed.

>> So why do some people make a habit of denying or minimizing the existence of the problem and requiring these threads to explain the nature of reality to them in black and white?

I can't speak for others, but I'm not trying to minimize or deny the existence of the problem.   The topic came up and thus it was discussed, lol.  Part of that discussion is the reality that the USB standards are followed loosely and that loose following is going to create issues with a device like the pi, issues which are being worked on thankfully.  I too hope that eventually the issue is solved for good (where good is defined in the horseshoes and hand grenades sense)

Morgaine Dinova wrote:

 

mynameisJim wrote:

 

Morgaine Dinova wrote:

 

namely that USB compliance means automatic support for everything that is class-compliant or has a driver for the architecture.  Partial percentages don't enter into this.  If Pi is USB-compliant as a USB host then it will work with 100% of USB-compliant devices subject to power, bandwidth and driver requirements being met.  No per-device development is required.

 

 

This is a perfect definition of what the USB standard should be.  I've yet to see it be true for any USB host ever.  And it's not always because the the host manufacturer made a mistake, USB devices  don't always follow the rules either.

 

But when devices don't follow the rules (assuming you refer to USB), that's just another way of saying that they're "USB non-compliant" so they're not part of the topic.  Sure, developers can and do make mistakes and some probably take shortcuts on purpose, but we're not talking about those.  We're talking about USB-compliant devices, and I hope I made it plain multiple times that that was the proviso.  Nobody has ever suggested that Pi should support non-compliant devices, nor devices with other bugs.

 

When devices are USB-compliant, then a properly working host will support them all, in any combination, 100% of them subject to their power, bandwidth and driver requirements being met.  No extra work is needed, no special testing of each device individually is needed.  That's the entire point of adherence to specs, it reduces the workload of both host and device manufacturers immeasureably by working to a common fixed point.  And this process works well, throughout the entire space of technology, not only in USB.

 

With fully class-compliant USB devices, the situation is even simpler because there are fewer areas of doubt since no device-specific drivers are required.  Every class-compliant device on the planet can and should be expected to work on all Linux hosts (non-USB bugs excluded of course) for all USB classes that have been well exercised over the years.  Obviously the bug-rate will be higher in less-used class drivers, but keyboards, mice and hubs have exercised Linux class drivers so many billions of times that little doubt remains that they work fine.

 

And yet, keyboard data dropouts are reported on Pi continually, so clearly some work remains to be done.  These class-compliant devices are not the source of the problem.  Indeed, the source of the problem is well known and documented by Pi developers.

Actually that's very much my point, non-compliant devices are routinely given the stamp of approval.  And non-compliant devices are really advertised as such.  The end result is that people plug a USB device into the pi expecting it to work like it should having no knowledge that it's not following the standard and then discussions about them arrise.

Now on the flip side here, as your previous post says

>> There's a clear and reproduceable problem (no engineer denies it), the devs are working hard on solutions for it (nobody denies it), and with enough time and effort and expenditure it is very possible that it may be solved for good (nobody denies that either --- there are some very competent devs working on it).

With a more robust USB host the problem devices (the non-compliant devices) are less likely to cause problems and go unnoticed.

>> So why do some people make a habit of denying or minimizing the existence of the problem and requiring these threads to explain the nature of reality to them in black and white?

I can't speak for others, but I'm not trying to minimize or deny the existence of the problem.   The topic came up and thus it was discussed, lol.  Part of that discussion is the reality that the USB standards are followed loosely and that loose following is going to create issues with a device like the pi, issues which are being worked on thankfully.  I too hope that eventually the issue is solved for good (where good is defined in the horseshoes and hand grenades sense)