"Emulate" USB Host

Hi there,

I'm quite sure it's not possible but still I'll ask.  :-)

If I'm only interrested connecting an USB keyboard to my embedded
unit, could I in some way emulate the host controller with two generic
I/O pins and some firmware?

Will there be speed problems? (if the protocol is asyncronuos)

No hubs or other stuff will ne nessesary to support. Just the keyboard
class (HID??)

Thanx

Yxan <yxan@mail.com> wrote:

> If I'm only interrested connecting an USB keyboard to my embedded
> unit, could I in some way emulate the host controller with two generic
> I/O pins and some firmware?

At the least, you'ld need some additional transceiver hardware, I think.
The data lines on USB aren't exactly 5V TTL compatible, IIRC.

Other than that, sure, it's possible to do that.  Hypothetically.
After all, the dedicated USB host controller are managing to do it,
and whatever it is they do, it can quite certainly be described as "a
couple pins and some firmware" (using some poetic license for the
upper protocol layers, which aren't handled by the host controller)

But you almost certainly don't want to do that.  Trying to bit-bang a
protocol at 11 Mb/s is going to be well beyond tricky.

And that's before you even start working on the higher levels of the
protocol stack.

You're trying to do exactly what an entire division of a major company
explicitly was told to go out of their to make hard for you do to.
And guess what, they did it --- it's friggin' hard.

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

On 7 Dec 2004 14:47:33 GMT, Hans-Bernhard Broeker wrote:

> You're trying to do exactly what an entire division of a major company
> explicitly was told to go out of their to make hard for you do to.
> And guess what, they did it --- it's friggin' hard.

Could you elaborate on this a bit? I would like to boycott whoever it was
that invented this spec from hell.

Bob

On 7 Dec 2004 06:31:18 -0800, yxan@mail.com (Yxan) wrote:

>Hi there,
>
>I'm quite sure it's not possible but still I'll ask.  :-)
>
>If I'm only interrested connecting an USB keyboard to my embedded
>unit, could I in some way emulate the host controller with two generic
>I/O pins and some firmware?
>
>Will there be speed problems? (if the protocol is asyncronuos)
>
>No hubs or other stuff will ne nessesary to support. Just the keyboard
>class (HID??)

I don't want to say it's impossible, but it would be a _huge_ task.
You still have to enumerate the device, and support a 1.5 MHz
asynchronous serial interface.  If you want to support HID, you'll
have to parse the configuration packet coming back from the keyboard
during enumeration to decode the received data (unless you intend to
support only one particular keyboard).

USB is designed to offload complexity from peripherals (like
keyboards) to the host.  ISTR someone putting together some code to
bit-bang a USB peripheral (perhaps a keyboard, but probably a custom
peripheral) but I've never seen anyone try it with a host.

It would be many orders of magnitude simpler to support a standard
PS/2 keyboard. You can probably even find code samples on the net that
do 99% of the job for you.

Disclaimer: I haven't done anything with USB OTG (On The Go), which
may make things somewhat simpler (but I doubt it).

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Bob Stephens <stephensyomamadigital@earthlink.net> wrote:
> On 7 Dec 2004 14:47:33 GMT, Hans-Bernhard Broeker wrote:

> > You're trying to do exactly what an entire division of a major company
> > explicitly was told to go out of their to make hard for you do to.
> > And guess what, they did it --- it's friggin' hard.

> Could you elaborate on this a bit? I would like to boycott whoever it was
> that invented this spec from hell.

Unless I misremember badly, it's Intel.  Which makes boycotting them
rather harder than one might like.

I've said this before, but I'll say this again: the only assumption
about motives that can really explain why USB was designed the way it
was designed, given existing technology at the time (particularly IEEE
1394, a.k.a. Firewire), is that it was predominantly a marketing
scheme to be able to keep selling powerful personal computers.  It was
a strategic move against the replacement of PCs by pervasive
computing.

