Forums

"Emulate" USB Host

Started by Yxan December 7, 2004
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