USB discussions getting a bit heated

Those threads are terrible They downplay most of the problems people have encountered and add confusion.

But it's a timebomb waiting to go off...

I guess user Kernel sums it up pretty nicely http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=12097&start=197

 

Frankly even though the Foundation people are not making profit on Raspi, I think it doesn't make them any less responsible for the quality of the device they designed and have been (indirectly) selling.

 

Regardless of the cause (software, power, design) of Pi's problems, they are frustrating to deal with and are likely to cause many to lose interest at some point (even children, or perhaps especially them).

 

Those threads are terrible They downplay most of the problems people have encountered and add confusion.

Thing is, the issues are complex. A lot of the confusion is being caused by people who mostly don't have a grasp of either the hardware or software problems.  Lets face it, with a usb IP block that nobody seems to have much information about, we're all in the dark and what makes it tick may as well be black magic

Still, at this point the Pi really is a development board - there's lots of development happening and various people working on fixing issues. Unfortunately due to all the hype there's lots of them landing in the hands of people who are used to a device that's been in development for years with budgets in the billions and expect everything to 'just work' instantly, instead they have a device that was designed to a strict budget with all the compromises that entails. This was bound to cause some friction.

I suspect the RPF was very much unprepared for the amount of destructive stress testing a couple of hundred thousand users can do in such a short time with devices that were never thought of during the design.

A class-compliant USB device is one that works with open source drivers for that class, ie. requires no device-specific drivers.

and when the open source driver is 'fixed' and your device stops working ?

I understand where you're coming from and the pragmatic answer is a good one. Reality doesn't always want to play ball.. 

So we have open source keyboard/mouse/whatever drivers that are known to work, but you have problems when you plug your device into the Pi - must be the device since it fails to work with the open source class driver    Ok, so I'm definetly playing devils advocate here, but as engineers I'm sure we realise it's never as simple as we'd like.

Let's just hope that CE doesn't stand for caveat emptor

Nooo...  China Export   probably not much difference then

selsinork wrote:

 

So we have open source keyboard/mouse/whatever drivers that are known to work, but you have problems when you plug your device into the Pi - must be the device since it fails to work with the open source class driver    Ok, so I'm definetly playing devils advocate here, but as engineers I'm sure we realise it's never as simple as we'd like.

Not so fast, cowboy.

When a device is pragmatically class-compliant when used with 500 trillion other Linux machines, but doesn't work with the open source driver for the class in Pi, then it's not reasonable to claim that the device is not class-compliant.  It may indeed be so, but it's not the leading candidate for an explanation, particularly when multiple devices exhibit the same behavior.

Not so fast, cowboy.

hehe..

When a device is pragmatically class-compliant when used with 500 trillion other Linux machines

however those 500 trillion other systems don't all share the same usb host controller, so not necessarily a valid comparison. It does help us narrow down the scope of the difference though.

It may indeed be so, but it's not the leading candidate for an explanation, particularly when multiple devices exhibit the same behavior.

Sure, but as we dig into some detail it gets harder to pin the tail on the donkey.  Lacking any certification audit trail we can't completely rule out everything else being broken, unlikely as it may be. So we assume the device is ok and the class driver is ok. We're still left with the low level driver, the IP core itself, or the Pi power design. We have some ability to modify the Pi power design, and the low level driver but don't know if a silicon issue could be compensated for in either of those ways.

Time may provide a solution, would certainly be disappointing if it didn't, and a software fix would be the best outcome..

selsinork wrote:

 

Time may provide a solution, would certainly be disappointing if it didn't, and a software fix would be the best outcome..

A software fix is quite likely to be able to resolve the problem, no matter how broken the controller core, just by working within its limitations.  In the same way that USB drivers reserve bandwidth for audio channels for example (and reject connections which they know cannot work), a driver that understands the controller's limits could allow only such devices that can work together to connect.

This could limit the choices, but we would at least have a 100% working platform within well defined constraints, and that is crucial.  Flakey operation has no place in USB.

Morgaine.

