P2 Hosted USB Keyboard/Mouse

garryj · 2019-05-17 00:27

Edit: 2020-09-17: added the KbMObjDemos v0.1.4 .zip package.

Edit: 2019-05-20: added the P2asm version .zip package.
Edit: 2019-05-18: update v0.02 (minor changes) and added the port A/B and the verbose enumeration .zip packages.

P2-Eval board + Serial Host accessory board, using pins 16..24 (16..25 if using A/B ports). Pin definitions are at the top of the 1CogKbm.spin2 file.
Sysclock 160MHz, 230400 baud serial.
Compile/run using fastspin and loadp2 and its built-in -t option terminal.

Spin2USBKbm-v0.02.zip:
The Spin2 top object file is KbMObjTest.spin2. The 1CogKbM.spin2 file is a one cog USB host + keyboard/mouse driver. The P2 pin usage is documented at the top of the 1CogKbm.spin2 file. The top object also loads the SmartSerial.spin and std_text_routines.spinh files that are packaged with Spin2gui.

Spin2USBKbMx2-v0.02.zip:
The same as above, but loads a second 1CogKbM object to utilize both ports (A-lower/B-upper) of the Serial Host accessory board.

USBEnumerate.zip
This is older code (three cogs) that outputs the contents of the various USB descriptors read at device enumeration. If you have a keyboard/mouse that is not recognized (or any other USB device) , the descriptor information may help when troubleshooting. Sometimes at cold startup, it may not detect a device when connected. If this happens, a reload of the code should get it going.

P2asmUSBKbm-v0.02.zip
P2asm version of the one cog USBKbM demo.

Tubular · 2019-05-17 00:33

@Ozpropdev will be really excited to see this, Garry. I think his current setup takes 2 cogs for the keyboard, and we were wondering whether adding mouse/second keyboard would take a 3rd or even 4th cog.

Great progress, and in Spin2 too. Thanks for your ongoing efforts

Rayman · 2019-05-17 00:40

Nice work!
I was hoping this was possible.

I think 250 MHz is going to be the sweet spot though.

ozpropdev · 2019-05-17 01:35

Cool @garryj :cool:
Looking forward to replacing my current USB keyboard code in Self hosted Micropython to this.

ersmith · 2019-05-17 16:20

This looks great, thank you @garryj!

I've tried several mice now and they've worked fine. Unfortunately I'm having trouble with keyboards. I've tried two keyboards. The first wasn't detected properly (it triggered the DEV_UNKNOWN "Boot protocol keyboard/mouse not found") so perhaps it just doesn't support boot protocol? The second was a wireless combo keyboard/mouse; the mouse part works fine, but only a few function keys are recognized and they're completely wrong (e.g. F1 is coming out as 'd' and F2 as backspace). Have you seen that before?

Thanks,
Eric

garryj · 2019-05-17 17:08

ersmith wrote: »

This looks great, thank you @garryj!

I've tried several mice now and they've worked fine. Unfortunately I'm having trouble with keyboards. I've tried two keyboards. The first wasn't detected properly (it triggered the DEV_UNKNOWN "Boot protocol keyboard/mouse not found") so perhaps it just doesn't support boot protocol? The second was a wireless combo keyboard/mouse; the mouse part works fine, but only a few function keys are recognized and they're completely wrong (e.g. F1 is coming out as 'd' and F2 as backspace). Have you seen that before?

Thanks,
Eric

Yes, during device enumeration "boot protocol" interfaces must be defined. I have an early MS wireless keyboard/mouse combo where the keyboard supported boot protocol and the mouse did not. Are the keyboards wired, or wireless? If the device is wireless and BlueTooth it's likely it won't work, as it appears that BlueTooth devices that support boot protocol are pretty rare.

For keyboards, do the alpha, numeric and punctuation keys emit the proper characters? The demo doesn't process keys outside the (US)ASCII $20..$7f "printable" range, so function keys and cursor navigation keys will emit their raw scancode, instead.

ersmith · 2019-05-17 18:19

