Live data from Hacker News

The Serial TTL connector we deserve

kohlschuetter.github.io

41–50 of 80 posts

Re: The Serial TTL connector we deserve

#41
post #9
post #8

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. Replacemen…

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.

Re: The Serial TTL connector we deserve

#42
post #6

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.

Re: The Serial TTL connector we deserve

#43
post #29
post #19

Earlier quoted context omitted.

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…

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…

Re: The Serial TTL connector we deserve

#44
post #40

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…

> 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.

Re: The Serial TTL connector we deserve

#45
post #25

Earlier quoted context omitted.

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...

Re: The Serial TTL connector we deserve

#46
post #11

Earlier quoted context omitted.

And where do I put Vref, RTS, CTS, and plug detect? That's 7 pins ;) 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.…

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:

  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...

Re: The Serial TTL connector we deserve

#47

Earlier quoted context omitted.

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(?)

Re: The Serial TTL connector we deserve

#48
post #24
post #12

Earlier quoted context omitted.

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.

Re: The Serial TTL connector we deserve

#49
post #6

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.

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.

Re: The Serial TTL connector we deserve

#50

Earlier quoted context omitted.

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.

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

Post reply on HN