"Emulate" USB Host

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:41B77778.9AB9A875@yahoo.com...
> Some years ago I built an extremely cheap peripheral.  It's only
> duty was to read a memory dump from a (nuclear) pulse height
> analyzer, which in turn was in a peculiar ad-hoc format which
> sufficed to dump and reload the PHA.  The physical interface
> consisted of the same miniature tape deck as was mounted in the
> PHA, and a single CMOS buffer chip, all hung off the parallel port.
> x86 timed loops did the clock/data separation, detected end of
> record gaps, etc., and allowed the memory dumps to be transferred
> to the PC and displayed and/or analyzed.  It was profitable because
> it cost almost NIL to manufacture, and the design effort was in the
> software.
>
> I am sure I was not alone in doing these things.  None of this
> would be possible with a USB interface.

Funny enough, the FTDI FT2232C chip is exactly designed to do this. Besides
the standard asynchronous protocol, it can also do synchronous protocols,
specially targeted to ISP and JTAG stuff.

Meindert

> I need to implement a USB host controller for an embedded system
> running VxWorks on a Xilinx Virtex II pro FPGA. Can anyone here
> recommend a good choice for the external host USB chip? (IP cores were
> too $$$) and software drivers that will run it? (I'll be connected
> various devices--HIDs, mass storage, video, etc on the bus).

> Regards,
>
> Bo


Does the Virtex contains a PowerPC?
Then the AT43USB380 might be what you want.
Will support Mass Storage and HID at least.
Don't know about Video.
The advantage of the AT43USB380 is that the Host S/W is simplified a lot.
The Host Stack is running on the chip, and the Virtex runs the Profiles.
Atmel delivers precompiled libraries for certain cores.
If it is not a Power PC, then further discussion is needed.

-- 
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.

> I'm not.  That would make even less sense than a keyboard attached to
> the same wire as a 320 GB external USB 2.0 hard disk.
>
> > And I'm not sure why you brought up 1394 at all.
>
> Because USB devices fall into several large categories:
>
> 1) replacement of former "legacy" ports (keyboard, mouse, printer, modem,
...)
> 2) high-bandwidth devices (nowadays usually USB-2.0 hi-speed), like
>    external harddisks and video stuff.
> 3) stupid stuff, including USB-to-USB "network cables".
>
> My point, is that 1) and 2) don't have any business travelling over
> the same pair of wires, and for 2), defining a new protocol was
> completely superfluous already when USB was originally designed ---
> 1394 filled that niche nicely, at higher bandwidth, with less hassle.

There are "political" issues here. P.1394 contains IP owned by Apple.
Intel was not exactly interested in promoting that, so they defined USB.
You may or may not like this, but I think Intel won.

I dont recall ever using my P.1394 mainly because no home electronics seems
to use it.
If my DVD Video provided P.1394 output from the TV Tuner, I would use it.
Don't own a DV camera which seems to be the only reason to use it at this
time.
I rather have multiple ports of of the same kind, than one or two of each,
since this gives me more flexibility.

Since I need USB ports for the Mouse, that means USB for everything.
I could get a P.1394 hard disk, but that would limit my options, and I don't
really
care too much about the speed on that one. With USB I can connect to more of
*my* home
equipment

-- 
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.

> I need to implement a USB host controller for an embedded system
> running VxWorks on a Xilinx Virtex II pro FPGA. Can anyone here
> recommend a good choice for the external host USB chip? (IP cores were
> too $$$) and software drivers that will run it? (I'll be connected
> various devices--HIDs, mass storage, video, etc on the bus).

If you need HS operation, and don't have a PCI local bus, check Philips 
parts:

onTheGo: 
http://www.semiconductors.com/markets/connectivity/wired/usb/products/otg/isp1761/
host only: 
http://www.semiconductors.com/markets/connectivity/wired/usb/products/host/isp1760/

Unfortunately, FlexStack source costs about $50K.
There's a PCI board with 1761, with a evaluation software for Linux. I do 
not know if it comes with source for Linux, also.
Availability could be an issue for both, also (I suppose)...

They have also many full speed hosts.

"Hans-Bernhard Broeker" <broeker@physik.rwth-aachen.de> wrote in message news:31ov16F3du2iuU1@news.dfncis.de...

> 1) replacement of former "legacy" ports (keyboard, mouse, printer, modem, ...)
> 2) high-bandwidth devices (nowadays usually USB-2.0 hi-speed), like
>    external harddisks and video stuff.
> 3) stupid stuff, including USB-to-USB "network cables".
>
> My point, is that 1) and 2) don't have any business travelling over
> the same pair of wires, and for 2), defining a new protocol was
> completely superfluous already when USB was originally designed ---
> 1394 filled that niche nicely, at higher bandwidth, with less hassle.

I get the impression that USB was originally designed to work like ADB
on Macs - i.e. for 1). The HID stuff is pretty neat, you can use a tool to
generate the HID class descriptor, and burn it into the Rom of a low cost
microcontroller with a low speed USB transceiver. Sure the driver on the
PC is probably a nightmare internally, but that only needs to be done once
per OS.

>
> If they had designed a new bus for category 1), and 1) alone, that'd
> have been perfectly fine with me.  But by forcing category 2) into the
> same channel, without compelling need of doing so, they crossed the
> line.
>
> One difference that makes me criticize USB is that its
> self-configuration mechanism is *way* over-complicated.  It's this
> mechanism, mainly, that causes the need for a PC at the root of the
> tree.  1394 auto-configuration is so simple that a digical camcorder's
> firmware can usually get it right without breaking a sweat.

Yeah, but the complication is on the host side, not on the device. The
device needs to be able to handle IIRC

Get Device Descriptor - fetch n bytes from Rom
Set Address - write a byte to a USB control reg
Set Configuration - the device probably only has one config, so it's a NOP.
You could light a led or something though, since it means that you are recognised
by the host.

plus read/write from/to whatever endpoints it needs for it's internal stuff.

Handling string descriptors would be nice, but you don't need it.

If you have a microcontroller with built in USB, all this is fairly painless -it's
easy to get it into a small rom.

>
> USB-2.0: yes.  USB-1.1 was too slow by almost a factor of 10.  Hard
> disks have been faster than 1.5 MB/s continuous transfer rate for a
> *long* time now.

USB key fobs are useful even with USB 1.0 actually, you can just leave stuff
copying while you do something else. But you're right that USB 1.0 isn't
exactly ideal for this sort of thing.

>
> -- 
> Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
> Even if all the snow were burnt, ashes would remain.