For keyboards, do the alpha, numeric and punctuation keys emit the proper characters? The demo doesn't process keys outside the (US)ASCII $20..$7f "printable" range, so function keys and cursor navigation keys will emit their raw scancode, instead.

For the wireless keyboard the alpha, numeric, and punctuation keys emitted nothing at all. The only keys that did anything were function keys, and they were emitting keys from the middle alpha row (d, h, j, k). Weird.

Third time lucky though, I managed to find another USB keyboard and it's actually working correctly. Now to hook your code up to mine. It looks very well commented and should be easy to integrate. Thanks for writing this!

Eric

garryj · 2019-05-17 19:18

I'm glad to hear that you had one that works!

Could you post the brand & model# of the failing keyboard keyboards? I've got six keyboards of various types in my test pool and they're all working for me. I'd like to investigate further as to why your's fail.

ersmith · 2019-05-17 20:04

Sure. The two failing keyboards are a Sony PS/2 keyboard (that one wasn't even recognized) and a Logitech K400 wireless keyboard/mouse combo (that one the mouse worked fine, but only a few keys did anything and they came out wrong: the alphanumeric keys did not respond at all but a few function keys produced alpha characters). An Asus USB keyboard worked fine though.

garryj · 2019-05-18 01:12

Yeah, the PS/2 keyboard probably didn't advertise the boot protocol. The Logitech K400 has me scratching my head a bit. Nothing it its specs suggest that it wouldn't support boot protocol. One of my test keyboards is a Logitech wireless K520, and it works. Trouble-shooting USB without an analyzer handy can get one pulling out their hair pretty quickly :zombie:

rogloh · 2019-05-18 03:23

garryj wrote: »

Trouble-shooting USB without an analyzer handy can get one pulling out their hair pretty quickly :zombie:

@garryj,
Could other COG(s) of the P2 somehow become a USB analyzer I wonder? Would it be possible to monitor/timestamp/log USB transaction activity in real time? If so, that could become a handy tool as well, particularly during driver/device bringup.

Rayman · 2019-05-18 16:00

I tried 3 different keyboards and they all worked. Thanks garryj!

I had a wireless combo but having trouble finding it...

Rayman · 2019-05-18 16:03

Borrowed a Logitech wireless kb/mouse combo and it works.
KB is K330, mouse is m215

avsa242 · 2019-05-18 17:58

I tried these:
Microsoft Media Pro (wired) keyboard, M/N 1031: works
Logitech K270 (wireless) keyboard and mouse, M/N Y-R0042: both work

Both come back after being disconnected and reconnected

If I can find its receiver, I have an old Logitech diNovo Edge keyboard (has a builtin touchpad) I can try

EDIT:
Yeah, no luck with the diNovo... Boot protocol keyboard/mouse not found as ersmith ran into above. The receiver is, IIRC, combination BT and non-specific 2.4GHz RF (maybe mostly for when the PC first starts and there is no Bluetooth stack yet?).

Cheers,
Jesse

garryj · 2019-05-18 23:00

rogloh wrote: »

garryj wrote: »

Trouble-shooting USB without an analyzer handy can get one pulling out their hair pretty quickly :zombie:

@garryj,
Could other COG(s) of the P2 somehow become a USB analyzer I wonder? Would it be possible to monitor/timestamp/log USB transaction activity in real time? If so, that could become a handy tool as well, particularly during driver/device bringup.

Yeah, a sniffer cog could monitor the usb pretty easily. The challenging part, as you mentioned, would be the filters that you need to build a comprehensive picture of the parts of the data stream that you're interested in. It's not even close, as an analyzer, but I've added some older code to the top post that outputs descriptor contents at device enumeration that may shed some light on why a keyboard/mouse device is not being recognized.

garryj · 2019-05-20 19:30

Added the p2asm version of the one cog keyboard/mouse demo to the first post.

thej · 2019-05-21 15:15

Looks like it might be time for a Google Doc of working Mice, KB and Combos.

J

Rayman · 2019-08-04 14:55

I'm looking at this code again to see how hard it would be to change it for games.
For games, you want to know all the keys that are currently being pressed.
Fortunately, I think this is going to be fairly easy.
I think this section has access to the keyboard report about all keys currently pressed:

' /* hkbd_compare
'------------------------------------------------------------------------------
' Compare current and previous keyboard data buffers for keypress changes.
'------------------------------------------------------------------------------
' On entry:
' On exit:
'   hpar1 - scancode of the last key in the down state, otherwise zero
'     (KEY_NO_KEY) if no keys were in the down state.
'   hkbd_modkeys - the current (possibly changed) modifier key states.
'------------------------------------------------------------------------------

BTW: This code is impressively well written and documented. Much nicer than anything I've ever done!

cheezus · 2019-08-04 16:02

I'm getting ready to start testing my USB devices and I was wondering if anyone had any ideas about getting a Novation Launchpad Mini to work with the P2? I've been trying to find information about the USB implementation but I guess my google-fu if off today. I was able to find this though
https://hackaday.com/2018/11/04/launchpad-midi-controller-put-to-work-with-python/

I'm also considering trying to get my Akai MPK249 working over USB, although since that has MIDI ports I'll probably just go that route.

garryj · 2019-08-04 17:48

Rayman wrote: »
I'm looking at this code again to see how hard it would be to change it for games.
For games, you want to know all the keys that are currently being pressed.
Fortunately, I think this is going to be fairly easy.
I think this section has access to the keyboard report about all keys currently pressed:
' /* hkbd_compare
'------------------------------------------------------------------------------
' Compare current and previous keyboard data buffers for keypress changes.
'------------------------------------------------------------------------------
' On entry:
' On exit:
'   hpar1 - scancode of the last key in the down state, otherwise zero
'     (KEY_NO_KEY) if no keys were in the down state.
'   hkbd_modkeys - the current (possibly changed) modifier key states.
'------------------------------------------------------------------------------

Yeah, the key-down event is the only one acted on. The boot protocol supports up to six key rollover (but the device may not), so you could directly poll the kbd_cur_report buffer to set up your own compare routine to track down/up state change for individual keys. The USB HID 1.11 spec appendix B describes the boot interface:
https://usb.org/sites/default/files/documents/hid1_11.pdf
I should probably add an event posting by the host when a keyboard data packet is received, but polling at 10ms or less intervals should catch the changes.

RossH · 2019-11-02 03:29

These drivers work fine on the RevA board, but I can't get them working on the RevB board. The LEDs flash but nothing is recognized when I plug it in.

I haven't looked at the code yet, but before I do - has anyone managed to get them working on RevB?

Ross.

rogloh · 2019-11-02 04:00

I haven't tried yet on my RevB as I noticed it needed fastspin which I haven't loaded yet but was planning to soon. Maybe ozpropdev has?

One further question to @garryj on this USB driver...

From memory these drivers support a keyboard, a mouse or a combined keyboard+mouse USB device on a single port, or devices on separate USB ports. Will it be feasible in the future to support an independent keyboard and mouse device on a single port, via a USB hub ? Any idea how many COGs that might take?

SaucySoliton · 2019-11-02 04:13

Some of the USB smart pin modes were combined/relocated to fit the SINC filter for the ADC. It's taking me too long to find the documents for it.

RossH · 2019-11-02 04:52

SaucySoliton wrote: »

Some of the USB smart pin modes were combined/relocated to fit the SINC filter for the ADC. It's taking me too long to find the documents for it.

That could be the problem. Unfortunately, I also can never seem to find any useful documentation on the Smart Pins. Perhaps Garry will have more luck

Does anyone know of any other USB code that works on the Propeller 2 RevB?

VonSzarvas · 2019-11-02 07:08

I thought Chip mentioned something about SINC changes recently... still hunting the thread.

There's some new updates here too:

https://forums.parallax.com/discussion/comment/1479811/#Comment_1479811

Guess you have that Ross, but might help someone.

VonSzarvas · 2019-11-02 07:11

Found what I was remembering...

Try the last page or so of this topic:

https://forums.parallax.com/discussion/comment/1479560/#Comment_1479560

RossH · 2019-11-02 07:30

VonSzarvas wrote: »

Guess you have that Ross, but might help someone.

Yes, I've looked at that, and it seems to accord with Garry's code (you have to manually enable the V2 alternate code). But it still doesn't work.

I have no equipment suitable for debugging this, so I will have to wait till someone with more experience with USB takes a look at it.

Peter Jakacki · 2019-11-02 09:23

Slightly OT but to do with HID as I did some work some time ago investigating the Logitech wireless dongle interface since that is based around Nordic nrf24 chips. Seems that would be a good way to interface keyboard and mouse combos and not have any connectors or cords. That is, we don't use their dongle, we just communicate via the nRF24 chip. I have some spare dongles so maybe I will try to hack one for further insight.

garryj · 2019-11-02 19:01

I don't yet have revb silicon to test with but, as @RossH said, the demo code does have commented out code that sets the revb smart pin mode. Switching to the alternate wrpin and wxpin settings should satisfy the revb USB NCO configuration:

' /* host_reset
host_reset
'                drvh    #KBM_ACTIVE_LED
                setint1 #0
                dirl    #DP                             ' Put smart pins into reset
                dirl    #DM
                wrpin   ##USB_V1HMODE_FS, #DP           ' The host is also the root hub, so full-speed is its native speed
                wrpin   ##USB_V1HMODE_FS, #DM
                wxpin   ##_12Mbps, #DM                  ' Default to Full-Speed
{
                wrpin   ##USB_V2MODE, #DP               ' Low-speed signalling is always used
                wrpin   ##USB_V2MODE, #DM
                wxpin   ##USB_H_FS_NCO, #DM             ' Host mode and default to 12Mbs baudrate
}

set_speed_low
                test    hstatus, #DWNSTRM_HUBF wz       ' If no downstream hub connected, set low-speed baudrate
        if_z    dirl    #DP
        if_z    dirl    #DM
                wrpin   ##USB_V1HMODE_LS, #DP           ' Low-speed signalling is always used
                wrpin   ##USB_V1HMODE_LS, #DM
        if_z    wxpin   ##_1_5Mbps, #DM                 ' Set 1.5Mbs baudrate if no downstream hub
{
                wrpin   ##USB_V2MODE, #DP               ' Low-speed signalling is always used
                wrpin   ##USB_V2MODE, #DM
        if_z    wxpin   ##USB_H_LS_NCO, #DM             ' Host mode and 1.5Mbs baudrate if no downstream hub
}

Here is also a link to Chip's post regarding an additional step he had to implement to get it working:
https://forums.parallax.com/discussion/comment/1475565/#Comment_1475565

Wish I could be of more help

garryj · 2019-11-02 19:55

rogloh wrote: »

I haven't tried yet on my RevB as I noticed it needed fastspin which I haven't loaded yet but was planning to soon. Maybe ozpropdev has?

One further question to @garryj on this USB driver...

From memory these drivers support a keyboard, a mouse or a combined keyboard+mouse USB device on a single port, or devices on separate USB ports. Will it be feasible in the future to support an independent keyboard and mouse device on a single port, via a USB hub ? Any idea how many COGs that might take?

Correct, regarding single ports. A USB hub driver has been on my todo list for quite a while, but has been side-tracked the last few months by other things. Since there shouldn't be any additional low-level buss signalling changes, I think the core code should still fit in one cog + lut exec, with the hub buss scheduler driver developed using C and/or spin. I'm hoping to get to that post-revb p2 silicon.

rogloh · 2019-11-02 21:49

garryj wrote: »

Correct, regarding single ports. A USB hub driver has been on my todo list for quite a while, but has been side-tracked the last few months by other things. Since there shouldn't be any additional low-level buss signalling changes, I think the core code should still fit in one cog + lut exec, with the hub buss scheduler driver developed using C and/or spin. I'm hoping to get to that post-revb p2 silicon.

Sounds promising, and I am hoping that might end up being the case. A single USB COG doing both devices separately on a single bus will be handy/essential once COGs become tight, which they inevitably will at some point when people make full use of the P2. Thanks garryj!

P2 Hosted USB Keyboard/Mouse

Comments