4 ms·

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

• amelius 3y ago
  Maybe it is better to just replace it by something existing but more advanced. Ethernet, for instance.
  • beambot 3y ago
    Ethernet PHY is way more complicated & costly than a small handful of TTL GPIOs...
  • theamk 3y ago
    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.
• theamk 3y ago
  (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.
• wrs 3y ago
  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.
  • detourdog 3y ago
    what sort of compatibility does RS-232 doesn't represent if not electrical or logical?
    • wrs 3y ago
      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.
      • Rediscover 3y ago
        FWIW, some Panasonic laptops still have real (non-USB, as opposed to their internally-USB-based) RS-232 ports. Just saying...
      • bongodongobob 3y ago
        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.
        • wrs 3y ago
          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.
        • detourdog 3y ago
• mannyv 3y ago
  Funny, I always thought that going over 38400 without flow control was unstable. Times have changed I guess.