Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 26 to 50 of 65

Thread: Teensy 3.6 USB Host support

  1. #26
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,973
    Maybe there's something unusual about your mouse?

    Quote Originally Posted by dun46 View Post
    the Mouse is from the brand Belkin
    Can you tell us a specific model number? Or show a photo with any identifying markings?

  2. #27
    Member
    Join Date
    Jul 2018
    Posts
    32
    The debug output does not show VID/PID so the mouse never even enumerates. Make sure the mouse works on a computer. Or try a powered USB hub.

  3. #28
    Member
    Join Date
    Feb 2015
    Location
    Rians in Provence, France
    Posts
    47
    Hi all,
    As I said previously, the 3.6 USB host port is running fine with Buydisplay touchscreen. 10.1"
    Using a Techtoy HDMI board and the Techtoy shield adaptor for 3.6.

  4. #29
    Junior Member
    Join Date
    Dec 2016
    Posts
    13
    Hi all.
    I have to ask everyone's excuses because my problem is wire connections.
    Everything works correctly, hub, keyboard and mouse.
    I thank you for the collaboration received and I hope it does not happen again.
    Thank you very much to all.

  5. #30
    Junior Member
    Join Date
    Oct 2012
    Location
    Austin TX
    Posts
    13

    Host to host?

    Would it be possible to connect another host device to the teensy via Host port and the USBHost_t36 library?

    Example - Let's say I have a Raspberry Pi that sends out USBmidi and I wanted to get that into my mac using the teensy 3.6 as a translator.

  6. #31
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,973
    Quote Originally Posted by nevetsokyeron View Post
    Would it be possible to connect another host device to the teensy via Host port and the USBHost_t36 library?
    Nope, sorry, that can't work. USBHost_t36 only communicates with USB devices and hubs. It can't talk to other USB hosts.

    Example - Let's say I have a Raspberry Pi that sends out USBmidi and I wanted to get that into my mac using the teensy 3.6 as a translator.
    You could accomplish this using a pair of Teensy 3.x or even Teensy LC, with hardware serial lines between them. Each board listens on its USB port and forwards any messages to the other board, and also listens for any incoming messages from the other board and transmits them over USB.

    If you want it to run fast, use at least Teensy 3.2, where the serial ports have FIFOs and RTS/CTS handshaking to work effectively at fast baud rates. A pair of Teensy LC boards could do it, but getting the serial link to run in the Mbps range is unlikely with the less powerful LC hardware.

  7. #32
    Junior Member
    Join Date
    Dec 2016
    Posts
    13
    Hello all.
    I have already tested with a PS3 "Ipega PG-9076" and it works very well.
    https://www.amazon.com/PG-9076-Wirel.../dp/B075J7YQTC
    My configuration is: Teensy 36 USB1 ---> Hub ---> Dongle Bluetooth .)))) ((((. Joystick PS4
    It also works through USB cable connected directly to the hub
    Thank you very much for the help.
    dun46

  8. #33
    Junior Member
    Join Date
    Oct 2012
    Location
    Austin TX
    Posts
    13
    Quote Originally Posted by PaulStoffregen View Post
    Nope, sorry, that can't work. USBHost_t36 only communicates with USB devices and hubs. It can't talk to other USB hosts.
    Aw darn.

    Thanks for the quick reply!

  9. #34
    Junior Member
    Join Date
    Dec 2016
    Posts
    13
    Hi all.
    I have used the KurtE library that supports bluetooth
    https://github.com/KurtE/USBHost_t36/tree/Bluetooth-WIP
    and all working very fine.
    regards

  10. #35
    Junior Member
    Join Date
    Jan 2019
    Posts
    2
    I have a USB mini host shield 2.0 on a Teensy 3.6. Turned it on today, seemed good, my bluetooth dongle plugged into it was blinking.

    I just set up a new computer, got all the latest libraries and sent my code to Teensy and then the host shield wouldn't initialize. When I run the test program, This is the entire output:

    USB Host Testing - Serial

    What could be the source of this problem?

  11. #36
    Junior Member
    Join Date
    Jan 2019
    Posts
    2
    Oh damn, forgot I had to adjust this in settings to zero:

    #define USE_SPI4TEENSY3 0

  12. #37
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    I still find it unfortunate that this chip has EHCI. It is not by any means an MCU friendly hardware design.

    While it MIGHT make sense if using an RTOS, it is still a horrid USB implementation, never liked [eox]HCI controllers, here's why.
    1. Too much work on the processor side.
    2. Takes a huge amount of code to actually do anything, code bloat.
    3. You can't just send a packet.
    4. Memory eating pipes.
    5. Manual timing (WTAF???). Reminds me of those dumb total junk win-printers.
    ...and much more.

    At least Microchip has gotten this right on their MIPS32 platform. Would be nice to see NXP do the same.

    @PaulStoffregen
    So, I glazed over all the huge amounts of code of the t36 USB lib, and well, too bad you have to maintain a pipe. If that wasn't required, it could have fit better into UHS3. If there is an actual way to not require the whole pipe stuff, I'd really like to know how to do that. Perhaps I am misunderstanding the relationship too. UHS3 only needs to maintain some simple endpoint data, is this the same thing as these pipes?

  13. #38
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,973
    EHCI is indeed complicated. Whether you consider that good or bad is a matter of perspective. If you value high performance for multiple devices running simultaneously or you want to write software with non-blocking APIs, EHCI has a lot to like.

    For a simple synchronous & blocking design like UHS3, indeed EHCI is frustrating.

    Is that code I submitted about a year ago still in UHS3? I believe it was pretty close. It did work for the tests I ran at the time. Maybe it can be made to work in all cases with some simple changes, like fully disabling the asynchronous schedule between operations?

  14. #39
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    Quote Originally Posted by PaulStoffregen View Post
    EHCI is indeed complicated. Whether you consider that good or bad is a matter of perspective. If you value high performance for multiple devices running simultaneously or you want to write software with non-blocking APIs, EHCI has a lot to like.

    For a simple synchronous & blocking design like UHS3, indeed EHCI is frustrating.
    Right, Most bare-metal/non-RTOS stuff won't care if it blocks, because you are not typically running multiple threads of execution.

    Quote Originally Posted by PaulStoffregen View Post
    Is that code I submitted about a year ago still in UHS3? I believe it was pretty close. It did work for the tests I ran at the time. Maybe it can be made to work in all cases with some simple changes, like fully disabling the asynchronous schedule between operations?
    Have not had the chance to check on it to be honest. There have been a ton of improvements since last year too. I'll have to revisit this again, and try to wrap my head around what I'm not understanding with the whole need to track pipes v.s. just popping arbitrary packets onto the serial interface engine one at a time.

  15. #40
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,973
    For bulk & control, I believe this should be possible. It's been about a year since I tried to contribute that code, which was also the early days of USBHost_t36.

    https://github.com/felis/UHS30/commi...76b3bdf4e9R653

    Looks like the code is disabling the async schedule, at line #699.

    If you can send me a test case that causes this to fail, I could try running it here and see if I can come up with a way to make it work.

  16. #41
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    @PaulStoffregen I revisited the code, and added some notes, mostly where you misunderstood some things.
    Pull the source, update the submodule, take a look at it when you get the chance.
    As far as hub support, I will tackle that later, as it involved handling TT's.

  17. #42
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    @PaulStoffregen Here is how close it is to working.

    Code:
    ISRbottom, usb_task_state: 0x3
    PCI Vbus state changed to 2
    USB host speed now 2
    ISRbottom, usb_task_state: 0x3
    ISRbottom, usb_task_state: 0x5
    ISRbottom, usb_task_state: 0xC
    ISRbottom, UHS_USB_HOST_STATE_CONFIGURING
    
    
    
    Configuring: parent = 0, port = 1, speed = 2
    
    
    Configuring PktSize 0x40,  rcode: 0x00, retries 0,
    ctrlReqOpen
    SetAddress, addr=0, ep=0
    ep entry for interface 0 ep 0 max packet size = 64
    SetAddress, speed=2, maxlen=64
    SetAddress, parent=0, parent_port=1
    ctrlReq2: left: 64, read:64, nbytes 64
    ctrlReqRead left: 64, nbytes: 64, dataptr: 2002fe78
    InTransfer 64
    ctrlReq3: acceptBuffer sz 18 nbytes 64 left 46
    PCI Vbus state changed to 2
    USB host speed now 2
    ctrlReqOpen
    SetAddress, addr=0, ep=0
    ep entry for interface 0 ep 0 max packet size = 64
    SetAddress, speed=2, maxlen=64
    SetAddress, parent=0, parent_port=1
    0 retries.
    DevDescr 2nd poll, bMaxPacketSize0:64
    ctrlReqOpen
    SetAddress, addr=1, ep=0
    ep entry for interface 0 ep 0 max packet size = 64
    SetAddress, speed=2, maxlen=64
    SetAddress, parent=0, parent_port=1
    ctrlReq2: left: 18, read:18, nbytes 18
    ctrlReqRead left: 18, nbytes: 18, dataptr: 2002fe78
    InTransfer 18
    PCI Vbus state changed to 2
    USB host speed now 2
    ctrlReqOpen
    SetAddress, addr=0, ep=0
    ep entry for interface 0 ep 0 max packet size = 64
    SetAddress, speed=2, maxlen=64
    SetAddress, parent=0, parent_port=1
    0 retries.
    configs: 1
    Good... one config on the device.
    Code:
    ctrlReqOpen
    SetAddress, addr=1, ep=0
    ep entry for interface 0 ep 0 max packet size = 64
    SetAddress, speed=2, maxlen=64
    SetAddress, parent=0, parent_port=1
    ctrlReq2: left: 9, read:9, nbytes 9
    ctrlReqRead left: 9, nbytes: 9, dataptr: 2002feb8
    InTransfer 9
    CONFIGURATION: 0, bNumInterfaces 1, wTotalLength 39
    ctrlReqOpen
    SetAddress, addr=1, ep=0
    ep entry for interface 0 ep 0 max packet size = 64
    SetAddress, speed=2, maxlen=64
    SetAddress, parent=0, parent_port=1
    ctrlReqRead left: 39, nbytes: 39, dataptr: 2002fdf0
    InTransfer 39
    bLength: 9 bDescriptorType: 02
    eating 8
    bLength: 9 bDescriptorType: 04
    INTERFACE DESCRIPTOR FOUND
    Getting 3 endpoints
    bLength: 7 bDescriptorType: 05
    ENDPOINT DESCRIPTOR: 0
    ENDPOINT DESCRIPTOR OK
    eating 0
    bLength: 7 bDescriptorType: 05
    ENDPOINT DESCRIPTOR: 1
    ENDPOINT DESCRIPTOR OK
    eating 0
    bLength: 7 bDescriptorType: 05
    ENDPOINT DESCRIPTOR: 2
    ENDPOINT DESCRIPTOR OK
    eating 0
    eating 1
    ENDPOINT DESCRIPTORS FILLED
    Good, correctly filled endpts
    Code:
    TestInterface VID:0718 PID:0065 Class:00 Subclass:00 Protocol 00
    Interface data: Class:08 Subclass:06 Protocol 06, number of endpoints 3
    Parent: 00, bAddress: 01
    Driver 1 supports this interface
    Driver 1 can be used for this interface
    USB_INTERFACE END OF STREAM
    ctrlReqOpen
    SetAddress, addr=1, ep=0
    ep entry for interface 0 ep 0 max packet size = 64
    SetAddress, speed=2, maxlen=64
    SetAddress, parent=0, parent_port=1
    ctrlReq2: left: 9, read:9, nbytes 9
    ctrlReqRead left: 9, nbytes: 9, dataptr: 2002feb8
    InTransfer 9
    CONFIGURATION: 1, bNumInterfaces 1, wTotalLength 39
    Best configuration is 1, enumerating interfaces.
    ctrlReqOpen
    SetAddress, addr=1, ep=0
    ep entry for interface 0 ep 0 max packet size = 64
    SetAddress, speed=2, maxlen=64
    SetAddress, parent=0, parent_port=1
    ctrlReqRead left: 39, nbytes: 39, dataptr: 2002fdf0
    InTransfer 39
    bLength: 9 bDescriptorType: 02
    eating 8
    bLength: 9 bDescriptorType: 04
    INTERFACE DESCRIPTOR FOUND
    Getting 3 endpoints
    bLength: 7 bDescriptorType: 05
    ENDPOINT DESCRIPTOR: 0
    ENDPOINT DESCRIPTOR OK
    eating 0
    bLength: 7 bDescriptorType: 05
    ENDPOINT DESCRIPTOR: 1
    ENDPOINT DESCRIPTOR OK
    eating 0
    bLength: 7 bDescriptorType: 05
    ENDPOINT DESCRIPTOR: 2
    ENDPOINT DESCRIPTOR OK
    eating 0
    eating 1
    ENDPOINT DESCRIPTORS FILLED
    AttemptConfig: parent = 0, port = 1
    Driver 1 supports this interface
    Interface Configured
    Good, correctly associated driver!!
    Code:
    ctrlReqOpen
    SetAddress, addr=1, ep=0
    ep entry for interface 0 ep 0 max packet size = 64
    SetAddress, speed=2, maxlen=64
    SetAddress, parent=0, parent_port=1
    Driver 0 @ 00 Skipped
    Driver 1 @ 01 Initialize
    ctrlReqOpen
    SetAddress, addr=1, ep=0
    ep entry for interface 5 ep 0 max packet size = 64
    SetAddress, speed=2, maxlen=64
    SetAddress, parent=0, parent_port=1
    ctrlReq2: left: 1, read:1, nbytes 1
    ctrlReqRead left: 1, nbytes: 1, dataptr: 1fff25e4
    InTransfer 1
    outTransfer: addr: 0x01 ep: 0x02 nbytes: 0x001f data: 0x0x2002fd88
    SetAddress, addr=1, ep=2
    Ok, now this is where it falls apart.
    Code:
    ep entry for interface 42 ep 2 max packet size = 0    pep->bIface corrupted
    SetAddress, speed=2, maxlen=0
    SetAddress, parent=0, parent_port=1
    outTransfer: SetAddress 0x00
    SetAddress, addr=1, ep=1
    ep entry for interface 208 ep 1 max packet size = 0     pep->bIface corrupted
    SetAddress, speed=2, maxlen=0
    SetAddress, parent=0, parent_port=1
    InTransfer 13
    --- frozen, until I unplug thumb drive, because it failed to init :-)

  18. #43
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    Found it... OutTransfer() method not implemented.

  19. #44
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,973
    Do you want me to try to write the OutTransfer() function?

    From "Class:08 Subclass:06 Protocol 06", I'm guessing you're testing with a USB flash drive or hard drive? I have several random ones here. Just use any? Can you can give me the .ino example file, so I'm testing with the same code?

  20. #45
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    I'll be pushing the example soon.
    It will be in
    Code:
    libraries/UHS_FS/examples/UHS_KINETIS_EHCI/UHS_FS_NEW_DEMO
    Right now I am fixing address creation, as it has always been broken.
    Once fixed you will be able to determine hub parent and port # properly just from the destination address.

  21. #46
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    Pushed it now. I'll finish fixing the awful hub code.

  22. #47
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,973
    If you want to write OutTransfer, I believe the code should look very similar to InTransfer, except you would use 0 instead of 1 in the 3rd input to init_qTD().

    in other words, change this:

    Code:
            init_qTD(data, *nbytesptr, 1, pep->bmRcvToggle, false);
    to perhaps something like this:

    Code:
            init_qTD(data, nbytes, 0, pep->bmRcvToggle, false);
    and delete the (probably buggy anyway) line which tries to read the number of bytes actually sent from the status register.

  23. #48
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,973
    So this would be my first guess...

    Code:
    uint8_t UHS_NI UHS_KINETIS_EHCI::OutTransfer(UHS_EpInfo *pep, uint16_t nak_limit, uint16_t nbytes, uint8_t *data) {
            HOST_DUBUG("OutTransfer %d\n", nbytes);
            init_qTD(data, nbytes, 0, pep->bmRcvToggle, false);
            uint8_t rcode = dispatchPkt(0, 0, nak_limit);
            uint32_t status = qTD.transferResults;
            pep->bmRcvToggle = status >> 31;
            return rcode;
    }

  24. #49
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,973
    I'm looking at this now. Seems there are 2 issues.

    1: Somehow the endpoint's maxPktSize field is zero. Obviously we can't send an OUT packet if we're not allowed to have any bytes in the packet!

    2: OUT transfers at 480 Mbit/sec use a special ping protocol. At 12 & 1.5 Mbit/sec, when a device isn't ready it answers NAK. But at high speed, the protocol is more complex. So far, dispatchPkt() does not know how to handle the case where the device responds with a NYET token, and treats it like an error.

    I'll try to do something with #2.

    On #1, for now I've got a horrible hack that just guesses how many bytes we're allowed if maxPktSize is zero.

  25. #50
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,973
    I've sent a pull request for OutTransfer().

    https://github.com/felis/UHS30/pull/41

    It has ugly workarounds for both those issues, so at least OUT transfers can work.

Posting Permissions

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