Hi Morgaine,

You seem good at explaining things to non-engineer types.  My question to you is this.  I attached an Abe Bluetooth dongle directly to my Pi.  On the dongle there are to light diodes (I think) one turns and stays red the other green and it flashes during data transmissions.  During bootup I saw that the system did pick up the bluetooth and the generic bluetooth driver was loaded.  So is it possible that a system can pick up a device that is connected to its usb ports but not have enough to power it?  Or is it possible for the bluetooth to be broken but still be recognized. I ask this because no lights appeared at all and given the conversation regarding usb ports ...

Cheers

David

@David: I'll try to answer.

All of the fault scenarios that you mention are feasible as a combination of Pi power constraints, Pi USB faults, and ARM driver non-working.  I don't know whether your particular Bluetooth dongle is known to work with ARM using class-compliant drivers, but let's assume that it does otherwise there is little point in further analysis.

(Eg. if it only works with a binary x86 driver blob then obviously there is no chance of it working on ARM, and if it is not class-complaint and hence requires its own bespoke Linux driver which hasn't yet been ported to ARM then again, there is little a non-developer can do.  Therefore let's assume that it works with ARM, so we're just trying to get an ARM-capable device to work with Pi.)

Your first question can be answered even without any testing:

David Harrison wrote:

 

During bootup I saw that the system did pick up the bluetooth and the generic bluetooth driver was loaded.  So is it possible that a system can pick up a device that is connected to its usb ports but not have enough to power it?

Yes, it is possible, because before a USB Bluetooth dongle transmits RF, it will attempt to get connected into the USB device chain.  That involves only the USB interface circuitry on the dongle and not its RF circuits, which would normally be quiescent at this stage and hence not consuming much power.  (Significantly more power is consumed by the dongle when it transmits Bluetooth RF than when it is not transmitting.)  So, the dongle could in principle need only a little current during the connect phase, well within the Pi's capabilities, but then later require in excess of the Pi's power limits when transmitting.

USB has a way of dealing with this "I need more current" situation because it is quite common.  Host ports are required to be able to deliver an initial unit of current, and then additional units are negotiated between the USB host and the power-hungry device.  Unfortunately I don't think we know exactly how this negotiation works on Pi, because although the LAN9512 chip contains a hub and is (presumably) USB-compliant, that hub is not self-powered but takes power from the Pi board under SoC control, which has some idiosyncracies.

The Pi has polyfuses with high on-resistances in series with its USB power lines, so the current available to devices that request more is limited by the voltage dropping as more current is provided, until eventually the voltage drops below USB spec or the polyfuse trips and pretty much turns it off altogether.  What's more, we have no idea whether the Pi's highly broken USB driver understands that there are polyfuses in those lines and hence that it cannot just offer additional units up to the USB maximum if it does grant such requests.  Even if it does or could, the wide variation in polyfuses on-resistance would make this very hit-or-miss.  I hope that is not happening.

The best we can hope for is that the Pi's driver has been set up to refuse to grant additional units of current above 100mA.  We could then have the situation that a Bluetooth dongle gets enough power from the USB port to allow the Pi's USB driver to enumerate it and to commence the power negotiation.  The extra power request would then be rejected, and if the dongle has the smarts to recognize the rejection, then the dongle's RF transmitters would never be enabled.  The device would be inoperative as you hypothesized, but recognized as a USB device.

I hope that answers your first question and explains the reasoning behind the answer.

To get some more info on what actually happens within Pi we would have to read the USB driver source to see whether it handles power negotiation and whether requests are granted or rejected, and we'd have to look for messages that would be logged if a power request were refused.  You would then have to look for such refusal messages in your error messages log.

Your second question (separate from the power question) isn't easy to answer in any detail:

Or is it possible for the bluetooth to be broken but still be recognized. I ask this because no lights appeared at all and given the conversation regarding usb ports ...

Because the USB interface circuitry is generally separate from the rest of a device, that is certainly possible in principle.  However, assuming that we're talking about class-compliant devices that are known to work on ARM, I would think that it's unlikely for the non-USB part of the device to be totally inoperative on Pi unless it's caused by the generally broken state of Pi's USB system.  It's very hard to say.

Morgaine.

Thank you so much for all your help

Cheers

David

ah ha Morgaine!  We may be "clueless" and walking around in the dark - - - but we sure know how to find someone with a light

great explanation to @David.

Best

peg

Funny comment, Peg, but I hope the references to 'clueless' weren't misunderstood.

The 'clueless' aren't those who don't know --- the more you know, the more you realize that you don't know, so not knowing is not the defining property.  It's only those who don't wish to know and don't wish to think, or cannot think.

Walking around in the dark is what we all do, but the desire for illumination is what takes us to the nearby planets today, and one day to the stars.  Civilization is all about riding on the shoulders of those who went before, so if you know how to find someone with a light then you're helping to carry that torch forward and build that pyramid of knowledge and capability.

Welcome to the dark.  But as you said so well, we sure know how to find someone with a light.

Morgaine.

Funny comment, Peg, but I hope the references to 'clueless' weren't misunderstood.

The 'clueless' aren't those who don't know --- the more you know, the more you realize that you don't know, so not knowing is not the defining property.  It's only those who don't wish to know and don't wish to think, or cannot think.

Walking around in the dark is what we all do, but the desire for illumination is what takes us to the nearby planets today, and one day to the stars.  Civilization is all about riding on the shoulders of those who went before, so if you know how to find someone with a light then you're helping to carry that torch forward and build that pyramid of knowledge and capability.

Welcome to the dark.  But as you said so well, we sure know how to find someone with a light.

Morgaine.

Let me clarify the context related to my "clueless" comment.

I have no issue or problems with people that don't have a clue and are asking the right questions and in a proper manner. I've been clueless and I'm clueless in many many things and we all at sometime are "newbies." That's not the issue.

The issue is with a forum where moderators are supposed to, among other things "moderate" some comments so wrong information doesn't get widespread.

In the case of the R-Pi forum if somebody states something like "The chips in the RPi are supposed to run hot, they are designed to operate safely to 120 degrees C," I've not seen any moderator or anybody from RPF to reply to that comment so the clueless person that made it can get un-clueless, or even providing the right information about what is the correct operating temperature range for the R-Pi and its parts.

On the other hand people reporting real problems, and providing valuable information, get bashed, harassed, called names and banned.

This is from where my "clueless" comment came from.

-J

All,

I got a kick out of the clueless thing!! Hope you didn't misunderstand my compliment!

I have learned so much in the last few months - and it's from reading then researching, then doing after you have explained or discussed something. . .

My thanks to you all - keep the light coming

peg

Morgaine. . . I've become a fan of yours...please see my reply to jamodio

Peg Wagner wrote:

 

Morgaine. . . I've become a fan of yours...please see my reply to jamodio

Yay, I have a fan!  I'm not sure what to do now, I've never had one before.

PS. I can't improve on your last line to jamodio --- "keep the light coming".  That's glorious!

One light that stays off is that of the backfeeding usb hubs. If the Pi is powered from the a downstream port of the same hub, wouldn't that basically ensure that the Pi receives the full voltage, and shouldn't it boot normally, besided getting some voltage as well on one of it's usb ports? This would basically just short the main and usb polyfuse on the board. But reading from reports, people say that keyboard and mouse behavour is bad with a hub providing power to it's upstream port. This doesn't make sense.

Considering the power negotiation of usb ports. When you run into issues on a windoze pc, it simply shows a warning message that a device needs more power and should be connected to a self powered hub. Since the driver is not loaded, the device can't start to consume the power it needs. The usb port will keep providing current untill a Polyfuse trips (or some other protection turns on.) On cheap mobo's, they will even provide just one 1Amp fuse for 2 usb ports. It will have a lower resistance under normal operating conditions, and power hungry usb harddisks will work as long as the second usb port isn't badly loaded as well. Maybe it's an idea to improve the price on the Pi2.