Quick Teensy 3.6 USB Host questions

Status
Not open for further replies.
D

DaveAK

Well-known member
I've just had to cobble together a quick dynamometer DAQ using a Teensy 3.6 and have a question about the USB Host. Part of the DAQ includes a serial input of weather data through an FTDI chip. After I wasted too many hours because I had got the D+ and D- wired in reverse I finally managed to get it working using UHS30 but couldn't get anything using USBHost_t36. Since it does work I just have a few quick questions to help clarify things before I implement it in my actual project.

  1. Should USBHost_t36 work with an FTDI serial device? I would prefer to use it if I can as it appears to use familiar Serial functions.
  2. Do I need any references to a USB Hub if I'm actually connecting the device directly to the Teensy?
  3. I got it all to work with the acm_terminal example from UHS30. This all seems to revolve around the MY_ACM class.
    • USB_HOST_SERIAL doesn't seem to actually do anything, (at least in my example testing). Can this all be ignored?
    • Should I just be creating my own class implementing UHS_CDC_ACM for my project and implementing the OnStart() and OnRelease() functions?
    • Does UHS_CDC_ACM have available() and other functions that Arduino Serial/Stream does, or would I have to implement them if I wanted to use them? (It was late when I finally got success and I admit I haven't gone through the source yet.)
This is my first post and I'd just like to thank all the regulars on here for the many replies to threads that I've read that have helped me with other projects!

EDIT: Just to clarify, I did get the keyboard example working with USBHost_t36, just not the serial device stuff.
 
Last edited:
I can answer these first 2...

Should USBHost_t36 work with an FTDI serial device? I would prefer to use it if I can as it appears to use familiar Serial functions.
Click to expand...

Yes, FTDI should work. Or at least the few that have been tested. But FTDI makes many different chips.

Any chance you could edit USBHost_t36.h to enable to verbose debug info? If you could post that info here, it would go a long way towards someday getting USBHost_t36 improved to work with that specific FTDI chip.


Do I need any references to a USB Hub if I'm actually connecting the device directly to the Teensy?
Click to expand...

No, the hub instances are only needed if you put a USB hub between the device and Teensy 3.6, or if the product you're using actually has a hub integrated inside (as some USB keyboards do).
 
Hey Paul, here's the debug output. The manufacturer, product and serial number all appear correct. I'm using the SerialTest sketch and just modified the baud rate to 9600. The device streams data constantly in one second intervals, so I'm expecting userial.available() to be triggered and the data received to be echoed to Serial. In testing my sketches it always seems to hang at userial.begin(9600). In this one I'm not sure it's ever getting that far as it's not showing Device connected in the serial console.

Code: 
USB Host Testing - Serial
sizeof Device = 36
sizeof Pipe = 96
sizeof Transfer = 64
power up USBHS PHY
port change: 10001803
    connect
  begin reset
port change: 10001805
  port enabled
  end recovery
new_Device: 12 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
Device Descriptor:
  12 01 00 02 00 00 00 08 03 04 15 60 00 10 01 02 03 01 
    VendorID = 0403, ProductID = 6015, Version = 1000
    Class/Subclass/Protocol = 0 / 0 / 0
    Number of Configurations = 1
enumeration:
enumeration:
Manufacturer: FTDI
enumeration:
Product: WeatherStationV2
enumeration:
Serial Number: WS2JF0OH
enumeration:
Config data length = 32
enumeration:
Configuration Descriptor:
  09 02 20 00 01 01 00 80 2D 
    NumInterfaces = 1
    ConfigurationValue = 1
  09 04 00 00 02 FF FF FF 02 
    Interface = 0
    Number of endpoints = 2
    Class/Subclass/Protocol = 255 / 255 / 255
  07 05 81 02 40 00 00 
    Endpoint = 1 IN
    Type = Bulk
    Max Size = 64
    Polling Interval = 0
  07 05 02 02 40 00 00 
    Endpoint = 2 OUT
    Type = Bulk
    Max Size = 64
    Polling Interval = 0
enumeration:
USBHub memory usage = 960
USBHub claim_device this=1FFF2A40
USBHub memory usage = 960
USBHub claim_device this=1FFF34C0
HIDParser claim this=1FFF2040
HIDParser claim this=1FFF2540
HIDParser claim this=1FFF3880
USBSerial claim this=1FFF2E80
vid=403, pid=6015, bDeviceClass = 0, bDeviceSubClass = 0, bDeviceProtocol = 0
09 04 00 00 02 FF FF FF 02 07 05 81 02 40 00 00 07 05 02 02 40 00 00 
Descriptor 4 = INTERFACE
HIDParser claim this=1FFF2040
HIDParser claim this=1FFF2540
HIDParser claim this=1FFF3880
USBSerial claim this=1FFF2E80
vid=403, pid=6015, bDeviceClass = 0, bDeviceSubClass = 0, bDeviceProtocol = 0
09 04 00 00 02 FF FF FF 02 07 05 81 02 40 00 00 07 05 02 02 40 00 00 
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
 
I apologize for resurrecting such an old topic but it is the only one pertinent to my inquiry and it seemed a better decision than starting a new thread.

In short, from what I can tell, PID 6015 indicates a "FT-X" (FTX) FTDI device. I've basically been pursuing this issue under the assumption that it is a FT230X device or is an otherwise compatible device with little-to-no changes needed to source code.

Anyhow, using the USBHost_t36 library I'm able to get to the point of establishing pipes and performing control callbacks so as to set baud rate, flow control, etc. However, after the code proceeds through that step, the device does nothing else. The device works as it should when connected to a Windows PC utilizing FTDI's VCP (and D2XX?) drivers. I've did the following in an attempt to rectify the issue:


Analyze USB traffic with Wireshark to see the raw data transmitted when using the VCP driver. It appears the USBHost_t36 library mimics the same data up until the point of transmitting control data related to configuration; i.e.:

VCP Response: 09 02 20 00 01 01 00 80 2d 09 04 00 00 02 ff ff ff 02 07 05 81 02 40 00 00 07 05 02 02 40 00 00
USBHost_t36 Response: the same

VCP Request: 00 09 01 00 00 00 00 00
VCP Response: Echoes the same transmission absent the setup data in the request.
USBHost_t36 Request: The various transmission and setup data in the FTDI section of the control callback of USBHost_t36
USBHost_t36 Response: None?


I've accordingly attempted to mimic the above behavior by editing the USBHost_t36 library and I've met no success. Additionally, I've dug into other available FTDI drivers (e.g., Linux) and such as well to attempt to gain some insight and ideas, but I've had no luck in implementation. Random searches of pertinent code (e.g., baud rate divisors and such) have turned up some promise as well but none of the attempts to alter the control transmissions have seemed to work.

To note, I am a complete amateur - especially in regards to the USB protocol and associated characteristics. Nonetheless, I've read the referenced USB documentation as well as other material in order to figure this out - but still with no luck.

DaveAK: were you ever able to get the device working?
PaulStroffregen: do you have any advice?


Respectfully,
Dockery
 
To answer the question directed to me, unfortunately I simply can't remember how far I got with this. The dyno projects stalled out and the USB weather station is still in my drawer but I've since used the T36 for other things. It seems I was getting something with UHS30, (whatever that is!), and I might have decided that was enough. Like I said though, I really can't remember and I would have to hook things up again and find the code I was working on to give a better answer.
 
Dave, thank you for taking the time to follow up on this. I am grateful for your response and I apologize for asking about something so long ago.
 
Status
Not open for further replies.
Back
Top