how would i go about transferring data via a usb to usb cable, basicly a direct link to that pc. do i have to use i/o ports and kmd's or is there some api for that in windows xp/2k/nt i have here?
Posted on 2004-03-18 20:57:04 by Qages
USB is designed such that there can not be two masters on the serial network. Its physically designed with one end that only connects to the master, and the other to slave devices. As such, you can not link two PC's together in the first place.

But to answer your question, if you could, you would need to get down and dirty with WDM's and KMD's.

Regards,
NaN
Posted on 2004-03-18 22:26:59 by NaN

As such, you can not link two PC's together in the first place.


...

http://www.google.com/search?ie=UTF-8&oe=UTF-8&q=usb+pc%2Dto%2Dpc
seems to have a form of "adapter" on the cable. I wouldn't recommend using a standard cable to connect to computers, I heard some rumours about fried motherboards.
Posted on 2004-03-19 07:41:47 by f0dder
then i have no other way to transferr data between my two laptops.
Posted on 2004-03-19 12:56:51 by Qages
Qages, one of those pc-to-pc USB cables should work, at least with WinXP I think?
Posted on 2004-03-19 13:22:15 by f0dder
k, i had got the impression that it would fry my mobo.
Posted on 2004-03-19 14:26:51 by Qages
I stand by my comments. The devices on these web pages appear to have two slave devices working together to buffer and bridge information. As such each computer sees a single slave device. In concept i see no worries with it. Quages, if you need something like this then buy it. But directly connecting two PCs via a single USB cable can not be done.

USB works by time slicing. The master device (the CPU) gives evey slave device a fagment of its time and asks it needs to do any communications, if so it schedules it in and tells the slave when its ready for it transfer (either way). So hopefully now you can see why two CPUs wont work directly andy why the cords have been designed to avoid this. There can only be one master scheduler on any USB network.

The producs f0dder dug up basically transfer info in two stages: USB network 1 from PC 1 to the slave device in the cord buffers data transfered. Then on USB network 2 from PC 2 to the save device uploads data from the buffer to the PC 2. There is no fear of electrical damage here, as part of the USB spec ensures that the first connection made electrically is the ground pin, and it is also the last connection to break upon removing a usb plug.

Regards,
:NaN:
Posted on 2004-03-19 16:34:23 by NaN
ok say i have one of these, how would i transferr data to it?
Posted on 2004-03-19 17:41:33 by Qages
Either built-in windows support (winxp?), or drivers with the cable, I guess. One of the product sites mentioned TCP/IP across the cable :)
Posted on 2004-03-19 17:43:51 by f0dder
PCs don't use USB OTG (on-the-go) which allows two USB devices to talk to each other over a plain cable. A mini-USB connector is used to prevent PCs from talking to each other (and frying motherboards.) I haven't checked too carefully to see if OTG is finalized or not.

Standard USB is a master-slave system, where the master sends commands to the slave to begin any data transfer. The masters (PCs) will not respond like slaves, so it's impossible to communicate between two PCs with a straight USB cable.
Posted on 2004-03-20 01:10:54 by tenkey
I have a USB data transfer cable. It uses a USB connector on both ends to connect to both PCs.

It is supposed to be able to be set up as a network device, but I have not got it working as such. Instead I use the PC-Linq software it comes with. Must be installed on both machines.

IIRC USB to USB gives a transfer rate of about 6Mb/s = .75MB/s

On the other hand, you can use a crossover Network cable between the two machines, set up your network (no new software to install IIRC), set shared directories, etc, and once the machines are connected you can transfer files at 100Mb/s, which is 16 times as fast. In addition, if you share a CD (possbly DVD as well) you can install software on the networked machine over the Network cable.

Of course, you can also install a conventional network.
Posted on 2004-03-21 23:20:53 by V Coder
Does your pc<->pc usb cable have any form of adapter on it, or is it a plain cable?

As for data rate... if this also works on USB2, it should be a "wee bit faster". Iirc USB2 is 480mbit/s, or 60MB/s. Of course there's protocol overhead etc., but I suppose you should still be able to make it go "somewhat faster" than a conventional 100mbit network? :p
Posted on 2004-03-22 03:17:09 by f0dder
Yes, as far as I know, USB 2.0 data transfer cables exist. I suppose at top speed it is just a bit slower than the fastest hard drive... Signalling etc nonetheless, it should be pretty fast.

The USB data transfer cable consists of a "device" just over 1 square inch with two USB cables and connectors: one at either end to connect to the two machines.

You can get a look at it following the link from www.lpt.com - it is http://www.lpt.com/Shop/shop.asp#NetLinQ

Or look at http://www.ebusinesscables.com/USB_Data_Transfer_cable.htm

