USB discussions getting a bit heated

Reading that "USB - the Elephant in our Room" thread on the RPF forum again is really depressing.

From the fanbois' typical "It works for me so your complaints make no sense", or "You shouldn't expect it to work because the Foundation makes no money", to JamesH's repeated strawman of "We would need to test EVERY SINGLE USB DEVICE", it makes you wonder what it is about the Foundation that its most vocal defence comes from those with impaired logic ability.  The correlation seems strong.

There's probably some kind of thesis in psychiatry available there.

Reading that "USB - the Elephant in our Room" thread on the RPF forum again is really depressing.

Don't read it then   I think it's unfortunate that while there's a couple of people who seem willing to discuss solutions, Pete & dom spring to mind, most of the productive discussions are getting swamped in the noise.

Morgaine Dinova wrote:

PS. I've  just discovered that the Ethernet MAC on the TI AM 3358/9 is 10/100/1000 !!  It's only the PHY on the BeagleBone that limits it to 100Mbps.  So it's even more "proper" than I thought. :-)

Actually, the AM3358/9 have versions with two 10/100/1G Ethernet ports which can be coupled to make a three port Ethernet switch (the third port being the CPU).  It also has support for IEEE 1588 Precision Time Protocol, if you really want to know what time it is

John Beetem wrote:

 

Actually, the AM3358/9 have versions with two 10/100/1G Ethernet ports which can be coupled to make a three port Ethernet switch (the third port being the CPU).  It also has support for IEEE 1588 Precision Time Protocol, if you really want to know what time it is

Awesome chip.  It needs someone to make a rock-bottom board using it to compete at the Pi price niche.

There are quite a few things that could be whittled off the BeagleBone to bring the BOM cost down from $89:

• The PMIC expansion header and LCD/backlight interface are not essential.
• The PMIC itself has a lot of extra features outside of power management that may be superfluous in a bottom-end board so a cheaper PMIC may be available.
• The front-end USB hub is not essential.
• The front-end FT2232H that connects to the USB hub is not essential.
• The BeagleBone's USB device/host flexibility could be reduced by routing the SoC's two USB OTG ports to a combined host USB connector for lower cost.
• The reset button is not essential.
• The two large expansion headers provide good physical support for daughterboards, but could be shortened to reduce cost.
• If one must play RPF-type marketing tricks, don't supply the micro-SD card with the board.
• It must be remembered that in addition to BOM reductions, there will be at least one increase:  HDMI socket and associated circuitry, which must be on-board..

I bet that such reductions could get the BOM cost down down to the Pi price niche for Pi-type volumes.  BeagleBone is made in much smaller volumes than Pi, so their volume price breaks are probably not very good currently, but with volume sales that would change dramatically.

Morgaine.

Morgaine Dinova wrote:

 

I bet that such reductions could get the BOM cost down down to the Pi price niche for Pi-type volumes.  BeagleBone is made in much smaller volumes than Pi, so their volume price breaks are probably not very good currently, but with volume sales that would change dramatically.

I think the key here is volume.  In large volumns BB could probably come down to under US$50 even with the current BOM, and the DVI cape could come down to US$15 instead of US$50.  Another cost factor is USA manufacturing, but I'm happy to pay a bit more and not wonder about quality.

I like having a separate video cape so you have the choice of VGA (coming soon!) or LCD.  But à la carte is always going to be more expensive.

True, the flexibility of BeagleBone is very high, but unfortunately price is king.

Sadly, the board is priced above the point on the budget radar where price is no barrier for the average pocket in the "West" (often said to be the price of an evening out).  But the board is also so well specified that there is ample room for a bottom-end product of that line created through feature reduction.

The Beagle family would be rounded off beautifully with a "BeagleBite" (to stay within their naming meme), where everything except reliability is sacrificed at the altar of BOM cost.  And when sales rocket in reverse exponential proportion to price, the team would find itself with a whole product line ready to cater for different use cases, unlike Pi.

Morgaine.

Actually, the AM3358/9 have versions with two 10/100/1G Ethernet ports

Doesn't take a lot of imagination to realise that a lot of people would be interested in a cheap device with two decent ethernet ports.  Different target market, but still.  With three configurations, one with usb only for all the weird wifi lovers, then single wired port and dual wired port versions you have an interesting device.

Only question is whether the Arm is fast enough to deal with two 1G ports. I've come across a fair few of those little nas enclosures that do have 1G ports but barely manage 100M speeds on them.

And when sales rocket in reverse exponential proportion to price, the team would find itself with a whole product line ready to cater for different use cases, unlike Pi.

If nothing else the Pi has proved there's a market for a cheap device. Hopefully another device will rise to that challenge and some healthy competition gives us some interesting devices to use.

Probably right, but remember that the R-Pi has been always promoted as a cheap linux "computer," many people realize that to make it work as a computer there is other stuff and extra expenditure associated with it.

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

-J

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 !

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.

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.