Analyzing USB Comm

[kirtcathey]

Darrel,

Thanks again. A straight answer, and a common sense one at that.
What was I thinking? The USB bus does carry all the scattered traffic and isolating the keyboard only traffic is possible. BUT not at that speed on a little MCU. Now that you point that out - I may as well have tried to develop an enterprise accounting system on a 16F series chip.

Okay, so now I have to move on to completely internalizing the keyboard command as a host, filtering for processing information, then passing on to destination host.

Thank you.

[kirtcathey]

FTDI is my friend.....
http://www.ftdichip.com/Products/FT8U100AX.htm
And this chip has a port specifically for keyboard communication.
The FTDI web site says this device is not recommeded for new designs, but it's in stock at the elctronics store down the road.

Will post the final design and questions as this unfolds.... so I am still with a USB PIC!

[Darrel Taylor]

Ehhhh, maybe not such a good "Friend".

Never used that chip, but looking at the datasheet, it seems that it's mostly a "HUB".

It does accept rs232, keyboards, mice and stuff.
But the conversion is to USB, not RS232.

I don't see any way to read the keyboard with an MCU.
Could be I just haven't read far enough.

If you want FTDI, then I think the ...

Vinculum Embedded USB Host Controller
http://www.ftdichip.com/FTProducts.htm#Vinculum

might get you closer.

[kirtcathey]

Darrel,

You're right (again). Vinculum is the way to go, and that chip I mentioned is a hub with 7 downstream and one upstream.... it may work, but not experimenting any more if I can avoid it. I bought what was available at Akihabara today - a USBN9604, which is a node controller from National Semicon. Can't wait to get out of this meeting and back home to put things together.

If I may ask another question...
1) I understand that coding away to filter all the stuff that would come in on a comparator would be an arduous task, but why is speed an issue? People can only type so fast. Or, would the comparator require a couple cycles each time doing it's thing? I know my code would require a couple of cycles to filter the signal as well. Gave up on that route for this particular endeavor, but still fishing around for information just because I want to know more about that function on MCU.

[Darrel Taylor]

... but why is speed an issue? People can only type so fast.

Well, let's say that an 18F is running at 48Mhz. (the fastest 8-bit PIC)
Divide that by 4, and the CPU core will execute 12 million instructions per second.

Full-speed USB is 12 million bits per second. So at best, you could only execute 1 instruction of your program per incoming BIT of data.

Now, considering it takes 4 instructions to copy the state of a pin to a BIT variable. It's easy to see that it just can't be done with software.

Plus there is a LOT of overhead communication with USB. Even if nobody was typing on the keyboard, there's still a ton of data being passed back and forth. The computer is constantly asking the device ... "Are you there", and the device says ... "Yup, I'm here", over and over and ...
When it gets unplugged and the computer doesn't get an "I'm here" anymore, it disconnects the device driver and you hear the ding-dong.

So basically, USB interfaces MUST be done with hardware.

hth,

[rmteo]

Technically, the fastest 8-bit PICs are the PIC18FxxKxx series that are rated at 64Mhz. But you are absolutely correct about USB stuff being done in hardware.

[Darrel Taylor]

Technically, the fastest 8-bit PICs are the PIC18FxxKxx series that are rated at 64Mhz.

I stand corrected!

I will now have her give me 40 lashes for the error.
WooHoo!