Shop Learn
P2 Hosted USB Keyboard/Mouse - Page 6 — Parallax Forums

P2 Hosted USB Keyboard/Mouse

12346»

Comments

  • JRetSapDoogJRetSapDoog Posts: 880
    edited 2021-03-01 09:06

    That's interesting/good to know. In that case, perhaps that keyboard might work with the P2 if garryj is able to (make time to) get the hub-compatible version fully working. I presume that one would hook up a hub (such as a four-port hub) to one instance of such a driver through one port. That presumably would take one cog and just two or three pins (I would assume three pins, including an Event Repository pin, unless garryj says otherwise). But that's down the road, if it happens at all (it's apparently quite tricky to integrate the low-speed stuff with the more straightforward high-speed stuff, I believe garryj said).

    Personally, I'd be thrilled with a non-hub version that could talk to multiple physical ports using just a single cog, with each physical port taking two or three pins, of course. But I have no real idea if that is possible. I believe that garryj has said that the current driver needs a minimum clock of somewhere between 80-95 MHz to work with full-speed stuff. Meeting the timing requirements seems to be the limiting factor. But if such a version were possible, it would be quite useful and avoid needing to dangle a hub off of a port. If cog or lut memory were tight, I'd be happy with just a keyboard- or mouse-only version of such a driver. But again, I have no idea if it is possible. Hmm, on second thought, I'm pretty sure that it must be "impossible." ;)

  • JRetSapDoogJRetSapDoog Posts: 880
    edited 2021-03-01 08:23

    @Cluso99, thanks! I do recall that somewhere you mentioned placing vsync on the pin just below hsync. I'm glad that we can do this, but if I do another version of my current board, I think I'll place vsync after the red signal and also start my hsync on pin 0 of an eight-pin group instead of pin 4, as that appears to be more "standard" with what others are doing here and will save me from having to edit other people's code (even though such edits are straightforward). Plus, I always worry that someone will write a driver that requires the pins to be in a specific order in terms of vsync (of course, hsync and blue, green and red are already in a "standardized" order). That's less likely to happen for VGA, though, as there are "only" four DAC's for a cog, so the slower vsync signal has to be handled by an ordinary pin on either side elsewhere, I meant, of a four-pin group, which would "naturally" place it just above (or just below) the four DAC-driven signals. Also, if anyone else used my board, they also wouldn't have to modify any code. I guess you could call it "going with the flow." Anyway, as I mentioned, I'm happy that garryj's USB pin usage can tuck right in beside the VGA signals. That worked out just fine. Edit: Initially, I psychologically liked keeping hsync and vsync together, but that doesn't really matter. Well, it could from a routing standpoint, I suppose, but it didn't matter in my case.

  • roglohrogloh Posts: 3,297

    @JRetSapDoog You can always try to use 4 pin VGA to help save a pin. eg. Composite H+V syncs on the one pin (75ohm), my video driver supports this as well as a Sync-on-Green mode with 3 VGA pins. Many monitors support these too although 5 pin VGA is of course more universal (RGBHV). Plus with the P2 the VSync output can be located on any pin, nothing special about it. In general it's best to have HSync on the base pin of each nibble so the P2's internal colourspace HW can utilize it, though if you write your own custom driver it's likely possible to bit bang it elsewhere as well (with extra care to keep synced to the streamer if that is used).

  • @Clusso99, by the way, I'm sure that you know that in garryj's latest version of his driver, he has the LED status pin using the same pin that serves as an Event Repository. So one kind of gets the LED status functionality at no additional cost, as it used to be on a separate pin, at least if I've followed his comments and this thread correctly. But I haven't yet hooked up an LED and resistor yet to watch it show the status. Maybe I should just to confirm that it works. Anyway, are you saying that, just as garryj sort of double uses the pin (the smart pin half and the physical pin half) to do both event storage and driving the LED, that the LED functionality could be sacrificed and the physical pin used for other things if the associated code driving the LED was ripped out (while still retaining the Event Repository functionality)? Is that what you did/mean? If so, that could come in handy.

  • JRetSapDoogJRetSapDoog Posts: 880
    edited 2021-03-01 08:30

    @rogloh, thanks for that info. Those are a couple of possibilities. Quite a while back, I did locate a very long datasheet for the chip that the driver board in my setup uses. And I seem to recall it mentioning something about sync-on-green (SoG), but I don't think I ever fully understood it and the size of that data sheet unnerved me (I think that it was at least a hundred pages with a ton of setup registers, etc.). Edit: The firmware of the chip is actually alterable if one has the right software tool. Another thing that dissuaded me was that using such functionality might make it more troublesome for me (or possibly someone else) to use other people's drivers.

    About the h, b, g, r pin order, I believe that it was you that originally explained the colourspace advantages of this "standardized" order to me (and pointed out that this order was the one that Chip was using). Thanks so much. And while it may be possible to alter that order (if not using the colourspace HW, I suppose), I don't think a person at my low "pay grade" should do so. I already tend to make things "funky" enough as it is. Nevertheless, I'll keep it (and especially composite sync and SoG) in the back of my mind (coz never say never), and it's really great that you were able to integrate that extra sync functionality into your amazingly versatile driver (which I routinely followed, even if much of it was over my head). You've got everything in there but the kitchen sink. Well, maybe that, too. I forget if you have mouse cursor capability in there, but I wouldn't be surprised. If so, maybe garryj's driver can be used to provide it with the x-y data through an intermediary. (And notice how I brought my comment back to USB stuff to keep it on topic? Well, I tried, anyway.)

  • roglohrogloh Posts: 3,297

    @JRetSapDoog said:
    I forget if you have mouse cursor capability in there, but I wouldn't be surprised. If so, maybe garryj's driver can be used to provide it with the x-y data through an intermediary. (And notice how I brought my comment back to USB stuff to keep it on topic? Well, I tried, anyway.)

    Yes a USB mouse works nicely with the sprite cursor position in the driver. It's designed for that. A simple long update with X,Y values and it will follow the mouse co-ordinates, though it does need scaling to the graphics resolution. Just a few lines of SPIN2 or PASM, it's very simple and very responsive, as it is drawn directly into the line buffer for you.

  • Very nice, indeed. I figured that you'd do it on the fly (or effectively so), like a sprite.

  • RaymanRayman Posts: 12,027

    @JRetSapDoog I also had trouble with that event pin stomping on something when not using the Parallax USB adapter...
    I tweaked the Start() function a bit to stop that and also have it automatically update cursor position and key report like this:

    PUB start(base_pin, enable_pin, dm_pin, err_led_pin) : cog
    'RJA:  Adding handling of mouse data to this driver
    'RJA:  Adding explicit enable pin that can be set to -1 to not use
    'Setting pointers in assembly code before starting cog
        pMouseX:=@mouseGunk
        pMouseY:=@mouseGunk+4
        pMouseMaxX:=@mouseGunk+8
        pMouseMaxY:=@mouseGunk+12
        pMouseButtons:=@mouseGunk+16
        pKeyReport:= @pressedKeys
    
    'Enable USB power, if enable_pin>0
      if (enable_pin>0)
        pinh(enable_pin)
    

    So, you just set the enable_pin negative to not use it...

  • JRetSapDoogJRetSapDoog Posts: 880
    edited 2021-03-01 13:18

    Hi, Rayman. Thanks for that comment. I like your tweaked start() method. Yeah, that's a better (long-term) solution than just commenting that functionality out. By "...trouble with that event pin stomping on something...," I assume that you mean the "enable pin" instead of the "event pin" (both words start with an 'e'). Unless I missed something, that matches what you wrote subsequently. Anyway, I think that your tweaked method would make using the driver somewhat easier for a more casual user to use (and everyone, really). And maybe garryj will incorporate something like that in a subsequent release.

    As for how your accessing the mouse cursor coordinates and key states, I need to look at that further. But I think that I like the idea of putting such updating into the driver itself (with everything in one place). Currently, I'm using a modified version of one of garryj's demo programs as an intermediary between my top-level object and his USB driver. But why pay a middleman when you can buy direct from the factory? So I may change things later once I understand my options better. Thanks again for your comment.

  • Thanks for the comments and ideas, guys! I've been trying to focus on the hub-aware version, as I think it may offer the most bang for the buck, and should be much more friendly to two and three pin setups. The only hard rule is that the D- pin# must be an even numbered pin and the D+ pin# must be D- + 1.

    When used as a host only, it should behave the same as the current single port version does, for low and full speed devices. If a hub is connected, it will initially support up to four ports. The first iteration will be limited to full-speed capable devices via hub, with (hopefully) low-speed devices via hub coming later.

    As far as hubs go, USB 1.1 and 2.x versions work the best, but the two 3.x hubs I have are pretty finicky.

  • RaymanRayman Posts: 12,027

    Wow, you actually have USB hub working? That's impressive. Still in just one cog?
    Aren't most things full-speed at least now? I'm trying to remember what might be low speed only...

  • JRetSapDoogJRetSapDoog Posts: 880
    edited 2021-03-05 08:34

    Yes, it would be really swell to have hub compatibility. About the number of cogs for a hub-capable USB host driver, the goal appears to be one cog. Gary has stated:

    "A USB hub driver has been on my todo list for quite a while..... 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." [thread pg. 1]

    "I'm still (very slowly) working on a hub-capable version which works with one USB cog. The host is freed from some of the the device connect/disconnect load that is handled by the hub. I have full-speed boot protocol keyboard/mouse working fairly well with up to four ports. Low-speed devices via hub has been a tougher nut to crack...." [thread pg. 5]

    I wonder how many keyboards and mice are full speed as opposed to low speed. On Wikipedia's entry on the old PS/2 port, I found this about mice sampling/polling: "Both PS/2 and USB allow the sample rate to be overridden, with PS/2 supporting a sampling rate of up to 200 Hz[2] and USB supporting a polling rate up to 1 kHz as long as the mouse runs at full-speed USB speeds or higher." (emphasis added) So, I'd imagine that gaming mice are full-speed devices, but don't know about regular mice (or keyboards).

    Offhand, I forget if the current USB host driver provides a way to report whether a device is connected at LS or FS. I seem to recall something about the DM and DP lines being used differently depending on the device speed.

  • evanhevanh Posts: 11,042
    edited 2021-03-06 05:08

    Plugging in USB things to desktop box ...
    1st mouse = 12 Mb/s
    2nd keyboard (only one USB) = 1.5 Mb/s
    Prop2 = 12 Mb/s
    2nd mouse = 1.5 Mb/s
    3rd mouse 1.5 Mb/s
    USB2 hub (it's actually USB3, shows up as two hubs) = 480 Mb/s
    4th mouse = 1.5 Mb/s
    Combo mouse+keypad = 1.5 Mb/s

  • JRetSapDoogJRetSapDoog Posts: 880
    edited 2021-03-06 10:20

    Thanks, evanh. So, including the combo device, that's one full-speed mouse and four low-speed mice, plus two low-speed keyboards. That's six out of seven devices that are low-speed ones. Following your lead, I tried checking the connection speeds of a keyboard and a couple of mice under the Device Manager of Windows 10, but I didn't see anything that told me the connection speed (1.5 or 12 Mb/s). Under Properties and Details and Properties again, there were several dozen little reports with various bits of info, but I didn't see anything that gave the connection speed. Maybe I missed it. Anyway, with so many keyboards and mice apparently being low speed (1.5 Mb/s) devices, it sounds like they wouldn't work with a hub-compatible P2 host driver that only worked with full-speed devices. Or am I missing something? But even if that's right, if such a driver does get released, perhaps a subsequent version could add support for low-speed devices. But we'll gladly and appreciatively take whatever we can get, of course.

  • evanhevanh Posts: 11,042
    edited 2021-03-06 09:07

    @JRetSapDoog said:
    Thanks, evanh. So, including the combo device, that's one full-speed mouse and four low-speed mice, plus two low-speed keyboards. That's six out of seven devices that are low-speed ones.

    Err, I misled you a little it seems, my main keyboard is an old PS/2. The listed keyboard is the sole USB keyboard I have.

    Following your lead, I tried checking the connection speeds of a keyboard and a couple of mice under the Device Manager of Windows 10, but I didn't see anything that told me the connection speed (1.5 or 12 Mb/s). Under Properties and Details and Properties again, there were several dozen little reports with various bits of info, but I didn't see anything that gave the connection speed. Maybe I missed it.

    I'm using the KDE Info Centre that comes with the Kubuntu distro. It in turn will be probing the Linux /proc (or /sys I keep forgetting which) structures I presume.

    Anyway, with so many keyboards and mice apparently being low speed (1.5 Mb/s) devices, it sounds like they wouldn't work with a hub-compatible P2 host driver that only worked with full-speed devices. Or am I missing something? But even if that's right, if such a driver does get released, perhaps a subsequent version could add support for low-speed devices. But we'll gladly and appreciatively take whatever we can get, of course.

    I haven't been reading all that closely. But I have faith in Garry anyway. :)

  • JRetSapDoogJRetSapDoog Posts: 880
    edited 2021-03-06 10:17

    Ah, sorry about that. Anyway, Garry has surprised himself, I think, by what's possible in/with one cog (with a competent and dedicated code warrior, I mean). One limiting factor, though, is finding the time. So we'll (and by "we'll" I mean "I'll) have to be patient.

  • For reference, here's a link to a Hackaday announcement about a project in which Dmitry Samsonov is doing a USB host that allows "for four USB 1.1 devices to be connected directly to the ESP32 without a separate dedicated chip." Don't know if he has implemented a hub or whether he can handle four separate ports with one instance (perhaps the latter from the picture?). Dmitry has responded to the announcement in the comments. Anyway, posting here for what it's worth.

Sign In or Register to comment.