USB discussions getting a bit heated

@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.

Here are some results i ran into when using cheap powered hub.

Initialy they may seem incompatible with th PI, but it could be due to some compromise in the design/production run to cut pricr down.

I ordered some cheap 7 port power USB hub (like 3 for $12) with the power supply included.

on my 1rst attempt i connected my PI to the hub for both power, keyboard and mouse on the hub.

The PI would start to boot and then keept on rebooting.

I removed the keyboard and mouse, no change.

The supplied power supply was rated for 5v 1A only, clearly insuficient current rating. so i used a 5v 2A supply i had left over.

I reconnected everything back, then the PI booted till it got to the USB port detection and then it was looping into the USB detection sequence. Then i noticed the micro usb plug was NOT connected on the PI ????? The PI was receiving power from the normal USB jack instead.

I then connected the micro USB plug and reapplied power, now the PI booted normaly. But the keyboard and mouse where erratics.

I decided to look inside the USB hub case and i found a jumper that connected the external power supply to the +5v side on the incoming usb connector from the PI.

Then i proceded to remove said jumper. Now the PI would not power on from the hub, good.

So i connected the micro usb cable to the powered hub along the keyboard and mouse.

now they are all behaving properly.

So my theory is that when the jumper wire was installed in the hub and you use the same hub for both power and expansions some current loops may be created inside the PI and cause some undesirable behaviour.

The USB upstream A-B backfeed that you describe is what causes the official "Pi Accessory" 7-port Dynamode hub to fail with the Pi, as I described in this thread ---  http://www.element14.com/community/thread/19316?tstart=30  .

I'll probably hack out the backfeed path or insert a diode some day, but for now it's working fine with Intel PCs.

Unfortunately the Pi's USB problems go far beyond just being succeptible to backfeed from cheap hubs.

I gather that 8 endpoints is a hardware limit

So I stumbled on some other information on this limit of 8 'somethings'  here https://github.com/raspberrypi/linux/issues/29#issuecomment-6882473 it's not realy clear to me what the actual relationships are between a channel and an endpoint. It seems more like a channel is used by an endpoint that has some specific property, not simply all endpoints.

What does seem good is that there are other people outside the RPF working on drivers for this same synopsis core so there may be some light at the end of that tunnel

The downside is the other work is for the mainline kernel and we're 'officially' stuck at 3.1.9 so backporting stuff will likely be an issue and take time.

The funny bit is that I came across the links into those discussions on github from an irc discussion of a usb webcam that has 26 endpoints !

Thank you so much for all your help

Cheers

David

I wonder when Eben will stop saying that the R-pi can do "what other computers do."

depends how you define 'other computers'. compare a Pi, a laptop, a desktop, a blade server and an IBM BlueGene/Q.  We hopefully both agree they all fit the general term 'computer' but all have vastly different capabilities and expansion options.. So, can the Pi manage 16.32 petaflops/s ?  Don't think so, no matter how good the GPU is.

Narrow the focus enough and they can probably all run linux, so yes, the Pi can do 

When Eben says "other computers", I would grant him the narrow interpretation of that, meaning "small personal computers that private people commonly have".

The trouble with Pi is that it fails to do what such small personal computers manage to do effortlessly every day for millions of users around the world.  Those small personal computers that everyone has don't fail to enumerate large numbers of USB devices nor lose USB data continually.  That's the problem I would lay at Eben's door.

New Gizmo from FTDI designed for the R-Pi

http://www.ftdichip.com/Products/Modules/RPi.htm

PS asuming USB works ...

-J

jamodio wrote:

 

PS asuming USB works ...

New disclaimer for USB device manufacturers' packaging?

"This device may or may not work with Raspberry Pi.

  Dice and Magic 8 Balls available as accessories."

selsinork wrote:

 

I gather that 8 endpoints is a hardware limit

So I stumbled on some other information on this limit of 8 'somethings'  here https://github.com/raspberrypi/linux/issues/29#issuecomment-6882473 it's not realy clear to me what the actual relationships are between a channel and an endpoint. It seems more like a channel is used by an endpoint that has some specific property, not simply all endpoints.

 

The funny bit is that I came across the links into those discussions on github from an irc discussion of a usb webcam that has 26 endpoints !

Well, I don't think "channel" is a USB term.  Perhaps a "channel" means a "DMA channel", and 8 DMA channels can be configured simultaneously to cover endpoints with actual transfers in progress.  That is, as soon as one transfer completes that "channel" is available for a new one.

26 endpoints?  Whoa.  Pretty close to the 16 input plus 16 output limit.