Model A Q: Can it be USB client instead of USB host?

[jac1d]

Hello Everyone,

I was looking at my model B and the schematics last night and the SMSC chip is both a USB root hub as well as the USB to Ethernet adapter. This is great if you want to connect USB periperhals to the Pi. But what if you want the Pi to BE the peripheral?

I have an application where I would like to run my Pi as a USB client slaved to another host. I do not believe this is possible on the model B (although I would welcome suggestions on how to do it if it is). However, I -think- the USB port on the model A is driven directly from the Broadcom SoC, which may mean that you can trigger a mode change from USB root hub to USB client within the SoC. Does anyone know if this is possible? It seems likely given the mobile phone lineage of the chip, phones would normally be clients, not hosts.

Also, is there any news on when the model A will be available? I saw a glimpse of it here:

http://www.v3.co.uk/v3-uk/news/2189885/ ... nits-video

And, to qwell the inevitable "why would you NOT want ethernet" responses:

There are lots of embedded applications where the Pi will be part of a larger project and it does not individually require networking or the networking can be achieved over the single USB port, especially if it can be put in client mode.

-Jeff

[Burngate]

Somewhere in the spectrum that goes from yes via probably and possibly to no.

There appears to be no hardware reason why it shouldn't act as a device, but given that the USB subsystem was bought in and appears to be somewhat less than perfect, and is dependant on software, we'll have to wait and see.

The USB is improving daily, due to a lot of hard work by a few clever people, and will eventually work properly, as a host. However device use is likely to raise further problems. The model A is not yet out, and any features of it will not be addressed until at least closer to its launch.

One last point. USB is a host-device system. If you wish to look at USB in the client-server model, then the host is the client and a device is a server.

[mahjongg]

No for the model-B but Yes for the model-A.
For the model-B the built in hub prevents it, but in principle the SoC used has this functionality (USB-on-the-go). Only needs a "switch to client" input signal (GPIO), or be configured permanently as a client. Only I have no idea if the current USB software supports it.

[Jim JKla]

Well Burngate a deeply symantic answer of a kind related to the "Syntax sucks" debate at the time of the BBC and Spectrum and therin madness lies.

There has to be a good argument for making the "A" both a USB Client and Server if for no other reason than to allow students to build a raspberry farm

[Gert van Loo]

Yes, Model-A should be able to work in slave mode. However I have no idea if it requires a special OS port.
I have heard that one of the main reasons why the current USB software is "sub-optimal" is because it was written for and tested on USB slave devices mostly**.
It seems the BCM2835 was the first device to seriously use it in master mode.

**The USB core was one of the few pieces of Silicon IP bought and not in-house developed.
The software stack was part of the delivery.

[Burngate]

Well Burngate a deeply symantic answer of a kind related to the "Syntax sucks" debate at the time of the BBC and Spectrum and therin madness lies. ...

Estate agents mis-apply the client-server model.
As a server, they should wait for me, the client, to initiate a dialogue. Instead, they overload my recycle bin with unwanted flyers

USB treats a keyboard - a client - as a server, so keeps asking if it has anything to say. Hence the 8k interrupts /sec

[Emanuele]

I too hope to get some news about delivery of model A. Unless I missed some posts about it, the latest piece of solid information was that the hardware partners had a contractual obligation to start delivering model As by the beginning of this academic year.

Even if I don't really need it (I have an old USB bluetooth adapter that is gathering dust anyway; hopefully it should work), USB client would be really nice. In that case, would you need a special USB cable to connect a model A to a PC?

[Gert van Loo]

I too hope to get some news about delivery of model A. Unless I missed some posts about it, the latest piece of solid information was that the hardware partners had a contractual obligation to start delivering model As by the beginning of this academic year.

Even if I don't really need it (I have an old USB bluetooth adapter that is gathering dust anyway; hopefully it should work), USB client would be really nice. In that case, would you need a special USB cable to connect a model A to a PC?

Yes, The model A will come with a HOST port. So you need a Host to Host cable, which is non standard.
As part of that you must make sure there is no power going over the cable so either (or both) host power wires need to be not connected.

[jac1d]

To summarize what I think I have heard from everyone so far:

1) It is likely that the Model A is capable of acting as a USB peripheral rather than its current state in the Model B where it acts as a host/root hub. However, it is not yet known if this is a simple matter of flipping a switch in the driver or some other method is required.

Based on Gert's comment that the IP core was primarily developed to act in peripheral mode, it suggests we might even enjoy better stability in peripheral model than we do in root hub mode.

2) Because the connector is a female/host style connector, a non-standard cable or adapter will be needed to wire the device up to an external host, in peripheral mode. This also has ramifications for powering.

3) The philosophical definition of the A is the model B without Ethernet (or the B is the A with Ethernet, I suppose), which may mean this suggestion is moot, but perhaps it would be interesting if the A was a peripheral and the B was a host so that there were two different flavours of the Pi. It opens up a whole different kind of development and programming opportunities. Or perhaps the peripheral model should be a "C" model and have a male USB peripheral connector instead of a host port. That way the powering and other issues could be addressed.

I think the ideal of a model C in peripheral mode with the male connector is quite intriguing and leverages all the design work with just a small change in connector and wiring. And of course what ever is required to flip the driver bit to make the device a peripheral, but that is likely not too hard (hopefully).

Is anyone else interested in a potential "model C" unit as described above?

-Jeff

[Emanuele]

...

3) The philosophical definition of the A is the model B without Ethernet (or the B is the A with Ethernet, I suppose), which may mean this suggestion is moot, but perhaps it would be interesting if the A was a peripheral and the B was a host so that there were two different flavours of the Pi. It opens up a whole different kind of development and programming opportunities. Or perhaps the peripheral model should be a "C" model and have a male USB peripheral connector instead of a host port. That way the powering and other issues could be addressed.

I think the ideal of a model C in peripheral mode with the male connector is quite intriguing and leverages all the design work with just a small change in connector and wiring. And of course what ever is required to flip the driver bit to make the device a peripheral, but that is likely not too hard (hopefully).

Is anyone else interested in a potential "model C" unit as described above?

-Jeff

I can see how Model C could be useful, but personally I would like to defend a bit Model A as it is, since in my view it is the best model by far and it doesn't get the credit it deserves.

The way I saw Raspberry Pi one year ago was a sort of new "Commodore 64". You connect a cheap keyboard, a spare power adapter and an old and small TV via the composite plug. Since you don't need to go through an extra chip to provide power to 2 USB ports and the ethernet port, I believe there is a much better chance for a power adapter that you already have to work well. Fast forward one year, and I fear that the tacit assumption now is that even if you buy a Model A, you should buy a hub anyway, so you can connect a keyboard and a mouse to get the same experience that everyone else has been enjoying with model B. If it wasn't clear already, I strongly disagree. In my view, the only problem with plain model A is that it is too good.

[jac1d]

Now that the model A has been in the wild for a while, I am curious about resurrecting this topic and finding out if any thing has developed on this front that might move this forward?

Have there been any advancements made around turning the model A unit in to a USB device instread of a USB host?

-Jeff

[Jim Manley]

There doesn't seem to be much interest in this since one can use a USB wired/wireless network adapter in the single USB port on the Model A. Of course, you need to determine the IP address of the Pi, but that's easy enough to do by looking at the IP addresses assigned by the local router after the Pi has booted and obtained its address via DHCP.

[jac1d]

Jim,

While you are entirely correct in what you say, it is not correct to associate your suggestion with the idea that there is not much interest in this. Nor does your suggestion address the need that prompted the question in the first place. A quick Google and a search of the forums indicates that is absolutely interest in this from the embedded and various other communities.

-Jeff

[Jim Manley]

Jim,
While you are entirely correct in what you say, it is not correct to associate your suggestion with the idea that there is not much interest in this. Nor does your suggestion address the need that prompted the question in the first place. A quick Google and a search of the forums indicates that is absolutely interest in this from the embedded and various other communities.
-Jeff

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).

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.

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'm not trying to be negative, just describing why more attention can't be paid to things like this. There are a ton of features I'd like the Pi to have, but there is already plenty to do just for educational uses.

[gsh]

Answer:

Yes I've had USB device mode working on the Pi model A. I just haven't had the Linux gadget interface working with it. I don't know if there's anyone out there with the knowledge to have a go but the software should work with it (although with all the work on the USB host we may have broken device mode in the intervening period!)

Gordon

[jac1d]

Jim,

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.

-Jeff

[jac1d]

Answer:

Yes I've had USB device mode working on the Pi model A. I just haven't had the Linux gadget interface working with it. I don't know if there's anyone out there with the knowledge to have a go but the software should work with it (although with all the work on the USB host we may have broken device mode in the intervening period!)

Gordon

Gordon,

I am on a team with someone people who have experience with the USB gadget driver (specifically the cdc_ether network area) on a day to day basis and we would be happy to take a look at the Pi in this mode and contribute what we can (time allowing, we may be a bit slow to respond due to current work load).

In terms of documentation on what you have achieved to date and where we could start reading about chipset/driver, could you share any URLs or details?

Thanks,

-Jeff

[bubnikv]

Hello.

