■ FIGURE 8. LANC command bytes.
After clearing the terminal, the program drops into a
loop. At the top, we use the rxtime() method to
wait for the idle space between packets. Here's
how that works: rxtime() will wait up to n
milliseconds for a character. If no character is
available, it will return -1. By waiting for 2 ms and
receiving a -1, we know that we've located the
idle gap between packets. Another loop displays
the next eight bytes in hex format. The output of
the program is shown in Figure 7.
■ FIGURE 7. LANC input test.
When you run this program, you'll see the last
six bytes flipping around, though the first two —
both $FF — will never change. These are the
command bytes and are changed by an external
controller. That will be the focus of our LANC
MODBUS and similar protocols, we'll look for this idle
period to set up for the start of the next packet/frame.
Let me show you how easy this is using a standard
pub main | c
LANC command sequences are two bytes, and these
are expected at the beginning of the packet. The
responsibility of the external controller is to wait for the
command bytes and then modify them during
transmission. Again, this is possible due to the open-collector nature of the LANC connection.
lanc.start(SIO, SIO, %1100, 9_600)
term.start(RX1, TX1, %0000, 115_200)
The camcorder will always output $FF, which is to
say that the pull-up is keeping the LANC line high for
each bit. This allows the controller to modify these bytes
by pulling selective bits low.
c := lanc.rxtime(2)
until (c < 0)
Building a serial UART for 9600 baud is no trouble at
all for the Propeller; in fact, it's easily done in Spin. There
is a special consideration with sending command bytes
for LANC: The camcorder generates the start bits for
each byte. To be candid, Spin is probably fast enough to
deal with this, too, but I chose to write my driver in
PASM; it's easy enough to do, and we have better
precision over timing.
In this example (jm_lanc_monitor_ez.spin), we're
using two copies of FullDuplexSerial: one for the LANC
input; the other for displaying the LANC data on the PST
terminal. The LANC serial is set up for half-duplex/open
mode at 9600 baud.
Have a look at Figure 8. This diagram represents the
LANC line when the command bytes $18 and $33
(record toggle) are being transmitted. The red line
indicates control of the LANC serial line from the
camcorder side; the blue line represents control of LANC
serial from the controller side. Note that the controller
can only pull the LANC line low; the pull-up in the
camcorder keeps the line high for the idle state and one
bit. The critical point is that the camcorder exerts the
start bits for all bytes in the packet. That is to say that our
serial output to the LANC device will be modified from
14 July 2014