Interesting Linux hack

Greetings all. A project that I have wanted to work on for some time is to write some kind of USB interface for Linux so that the following scenario could be achieved:

Linux is running on a laptop (netbook to be precise). Machine B can be any other computer (Windows, Mac or Linux, should not matter).

I want to write an app or driver such that when run (myApp -i /dev/usb1 -p folder) it would reconfigure (in this case) /dev/usb1 and attaching "folder" to it. Folder can be any local directory. Finally I would plug a USB cable into the correct Linux port and connect the other end of the cable to the USB port on Machine B. The payoff is that the Linux box would appear to Machine B as if it were a standard USB (or other) drive. MP3 players do this all the time and I read somewhere that Macbooks can do this too.

So my questions are:
1. Does something like this already exist? If not
2. What would be the best general way to approach something like this in terms of libraries and such?
3. Finally, can anyone yield any links to info that might help with this?

I think the utility of this would be extraordinary....

TIA..
Jeff

Linux-USB Gadget API Framework

The secret Google magic was "usb slave driver," a term which I wasn't sure about but figured it might be right.

I dunno if brewbuck's suggestion will suffice.

However, I've written simple usb kernel drivers before. The first thing I would do is plug the cable in connecting the two usb ports and see if anything shows up under lsusb -- this does not require a driver (other than the usb hub driver), but a (more specific) driver does require this (for the hub driver to recognize some kind of attached device). Presumably it will be the hub at the other end? I don't have a male/male USB cable so can't try it.

Hence: if you have no listing under lsusb, you are probably out of luck, can't be done...not without serious hacks to the hub driver, anyway.

Thanks; about an hour after posting this last night I found the Linux USB-Gadget link you mentioned (and it was some Google search phrase magic that made it finally turn up...I would never have thought of adding 'slave' to the search phrase). I am trying to find the most recent version of the source now and poke around with the File Backed Storage gadget. One thing about that which caught me by surprise is that the data-store is not interactive, or at least not safely so. Admittedly this article is from 2005 and a lot can happen by now, I did kind of want the ability to interact with the data being stored (from the linux-user-space) while it was pretending to be a drive for someone else. It is not a big-driving need, just one that I would like to see.

In any event tks for the help all. MK will you be on your chat server later?

BTW this is a part of a larger project that will take a lot of time (and a few $$ so I can do it as money becomes available) but as some of you may or may not know, I have had an Asus EEE 701 that has served me well for years....until recently when I accidentally stepped on the lid, cracking the LCD screen. The computer part still works but the rest is hosed. Now from the "turning lemons into lemonade", what is an enterprising fellow to do with a full (linux-based, not that it matters in this context) pc in an extremely light-weight form-factor (whole thing is just over a pound) with a full array of ports and 20 gigs of storage/1G of ram? Well how about using it as a mainboard for a robot? Built-in wifi along with an exposed USB port so that (when used with the above) would allow one to jack the robot into any laptop exposing most of the OS, allowing for easier installation of updates, fixes, etc. I am looking for for a proper chassis to get started with, mounting the remains of the EEE, wiring the servos to the PC over USB/possibly serial. This would give me a jump-start/foundation to start building/experimenting. A lot of times single-board computers useful for such things have various limitations...by starting with what is essentially a PC and a stock Debian (probably) install, the possibilities are endless. Note; one reason I am starting with so much of it pre-fabbed is that I just bought a new house and just (like 4 weeks ago) started a new job so I don't have much of a work-area built up yet. Anyhow it sounds like fun and while the wife sees a pile of junk, in my head I see:

File:Ed-209.jpg - Wikipedia, the free encyclopedia

If I'm not mistaken, you'll not be able to do this. The hole deal about USB is that it is a HOST/CLIENT type connection. The cables that link computer to computer also have inside them a USB->ETHERNET type converter in them (about $2) which makes it work. I am pretty sure that you'd need a FUNCTION or CLIENT type port on your box to make it work -- But I'm not 100% sure on this.

Good luck!

Originally Posted by jeffcobb

I would never have thought of adding 'slave' to the search phrase

Well, I had just got off the phone with my mother, so the term "slave driver" just kinda popped into my head.

Originally Posted by brewbuck

Well, I had just got off the phone with my mother, so the term "slave driver" just kinda popped into my head.

Boom-tish!

Originally Posted by Kennedy

If I'm not mistaken, you'll not be able to do this. The hole deal about USB is that it is a HOST/CLIENT type connection. The cables that link computer to computer also have inside them a USB->ETHERNET type converter in them (about $2) which makes it work. I am pretty sure that you'd need a FUNCTION or CLIENT type port on your box to make it work -- But I'm not 100% sure on this.

Good luck!

I *will* make it work. In truth it is not high-priority for the project I outlined above but it is the principle of the thing. Besides, MP3 players do this all the time and as I may have may have mentioned, Macs can do this (plug one Mac into another via USB and one becomes a slave/drive). Used for backups and such...

If I'm not mistaken, you'll not be able to do this.

