Raspberry Pi Model A/A+ host mode

Would it be difficult to implement a USB host mode for the two Raspberry Pi Model A?

The idea is to connect a RISC OS Pi device as a host on another computer.
With share of some local RAMFS resource (and if possible Ethernet other USB).

I have many projects for Raspberry Pi Model A as an appliance, but I still need to find a way to use USB host.
Under Linux, or – better – under RISC OS :)

I could put some money on USB host mode changes.

I presume you mean device mode – it already works in host mode. In device mode you would plug the pi into another computer and it would be seen by the other computer as – well I suppose it could emulate any device you want.

A quick look around the net suggests that it is only possible on the model A because it doesn’t have a hub. You can’t have the pi working as a host (Ethernet and other usb) and as a device.

If you had a pi working as a device you would be limited by the drivers available on the host computer so for example making the pi look like a combination of any standard usb classes is possible – though not easy – without requiring specific drivers on the host.

Sorry. Typo. Yes, device mode.

A quick look around the net suggests that it is only possible on the model A because it doesn’t have a hub. You can’t have the pi working as a host (Ethernet and other usb) and as a device.

So my subject: Raspberry Pi Model A/A+ host [device] mode.
Emulation of a storage device should be enough (ethernet mode would be cool also).

OK, so you want an A+ to behave as an 8-6-80 device.

Do you intend to write the device under RISC OS or something else?

What do you intend as the medium to export? Do you intend it to be a file (which AIUI would limit you to 4 GiB), a partition, some reserved space, or what?

Looking at it from the highest level, what are you expecting to achieve that couldn’t be achieved much cheaper by buying a USB card reader/writer and putting an SDHC card in it?

As there is only 1 USB controller on the pi if you are using it in device mode you can’t use it in host mode so you can’t use ethernet or usb on the pi.

Wouldn’t accessing the pi’s data storage via ethernet or serial port do or is that too slow.

Sorry if I’m sounding a little negative I’m just struggling to justify the the work involved to make the pi work like a sd card reader.

if you are using it in device mode you can’t use it in host mode so you can’t use ethernet or usb on the pi.

Which also precludes keyboard and mouse.

Wouldn’t an USB Network Bridge Cable be a solution? A bit like what Colin says.

What do you intend as the medium to export? Do you intend it to be a file (which AIUI would limit you to 4 GiB), a partition, some reserved space, or what?

The simplest way would be to share a whole RAMFS disc.

Looking at it from the highest level, what are you expecting to achieve that couldn’t be achieved much cheaper by buying a USB card reader/writer and putting an SDHC card in it?

I want to have a computer behind. One of my two projects is to offload compute to a Pi. You connect it as an USB key, send a file with commands, another with parameters, wait for a result file to appear and get it.

Need more power, add more Pi with an USB hub.

As there is only 1 USB controller on the pi if you are using it in device mode you can’t use it in host mode so you can’t use ethernet or usb on the pi.

I mean, Ethernet over USB. A classic way to access a Linux key in device mode. Permits things as server applications on the key. It’s better than a simple “see me as an USB key” mode, but more complex to set up.

Wouldn’t accessing the pi’s data storage via ethernet or serial port do or is that too slow.

If you have a lot of Pi, it’s not really a good solution. The switches and cables will take more room and use more power than the set of Pi.

A serial port would be OK, but will be too slow. GPIO is not fast enough either.

Which also precludes keyboard and mouse.

Not a problem.

Wouldn’t an USB Network Bridge Cable be a solution? A bit like what Colin says.

This type of cable only simulates device mode (slowly). You don’t need it with a Pi Model A. And anyway, you still need software/driver to support file sharing emulation or Ethernet emulation.

Of course, the best would be to have a driver that can convert the Pi in an Ethernet over USB device. Then you’ll be able to use any server software as usual (ftpc, webjames, vncserv). From the PC, Ethernet over USB is supported. For the RISC OS host, you’ll need another driver. So it’s probably a bit complex. To emulate an USB key is probably simpler.

Applications

With file sharing only:
- clustering (of course, just for test or research, since the Pi has not a very good perf/watt ratio).
- file management (crypto, converters, etc.)