Also, do a google search on
usb "data transfer cable"
Posted on 2004-03-22 17:36:39 by V Coder
I did a similar google (usb pc-to-pc), and looked briefly at both usbgear.com and lpt.com - and saw the small device on the cable. Just wondered whether yours was a "plain" cable and if that would work - I saw some pretty funky error messages in WinXP when a friend tried to connect his laptop to his mainbox with a plain cable ;)

Do you know whether your cable would support USB2 rates, or if the device on the cable can only handle USB1 rates? I might be interested in a USB2 pc2pc cable, since I have massive data transfers going on in my home LAN sometimes, and such a cable should be cheaper than a couple of gigabit NICs etc ;)
Posted on 2004-03-22 17:43:52 by f0dder
This old DOS program "Laplink" was designed to do exactly what you request. That is xfer files from one computer to another. I hope there is not a reason you prefer USB port other than speed. There should be a copy around somewhere. I might even have one myself on some old 5 and a quarter diskettes.
Posted on 2004-03-22 18:11:12 by mrgone
Laplink? eeek, that means serial or parallel transfer == pretty damn slow. You wouldn't want to use that to transfer a few++ gigabytes, would you? :P

There's other reasons than just speed to prefer USB. The connectors are nicer & smaller than serial/parallel, and faster to plug/unplug. The cables are smaller, both thinner and because of the smaller connection.

And furthermore, because it's a serial connection, I would assume you can have longer cables without transmit errors and thus decreasing speed?
Posted on 2004-03-22 18:18:30 by f0dder
My cable is just USB 1.1. However, I'm sure I've seen a USB 2.0 cable... I think...?
Posted on 2004-03-22 20:09:48 by V Coder
My gut feel is while the USB2 spec is designed for fast data transfers, the 'device' that buffers and forwards from one network to the other would be the real source of bottle necking. They look like they are designed small, so you probably dont have alot of on-board ram. While you can get very fast ram, you also need more buffer space to store info from one nextwork while waiting for the master on the other network to get back to you. (Remember the USB network is time sliced between all its devices, and neither network will be synchronized with each other).

My gut feel is these devices simply work in a push-pull fashion where it fills its rams by ordering a chunk of memory from the CPU usb network. Waits for it to arrive and fills memory. Checks the checksums, then issues a transmittal to the the CPU 2 usb network. Waits for its 'ok' to begin and sends it off. Then it goes back again, and does it all over.

The fact neither network can be synchronized, and that the buffer adds an extra stage in the transfer really diminishes the USB top speed to less than 50% (two stage push-pull itself will half the max speed, the non-synchronized waits will continue to diminish it further).

Of course this is just my 'gut feel'... i could be totaly on cRaCk ;)

:alright:
NaN
Posted on 2004-03-22 21:04:43 by NaN
I don't think you'll need a lot of ram. Things like ethernet packets are, iirc, 1518bytes max (1500 bytes of payload). So with, say, half a meg of ram you could have enough storage for a whole bunch of ethernet packets. I'm not sure if that's the format used by these devices, so it's just for comparison. It's also worth noting that this packetsize is used on 10,100,1000,10000mbit ethernet - both 1000 and 10000 are "somewhat more" than the 480mbit of usb2 :p (gbit and 10gbit ethernet has something called 'jumbo frames' though, to improve efficiency - I don't know what's most normal to see on a gbit ethernet though, jumbo or normal packets.)

I assume that USB devices can trigger an interrupt to the USB controller, and that this will generate an interrupt on the PC? This should make the system work pretty well (assuming you don't have a lot of active hi-speed USB devices at once, but that's not a very common scenario these days I think). Don't tell me that USB is built around polling :p
Posted on 2004-03-23 03:27:48 by f0dder
USB is actually pretty slow because of the limits on packet size. And because the host (PC) controller has to do most of the work. The raw bit rate is 1.5 Mbps for low speed, and 12 Mbps for full speed.

Using a full speed 12 Mbps connection, you have max 64 byte packets for a lossless transfer, and max 1023 byte packets for lossy (no retry) transfer.

USB 2 in high speed (480 Mbps) mode allows larger packet sizes.

In USB 1, data transfers must be packed to fit into 1 ms time frames. Like disk sectors, the packets are separated by gaps, and start with sync patterns.



f0dder,

Hate to tell you this, but USB is indeed built around polling, or more precisely, by pinging. The pinging is done automatically by the USB host controller. Retries are automatic. The host controller can then raise an interrupt when it has successfully transferred data.

USB devices don't initiate data transfers. Data is sent to a device by sending an OUT token (packet) followed by the data. Data is retrieved from a device by sending an IN token, and then waiting (for a very short period) for the device to start sending data. Success is signalled by an ACK token from the data receiver.

The only preemptive action a device can make is the remote wakeup. In all other cases, the device is a slave to the master host controller, sending signals to the master only when asked.
Posted on 2004-03-24 03:18:09 by tenkey