^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) PLIP: The Parallel Line Internet Protocol Device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) ================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) Donald Becker (becker@super.org)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) I.D.A. Supercomputing Research Center, Bowie MD 20715
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) At some point T. Thorn will probably contribute text,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) Tommy Thorn (tthorn@daimi.aau.dk)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) PLIP Introduction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) -----------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) This document describes the parallel port packet pusher for Net/LGX.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) This device interface allows a point-to-point connection between two
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) parallel ports to appear as a IP network interface.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) What is PLIP?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) =============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) PLIP is Parallel Line IP, that is, the transportation of IP packages
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) over a parallel port. In the case of a PC, the obvious choice is the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) printer port. PLIP is a non-standard, but [can use] uses the standard
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) LapLink null-printer cable [can also work in turbo mode, with a PLIP
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) cable]. [The protocol used to pack IP packages, is a simple one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) initiated by Crynwr.]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) Advantages of PLIP
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) ==================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) It's cheap, it's available everywhere, and it's easy.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) The PLIP cable is all that's needed to connect two Linux boxes, and it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) can be built for very few bucks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) Connecting two Linux boxes takes only a second's decision and a few
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) minutes' work, no need to search for a [supported] netcard. This might
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) even be especially important in the case of notebooks, where netcards
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) are not easily available.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) Not requiring a netcard also means that apart from connecting the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) cables, everything else is software configuration [which in principle
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) could be made very easy.]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) Disadvantages of PLIP
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) Doesn't work over a modem, like SLIP and PPP. Limited range, 15 m.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) Can only be used to connect three (?) Linux boxes. Doesn't connect to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) an existing Ethernet. Isn't standard (not even de facto standard, like
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) SLIP).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) Performance
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) ===========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) PLIP easily outperforms Ethernet cards....(ups, I was dreaming, but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) it *is* getting late. EOB)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) PLIP driver details
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) -------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) The Linux PLIP driver is an implementation of the original Crynwr protocol,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) that uses the parallel port subsystem of the kernel in order to properly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) share parallel ports between PLIP and other services.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) IRQs and trigger timeouts
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) =========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) When a parallel port used for a PLIP driver has an IRQ configured to it, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) PLIP driver is signaled whenever data is sent to it via the cable, such that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) when no data is available, the driver isn't being used.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) However, on some machines it is hard, if not impossible, to configure an IRQ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) to a certain parallel port, mainly because it is used by some other device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) On these machines, the PLIP driver can be used in IRQ-less mode, where
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) the PLIP driver would constantly poll the parallel port for data waiting,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) and if such data is available, process it. This mode is less efficient than
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) the IRQ mode, because the driver has to check the parallel port many times
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) per second, even when no data at all is sent. Some rough measurements
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) indicate that there isn't a noticeable performance drop when using IRQ-less
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) mode as compared to IRQ mode as far as the data transfer speed is involved.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) There is a performance drop on the machine hosting the driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) When the PLIP driver is used in IRQ mode, the timeout used for triggering a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) data transfer (the maximal time the PLIP driver would allow the other side
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) before announcing a timeout, when trying to handshake a transfer of some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) data) is, by default, 500usec. As IRQ delivery is more or less immediate,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) this timeout is quite sufficient.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) When in IRQ-less mode, the PLIP driver polls the parallel port HZ times
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) per second (where HZ is typically 100 on most platforms, and 1024 on an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) Alpha, as of this writing). Between two such polls, there are 10^6/HZ usecs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) On an i386, for example, 10^6/100 = 10000usec. It is easy to see that it is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) quite possible for the trigger timeout to expire between two such polls, as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) the timeout is only 500usec long. As a result, it is required to change the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) trigger timeout on the *other* side of a PLIP connection, to about
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) 10^6/HZ usecs. If both sides of a PLIP connection are used in IRQ-less mode,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) this timeout is required on both sides.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) It appears that in practice, the trigger timeout can be shorter than in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) above calculation. It isn't an important issue, unless the wire is faulty,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) in which case a long timeout would stall the machine when, for whatever
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) reason, bits are dropped.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) A utility that can perform this change in Linux is plipconfig, which is part
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) of the net-tools package (its location can be found in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) Documentation/Changes file). An example command would be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) 'plipconfig plipX trigger 10000', where plipX is the appropriate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) PLIP device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) PLIP hardware interconnection
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) -----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) PLIP uses several different data transfer methods. The first (and the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) only one implemented in the early version of the code) uses a standard
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) printer "null" cable to transfer data four bits at a time using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) data bit outputs connected to status bit inputs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) The second data transfer method relies on both machines having
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) bi-directional parallel ports, rather than output-only ``printer``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) ports. This allows byte-wide transfers and avoids reconstructing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) nibbles into bytes, leading to much faster transfers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) Parallel Transfer Mode 0 Cable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) ==============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) The cable for the first transfer mode is a standard
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) printer "null" cable which transfers data four bits at a time using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) data bit outputs of the first port (machine T) connected to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) status bit inputs of the second port (machine R). There are five
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) status inputs, and they are used as four data inputs and a clock (data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) strobe) input, arranged so that the data input bits appear as contiguous
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) bits with standard status register implementation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) A cable that implements this protocol is available commercially as a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) "Null Printer" or "Turbo Laplink" cable. It can be constructed with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) two DB-25 male connectors symmetrically connected as follows::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) STROBE output 1*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) D0->ERROR 2 - 15 15 - 2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) D1->SLCT 3 - 13 13 - 3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) D2->PAPOUT 4 - 12 12 - 4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) D3->ACK 5 - 10 10 - 5
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) D4->BUSY 6 - 11 11 - 6
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) D5,D6,D7 are 7*, 8*, 9*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) AUTOFD output 14*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) INIT output 16*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) SLCTIN 17 - 17
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) extra grounds are 18*,19*,20*,21*,22*,23*,24*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) GROUND 25 - 25
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) * Do not connect these pins on either end
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) If the cable you are using has a metallic shield it should be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) connected to the metallic DB-25 shell at one end only.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) Parallel Transfer Mode 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) ========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) The second data transfer method relies on both machines having
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) bi-directional parallel ports, rather than output-only ``printer``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) ports. This allows byte-wide transfers, and avoids reconstructing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) nibbles into bytes. This cable should not be used on unidirectional
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) ``printer`` (as opposed to ``parallel``) ports or when the machine
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) isn't configured for PLIP, as it will result in output driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) conflicts and the (unlikely) possibility of damage.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) The cable for this transfer mode should be constructed as follows::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) STROBE->BUSY 1 - 11
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) D0->D0 2 - 2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) D1->D1 3 - 3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) D2->D2 4 - 4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) D3->D3 5 - 5
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) D4->D4 6 - 6
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) D5->D5 7 - 7
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) D6->D6 8 - 8
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) D7->D7 9 - 9
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) INIT -> ACK 16 - 10
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) AUTOFD->PAPOUT 14 - 12
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) SLCT->SLCTIN 13 - 17
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) GND->ERROR 18 - 15
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) extra grounds are 19*,20*,21*,22*,23*,24*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) GROUND 25 - 25
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) * Do not connect these pins on either end
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) Once again, if the cable you are using has a metallic shield it should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) be connected to the metallic DB-25 shell at one end only.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) PLIP Mode 0 transfer protocol
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) =============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) The PLIP driver is compatible with the "Crynwr" parallel port transfer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) standard in Mode 0. That standard specifies the following protocol::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) send header nibble '0x8'
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) count-low octet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) count-high octet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) ... data octets
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) checksum octet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) Each octet is sent as::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) <wait for rx. '0x1?'> <send 0x10+(octet&0x0F)>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) <wait for rx. '0x0?'> <send 0x00+((octet>>4)&0x0F)>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) To start a transfer the transmitting machine outputs a nibble 0x08.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) That raises the ACK line, triggering an interrupt in the receiving
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) machine. The receiving machine disables interrupts and raises its own ACK
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) line.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) Restated::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) (OUT is bit 0-4, OUT.j is bit j from OUT. IN likewise)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) Send_Byte:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) OUT := low nibble, OUT.4 := 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) WAIT FOR IN.4 = 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) OUT := high nibble, OUT.4 := 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) WAIT FOR IN.4 = 0
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags