The KbMObjDemos_v0_1_4.zip package has been added to the first post of this discussion. It includes the latest USB host + "boot protocol" keyboard/mouse driver P2 object. The zip package includes three clients that offer differing binary footprints. The README.md file in the zip describes the features and changes.
@rogloh, my apologies for taking so long to get this out.
Thanks garryj.
No problem, I've been busy on my own drivers lately myself. But this will certainly get used by me soon enough now there is the ability to run with different frequencies and pins etc.
Will this driver be able to (eventually) support USB ports on P2's that are not layed out the same as the P2-EVAL USB add-on boards? I only had a breif look, and just noticed this information below for the start method. In some hardware implementations like P2D2 etc, they may desire different mappings and only might want to use 2 or 3 USB pins perhaps, not all 4 pins in a block etc. Is that going to be possible one day too? What are the actual pin restrictions? We already know the USB D+/D- need to be pair, but can any of the other pins like LED status and protection etc be made optional or configurable on arbitrary pins? I need to dig into that more.
'' Caller must define all I/O pins required by the USB host. This implementation
'' uses the Parallax P2 Eval "Serial Host" add-on board, which requires a
'' contiguous four-pin block starting at an even pin number. All host pin
'' assignments are configured in the "usb_host_init" code block.
'' Returns cog number, or -1 if cog not available.
Will this driver be able to (eventually) support USB ports on P2's that are not layed out the same as the P2-EVAL USB add-on boards? I only had a breif look, and just noticed this information below for the start method. In some hardware implementations like P2D2 etc, they may desire different mappings and only might want to use 2 or 3 USB pins perhaps, not all 4 pins in a block etc. Is that going to be possible one day too? What are the actual pin restrictions? We already know the USB D+/D- need to be pair, but can any of the other pins like LED status and protection etc be made optional or configurable on arbitrary pins? I need to dig into that more.
It should be pretty easy to do. Only d- and d+ have the even/odd restriction. The client can create constants that define an offset from "basepin" to target the other pins needed. There are cog registers for each of the pins, and all assignment is done within that "usb_host_init" pasm block.
In my brief look before it seemed a little non-obvious to find the exact demarcation between demo application and the underlying driver itself. So I just need a bit more time to try to figure it out.
For people who just use keyboard and mouse, it may be handy to have a small/simple SPIN object that sits between their applications and the USB driver so they don't need to deal with a lot of USB event stuff etc and can just read keys and mouse position etc. I sort of hacked up something I could start to use out of some code from your previous version that looked a bit like the P1 keyboard driver etc but I probably need to figure out something for the new one. One of the issues is the USB polling sort of needs another COG if you don't do it in your own application and that could become wasteful if you have multiple USB ports etc. This is why any future hub support could be quite good so you could potentially run a single USB driver COG for both keyboard and mouse USB transfers. I was happy to dedicate a COG to keep polling the mouse and capture keypresses etc as I found it could also be used to update the mouse sprite position too and made the overall UI response silky smooth.
Have you tried your USB driver with many other types of USB devices, or just the HID stuff?
For people who just use keyboard and mouse, it may be handy to have a small/simple SPIN object that sits between their applications and the USB driver so they don't need to deal with a lot of USB event stuff etc and can just read keys and mouse position etc. I sort of hacked up something I could start to use out of some code from your previous version that looked a bit like the P1 keyboard driver etc but I probably need to figure out something for the new one. One of the issues is the USB polling sort of needs another COG if you don't do it in your own application and that could become wasteful if you have multiple USB ports etc. This is why any future hub support could be quite good so you could potentially run a single USB driver COG for both keyboard and mouse USB transfers. I was happy to dedicate a COG to keep polling the mouse and capture keypresses etc as I found it could also be used to update the mouse sprite position too and made the overall UI response silky smooth.
What you're describing is pretty much what the "demos" are meant to be. They are basically very simple class drivers, not designed to be a top object in the real world. What's not yet implemented is a ton of functionality to make use of the keyboard/mouse data that's coming from the USB. There are many more keyboard/mouse focused events that need to be made available. I've been thinking about using method pointers to have some kind of callback based way for a client to have access to, for example, mouse button events. In other words, some sort of API...
Have you tried your USB driver with many other types of USB devices, or just the HID stuff?
Just about any low-speed/full-speed device plugged in will enumerate, but will end up with a "no keyboard/mouse device found" message. The devices are easy to talk to, but implementing what it is that they do is the real challenge.
In my brief look before it seemed a little non-obvious to find the exact demarcation between demo application and the underlying driver itself. So I just need a bit more time to try to figure it out.
For people who just use keyboard and mouse, it may be handy to have a small/simple SPIN object that sits between their applications and the USB driver so they don't need to deal with a lot of USB event stuff etc and can just read keys and mouse position etc. I sort of hacked up something I could start to use out of some code from your previous version that looked a bit like the P1 keyboard driver etc but I probably need to figure out something for the new one. One of the issues is the USB polling sort of needs another COG if you don't do it in your own application and that could become wasteful if you have multiple USB ports etc. This is why any future hub support could be quite good so you could potentially run a single USB driver COG for both keyboard and mouse USB transfers. I was happy to dedicate a COG to keep polling the mouse and capture keypresses etc as I found it could also be used to update the mouse sprite position too and made the overall UI response silky smooth.
This is exactly what Catalina does. It has a HMI plugin that decodes the USB events, and simulates the "old" (P1-style) keyboard and mouse interfaces. It even returns (mostly) the same keycodes as the old P1 keyboard drivers did.
If you are interested, check out "Catalina_HMI_Plugin_VGA.Spin2" in Catalina's "target_p2" subdirectory. This same plugin also handles the VGA interface, but it would be fairly easy to just extract the keyboard/mouse code for use elsewhere.
Demo Client v0.1.4 + USB low/full speed keyboard/mouse
Sysclock: 180000000, Clkmode: $10008FB, Baud: 230400
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
PortB boot protocol keyboard/mouse not found
USB portA error 6: txn retries exceeded
Works great with inexpensive mini USB keyboard mouse!
But...
Neither of the RaspberryPi official keyboard or mouse works:
Demo Client v0.1.4 + USB low/full speed keyboard/mouse
Sysclock: 180000000, Clkmode: $10008FB, Baud: 230400
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
PortB boot protocol keyboard/mouse not found
USB portA error 6: txn retries exceeded
dgately
Is your terminal x-term? There are two other *.ans files that have different encodings. Give them a try to see if the image improves.
Yep, low cost generic devices tend to be the ones most likely to work. Bummer on the RaspberryPi official keyboard/mouse. The portB message "keyboard/mouse not found" means the driver was unable to find the "boot protocol" it was looking for. Since it was able to read the descriptor, it may be that "official Pi" devices may not publish that particular protocol as being available.
Seems that the code requires two extra pins below the D-/D+ pair. Definitely didn't realise this
However, works fine on my RetroBlade2 on either microUSB port. I will need to modify the code to use a different pair of control pins so I can use both ports. I have the D-/D+ pairs on pins 48/49 and 50/51. Pins 52/53 and 54/55 are free tho.
I think the extra pins are for use with the parallax usb accessory board. There’s a status led and a power enable pin, as I recall. Should be simple to comment out...
I think the extra pins are for use with the parallax usb accessory board. There’s a status led and a power enable pin, as I recall. Should be simple to comment out...
There is a pin used for signaling between cogs (and status LED) which is the first base pin. base+1 is the enable pin (used by the P2 host expansion pcb), D-/D+ are base+2/+3. P56 is used for usb error led for the first usb port, and P57 for the second usb port (if used).
I'm glad you guys have given it a go! My intent was to make the P2 Eval + USB add-on board as "plug and play" as possible. I hope the comments were clear enough to make it fairly easy to adapt to non-addon board situations. Any suggestions you may have that would make things smoother in this area are certainly welcome 👍.
If the format didn't change then there was a bug in the old version, I think...
Here's from the old version:
if usbcog
PINL(USB_EVENT_REPO) ' DIR bit low puts smart pin in reset mode
wrpin(SP_REPO1_MODE, USB_EVENT_REPO) ' Set "long repository" mode to act as an event mailbox
PINH(USB_EVENT_REPO) ' Enable the event mailbox smart pin (will raise IN)
The pinfield should come first, but it's second.
Looks like the new version has this in assembly...
I just tried this with a PS/2 to USB adapter. It has both a mouse and a keyboard socket, but I don't have a mouse on hand. The Keyboard portion seems to work, but only if I hotplug it into the P2. It doesn't work if it's already connected while loading the program. In that case it just gives me this and is unresponsive:
Mini Client + USB low/full speed keyboard/mouse v0.1.4
Sysclock: 180000000, Clkmode: $10008FB, Baud: 2000000
P2RevB+ detected, USB driver version v0.1.4
PortA started: cogID 1, event pin# 16
PortA btn: 00000001, X: 006, Y: 075
With games in mind, I've made a modified version of the driver that reports the current keycodes.
It's "1CogKbM_rja3b.spin2" and was posted with the Rogue for VGA code.
Basically, it's a list of all the currently pressed keys...
It's also used with the tetris code, but was not implemented correctly... (Have to fix that...)
@Wuerfel_21 said:
I just tried this with a PS/2 to USB adapter. It has both a mouse and a keyboard socket, but I don't have a mouse on hand. The Keyboard portion seems to work, but only if I hotplug it into the P2. It doesn't work if it's already connected while loading the program. In that case it just gives me this and is unresponsive:
Mini Client + USB low/full speed keyboard/mouse v0.1.4
Sysclock: 180000000, Clkmode: $10008FB, Baud: 2000000
P2RevB+ detected, USB driver version v0.1.4
PortA started: cogID 1, event pin# 16
PortA btn: 00000001, X: 006, Y: 075
I haven't done any testing with a PS/2 to USB adapter. During device enumeration, the driver searches for an HID "boot protocol" descriptor. If one is not found, or does not comply with the USB HID definition for this protocol, things will go south quickly. Since it does work when hot-plugged, it sounds like the boot protocol is there, but there may be something going bonkers when the adapter is first probed. I have a PS/2 keyboard, so I'll get an adapter and see what I can find.
Just picked up one that looks to be a clone to yours. I'm lucky to be about 15 minutes away from Vetco Electronics: https://vetco.net which has all kinds of interesting "retro" stuff 😃. I'll have to diff Ray's version to see what pops up.
I don't remember changing anything that could affect this... All I did was add some code to automatically update mouse location and then also the keyboard scan codes.
I may have slowed things down a hair though by doing this...
Garryj, at this point in time, do you see any tight spots in doing 12 Mbaud USB, or any ambiguities due to how the smart pin USB hardware works? Is there anything that seems hard to get certain control of? Do you feel like it's possible to do USB perfectly?
Comments
Thanks garryj.
No problem, I've been busy on my own drivers lately myself. But this will certainly get used by me soon enough now there is the ability to run with different frequencies and pins etc.
Will this driver be able to (eventually) support USB ports on P2's that are not layed out the same as the P2-EVAL USB add-on boards? I only had a breif look, and just noticed this information below for the start method. In some hardware implementations like P2D2 etc, they may desire different mappings and only might want to use 2 or 3 USB pins perhaps, not all 4 pins in a block etc. Is that going to be possible one day too? What are the actual pin restrictions? We already know the USB D+/D- need to be pair, but can any of the other pins like LED status and protection etc be made optional or configurable on arbitrary pins? I need to dig into that more.
In my brief look before it seemed a little non-obvious to find the exact demarcation between demo application and the underlying driver itself. So I just need a bit more time to try to figure it out.
For people who just use keyboard and mouse, it may be handy to have a small/simple SPIN object that sits between their applications and the USB driver so they don't need to deal with a lot of USB event stuff etc and can just read keys and mouse position etc. I sort of hacked up something I could start to use out of some code from your previous version that looked a bit like the P1 keyboard driver etc but I probably need to figure out something for the new one. One of the issues is the USB polling sort of needs another COG if you don't do it in your own application and that could become wasteful if you have multiple USB ports etc. This is why any future hub support could be quite good so you could potentially run a single USB driver COG for both keyboard and mouse USB transfers. I was happy to dedicate a COG to keep polling the mouse and capture keypresses etc as I found it could also be used to update the mouse sprite position too and made the overall UI response silky smooth.
Have you tried your USB driver with many other types of USB devices, or just the HID stuff?
This is exactly what Catalina does. It has a HMI plugin that decodes the USB events, and simulates the "old" (P1-style) keyboard and mouse interfaces. It even returns (mostly) the same keycodes as the old P1 keyboard drivers did.
If you are interested, check out "Catalina_HMI_Plugin_VGA.Spin2" in Catalina's "target_p2" subdirectory. This same plugin also handles the VGA interface, but it would be fairly easy to just extract the keyboard/mouse code for use elsewhere.
Ross.
Works great with inexpensive mini USB keyboard mouse!
But...
Neither of the RaspberryPi official keyboard or mouse works:
https://raspberrypi.org/products/raspberry-pi-keyboard-and-hub/
https://raspberrypi.org/products/raspberry-pi-mouse/
dgately
Yep, low cost generic devices tend to be the ones most likely to work. Bummer on the RaspberryPi official keyboard/mouse. The portB message "keyboard/mouse not found" means the driver was unable to find the "boot protocol" it was looking for. Since it was able to read the descriptor, it may be that "official Pi" devices may not publish that particular protocol as being available.
However, works fine on my RetroBlade2 on either microUSB port. I will need to modify the code to use a different pair of control pins so I can use both ports. I have the D-/D+ pairs on pins 48/49 and 50/51. Pins 52/53 and 54/55 are free tho.
Many thanks Garry for making the USB object(s)
Was working fine, until it clobbered I/O pin #2...
Took me a while to figure it out, but:
got changed to:
There must have been a reversal in the order of arguments at some point because the second version has the arguments in the wrong order...
Guess I should upgrade to 2020 version at some point...
Mike
changed to
wrpin
If the format didn't change then there was a bug in the old version, I think...
Here's from the old version:
if usbcog PINL(USB_EVENT_REPO) ' DIR bit low puts smart pin in reset mode wrpin(SP_REPO1_MODE, USB_EVENT_REPO) ' Set "long repository" mode to act as an event mailbox PINH(USB_EVENT_REPO) ' Enable the event mailbox smart pin (will raise IN)The pinfield should come first, but it's second.
Looks like the new version has this in assembly...
I just tried this with a PS/2 to USB adapter. It has both a mouse and a keyboard socket, but I don't have a mouse on hand. The Keyboard portion seems to work, but only if I hotplug it into the P2. It doesn't work if it's already connected while loading the program. In that case it just gives me this and is unresponsive:
Also, is it just me or is there no way to get the current state of a particular key?
With games in mind, I've made a modified version of the driver that reports the current keycodes.
It's "1CogKbM_rja3b.spin2" and was posted with the Rogue for VGA code.
Basically, it's a list of all the currently pressed keys...
It's also used with the tetris code, but was not implemented correctly... (Have to fix that...)
@Rayman
Thanks, that one even seems to detect the keyboard right away. Do you know how would I read the state of modifier keys with this?
If I remember correctly what it returns is the actual scancodes for the keys. Just have to look up the scancodes for modifier keys I think...
The modifiers don't have scancodes, they have their own bits in the keyboard readout
Right... Just looked and bits in the first byte are the modifiers. Second byte is always 0 and keys start at the third byte.
Jup, just figured it out myself, too.
Many thanks, this is just what I need.
I haven't done any testing with a PS/2 to USB adapter. During device enumeration, the driver searches for an HID "boot protocol" descriptor. If one is not found, or does not comply with the USB HID definition for this protocol, things will go south quickly. Since it does work when hot-plugged, it sounds like the boot protocol is there, but there may be something going bonkers when the adapter is first probed. I have a PS/2 keyboard, so I'll get an adapter and see what I can find.
Oddly enough, it works perfectly fine with Ray's modified object.
The one I have looks like this, if it helps:
Just picked up one that looks to be a clone to yours. I'm lucky to be about 15 minutes away from Vetco Electronics: https://vetco.net which has all kinds of interesting "retro" stuff 😃. I'll have to diff Ray's version to see what pops up.
I don't remember changing anything that could affect this... All I did was add some code to automatically update mouse location and then also the keyboard scan codes.
I may have slowed things down a hair though by doing this...
For reference, this is the further modified version that works perfectly for me right now.