USB host to device "passthrough"
This is more of a theoretical question than a "how do I" one. Depending on the answers then I may post further or decide I just dont have the know how, lol.
If I buy a Mini2440v2 development board (Arm920) that has both USB host and USB device ports, is it possible to "passthrough" devices plugged into the host port to the device port?
My reasoning is... If I build a device using this board and a usb touchscreen plugged into the host port and then plug the resulting device into a PC via the device port (PC is now host to my device) I'd like to allow the touchscreen to be seen by the pc, as well as any internal storage and/or any usb drives or other devices plugged into my device.
MYDevice ARM board (Contains/is linked to...)
USB external disk
Internal Flash drive
External USB Keyboard.
When MYDevice is plugged into the PC, the PC should be able to see and access/use all the bits as if they were directly plugged into the PC's USB.
Having searched the web, this is not something like USB OTG or Host/device switching... instead its more about faking the USB return devices. As MyDevice will always be a client to the PC, yet on its own a host to the other devices.
I believe what you want to learn about is the USB Gadget API. A Google search yields numerous good starting references.
After looking I think it is do-able and quite simple in concept, if not the actual code.
Now all I have to do is learn C and update my knowledge from years ago, before i went into as/400 application programming.
I'm guessing the other parts I need to study are USBCORE for the host side, and a few device drivers to see how it all hangs together.
@JW, did you get this working? I am looking at doing a similar USB passthrough with our ARM embedded system.
Sadly my knowledge of C was not up to this in the end.
However what I did manage was a little bit more of "if it could it would do it this way" overview.
The documentation (down the page a bit) shows how usb over ip works.
What I would have done is when my device (server) was plugged into the pc the pc would load the usbdriver for my device, this would be exactly the same as the usb-ip VCHI except instead of usb over ip, it would be usb over usb.
1) Where something in my device was connected via usb, it would work exactly as shown in the usb-ip diagram creating a stub driver. eg. a usb keyboard plugged into my device.
2) Where something was not connected via usb, eg. a hard drive or a virtual keyboard on the screen, it would create a _fake_ stub driver of an already known usb device and would then translate the usb requests to the real (hard drive) or virtual (keyboard) device.
For item 2, I'm not sure how much work would be involved as I'm a little unsure how usb works at this point... my guestimate is that its no more than an end to end wrapper over the underlying hardwares native data/control types, the thinking behind this guess is because a usb hard drive can have a different hard drive (size/make) connected and it still works so there must be an abstraction between the usb type/make and the underlying physical hardware type. (a)
eg. diskrequest-seek>wrapped usbSoftwareControl>PhysicalUsb>----wire---->PhysicalUsb>un-rapped usbHardwareControl>diskrequest-seek>physicalHD
If the above is true, then the fake stub would strip away the usb controlling data (request) to get at the raw device command, and then send that command to the devices hardware stack, get the resulting data, wrap it back into usb control data (result) and then send it over the usb.
I did also think about this a little further... when an item of hardware in the server (mydevice) was in passthrough mode it may also be needed exclusively for that device at times. If the mydevice was a notepad with a screen, and a virtual keyboard, there might be times when the keyboard was needed for the notepad itself, say the notepad was running an email client, when a new mail message pops up hitting a special combination of keys on the virtual keyboard would cause the keyboard to no longer send data via the stub driver, the driver would however stay active and connected to the vhci, it would still receive the key presses it would just not send them on... another special combination of keys would then cause the driver to once again send data to the pc.
(a) this abstraction is not however complete, a usb harddrive does not return a controler type (ie sata) it returns a device type (hd) if you plug in a CD drive into a usb harddrive (by opening it and taking out the tiny PCB and connecting that to the cd player + power cord) it does not work as HD commands, not CD commands are sent... that said I see no reason why the writer of the usb driver could not have written a slightly more abstract driver that would first query the device attached to the usb, then initiate the correct device in the usb/device interface such as "this is a hd" or "this is a XX type cd/dvd drive"
|All times are GMT -5. The time now is 01:33 AM.|