Hi!
Just curious about what people were planning on using their Raspberry Pi's for once they started getting them!??
Current plan- SFF Media PC / NAS etc mounted onto the VESA on the back of my TV
Later plan- Replace car stereo etc with RPi
Probably not the most origional use there but still, godda start somewhere!
Drew, your mention of the challenge made me daydream a bit about what might make a really useful project, especially for those who have hit hardware limits of the Pi's USB implementation. One way of dealing with the problem is simply to avoid it, and that is clearly what most successful Pi projects have done.
But there is another way too, albeit much more ambitious and requiring much more work, and that is to extend the USB system beyond the reach of the hardware limits of the SoC. Let me explain. I'll use a sort of analogy.
Many people will have heard of the concept of TCP offload engine, which appears in many high-end networking cards as a way of accelerating performance of TCP/IP networking. The general idea is to implement part or all of the network stack in dedicated hardware instead of using the CPU, so that the "NIC" actually becomes a lot more than just an Ethernet interface card. Its level of abstraction is raised significantly, and it delivers a full TCP/IP networking service to the CPU instead of just handing it raw frames of data. The NIC's dedicated hardware has nothing else to do so network responsiveness and throughput are greatly improved, and the host CPU doesn't have to deal with the intensive demands of low-level protocols so it has more time to run user programs, and so everyone is happy.
Well consider if something similar were done with USB instead of with networking layers --- not exactly equivalent, but nevertheless a form of functionality offload. Imagine if the existing USB host port on both Model B and the forthcoming Model A were used exclusively to link to a cheap external microcontroller board, for example the Freescale Freedom KL25Z or the ST STM32F4-Discovery , both of which cost around a tenner or less. ARM Cortex-M microcontrollers like on these boards (M0+ and M4F respectively) tend to have very polished USB stacks with good performance, including totally open source ones. There would be no shortage of resources from which to create a complete USB Offload Engine, by analogy with the TCP one, possibly running under one of the open source realtime operating systems like FreeRTOS or ChibiOS.
The above would deal with the low-level half of the problem on the microcontroller board, but the high-level part back on the Pi would still remain to be done. In essence a new Linux driver would have to be written which communicates with the USB Offload Engine using the Pi's own USB as a simple messaging conduit. Note that the intention would not be to treat the remote engine as part of the Pi's USB device tree, because that would just succumb to the Pi's existing USB controller limitations. Instead, the goal would be to create a new virtual USB device in the Pi's kernel, with communications to that device's actual hardware being carried by the Pi's existing USB system. The latter won't need to know about any USB devices attached to the microcontroller board, and therefore operation would always remain within the BCM2835's capabilities regardless of what USB devices you attach.
Anyway, it's just daydreaming, but the potential for such a high-powered solution is there, and it would be very cheap and provide high USB performance without taxing the Pi's CPU. The tradeoff of course is that it would require a huge amount of work to create this. A fine project!
(It's also worth mentioning that the Pi's other hardware interfacing would be expanded enormously as well.)
Something to think about on cold winter afternoons. 
Morgaine.
Morgaine Dinova wrote:
... USB Offload Engine....
That's a nice extension of Wheeler's Law to hardware: "All problems in Computer Science can be solved by another level of indirection... Except for the problem of too many layers of indirection". Datacom often adapts Wheeler's Law by encapsulating one protocol within another protocol, and that same thing could certainly be done here. The USB traffic between RasPi and the USB Offload Engine can be larger packets with an extra header for device endpoint information.
As you say, a big job. Probably lots of kernel-fu. I suspect most people who have the skill and knowledge to do it would rather work on something else, but it only takes one fanatical masochist to accomplish it 
John Beetem wrote:.
As you say, a big job. Probably lots of kernel-fu.
Not necessarily complex in the Linux kernel, because after all this would be a virtual USB device, and typically most driver nasties stem from having to interface with ugly physical hardware. Here we would be able to invent whatever elegant messaging protocol we like for talking to the offload engine because we control both ends.
It's worth noting that this driver wouldn't have to be Pi-specific at all, and possibly not even ARM-specific because the USB conduit could be coded to work over any generic USB infrastructure.
A USB offload engine for use on any machine with a Linux kernel would be more than cool. 