As a side effect, it will sooner or later kill off the ordinary PCs'
usability for applications typical to this very newsgroup.  I suspect
there are entire "computer stores" already without a single serial or
parallel port to be found on the premises --- well, possibly excepting
the debug ports of the cash register and soda vending machine.

To put it bluntly: there was *nothing* wrong with the PC keyboard
interface that it would have taken something like USB to fix.  There
were some extensibility issues with mouse protocols (not with the port
itself, mind you!), granted, but even for those, USB is serious
overkill.  I don't see any plausible reason a human interface device
controlled by a person's hand could possibly need a 11 Mb/s data link
to the computer.

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

On Tue, 07 Dec 2004 14:51:54 GMT, Bob Stephens
<stephensyomamadigital@earthlink.net> wrote:

>On 7 Dec 2004 14:47:33 GMT, Hans-Bernhard Broeker wrote:
>
>> You're trying to do exactly what an entire division of a major company
>> explicitly was told to go out of their to make hard for you do to.
>> And guess what, they did it --- it's friggin' hard.
>
>Could you elaborate on this a bit? I would like to boycott whoever it was
>that invented this spec from hell.

I'm not certain what Hans-Bernhard  is referring to, but the statement
might not be completely fair.

IIRC, Microsoft wanted "new" computers to lose some legacy hardware,
specifically keyboard, mouse, serial, and printer ports as well as the
ISA bus.  They became one of the driving forces, along with Intel,
NEC, HP, Agere, Philips, and Compaq (IIRC) of USB.  

The goals of USB included replacing the aforementioned ports and bus,
as well as providing true PnP so there would be no fiddling with
jumpers and no consumption of system resources (specifically
Interrupts and I/O ports).  Furthermore, it was decided that the
peripheral side of the interface should be as simple as possible, so
as not to impact the cost of peripherals too much.

Writing code for the peripheral side of the interface isn't a whole
lot more complex than writing code to talk to a UART.  Writing the
host side drivers is, however.

Ever since computers have started shipping with USB ports, many
embedded systems programmers have felt it's a plot to make their lives
more difficult.  I don't believe that's true.  It's a plot to make the
average computer user's life less difficult, which makes Microsoft's
and computer manufacturers'  lives less difficult (in theory anyway).
And it mostly works.  

But embedded systems programmers are not (generally) average computer
users.  Average computer users simply use their peripherals, generally
for what they were designed for.  Embedded systems programmers
bastardize serial and parallel ports for their own use, and hook up
peripherals to systems for which they weren't developed.  In doing so,
we've ridden the cost curve down and are used to cheap, simple
solutions.  USB makes some of this more difficult.

Note that I don't have any particular love (or hate) for USB.  I have
written code for HID devices, but that was years ago at a different
employer, and my income isn't dependant on it's success (or failure).
I just don't see it as a conspiracy against me using cheap PCs and
peripherals, any more than I see protected mode as a conspiracy to
keep me away from I/O port access (actually, less: keeping me away
from I/O ports _is_ one of the goals of protected mode...).

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

On 7 Dec 2004 15:22:25 GMT, Hans-Bernhard Broeker
<broeker@physik.rwth-aachen.de> wrote:

>Bob Stephens <stephensyomamadigital@earthlink.net> wrote:
>> On 7 Dec 2004 14:47:33 GMT, Hans-Bernhard Broeker wrote:
>
>> > You're trying to do exactly what an entire division of a major company
>> > explicitly was told to go out of their to make hard for you do to.
>> > And guess what, they did it --- it's friggin' hard.
>
>> Could you elaborate on this a bit? I would like to boycott whoever it was
>> that invented this spec from hell.
>
>Unless I misremember badly, it's Intel.  Which makes boycotting them
>rather harder than one might like.

Yes, Intel was in there, along with Microsoft (who I think started the
ball rolling) and some PC manufaturers.

>
>I've said this before, but I'll say this again: the only assumption
>about motives that can really explain why USB was designed the way it
>was designed, given existing technology at the time (particularly IEEE
>1394, a.k.a. Firewire), is that it was predominantly a marketing
>scheme to be able to keep selling powerful personal computers.  It was

