views:

237

answers:

3

I have a need to write an client-server application where a tiny server rests on a USB gadget and communicates with a client application on the host.

I've not done this sort of thing before but I have done webapps and usually, they're all developed and debugged on the local machine using the lo loopback network interface. This has perhaps influenced my way of thinking and I'm looking for a way to simulate a USB host and gadget on my machine so that I can build both ends of the application completely on my PC before I dive into the actual gadget and get the thing going.

Is this the right way to go about it? I realise that the USB protocol is asymmetrical and found some references to this over here but it seems to most natural way to go about it.

If it is the right way, how do I start off with something like this and are there any potential problems that others are aware of which I might stumble over?

Update

References which I found from Googling earlier. There are Linux Kernel modules (part of my Ubuntu Install too) which seem to be able to simulate the host and gadget sides (viz. dummy_hcd and gadgetfs respectively). My idea is to simply have something like

Host application (client) on PC <-> device file 0 <-> Loopback device <-> device file 1 <-> Gadget application (server) also on PC (will be moved to gadget).
+5  A: 

Don't over-think it.

You don't need to fancy "loopback" device.

You're right about simulating the USB host. You don't need to create a fancy USB loopback device or any silliness like that.

  1. Design your client.

  2. Design a "generic" USB interface layer that would simply passes requests to a real USB device driver. Don't code this yet.

  3. Code a USB interface layer that mocks the host instead of using the real USB device. This has the same interface as your generic USB interface. It's a proper subclass. However, it doesn't actually use the USB device driver. Instead it acts like it's the web server on the USB device.

    Clearly, it's not a complete simulation. It's just enough for you to test your client. Each key feature that the client must interact with is represented with enough canned responses that you're sure the client works.

  4. When your client works, code the real USB interface layer that really passes requests from client to device. This is that you'll use in production and to do integration tests with the real USB device.

Your client software now has two configurations -- all handled in software:

  • The real driver -- for production.

  • The mock driver -- for unit testing.

It shouldn't be any more complex than this. And, you can now unit test your entire client using your mock host.

S.Lott
Can you elaborate on step 3 and later? I'm not quite sure I understand.
Noufal Ibrahim
+1  A: 

While what you are looking for is technically possible, I would say that it is difficult to implement, since it involves the creation of a USB driver that will emulate a real USB device.

There are a couple of alternatives I can recommend. First, you can choose to use a virtual COM port to communicate over USB. The host software can be developed and tested with a simple serial interface. Another solution is to first create the business logic part, test it with a software simulator and then move to the hardware part.

Finally, if you don't know it already, have a look at the libusb library.

kgiannakakis
There are already kernel modules to do the simulation. I think the heavy lifting has been done and I can concentrate on the client and server applications. I've updated the question reflecting my findings.
Noufal Ibrahim
A: 

I'd suggest you make the device look like a common usb network adaptor. Then server is then web server and users don't need to install software. doing the testing on your PC is then exactyl the same as you've done before.

OR make it look like a USB serial device, and put a SLIP link over it (that's easy)

If you really have to have a weird protocol, grab a USB developer kit like one of the microchip USB PIC kits. The target system is then programmed and run from your host PC.

Tim Williscroft
The problem with the network adapter is that the device on which I'm going to finally put the application doesn't have networking support and I don't want to add it just for testing. The USB Serial device suggestion is something interesting. Thanks
Noufal Ibrahim