Anyone knows if the Teensy 3.6 USB is faster?

Status
Not open for further replies.
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:
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....
 
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.
 
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/17184-classicline-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:
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:
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/drivers/hid/usbhid/usbkbd.c
http://lxr.free-electrons.com/source/drivers/hid/usbhid/usbmouse.c
 
Last edited:
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.
 
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:
Is it much work to add support fo the LEDs on the keyboard ....? :rolleyes: 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:
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
 
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.
 
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:
... 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:
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.
 
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:
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.
 
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 ?
 
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.
 
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;
}
 
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..
 
@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.
 
Status
Not open for further replies.
Back
Top