O_o

He will absolutely be able to do this. (I'm assuming an infinite timetable and a desire to learn.) It already exists. It isn't even expensive. (If I knew him, I could source him a controller to act as the "middleman" for about $4.50 USD, but then he would have to wire the "mini-b" connectors himself.)

If you want this to "just work" you'll have to do a lot of work. (It would be a lot easier if you are were only interested in a "file storage" mode.)

All you really need is a "middleman". You need a small controller to act as the "client" from both hosts. It isn't difficult. It isn't trivial either; I'm just saying that it isn't as if this was something beyond the measure of a hobbyist. The hardest part, to my mind, would be developing the host driver layer. If you source a decent controller, the "middleman" code practically writes itself.

I can give you more details on this "work" if you like.

Soma

For controlling a robot, a microcontroller is probably more suitable. Unless you want to do very intensive things like computer vision.

You'll need a microcontroller (with an FTDI USB-TTL chip) to interface your laptop to the actuators and sensors anyways.

What do you want the robot to do?

I'm on my second robot (a robot that balances on 2 wheels) and so far all my computing needs can be solved by a $5 microcontroller. For more computationally intensive things (haven't encountered any yet), I would consider using a RF link to offload it to a PC.

I don't think mounting a netbook on the robot itself would give you enough benefit to justify the hassle (the added weight itself means you need higher powered motors, and a bigger battery to support it, as well as better power supply circuitry). And then there's the bigger physical size, meaning bigger robot, more material, etc.

The only downside of using an RF link (if you do need the computing power) is the bandwidth (~25kb/s), but you won't be able to go much higher than that anyways, even with a USB 2.0 link, because you will be limited by the microcontroller's UART speed (~1 megabaud, or about 100kb/s). To go faster you'll probably need dedicated chip, on a FPGA or something, but that will get very expensive (and hard to use).

@Cyber: Sometimes I like the challenge of making stuff out of whats at-hand versus off-the-shelp parts. I have the EEE (1.5 lbs including battery) which is in good shape and a very small form-factor (this is a 701 which everyone complained about being too small. As for what the robot does, I don't know entirely yet but first will be to have it be somewhat autonomous and be able to learn things like the layout of the house, maybe a little speech-driven commands. Beyond that I need to look at things like computer vision...it will evolve over time.

To do all the things you listed, you'll need to have a lot of circuitry on board. At that point, the laptop would be pretty much redundant anyways, especially since you need a microcontroller anyways to interface the laptop to the rest of the circuitry. Might as well just program the microcontroller.

Originally Posted by jeffcobb

I *will* make it work. In truth it is not high-priority for the project I outlined above but it is the principle of the thing. Besides, MP3 players do this all the time

An mp3 player is exactly the same thing as a usb key drive -- in fact, AFAIK there are no specific drivers for mp3 players under linux since you can access them just fine as a drive. But this is a far cry from linking two hubs together.

Ie, an mp3 player is totally dissimilar to another computer's usb port.

and as I may have may have mentioned, Macs can do this (plug one Mac into another via USB and one becomes a slave/drive). Used for backups and such...

As Kennedy hinted earlier, this is done with a special cable, you can watch a video about it here:
Targus For Mac File Share Cable Direct connect adapter - Hi-Speed USB

They do look almost like a normal usb cable, but there are electronics "hidden" in it at one end and software is involved. So you might be able to write a linux driver to interact with this device, but probably that will not be much fun (even: impossible) unless you get some details about how the interface works from Targus.

If you really want to try using a regular cable (ie, something that probably has not been done by anyone with any kind of computer) inquire to the kernel-dev mail list to find out who to contact about the usb hub driver and ask them if this is (even theoretically) possible using the current kernel hub driver (I think it is not, but).

The kernel can load (or autoload) usb drivers based on the device id they show when plugged in (this is what you can find under lsusb). You need to register those with the kernal, eg:

Code:

#define VENDOR 0x0c45
#define PRODUCT 0x612a

If you plug a device in for which there is no known driver, nothing happens. Since a usb hub was not made for a two way relationship, I doubt plugging one into another will show anything (again, if you can find a male male usb cable you can check). There will simply be no communication at all. There will be no vendor and device id show to register anything. And unless you have a device attached to the hub, there is no way to "send" anything thru a specific port (notice, they are not numbered hardware interfaces like serial ports; on a low level, you deal with the hub and not the ports -- this is a 100% hardware relationship managed by the hub, not the OS. The OS's relationship ends at the hub). So you could not "spoof" a vendor/product id from the other end by "choosing" to send some signal thru a specific usb port. The ports do not exist on a software level, only the hub does.


You'd be better off considering the serial ports (or, obviously, the ethernet) for this since I think you will have to write a whole ton of software to represent the filesytem across the interface anyway, and that will be more or less the same. Ie, this is basically a version of NFS.

You could write a kernel driver to create a non-physical device to work with such software (I think that's what NFS does), that is, the "device" will actually be an interface with the ethernet connected software.