USB software host controller

bifferos

I'm interested in opinions on whether it is sensible to use the propeller as a USB host controller.
According to my calculations (bearing in mind I'm a complete propeller noob) the hardware is
capable of sampling a 12MHz bit stream with a few cogs and the right clock speed, so it is also
capable of 'replay' at such a rate. The cog memory seems sufficient to contain a 64-byte
USB packet, so if the transfer modes are restricted it should be possible to talk to
full-speed devices.

I'm just wondering why this hasn't been done (I can only find references to USB devices).
The overall price seems comparable to VNC1L, but with the advantage that you don't need
to use surface mount.

Any thoughts?

regds,
biff.

Mike Green

USB hosting is very complicated. It's not enough to just get the bits in and out, particularly if you want to host mass storage devices where you also want to have the file system support. Commercial USB host devices also have special hardware engines for handling the low level bit stream which the Propeller would lack and this can easily and reliably handle the full rate USB 1.1 transfers where it's complex and difficult to even do that. If you would like to work on it, by all means do so, but the cost of a fully developed and tested (and supported) USB host including a mass storage file system is low enough to not justify the effort for most people. This may all change when the Prop 2 is finished with its higher speed and larger memory, but it will still probably more make sense to use at least a low level USB controller like the MAX3421E.

bifferos

Unfortunately MAX3421E is surface mount, meaning a lot more cost and hassle for someone
like me. It means I must design a PCB, becoming familiar with some CAD package (but which
one?), purchase lots of nasty chemicals, play games with my laser printer to produce aligned
artwork etc... When all this is taken into account, the software implementation doesn't seem
such a bad idea. I think I had in mind partial support for the standard, along the lines of

http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2007/blh36_cdl28_dct23/blh36_cdl28_dct23/index.html

I'm not really interested in USB storage solutions but rather bluetooth at the moment, for
communication with robotics applications. There are a few things working in my favour:

1) No support needed for (un)plugging
2) Endpoints/configs can be enumerated 'offline' perhaps using libusb on a desktop machine - no
need to enum at run-time since I'll know in advance which devices I'll be using.
3) No need for standby/sleep etc..
4) No need for any long cables, the device will be in the same box as the MCU.
5) No hub support needed (you could put extra devices on extra pins)

I think with these limitations, it shouldn't be too tricky, but then, until you've tried something you
never really know I suppose.

OwenS

If you want Bluetooth, why not just buy one of the millions of Bluetooth modules that already exist that don't need to be interfaced by USB?

bifferos

@OwenS: If you can name some that retail for < $10 in one-off quantities (like bluetooth USB adapters),
then I'm all ears.

Mike Green

The cheapest one I've seen is about $50 from SparkFun. It comes ready-to-go as a serial link replacement. As an educational effort with no promise of success, it's hard to argue with an attempt to make it work with a Propeller if you've got the time, expertise, and interest. As a practical suggestion for a wireless link, $20 to pay over and above the cost of one-off hardware (Bluetooth dongle plus Propeller Protoboard) is pretty reasonable. (I'm assuming that the Bluetooth support will use much of the capability of a Propeller to implement. If not, $40 is still reasonable for the development cost)

LoopyByteloose

As of two days ago, I just hacked into a USB game controller because I suspected that it is among the most simple of the USB devices to hack. I took it apart in order to consider modifying it to use shift registers, but it became obvious that wasn't possilbe. So I noted the wires and their markings.

There are 4 wires - +5, GND, D+, and D-. I realized that the D+ and D- looked very familiar. So I am thinking of next connecting an RS-485 driver to the D+ and D- and decoding what is actually going on. A scope would come in handy. It may be a lot simpler than the documentation leads one to believe. USB device send packets that either identify the device, pass information, or perform a third [noparse][[/noparse]forgotten] function. Since the Game Controll has no need of dialogue, I suspect it just initializes a listen and wait mode in the USB host.

If the TTL from the RS-485 can be managed directly by the Propeller, we would all benefit from a very handy user interface. I don't expect a full blown USB support. But I do feel there are possiblities of one individual 'low level' devices working very well on a case-by-case basis.

Of course, I am assuming this a simplex device, not a half-duplex.· That may be my downfall.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:

Do you want a quickly operational black box solution or the knowledge included therein?······

···················· Tropically,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Post Edited (Kramer) : 3/28/2008 6:37:58 PM GMT

bifferos

@Kramer: You've given me an idea: Forget about building a USB host controller - first build a sniffer. There must surely be high-speed 'logic analyser style' capture code already knocking about. Fortunately I can now borrow a real USB sniffer, so that should help.

Nice idea about using RS485 to get ttl levels since it means not needing to sample two signals, but I wonder if rs485 silicon will operate at 12MHz? Also, don't forget that both lines go low to signal certain conditions (possibly ones you can ignore for your application), so you need more than just a simple push-pull driver.

Personally I'm less interested in the low speed devices since that's already been done with an AVR (see my link), but I guess you might be interested to port that code to propeller to access your controller. They have it working with a mouse at least.

stevenmess2004

There is some code here http://forums.parallax.com/showthread.php?p=675656 and some other comments here propeller.wikispaces.com/USB+Slave about using the propeller as a slave usb device.

OwenS

Kramer: An RS485 device might not be able to sense the 400mV differential used on USB, and may not function at 12Mhz. Also, low speed devices use a completely different signaling system.

EDIT: Oh, sorry. Thats high speed mode I'm looking at

LoopyByteloose

Okay, but can't one setup of a few good op-amps to sort out the 12mhz signal in a fashion similar to an RS-485 transceiver?

I suspect pursuing 12mhz transfers from the start is a bit hairy. Can't one start with slower speed devices? The game controller is extremely central to a lot of Propeller applications. So, finding a way to support it first would be a stepping stone along the way.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:

Do you want a quickly operational black box solution or the knowledge included therein?······

···················· Tropically,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

OwenS

You could, although I imagine it would take a lot of perusing of the USB specification. And, your not going to be able to talk to hubs. Or call yourself USB compliant, since compliance requires at least full speed support.

You must also remember that there are three types of transfers, Bulk, In/Out, and Isochronous (Two for low speed devices, which don't support bulk). And remember that Isochronous has tight requirements.

It would be far, far easier to just use a MAX3421E. And easier than that to use something like a Vinculum or USBWiz

bifferos

@Kramer: I wouldn't go anywhere near the official USB standard if you are interested in implementing this, but rather, use the AVR code and combine it with the Beyond Logic site, starting somewhere around here: http://www.beyondlogic.org/usbnutshell/usb2.htm#DataSignallingRate. Use this in combination with something sniffing your USB controller packets, like usb snoop (http://sourceforge.net/projects/usbsnoop/). You can do this if the controller can be made to work with Windows. Sometimes just seeing what goes back and forth can be enough to figure out what you have to do to 'fake' the controller behaviour.

I'm not saying it'll be a 5 minute job, of course....

OwenS

If you insist on implementing USB in software with the Prop, I suggest you at least use a 6Mhz input clock. Running at 96Mhz, a multiple of the USB data rate, would make things easier