The Serial TTL connector we deserve(kohlschuetter.github.io) |
The Serial TTL connector we deserve(kohlschuetter.github.io) |
I added one to my single-board computer enclosure, following FTDI's wiring. Now I can easily connect whenever I need to use the serial console, and a standard 3.5mm audio extension cable will let me reach across the room without moving my main computer. Replacement parts, if I ever need them, are cheap and easy to find.
Here's the pinout:
https://www.ftdichip.com/Support/Documents/DataSheets/Cables...
Granted, you shouldn't hotplug TTL serial, but everyone™ does it anyway. (In some situations you're even forced to, to avoid reverse powering something.)
It works well for capturing serial logs, a console or software updates in development. The advantage i saw was that I could order 50 cables from a distributor and give one to everyone that works on the device.
If someone needs one on the other side of the world, they can get one from a local suppliers.
Hot plugging hasn't been a problem in my designs, I add a series resistors to the uart net and ESD protection if software developers will use it.
When I use it for other devices, like routers, SBCs and IP cameras I avoid hot plugging and leaving it connected when the device isn't powered.
So expected are:
T → T
R → R
S → S
T → S
T → R
R → S
On audio systems this is typically not an issue, since tip and ring carry signals that on any gear worth anything should have an output stage that can easily handle a connection to ground.
Even as pure audio jack, the 3.5mm connector has two standards, with the difference on ground and mic.
The same issue applies to PCB header pins.
And the same goes for 25-pin D-sub connectors, which have been widely used as RS-232, parallel printer, and SCSI ports.
Voltages vary, too.
This is why we check before wiring them to other things.
........ and the DEX pinout has Rx/Tx in reverse (our tip receives and our ring transmits) in comparison to the FTDI TTL setup. Wellp!
The safest thing is to have a 4th vref/vccio pin, then the debugger should power its tx signal from that pin, at whatever voltage it's at. Same for the RX pin, it's not nice to have a pullup to a certain voltage when the target is off.
I totally agree. And yet, the 4th pin is, from personal experience, dying out. Because people have been, er, let's say "undereducated", in how to use it correctly, and with cheap USB-TTL-serial, the circuitry to use it correctly isn't included on either side.
And then people reverse-power their boards and fry things, so the board designers remove the 4th pin.
We can't have nice things. :'(
P.S.: the "undereducation": if neither side has a Vref INPUT(!) you leave the connection open. And unless your USB-TTL-serial is very explicit about it, it does NOT have a Vref input.
At that point please, please, please just switch to the 4-wire configuration exposing V_IO (aka V_target aka ...). So many problems go away when you have that available. It's nice to have at 3.3V as well, but a lot of OTS 3.3V adapters aren't configured to make use of it.
</jk>
Less of a joke though: those aren't polarized, how do you not accidentally 180° them? Are they magnetically polarized or what?
[ed.: I didn't initially see it, they're mechanically polarized, one "short end" is flat, the other rounded.]
And yes, they're magnetically polarized according to the datasheet. To answer the sibling comment, they're through-hole soldered but frustratingly are 2.7mm not 2.54 so you'd be squeezing a little into an existing header (ignoring clearance on the side anyway). I'm not sure why the 7-pin is obsolete, they make up to 5-way active.
Or Adafruit? https://www.adafruit.com/product/5468
1. Automatic DCE-DTE detection and an interface which will rewire itself as needed to be the correct way, or you automatically know DCE vs DTE by connector gender.
2. Automatic Voltage Detection - 232 levels, TTL 5v, TTL 3v - and interfaces that are isolated enough to deal with the wrong voltage (clamping diodes or whatever), or different cable sizes for each.
3. Automatic type detection - TTL/RS-232, RS-422, RS-485, or different connector types by each.
Ideally I'd do this on a 8p8c or 10p10c connector, because of ease of making cables, with various resistance values across pins 1-8, or 1-10 to tell you what kind of interface it was.
- Chop a PCI connector and have edge fingers on the PCB
- Skedd connectors
- Micro usb with a toggle switch or solder blob to switch between SWD/UART or USB
- Low profile usb-c and have D+/- as normal, and RX/TX over the accessory pins (like audio)
- Pogo pin clips
- GH1.25 connectors
- Tag-connect meh
- If thickness of pcb allows, your PCB can plug directly into a USB-A port (Thicc pcb) or if its too thin, it can plug into a male usb-c connector from a charger cable(might bend some pins though)
etc. etc.
So just like the author, anything but Dupont connectors ;)
You can "break glass" and get the off the shelf cable delivered overnight (and you can spec it if you need a spec cable) or you can make an adapter for the 6-pin tag-connect cable and the TTL-serial adapter that you have.
The alignment mechanisms on TagConnect/EdgeConnect negate any space advantage.
Apart from that, this doesn't even touch upon the various voltage levels for logic-level serial ports, or the question of whether to Vref or not to Vref. (Or RTS/CTS.)
Nordic has a serial-over-ble profile, but it is not standard like RFCOMM.
Too bad there's no standard for debug accessory connections. Also, at that point (putting a USB-C TCPC on your board) you might as well do full usbserial…
NB: there's no orientation detection in debug accessory mode.
Adding more colors would multiply their logistic and inventory requirements, which are already hard with so many different connectors multiplied by number of pin options. Multiplying that even further by number of colors that most people would never buy isn’t a win.
If you have a portable device which needs serial connector, don't bother with weird connector and bespoke adapters which will get lost. Go for USB-C directly. As an extra bonus, USB-C is significantly more electrically rugged than raw UART input.
(this does not apply if you have some sort of multi-port serial port server, but those are pretty rare, and most likely use real RS232 voltages anyway)
So, for example, with 3-wire serial and a non-polar 3-pin connector: TXD and RXD backwards (again) so nothing talks? No worries: Flip the connector 'round 180 degrees, and it works.
Same goes for CTS, RTS, DTR, DSR, and so on.
Those magnet couplings are nice. EDAC make a non-Aliexpress version, about $25 a pair.
The point is to shave off the last cent, which is why you get a possibly-unpopulated 1×4 or 1×3 2.54mm header. Bonus points if the manufacturer designed series resistors into the board (let's say 0402 or even 0201) and left those out too to save the last 0.01 cent.
A Tag-Connect footprint has a BOM cost of zero. (Though not a TCO of zero in a closed enterprise ecosystem, as everyone needing to debug the devices needs to buy a stupid $60 pogo-pin cable.)
If you are willing to design a board with with 8p8c connector, identification resistor, and protection parts, then you might as well put RS-232/RS-422 transceiver. Those are very cheap nowadays, might even be cheaper than the connector itself. And you standardize on crossover cables, there will be no need DCE-DTE detection.
(Not that anyone would need this today. If you are connecting to existing serial port, there is USB, and USB-serial adapters are very cheap. And if you are designing a serial-based communication system, say for the robot, then CAN or RS485 are much better choices)
In my working life I've seen -
at least 3 different ways to do RS-232 on 8p8c
DTE-DCE is always an issue on standard 232, otherwise I wouldn't have so many null modem cables
232 and 3.3v TTL on the same board or assembly
3.3v and 5v TTL on the same board or assembly
Inconsistent labelling.
I'm in my mid 40's and I think there is a reasonable chance something with RS-232 serial timings will outlast me, it'd be nice to make it more foolproof, as its one of a very few interfaces that will work without drivers.
I do think as a matter of standard good design practice we should be putting clamping diodes on debug ports to prevent blowing things up if hit with the wrong voltage,
Err… if you're trying to approach the problem, the onus is on you to come up with options?
I'm not going to preclude you from being creative and coming up with a zero-cost solution that somehow magically does all this, but personally speaking I'd say the chances are minute and it's not worth my time.
I'm also not gonna try to stop you from building that thing you originally suggested, with the 8P8C or 10P10C connector and strapping pins and autodetection and whatnot, I'm just pointing out to you the issues I think it will run into. You're free to ignore my concerns. I'm a random commenter on the internet.
P.S.: calling it DTE-DCE auto detection signals to me that you haven't done a lot of work in this field; those terms are not in common use for TTL serial. People in the field would probably call it something like "TX/RX swap". (Hard to say, since it doesn't really exist.) Maybe you're an engineer for field buses or something like that though…
But yes, if someone happens to be using their serial line for some kind of sensitive signaling, then I would agree that choosing a more isolated connector (or just avoiding hotplug) would make sense.
LEGO knows exactly the demand for every color of every piece because they make the sets.
If they made 10 different colors of the connector, they’d still sell mostly white and black. Then the rest would sit on shelves and take up manufacturing line time and shelf space. Then they’d have to reprice them to sell off the colors that weren’t moving.
LEGO has none of these problems. Everything goes into a set or retail package they make. The individual loose bricks go into a limited number of options at a few retail stores.
There are Android apps that support serial over ble
It would be amazing though to make it a hermaphroditic 4 or 6pin connector. With a pinout like this:
GND TX [VrefTX VrefRX] RX GND
GND TX1+ TX1- VBUS CC1 D+ D- SBU1 VBUS RX2- RX2+ GND
GND RX1+ RX1- VBUS SBU2 D- D+ CC2 VBUS TX2- TX2+ GND
(If you do this, make sure that you don't send more than 3.3ish V over a pin, and that you're tolerant of 3.3V incoming, so that you don't explode yourself or victim devices if people randomly plug you into things. https://github.com/google/usb-cereal is a reference design for a UART over USB-C SBU adapter used for Pixel phones)
I also pointed out in that comment that USB-C debug accessory detection does not support orientation detection - and neither does the Google adapter you linked (it doesn't use debug accessory mode, and doesn't have some other solution either). As they say: "Determine correct orientation - top vs. bottom - the tool operates correctly only when SBU1 pin corresponds to TX and SBU2 pin corresponds to RX."
The fact that you can't detect orientation in debug accessory mode is a direct result of how it works: both CC lines are connected to the peer; normally the cable pulls one of the two to ground which is then your orientation reference for all the other pins. (This is also why you can't use a regular USB-C receptacle for debug accessories, it has to be direct to plug, the 2nd CC line doesn't go through the cable.)
So, if you use the SBU pins, it's not reversible anymore. If I remember correctly, debug accessories must still put USB on D+/D-, so the remaining option is to put serial RX/TX on the high speed pins, twice each on 180° positions.
I think rotation is a bit extra though. The frustration with the dupont/0.1" headers is that they're not polarized. As soon as you add a key (or a literal magnetic polarity here), that problem goes away.
There are possibly ways to handle orientation in software. If you did a 4-pin and include VCC, the pinout on the pi is hi-lo-tx-rx, so you could look for hi-lo-hi-hi and wait for some period to identify any logic transitions on the tx pin. There should always be a period where that pattern is correct, because either the output is idle (high) or it's sending a bit sequence which will also involve a high somewhere. If you ever see the "2nd" pin high, you know it's not ground. Then your serial transceiver needs some way of setting up rx/tx or tx/rx (either you remap the pins, software serial, or use an analog multiplexer).
I assume the possibility of spurious Rx state is why FTDI chose to wire Rx to the tip pin of the female TRS connector: It's the last pin to make contact with anything when plugging in, and therefore least likely to be bridged to ground. I suppose the mechanical design of any particular jack would determine whether it's possible at all.