http://www.lammertbies.nl/comm/cable/RS-232.html
which has plans for an RS-232 monitor cable. This allows you to use one
serial port to monitor a conversation between two other serial ports.
Sounds like just what you need.
On Fri, 12 Nov 1999, Riley Williams wrote:
> Hi there.
>
> Probably at least partly off topic here, but...
>
> A friend of mine will shortly be working on a driver for Linux for
> some rather specialised hardware that connects via the serial port. He
> doesn't have any technical specs for it, nor does there appear to be
> any chance of him getting any. What he does have is one sample of the
> said hardware, together with the official cable to connect it to a
> standard serial port, and the Windows 95 driver for it.
>
> The driver apparently takes over control of the relevant serial port,
> and then produces a virtual serial port that a normal terminal program
> can connect to and use to control the hardware. However, the actual
> handshake over the serial line is a complete mystery, and attempts to
> monitor it via various freely available RS232 snooper programs that
> run under Win95 have so far only succeeded in causing Win95 to BSOD a
> few times more than it would otherwise have done.
>
> Michael does have a second computer running Linux, as well as the
> primary one that dual-boots Linux and Win95, and the suggestion has
> been made that some sort of snooping by having the second machine
> monitor the actual serial link would be the next stage.
>
> The basic options I can see are as follows:
>
> 1. Have a serial lead from the Win95 machine to the Linux machine,
> with the modem plugged into a second serial port on the Linux
> machine, and a program thereon that literally copies everything
> between the two ports, but saving copies in files as well.
>
> The basic problem I can see with this approach is that if there
> are any timing dependancies in the handshake, they could easily
> be violated as a result of the latency involved.
>
> 2. Have a special lead made up, consisting basically of a serial
> extension lead with an additional lead wired in parallel and
> connecting to the PARALLEL port on the Linux machine, wired
> such that Gnd on the serial connects to Gnd on the parallel,
> and the other 8 wires on the serial each connect to one of the
> eight data wires on the parallel. The Linux machine would then
> run a program which just took a snapshot of the parallel port
> every X microseconds and filed this on the hard drive somewhere,
> repeating this for as long as necessary.
>
> This approach has the following obvious advantages:
>
> 1. As long as the sample rate exceeds twice the baud rate of
> the serial link, it is guaranteed to capture the entire
> handshake and all data transferred.
>
> 2. If there are nay timing constraints in the handshake,
> they will not be violated as the handshake between the
> Win95 box and the hardware is not being changed.
>
> The following obvious disadvantages are also apparent:
>
> 1. The interval timing on the Linux box will need to be very
> accurate. As the maximum Baud rate of a standard serial
> port is 115,200 Baud, a frequency of 333k samples every
> second, giving an inter-sample period of 3 microseconds,
> is to be recommended. This also allows leeway for the
> interval to drift slightly and still obtain sufficient
> readings to positively identify the transitions.
>
> The basic question is whether such is realisable on the
> Linux box in question, which is based on a 486dx4/75
> processor.
>
> 2. To avoid problems connected with hard drive latency in
> write operations, the system will probably need to buffer
> the handshake session to RAM, with as large a buffer as
> possible. The available system only has 32M of RAM, so
> the maximum buffer size is likely to be around 20M, or
> around a minute's worth of handshake. Is this enough?
>
> Since I have probably omitted some really obvious means of doing this,
> can anybody with any experience in this field please advise on their
> recommendations?
>
> I will note in advance that the available finance will NOT run to the
> purchase of anything beyond basic test gear, so suggestions relating
> to obtaining a digital signal analyser can be left unsaid...
>
> Finally, Michael isn't currently on L-K so if any replies can be cc'd
> to him, it would be appreciated. I don't mind whether the replies are
> on L-K or private to Michael and me as I am on L-K.
>
> Best wishes from Riley.
>
> PS: The kernel versions page is now back online at the URL below, and
> includes separate sublists both for each kernel series, and for
> each year of development.
>
> +----------------------------------------------------------------------+
> | There is something frustrating about the quality and speed of Linux |
> | development, ie., the quality is too high and the speed is too high, |
> | in other words, I can implement this XXXX feature, but I bet someone |
> | else has already done so and is just about to release their patch. |
> +----------------------------------------------------------------------+
> * http://www.memalpha.cx/Linux/Kernel/
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/