Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 51 to 75 of 90

Thread: Anyone knows if the Teensy 3.6 USB is faster?

  1. #51
    Senior Member
    Join Date
    Jul 2014
    Posts
    140
    I've also seen the 01 01 01 01 01 01 pattern, so I've created a dataset:

    Keys: 1
    KB Data: 00 00 1E 00 00 00 00 00
    Pass with order '1'

    Keys: 12
    KB Data: 00 00 1F 1E 00 00 00 00
    Pass with order '21'

    Keys: 123
    KB Data: 00 00 1F 20 1E 00 00 00
    Pass with order '231'

    Keys: 1234
    KB Data: 00 00 1F 20 21 1E 00 00
    Pass with order '2341'

    Keys: 12345
    KB Data: 00 00 01 01 01 01 01 01
    Fail

    Keys: 1234 6
    KB Data: 00 00 1F 20 21 23 1E 00
    Pass with order '23461'

    Keys: 1234 67
    KB Data: 00 00 01 01 01 01 01 01
    Fail

    Keys: 1234 6 8
    KB Data: 00 00 1F 20 21 23 25 1E
    Pass with order '234681'

    Keys: 1234 6 8 + any other key
    KB Data: 00 00 01 01 01 01 01 01
    Fail

    If I had to guess, this is a limitation with the keyboard scan. I say this because I used the Keyboard Test Utility and saw that windows has exactly the same limitation - I could not press any of the 01 01 01 01 01 01 combinations and see the letters as 'pressed' in the Keyboard Test Utility. That sounds like good news to me for your driver - probably not a bug?
    Last edited by macaba; 02-21-2017 at 08:56 AM.

  2. #52
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,212
    Yeah, probably not a bug. Sure looks like just a keyboard limitation (and one I need to handle gracefully in the driver). But difficult for me to confirm, since the 1 extra keyboard I have doesn't do this. Without the protocol analyzer observing the actual USB communication between Teensy and the keyboard, hard to say with absolute certainty.

    Maybe I should buy another keyboard for testing? Would be nice to find one that does this behavior. A compact size keyboard would be really nice, as my pile of USB test devices is growing....

  3. #53
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,212
    Turns out, all the other keyboards I have are fairly high-end models with USB hubs built in. I still have work to do on the hub driver, and the EHCI core to support more than 1 device, before I can test any of the others.

  4. #54
    Senior Member
    Join Date
    Jul 2014
    Posts
    140
    I'm sorry to say that protocol analyzer costs too much for me to add it to my tool collection (who doesn't love more tools?!) so can't really help there.

    For that dataset I used a Dell SK-8115 keyboard. (Old keyboard, not available new any more)

    I was also able to reproduce the same behaviour with:
    http://www.trust.com/en/product/1718...cline-keyboard
    Edit: Just looked, looks like I have an older revision to the ones currently on sale. There's a good chance that recent revisions would do the same thing.

    I'd be surprised if the Logitech K120 didn't do the same thing (cheap & available) but I don't have one to confirm.
    Last edited by macaba; 02-21-2017 at 09:10 AM.

  5. #55
    Senior Member
    Join Date
    Apr 2014
    Location
    -
    Posts
    9,756
    I found some Info :-)
    This effect has a name, its called "Ghosting" and gamers can buy special keyboards with "Anti-Ghosting" feature.

    Edit: I'm using a "Cherry eVolution STREAM XT Keyboard G85-23100" But it has normal size.
    Not sure if the "G" stands for "German".
    Last edited by Frank B; 02-21-2017 at 05:10 PM.

  6. #56
    Senior Member
    Join Date
    Apr 2014
    Location
    -
    Posts
    9,756
    A bit more information:

    http://www.usb.org/developers/hidpage/Hut1_12v2.pdf page 53 says,

    0x01 is Keyboard Error Rollover
    0x02 is Keyboard Post Fail
    0x03 is Keyboard Error undefined.

    The first valid code is 0x04, which is the key "a".

  7. #57
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,697
    well, since the K66 proto shield has host USB on it, I hooked up a keyboard and ran Paul's k66_usbhost sketch. looks like it is working. KB data changes as i hit the keys. I don't know squat about the USB protocols and such, but if you need another test point .....

    keyboard is GearHead model KB1700U

    i also hooked up USB mouse.

    are linux drivers useful as point of reference?
    http://lxr.free-electrons.com/source...sbhid/usbkbd.c
    http://lxr.free-electrons.com/source...hid/usbmouse.c
    Last edited by manitou; 02-22-2017 at 02:50 PM.

  8. #58
    Senior Member
    Join Date
    Apr 2014
    Location
    -
    Posts
    9,756
    Quote Originally Posted by manitou View Post
    well, since the K66 proto shield has host USB on it, I hooked up a keyboard and ran Paul's k66_usbhost sketch. looks like it is working. KB data changes as i hit the keys. I don't know squat about the USB protocols and such, but if you need another test point .....

    i also hooked up USB mouse.
    Do you want one of my boards ? It has usb.

  9. #59
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,212
    Quote Originally Posted by manitou View Post
    are linux drivers useful as point of reference?
    Linux source will be help later for other types of devices without well documented protocols, like FTDI serial converters.

    For HID not using the 2 fixed boot protocols, it's not a matter of missing info, merely a matter of a highly flexible protocol that results in quite a bit of complex code needed to fully support it. A full generic HID parser is going to take time.

    Soon I'll add a driver similar to Linux hidraw, where you can parse the report bits & bytes yourself. That's what Oleg & Andrew seem to do now in the USB Host Shield library. Actually, it looks like they provide something more like a toolkit of USB stuff and getting the report data is a bit of a DIY effort, and then you have to figure out which bits & bytes you need.

    But before I do even that, so much more work is needed. USB disconnect isn't supported at all, and bad things happen if you plug another device in after a disconnect. Interrupt type endpoints aren't getting their polling intervals or making use of the bandwidth planning. I'm going to add a timer service the device drivers can use. The hub driver really needs it and others probably will too. So much is needed before this will all become really usable...
    Last edited by PaulStoffregen; 02-22-2017 at 03:38 PM.

  10. #60
    Senior Member
    Join Date
    Apr 2014
    Location
    -
    Posts
    9,756
    Is it much work to add support fo the LEDs on the keyboard ....? perhaps simple LED on/off functions...?
    I have my keyboard-emulation/translation working (better than in VICE!), the LEDs (for caps lock, and i want to use one for a joystick-switch indicator on the numpad) are missing...
    Last edited by Frank B; 02-24-2017 at 09:59 PM.

  11. #61
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,212
    More progress... interrupt endpoints now get their actual interval (rather than always the slowest possible polling) and USB disconnect is now handled fairly well with (hopefully) all dynamic resources freed. I just disconnected and re-enumerated a keyboard 60 times in a row! Built this little board recently to help with the disconnect testing....

    https://www.oshpark.com/shared_projects/Ie73B1He

  12. #62
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,212
    The hub driver is now sort-of functional. At least it's possible to connect and enumerate 2 keyboards. It's still not handling disconnects or other events in many states, but I'll be adding those soon.

  13. #63
    Junior Member
    Join Date
    Feb 2017
    Posts
    2
    I took a couple of days to write a driver for USB HS device mode and it's mostly working, except for control transfers with an OUT data stage. All other transfer types are working in my implementation.

    I've never worked on USB before, so I am probably confused on how to receive the payload... once I've parsed the setup stage, I prime my endpoint to receive (but never get an interrupt for EPCOMPLETE). Is that not correct?

    edit: Never mind. I wasn't respecting the bmRequestType field on the setup packet.
    Last edited by rgthnd; 03-05-2017 at 05:52 PM.

  14. #64
    Senior Member
    Join Date
    Apr 2014
    Location
    -
    Posts
    9,756
    ... still a few bugs, but it already uses the USB HOST for keyboard, and as soon as a driver is available, joystick, too :

    Teensy running a very old C64 game

    BTW, I had to add code to SLOW DOWN this thingy, the native speed is 1.9..3.4x a original C64
    I still have to add a few details which may make it a bit slower.


    Edit: I made great progress this evening: The video does not show some sprites, which are now visible :-)
    Sprite-Sprite collision with interrupts are working now, sprite-foreground collision-detection seems to be buggy,
    And for some reason, it does not play the sound. hm. I'll fix that and test more advanced games, then...

    "Joysticks" are on the Keyboard-numpad.
    Last edited by Frank B; 03-06-2017 at 10:14 PM.

  15. #65
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,212
    That looks really awesome!

    Guess I ought to get a joystick driver working....

  16. #66
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,212
    The host library now has a public API and it's actually in the form of an Arduino library.

    https://github.com/PaulStoffregen/USBHost_t36

  17. #67
    Junior Member
    Join Date
    Mar 2017
    Posts
    3
    Will there be support for detecting modifier keys and control for keyboard LED's?
    It would be really nice. In my project I'll need that feature.

  18. #68
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,212
    Yeah, the keyboard API needs to be extended. As a first try, I went with the simple API that Arduino is documenting on their site. But it seems to have some pretty significant limitations...

  19. #69
    Senior Member
    Join Date
    Apr 2014
    Location
    -
    Posts
    9,756
    Paul, do you have a schedule for the joystick/joypad driver ?
    Or can you give detailed hints how to add it.. ?

    I have my Teensy-C64 almost 100% working..only little problems remaining.
    Games i tried are "Donky Kong", "Dig Dug", "Commando", "PaperBoy" (<- this one uses very dirty VIC tricks and disables the borders to display sprites) and more.
    I'll record&upload some videos tomorrow.
    Last edited by Frank B; 03-18-2017 at 08:06 PM.

  20. #70
    Just today got one of my USB displays almost fully operational on my Teensy 3.6, thanks to Pau'ls USBHost work.
    Display is a composite device; an LCD (480x272x2 with a 512b packet size) and a HID touch input interface (interrupt driven). What I thought was interesting, and why this post, is that throughput benchmarking shows the Teensy's USBHost interface is more than capable of matching that of a PC.
    On the Teensy (180Mhz), I'm seeing ~23MB/s (thats megabyte) data throughput from T36 to display, which translates to around 90FPS update rate, and this is exactly how the display performs under a PC running Windows 7.

    So a big thank you to Paul and the team, excellent work in the Teensy.

  21. #71
    Senior Member
    Join Date
    Apr 2014
    Location
    -
    Posts
    9,756
    Quote Originally Posted by MichaelMC View Post
    Just today got one of my USB displays almost fully operational on my Teensy 3.6, thanks to Pau'ls USBHost work.
    Display is a composite device; an LCD (480x272x2 with a 512b packet size) and a HID touch input interface (interrupt driven). What I thought was interesting, and why this post, is that throughput benchmarking shows the Teensy's USBHost interface is more than capable of matching that of a PC.
    On the Teensy (180Mhz), I'm seeing ~23MB/s (thats megabyte) data throughput from T36 to display, which translates to around 90FPS update rate, and this is exactly how the display performs under a PC running Windows 7.

    So a big thank you to Paul and the team, excellent work in the Teensy.
    Sounds great ! Is there more information available ? Which display exactly ? Is the code open source ?

  22. #72
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,212
    Quote Originally Posted by Frank B View Post
    Paul, do you have a schedule for the joystick/joypad driver ?
    No. Almost every schedule I've ever said for any specific software development has always ended up very, very late. Now I try to avoid making such promises.

    The only schedule I do try to follow is packaging updates and fixes for a new Teensyduino release approx every 3 to 4 months. I'm mostly inspired by Ubuntu's release model. A new release comes on a predictable schedule, but what things will actually be in each release remains to be seen....

    Or can you give detailed hints how to add it.. ?
    For a quick & dirty hack, copy the keyboard driver. Change the class name everywhere. Delete most of the matching checks in claim() and maybe just hard-code a couple checks for your joystick's VID and PID. Increase the buffer and max packet size, if your joystick sends more than 8 bytes. Then rewrite new_data() to parse whatever data your joystick sends. With a little experimentation you'll easily discover which bits & bytes are which buttons and axes.

    The right way involves reading and parsing the HID descriptor, and then using that data to parse the bits & bytes. I plan to do this eventually, but it's a huge project. I do not expect to have it working anytime soon. For now, go with the ugly hack if you just want to get your joystick working.

  23. #73
    Quote Originally Posted by Frank B View Post
    Sounds great ! Is there more information available ? Which display exactly ? Is the code open source ?
    Display is a USBD480. Software isn't public, yet, but I will put everything on github once the graphics primitives and font renderer (from file, SDIO is fast enough) are implemented.
    For the driver, my basic approach is to emulate as much as required of the libusb0 API interface, as from here is where my experience lies meaning porting code is much less troublesome.
    eg;
    Code:
    	static bool usb_control_msg (Device_t *dev, uint32_t orequestType, uint32_t omsg, uint32_t ovalue, uint32_t oindex, void *buff, uint32_t len)
    	{
    		setup_t setup;
    		mk_setup(setup, orequestType, omsg, ovalue, oindex, len);
    		return queue_Control_Transfer(dev, &setup, buff, NULL);
    	}
    
    	static bool usb_bulk_write (USBDriver *drv, Pipe_t *pipe, const void *buffer, const uint32_t len)
    	{
    		return queue_Data_Transfer(pipe, (void*)buffer, len, drv);
    	}
    and in use:
    Code:
    writeData (const void *data, const size_t size)
    {
    	__disable_irq();
    	bool ret = usb_bulk_write(this, pipe_out, data, size);
    	__enable_irq();
    	return ret;
    }

  24. #74
    Senior Member
    Join Date
    Apr 2014
    Location
    -
    Posts
    9,756
    Great!
    Where did you buy this display ?
    Do you think i can use it for the C64-EMU ? (It must be able to refresh the whole display-content with 50HZ)
    Anyway, it sounds fun..

  25. #75
    Senior Member
    Join Date
    Apr 2014
    Location
    -
    Posts
    9,756
    @PaulStoffregen: Hm, i see what i can do.. :-) Maybe it's more straightforward to use a few pins ... But USB would more easy for the user.

Posting Permissions

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