With a complete Ethernet over USB support:
- RISC OS in a box, accessible from any PC.

I have interests in both. Clustering, as I’m working on compute things. RISC OS in a box, to deliver some of my software as appliances (and stop using Windows for good in my business projects :) ).

More information (not really useful):
http://www.raspberrypi.org/forums/viewtopic.php?f=98&t=74098
http://elinux.org/RPi_Tasks#OTG_device_mode

I want to have a computer behind. One of my two projects is to offload compute to a Pi. You connect it as an USB key, send a file with commands, another with parameters, wait for a result file to appear and get it.

I hate to burst your bubble, but what you are asking is impossible.

In order to present a device as a “USB key”, you will be working in MSC mode. This is the one where plugging it in gives it a drive letter (under Windows) or an icon on the iconbar (under RISC OS).
The problem? MSC works at the level of the underlying filesystem structure. In other words, the host will be asking the USB device to read and write sectors, and it is the host that will be dealing with the disc format (among other things). If you made a RAMdisc a valid USB device and plugged it into Windows, it would not be understood. It would need to be formatted as a FAT or NTFS volume. Then it would be understood, by the host.
Because of this, it is absolutely NOT possible for the device providing the filesystem to be able to access that filesystem at the same time as it is connected to any host. Why? Because the host will be managing the filesystem. Free space, directory structures, caching, you name it. Changing anything will be a recipe for disaster.

Don’t take my word for it – go find any Android phone that shares its SD card in MSC mode. Plug it into a PC. Notice that the SD card is now completely inaccessible to Android.

Two devices simply cannot be permitted low-level access to a filesystem at the same time.

You could, perhaps, consider MTP mode (works at a higher level) but I do wonder if all the effort will be worth it? http://en.wikipedia.org/wiki/Media_Transfer_Protocol [EN] / http://fr.wikipedia.org/wiki/Media_Transfer_Protocol [FR]

http://elinux.org/RPi_Tasks#OTG_device_mode

Amusing reading. All that work to try to “debrick” a “bricked” SD card. Me? I’d just burn a recent clone into a spare SD and swap. Job done in five minutes (and most of that is making the SD).
No need to make a simple job complicated.

If you have a lot of Pi, it’s not really a good solution. The switches and cables will take more room and use more power than the set of Pi.

True, but the use of Ethernet has a number of benefits that might outweigh this. I should ask – how many RPis do you plan to hook together? You can get some pretty low-power 8, 12, 16 port switches these days. And as for cables, you might be able to make do with those dinky patch cables that are about 25cm long. Long enough to join two devices in proximity, short enough not to have metres of cable coiled up.

Anyway. Ethernet. Widely compatible. Pretty much anything with an ethernet socket can be plugged in and provided the desired software is loaded (web server, or what-have-you), it should “just work”. The RISC OS ethernet stack isn’t overly difficult to use, writing servers and clients is fiddly but not impossible. Using C makes it much easier as you can just call the functions in TCPIPLib for a lot of it. In BASIC? Doable, but have fun with the crazy indirections you’ll come across. :-)
Ethernet uses the concept of “ports”. Your server will run on a port. Like 80 for http. If you want to provide another service, you just write the software to hang off another port. No insane reconfiguration. No thinking “oh crap, how can I share a serial port between multiple programs?”, this is basic functionality of how the Internet module (and TCP/IP as a whole) works.

A serial port would be OK, but will be too slow.

Probably best to reserve the serial port for if you need to hook up a terminal to access the command line.

GPIO is not fast enough either.

Of course not. The benefit of stuff like IIC, serial, and USB (counting ethernet as it hangs off USB on the Pi) is that a lot of the behaviour is pushed off to hardware. There’s no need to poll I/O lines for changes, or to respond to every single twitch of an I/O within an acceptable time. Just leave it to some custom hardware and it’ll interrupt when it has something to say. Back in the ’80s, a small IC could cater for serial communications at 19200 baud, and it would raise its hand for each byte received. It took us two decades before we had a computer fast enough to perform the same task by directly reading the state of the logic lines. And it is probably about today when we have computers powerful enough to do it reliably and do other stuff at the same time.
So, yes, if possible, push an I/O job to some dedicated hardware.

To emulate an USB key is probably simpler.

Or not.

Sorry.

Assuming you choose the simple path (Ethernet), you might find this interesting:
http://raspberrywebserver.com/raspberrypicluster/raspberry-pi-cluster.html
(that site actually runs on the Pi cluster described)

But be realistic. The document above says “you’d probably need about 20 Pies to produce a cluster with as much computing power as a PC”. This should be done for enjoyment and education, not to build a kick-ass cluster.

Another: http://likemagicappears.com/projects/raspberry-pi-cluster/

And some nice pictures on this French site: http://www.framboise314.fr/33-framboise314-pour-10-gflops-un-supercalculateur-a-base-de-raspberry-pi/
Actuellement, Framboise314 est bien interessante!

I think the best solution would be to emulate a serial device.

I hate to burst your bubble, but what you are asking is impossible.

You forget something: Windows does not use caching on USB keys. Never. So with some limits (don’t create new files, just append data to them), it should be possible. I proposed this, because I used with some equivalent configuration before (a DOSFS file used at the same time by RISC OS and the PC Card).

But I’m agree: this is not a good solution. A good solution would be to have an Ethernet over USB implementation (long term goal) or a simple way (serial emulation?) to exchange data (short term goal). Filesystem emulation can only be a very short term goal. A PoC.

True, but the use of Ethernet has a number of benefits that might outweigh this.

Yes, but perhaps not with an Ethernet port, especially with USB 3.0 coming. Ethernet switches are more pricey, use more power and are slower than USB 3. And you’ll use two cables: one USB for power, one Ethernet for data. Not very optimised. Problem: I don’t see a lot of PoE ARM modules on the market… but a lot of USB ARM modules.

IMHO, It would be better to stack a few boards with USB (in a 1 U case). This compute node could then be connected to other nodes with Ethernet 10G.

But be realistic. The document above says “you’d probably need about 20 Pies to produce a cluster with as much computing power as a PC”. This should be done for enjoyment and education, not to build a kick-ass cluster.

70W for the equivalent power of a PC, it’s not very interesting… 20W is better. Replace the Pi with some Humminboards, or OMAP cards, and it’s a bit different. Use 100 Pi and it’s different too, especially for developers who want to test HPC code. 100 Pi Model B + 3 or 4 switches will use a quarter of a rack. 100 Pi Model A + 10 USB switches, could be stacked in a PC case or a 3U server case.

I think the best solution would be to emulate a serial device.

For my needs, it would be perfect (at decent speed of course).
I don’t really need Ethernet over USB, even if it would open doors to very interesting uses (for example a RISC OS box), so a broader audience.

Today I use some Pi with Ethernet for my tests. But there are some problems, especially with network configuration and security. To make my compute nodes, I could use USB device mode under Linux (with more powerful motherboards), but I prefer not to leave the RISC OS world, even if I need to give money to a developer to get a driver.

The fact is that my software (very long term project, but in progress) is a RISC OS one. I would like the compute modules to use the same OS, but there is no obligation.

Ah, OK. We’re getting somewhere.

You can get an Ethernet switch that consumes about as much power as one or maybe two RPi’s. You can network the sort of number of devices that you’re talking about, quite easily.

Once you do that, you can share all the drives you like between the machines by ShareFS. This applies equally to RAMFS, SD or rotating drives. The problems of contention for files have been solved for you. Not to mention that you have all the inter-machine communication that you require, at pretty good speed and latency.

Faced with the simple, existing alternative, I can’t see anything to recommend your proposed solution.

Third bloody time. I hate how this forum randomly kicks you off and throws away your message with a “You must log in”. I don’t have all afternoon to write this.

Windows does not use caching on USB keys. Never.

Yes. It does. I’m not going to write it all a third time, just to say you are probably thinking of this:

There is a difference between write caching and read caching. Do you really think Windows will re-read the directory and drive mapping every single time when it can remember that stuff?

Oh, and as you might have noticed, the user can choose to turn on caching. It’ll make things faster, at the expense of having this happen if they pull out the media without dismounting it:

That, incidentally, happened when I removed a CD-ROM. Go figure.

Anyway. Having two devices attempting to maintain low-level access to a filesystem at the same time is a recipe for disaster.
Oh, and did you catch the part where I mentioned that the host machine handles the disc format? If you want to plug it in to a PC, it will need to be FAT formatted. If you want to plug it into another Pi, it will need to be FileCore formatted (is RAMFS a FileCore format internally?).
If you want to run USB interconnections to twenty different machines….well, I’d take my hat off to you if you manage to get that to work.
Ethernet, on the other hand, can do it. No sweat. Any decent switch will also allow machines to talk to each other at their full speed. For example, machines 1 and 2 can talk at full speed and machines 3 and 4 can do likewise without the pairs interfering. Can you say the same for USB? You do understand, I hope, that a USB switch will require you to correctly dismount a storage device before switching it to a different machine? It isn’t intended to share the same device across multiple machines at the same time. For that, you’d want a NAS and…yup, you guessed it, ethernet!

Yes, but perhaps not with an Ethernet port, especially with USB 3.0 coming.

Not really relevant with the Pi. Not really relevant at all, I’m afraid.

The Pi is benchmarked to run its I/O between 170mbit/sec and 250mbit/sec (can’t be bothered finding references again, I provided loads, go pee on Josh and Rick for making Beast so crappy). Anyway, the point is that while the Pi can run its ethernet at full speed (something around 12MiB/sec flat out, IIRC), it cannot fully utilise its single USB2 port.
So if a 700MHz ARM can’t max out a 480mbit/sec USB2 port, can we expect a 1.5GHz ARM to do well with USB3? I wonder, even, if the 1GHz Beagle is enough to max out USB2. Adding more cores won’t help as we’ll be running into limitations of the I/O itself.

Problem: I don’t see a lot of PoE ARM modules on the market… but a lot of USB ARM modules.

That is probably because the USB hardware probably already provides some support for OTG. It is used in some mobile phones to allow what is normally a USB device to become the host and allow USB media to be plugged in.
PoE, on the other hand, is less likely to be desired. Why? It isn’t a normal method of powering these ARM boards. Given that PoE is anything from 35-56V (nominally 44-48V at source), there will need to be voltage regulation. Spike suppression. All sorts of stuff. A PoE on a Pi would probably double (if not treble) the build price.
PoE does exist on ARM devices – IP cameras often use it – but it is a manufacturer choice. It isn’t there as standard. OTG probably is.
I understand from my web searches that the Pi actually has an OTG port somewhere, it just isn’t tracked out.

70W for the equivalent power of a PC, it’s not very interesting…

20 Pi will cost about the same as a mid-range PC. I think the point is that you can do distributed computing “supercomputer style” on something you can make yourself without bankrupting. Real actual hardware.
Plus, it’s cool. Let’s face it. It doesn’t matter if your 20 Pi do nothing more than blink LEDs at random. Just wire them up and you’re instantly elevated to the status of hardcore geek. ;-)

20W is better.

Cheapest 24 port switch I could find → http://www.amazon.fr/TP-Link-TL-SG1024D-Switch-Gigabit-rackable/dp/B003UWXFM0/ TP’s website claims the power draw is 14.6W max.

If an eight port will do you, there’s a lovely bit of kit available in the US for $20. http://www.amazon.com/gp/product/B007KZQM8W/ Add around $13 to ship to France, coming to about €26 all in. It consumes less than 5W when running all eight ports.

Replace the Pi with some Humminboards, or OMAP cards, and it’s a bit different.

Certainly. The Pi will run on power sources that wouldn’t get the Beagle xM as far as starting up the bootloader…

I’m afraid I’m going to have to side with Dave. Well, he’s agreeing with what I said earlier but same difference. Ethernet is simple to use, simple to implement, has been tried and tested for a long long time, can be used far beyond the point of just passing files between machines (sharing status? job control? etc). ShareFS itself has been around for almost a quarter century (it popped up circa RISC OS 3, didn’t it?). It is a tried and tested protocol.

