Pi vs BeagleBone-Black

selsinork wrote:

 

jamodio wrote:

 

For a school kid learning to program in phyton that won't make a big difference but for an embedded research and development engineer makes a big one.

The question raised by that is whether a schoolkid learning scratch or python actually needs or wants to be doing it on a Pi.  You can do these things on a windows PC, or if there's some unknown advantage to a credit card sized bare board there are other devices that fit the bill. Mostly these other platforms just work.

I think this probably answers your question:

This project aims to get computers in to the hands of people who don’t have access to computers that they can program on (which isn’t the same as just having access to a computer). I’m also not sure why you have mentioned schools and universities that already have PC’s. If they already have PC’s they don’t need the Raspi anyway, so are not the target audience.

(emphasis in original)  http://www.raspberrypi.org/archives/633#comment-11458  JamesH February 14, 2012

coder27 wrote:

 

Billy Thornton wrote:

 

jamodio wrote:

 

Billy Thornton wrote:

 

Anyone know how old this usb hardware design is and what else it is in?

 

Yes.

Hmm. Helpful. is it you, or someone else? Like, do you know, or did you just answer for the fun of it. Thats my job.

 

Your job involves this Synopsis usb design?

 

 

Actually, he saying that his job is "answer(ing) for the fun of it", not that he works on the synopsis USB core.  He was being tongue in check (sarcastic)

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.

It puzzles me why we have to go through this process of re-explaining the USB issue so regularly.

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).  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?

If there were no USB problem, the devs wouldn't be spending their time trying to fix it, would they?

It puzzles me why we have to go through this process of re-explaining the USB issue so regularly.

You've heard the old saying about leading the horse to water but not being able to make it drink ....

substitute leading with telling and drinking with listening.  (grammer errors excluded)

Mark

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)

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?

They are just regurgitating what JamesH wrote on the other forum:

by jamesh » Mon Apr 29, 2013 2:30 am

 

The vast majority of people see no issues whatsoever, so rather than Essex, I'd say a small village in Scotland, Largs perhaps. Most people never go to Largs (although it is a nice place), so most people never see the problems (I was born in Essex, and I never see any problems).

Just because your very specific purpose doesn't work very well, does not mean the device it not fit for purpose in a huge number of other areas. Saying it only works with keyboard and mouse is obviously quite quite wrong. I've used it with USB hard drives using OpenELEC with no problems (High data transfer). I've used it with wireless adapters with no problems, streaming video, no problems.

I have a USB slide scanner. It doesn't work on my Ubuntu PC. USB isn't quite as universal as its name implies.

I can't speak for others,

Actually, he saying that his job is "answer(ing) for the fun of it", not that he works on the synopsis USB core.

mynameisJim wrote:

 

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.

You have my total support if a device is not USB-compliant and some people complain that Pi fails to support it.  Such devices fail the tacit agreement to follow specs, and the fewer of them that survive, the better.  Good riddance.

But that uncompromising position on non-compliant devices (may they burn in ignomy) is matched with an equally uncompromising position on hosts that don't work correctly with fully USB-compliant devices, especially class-compliant devices in the most common classes.  Engineering is an iterative and evolving process and some things take time to get right, and that's OK, I can wait, and the devs are heading in the right direction.  But it has to be fixed.

What gets short shrift from me (actually, zero shrift) is some people trying to scupper the very cool and useful engineering process of fixing things by claiming that the problem doesn't exist or doesn't matter.  This does not apply to you, since you acknowledge that there is a problem to fix.  That's the mandatory first step to solving it, and I'm always grateful to see it.  That's engineering.

coder27 wrote:

 

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?

 

They are just regurgitating what JamesH wrote on the other forum:

 

Yes, pretty much.  But it's not just jamesh saying it, it's everyone associated with the Raspberry Pi Foundation who posts on their forums except for dom and gsh.  It's cognitive dissonance, they want to believe the Raspberry Pi is flawless and can't deal with it when any evidence to the contrary is presented.  This is the cause of the denial and minimisation.

But denial and minimisation is an improvement over the total silence which was the RPFs initial non-response to the USB problems when they were first pointed out and the subsequent 'it's caused by an inadequate power supply" catch-all explanation.