Raspberry Pi Model A/A+ host mode
David Feugey (2125) 2709 posts |
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. I have many projects for Raspberry Pi Model A as an appliance, but I still need to find a way to use USB host. I could put some money on USB host mode changes. |
Colin (478) 2433 posts |
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. |
David Feugey (2125) 2709 posts |
Sorry. Typo. Yes, device mode.
So my subject: Raspberry Pi Model A/A+ host [device] mode. |
Dave Higton (1515) 3497 posts |
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? |
Colin (478) 2433 posts |
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. |
Dave Higton (1515) 3497 posts |
Which also precludes keyboard and mouse. |
Wouter Rademaker (458) 197 posts |
Wouldn’t an USB Network Bridge Cable be a solution? A bit like what Colin says. |
David Feugey (2125) 2709 posts |
The simplest way would be to share a whole RAMFS disc.
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.
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.
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.
Not a problem.
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. |
David Feugey (2125) 2709 posts |
Applications With file sharing only: With a complete Ethernet over USB support: 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): |
Rick Murray (539) 13806 posts |
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). 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] 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).
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. :-)
Probably best to reserve the serial port for if you need to hook up a terminal to access the command line.
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.
Or not. Sorry. |
Rick Murray (539) 13806 posts |
Assuming you choose the simple path (Ethernet), you might find this interesting: 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/ |
Colin (478) 2433 posts |
I think the best solution would be to emulate a serial device. |
David Feugey (2125) 2709 posts |
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.
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.
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.
For my needs, it would be perfect (at decent speed of course). 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. |
Dave Higton (1515) 3497 posts |
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. |
Rick Murray (539) 13806 posts |
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.
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.
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.
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.
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.
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.
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!] |
Colin (478) 2433 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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 :) |
David Feugey (2125) 2709 posts |
It’s the solution I use today.
Sorry. Didn’t see this on my setup (Win7). But I’m agree: this is not a good solution. A PoC. Nothing else.
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).
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.
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. |
David Feugey (2125) 2709 posts |
Interesting. And you see what I need :)
Ah, good to know :)
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). |