You can place an order or two with Amazon, Farnell, etc and have your 20 Raspberry Pis talking to each other by the weekend (maybe, depending on postage). When do you think you would finish your Pi-as-a-USB-device driver? If ever?

Don’t make like difficult for yourself.

[copied to clipboard, I ain’t writing this a fourth time!]

Just to balance things up :-) I’ll side with David. If you are going to be geeky enough to connect 20 pi together then you may as well go the whole hog and communicate with them via USB after all a pi a+ doesn’t have an ethernet port and only consumes 200mw.

You’d just need the device to present a control, bulk in and out endpoint. The host side is already written just open the bulk endpoints in DeviceFS to read and write data to the device. On the device side you have complete control of the controller just kill the USB modules, it doesn’t need to be anything special you just respond to standard control requests. There’s no need to emulate any higher level protocol, no need for fancy programming to share the resource like there is when the usb device is used in host mode. You end up with a connection that is as fast as usb can go. It’s about as easy as programming a usb controller gets – which is not easy unfortunately :-)

If the device side was written I can see it being preferable.

FWIW the MUSBDriver module (used for the USB OTG controller on OMAP3 boards) has rudimentary support for device-mode operation. Just enough that I was able to get *USBDevices of the host machine to show “RISC OS computer” when I connected my BB to it. But I haven’t tested it recently, so it might be that it’s a little broken now.

I’m not sure how much support there is for device-mode operation in the Pi USB driver. Certainly the original DWC driver has support for device mode operation, but I’m not sure if it was ever hooked up to Linux, and I’m fairly certain I disabled building of the code under RISC OS to cut down on the amount that needed to be ported over (and to reduce the code bloat a bit).

Plus of course we don’t have any OS APIs to allow USB device emulators to register themselves with the device-mode hardware driver :)

Faced with the simple, existing alternative, I can’t see anything to recommend your proposed solution.

It’s the solution I use today.

Yes. It does. I’m not going to write it all a third time

Sorry. Didn’t see this on my setup (Win7). But I’m agree: this is not a good solution. A PoC. Nothing else.

Not really relevant with the Pi. Not really relevant at all, I’m afraid.

I don’t expect to get more performance. Just the same, with one less cable and no need for a big switch (because switch with more than 16 ports are pretty big and impossible to integrate in a server box).

You can place an order or two with Amazon, Farnell, etc and have your 20 Raspberry Pis talking to each other by the weekend (maybe, depending on postage). When do you think you would finish your Pi-as-a-USB-device driver? If ever? Don’t make like difficult for yourself.

I repeat: I already have a multinode Ethernet setup. I just want to go further with a more simple solution. Network cables and switches use a lot of room and power. USB device mode could permit me to remove them… and to go further on the project, with a setup more easy to scale, setup, manage, demonstrate and duplicate.

When do you think you would finish your Pi-as-a-USB-device driver? If ever?

Never. I don’t want to make it. Just to know if it’s possible. Then, I’ll probably put money on such a project because I need it for my own project.

It doesn’t need to be anything special you just respond to standard control requests. There’s no need to emulate any higher level protocol, no need for fancy programming to share the resource like there is when the usb device is used in host mode. You end up with a connection that is as fast as usb can go. It’s about as easy as programming a usb controller gets – which is not easy unfortunately. If the device side was written I can see it being preferable.

Interesting. And you see what I need :)

FWIW the MUSBDriver module (used for the USB OTG controller on OMAP3 boards) has rudimentary support for device-mode operation. Just enough that I was able to get *USBDevices of the host machine to show “RISC OS computer” when I connected my BB to it. But I haven’t tested it recently, so it might be that it’s a little broken now.

Ah, good to know :)

Plus of course we don’t have any OS APIs to allow USB device emulators to register themselves with the device-mode hardware driver :)

Just to be able to transfer data between RISC OS computers (x in device mode and 1 in host mode) would be enough. My (not yet definitive) idea, would be to make 6 modules nodes (1 master Pi with Ethernet that controls 6 Pi A in USB mode). So it’ll be easy to make a 42 nodes computer with a small 8 port Ethernet hub. Today, more than 16 nodes need a very big hub. Of course, I will still need a PiLinux config for DHCP and routing (so 42 compute nodes max).