diff options
Diffstat (limited to 'static/freebsd/man4/lp.4 3.html')
| -rw-r--r-- | static/freebsd/man4/lp.4 3.html | 231 |
1 files changed, 0 insertions, 231 deletions
diff --git a/static/freebsd/man4/lp.4 3.html b/static/freebsd/man4/lp.4 3.html deleted file mode 100644 index 0977e1f2..00000000 --- a/static/freebsd/man4/lp.4 3.html +++ /dev/null @@ -1,231 +0,0 @@ -<table class="head"> - <tr> - <td class="head-ltitle">LP(4)</td> - <td class="head-vol">Device Drivers Manual</td> - <td class="head-rtitle">LP(4)</td> - </tr> -</table> -<div class="manual-text"> -<section class="Sh"> -<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1> -<p class="Pp"><code class="Nm">lp</code> — <span class="Nd">printer port - Internet Protocol driver</span></p> -</section> -<section class="Sh"> -<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1> -<table class="Nm"> - <tr> - <td><code class="Nm">ifconfig</code></td> - <td><var class="Ar">plip0</var> <var class="Ar">myaddress hisaddress</var> - [<code class="Fl">-link0</code>] - <p class="Pp"> - <br/> - <code class="Cd">device ppbus</code> - <br/> - <code class="Cd">device plip</code> - <br/> - <code class="Cd">device ppc</code></p> - </td> - </tr> -</table> -</section> -<section class="Sh"> -<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1> -<p class="Pp">The <code class="Nm">lp</code> driver allows a PC parallel printer - port to be used as a point-to-point network interface between two similarly - configured systems. Data is transferred 4 bits at a time, using the printer - status lines for input: hence there is no requirement for special - bidirectional hardware and any standard AT-compatible printer port with - working interrupts may be used.</p> -<p class="Pp">During the boot process, for each <code class="Nm">plip</code> - device which is probed and has an interrupt assigned, a corresponding - <code class="Nm">network</code> device is created.</p> -<p class="Pp">Configuring an <code class="Nm">lp</code> device with - <a class="Xr">ifconfig(8)</a> causes the corresponding - <code class="Nm">parallel port bus</code> to be reserved for PLIP until the - network interface is configured 'down'.</p> -<p class="Pp">The communication protocol is selected by the - <code class="Cm">link0</code> flag:</p> -<dl class="Bl-tag"> - <dt id="link0"><a class="permalink" href="#link0"><code class="Fl">-link0</code></a></dt> - <dd>(default) Use <span class="Ux">FreeBSD</span> mode (LPIP). This is the - simpler of the two modes and therefore slightly more efficient.</dd> - <dt id="link0~2"><a class="permalink" href="#link0~2"><code class="Cm">link0</code></a></dt> - <dd>Use Crynwr/Linux compatible mode (CLPIP). This mode has a simulated - Ethernet packet header, and is easier to interface to other types of - equipment.</dd> -</dl> -<p class="Pp">The interface MTU defaults to 1500, but may be set to any value. - Both ends of the link must be configured with the same MTU.</p> -<section class="Ss"> -<h2 class="Ss" id="Cable_Connections"><a class="permalink" href="#Cable_Connections">Cable - Connections</a></h2> -<p class="Pp">The cable connecting the two parallel ports should be wired as - follows:</p> -<div class="Bd Pp Li"> -<pre> Pin Pin Description - 2 15 Data0 -> ERROR* - 3 13 Data1 -> SLCT - 4 12 Data2 -> PE - 5 10 Data3 -> ACK* - 6 11 Data4 -> BUSY - 15 2 ERROR* -> Data0 - 13 3 SLCT -> Data1 - 12 4 PE -> Data2 - 10 5 ACK* -> Data3 - 11 6 BUSY -> Data4 - 18-25 18-25 Ground</pre> -</div> -<p class="Pp">Cables with this wiring are widely available as 'Laplink' cables, - and are often coloured yellow.</p> -<p class="Pp">The connections are symmetric, and provide 5 lines in each - direction (four data plus one handshake). The two modes use the same wiring, - but make a different choice of which line to use as handshake.</p> -</section> -<section class="Ss"> -<h2 class="Ss" id="FreeBSD_LPIP_mode"><a class="permalink" href="#FreeBSD_LPIP_mode">FreeBSD - LPIP mode</a></h2> -<p class="Pp">The signal lines are used as follows:</p> -<dl class="Bl-tag"> - <dt id="Data0"><a class="permalink" href="#Data0"><i class="Em">Data0 (Pin - 2)</i></a></dt> - <dd>Data out, bit 0.</dd> - <dt id="Data1"><a class="permalink" href="#Data1"><i class="Em">Data1 (Pin - 3)</i></a></dt> - <dd>Data out, bit 1.</dd> - <dt id="Data2"><a class="permalink" href="#Data2"><i class="Em">Data2 (Pin - 4)</i></a></dt> - <dd>Data out, bit 2.</dd> - <dt id="Data3"><a class="permalink" href="#Data3"><i class="Em">Data3 (Pin - 5)</i></a></dt> - <dd>Handshake out.</dd> - <dt id="Data4"><a class="permalink" href="#Data4"><i class="Em">Data4 (Pin - 6)</i></a></dt> - <dd>Data out, bit 3.</dd> - <dt id="ERROR*"><a class="permalink" href="#ERROR*"><i class="Em">ERROR* (pin - 15)</i></a></dt> - <dd>Data in, bit 0.</dd> - <dt id="SLCT"><a class="permalink" href="#SLCT"><i class="Em">SLCT (pin - 13)</i></a></dt> - <dd>Data in, bit 1.</dd> - <dt id="PE"><a class="permalink" href="#PE"><i class="Em">PE (pin - 12)</i></a></dt> - <dd>Data in, bit 2.</dd> - <dt id="BUSY"><a class="permalink" href="#BUSY"><i class="Em">BUSY (pin - 11)</i></a></dt> - <dd>Data in, bit 3.</dd> - <dt id="ACK*"><a class="permalink" href="#ACK*"><i class="Em">ACK* (pin - 10)</i></a></dt> - <dd>Handshake in.</dd> -</dl> -<p class="Pp">When idle, all data lines are at zero. Each byte is signalled in - four steps: sender writes the 4 most significant bits and raises the - handshake line; receiver reads the 4 bits and raises its handshake to - acknowledge; sender places the 4 least significant bits on the data lines - and lowers the handshake; receiver reads the data and lowers its - handshake.</p> -<p class="Pp">The packet format has a two-byte header, comprising the fixed - values 0x08, 0x00, immediately followed by the IP header and data.</p> -<p class="Pp">The start of a packet is indicated by simply signalling the first - byte of the header. The end of the packet is indicated by inverting the data - lines (i.e., writing the ones-complement of the previous nibble to be - transmitted) without changing the state of the handshake.</p> -<p class="Pp">Note that the end-of-packet marker assumes that the handshake - signal and the data-out bits can be written in a single instruction - - otherwise certain byte values in the packet data would falsely be - interpreted as end-of-packet. This is not a problem for the PC printer port, - but requires care when implementing this protocol on other equipment.</p> -</section> -<section class="Ss"> -<h2 class="Ss" id="Crynwr/Linux_CLPIP_mode"><a class="permalink" href="#Crynwr/Linux_CLPIP_mode">Crynwr/Linux - CLPIP mode</a></h2> -<p class="Pp">The signal lines are used as follows:</p> -<dl class="Bl-tag"> - <dt id="Data0~2"><a class="permalink" href="#Data0~2"><i class="Em">Data0 (Pin - 2)</i></a></dt> - <dd>Data out, bit 0.</dd> - <dt id="Data1~2"><a class="permalink" href="#Data1~2"><i class="Em">Data1 (Pin - 3)</i></a></dt> - <dd>Data out, bit 1.</dd> - <dt id="Data2~2"><a class="permalink" href="#Data2~2"><i class="Em">Data2 (Pin - 4)</i></a></dt> - <dd>Data out, bit 2.</dd> - <dt id="Data3~2"><a class="permalink" href="#Data3~2"><i class="Em">Data3 (Pin - 5)</i></a></dt> - <dd>Data out, bit 3.</dd> - <dt id="Data4~2"><a class="permalink" href="#Data4~2"><i class="Em">Data4 (Pin - 6)</i></a></dt> - <dd>Handshake out.</dd> - <dt id="ERROR*~2"><a class="permalink" href="#ERROR*~2"><i class="Em">ERROR* - (pin 15)</i></a></dt> - <dd>Data in, bit 0.</dd> - <dt id="SLCT~2"><a class="permalink" href="#SLCT~2"><i class="Em">SLCT (pin - 13)</i></a></dt> - <dd>Data in, bit 1.</dd> - <dt id="PE~2"><a class="permalink" href="#PE~2"><i class="Em">PE (pin - 12)</i></a></dt> - <dd>Data in, bit 2.</dd> - <dt id="ACK*~2"><a class="permalink" href="#ACK*~2"><i class="Em">ACK* (pin - 10)</i></a></dt> - <dd>Data in, bit 3.</dd> - <dt id="BUSY~2"><a class="permalink" href="#BUSY~2"><i class="Em">BUSY (pin - 11)</i></a></dt> - <dd>Handshake in.</dd> -</dl> -<p class="Pp">When idle, all data lines are at zero. Each byte is signalled in - four steps: sender writes the 4 least significant bits and raises the - handshake line; receiver reads the 4 bits and raises its handshake to - acknowledge; sender places the 4 most significant bits on the data lines and - lowers the handshake; receiver reads the data and lowers its handshake. - [Note that this is the opposite nibble order to LPIP mode].</p> -<p class="Pp">Packet format is:</p> -<div class="Bd Pp Li"> -<pre>Length (least significant byte) -Length (most significant byte) -12 bytes of supposed MAC addresses (ignored by FreeBSD). -Fixed byte 0x08 -Fixed byte 0x00 -<IP datagram> -Checksum byte.</pre> -</div> -<p class="Pp">The length includes the 14 header bytes, but not the length bytes - themselves nor the checksum byte.</p> -<p class="Pp">The checksum is a simple arithmetic sum of all the bytes (again, - including the header but not checksum or length bytes). - <span class="Ux">FreeBSD</span> calculates outgoing checksums, but does not - validate incoming ones.</p> -<p class="Pp">The start of packet has to be signalled specially, since the line - chosen for handshake-in cannot be used to generate an interrupt. The sender - writes the value 0x08 to the data lines, and waits for the receiver to - respond by writing 0x01 to its data lines. The sender then starts signalling - the first byte of the packet (the length byte).</p> -<p class="Pp">End of packet is deduced from the packet length and is not - signalled specially (although the data lines are restored to the zero, idle - state to avoid spuriously indicating the start of the next packet).</p> -</section> -</section> -<section class="Sh"> -<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE - ALSO</a></h1> -<p class="Pp"><a class="Xr">ppbus(4)</a>, <a class="Xr">ppc(4)</a>, - <a class="Xr">ifconfig(8)</a></p> -</section> -<section class="Sh"> -<h1 class="Sh" id="BUGS"><a class="permalink" href="#BUGS">BUGS</a></h1> -<p class="Pp">Busy-waiting loops are used while handshaking bytes, (and worse - still when waiting for the receiving system to respond to an interrupt for - the start of a packet). Hence a fast system talking to a slow one will - consume excessive amounts of CPU. This is unavoidable in the case of CLPIP - mode due to the choice of handshake lines; it could theoretically be - improved in the case of LPIP mode.</p> -<p class="Pp">Polling timeouts are controlled by counting loop iterations rather - than timers, and so are dependent on CPU speed. This is somewhat stabilised - by the need to perform (slow) ISA bus cycles to actually read the port.</p> -</section> -</div> -<table class="foot"> - <tr> - <td class="foot-date">March 4, 1996</td> - <td class="foot-os">FreeBSD 15.0</td> - </tr> -</table> |