Need Propeller code to read data from a USB HID keyboard (not PS/2 emulation)
Bean
Posts: 8,129
I have a bunch of USB (HID) mini keyboards that I would like to see to propeller users.
I was hoping the keyboards would be serial or PS/2, but it turns out that they are USB HID devices.
I did some searching and I found some threads that can make the propeller be a USB (HID), but none that allows the propeller to receive data FROM a USB device.
From what I discovered the communication is fairly slow and should be doable on the propeller. But before I try to do it myself, I thought I would ask if anyone else has already done this, or knows of code that already does this.
Thanks for any help you can give me,
Bean
I was hoping the keyboards would be serial or PS/2, but it turns out that they are USB HID devices.
I did some searching and I found some threads that can make the propeller be a USB (HID), but none that allows the propeller to receive data FROM a USB device.
From what I discovered the communication is fairly slow and should be doable on the propeller. But before I try to do it myself, I thought I would ask if anyone else has already done this, or knows of code that already does this.
Thanks for any help you can give me,
Bean
Comments
Which has been used for the Prop- Android connection here http://forums.parallax.com/showthread.php?130380-Android-Debug-Bridge-on-a-prop&highlight=android+bridge
No idea if the is any HID implementation in there though.
Thanks for the linky...
There is a HID implementation, but it requires 3 cogs and a 96MHz clock.
I may be wrong, but I thought the HID implementation used a much slower USB clocking speed (1.5MHz).
Bean
Bean
.http://nagasm.suac.net/ASL/usb/kbdps2.pdf
http://nagasm.suac.net/ASL/usb/usbkbd.pdf
The CY7C63413 offers 2 modes of operation after a power- on-reset (POR) event:
suspend-on-reset (typical for a USB application)
and run-on-reset (typical for a PS/2 application).
The suspend-on-reset mode is selected by attaching a pull-up
resistor (100K to 470K W) to Vcc on Bit 7 of GPIO Port 3.
The run-on-reset mode is selected by attaching a pull-down resistor
(0 to 470K W) to ground on Bit 7 of GPIO Port 3.
Have you looked at Kye's HID keyboard/mouse driver? It sounds like what you are after.
--trodoss
The USB host code could be modified to be more flexible for 1.5Mbps. That's definitely a longer project though. Today the 12Mb/s USB host code requires using certain pins and demands that bit stream timing be exactly right - no i.e. autobauding. With 1.5Mb/s connections both of those problems can be corrected. Of course that won't change the connector requirement :<
@trodoss, the USB HID requirement is very different from the HID interface serviced in your pointer.
That object is for PS/2. This keyboard does not use PS/2. I've tried it.
@TonyP12, From reading the datasheet the firmware has to be written to support PS/2 protocol. Since this keyboard is a custom product is appears the PS/2 protocol is not supported. But I'll try the connections you mention and see what happens.
Bean
I take a picture today when I get home. These keyboard are really nice compared to the other mini keyboards I had. They "click" when pressed and also have seperate digit keys.
Just by cutting a cable inside and making 4 connections to a USB cable you can plug them into a PC and they work as a PC keyboard.
Bean
On the cable:
Black = USB (D+)
Green = USB (D-)
Yellow = +5V
Gray = Gnd
Blue and Red = Int/Ext power signal to PDA (not used for my application)
Bean
Maybe tonyp12 or tubular should be hacking at these. It should be easy to make a Propeller key scanner for these, but it would be more work than I should be doing right now.
It is a CY7C63413-PVC which digikey says is a OTP part
Bean
Apparently there is a simpler "Boot Protocol" that can be used for keyboards.
The mini keyboard seems to support it because I can use it in the BIOS setup screens.
Do any of you USB "Gods" know if the boot protocol is in fact simpler ? Any ideas about how to implement it in the propeller ?
Bean
USB is not my primary area of interest, but I'll poke around since I have the units.
I'm quite busy right now, so have patience.
From what I've read the boot protocol is simplier, so I thought maybe that would be easier to implement.
Let me know if you need any more info or more keyboards.
I think I'm going to connect USB cables and try to sell some on ebay as a mini-keyboard for tablets and such.
Bean
I'd love to post and say I have this problem already solved, but I ran into a roadblock in my implementation and a month later I haven't had time to touch it, so I think I'll post what I have on the off chance someone else has a need to fix it before I can.
Much of what I have done is based on the excellent full speed driver that Micah wrote. Its not a direct port that simply reduces frequency, since alot of the tricks she used to get the 12Mbps version working isn't necessary with 1.5Mbps clock.
Here's what seems to work:
1. can send REQ_SET_ADDRESS message to attached USB device and it will respond with the ACK token
originally, I thought this was a good sign that I was almost done .... but no such luck.
Here's what doesn't work:
The USB devices I tested all ACK receiving the command itself, but the next step is to request a status message where the device should acknowledge performing the address change, but all I get is NAK or STALL
I tried various low speed devices: keyboard, mouse, joystick ... all with pretty much the same result. They all acknowledge receiving the command, but I can never get them to successfully change address.
The only major thing I haven't implemented yet is SOF packets ... but the USB spec is a little fuzzy on if these are required for low speed devices.
The code is instrumented for debugging with Hanno's ViewPort ... I guess someone could use an external scope or logic analyzer, but ViewPort is just so much more convenient.
There are no pin 0-8 req like on the HS version, but I still use 96MHz clocks ... I'm sure its technically possible to implement on 80MHz, but ...
1. I use 6Mhz crystals on all my designs anyway
2. 1.5MHz is very easy to generate precisely with 96MHz clock ... with 80MHz clock there will be a little error ... not sure if this would matter (hopefully not)
3. currently I am using all 64 clocks cycles that are available in the RX loop to watch for end-of-packet condition (SE0), perform NRZI decoding and store bits to local buffer (It seems likely that this could be done more efficiently and certainly can be done outside the RX loop at the expensive of some extra local storage)
Hopefully, I'll get back to this sometime soon and can figure out where the issue is at, but I'm willing to post what I have so far in case some USB guru out there can get this version working faster than doing another rewrite of the FS driver.
I think a 1 cog - Low Speed USB driver is well within the capabilities of the propeller, and it seems to me this would be highly desired for connecting propeller projects to keyboards, mice, joysticks.
I'd be more than happy to send you a couple of these keyboards for you to experiment with. Just send me a Private Message with your address and I'll send a couple to ya.
Bean