Forum Rule: Always post complete source code & details to reproduce any issue!
Page 6 of 6 FirstFirst ... 4 5 6
Results 126 to 145 of 145

Thread: USB Host Mouse Driver

  1. #126
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,987
    I did a little experimenting with some of the extra keys on some of the keyboards. They generate different top level collections and the like.
    So I create a couple hid input classes:
    KeyboardPowerController - Power button(s)
    KeyboardConsumerController - Some of the controller keys like Calculator,

    Just experimenting: I have the Power one set an available where you can get a Buttons field that cooresponds to all of the buttons...

    Have the Consumer one work like main keyboard, where you can register a callback (actually two). It is interesting that some of the keyboards generate a push and release and others do not. I have an issue that I am assuming push/release as first keyboard had it...

    Also ran into issue with Logitech - that these HID top level reports are on the Interface for the Mouse. The Hid code right now calls hid_input_end for all top level report handlers for that interface regardless if it had anything to do with that top level report. So I was setting available on all three top level reports... Now each of them set a bit in their hid_input_begin method and only set available state in the hid_input_end if the begin was called...

    Again sort of experiment/WIP. But pushed up the current stuff in a new branch (based off of master) https://github.com/KurtE/USBHost_t36...r_special_keys

  2. #127
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,441
    @Kurt - can you remind me of what features (other than the vendor/product/serial strings) are on your HID-Device-API-Additions branch that I haven't yet merged?

  3. #128
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,987
    @Paul - I think that is mainly it. I have not tried everything yet, but I am... There were some differences in our Test program Mouse.ino, I added a few of them to my own new branch. Things like the keyboard callback printing out the OEM character and modifiers, so we can see what did not translate...

    Also there was a difference in checking to see if a device is connected or not to one of our objects. I had something like if (keyboard1.connected())... You have if (keyboard1) ...
    I would update mine to yours, but now working on different branch...

    I am having better luck with the keyboard - HID extras - Classes I mentioned in #126, I am now able to process a lot of the multimedia keys and power key... Again current stuff up in the branch I mentioned, but I now want to merge those two new classes into one... Maybe keyboardHIDExtras or some such name. At this point I prefer going with two classes in the user code versus trying to merge this new class with the Keyboard class and need something like multiple inheritance.

    So far I am processing top level collections (C0001 and 10080), Not sure yet if it would make sense to try some of the vendor specific ones like: (FF000001), which I think some keyboards support...
    Also currently Power comes back as you can check for connected, and then call for what buttons were pressed versus, the other keyboard stuff with callback... I want to unify. Not sure in this new call back if the call backs should be passed two variables (Top level usage #, button #) or should do like other places where we pass it as 32 bits with Usage as high word...

    I am also going to play with maybe adding the special keys mapping (F1-F12, HOME, END... ) to match the Arduino keyboard library... To see how well that would work.

  4. #129
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,441
    I personally want to work on serial devices next (cdc, ftdi, pl2303, ch340). There's also a contribution for ant wireless that I've been neglecting. That code is structured as a stand-alone project, so that one will involve substantial work on my part to integrate, which is the reason it's still sitting unmerged.

    Really, just wanted to make sure I didn't miss anything major before starting work on other stuff.

    While I'd really like a single easy-to-understand keyboard class, I agree the multiple inheritance stuff is probably a nightmare.

    On the strings, I want to explore packing them into a small, fixed-size buffer added to the device struct. They're already being read during the enumeration. I had planned to do this all along, but honestly just getting EHCI and the bare-bones enumeration working kinda burned me out for a while. This is one of many things I left undone.

  5. #130
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,441
    On the connected function, I really want to try to follow Arduino's API conventions, at least where we can. I believe I mentioned using the bool operator like usb serial does earlier on this thread, or maybe one of the others. Yeah, it's probably buried back in a ton of messages now.

  6. #131
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,987
    @Paul - Let me know what things I can help with.

    I agree with the connected vs the bool. Although I think it is more extended than if(Serial) in that the Serial is more like a one shot (I think) once set it stays set (at least used to...)

    I agree having some of the Serial devices like FTDI and cdc would be great. Which wireless?

    I will continue to play some with the Mouse/Keyboard/Joystick.... Would be nice to support XBox as well...

    As for Strings, I assumed that might be an option, that would make it a lot easier to use than having to have query functions that than have to wait for the USB transaction to happen...
    Was not sure if you would want to build it into each Device to always use or if you wanted maybe a constructor buffer parameter and/or a addBuffer() call that allowed you specify one. The issue would be timing... As you would have to have the buffer before the connection/claim code runs.

    Also not sure if my hack was sufficient to convert the Unicode to Ascii... Or if it needs to be more generic.

  7. #132
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,987
    @Paul (and others) - I updated the new branch https://github.com/KurtE/USBHost_t36...r_special_keys

    Right now it is one extra HID class... I added the top usage value as first parameter for callback. Appears to be working fine on most keyboards. Need to figure out a little more with MS combined keyboard I have.

    I also added maping of the keys like arrow/Fn/Home/end/Insert/Delete - to new defines. My new defines are in this library header file KEYD_UP, which has the same value as the KEY_UP_ARROW key for the Arduino keyboard library. I did not use their names as they have things like: KEY_F1, which is what they use for mapping. Where are cores3/keylayouts.h has this define of the actual keyboard scan values.

    Again may have to make small mods to handle MS keyboard correctly. Might be interesting to see how it works with other keyboards. I have tried it so far on the 5 different keyboards I have.

    May also extend to other reports if needed, like a Dell multimedia keyboard many of the extra keys work, but not a knob...

  8. #133
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,987
    @paul (and everyone) - Put in a simple fix that appears to make my MS keyboard work better with the special keys.

    Also I updated the test program (Mouse - probably should rename) - that on normal keyboard characters and likewise for the Special HID class call back, I look up some of the Key codes and print out the logical name for the Key event:

    Example output for one of my Dell wired keyboards:
    Code:
    USB Host Testing
    key 'a'  97 MOD: 0 OEM: 4 LEDS: 0
    key 'b'  98 MOD: 0 OEM: 5 LEDS: 0
    key 'c'  99 MOD: 0 OEM: 6 LEDS: 0
    key 'd'  100 MOD: 0 OEM: 7 LEDS: 0
    key 'e'  101 MOD: 0 OEM: 8 LEDS: 0
    key 'f'  102 MOD: 0 OEM: 9 LEDS: 0
    key 'g'  103 MOD: 0 OEM: A LEDS: 0
    key 'A'  65 MOD: 0 OEM: 4 LEDS: 2
    key 'B'  66 MOD: 0 OEM: 5 LEDS: 2
    key 'C'  67 MOD: 0 OEM: 6 LEDS: 2
    key 'D'  68 MOD: 0 OEM: 7 LEDS: 2
    key 'F1'  194 MOD: 0 OEM: 3A LEDS: 0
    key 'F2'  195 MOD: 0 OEM: 3B LEDS: 0
    key 'F3'  196 MOD: 0 OEM: 3C LEDS: 0
    key 'F4'  197 MOD: 0 OEM: 3D LEDS: 0
    key 'F5'  198 MOD: 0 OEM: 3E LEDS: 0
    key 'F6'  199 MOD: 0 OEM: 3F LEDS: 0
    key 'F7'  200 MOD: 0 OEM: 40 LEDS: 0
    key 'F8'  201 MOD: 0 OEM: 41 LEDS: 0
    key 'F9'  202 MOD: 0 OEM: 42 LEDS: 0
    key 'F10'  203 MOD: 0 OEM: 43 LEDS: 0
    key 'F11'  204 MOD: 0 OEM: 44 LEDS: 0
    key 'F12'  205 MOD: 0 OEM: 45 LEDS: 0
    key 'HOME'  210 MOD: 0 OEM: 4A LEDS: 0
    key 'END'  213 MOD: 0 OEM: 4D LEDS: 0
    key 'Ins'  209 MOD: 0 OEM: 49 LEDS: 0
    key 'PUP'  211 MOD: 0 OEM: 4B LEDS: 0
    key 'Del'  212 MOD: 0 OEM: 4C LEDS: 0
    key 'PDN'  214 MOD: 0 OEM: 4E LEDS: 0
    key 'Del'  212 MOD: 0 OEM: 4C LEDS: 0
    key 'PDN'  214 MOD: 0 OEM: 4E LEDS: 0
    key 'UP'  218 MOD: 0 OEM: 52 LEDS: 0
    key 'LEFT'  216 MOD: 0 OEM: 50 LEDS: 0
    key 'DN'  217 MOD: 0 OEM: 51 LEDS: 0
    key 'RIGHT'  215 MOD: 0 OEM: 4F LEDS: 0
    HID (C0000) key press:223 - AC Home
    HID (C0000) key release:223
    HID (C0000) key press:18A - AL Email Reader
    HID (C0000) key release:18A
    HID (C0000) key press:194 - AL Local Machine Browser
    HID (C0000) key release:194
    HID (C0000) key press:192 - AL Calculator
    HID (C0000) key release:192
    HID (C0000) key press:CD - Pause/Continue
    HID (C0000) key release:CD
    HID (C0000) key press:B7 - Stop
    HID (C0000) key release:B7
    HID (C0000) key press:E2 - Mute
    HID (C0000) key release:E2
    HID (C0000) key press:EA - Volume Down
    HID (C0000) key release:EA
    HID (C0000) key press:E9 - Volume Up
    HID (C0000) key release:E9
    HID (C0000) key press:B6 - Scan Previous Track
    HID (C0000) key release:B6
    HID (C0000) key press:B5 - Scan Next Track
    HID (C0000) key release:B5
    HID (C0000) key press:183 - AL Consumer Control Configuration
    HID (C0000) key release:183
    HID (C0000) key press:183 - AL Consumer Control Configuration
    HID (C0000) key release:183

  9. #134
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,987
    @Paul -

    I was thinking of re-implementing the string code for Vendor, Product, Serial using the data retrieved by the enumeration code. But trying to figure out good place to store it.

    The most obvious place would maybe add a buffer to the Device_struct structure. My guessing is you would probably want to reserve maybe 64 bytes?

    Using my HID branch, that prints out some of the information, I see strings like:
    Code:
    Keyboard 1 Manufacturer: Lite-On Technology Corp.
    Keyboard 1 Product: USB Multimedia Keyboard
    Keyboard 1 no Serial number string
    ...
    Keyboard 1 Manufacturer: Teensyduino
    Keyboard 1 Product: Serial/Keyboard/Mouse/Joystick
    Keyboard 1 serial: 457240
    ...
    Keyboard 1 Manufacturer: Logitech
    Keyboard 1 Product: USB Receiver
    Keyboard 1 no Serial number string
    ...
    Keyboard 1 Manufacturer: Dell
    Keyboard 1 Product: Dell USB Keyboard Hub
    Keyboard 1 no Serial number string
    
    *** Keyboard 1 0461:4e67 Connected ***
    Keyboard 1 no Manufacturer string
    Keyboard 1 Product: HP USB Multimedia Keyboard
    Keyboard 1 no Serial number string
    *** Joystick 054c:05c4 Connected ***
    Joystick Manufacturer: Sony Computer Entertainment
    Joystick Product: Wireless Controller
    Joystick no Serial number string
    Might get away with some less.

    But if I understand correctly the Device objects are part of the HUBS and currently each HUB has 7 of these structures. SO for example with our Test app Mouse.ino we have:
    Code:
    USBHost myusb;
    USBHub hub1(myusb);
    USBHub hub2(myusb);
    USBHub hub3(myusb);
    ...
    So if I am reading this right our test app has 21 Device_t objects, so that 64 bytes would add 64*21=1344 bytes... Obviously we could cut out a HUB from the example.

    Alternatively we could add the data to the USBDriver class. There are probably fewer of these. Like maybe 10 in our example program... Most apps would have less...

    Alternatively could do something completely different, like maybe have one buffer, part of the enumeration code. Could have some optional callback to app code, that says new object created, and either pass pointers to the strings or allow user to query them... And let the app decide what to do with the strings...

    Thoughts.

  10. #135
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,441
    @Kurt - I'd like to merge whatever HID stuff you have in progress. Soon I'll need to change the print() and println() names that appear throughout the code, because they conflict with inheritance from Stream needed in the serial driver. Let's get your progress merged before this change creates a ton of merge conflicts.

    In other news, today I got the serial driver mostly working with FTDI. Will add the others soon. CDC-ACM is going to need more work in the enumeration code (for IAD), so please let me know if you have any changes enumeration.cpp?

  11. #136
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,987
    @Paul - I created a Pull request with my current stuff... Some of the stuff in this and also things I am still looking at include:

    a) Keyboard handles many of the Multimedia keys and power keys - Handles two different reports. Currently I have this like keyboard where there is a Press and Release method... But there is an issue with one of my keyboards that has a Knob for volume. Currently does not work properly. Should probably have callback have another parameter with the value... Not sure if it should replace both Press/Release.

    b) Keyboard - I map many of the extra keyts Fn, Arrow, Home/end/Pgup/Pgdn into the same values that Arduino Keyboard library does. Which are values > 0x80.

    c) Test app(Mouse.ino) - now displays these new values. I also have it case out these new values as well as multimedia keys and print out the name of the key.

    d) Test app - detects when devices are connected and not connected and prints out connect (with PID/VID) and disconnect.

    e) Yesterday - Added methods again to get the Vendor string, Product String, Serial # string... WIP - I added 48 byte buffer to every Device_t structure plus 3 bytes for start index for the strings... I don't like this usage of memory. With 3 hubs I think it adds 21 Device_t objects... I am thinking of 2 other ways. Add it to the buffer to the USBHost class. Probably a lot fewer of these so less memory.
    Or maybe add it as a new memory buffer, where different classes can contribute some... Or maybe a way to add them to specific Objects...

    Example not sure if something like:
    Code:
    uint8_t keyboard_string_buffer[48]
    KeyboardController keyboard1(myusb, keyboard_String_buffer, sizeof(keyboard_string_buffer));
    Would work and if that would be a desirable way to do it... Nice thing about this is the user can control which objects that they may be interested in...
    An interesting thing about this would be with ones like Mice/Joystick as the actual object is the USBHidParser... But probably would not be too hard. Could have one static buffer that we use in the enumeration, and then when it calls off to the claim function, the claim can then move the data into the user buffer...

    Let me know if you want anything changed or removed before merging.

  12. #137
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,441
    Ok, I merged it all. Not quite sure how I feel about the key codes and some other little bits, but at this point I'd rather like to avoid a mess of merge conflicts.

    Later today I will rename all the print and println calls. Please pull that into your copy before starting more work, so we don't get too far out of sync.

  13. #138
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,987
    Quote Originally Posted by PaulStoffregen View Post
    Ok, I merged it all. Not quite sure how I feel about the key codes and some other little bits, but at this point I'd rather like to avoid a mess of merge conflicts.

    Later today I will rename all the print and println calls. Please pull that into your copy before starting more work, so we don't get too far out of sync.
    Sounds good - again let me know if you want the special key code stuff changed/removed... I just thought it would be nice to be able to easily receive them... So followed the Arduino library for values.

    Also as I said not sure about best way to handle the Strings... As I mentioned there are a few different options... So if you have a preference let me know and I will converge over.

    Edit: My master branch is now in sync... Will wait until you do the renames before doing anything.

    Thanks - Also great work getting FTDI in place!

  14. #139
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,441
    Ok, here's the big patch. Please sync this into your copy.

    https://github.com/PaulStoffregen/US...74f3dd0405dd60

    Rather than changing "print" and "println" everywhere, I put in a couple #define lines at the top of most files, so this change isn't as disruptive as I had feared. The downside is you can't actually do stuff like "Serial.print" or "Serial1.print" within the files with those defines. Well, not unless you undefine them.

  15. #140
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,987
    Thanks Paul,

    I am now in sync. Again please let me know any parts that you would like different or not there...

  16. #141
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,987
    @Paul and others -

    Wondering about how to properly measure data usage in these programs/objects.

    I am/was concerned about how much memory the objects were taking, when I added about 50 bytes to each of the Device_t objects. Looking at the code I see that the HUB objects I believe will include 7 of these objects that they contribute to the memory pool. So since the demo APP has 3 hubs defined in it, I wonder what changing from 3 to 2 hubs would do for the reported memory usage.

    Note: In the test app, I have a few tables for many of the objects, such that I can loop asking if the Device is currently connected (bool operator). Plus an array of strings with printable names, plus an array of bools to know the previous state.

    When I changed from 3 HUBS to 2 HUBS, the memory change difference reported was 8 bytes: From 18912 to 18904... I tried increasing to 4 and it reported 18920
    Code:
     Not used: D:\arduino-1.8.5\hardware\teensy\avr\libraries\USBHost_t36
    Using library USBHost_t36 at version 0.1 in folder: C:\Users\kurte\Documents\Arduino\libraries\USBHost_t36 
    Sketch uses 55992 bytes (5%) of program storage space. Maximum is 1048576 bytes.
    Global variables use 18920 bytes (7%) of dynamic memory, leaving 243224 bytes for local variables. Maximum is 262144 bytes.
    So wondering why changes in these objects don't show any real change in Globals?

    Edit: I did a quick and dirty:
    Serial.println(sizeof(USBHub), DEC);

    And it prints out 1216
    Last edited by KurtE; 10-16-2017 at 10:00 PM.

  17. #142
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,441
    Many of the structures have align attributes, especially the array of pointers for the periodic schedule.

    Perhaps small changes are tending to "fill in" the gaps left over because the linker was forced to align stuff?

  18. #143
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,987
    I am not sure... As I mentioned in the Edit, the Sizeof(USBHub) prints out that the HUB structure is 1216 bytes. And when I dropped the buffer size down from 48 to 10.
    It printed as 960 so difference of 256... My guess is it did not save the expected 266 bytes. probably due to the alignment

    Again maybe experimenting at moving the String buffer out of the Device_t structure as we will have lot more of them than we need. Only need ones for actual devices the user app wants to talk to.
    Like the Keyboard object. Like the Serial object...

    Again may try three different solutions:
    a) Have these objects contain the string buffer..
    b) Have these ojbects contribute string buffers, that than when we have an object that is claimed, asks for buffer.
    c) Maybe have the user specify buffer/length on constructor for objects that they wish to be able to query on.

    Also looking at the code, wondering about, us passing in myusb to objects like:
    Code:
    USBHost myusb;
    USBHub hub1(myusb);
    USBHub hub2(myusb);
    USBHub hub3(myusb);
    USBHub hub4(myusb);
    As far as I know, these references are not used in any way. That the USBHost object is all static. Maybe for future use?

  19. #144
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,441
    Quote Originally Posted by KurtE View Post
    Maybe for future use?
    Yes, and also for some semblance of compatibility with the USB Host Shield library. But realistically, I'm not a big fan of many of their API decisions. Use of pointer & template syntax creeps into Arduino sketches.

    Turns out version 2 and 3 uses different syntax. Early on I put both constructors into the drivers. This is one of many little API decisions I kinda put off fully making. Now that the library is really starting to mature, it'll soon be time to choose and then keep the API stable.

  20. #145
    I use the same method, and wirless mouse loghitech and it works fine!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •