FTDI (the company practically synonymous with TTL serial adapters) uses 3.5mm tip-ring-sleeve connectors for this. In other words, a common headphone jack.
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.
That really sucks for hotplugging since TRS connectors sliding in basically make random connections before seating properly.
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.)
I've been using this ftdi cable too for the last 15 years or so and, while trs isn't a great connector, I haven't had any issues in practice.
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.
My scenario is connecting terminal emulators to getty or u-boot, which I think is a common one. A blip of line noise when plugging in would be barely considered an annoyance, easily cleared by pressing Backspace.
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.
There's a small risk of CPUs and I/O pins getting fried if GND levels aren't equalized first and instead that equalizing force would go through those pins. One could argue that it's hardware designer's responsibility to save users from such things, but then again, using a better connector than TRS can be one of them.
Thing is, for a serial TTL connector to become ubiquitous, it needs to cover at least something like 99% of scenarios. Or maybe 95%. 3.5mm TRS ain't that, and thus just increases general diversity in connectors.
In my experience noise on hot-plugging the serial adapter is a complete nonissue. I'm sure it matters for you, sometimes. But for this kind of embedded work, I'd say it's important far, far less than 1% of the time.
In my experience with... it's maybe 20? ... embedded boards, junk during boot breaks the boot flow for about half of them. And attaching quickly after target powerup is very often the crux of the exercise, to get to the bootloader fast enough before it moves on, but also you don't have the shifters (or Vref pin) in place to be able to attach beforehand...
Since I once had the case where junk on the line (from a wiggly connection) caused Magic Sysrq requests I'm fully on your side. No junk tolerated for potential hot plug connections.
I'm aware of serial breaks, but this is the first I've heard of them being interpreted as SysRq by Linux. That could be handy. Thanks for the tip.
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.
Using a male TRS 3.5mm audio connector is something you should do with care. When you hotplug that connector the plug's tip (T) may first make contact with the sleeve (S) of the receptible, then briefly hit the ring (R) until it finally lands on the tip connector. Same goes for the plug ring (R) which may have contact with the sleeve (S) of the receptible.
So expected are:
T → T
R → R
S → S
and what can happen briefly is:
T → S
T → R
R → S
Depending on what you're using the connector for, that can ruin your day. Likely this isn't an issue on serial connections, but I have seen people use that connector for power..
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.
Every vendor defines their audio jack connector serial port differently. It is very dangerous to use 3.5mm jack. There is no pinout standard of using 3.5mm.
Even as pure audio jack, the 3.5mm connector has two standards, with the difference on ground and mic.
Well, not every vendor does it differently, because there are far more vendors than possible wiring permutations on a 3-contact connector... but I understand what you mean.
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.
Funny - in the retail industry, we use a 1/4" jack instead that runs straight RS232 level traffic (for "DEX" - data exchange - typically sending invoices to a merchant from a route driver, or pulling data from vending machines on a route).
........ and the DEX pinout has Rx/Tx in reverse (our tip receives and our ring transmits) in comparison to the FTDI TTL setup. Wellp!
One thing that i see often: just because both your debug cable and your target runs at the same voltage (eg: 3.3V), doesn't mean it's safe to plug them together. You could easily have a situation where your target or your debugger is off, so at that point you're powering the off thing through the uart pins (the esd diode on the pin).
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.
> 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.
> I assume that all connections use 3.3V signal levels. Should I ever come across 5V signals, I would probably use a larger Julet M8 for differentiation. OpenWrt writes that some routers already ship with incompatible 1.8V or 2.5V logic. Should the time arrive that I need to work with those, I would probably use this little fella called Micro Q ....
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.
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.
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
So it always plugs at a 180° rotation, connecting RX to TX. And any cable also rotates 180°. Since you always have an odd total of (connections + cables), you always get the right connection...
Better yet, you could add more pins and switch them to using differential pairs to make it extensible for more use cases. While you're at it, you could have pins on both the top and bottom of the connector, and use a pair of sense pins to detect orientation, so that super specialized use cases can use every single pin available on the connector.
If only you could buy receptacles for this for like five cents a pop...
(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.
Frankly I'm amazed that a solution exists that isn't hundreds of dollars. Some of these niche connectors can be really spendy.
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).
For a minute there, I was picturing a connector with an odd number of pins (3), and was actually hoping that they were indeed non-polarized. This would allow for ground to be on the middle pin and for directional signals to radiate outward from there.
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.
If you have money to burn, get some LEMO push-pull connectors. They'll run you about $80 for a pair of each gender, but when you use them, you understand why trendy audio gear and instrumentation/optical OEMs use them. Occasionally when I make a project I treat myself and use them. Cheaper options are Mini XLR and Hirose HR10. Molex make a lot of wire-wire, but they're typically not rated for more than 25-50 cycles.
Those magnet couplings are nice. EDAC make a non-Aliexpress version, about $25 a pair.
One side could be flush with an enclosure, but it's not clear how you attach the other side to a cable. There doesn't appear to be any housing to cover soldered wires, for instance.
I would tell anyone who is doing a new traditional serial connector/cable to add the following -
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.
At that point it's not a debug connector anymore. Note there's a pseudo-standard for V.24/RS232 on RJ45 already, and nobody uses it for debug connectors since (a) you'd need a RS232 transceiver and (b) RJ45 connectors are honking huge.
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.)
I think they mean the debug adapter should auto-detect all these things, not the debug port. You'd have one adapter you could plug in to anything and it would usually magically work.
yes, largely - even if its just pin headers adding a detect line which shows a resistance between it and ground would be an improvement.
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…
That sounds completely useless. Who needs a standard that is not actually standardizing anything?
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)
you are over-engineering it. At the end of the day, it's a debug connector, when you use it, you should know what you are doing. The more thing you add to debug connector, the more thing you have to debug when the debug connector not working.
What you are describing is going to be nightmare to work with - i.e. when you will have automatic detection of levels and it will decide to push RS232 into 3V3 MCU then you will have dead, maybe one of the kind prototype or dead expensive production device
I cannot count how many PCBs I did with various quick connect ideas to have a fast way to debug..
- 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 ;)
They are ok, put them into production for around 250units. Was very excited about them, but plugging and unplugging is not as graceful, and sometimes you stab yourself with their sharp pins.
I'm going back to mounting a usb-c connector on the pcb me thinks.
Yes. For about 98% of embedded, you want the pinout for the TC2030-FTDI-C232HD-DDHSP-0-DTR cable that has DTR and RTS on it for STM32, ESP32, and Arduino-style bootloaders. It's 3.3V only iirc. Power is delivered by the cable on pin 1 so leave that terminal disconnected if it's an issue.
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 only things with a chance at succeeding in this space are putting USB-serial directly on the board + USB-C, or alternatively bluetooth classic RFCOMM profile. (The latter is a very long shot.)
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.)
Indeed… a fact making me really sad about BLE :(. The Nordic profile might become widespread enough to become de-facto standard, but AFAIK isn't quite widespread enough yet, i.e. people are still homebrewing almost the same thing(?)
Home Assistant and it’s relative esphome just added serial-proxy support. Basically you can use any esp32 board to add smart capabilities for old devices via serial port.
Ideally you wouldn't need to expose a TTL serial debug port to begin with. Maybe on a prototype you would want this but I'd rather just have a single connector that can expose everything (jtag or swd). Bonus points if the interface chip is on the board so it's just a USB port
FUSB307B is amazing for this, it has a hardware DBG output pin indicating that a USB-C debug accessory mode connection has been made. Perfect for connecting a mux and putting SWD & serial on some USB-C pins.
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.
Well the first problem you will hit I'd that very likely you will need to protect or isolate those lines from ESD. This will raise price of device and it will get denied just in these grounds.
ESD diode costs are nothing compared to the connector headers or even dealing with the mechanical complications of exposing Just One More Thing. Seriously, they're cheap.
I always wonder why Molex makes only black and white connectors. This makes it needlessly difficult to use different connectors for different purposes. Same with phoenix contact but there it's mostly green terminal blocks. Is it so difficult to just offer some more colors?
They’ll make them in any color you want if you order enough.
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.
Making them in different colors is the easy part. Inventorying and selling them is the hard part.
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.
on Aliexpress, Julet M6 pigtail pair is $2.99, while USB-TTL breakout (with female USB-C connector) is $1.40 - even for nice CP2102 with unique serial number.
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)
FWIW, my initial thought here was not transistor-transistor logic but through-the-lens (re: camera light metering). I was excited to learn that maybe someone had waded through the stovepiped mess of TTL metering across camera manufacturers and developed an open-source solution.
FTDI (the company practically synonymous with TTL serial adapters) uses 3.5mm tip-ring-sleeve connectors for this. In other words, a common headphone jack.
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...
That really sucks for hotplugging since TRS connectors sliding in basically make random connections before seating properly.
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.)
I've been using this ftdi cable too for the last 15 years or so and, while trs isn't a great connector, I haven't had any issues in practice.
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.
They're not random connections; they're predictable. I'm not worried about Tx briefly touching Rx or ground in these devices.
Random in the time sense. You'll get junk on your serial line, depending on the scenario that can matter a lot.
My scenario is connecting terminal emulators to getty or u-boot, which I think is a common one. A blip of line noise when plugging in would be barely considered an annoyance, easily cleared by pressing Backspace.
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.
There's a small risk of CPUs and I/O pins getting fried if GND levels aren't equalized first and instead that equalizing force would go through those pins. One could argue that it's hardware designer's responsibility to save users from such things, but then again, using a better connector than TRS can be one of them.
Thing is, for a serial TTL connector to become ubiquitous, it needs to cover at least something like 99% of scenarios. Or maybe 95%. 3.5mm TRS ain't that, and thus just increases general diversity in connectors.
In my experience noise on hot-plugging the serial adapter is a complete nonissue. I'm sure it matters for you, sometimes. But for this kind of embedded work, I'd say it's important far, far less than 1% of the time.
In my experience with... it's maybe 20? ... embedded boards, junk during boot breaks the boot flow for about half of them. And attaching quickly after target powerup is very often the crux of the exercise, to get to the bootloader fast enough before it moves on, but also you don't have the shifters (or Vref pin) in place to be able to attach beforehand...
Since I once had the case where junk on the line (from a wiggly connection) caused Magic Sysrq requests I'm fully on your side. No junk tolerated for potential hot plug connections.
What byte sequence on a Tx/Rx/Gnd serial line can trigger Sysrq key sequences?
It's not a byte sequence, it's a BREAK == pulling the line low for longer than a byte, i.e. invalid serial framing on the stop bit.
I'm aware of serial breaks, but this is the first I've heard of them being interpreted as SysRq by Linux. That could be handy. Thanks for the tip.
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.
Using a male TRS 3.5mm audio connector is something you should do with care. When you hotplug that connector the plug's tip (T) may first make contact with the sleeve (S) of the receptible, then briefly hit the ring (R) until it finally lands on the tip connector. Same goes for the plug ring (R) which may have contact with the sleeve (S) of the receptible.
So expected are:
and what can happen briefly is: Depending on what you're using the connector for, that can ruin your day. Likely this isn't an issue on serial connections, but I have seen people use that connector for power..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.
Every vendor defines their audio jack connector serial port differently. It is very dangerous to use 3.5mm jack. There is no pinout standard of using 3.5mm.
Even as pure audio jack, the 3.5mm connector has two standards, with the difference on ground and mic.
Well, not every vendor does it differently, because there are far more vendors than possible wiring permutations on a 3-contact connector... but I understand what you mean.
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.
Funny - in the retail industry, we use a 1/4" jack instead that runs straight RS232 level traffic (for "DEX" - data exchange - typically sending invoices to a merchant from a route driver, or pulling data from vending machines on a route).
........ and the DEX pinout has Rx/Tx in reverse (our tip receives and our ring transmits) in comparison to the FTDI TTL setup. Wellp!
This one?
https://en.wikipedia.org/wiki/DEX_(protocol)
https://www.cable-tester.com/dex-connector-pin-out/
https://www.storedex.com/abcs-of-dex
One thing that i see often: just because both your debug cable and your target runs at the same voltage (eg: 3.3V), doesn't mean it's safe to plug them together. You could easily have a situation where your target or your debugger is off, so at that point you're powering the off thing through the uart pins (the esd diode on the pin).
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.
> 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.
> I assume that all connections use 3.3V signal levels. Should I ever come across 5V signals, I would probably use a larger Julet M8 for differentiation. OpenWrt writes that some routers already ship with incompatible 1.8V or 2.5V logic. Should the time arrive that I need to work with those, I would probably use this little fella called Micro Q ....
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.
Nice but it’s huge! I’d prefer something smaller like these 3 pin magnetic connectors from Aliexpress. https://a.aliexpress.com/_c4CtK0gj
And where do I put Vref, RTS, CTS, and plug detect? That's 7 pins ;)
</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.]
You'll be wanting these: https://www.digikey.com/en/products/detail/edac-inc/686C0731...
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
Yes, yes :). I was really joking with the 7 pins.
It would be amazing though to make it a hermaphroditic 4 or 6pin connector. With a pinout like this:
So it always plugs at a 180° rotation, connecting RX to TX. And any cable also rotates 180°. Since you always have an odd total of (connections + cables), you always get the right connection...Better yet, you could add more pins and switch them to using differential pairs to make it extensible for more use cases. While you're at it, you could have pins on both the top and bottom of the connector, and use a pair of sense pins to detect orientation, so that super specialized use cases can use every single pin available on the connector.
If only you could buy receptacles for this for like five cents a pop...(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 noted this in https://news.ycombinator.com/item?id=48079649
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.
Frankly I'm amazed that a solution exists that isn't hundreds of dollars. Some of these niche connectors can be really spendy.
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).
For a minute there, I was picturing a connector with an odd number of pins (3), and was actually hoping that they were indeed non-polarized. This would allow for ground to be on the middle pin and for directional signals to radiate outward from there.
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.
If you have money to burn, get some LEMO push-pull connectors. They'll run you about $80 for a pair of each gender, but when you use them, you understand why trendy audio gear and instrumentation/optical OEMs use them. Occasionally when I make a project I treat myself and use them. Cheaper options are Mini XLR and Hirose HR10. Molex make a lot of wire-wire, but they're typically not rated for more than 25-50 cycles.
Those magnet couplings are nice. EDAC make a non-Aliexpress version, about $25 a pair.
One side could be flush with an enclosure, but it's not clear how you attach the other side to a cable. There doesn't appear to be any housing to cover soldered wires, for instance.
Do you solder them to a PCB directly?
They have PCB mount versions also I think.
I found Julet connectors incredibly hard to disconnect once plugged in. I can’t get a good grip on anything.
They’re good for eBikes because they’re sturdy and don’t disconnect easily, but I dread un-/plugging them.
I would tell anyone who is doing a new traditional serial connector/cable to add the following -
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.
At that point it's not a debug connector anymore. Note there's a pseudo-standard for V.24/RS232 on RJ45 already, and nobody uses it for debug connectors since (a) you'd need a RS232 transceiver and (b) RJ45 connectors are honking huge.
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.
> the point is to shave off the last 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.)
I think they mean the debug adapter should auto-detect all these things, not the debug port. You'd have one adapter you could plug in to anything and it would usually magically work.
yes, largely - even if its just pin headers adding a detect line which shows a resistance between it and ground would be an improvement.
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,
I'm open to other options, the biggest things is DTE-DCE auto detection
> I'm open to other options,
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…
That sounds completely useless. Who needs a standard that is not actually standardizing anything?
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)
you are over-engineering it. At the end of the day, it's a debug connector, when you use it, you should know what you are doing. The more thing you add to debug connector, the more thing you have to debug when the debug connector not working.
What you are describing is going to be nightmare to work with - i.e. when you will have automatic detection of levels and it will decide to push RS232 into 3V3 MCU then you will have dead, maybe one of the kind prototype or dead expensive production device
Depends on what you make the default as.
I mostly just go with 3.5mm audio jacks; FTDI makes a prebuilt cable: https://ftdichip.com/products/ttl-232r-5v-aj/
Pine64 use audio sockets for debug uarts.
I cannot count how many PCBs I did with various quick connect ideas to have a fast way to debug..
- 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 ;)
How did the skedd connectors work out? I assume Wuerth redfit? I'm looking at ordering some to try them.
They are ok, put them into production for around 250units. Was very excited about them, but plugging and unplugging is not as graceful, and sometimes you stab yourself with their sharp pins. I'm going back to mounting a usb-c connector on the pcb me thinks.
We had one commonly accepted connector with a well defined standardized pinout: DB-9/DE-9 with PC serial connector pinouts.
We had, but it's way too big for many of today's devices.
TagConnect or EdgeConnect ftw.
Is there a standard for TTL-serial pinout on those? I'm not aware of one, only for SWD…
Yes. For about 98% of embedded, you want the pinout for the TC2030-FTDI-C232HD-DDHSP-0-DTR cable that has DTR and RTS on it for STM32, ESP32, and Arduino-style bootloaders. It's 3.3V only iirc. Power is delivered by the cable on pin 1 so leave that terminal disconnected if it's an issue.
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.
.100 headers tend to be smaller than most TagConnect/EdgeConnect footprints and you don't have to use expensive custom cables.
The alignment mechanisms on TagConnect/EdgeConnect negate any space advantage.
TagConnect is too fragile. Broken off way too many of the little plastic "hooks" that go through the board.
The only things with a chance at succeeding in this space are putting USB-serial directly on the board + USB-C, or alternatively bluetooth classic RFCOMM profile. (The latter is a very long shot.)
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.)
Microcontrollers that support BLE are getting so cheap this really is becoming an option. Hopefully with some button that activates it.
RFCOMM is old Bluetooth, not BLE.
Nordic has a serial-over-ble profile, but it is not standard like RFCOMM.
Indeed… a fact making me really sad about BLE :(. The Nordic profile might become widespread enough to become de-facto standard, but AFAIK isn't quite widespread enough yet, i.e. people are still homebrewing almost the same thing(?)
I mean, sure there are still rough edges, but it's not like rs232 over Juliet is some widely supported standard.
There are Android apps that support serial over ble
Home Assistant and it’s relative esphome just added serial-proxy support. Basically you can use any esp32 board to add smart capabilities for old devices via serial port.
Ideally you wouldn't need to expose a TTL serial debug port to begin with. Maybe on a prototype you would want this but I'd rather just have a single connector that can expose everything (jtag or swd). Bonus points if the interface chip is on the board so it's just a USB port
FUSB307B is amazing for this, it has a hardware DBG output pin indicating that a USB-C debug accessory mode connection has been made. Perfect for connecting a mux and putting SWD & serial on some USB-C pins.
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.
Well the first problem you will hit I'd that very likely you will need to protect or isolate those lines from ESD. This will raise price of device and it will get denied just in these grounds.
ESD diode costs are nothing compared to the connector headers or even dealing with the mechanical complications of exposing Just One More Thing. Seriously, they're cheap.
I always wonder why Molex makes only black and white connectors. This makes it needlessly difficult to use different connectors for different purposes. Same with phoenix contact but there it's mostly green terminal blocks. Is it so difficult to just offer some more colors?
They’ll make them in any color you want if you order enough.
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.
I mean, LEGO can make the same brick in many different colors. With much lower tolerances.
Making them in different colors is the easy part. Inventorying and selling them is the hard part.
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.
Have you seen what LEGO costs though?
You can solve that problem with a bit of heat shrink if you really want to.
If you want something with very small pcb footprint and DIY cheap cable try Hack connect https://arcade.makecode.com/hardware/dbg
on Aliexpress, Julet M6 pigtail pair is $2.99, while USB-TTL breakout (with female USB-C connector) is $1.40 - even for nice CP2102 with unique serial number.
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)
Ideally I'd like to standardize on something that disconnects easily rather than breaking a different part.
FWIW, my initial thought here was not transistor-transistor logic but through-the-lens (re: camera light metering). I was excited to learn that maybe someone had waded through the stovepiped mess of TTL metering across camera manufacturers and developed an open-source solution.