Analyzing USB Comm

Hi All.

This is something I have been working on a while, and as I discover more, the scope expands! I (still) want to create a device that connects between a keyboard and host PC that will trigger a remote process when the end-user types a certain string into the keyboard. I am currently using the 18F2550. Yes, I understand that the PIC 18F cannot be a USB host. I am not trying to host the USB keyboard but just want information that comes from it to the PC host.

This has led me to looking into using an onboard comparator tapped into the D+ and D- lines and decipher the key strokes with code. Which is a big plus for size, since I may not need a USB PIC afterall. I think I can setup the comparator with the following information, but do not know exactly how. For example, I think that a threshold voltage of 1.25 Volts is probably going to work, but do not know where to connect the D+ and D- lines (that are tapped). Also, how do I work out the timing and setup the timer? Will one comparator suffice, or do I need to setup two comparators?

Here is the information that I've got about the USB differential signaling:
Transmitted signal levels are 0.0–0.3 volts for low and 2.8–3.6 volts for high in Full Speed (FS) and Low Speed (LS) modes.

Now, if we go this far, I want to create something bigger than a keyboard detector! We can create another analysis tool for the workbench - a USB protocol analyzer.

Any help?

Thank you.

Hi,

are you trying to detect any keys from the keyboard or specific ones?

If you are trying to detect specific key presses, analyzing the USB data using comparators sounds quite tricky to me...

If it was me, I would make a software application that listens for the specific key presses and then on receiving them outputs a specific message to the PIC, either by USB or RS-232, and then the PIC can take the relevant action.

May be a different way of looking at what you are trying to achieve.

Hope this helps

Rob

Good call and thank you, but host software is not an option. If so, believe me, it would have been complete very soon after seeing the requirement. The system controls a complex factory robot controlling system and the engineer on that end will not let us install any software (but he doesn't mind us poking around with the hardware... whatever!). The first three characters will have to be detected and will be constant. The last four will change and be alphanumeric, and will need to be sent to the other end for control reasons.

I understand that the coding will be complex. Just need to know how to setup a comparator for this kind of thing so I can start coding. It is amazing at how little is available about the comparator. There is a lot out there that talks about the comparator, and Melanie has a great posting on setting it up in PicBasic, but nothing on what wire goes where, how to setup the timer and how that connects to the comparator or any other detail for someone to get started. I've used in some way or another quite a bit of different functions on the PIC - just not the comparator.

These are my search results so far:
Google -nothing but references to Microchip and this forum.
This forum -only morsels in bits and pieces with one good post on the very basics by Melanie.
Microchip -20 ways to configure a comaparator for anything I don't need to do.

Thanks again.
--Kirt

I really don't think you're going to have much luck doing that.

USB is a VERY complex protocol operating at 12 Megabits/sec. (full speed)
That's waaaayyyy to fast for those poor little comparators.
And also waaaayyyy to fast to decode with software even if the comparator could handle it.

Plus, there are control transfers and polling every 1ms, and just because you see data on those lines, doesn't mean it either came from, or is intended for the keyboard. It could very well be a control transfer for another device on the bus.

I know you don't want Host interface. But you'll have to, for a USB keyboard.
There are many different dedicated Host chips, like ....

USBwiz
http://www.ghielectronics.com/details.php?id=5&sid=6
<br>

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.

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!

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.
<br>

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.

Quote:

---

Originally Posted by kirtcathey

... 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,

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.

Quote:

---

Originally Posted by rmteo

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! :D
<br>

Thank you.... soldering the USB controller chip onto a daughter board right now. When I get the whole rig breadboarded and working, will update my schematic and post it here.

Again, thank you for all the direction.

How about a different approach:

Take a PS/2 keyboard and a PS/2-USB adaptor and tap the data on the PS/2 side.
There are a lot of keyboard interfacing examples out there...

Regards,

Ingo

That would be the quicker route and it was considered, because there is a lot about tapping a PS2 keyboard out there.... and it's still not out of the question. Right now I have everything breadboarded with the USBN9604 and am working on the code, so will continue to push forward with USB only.

Thank you for the suggestion.