Teensy 4.1 USBhost_t36 library: should HIDDeviceInfo example print out HID packets?

liudr

Well-known member
I'm able to run this sample code. It prints out USB device information of a keyboard and a barcode scanner I plugged in. But I thought it may print out RAW HID data when I type on the keyboard like 8-byte reports etc. but nothing is printing out. Is this sample code supposed to print anything out if I press keys or scan bar codes? These are working devices I've been using for projects. I could probe it with my Beagle analyzer to see what's going on though. My hunch is that set config was issued but there's no regular polling.

I'm hoping to find a bare metal example though. Something that would allow me to see how the control transfers and bulk transfers are done. What library function to call with what arguments. These library examples may be too high level:D

This is from my bar code scanner. It's an HID keyboard emulation device. Works as a keyboard, sending 8-byte INT-IN packets for each character.

Code:
USBDeviceInfo claim this=20005E48

****************************************
** Device Level **
  vid=5E0
  pid=1200
  bDeviceClass = 0
  bDeviceSubClass = 0
  bDeviceProtocol = 0
09 04 00 00 01 03 01 01 00 09 21 10 01 00 01 22 4D 00 07 05 81 03 40 00 03

USBDeviceInfo claim this=20005E48

****************************************
** Interface Level **
09 04 00 00 01 03 01 01 00 09 21 10 01 00 01 22 4D 00 07 05 81 03 40 00 03
 bInterfaceNumber = 0
 number end points = 1
 bInterfaceClass =    3
 bInterfaceSubClass = 1
    HID (BOOT)
 bInterfaceProtocol = 1
report descriptor size = 77
  endpoint = 81
    attributes = 3 Interrupt
    size = 64
    interval = 3
 
There is a debug enable in the source code: {local}\hardware\teensy\avr\libraries\USBHost_t36\USBHost_t36.h

Code:
// Uncomment this line to see lots of debugging info!
//#define USBHOST_PRINT_DEBUG

That should emit lots of the low level messages
 
Thanks! I've just found where this include file is under vscode platformio teensy because I've decided to use vscode. I'll try this when I get back home. So just general question about the t36 library. This was developed for Teensy 3.6 and expanded to 4.x, correct? Does it support USB 2.0 High speed?

[Edit]: I was reading the .h file so it seems that these processors are compatible with the library:

Code:
#if !defined(__MK66FX1M0__) && !defined(__IMXRT1052__) && !defined(__IMXRT1062__)
#error "USBHost_t36 only works with Teensy 3.6 or Teensy 4.x.  Please select it in Tools > Boards"

So Teensy 3.6, ???, and Teensy 4.x?

The header says EHCI, maybe this hints it's USB 2.0 HS?
https://www.intel.com/content/www/u.../universal-serial-bus/ehci-specification.html
 
Last edited:
The simple answer is, it should try to dump the HID messages,
There is some simple debug monitor code that should turn on/off the decoded data or the raw data...

But: it may depend on the device. That is some devices require you to send some message, like use report 1... Before they will start transmitting any data.

Edit: yes it does support high speed. But note some of the classes may or may not. Example there are two flavors of the Serial object and Midi Object, one is setup to only handle smaller messages (64 byte) the others are setup to handle the 480mbs speed with 512 byte records
 
Thanks KurtE. I did toggle these raw data etc options and no luck. I know my bar code scanner well enough to know that when it beeps a doh-mi-sol, it means it's been configured. But if it's not polled then when I scan a barcode, it will beep and the double beep and flash red light. That's what I saw with this code. I'll poke with my usb analyzer then. It should tell me whether there's any INT-IN polling or not. I'll post back my findings.
 
Note: as you mentioned this looks like a keyboard (boot mode). Most keyboards have 8 byte messages.... But this has 64 bytes.

I know that in keyboard when we are claiming the keyboard, we will typically send one or another messages which may be needed to start the keyboard to transmit data.
Code:
	if (in_forceBoot_mode_list) {
		println("SET_PROTOCOL Boot");
		mk_setup(setup, 0x21, 11, 0, 0, 0); // 11=SET_PROTOCOL  BOOT
	} else {
		mk_setup(setup, 0x21, 10, 0, 0, 0); // 10=SET_IDLE
	}
	queue_Control_Transfer(dev, &setup, NULL, this);
And note in the case of set boot protocol, we then in the control callback see when that is transferred and then send out the set idle message
 
Great! Thanks. The bar code scanner has two modes. Only one is accessible via USB at a time. At the moment it is in the default boot protocol keyboard emulator mode, "USB class speak" 3,1,1. In this mode there is no report number (HID report descriptor says so) thus only 8-byte reports are transferred. I do remember you need to set idle. Wish I brought the whole box of stuff including my Beagle-480 with me.

For the alt mode, you scan a special code to enter after which the scanner enumerates as a different device, or USB class 3,0,0. This mode actually needs 64-byte packets. Not sure what protocol it is but you can guess the data structure. To think about it, "pressing each key" (311) for a char in a bar code is very slow. Sending up to 60+ chars at a time (300) is what's more appropriate. Imagine typing in a 300+ char driver's license scan!

I like this line. It's low-level enough for me :D

Code:
queue_Control_Transfer(dev, &setup, NULL, this);

Hoping to find its definition and see how to use it properly. I'm interested in writing a CP2102 or FT231X driver with low-level calls as a practice to understand this USB host stack.
 
I tested with my Beagle protocol analyzer. There are no set idle or INT-IN polling after set config. The 4.1 board doesn't provide sufficient current to the bar code scanners so I rigged the 5V from a USB powered hub to my scanner. Still there's no go. For my keyboard. There were polling but since there were no set idle or set report there were no responses from the keyboard despite the polling.
 
Back
Top