Pi vs BeagleBone-Black

Sorry, reading the thread referenced (and I'm well tired so may have misread) but it seems to me to say that the most of the problems are fixed, and the only problems I still see are for realtively obscure devices. Not perfect, but looks pretty good to me and ive never had any usb problems. So what, actually, are the limitation that some people are complaining about?

Im seeing two people working on the usb stuff, gsh and antoher one, thats not a big engineering effort. There may be more i guess.#

Adding stuff to chips make them more expensive just from silicon area, so be careful what you wish for. You might get better features, but you will also have to pony up more bucks.

Billy Thornton wrote:

 

Adding stuff to chips make them more expensive just from silicon area, so be careful what you wish for. You might get better features, but you will also have to pony up more bucks.

It's not like you'd keep the existing usb core and just add a new one. Removing a flawed piece and replacing it with a working one isn't necessarily going to take more space. That will naturally depend on the implementation details, about which we know nothing.

Morgaine Dinova wrote:

 

they probably have no choice if leaving the Broadcom stable is not an option.

I think that politically, as long as Eben works for Broadcom but aparrently spends most of his time on RPi, going for a SoC form a different manufacturer may be difficult. Even if they can, they'll lose the valuable help from a bunch of engineers who know the broadcom device inside out.

selsinork wrote:

 

Billy Thornton wrote:

 

Adding stuff to chips make them more expensive just from silicon area, so be careful what you wish for. You might get better features, but you will also have to pony up more bucks.

It's not like you'd keep the existing usb core and just add a new one. Removing a flawed piece and replacing it with a working one isn't necessarily going to take more space. That will naturally depend on the implementation details, about which we know nothing.

As i understand it, the usb core requires a big software driver tomake it work because it doesnt do enough in hardware. Chaning to a new hardware block will almost certaily increase the size of the chip, to get that software in to hardware. but my point was actually on the ethernet point - add that and you chips get bigger.

Billy Thornton wrote:

 

the only problems I still see are for realtively obscure devices.

USB is not a bus standard for non-obscure devices.  It is a universal standard for all class-compliant USB devices using the shared class drivers, and it's also a universal standard for USB-compliant devices that provide their own drivers for the host architecture.  This means that all USB compliant devices of any USB version (up to 2.0) and of any speed and used together in any mix are expected to work even through multiple cascaded hubs, as they do in every other computer with USB host functionality.  Old and new devices are all supported, if USB compliant, subject only to driver availability.

Subject to attaching only USB-compliant devices, a USB-compliant host board should never fail to operate its USB system correctly.  (Devices that would exceed available USB bandwidth are validated at connection time and rejected in advance if their needs cannot be met, so that once the session is established it has a reasonable guarantee of proper operation.)

The fact that the Pi's USB system does not handle the connection of completely USB-compliant devices of mixed types without dropping data or breaking USB sessions including networking is a very important fault.  The reasons for the failure are well understood after intensive engineering diagnostic work, and are well documented on the RPF site.  The fact that your own setup does not trigger the fault does not mean that others are as lucky.

selsinork wrote:

 

I think that politically, as long as Eben works for Broadcom but aparrently spends most of his time on RPi, going for a SoC form a different manufacturer may be difficult. Even if they can, they'll lose the valuable help from a bunch of engineers who know the broadcom device inside out.

For his sake, I hope Eben wasn't the chip designer who chose the Synopsys core for various BCM devices.  Whoever made that unfortunate choice is unlikely to be popular at Broadcom, at least among fellow engineers.  It's not easy to overcome problems once they're set in hardware.

And t

Morgaine Dinova wrote:

 

Billy Thornton wrote:

 

the only problems I still see are for realtively obscure devices.

 

USB is not a bus standard for non-obscure devices.  It is a universal standard for all class-compliant USB devices using the shared class drivers, and it's also a universal standard for USB-compliant devices that provide their own drivers for the host architecture.  This means that all USB compliant devices of any USB version (up to 2.0) and of any speed and used together in any mix are expected to work even through multiple cascaded hubs, as they do in every other computer with USB host functionality.  Old and new devices are all supported, if USB compliant.

 

Subject to attaching only USB-compliant devices, a USB-compliant host board should never fail to operate its USB system correctly.  (Devices that would exceed available USB bandwidth are validated at connection time and rejected in advance if their needs cannot be met, so that once the session is established it has a reasonable guarantee of proper operation.)

 

The fact that the Pi's USB system does not handle the connection of completely USB-compliant devices of mixed types without dropping data or breaking USB sessions including networking is a very important fault.  The reasons for the failure are well understood after intensive engineering diagnostic work, and are well documented on the RPF site.  The fact that your own setup does not trigger the fault does not mean that others are as lucky.

So what? Some (obscure?) USB stuff doesnt work very well. Ive got USB stuff that wont work on ubuntu desktops. I've got a usb socket on my car radio that doesnt work with some sticks. You are writing as if the raspberry pi is the only device that has usb problems. it isnt. Loads so. Its a shame it doesnt do everything, but hey, my ute won't go 200kmh. but it does do what I bought it for. Maybe some people dont have all they want out the usb, but a hell of a lot of people do. most of them in fact. You are wrong. I reckon the remaining issues dont add up to an important fault simple by working out the numbers.  its like saying any old product has an important fault if 0.001% of the people using it has problem. thats not true. Most products have some level of fault, and that level is acceptable if it only affect a low number of people. I've got some pos samsung phone, some stuff on it doesnt work very well and it should. So what.

selsinork wrote:

 

jamodio wrote:

 

Unfortunately there is and there will be no real fix for the usb issues with the Rpi.

All sounds like an even better learning experience, a real world problem that can't be fixed. Lots of those exist, so learning how to deal with them and how to chose a compromise would be a useful skill ?

What we have is not a fix but a work around, something very common from any semiconductor company where fixing some problems requires to go back to the silicon drawing board. The Synopsys USB IP included on the BCM2835 does not include a full host mode implementation so we (well them) are using a software layer to make it behave like a host, and since both the Synopsis stuff and Broadcom stuff are proprietary and under NDA getting other knowledgeable and capable people to contribute is almost impossible.

The issue for the Rpi is that the USB interface is its primary way to communicate to the external world, ie other USB devices and Ethernet.

And a major difference at this level between the Rpi and BBB is that the BCM2835 SoC has been developed as a multimedia applications processor, basically a video processor plus a ARM core for supervisory and general functions, on the other hand the Sitara AM355x is a generic microprocessor that is enhanced with image, and graphics processing, and other stuff.

There are also some important differences between the ARM1176J core used on the BCM2835 and the Cortex-A8 used on the AM355x.

This is a great introduction video from ARM about the ARM architecture fundamentals http://www.youtube.com/watch?v=7LqPJGnBPMM

On about minute 8 you can see a slide similar to this one ...

Now, don't get confused (I always do) with the family version and the architecture version.

ARM1176J is a v6 architecture, and Cortex-A8 a v7, where ARM introduced significant changes to support applications and the concept of hardware profiles and was designed from the scratch to support applications where a microcontroller has to run a full fledged operating system such as Linux.

It is also important to note the different implementations of the same architecture, for example Cortex-A8 has a 13-stage pipeline when Cortex-A9 a 8-stage pipeline but both are v7A.

So yes the primary differences between the Rpi and the BBB are under the hood and a big issue with the BCM2835 is that we are not even able to open the hood, we were just given the opportunity to sneak at the some of the GPIO stuff but not even electrical specs and functionality of those pins. For a school kid learning to program in phyton that won't make a big difference but for an embedded research and development engineer makes a big one.

Unfortunately when somebody posted that his customers where not happy using the Rpi for embedded applications and I asked why, I've got a very flaky response.

I'm still trying to explore the viability of the Rpi on this segment but with the actual proliferation of other alternatives (BBB included) the Rpi is loosing points every second.

I'm about to test now the Wandboard with the quad Cortex-A9 Freescale i.MX6.

Cheers

Jorge

Morgaine Dinova wrote:

 

selsinork wrote:

 

I think that politically, as long as Eben works for Broadcom but aparrently spends most of his time on RPi, going for a SoC form a different manufacturer may be difficult. Even if they can, they'll lose the valuable help from a bunch of engineers who know the broadcom device inside out.

 

For his sake, I hope Eben wasn't the chip designer who chose the Synopsys core for various BCM devices.  Whoever made that unfortunate choice is unlikely to be popular at Broadcom, at least among fellow engineers.  It's not easy to overcome problems once they're set in hardware.

of course, they probably dont give a damn since its probably been in their for years and no-one noticed the problem until the raspberry pi came out. I had some involvement in a project that used the videocore3 years ago. That had usb on it. Well, the development kit did anyway. I'd bet it was the same stuff, and the engineers working on it never had any problems that I heard about. I doubt mr upton gives a damn either.

Anyone know how old this usb hardware design is and what else it is in?

Billy Thornton wrote:

 

Anyone know how old this usb hardware design is and what else it is in?

Yes.