Hacker News Reader

Comment by 1970-01-01 | Hacker News Reader

1970-01-01

>The baud rate was a lucky guess, but 115200 is very common on such devices.

This is a 40 year old problem that has no solution. All we would need to do is agree on exactly how to do it and set it as a standard.

https://www.eevblog.com/forum/microcontrollers/smart-auto-ba...

View on HN

(1) The "standard" is pretty impossible as long as there are cheap microcontrollers and USB-UART adapters around. If your CPU runs at 4 MHz clock, you simply cannot get 57600 baudrate going (without PLL, but 4MHz micro is not going to have it). But if you have embedded linux, you want it fast, at least 115200, maybe even 230400... But depending on the clock tree, your UART clock could be pretty low, so maybe 250000 baud is more realistic. But many cheaper adapters have problem with high speeds and/or non-standard rates, so if you expect your device to be serviced in the field with ad-hoc equipment, maybe go down to 57600 just to make sure?

(2) The solution existed for a long time: get a logic analyzer or a scope, then look at the signal. This is pretty simple and very cheap, as sub-MHz logic analyzers are like $10 today.

(3) That said, last time I had an unknown device I was too lazy to find my scope and connect it.. it was much easier to me to try a few bitrates using regular UART util output started to make sense, especially since it's often easy to tell if the bitrate is a bit off or way off.

Or we could agree to use a self-clocked format (Manchester coding or similar) so it wouldn’t be necessary to know the rate up front. It would go half as fast, but we have 4MHz UARTs nowadays so that’s no big deal for a console.

Everybody uses a USB dongle now to talk to these things anyway, so there’s no reason to stay electrically or logically compatible with RS-232.

what sort of compatibility does RS-232 doesn't represent if not electrical or logical?

I’m saying RS-232 is irrelevant both electrically and logically, if you’re already assuming people can agree on something new. There are lots of better cheap 3-wire logic-level serial protocols nowadays. The days when your PC had a literal RS-232 port on the back are long gone.

What I was trying to express is that a protocol based on simple electricity/gates and logic is so simple that it almost has to exist and almost all that RS-232 consists of.

Many 1-wire are RS-232 implementations over a "1" wire.

I have my eye on Sony 8K TV and it has RS-232.

Agreed, my suggestion is just to make that simple protocol self-clocking (which is simple to do) so you eliminate the strict yet unknowable timing requirement of “UART protocol” (I don’t know a better name for the logical protocol underlying RS-232).

Industrial automation would like a word. Seems to be slowly moving to TCP/IP but lots and lots use serial communication either internally or to the HMI/workstation.

Industrial or automotive communication is over long distances in hostile environments (as was RS-232, arguably). This is just for short logic-level comms to a debug port on a board.

I'll bet many of those implementations are SLIP Serial link IP.

Yup, if it was built in the mid 2010s or later I'll see that, but most of the machines I've worked with have been running since the 90s. Still running Windows XP etc.

Occasionally, but usually it's simpler protocols like Modbus running over serial.

FWIW, some Panasonic laptops still have real (non-USB, as opposed to their internally-USB-based) RS-232 ports. Just saying...

Are there?

If I look at a common MCU, my choices are UART, SPI and I2C. Out of those, UART is the only interface which can easily handle printf-style debug messages without additional protocols. I can manage something with SPI or I2C in a pinch, but this would be non-standard and require special software on PC side. If I really hate UART for some reason I can set up SPI master, but this will just require 2 extra wires and a very special host adapter (all the ones I saw are master-mode).

More expensive micros have CAN and Ethernet. Ethernet is nice but needs magnetics, probably overkill for debug port; plus once you have Ethernet on-board no one is happy with raw frames, so you end up with ARP, DHCP, IP, TCP and lots of memory usage. CAN is pretty cool, but developer tools are overpriced and very bad, and most larger SOCs do not have support for it. Plus you still have to select baudrate for it :)

Sadly, there does not seem to be anything "new" people could agree too... The combined inertia of billions of microcontrollers will keep UART alive forever.

... but hey, if I were a head of R&D for microcontroller company, I'd totally design my own debug protocol. It'd be pulse based (to allow random clock rates but also keep line quiet when there is no output), potentially capacitively coupled (because I hate ground loops), use single signal wire + ground (because debug channel does not need full duplex), have integrated "packet end" mark and predefined packet types for text logs and binary TLV. It'd also have fully open debug tools. But I am not designing my own chips, so I am just using UART.

To be clear, this doesn’t currently exist, but the premise was that everyone agrees to switch to something else. (Which is an unlikely premise, but maybe if something got momentum…)

Microcontrollers do have their own proprietary serial debug protocols. ARM SWD, for example, has been around for almost 15 years. It’s “proprietary”, but being ARM that means it’s in billions of chips from many manufacturers. It does require a clock line, though.

https://www.ti.com/lit/wp/spmy004/spmy004.pdf

I’m suggesting something much simpler though, just keep the UARTs and stick a Manchester encoder/decoder in between.

Funny, I always thought that going over 38400 without flow control was unstable. Times have changed I guess.

Maybe it is better to just replace it by something existing but more advanced. Ethernet, for instance.

Ethernet is nice, but for low-level debug purposes, it is significantly harder to use than UART.

With UART, you have a single integer to guess, maybe one of the 10 options. And guessing it simple, as data flows even when nothing is connected, so you can trivially find it on the PCB and scope it.

With Ethernet, you have vastly more thing to guess. Starting with Ethernet pinout, then IP address, then port, protocol and authentication. And in most cases, you are not going to be able to passively listen and get useful debug information - while I can theoretically imagine an embedded system configured with netconsole in broadcast mode, I've never seen such configuration in practice.

Yes, Ethernet is very nice if device works, but it's pretty unusable for embedded / early boot debugging.

Ethernet PHY is way more complicated & costly than a small handful of TTL GPIOs...

Reply on news.ycombinator.com