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.
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,
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.)
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
Strange analogy considering that RMS got to where he is precisely by finding nails to hit much, much more than occasionally, and much, much more than most hammers.
I think it hits perfectly. He espouses that almost every vendor everywhere is doing something immoral and it will inevitably be used against you. Eventually, some of these predictions come true enough for some part of his audiences.
I don't think you've made a point about his abilities. I do think you've restated his proclivities, which reinforces the basis for the quip.
This is particularly uncharitable to someone that saw around many corners and was articulate enough to warn us about them in advance.
There's a reason there's a subreddit called "Stallman Was Right", and it's not that he was shotgun blasting opinions and landed a few of them. It's because he has a systemic understanding of the incentives our system sets up and is able to project decades into the future about how those incentives will play out.
Windows Phone was so so good - it was THE phone I recommended to users who were on feature phones/non-smart phones because the UX was so simple and clean (and obvious) - with a side effect that if you HAD a smart phone before (Palm, Apple, Android, BlackBerry, the UX was contrary to what you were used to).
Windows Phone died because MS didnt do enough to build the app ecosystem, and bailed out too soon. I also feel webOS was a lost opportunity too - in some ways it was just too ambitious for the hardware of its time.
I was one of two non-MSFT I knew of that had one.. and I bought it because an MSFT employee was showing it off and I was convinced. The concept of Tiles was great and Cortana was respectable. It felt comparable to Siri and way better than Google.
I used it for a couple years until the apps I needed started disappearing due to lack of updates.
I really wish I had messed with Windows Phone when it was a thing. They were the only ones not to just ship a clone of an existing interface ASAP. But it was closed source and offered no advantages for carriers or device makers compared to Android.
WebOS needed WASM and a lot more to be successful. I think WASM/WASI is to the point that the next major platform build out can use it.
Also, if you dont think Apollo had pork in it, you're not aware enough of the history, the various assembly plants were placed mostly for political support, the shuttle and now SLS follows the same pattern.
I think a good protocol however is key for adoption. Many a good idea has died an early death because the implementation of it was, too complex, insufficiently robust, or poorly thought out for the future.
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.
reply