Raspberry Pi - Hardware Flaws and Fixups?

I asked myself a bit of a rhetorical question about Pi hardware over in the "Combining BeagleBone and Raspberry Pi" thread -- http://www.element14.com/community/thread/18382?tstart=0 .  I really don't know the answer to it so perhaps it makes sense to raise it as a question here in Pete's hardware thread:

 

Morgaine Dinova wrote:

 

...

It makes me wonder whether some ambitious Pi hacker could route the unconnected pins of the Pi's micro-USB power socket through level translators to the Pi's GPIO header, and bit-bang up a client-mode USB interface for the Pi.

Is this kind of thing feasible?

While it wouldn't have the speed of dedicated USB hardware, it would be an awesomely cool hack if it worked at all!

Morgaine.

While possible in theory (it's possible with an AVR clocked at 12 MHz), it is not the "way to go" IMHO.

The raspberry pi has the "USB device" hardware on-chip. Why not use that? Buy yourself a model A,

remove R36, and R37 (not present on Model B) and patch the pads to the micro USB connector.

(Should you find yourself stuck with a model B at this point in time, you'll have to remove the LAN9512 instead of the two resistors).

If you're not into hardware patching your 'PI just yet, wait for a model A and make/buy an A-A straight through USB cable. Then you get to work on the drivers.

If you want your 'pi patched but don't want to do it yourself, I'll do it for you. $25 excluding return shipping.... (no guarantees)

Thanks for your feedback, Roger.  It was very interesting to hear that such a hack is indeed feasible, and even more interesting to hear that Model A boards could allow a more efficient USB hardware interface to be brought out reasonably easily.

While I don't expect to want the above kind of hardware hack on my Pi personally (I'm still waiting for mine anyway), playing with my new BeagleBone is inevitably bringing up various ideas by comparison with the Pi's design.

Thinking about such hardware modifications is important in two ways I think:

• On the one hand, with millions of Pi eventually in the world once the plans to introduce it into education finally unfold, it is quite inevitable that many enthusiasts will be eager to take their Pi in directions that were never envisaged at design time, as this often adds interest and appeal.  That's in the nature of enthusiasts and budding engineers, and encouraging their efforts fits in perfectly with the Pi's educational goals.
• On the other hand, professional engineers are alway interested in the next generation of things that they create, and ideas for improvements in their designs can come from anywhere and everywhere.  The Foundation's engineers are no exception of course, and your suggestion regarding extended USB abilities for Model A could spark some interesting design changes for next generation boards.

The Pi Model A is by design a less well connected board than the model B, in the very important interest of low BOM cost.  But removing R36 and R37 reduces the component cost even further, and routing the micro-USB's unused pads to the SoC's USB device could give a hypothetical Model "A2" extra USB connectivity in place of Model B's more costly Ethernet.  This even fits in well on power budget grounds, since the Model A has lower power requirements than Model B and a 500mA upstream port will in most cases be perfectly adequate.

This seems like a good idea to bounce off Pete.  How about redesigning Model A for extra upstream USB capability?  After all, there are no Model A boards mass produced yet, so this would be a good time to do it.  But even if not now, it sounds like a great way of making a future Model A better at no extra cost.

Morgaine.

It is not completely "extra" and "free". The current model B PCBs are also the model A PCBs. Redesigning for an updated model A would add (mostly one-time) costs. Also, note that it is not an "extra" option. You lose the option for "USB host" connectivity. So the "interface with the world" becomes the GPIO, CSI, DSI and USB-device.

Ah, that's no good, I thought you meant that there was an extra and unused USB client-mode port on the SoC.  I can't imagine many people being willing to give up their USB host-mode ability.

So, we're back to bit-banging for client-mode USB.  Far less than ideal, but among millions of Pi users, I bet that someone has a go at that one day.

Ah, that's no good, I thought you meant that there was an extra and unused USB client-mode port on the SoC.  I can't imagine many people being willing to give up their USB host-mode ability.

So, we're back to bit-banging for client-mode USB.  Far less than ideal, but among millions of Pi users, I bet that someone has a go at that one day.

Bit bang a client-mode USB connection? Uhgh.

I'd look at using an MCP2200 or FTDI equiv connected to the UART on the GPIO pins with a couple of wires going to the un-connected d+/d- pins of the micro-usb connector.

And for the IO pin headers, how about using a header with pins long enough to plug in on both sides? The STM32F4 Discoverys I bought have nice long pins allowing IDC connectors top and bottom.

something different...  if there is ever a redesign,  perhaps splitting up the gpio header in a seperate UEXT and GPIO header.

Having a standard UEXT connector would mean that a lot of existing extension boards will be available.

So far i can see the pins are already there (serial,i2c,spi)

Or someone can make an adapter cable of course ...

And please add a RESET button !!

-J