Raspberry Pi - Hardware Flaws and Fixups?

Note that this "hdmi through USB" is probably not proper use of the USB connector. They need have the USB connector anyway so they multiplex the HDMI signals onto that connector when you connect that special cable. USB isn't fast enough to handle most screens. (Full-HD is about 3Gbit/sec, just a tad over 480Mbps... )

Hi Pete,

I love the work you have done on this, I am having great fun and learning loads with my Pi.

I do have one suggestion/request.

In my current setup, I have an external USB hub powered with a 3A PSU (which I know is overkill, but it was handy).  For the wiring I have a micro USB lead into the hub just for power, and then I have a standard USB A to USB B lead from the hub into one of the USB ports on the Pi.

This seems to be one cable more than I should need.  To make the cabling cleaner and simpler looking, I have tried removing the micro USB lead and the Pi starts to boot up, but then resets when it gets to the USB Hotplug boot code.

Why couldn't the power flow from the powered external USB hub into the Pi via one of its two USB ports via a USB A to USB B lead?  Then I would only need the one lead from the Pi into the hub for both power and data.

It is a very small point, but I think it would be a nice touch.

Thanks

Gary.

The topic was the target applications for which Broadcom designed the BCM2835, so it's not very relevant to mention the few  smartphones that *DO* have an HDMI socket when there are none that use the BCM2835.

The Samsung Galaxy SII uses a 1.2 GHz dual-core ARM Cortex-A9 SoC in most jurisdictions; the Samsung Exynos GT-I9100, a real beast of a modern ARM processor, and not the BCM2835.  A smartphone using the BCM2835 would not make it in the current smartphone market, whereas in the intended applications which Broadcom has described --- http://www.broadcom.com/products/BCM2835 --- it's perfectly fine even today since they require no huge amount of CPU power.

The full story is given here in the section labelled "VideoCore ICs" -- https://en.wikipedia.org/wiki/VideoCore

As you can see from the table, the older BCM27xx VideoCore ICs were used in iPods and Symbian phones, but no BCM28xx ever was.  The BCM2835 device is only known to have been used in Roku 2 and now in Raspberry Pi, and was not designed for smartphones.  If it had been, Broadcom's description would say so.  It doesn't.

Perhaps "Power Options" could be a topic examined in some detail when considering the next revision.  I know that people have expressed interest in PoE on the Rpi blog or forum, so that's an item for the wishlist if it can be done cheaply.

It would certainly appeal to have your Rpi-based servers connected only by an Ethernet lead and nothing else.  Nowadays it's quite inexpensive too --- an 8-port 10/100Mbps switch with PoE on all ports costs around $55 from Amazon, and would give you a nice little cluster with no extra wiring.

Morgaine.

GizmoB73 wrote:

In my current setup, I have an external USB hub powered with a 3A PSU (which I know is overkill, but it was handy).  For the wiring I have a micro USB lead into the hub just for power, and then I have a standard USB A to USB B lead from the hub into one of the USB ports on the Pi.

Hi Gary,

I'm not Pete, but I think I understand what is going on. I had planned to do exactly what you wanted to do before i found out why it doesn't work. As apparently you've verified... :-)

There are several auto-resetting fuses on the board. There is a 700mA one between the micro-usb power-port and the rest of the system. And there are two 140mA ones between the 5V of the system and the outgoing USB ports.

So, apparently your Raspberry Pi manages to partially boot through one 140mA fuse before apparently the fuse decides to do what it's supposed to do: enough is enough! and it shuts down the power.

Pete has said that those fuses, although rated for 140mA will hold out until 280mA, and then suddenly start to limit the current to 140mA. Apparently the RPI manages to work on less than that 280mA.

What I THINK you observed is that at that stage the USB gets enabled, and that also means the ethernet chip. That's what makes the difference between the Model A and Model B, and that causes a reported difference in current-requirements.

It sounds very much like you could be right, that would explain why it kept rebooting.

Presumably that means that one of those two fuses could be swapped for a larger value then.  I realise why that has been done, but there could be an understanding that the bottom port could double up as the supply perhaps.

Jumpers could be another solution, but i doubt that there is sufficient spare space on the board for that?

Obviously i won't be hacking this one to test it out!

Yes Roger is spot on.

I can see the value in your suggestion, but I was worried simply that if someone parks something on the second USB that takes a fair bit of current, adds something to the GPIO and then tries to feed the whole board by back feeding from a USB we were going to run into 'use case' related issues and related support.  (OK - like now)

There is an argument for at least up rating to 500mA but the whole concept of back feeding is a topic in itself.  I always thought this would be a world of unintended consequences as IMO it should not really be supported anyway?  It also presents problems in that then the input fusing and tracking needs to be reviewed to just make sure it will cope with it - which I do so if you want to hack your own Pi you can.

The SMSC does have reporting for USB power issues , but I don't think the software guys have implemented in the drivers - moot point if the fuse rips the rug from under you anyway.

This whole topic looks like a thread in itself with additional (valid) discussion on PoE for new versions.  Would anyone be willing to put up a thread collecting all the salient stuff so far in the head?

Cheers

Pete

Hi Pete,

thanks for providing this excellent "technical window" to the Raspberry Pi and for the interesting dialogue.

Have you ever considered using a power management IC instead of the several LDO's ?

While I think that PoE sounds interesting I've the impression that probably will be cost prohibitive to implement, I'm still on the search for a cost effective PoE solution (meaning a IEEE802.3af fully complaint.)

Not sure if I missed the answer, but it has been asked a couple of times if and when full schematics of the board will be released ?

So far the only section that seems to be available is the power supply.

One suggestion I'd add is replacing the microUSB connector by something more sturdy like a DC Power Jack.

Thanks again & Regards

Jorge

Someone always has something they don't like when choices are being made.

I think the decisison to go for microUSB is a good one. Adapters providing "5V, 1A charging current" for devices like HTC smartphones are common. The charging connector has been standardized to "microUSB" which now nicely fits the Raspberry Pi. IMHO this all fits together nicely.

Do you have any (anecdotal?) "proof" that the microUSB connector is (too) weak?

Schematics are going to be published, I've heard. Sometime after the design has been "finalized" which means more than a few boards going to customers.

I think the micro USB is an OK choice, but I think a 2.5mm dc power jack (positive tip) would have probably been better. They are two a penny, very common psu's and tend to be more robust sockets when physically anchored.

I work for a hardware manufacturer who use these micro USB sockets in a couple of our products. I have seen plenty where the socket is rattling around inside the case after someone has pushed the plug in  too hard and the socket has ripped clean off of the pcb.  The socket can also get loose internally when forces are applied with the plug inserted.

This is not intended to be criticism, merely my observations, from existing products, and I doubt that school children will be gentle.