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 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 ;)
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.)
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.
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.
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.
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!
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
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?
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.
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.
> 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.
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)
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.
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.
25 comments
[ 3.0 ms ] story [ 50.0 ms ] thread- 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 ;)
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.)
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...
Even as pure audio jack, the 3.5mm connector has two standards, with the difference on ground and mic.
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.
........ and the DEX pinout has Rx/Tx in reverse (our tip receives and our ring transmits) in comparison to the FTDI TTL setup. Wellp!
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 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.
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)
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.