We are also interested into the USB OTG feature for the Raspberry PI A. We would like to use the R-PI as a smart camera for tracking purposes and the data throughput is essential to us. The 100mbit ethernet of the R-PI B is a limit to us and we hope that the USB OTG would eventually provide higher throughput than the possible 1gbit ethernet adapter over the USB 2.

Thanks,
Vojtech

[jamesh]

I don't think you will see much if any improvement in data transfer doing that. Note that all data transfer in and out of the ARM goes via one USB2 port.

[bubnikv]

Thanks for the response, James.

We did some experiments with the mjpeg-streamer sending a test picture in a loop. We achieved highest throughput of around 65kbps TCP stream over a R-PI 100mbit ethernet connected directly to a dedicated ethernet adapter of a Windows 7 box. We had the R-PI overclocked and the top tool indicated 95% of the CPU time spent in the kernel and in the interrupt service. Therefore we learned that the bitbanging of the USB port is likely the bottleneck.

I wonder whether the USB processing could be optimized? At 700MHz CPU clock and 80kbps raw ethernet throughput there seems to be 8.75 CPU clocks per ethernet bit available. It feels like optimizing the inner loop of the USB driver may bring some improvements. Do you find it reasonable to invest time into it?

Thanks, Vojtech

[jamesh]

Thanks for the response, James.

We did some experiments with the mjpeg-streamer sending a test picture in a loop. We achieved highest throughput of around 65kbps TCP stream over a R-PI 100mbit ethernet connected directly to a dedicated ethernet adapter of a Windows 7 box. We had the R-PI overclocked and the top tool indicated 95% of the CPU time spent in the kernel and in the interrupt service. Therefore we learned that the bitbanging of the USB port is likely the bottleneck.

I wonder whether the USB processing could be optimized? At 700MHz CPU clock and 80kbps raw ethernet throughput there seems to be 8.75 CPU clocks per ethernet bit available. It feels like optimizing the inner loop of the USB driver may bring some improvements. Do you find it reasonable to invest time into it?

Thanks, Vojtech

A huge amount of work has been done on the USB driver to make it more reliable. Whether that helps with performance I don't know, but I imagine its pretty well optimised.

Your 65kbs sounds very low. I've seen people posting figures much higher than that. 91MB/s posted here...http://www.raspberrypi.org/phpBB3/viewt ... work+speed

The problem is more likely in producing the data in the first place. Have you tried streaming H264 direct from raspivid using the Raspi camera (1080p30 possible) ? Or are you using a webcam?

[siege]

Gordon, Jeff, Any progress? I'm very much interested in a solution.

George.

[technix]

To summarize what I think I have heard from everyone so far:

1) It is likely that the Model A is capable of acting as a USB peripheral rather than its current state in the Model B where it acts as a host/root hub. However, it is not yet known if this is a simple matter of flipping a switch in the driver or some other method is required.

Based on Gert's comment that the IP core was primarily developed to act in peripheral mode, it suggests we might even enjoy better stability in peripheral model than we do in root hub mode.

2) Because the connector is a female/host style connector, a non-standard cable or adapter will be needed to wire the device up to an external host, in peripheral mode. This also has ramifications for powering.

3) The philosophical definition of the A is the model B without Ethernet (or the B is the A with Ethernet, I suppose), which may mean this suggestion is moot, but perhaps it would be interesting if the A was a peripheral and the B was a host so that there were two different flavours of the Pi. It opens up a whole different kind of development and programming opportunities. Or perhaps the peripheral model should be a "C" model and have a male USB peripheral connector instead of a host port. That way the powering and other issues could be addressed.

I think the ideal of a model C in peripheral mode with the male connector is quite intriguing and leverages all the design work with just a small change in connector and wiring. And of course what ever is required to flip the driver bit to make the device a peripheral, but that is likely not too hard (hopefully).

Is anyone else interested in a potential "model C" unit as described above?

-Jeff

Why another USB port? Just axe the existing USB-A port and replace the micro-B which is now only used as a power pin with a micro-AB which is both capable of being a host and a slave with the 5th pin connected to the appropriate GPIO. No non-standard wiring required, almost looks identical, existing system still work, and bits and pieces from some Android devices can be used.

[mikerr]

you're replying to an old thread,
we did eventually get USB client functionaility of a sort with Model A:
http://www.raspberrypi.org/forums/viewt ... 98&t=74098

but only to act as mass storage for the SD card, nothing else.

[ghans]

The much touted "USB boot" feature of the Mode A / CM is
definitiely essential for flashing , but only a nifty gimmick
compared to what might be accomplished with Linux which
is open-source and has lots of free tools already available
for it (provided somebody in the community
understands the humongous Linux driver or public
documentation on the controller miraculously drops
from the skies).

ghans