I'm looking for any version of the 1CogKbM driver that works with any version of a Spin2 compiler. Can anyone point me to a combination of driver and compiler that works together? I've tried every combination I can find, and by messing around with the code I can usually make it compile, and (usually) get the start-up banner to appear -so I know it is compiling, loading and executing. But none of my attempts seem to get any further. And Spin2 does my head in
I'm using a P2 Eval board, which I know used to work with this driver, but I can't seem to find the right combination of driver version and Spin2 compiler any more.
USBNew is good. I mainly use it for game controllers.
For keyboards and mice, still using a modification of the old version...
There are variations on this that let you not use the enable pin and not use the LED pin...
CON 'USB mouse pin settings --> Set USB keyboard basepin here!
USB_BASE_PIN =24'16'24'16'24'16 'led for USB activity
USB_ENABLE_PIN =USB_BASE_PIN+1 'Parallax adapter uses this to control USB power (can be -1 to disable)
USB_DM_PIN =USB_BASE_PIN+2 'upper port on Parallax 2 port adapter
USB_ERR_LED_PIN =USB_BASE_PIN+0 'Need to update USB driver so this can be ignored...
var 'USB kbm vars
long mx,my,MaxX,MaxY,buttons,scan1,scan2 'leave these together in this order
'Start keyboard
'Start up USB
kbm.Start(USB_BASE_PIN, USB_ENABLE_PIN, USB_DM_PIN, USB_ERR_LED_PIN, @mx)
'Wait for keypress
repeat until scan1
@RossH said:
I'm looking for any version of the 1CogKbM driver that works with any version of a Spin2 compiler. Can anyone point me to a combination of driver and compiler that works together? I've tried every combination I can find, and by messing around with the code I can usually make it compile, and (usually) get the start-up banner to appear -so I know it is compiling, loading and executing. But none of my attempts seem to get any further. And Spin2 does my head in
I'm using a P2 Eval board, which I know used to work with this driver, but I can't seem to find the right combination of driver version and Spin2 compiler any more.
If it compiles and load but doesn't work maybe is some settings, like pin numbers, clock settings, etc. ?
The original 1CogKbM driver doesn't support hubs.
Anyway, the usb driver I have on my Github repository https://github.com/maccasoft/P2/blob/master/usb.spin2 is PASM-only so it is compiler-independent, it doesn't have a Spin interface, you need to compile and run with debug to see activity from connected devices.
Other versions, like Ada's usbnew have a lot of preprocessor statements that are not compatible with either PNut or Spin Tools.
Anyway, the usb driver I have on my Github repository https://github.com/maccasoft/P2/blob/master/usb.spin2 is PASM-only so it is compiler-independent, it doesn't have a Spin interface, you need to compile and run with debug to see activity from connected devices.
Aha! Bingo! Thanks very much!
I already have an older version of this driver included as part of Catalina - but I discovered a few days ago that while my version works ok with hardwired keyboards, it no longer works with any of the the hardwired mice I have on hand.
Your program confirmed that it is my mice that are the problem. The driver seems to support only a limited range of hardwired mice, and I had apparently replaced all my hardwired mice (which used to work) with ones that the 1CogKbM driver does not support - but I did not realize this until a few days ago.
Both your driver and mine still work with my wireless mouse and keyboard, so at least I now know the problem is with the driver, and is not something I broke in my version (which was what I had feared!).
Not sure how to fix the driver so it supports a wider variety of hardwired mice yet - but your "standalone" driver is sure to be a great help!
@RossH said:
Your program confirmed that it is my mice that are the problem. The driver seems to support only a limited range of hardwired mice, and I had apparently replaced all my hardwired mice (which used to work) with ones that the 1CogKbM driver does not support - but I did not realize this until a few days ago.
Both your driver and mine still work with my wireless mouse and keyboard, so at least I now know the problem is with the driver, and is not something I broke in my version (which was what I had feared!).
Not sure how to fix the driver so it supports a wider variety of hardwired mice yet - but your "standalone" driver is sure to be a great help!
Take a look at usbnew linked above and follow the MOUSE_FULL_PROTOCOL defines, could be that you mice doesn't support the BOOT protocol.
I think I found the problem, but I'm not sure if my fix is correct.
The usb.spin2 code works with a wireless combo keyboard/mouse, and also with just a hardwired keyboard, but not with just a hardwired mouse.
To make it work with all of these I commented out lines 1826 - 1834 - e.g. replace them with:
{
cmp hkbd_ep_addr, #0 wz ' A SetIdle() duration of indefinite covers both keyboard and mouse
if_nz jmp #.skip ' So skip if it has already been done
mov hpar1, #0 ' SetIdle() duration 0 = indefinite
getbyte hpar2, kb_intf_num, #0
call #hset_idle
cmp retval, #PID_ACK wz
if_nz mov hmouse_ep_addr, #0
if_nz jmp #.notify_client
.skip
}
The code appears to be assuming that it can set the keyboard idle even when there is no actual keyboard - just a mouse. If I let it do this, I get a PID_STALL response and the mouse stays unrecognized.
I think I found the problem, but I'm not sure if my fix is correct.
The usb.spin2 code works with a wireless combo keyboard/mouse, and also with just a hardwired keyboard, but not with just a hardwired mouse.
To make it work with all of these I commented out lines 1826 - 1834 - e.g. replace them with:
The code appears to be assuming that it can set the keyboard idle even when there is no actual keyboard - just a mouse. If I let it do this, I get a PID_STALL response and the mouse stays unrecognized.
However I think there is an error because it uses kb_intf_num while it should use ms_intf_num.
I'm not sure if this has some effects on combo keyboard+mouse.
Maybe try to replace getbyte hpar2, kb_intf_num, #0 with getbyte hpar2, ms_intf_num, #0 and see if it works with a mouse only, a keyboard and mouse (not combo) and a combo keyboard+mouse.
If doesn't work just comment the return code check, I don't think this is so important to invalidate the device found.
Maybe try to replace getbyte hpar2, kb_intf_num, #0 with getbyte hpar2, ms_intf_num, #0 and see if it works with a mouse only, a keyboard and mouse (not combo) and a combo keyboard+mouse.
If doesn't work just comment the return code check, I don't think this is so important to invalidate the device found.
Neither of those work with my hardwired mouse. It seems to be the call the hset_idle that is the problem, with either ms_intf_numorkb_intf_num.
@RossH said:
Neither of those work with my hardwired mouse. It seems to be the call the hset_idle that is the problem, with either ms_intf_numorkb_intf_num.
I did a couple of quick tests and seems there are some weird issues depending on the mouse. I have an old Kraun mouse that works without problems, and a RaspberryPi mouse that causes the code to loop forever reinitializing the device, commenting the call to hset_idle it works well. Seems to have the same issue with usbnew.
I guess commenting the whole idle code set for the mouse is good for now, until someone finds a better fix.
Comments
I'm looking for any version of the 1CogKbM driver that works with any version of a Spin2 compiler. Can anyone point me to a combination of driver and compiler that works together? I've tried every combination I can find, and by messing around with the code I can usually make it compile, and (usually) get the start-up banner to appear -so I know it is compiling, loading and executing. But none of my attempts seem to get any further. And Spin2 does my head in
I'm using a P2 Eval board, which I know used to work with this driver, but I can't seem to find the right combination of driver version and Spin2 compiler any more.
Any assistance would be appreciated.
Ross.
Try this - https://forums.parallax.com/discussion/comment/1566322/#Comment_1566322
USBNew is good. I mainly use it for game controllers.
For keyboards and mice, still using a modification of the old version...
There are variations on this that let you not use the enable pin and not use the LED pin...
'Start keyboard 'Start up USB kbm.Start(USB_BASE_PIN, USB_ENABLE_PIN, USB_DM_PIN, USB_ERR_LED_PIN, @mx) 'Wait for keypress repeat until scan1If it compiles and load but doesn't work maybe is some settings, like pin numbers, clock settings, etc. ?
The original 1CogKbM driver doesn't support hubs.
Anyway, the usb driver I have on my Github repository https://github.com/maccasoft/P2/blob/master/usb.spin2 is PASM-only so it is compiler-independent, it doesn't have a Spin interface, you need to compile and run with debug to see activity from connected devices.
Other versions, like Ada's usbnew have a lot of preprocessor statements that are not compatible with either PNut or Spin Tools.
Hope this helps.
Aha! Bingo! Thanks very much!
I already have an older version of this driver included as part of Catalina - but I discovered a few days ago that while my version works ok with hardwired keyboards, it no longer works with any of the the hardwired mice I have on hand.
Your program confirmed that it is my mice that are the problem. The driver seems to support only a limited range of hardwired mice, and I had apparently replaced all my hardwired mice (which used to work) with ones that the 1CogKbM driver does not support - but I did not realize this until a few days ago.
Both your driver and mine still work with my wireless mouse and keyboard, so at least I now know the problem is with the driver, and is not something I broke in my version (which was what I had feared!).
Not sure how to fix the driver so it supports a wider variety of hardwired mice yet - but your "standalone" driver is sure to be a great help!
Ross.
Take a look at usbnew linked above and follow the MOUSE_FULL_PROTOCOL defines, could be that you mice doesn't support the BOOT protocol.
@macca
I think I found the problem, but I'm not sure if my fix is correct.
The usb.spin2 code works with a wireless combo keyboard/mouse, and also with just a hardwired keyboard, but not with just a hardwired mouse.
To make it work with all of these I commented out lines 1826 - 1834 - e.g. replace them with:
{ cmp hkbd_ep_addr, #0 wz ' A SetIdle() duration of indefinite covers both keyboard and mouse if_nz jmp #.skip ' So skip if it has already been done mov hpar1, #0 ' SetIdle() duration 0 = indefinite getbyte hpar2, kb_intf_num, #0 call #hset_idle cmp retval, #PID_ACK wz if_nz mov hmouse_ep_addr, #0 if_nz jmp #.notify_client .skip }The code appears to be assuming that it can set the keyboard idle even when there is no actual keyboard - just a mouse. If I let it do this, I get a PID_STALL response and the mouse stays unrecognized.
Is there a better solution?
Ross.
Usbnew simply ignores the return from hset_idle:
getbyte hpar2, kb_intf_num, #0 call #hset_idle 'cmp retval, #PID_ACK wz 'if_nz mov hkbd_ep_addr, #0 'if_nz jmp #.notify_client mov hctwait, _2ms_ call #poll_waitxHowever I think there is an error because it uses kb_intf_num while it should use ms_intf_num.
I'm not sure if this has some effects on combo keyboard+mouse.
Maybe try to replace
getbyte hpar2, kb_intf_num, #0withgetbyte hpar2, ms_intf_num, #0and see if it works with a mouse only, a keyboard and mouse (not combo) and a combo keyboard+mouse.If doesn't work just comment the return code check, I don't think this is so important to invalidate the device found.
Neither of those work with my hardwired mouse. It seems to be the call the hset_idle that is the problem, with either ms_intf_num or kb_intf_num.
Ross.
I did a couple of quick tests and seems there are some weird issues depending on the mouse. I have an old Kraun mouse that works without problems, and a RaspberryPi mouse that causes the code to loop forever reinitializing the device, commenting the call to hset_idle it works well. Seems to have the same issue with usbnew.
I guess commenting the whole idle code set for the mouse is good for now, until someone finds a better fix.
Yes, that's what I'll do. Thanks.