Why are surface solder pads used rather than vias for the D+/D- pins of the USB Host port on the Teensy 4.0 and 4.1? This makes mounting to a USB daughter board more difficult.
Do the D+/D- pins require dropping the voltage down from 5V to 3.3V when connecting the Teensy to a USB device? The documentation indicates this is required for all data pins.
Can the USB Device port be used in OTG mode, so that it can serve as a second USB host port?
On Teensy 4.1 the USB host port is 5 through hole pins. Here's how it's meant to work with Teensy 4.1.Originally Posted by lukexyz
On Teensy 4.0 the USB host signals are 2 bottom side pads. There simply was no room to do anything larger on Teensy 4.0. It was felt that bringing the signals to those pads was better than leaving them inaccessible.
No. Those pins are meant to connect directly.Do the D+/D- pins require dropping the voltage down from 5V to 3.3V when connecting the Teensy to a USB device?
USB doesn't use 5V signals. Only the power is 5V.
This really depends on the meaning of the word "can".Can the USB Device port be used in OTG mode, so that it can serve as a second USB host port?
No software support exists. Even if such software were published, you would also have a very unpleasant experience of needing to unplug whatever USB device(s) you're using and plug into a cable to your PC, for each time you wanted to upload any new program onto your Teensy. So if "can" means doing so in with provided libraries and software, the answer is no.
But the hardware on each port is OTG capable. In theory you could probably make a modified copy of USBHost_t36 which access the other port. That would probably be the "easy" path where little or no new code is needed, but a mountain of minor edits are needed so the global names don't conflict between the 2 copies. Or maybe even just modify the code to allow 2 instances of the main EHCI driver, if you have more appetite for writing some code than renaming tons of stuff. Either way, you'll also need to build up some sort of USB signal mux or other way to take the pain out of swapping cables around for every code update. If you're willing to go to all that trouble, then yes, the hardware capability is there so you can do it with some large amount of work.
However, USBHost_t36 supports hubs, so if you want to connect more than 1 USB device just using a hub is the easy path.
Ah, OK, sorry, I was looking at the wrong section of the pinout (USB device rather than USB host). That's great.
Since I need exactly two USB host ports during deployment, I may actually attempt this, so I do want to understand this better.
Is there any way to update the code on the Teensy 4.1 other than via the USB device port?
Does the standard method of updating code in the Teensy rely upon USBHost_t36? (I'm trying to understand what you are saying about needing to have two versions of the code.)
I do need the ability to update code during development. I don't mind swapping back and forth between a regular USB cable and an OTG cable for this. But if the code updating system in the Teensy doesn't depend upon USBHost_t36 (i.e. if only my code depends upon that library), then I don't understand why I would need two versions of the library. (Sorry, I am not familiar with the Teensy system yet -- I am at the stage of trying to pick a system for my project.)
Also I understand from what you wrote that the modifications to USBHost_t36 which would be needed to access the other port would be just changing of the primary port number or something, but that there are no actual changes needed to that library to support USB OTG per se, assuming that an OTG cable is used?
You said USBHost_t36 is designed to support hubs, so I assume it can access more than one port, but that the current code is hardwired to use just the host port for the first step in the USB chain? Is the library capable of treating the first step in the USB chain as a hub, so that both the on-board USB host port and the on-board USB device port (in OTG mode) are usable at the same time?
Will there be any hardware issues with using DMA transfers to/from both ports simultaneously (e.g. to copy a file from one USB Mass Storage device to another)? Is there sufficient memory bandwidth to support two concurrent transfers at 480Mbit/sec, so that reading from one drive can overlap with writing to the other drive, at the full USB 2.0 bandwidth?
Follow-up question: how can a USB OTG cable signal to the Teensy 4.1 that it is an OTG cable? Normally the Sense pin is shorted with GND in an OTG cable. But according to the Teensy 4.1 documentation, in the 5-pin USB Host header, there are two GND pins, and no Sense pin. Does switching to OTG mode therefore have to be done in software?
There is no support for OTG mode switching. USBHost_t36 is host only. I believe WZMX has an experimental port of some of the device code to run on the 2nd USB port, but that is also device only with no support for mode switching.
If you need OTG mode switch, you'll need to build everything yourself, from the ID pin detection to how power is handled to all the software.
USB device is the only supported way.Is there any way to update the code on the Teensy 4.1 other than via the USB device port?
No.Does the standard method of updating code in the Teensy rely upon USBHost_t36?
USBHost_t36 is hard coded to only use the 2nd USB port.I'm trying to understand what you are saying about needing to have two versions of the code.
If you want it to use the 1st port, there are 2 ways. You could make a complete duplicate copy of the library which is hard coded to use only the 1st port. Then to use both ports, your program could use 2 separate libraries. Lots of inefficient duplication of code, lots of legwork to rename all global scope names, but relatively "easy" as you just change the hardware register names to access the 1st port. No "real" programming changes.
Or you could try to modify the library to use both USB ports. Obviously that is a more elegant and "cleaner" solution. Some programming required...
Yes, that's correct.You said USBHost_t36 is designed to support hubs, so I assume it can access more than one port, but that the current code is hardwired to use just the host port for the first step in the USB chain?
You can create as many hub instances as you need and each manages the downstream ports on the connected hub.
Wow, so many questions rolled into one!Is the library capable of treating the first step in the USB chain as a hub, so that both the on-board USB host port and the on-board USB device port (in OTG mode) are usable at the same time?
Yes, USBHost_t36 supports hubs. Since there is only 1 physical USB host port on Teensy 4.1, the *only* way to use a hub is plug it into Teensy's USB host port (which I assume is what you mean by "first step in the USB chain"). You can plug hubs into hubs into hubs if you need a lot of ports. Just make sure to put enough hub instances into your program, and remember most 7 & 10 port hubs on the market today are internally just a network of 4 port hubs.
Yes, the 1st and 2nd USB ports on Teensy are fully independent. So you can use USB host while the 1st port is working as USB device.
No, there is no support for OTG mode on either port. Maybe with a lot of software work you might get either or both ports to work as OTG mode switching, but we don't have any support for that in any way at this time. You're completely on you own there! You'll need to dive into NXP's reference manual for all questions on making OTG work.
I really want to emphasize how you'll be essentially starting from zero and need to everything yourself to get OTG mode switching to work.
Probably not an issue. The DMA goes over the AXI bus which is 64 bits wide at 150 MHz. That's a theoretical 1200 MByte/sec bandwidth. Both USB ports at sustained max 480 Mbit speed (not deducting substantial USB protocol overhead) is only 1/10th of that theoretical AXI bandwidth.Will there be any hardware issues with using DMA transfers to/from both ports simultaneously (e.g. to copy a file from one USB Mass Storage device to another)? Is there sufficient memory bandwidth to support two concurrent transfers at 480Mbit/sec,
But as far as I know, we've never managed to get either port to run as sustained max theoretical bandwidth. It's not DMA, but software that ultimately limits the speed. With my PC, the fastest I've seen on device mode is about 50%. I believe Frank ran some tests which were faster, but still not at 80% (the amount bulk transfer is supposed to be able to use if everything is perfectly fast on both host and device). I recently did some testing with USB host MIDI transmit. The simple 2 ping-pong style buffer and normal code sending the messages achieves about 25%. It's pretty easy to get to 10-20% of the USB bandwidth, and with quite a bit of optimization work 50% or more is doable. But sustained use of it all for real applications requires extremely difficult optimizations. In many cases with device mode we've seen the main limitation isn't on the Teensy side, but overhead on the PC side.
I looked through the NXP documentation to try to find what would be necessary to switch port 1 from device to host mode. I found the info on the USB_nUSBMODE register for setting the mode. However, this code for USBHost_t36's ehci.cpp makes it look like the code changes to support two ports would not be trivial:
I really don't know enough about USB to make deep changes to USBHost_t36. I'm sure I will miss something like this, and would have no idea how to debug the problem.Code:if (stat & USBHS_USBSTS_TI0) { // timer 0 - used for built-in port events //println("timer0"); if (port_state == PORT_STATE_DEBOUNCE) { port_state = PORT_STATE_RESET; // Since we have only 1 port, no other device can // be in reset or enumeration. If multiple ports // are ever supported, we would need to remain in // debounce if any other port was resetting or // enumerating a device. USBHS_PORTSC1 |= USBHS_PORTSC_PR; // begin reset sequence println(" begin reset"); } else if (port_state == PORT_STATE_RECOVERY) { port_state = PORT_STATE_ACTIVE; println(" end recovery"); // HCSPARAMS TTCTRL page 1671 uint32_t speed = (USBHS_PORTSC1 >> 26) & 3; rootdev = new_Device(speed, 0, 0); } }
I guess I'll just submit this as a feature request then, for a future version of USBHost_t36: since both supported USB ports are OTG-capable, it would be great if both could be operated as host ports. Thanks!
For now I guess I'll have to use a second hub board to get two host ports.
Posting Permissions
Reply With Quote