Messages in this thread | | | Date | Sat, 13 Nov 1999 06:04:18 -0600 (CST) | From | <> | Subject | Re: [OT] Reverse Engineering |
| |
While trying to build an MMJ to DB25 cable for my VT-320, I found:
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/
| |