The actual pin numbers used are 22 and 23 not the miss printed 24 and 25. used basepin of 16 and the add to in the code. @ada thanks for the input of working with higher clock speeds. I am using with mouse not keyboard and I get nothing past the initial setup info that includes the cog and version numbers. If I read the listing file correctly there are a bunch of print traps already in the test code that should print out the mouse data etc. Not happening. I wonder if I somehow need to configure for a low speed USB. Not sure how to.
Jim
@Rayman The following are the only changes I have made to the KbMObjTest.spin2 file:
System stuff:
_xtlfreq = cfg#_xtlfreq
_clkfreq = cfg#_clkfreq_def
SER_RX = cfg#SER_RX
SER_TX = cfg#SER_TX
SER_BAUD = 2_000_000
@Rayman said:
Actually, it'd be nice if this driver could fall back to PS/2 mode if USB mode fails... I was reading that a lot of mice still support PS/2 mode...
Ir don't work like that. It's nothing to do with USB. That's the mouse/keyboard reconfiguring when it detects it has been plugged into a PS2 port.
So, you'd also have to electrically trick the device as well as making the port PS2 functional.
Further investigation after an interupt to get flexprop 5.9.8 installed and running. I can see where a keyboard event is being handled in the test program, but I cannot find where the mouse data even gets recognized.
if (usbA.byte[KBCON] and (data := usb1.key))
handleKeyData(data)
there is no such data recognizer for the mouse data so I don't see it getting passed to the mouse data handler. Any bright ideas?
Jim
@Rayman
In trying to compile WVGA HDMI Simple... I get a compiler error "expected 4 Parm got 5) seems that @MX is not expected by KBM routine start fn.
Jim
@RS_Jim I just extracted the above zip to an empty folder and the loaded it into Prop Tool. Seems OK.
There are probably various versions of the modified driver... Could be files with same name have slightly different content...
Try extracting the zip to a new folder. Restart Prop Tool and then open WVGA_HDMI_Simple_wUsbMouse_1a.spin2 and try to compile.
Think it should work.
As you probably know, you'll have to go into the driver to set DM/DP pins to match your setup.
@Rayman
The issue is with an @mx included in the start call to the mouse. Compiler says I have too many parameters being sent to the start call and looking at start, it is the @mx at the end of start. I compiled from a download from post 188. I did edit to conform to my environment, but that did not change the call. I am not using prop tool but @ersmith flexprop in a Linux environment with a 25Mhz P2 xtal. Do not have the panel but I wanted to use your mouse driver. once I know it will compile, I will lift your start up code for the mouse and do a simple program to display the XY bytes from the mouse. The whole idea is to use the mouse to control the speed and direction of a couple of motors.
Jim
See my post in General Discussion about crazy joystick idea.
@evanh
in a word, no I don't have the vga set up to test it right now.
here is my test program:
It compiles but hangs after printing that the mouse is loaded.
Jim
I realized after I attached the file, I did not include the config file. That sets the clock speed for a 25MHz xtal and a 200MHz sys clock..
Jim
I noted there was something odd with the encoding of the text source for 1CogKbM_rja3b.spin2. It was compiling in newest Flexspin but not in Pnut. Pnut was getting even weirder errors again.
What I did to make that work was convert file 1CogKbM_rja3b.spin2 from something called UCS2 encoding to UFT8 encoding. No editing of the source code.
Maybe try a USB keyboard? That seems to always work...
Am wondering if the 25 MHz crystal is the problem... Anybody gotten this to work with 25 MHz crystal?
Don't really know why that would be a problem though, especially at 200 MHz which is even multiple of both 20 and 25 MHz...
Still, maybe I'd try other clock speeds if won't work at 200 MHz...
Turns out there's a pretty big bug with the keyboard handling: it expects the report to have all the pressed keys left-aligned. This isn't actually what happens, at least with my PS/2 adapter. That keeps a key in the slot that was the first free one when it got pressed. So if you press X, press Y, then release X, then press X again, you'll get "XYXY" (extra Y press because it thought that all keys were released when only Y was pressed)
Demo Client v0.1.4 + USB low/full speed keyboard/mouse
Sysclock: 180000000, Clkmode: $10008FB, Baud: 2000000
P2RevB+ detected, USB driver version v0.1.4
PortA started: cogID 1, event pin# 16
PortB started: cogID 2, event pin# 20
Reset and suspend/resume actions set to USB portA
PortA boot protocol keyboard/mouse not found
@dgately said:
That gives me keyboard support!
The optical mouse still does not work:
How do I dump the USB descriptor?
Good, attached is a version of the driver that dumps the configuration descriptor bytes, enable debug and you should see a line with:
Cog1 hconfig_base = and a list of hex bytes.
This should give more informations about how the devices are configured (and maybe explains why it notifies the keyboad activity as gamepad...)
Edit: because the keyboard isn't recognized! It is detected as an unsupported gamepad which sends the report packets anyway...
@macca said:
Good, attached is a version of the driver that dumps the configuration descriptor bytes, enable debug and you should see a line with:
Cog1 hconfig_base = and a list of hex bytes.
This should give more informations about how the devices are configured (and maybe explains why it notifies the keyboad activity as gamepad...)
Edit: because the keyboard isn't recognized! It is detected as an unsupported gamepad which sends the report packets anyway...
Ok, I think I see how it works. The device identifies itself as generic HID (not keyboard or mouse specific), the driver detects this as a Gamepad, however the report descriptor sets the usage as keyboard (and I guess as mouse for the other interface) but is ignored, that's why it reports unsupported gamepad.
The driver should be modified to detect the keyboard/mouse setting in the report and enable the keboard and/or mouse support.
A bit complicated, but doable.
Seems this is much more complicated than expected.
I assumed to be able to test using a normal keyboard because it can operate with both boot and report protocols but for some reasons this doesn't work, I guess there is something else to do other than using the right interface.
The driver then needs some bigger change to be able to handle more than one device with the hid report interface.
At this time, the quickest way is ask the firmware author to implement the boot protocol for both keyboard and mouse interfaces (or implement yourself if you have familiarity with the Pi Pico SDK), AFAIK it is just a matter of setting the correct hid class/subclass/protocol values.
The board uses the Raspberry Pi RP2040 MCU to poll the keyboard and trackpad and put the key press information into a FIFO.
You can use the I2C interface to read the FIFO, reconfigure the chip, and change the keyboar backlight.
Connect the keyboard to a P2 using this I2C may be the simplest possible way to use it.
Yeah, but having a small plug-and-play solution, using USB seemed the goal.
Comments
The actual pin numbers used are 22 and 23 not the miss printed 24 and 25. used basepin of 16 and the add to in the code. @ada thanks for the input of working with higher clock speeds. I am using with mouse not keyboard and I get nothing past the initial setup info that includes the cog and version numbers. If I read the listing file correctly there are a bunch of print traps already in the test code that should print out the mouse data etc. Not happening. I wonder if I somehow need to configure for a low speed USB. Not sure how to.
Jim
So, you have DM=22 and DP=23? That should work.
If you post the code, we can take a look to see if something is wrong there...
Most mice seem to work although I seem to recall there being a few that don't...
Actually, it'd be nice if this driver could fall back to PS/2 mode if USB mode fails... I was reading that a lot of mice still support PS/2 mode...
@Rayman The following are the only changes I have made to the KbMObjTest.spin2 file:
System stuff:
_xtlfreq = cfg#_xtlfreq
_clkfreq = cfg#_clkfreq_def
SER_RX = cfg#SER_RX
SER_TX = cfg#SER_TX
SER_BAUD = 2_000_000
' _clkmode = $010007f8 _clkfreq = 200_000_000 _fclkfreq = float(_clkfreq) baud = 2_000_000 '230_400Jim
Ir don't work like that. It's nothing to do with USB. That's the mouse/keyboard reconfiguring when it detects it has been plugged into a PS2 port.
So, you'd also have to electrically trick the device as well as making the port PS2 functional.
Further investigation after an interupt to get flexprop 5.9.8 installed and running. I can see where a keyboard event is being handled in the test program, but I cannot find where the mouse data even gets recognized.
if (usbA.byte[KBCON] and (data := usb1.key)) handleKeyData(data)there is no such data recognizer for the mouse data so I don't see it getting passed to the mouse data handler. Any bright ideas?
Jim
Here's a version that I modified to provide the mouse position:
There's what looks like a slightly older version in the Tetris demo here:
https://www.parallax.com/tetris/
That might give you tips on how to use it...
Here's an example in spin
@Rayman
In trying to compile WVGA HDMI Simple... I get a compiler error "expected 4 Parm got 5) seems that @MX is not expected by KBM routine start fn.
Jim
@RS_Jim I just extracted the above zip to an empty folder and the loaded it into Prop Tool. Seems OK.
There are probably various versions of the modified driver... Could be files with same name have slightly different content...
Try extracting the zip to a new folder. Restart Prop Tool and then open WVGA_HDMI_Simple_wUsbMouse_1a.spin2 and try to compile.
Think it should work.
As you probably know, you'll have to go into the driver to set DM/DP pins to match your setup.
@Rayman
The issue is with an @mx included in the start call to the mouse. Compiler says I have too many parameters being sent to the start call and looking at start, it is the @mx at the end of start. I compiled from a download from post 188. I did edit to conform to my environment, but that did not change the call. I am not using prop tool but @ersmith flexprop in a Linux environment with a 25Mhz P2 xtal. Do not have the panel but I wanted to use your mouse driver. once I know it will compile, I will lift your start up code for the mouse and do a simple program to display the XY bytes from the mouse. The whole idea is to use the mouse to control the speed and direction of a couple of motors.
Jim
See my post in General Discussion about crazy joystick idea.
Try this one Jim:
Did it work?
@evanh
in a word, no I don't have the vga set up to test it right now.
here is my test program:
It compiles but hangs after printing that the mouse is loaded.
Jim
I realized after I attached the file, I did not include the config file. That sets the clock speed for a 25MHz xtal and a 200MHz sys clock..
Jim
Okay, compiling is the answer I was after.
I noted there was something odd with the encoding of the text source for 1CogKbM_rja3b.spin2. It was compiling in newest Flexspin but not in Pnut. Pnut was getting even weirder errors again.
What I did to make that work was convert file 1CogKbM_rja3b.spin2 from something called UCS2 encoding to UFT8 encoding. No editing of the source code.
Maybe try a USB keyboard? That seems to always work...
Am wondering if the 25 MHz crystal is the problem... Anybody gotten this to work with 25 MHz crystal?
Don't really know why that would be a problem though, especially at 200 MHz which is even multiple of both 20 and 25 MHz...
Still, maybe I'd try other clock speeds if won't work at 200 MHz...
I get no response from keyboard either.
Jim
If you’re providing 5V power and ground and have dm/dp wired up right, it should work.
But it’s easy to make a mistake when doing a custom setup. A lot easier with the eval board and USB adapter.
Don’t think the crystal is an issue but not 100% on that.
Also dm and dp wires need to be short if not on a pcb …
Ah ha, that could be the problem! Will work on that next.
Jim
Turns out there's a pretty big bug with the keyboard handling: it expects the report to have all the pressed keys left-aligned. This isn't actually what happens, at least with my PS/2 adapter. That keeps a key in the slot that was the first free one when it got pressed. So if you press X, press Y, then release X, then press X again, you'll get "XYXY" (extra Y press because it thought that all keys were released when only Y was pressed)
Tried this keyboard with garryj's newest driver, but keyboard/mouse not found at any ClkFreq...
https://tindie.com/products/arturo182/bb-q20-keyboard-with-trackpad-usbi2cpmod/#specs
Docs: https://solder.party/docs/bbq20kbd/
It would be a nice, small keyboard with mouse for P2s...
The creator is available on Discord https://discord.com/channels/715539174857375774/715539175335657573 for discussion...
Can you try this driver from the USB Gamepad thread ?
Otherwise, if you can capture the usb descriptor (raw hex dump, if possible), I can look at it.
EDIT
That gives me keyboard support!
The optical mouse still does not work:
How do I dump the USB descriptor?
Good, attached is a version of the driver that dumps the configuration descriptor bytes, enable debug and you should see a line with:
Cog1 hconfig_base = and a list of hex bytes.
This should give more informations about how the devices are configured (and maybe explains why it notifies the keyboad activity as gamepad...)
Edit: because the keyboard isn't recognized! It is detected as an unsupported gamepad which sends the report packets anyway...
Ok, I think I see how it works. The device identifies itself as generic HID (not keyboard or mouse specific), the driver detects this as a Gamepad, however the report descriptor sets the usage as keyboard (and I guess as mouse for the other interface) but is ignored, that's why it reports unsupported gamepad.
The driver should be modified to detect the keyboard/mouse setting in the report and enable the keboard and/or mouse support.
A bit complicated, but doable.
More info (from: USB Descriptor and Request Parser)
Seems this is much more complicated than expected.
I assumed to be able to test using a normal keyboard because it can operate with both boot and report protocols but for some reasons this doesn't work, I guess there is something else to do other than using the right interface.
The driver then needs some bigger change to be able to handle more than one device with the hid report interface.
At this time, the quickest way is ask the firmware author to implement the boot protocol for both keyboard and mouse interfaces (or implement yourself if you have familiarity with the Pi Pico SDK), AFAIK it is just a matter of setting the correct hid class/subclass/protocol values.
From the instruction:
Connect the keyboard to a P2 using this I2C may be the simplest possible way to use it.
Yeah, but having a small plug-and-play solution, using USB seemed the goal.