PaulStoffregen
Well-known member
Which 2 pins would you want to give up to be able to have this?
Next new Teensy , USB-C Please.
- Thread starter jdredd
- Start date
Which 2 pins would you want to give up to be able to have this?
defragster
Senior Member+
Indeed, look at a 4.0 and 4.1 ALL the middle ground is used at least once both top and bottom - not to mention the unseen middle layers. The d+ and d- are packed under the connector close to the source - as they need to be for reliable use.
snowsh
Well-known member
Off the top of my head, how about where the tiny d+ and d- pads are? change them to holes. I know this is a bit of a quick suggestion, and would required removal of the socket to work properly, but if there was a film of insulation over the USB socket it would be isolated from these holes and pins could potentially be soldered from underneath without having to remove the socket? I would personally then remove the socket for my needs and switch to pins. I have tried using the pads (soldering tiny wires destroyed the pads on the t4.1. and the pogo pins are too expensive here). My current solution is a cable cut short and soldered to my PCB which contains the sockets....
Alternatively, if this is for a new teensy 4.x variant; extend the PCB by one pin length.... if that's a possibility, I would like to see a T4.x with some SDRAM like the daisy seed. I am currently working on some ML code that I will most likely have to run on a second board (daisy seed currently top runner) to overcome the memory constraints....
looking at the board, how about adding 2 extra pins to the host connector? it seems like there would be space there next to the USB socket
Attachments
, particularly in regards to constexpr processing.
defragster
Senior Member+
If the board offered a creative place for two pins Paul would find it. Don't forget it is also using the longer USB-C connector so even that room wouldn't be there if a T_4,x were configured for that to fit.
Note on tool change in Beta thread - IIRC nothing until 1.61 to get this one shipped
As this discussion already happened some years ago, I repeat my suggestion to elongate the d+ d- pads to make the more solder friendly. That would IMHO be sufficient for most cases. Through holes invite to complex wiring, reducing possible throughput.
PaulStoffregen
Well-known member
No
Davidelvig
Well-known member
USB C would simplify my designs, and make them more reliable!
You know, true pin access (rather than pads) to the D+/D- data connections would be almost as good. Maybe better! I worry about my pogo pins.
You know, true pin access (rather than pads) to the D+/D- data connections would be almost as good. Maybe better! I worry about my pogo pins.
Hi Paul, have you some new info about the USB-C implementation? This feature becomes more and more important for a lot of users....
BriComp
Well-known member
I don't believe there has been any announcement about a future USB-C implementation.
joepasquariello
Well-known member
Why would you say that? It will eventually. We don’t know when.
PaulStoffregen
Well-known member
Yes, I can confirm USB-C is absolutely on the required list of features for all future Teensy boards.
Whether Teensy 4.0 and Teensy 4.1 get a redesign just to change the USB connector is much less certain.
Whether Teensy 4.0 and Teensy 4.1 get a redesign just to change the USB connector is much less certain.
I'd hope not, or at least if they do a way is found to have the port function as both device and host like the existing ones can. I have code that does this:
Code:
if (usb_configuration == 0) {
static TeensyUSBHost1 usb;
usb.begin();
} else {
// keep port in host mode
puts("Starting MTP...");
MTP.begin();
MTP.addFilesystem(mfs, "TEENSY");
poll_mtp = true;
}PaulStoffregen
Well-known member
Are you talking about the resistors connected to the CC pins?
Yes.
I have to try this, I'm using a micromod with a USB-C connector and been thinking about using it as a host as well so, this can be super useful. the variable usb_configuration comes from cores or somewhere else on your code?
Awesome, is your teensyUSBHost class public?
GitHub - A-Dunstan/teensy4_usbhost: USB Host library for Teensy 4.x
USB Host library for Teensy 4.x. Contribute to A-Dunstan/teensy4_usbhost development by creating an account on GitHub.
github.com
There's not many device drivers but if you're familiar with libusb the interface is similar.
PaulStoffregen
Well-known member
I don't see a way to make this work on USB-C with hosts that require the resistors on the other end. However, at least today many don't care, so for those common cases you can probably just connect the cable and have it work as it does with Micro-B and A connectors.
But if the resistors are checked (eg, MacOS on M-series Macs), as least with my limited imagination right now, it kinda looks like a catch-22 problem.
Writing "if (usb_configuration == 0)" checks whether a host as completed enumeration. For hosts that check the resistors, enumeration won't even begin if the pulldown resistors aren't seen. So if you want to work for that case, you must have pulldown resistors turned on.
Then if you switch the USB hardware into host mode, what is to be done with those pulldown resistors?
But if the resistors are checked (eg, MacOS on M-series Macs), as least with my limited imagination right now, it kinda looks like a catch-22 problem.
Writing "if (usb_configuration == 0)" checks whether a host as completed enumeration. For hosts that check the resistors, enumeration won't even begin if the pulldown resistors aren't seen. So if you want to work for that case, you must have pulldown resistors turned on.
Then if you switch the USB hardware into host mode, what is to be done with those pulldown resistors?
That's why I'm saying I don't want this change made to the T4.x, unless there's a way to make them float when they're not wanted.
An idea that occurred to me - and this is honestly just spitballing, I haven't put a lot of deep thought into it - since USB-C is directionless and requires the resistors to be connected to pairs of pins, perhaps one pair could have cuttable links to disable them for one orientation of the connector only. Is it hacky? Yes, but it's an uncommon solution for an uncommon problem.