Issue
150 January 2003
Going
Mobile
LIFE
IN THE SLOW LANE
If
real estate is all about "location, location, location,"
the essence of LIN boils down to "cost, cost, cost."
That’s not to say there aren’t other technical objectives
and considerations. For instance, keeping EMI to a dull
roar is important as the number of ones and zeroes flying
about climbs. And, of course, reliability and durability
are always a concern in automotive applications that
have to tolerate all manners of abuse from the weather,
potholed roads, and shade-tree mechanics. Nevertheless,
if the price isn’t right, there’s no need to bother.
To
that end, LIN does a pretty good job of avoiding the
feature creep that can subvert even the most well intended
standards efforts. The pragmatism is reflected in a
strategy of leveraging existing technology while avoiding
the temptation of trying to do all and be all. As you
go through the specs, you’ll see a lot of examples of
the "Keep it simple, stupid" (KISS) principle
at work.
When
it comes to networking cost, power consumption, reliability,
EMI, and all the rest, the story is simple: speed kills.
Thus, LIN specifies a maximum data rate of 20 kbps and
even allows running at a slower rate. Though not a strict
requirement, the recommended data rates for slow, medium,
and fast devices are 2400 bps, 9600 bps, and 19.2 kbps,
respectively.
As
the rates might imply, LIN uses the familiar UART scheme.
There are some embellishments, which you’ll see a little
later, but for the most part, it’s the plain vanilla
8N1 (i.e., 1 start bit, 8 data bits, and 1 stop bit)
approach that’s been around as long as I can remember.
Because practically every designer knows how a UART
works and practically every MCU has one, the LIN folks
were wise not to reinvent this wheel.
Physically,
the network is a single-wire bus up to 40 m in length
(subject to the overall combined wire and device capacitance
limit) and accommodates up to 16 nodes. Both specs seem
more than adequate for localized subsystems such as
a door or seat.
LIN
may lack the speed and whizzy features of other networks,
but it makes up for it with a hardy constitution. The
operating voltage range is a wide 8 to 18 V, and LIN
chips are even required to survive the infamous "load
dump" 40-V surge. The transceiver must tolerate
(i.e., thermal shutdown) and automatically recover from
short circuits. The loss of ground in a particular node
doesn’t compromise the operation of the residual network.
Slew rates are controlled (1 to 3 V per microsecond)
to limit EMI.
WHO’S
THE BOSS?
I
must admit to breathing a sigh of relief at LIN’s adoption
of a simple single-master multi-slave protocol. After
all, the peer-to-peer concept is all the rage, and even
simple networks (e.g., I2C) presume to offer multi-master
capability. It must have been quite tempting for the
LIN folks to hop on the free speech bandwagon.
Frankly,
I’m glad they didn’t. Multi-master schemes always rely
on some kind of arbitration hack that invariably leads
to compromises in performance, predictability, and complexity.
By
contrast, all communication in a LIN network takes place
under the direction of a single master. There’s no arbitration
overhead or uncertainty, and slaves enjoy guaranteed
access, presuming, of course, the master chooses to
grant it. Note that a master can also act as a slave
(i.e., to itself).
One
knock on polled master-slave networks is that communication
between slaves requires a two-step process. For instance,
the master might first interrogate a window switch and
then send the appropriate command to the window motor/relay.
Not
that this would be overly burdensome, but LIN offers
a way around the concern. Although most networks are
source and destination oriented, LIN instead classifies
messages according to an identifier rather than an address.
In essence, a LIN identifier describes the meaning of
the data rather than a source or destination.
So,
using the window example, the LIN master would issue
a single message (e.g., WINDOW_SWITCH_STATUS). Both
the window switch and window control nodes detect that
they are involved, the former issuing a response (e.g.,
NONE, UP, DOWN, EXPRESS_ DOWN) and the latter grabbing
it and driving the window accordingly. The result is
de facto direct slave-to-slave communication in a single
message.
Error
handling, or "fault confinement" in LIN-speak,
is handled in a similarly laissez-faire manner. Nodes
(master and slave) monitor their own transmissions (i.e.,
compare what’s on the wire with what they’re sending),
validate checksums, and perform a variety of other error
checks.
Slaves
can note errors and report them should the master choose
to interrogate. However, keeping with the "speak
only when spoken to" master-slave concept, there
are no automatic retries or ACK/NAK handshaking. Instead,
what happens when an error is detected is left up to
the designer and application software. The spec recommends
basically ignoring intermittent errors and bailing into
the limp home mode in the face of persistent errors.
No,
it isn’t elegant, but that’s OK. Consider the window
switch message example. If there’s a glitch and it doesn’t
get through properly, is there any reason to panic and
go through a fire drill? Nope, just wait for the next
time around in the polling cycle. The slight probability
of a delay (a fraction of a second) in window response
surely isn’t a showstopper, if even noticeable.
