Xcell Journal: The authoritative journal for programmable ... - Xilinx

Automotive
Cost
Speed
Network Per Node
CAN Up to 1 Mbps $2
LIN 20 Kbps $1
weight of wiring, increasing fuel efficiency,
and reducing handling time and manufacturing
costs. CAN also needs a 5V supply
for the bus, whereas LIN only requires 2V.
Table 1 shows the relative merits of LIN
versus CAN.
In summary, LIN offers these benefits:
• Complementary to CAN as an ultralow-cost
sub-network
• Self-synchronization mechanism means
no quartz oscillator required
• Low-cost silicon implementation using
on-chip UART or SCI
• Single wire + low baud rate = reduced
harness cost
• No protocol license fee
Microcontroller Implementation
There are many ways to implement LIN in
semiconductors:
• Software: bit bashing
• Software: UART implementation
• Hardware: MCU with dedicated
LIN port
• Hardware: PLD
Let’s look at each way and explore the
benefits and pitfalls of each.
Software: Bit Bashing
A LIN node can be implemented in many
microcontrollers (MCUs) with no additional
hardware except for a physical layer
driver device. It can be implemented using
existing on-chip MCU resources such as
timers, GPIO, and interrupts – effectively
“bit bashing.”
This type of implementation does have
restrictions – designers must adhere to
Requirements Size in Programmable Logic
Crystal oscillator,
two wires, 5V bus supply
348 slices (FPGA)
Single wire 256 slices (FPGA)
40M line length or 216 macrocells (CPLD)
Table 1 – CAN versus LIN
strict real-time programming constraints to
meet the full LIN specification. This is
expensive with respect to MCU timing and
on-chip resources and leaves very little
bandwidth for other application code.
LIN nodes based purely on “bit bashing”
may also be complicated to test, particularly
when integrated with existing
RTOSs. With this type of implementation,
it would be very difficult to achieve accurate
bit timing measurement and control
and may not be power efficient or practical.
Software: UART Implementation
LIN was originally conceived to make use
of existing UARTs within standard MCUs,
along with on-chip timers, GPIO, interrupts,
and serial ports. This is a better way
of implementing than simply “bit bashing”
but may have certain limitations in designs
that already use the on-chip serial port for
other tasks.
This implementation may also burden
the application code with LIN protocol
requirements and will complicate the
design and testability of the code. This
method also needs to be complemented
with GPIO functionality for error checking
and synchronization purposes and
requires CPU activity throughout LIN
message exchange. Therefore, it is not the
most power-efficient solution.
Hardware: MCU
with Dedicated LIN Port
An MCU with dedicated LIN port may
appeal to more designers, as it uses offthe-shelf
verified silicon. Thus, it will not
burden the software application with LIN
protocol processing, as shown in the previous
examples. This type of micro is well
suited for CAN-to-LIN bus bridging
applications where a need exists to pass
data between the two networks. This
implementation also tends to be less
power hungry than the equivalent software
solution.
As with most emerging networks,
however, the availability of silicon and
relatively high cost may be an issue and
create long lead times – so forward planning
is a must with respect to ordering
devices. One of the potential downfalls of
using these devices is when more than one
LIN is needed. For example, in an ECU
gateway, you may need to use more than
one MCU – which will impact part costs,
manufacturing costs, stocking costs, and
PCB complexity.
If your design requires something outside
of the specification provided by the
silicon vendor, this may also cause issues,
A LIN node can be implemented in many microcontrollers
(MCUs) with no additional hardware
except for a physical layer driver device.
as these fixed function parts allow little or
no flexibility for customization. The
devices still require an external bus transceiver
chip and a degree of real-time processing
in the MCU.
Distributed MCU solutions can also
result in complex design and test issues
associated with software-based designs;
designers may need to explore all potential
fault and interrupt loop states so that no
strange indeterminate states occur.
Exhaustive testing is costly, however, and
the test vectors can take longer to write
than the design code itself.
94 Xcell Journal Winter 2004