[Robotgroup] USB host uC
Glenn Currie
kd5mfw at texas.net
Sat Jun 2 10:48:07 PDT 2007
It is a bit more work than might be apparent to "roll your own" USB
projects.
Part of the motivation for the development of USB was that PCs have had
a history of
having a limited number of interrupts available to support all the
devices we might want
to use. You can use polling, where the driver spins in a loop looking
for I/O for a particular
device, but this is extremely inefficient since most of the time, the
peripheral has nothing
for the processor. With interrupt routines, a peripheral only needs to
ask for processor attention
when it is ready to pass data.
On older PCs, every serial, parallel, joystick, etc. required an
interrupt to service it. Before
Plug and Play, you had to set jumpers on the peripheral board so that it
would show up
on the desired CPU interrupt line. The number of devices users wanted
to use quickly
used up the 12 -14 interrupt lines. The next step was to make a bigger
mess and
"stack interrupts", that is to daisy chain several peripherals on the
same interrupt,
and let the interrupt handler code check to see which board was actually
requesting
service. This is essentially another form of polling.
The idea for USB has been around for quite a while, and the software is
getting better,
but can still have problems due to it's complexity.
Hardware wise, USB is just 4 wires, Data in, Data out, +5VDC, 5 VDC
return / ground.
The software gets pretty complicated very quickly.
One reason for this is the requirement that devices be "hot pluggable".
This is much harder
that it might seem. To support hot plugging, you must have software
running in the host
that knows what to do when a USB peripheral is plugged in. So you have
to have a sort of
master USB driver running, all the time on the host. When a USB device
is plugged in,
this is sensed and the host driver and the newly found peripheral go
through a dance called
"enumeration", in which they pass a significant amount of data to
negotiate the the connection.
The peripheral must, among other things, present a unique vendor id to
the host. The host USB
driver must then find the specific driver needed to support that
particular device. If the driver
is not found (maybe not loaded by the user yet off a driver CD provided
by the manufacturer),
the device does not get tied into the host system. If the correct
driver is found, then the host
master USB driver must load the product specific driver allocate memory
for I/O buffers etc.
The USB peripheral will indicate to the host, how much bandwidth it
wants. The host will
then check resources and see if the requested data rate can be
provided. If it can, then
the master driver will continue in the enumeration process. If for any
reason
(most likely other USB devices are already attached to the host) the
host will not be able
to provide the bandwidth requested by the peripheral enumeration fails.
If the peripheral wants to try again
it can ask for a lower bandwidth connection and see if the host can
provide it. This process be tried
over and over again until either the requested bandwidth can be
supported by the host
or enumeration fails.
If the peripheral cannot get the minimum bandwidth needed it will fail
to enumerate and
will not be tied into the host. For example, some USB video cameras
need a certain data
rate to send data or the device simply will not work in an acceptable
manner - frame rate
too slow.
If the bandwidth needed can be supplied, then the host must keep track
of the power
the peripheral is drawing. By the spec, you can have 5 volts DC at
about 500 ma. max.
per peripheral.
If you draw more current the host is obligated to shut down the peripheral.
A USB hub function is what keeps track of the current being drawn, along
with a many other things.
If you plug in peripherals with differing power and data bandwidth
requirements, the order
you plug them is important, as the root hub in the PC will provide
resources on a first come
first served basis. When the host hub is maxed out, no more devices
will be allowed to
enumerate on that hub. This is why most PCs now have multiple root hubs.
You can plug in an external USB hub to the root hub. This can provide
more connectivity
for devices, but the overall current and bandwidth is not increased -
and the external hub
and the root hub in the PC must maintain another level of information in
the driver, to keep
the addressing straight, inserting a hub complicates the addressing scheme.
So it takes a lot of software on the host end to support USB devices,
and you still need
the code to support a peripheral. The host USB software needs to be
able to cope with any sort
of USB device that is plugged in.
Microsoft has take years to fix a number of fundamental bugs in the
master USB driver code.
This is not much different that all the bugs in the .dll files used in
windows. Manufacturers
have created their own .dll files needed to make their hardware work,
and mixed these in
with the countless .dll files on a windows system. This created a
situation sometimes
called "DLL Hell". When adding a new device, a .dll substitution might
get the new device
working, but "break" existing peripherals on your system.
At least with Linux you can get the source code for the host end and
work through it, if you
have problems. This is a "nontrivial" task.
Depending on what you want to interface to USB, there are some
reasonably workable
solutions on the market. Silicon Labs sells a USB to serial development
kit for about
$30.00 through DigiKey. They supply the windows driver. This gets you
plugged into
windows, and then you have to write application code to do what you want
with the
serial port.
If you want are interest USB host, consider the Linksys WRTSL54GS. It
runs Linux
the source code is available and it supports connection to USB disk
drives. I have
used this device and it is a slick product. It sells for about $89.00
at Frys.
Check out the Open-wrt firmware for the WRT54GS. It is quite nice.
With the Linux source code in had you can also down load the GNU tool chain
(cross compiler) and recompile the code. This is a nontrivial task, but
it is possible.
The USB 1.1 and USB 2.0 specs are several pounds of reading, if you get
the printed
version on dead trees.
Good luck, and try to remember what it was you wanted to do with the USB
connection,
once you get it working - easy to get lost.
Cheers,
-Glenn
Gray Mack wrote:
> I think the only reply to that question came from you.
> Seems like the issue is not only would the chip be fast enough to talk USB, but it also has to do processing on the data and driver work. There are a few standard interfaces like thumbdrives and mice, but most are more custom requiring a windows driver (linux option if you are lucky) built for the specific product. It's a shame that USB technology has us kind of locked down right now.
>
> There continue to be advances in small products that are powerful enough to run linux and are around $100 or less. Things like the Linksys nslu2 (aka the 'slug') which was made to interface usb drives and present them as a network file storage for about $80 (see http://www.nslu2-linux.org/ ) have been demonstrated to interface to harddrives, printers, webcams, bluetooth, audio devices, etc with some linux know how and work. The device without accesories probably pulls about 500mA and is 5.12" x 0.81" x 3.56" and can be overclocked beyond its 133mhz so it is an option for robotics. I have not yet used mine beyond its intended purpose.
> -Gray
>
>
> ----- Original Message ----
> From: Robo Al <sp-18561884 at ggsys.net>
> To: Austin Robotgroup Mailing List <robotgroup at puremagic.com>
> Sent: Friday, June 1, 2007 12:24:00 AM
> Subject: [Robotgroup] USB host uC
>
>
> This is probably a question just for Gray, but
> did anyone ever find a uC that can behave as a
> USB host?
>
> Otherwise I guess USB OTG will be the next best
> thing if enough devices implement it.
>
> Alberto
>
> _______________________________________________
> Robotgroup mailing list
> Robotgroup at puremagic.com
> http://lists.puremagic.com/cgi-bin/mailman/listinfo/robotgroup
>
>
>
> ____________________________________________________________________________________
> Food fight? Enjoy some healthy debate
> in the Yahoo! Answers Food & Drink Q&A.
> http://answers.yahoo.com/dir/?link=list&sid=396545367
> _______________________________________________
> Robotgroup mailing list
> Robotgroup at puremagic.com
> http://lists.puremagic.com/cgi-bin/mailman/listinfo/robotgroup
>
>
>
>
More information about the Robotgroup
mailing list