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