Your response was unhelpful and dismissive of the original topic while making observations and assumptions that weren't relevant. I think you failed to grasp the context of the question, so I'm surprised you dove in so deeply. Sadly, Internet forums these days seem to be awash with this type of response.
Your posting history suggests that you have been self appointed as "he who shall roam the forums and shut down any discussion that he feels does not fit his vision
of what the project should be and how it should work." While I am sure you honestly believe this is a high value task and you're helping, I'm not sure that is actually the case.
It can be very discouraging for people new to the project or new to electronics to be set upon in this way. Moreover, it is irritating to the rest of us when set upon in this fashion. If you want to help, I would suggest you try to focus on asking basic questions of posts you contribute to, understanding context and then if you have value to add, adding it then. If not, there is no shame in staying silent and moving on to the next post.
Jeff - I'm referring to the number of people that need, much less want this, and it's miniscule compared to the number of Pi users Out There who don't. The lack of response to this thread since it started and was last posted to in August 2012 is the true indication of how much interest there isn't. If anyone really wants this, they're going to have to learn to do it themselves, assuming it's even feasible, and I haven't seen any documentation that it is (just because there's a rumor that a bit can be flipped in a driver doesn't mean it's true).
Jim, it may surprise you to learn the entire pi world is not these forums. This particular topic has garnered attention in various areas, especially embedded systems, and does come up regularly. Using the number of messages in this thread as the sole arbiter of interest in something is short sighted. This was already mentioned politely. I'm not sure what your motivation is to attempt to so aggressively shut down a topic you clearly have no interest in.
It is more than a rumour that the device supports OTG mode. It is a documented feature of the chip set and central to the original target application of a mobile phone. The maturity of the driver OTG mode and the relatively immaturity of the host mode driver (at time of launch) was a source of much discussion and some initial teething issues. Access to this driver function is still open for discussion, of course, but then that is the purpose of the thread isn't it?
If anyone really wants this, they're going to have to learn to do it themselves
I think you have made an interesting leap in your reading of the thread. No one was demanding that the foundation stop what they are doing and implement driver support for this. The question was being asked if anyone "who really wants this" has done any implementation work on it since the thread was started.
Since I started writing this very post, Gordon has chimed in with a positive report of the type I was soliciting. It sounds like we may be able to build on his success to achieve our goal. Thanks Gordon!
Using the USB port as a client has no advantages over a USB network interface because the throughput over the Pi USB bus isn't what people think it should be. 400 Mbps is the theoretical maximum instantaneous bit-rate for USB 2.x, not the actual throughput in practice. If there is any other activity on the bus between the host and other clients, the data rate drops to significantly less than the theoretical maximum rate divided by the number of clients plus the host. Also, there may still be some issues with the USB bus on the Pi that reduce throughput further, although I don't know if that's true with the Model A (e.g., the issue may be due to software interactions with the Ethernet/USB controller on the Model B). It's much more important that those issues be resolved before any effort is put into a USB client mode, if it's even possible.
Jim, thank you for the free lecture on the operation of USB. It might surprise you to know that most people who are interested in this topic at a low level are already well versed in USB. But let's take some of your comments one by one in the context of the original question:
Using the USB port as a client has no advantages over a USB network interface because the throughput over the Pi USB bus isn't what people think it should be.
You make a sweeping assumption here about the advantages or lack thereof of using the USB port to connect to another host. It also assume the host even has a traditional network interface, which it may not (think embedded systems). Your assumptions further focus only on throughput, which is short sighted. Throughput is but one of the considerations. From an educational and creativity perspective there are an infinite number of applications where the throughput would be more than adequate even at a fraction of USB2 theoretical max.
One of the principal benefits of being able to connect the model A as a USB device to an upstream host over a single cable is that it provides an extremely cost effective and easy to implement solution.
For any project where creating a large cluster of Pi devices is desirable, this is a very cheap, elegant and scalable solution. A single (albeit specialized due to powering considerations) cable could both power the device and carry a substantial amount of data on a point to point basis. Depending on where this will be deployed, traditional networking with WiFi or Ethernet may not be an option. Designers deal with many constraints including RF characteristics, cost budget, space budget, available power etc. Thus this discussion about alternate options.
It's much more important that those issues be resolved before any effort is put into a USB client mode, if it's even possible.
It's a big world out there, Jim. No one was suggesting this be done at the expense of work being done on host mode support. Someone may have already resolved this issue, thus the thread. Again, you might want to avoid leaping to the conclusion that every question or discussion is some how a formal demand on the limited resources of the foundation itself. Most things are ancillary discussions from people who enthusiastically support the project and are sharing their achievements, discoveries, questions, desires and ideas.
The Foundation's top priorities are to make the Pi more useful for educational purposes, not to satisfy every whim of small constituencies that, if they really had the technical need, could work out the necessary technical issues.
I think you should have to post your badge number before you're allowed to lecture others like this in threads where you don't add any real value. I should also point out that this "small constituency", via this discussion, is attempting to "work out the necessary technical issues".
There are a multitude of educational applications for being able to operate the Pi as a device instead of a host. The imagination of Pi users, young and old, can tap in to a whole new world with support for this capability. Many, many Pi users already have other devices that are working along side the Pi. Opening the door to linking them together with this type of structure is a net win for the platform from an educational and creativity perspective.
So while I agree, it is not a foundation priority, it is also incredibly narrow minded to dismiss the idea out of hand. As I said, there is no shame in staying silent and moving on to the next post if a topic isn't in your area of interest or expertise.