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, 231 insertions, 0 deletions
diff --git a/static/freebsd/man4/lp.4 3.html b/static/freebsd/man4/lp.4 3.html new file mode 100644 index 00000000..0977e1f2 --- /dev/null +++ b/static/freebsd/man4/lp.4 3.html @@ -0,0 +1,231 @@ +<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> |