Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #31621

Re: How to snif full-duplex UART protocol between two nodes

Show all headers | View raw

On 2/22/2023 4:33 AM, Theo wrote:
> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 2/21/2023 2:59 AM, pozz wrote:
>>> Il 20/02/2023 22:52, Paul Rubin ha scritto:
>>>> pozz <pozzugno@gmail.com> writes:
>>>>> Is there something already available that I can use?
>>>>
>>>> There is a traditional hack where you make or buy a Y cable that lets
>>>> you tap the serial i/o and listen to both directions from a PC.  Then
>>>> just log the data going in and out.  When I did it I used a simple
>>>> Python script and it was able to keep up with the device we were dealing
>>>> with (might have been 1200 bps, I don't remember).  It's possible
>>>> something like that already exists for Wireshark.
>>>
>>> Do you mean "joining electrically" (AND for UART TTL levels) the two signals
>>> and connect the result to the RX signal of a single serial port on the PC?
>>
>> No.  That won't work as the two transmitters could be trying to drive the
>> line (that they think only *they* own!) to different potentials.
> 
> I think it could work with a 'diode-OR' (or open-collector) kind of a
> arrangement: either end can pull the line to the active state, but otherwise
> the line will fall back to the inactive state.  The diodes prevent the line
> being driven to opposite potentials.

The problem is that you can't guarantee that the link will be run
half-duplex.

> It would only really work protocol-wise if you could be sure both sides
> weren't talking at the same time.  That might work if there was a
> command/response protocol where you could be sure everything was
> half-duplex.  And you also wouldn't be able to tell which end a byte came
> from, unless there was internal structure in the messages (like ASCII
> commands with carriage returns on the end).

.. assuming the reply doesn't get started *while* the "redundant fluff"
at the end of the command is still on the wire (e.g., if the only commands
are A, B, C -- each terminated by a CRLF -- then an implementation might
decide to act once it has received the A, B *or* C... without bothering
to wait for the CRLF.

The problem with all (?) EIA232 comms is that there really is no
(universally) defined protocol -- even the format of the characters
can be made to vary in real time!

[E.g., I've used BREAK and LONG_BREAK as out-of-band controls to
let me *hardware* reset the device at the other end of the line
(watch for the line to stay in a spacing condition for >> one
character time and yank on the RESET- signal when that happens).
If you want to store-and-forward that, will you reproduce the
exact same spacing condition?]

> But could work as a kind of poor-man's sniffer if you had no better option.

The implementation issue I see the OP facing will be getting two
"predictable" serial ports on the same *PC* host (or, whatever other
device he uses to host the logging software).

I have a bit of code that I use to piece together RPC "calls" with
their corresponding "returns" on an ethernet link.  It's easy to
get confused thinking that THIS reply was for THAT request -- when,
in fact, it was for the one before (or after).

Given the amount of buffering in 16450-ish UARTs -- and likely more
in USB dongles (when you consider the USB stack as part of the
issue), can you ever be sure to get data from one port in any given
timing relationship to the data from another?  Esp when the stack is
likely a black box to you?

At least with old (e.g., 6402) UARTs, the buffering was limited to
exactly what *you* did in software; you only had to worry about the
character potentially on the wire and the one queued up behind it
(or ahead of it, depending on your perspective).

Buffering is a PITA to work around.  Hence the appeal of hardware
solutions; "I saw this before I saw that".

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

How to snif full-duplex UART protocol between two nodes pozz <pozzugno@gmail.com> - 2023-02-20 11:16 +0100
  Re: How to snif full-duplex UART protocol between two nodes Don Y <blockedofcourse@foo.invalid> - 2023-02-20 04:17 -0700
  Re: How to snif full-duplex UART protocol between two nodes Theo <theom+news@chiark.greenend.org.uk> - 2023-02-20 12:23 +0000
  Re: How to snif full-duplex UART protocol between two nodes Richard Damon <Richard@Damon-Family.org> - 2023-02-20 07:59 -0500
  Re: How to snif full-duplex UART protocol between two nodes Paul Rubin <no.email@nospam.invalid> - 2023-02-20 13:52 -0800
    Re: How to snif full-duplex UART protocol between two nodes pozz <pozzugno@gmail.com> - 2023-02-21 10:59 +0100
      Re: How to snif full-duplex UART protocol between two nodes Don Y <blockedofcourse@foo.invalid> - 2023-02-21 04:11 -0700
        Re: How to snif full-duplex UART protocol between two nodes Theo <theom+news@chiark.greenend.org.uk> - 2023-02-22 11:33 +0000
          Re: How to snif full-duplex UART protocol between two nodes Don Y <blockedofcourse@foo.invalid> - 2023-02-22 05:08 -0700
    Re: How to snif full-duplex UART protocol between two nodes Rick C <gnuarm.deletethisbit@gmail.com> - 2023-02-21 14:05 -0800
      Re: How to snif full-duplex UART protocol between two nodes Paul Rubin <no.email@nospam.invalid> - 2023-02-21 16:55 -0800
        Re: How to snif full-duplex UART protocol between two nodes Brian Cockburn <brian.cockburn.1959@gmail.com> - 2023-04-22 07:03 -0700
  Re: How to snif full-duplex UART protocol between two nodes Grant Edwards <invalid@invalid.invalid> - 2023-02-20 22:18 +0000
  Re: How to snif full-duplex UART protocol between two nodes Clifford Heath <no.spam@please.net> - 2023-02-21 09:58 +1100
  Re: How to snif full-duplex UART protocol between two nodes Andrew Smallshaw <andrews@sdf.org> - 2023-02-21 07:05 +0000
  Re: How to snif full-duplex UART protocol between two nodes Andrew Smallshaw <andrews@sdf.org> - 2023-02-21 07:07 +0000

csiph-web