1394 and USB came along at pretty much the same time (though Apple had
FireWire earlier).  If you're going to fault USB with overkill, how
much worse is 1394?

>a strategic move against the replacement of PCs by pervasive
>computing.

I don't understand.  Could you expand on this?

>
>As a side effect, it will sooner or later kill off the ordinary PCs'
>usability for applications typical to this very newsgroup.  I suspect

Agreed.

>there are entire "computer stores" already without a single serial or
>parallel port to be found on the premises --- well, possibly excepting
>the debug ports of the cash register and soda vending machine.
>
>To put it bluntly: there was *nothing* wrong with the PC keyboard
>interface that it would have taken something like USB to fix.  There

This is mostly true, but incomplete.  USB is designed to replace the
keyboard, mouse, serial, and parallel ports as well as the ISA bus.
There were _huge_ problems with I/O and interrupt conflicts in legacy
systems.  ISA PnP never worked very well.  USB aims to reduce I/O and
interrupt resource usage by concentatrating it all in a single
controller, and simplify configuration (for the user) by doing it
automatically when a new device is connected.

>were some extensibility issues with mouse protocols (not with the port
>itself, mind you!), granted, but even for those, USB is serious
>overkill.  I don't see any plausible reason a human interface device
>controlled by a person's hand could possibly need a 11 Mb/s data link
>to the computer.

Neither did the developers of USB.  Which is why keyboards and mice
are generally designed to use low speed (1.5 MHz) mode.  Helps reduce
their cost.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

On Tue, 07 Dec 2004 15:37:25 GMT, Dave Hansen wrote:

> On Tue, 07 Dec 2004 14:51:54 GMT, Bob Stephens
> <stephensyomamadigital@earthlink.net> wrote:
> 
>>On 7 Dec 2004 14:47:33 GMT, Hans-Bernhard Broeker wrote:
>>
>>> You're trying to do exactly what an entire division of a major company
>>> explicitly was told to go out of their to make hard for you do to.
>>> And guess what, they did it --- it's friggin' hard.
>>
>>Could you elaborate on this a bit? I would like to boycott whoever it was
>>that invented this spec from hell.
> 
> I'm not certain what Hans-Bernhard  is referring to, but the statement
> might not be completely fair.
> 
> IIRC, Microsoft wanted "new" computers to lose some legacy hardware,
> specifically keyboard, mouse, serial, and printer ports as well as the
> ISA bus.  They became one of the driving forces, along with Intel,
> NEC, HP, Agere, Philips, and Compaq (IIRC) of USB.  
> 
> The goals of USB included replacing the aforementioned ports and bus,
> as well as providing true PnP so there would be no fiddling with
> jumpers and no consumption of system resources (specifically
> Interrupts and I/O ports).  Furthermore, it was decided that the
> peripheral side of the interface should be as simple as possible, so
> as not to impact the cost of peripherals too much.
> 
> Writing code for the peripheral side of the interface isn't a whole
> lot more complex than writing code to talk to a UART.  Writing the
> host side drivers is, however.
> 
> Ever since computers have started shipping with USB ports, many
> embedded systems programmers have felt it's a plot to make their lives
> more difficult.  I don't believe that's true.  It's a plot to make the
> average computer user's life less difficult, which makes Microsoft's
> and computer manufacturers'  lives less difficult (in theory anyway).
> And it mostly works.  
> 
> But embedded systems programmers are not (generally) average computer
> users.  Average computer users simply use their peripherals, generally
> for what they were designed for.  Embedded systems programmers
> bastardize serial and parallel ports for their own use, and hook up
> peripherals to systems for which they weren't developed.  In doing so,
> we've ridden the cost curve down and are used to cheap, simple
> solutions.  USB makes some of this more difficult.
> 
> Note that I don't have any particular love (or hate) for USB.  I have
> written code for HID devices, but that was years ago at a different
> employer, and my income isn't dependant on it's success (or failure).
> I just don't see it as a conspiracy against me using cheap PCs and
> peripherals, any more than I see protected mode as a conspiracy to
> keep me away from I/O port access (actually, less: keeping me away
> from I/O ports _is_ one of the goals of protected mode...).
> 
> Regards,
> 
>                                -=Dave

Now why did you have to go and get all reasonable and rational on us?
I was looking forward to a protracted rant;)


Bob

Dave Hansen <iddw@hotmail.com> wrote:
> On 7 Dec 2004 15:22:25 GMT, Hans-Bernhard Broeker
> <broeker@physik.rwth-aachen.de> wrote:

> >I've said this before, but I'll say this again: the only assumption
> >about motives that can really explain why USB was designed the way it
> >was designed, given existing technology at the time (particularly IEEE
> >1394, a.k.a. Firewire), is that it was predominantly a marketing
> >scheme to be able to keep selling powerful personal computers.  It was

> 1394 and USB came along at pretty much the same time (though Apple had
> FireWire earlier).  If you're going to fault USB with overkill, how
> much worse is 1394?

Not worse; but better, actually.  1394 is a well-done protocol,
fulfilling a real need (high-rate data streaming, esp. video), and it
does its job well.

I'm faulting USB for overkill for some of its applications only:
low-bandwidth, low-latency stuff like mouse and keyboard data has no
business occupying the same wire as a 11 Mb/s data stream.  It's
essentially impossible to avoid one type of communication getting into
the other's way.  USB 1.1 is a complete hodgepodge.  It's overkill for
some of its planned applications, and severely underpowered for most
of the others.

You'ld have thought that the guys at Intel & friends would know that
"one size fits all" doesn't ever really work.  But they did it
nevertheless.  Which begs the question: why?

> >a strategic move against the replacement of PCs by pervasive
> >computing.

> I don't understand.  Could you expand on this?

For a long time now, Microsoft and Intel have worked by the "single PC
as a center of your digital world" dogma.  That's what led to crazy
stuff like the current typical supermarket PC: 3+ GHz CPU, a GiB of
memory, thermal design problems that make working in outer space
appear like a minor issue in comparison, PCs louder than your average
car, and all that.

What we're looking at here is utter, total centralism.  The same kind
of centralism is designed into almost every aspect of the USB
protocol.  USB is highly asymmetric, offloading all the hard work to
the central hub: by silent assumption, that's a PC (of some kind,
i.e. Apple gets to play, too).

Now it's commonly accepted that dogmatic centralism is wasteful.
Distributed systems are often more efficient, and it's a lot easier to
specialize from a distributed general design to a one-node case than
to generalize from a centralistic design to a situation where a single
center simply can't cut it.  

IMHO it's at least plausible to assume that in a purely open market,
without the Wintel monopoly, other players would have grabbed a
significant share of the market in the move from the single PC to a
world of computing power delivered at the exact point it's needed.

> >To put it bluntly: there was *nothing* wrong with the PC keyboard
> >interface that it would have taken something like USB to fix.  There

> This is mostly true, but incomplete.  USB is designed to replace the
> keyboard, mouse, serial, and parallel ports as well as the ISA bus.

Wait a minute: a 11 Mbit/s star (it's not actually a bus), disturbed
by high-priority 1.5Mbit/s packets and several layers of protocol
overhead is supposed to replace an 64 Mbit/s bus that was already
being stretched to its limis by hardware of that day?  You gotta be
kidding.

If there's a single I/O interface of the legacy PC USB 1.1 was in no
way fit to replace, it's the ISA bus.

> ISA PnP never worked very well.

That's what rightly got us PCI.  Not an entirely sweet pill, either,
but in a totally different league than USB.


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

On 7 Dec 2004 16:32:48 GMT, Hans-Bernhard Broeker 
<broeker@physik.rwth-aachen.de> wrote:

> You'ld have thought that the guys at Intel & friends would know that
> "one size fits all" doesn't ever really work.  But they did it
> nevertheless.  Which begs the question: why?

For the same reason the same guys develop Wireless USB (WUSB), pretending 
BlueTooth has never existed.

   Vadim