Download Communication - Designing a Compact and Flexible LIN

Communication - Designing a Compact
and Flexible LIN Controller
AN2045
Author: Philippe Larcher
Associated Project: No
Associated Part Family: CY8C27xxx, CY8C24xxx, CY8C22xxx
GET FREE SAMPLES HERE
Software Version: PSoC Designer™ 4.0
Associated Application Notes: None
Application Note Abstract
By utilizing the re-configuration feature of the PSoC® MCU, an efficient master or slave LIN Controller can be built that leaves
most of the processor resources for the user’s application. No external components, other than the LIN transceiver and an
optional 32 kHz crystal, are required.
Introduction
Implementing the LIN (Local Interconnect Network)
standard in microcontrollers is usually done through
software or specific hardware.
Implementation of the LIN bus in software leads to a
significant CPU overhead (40%-90%), which greatly limits
the size and performance of the user application. On the
other hand, microcontrollers with integrated LIN hardware
only represent a sub-group of larger families, allowing for
a very limited set of features and peripherals to choose
from.
Thanks to PSoC’s closely integrated software/hardware
architecture, it offers LIN users several advantages
compared to other solutions:
ƒ
A 100%-compliant LIN controller can be built from
standard digital PSoC blocks, without external logic.
ƒ
ƒ
Maximum of 10% CPU overhead.
ƒ
Dynamic re-configuration reduces the size of the LIN
controller to 3 digital blocks (5 digital and 12 analog
blocks are left for user applications). Analog functions
often required by LIN applications can directly be
implemented in analog PSoC blocks.
Fully configurable PSoC-device architecture allows for
defining a single hardware platform for multiple LIN
applications.
November 11, 2002
This Application Note is a companion document of
Cypress MicroSystems LIN Reference Design. It does not
intend to describe the precise implementation of every LIN
feature in a PSoC device (this is done in other LIN
Reference Design documents), but rather to demonstrate
how PSoC architectural characteristics can be employed
to build an optimal LIN controller. A primer on LIN is also
included with explanations on transmission protocol (the
official LIN specification is available at http://www.linsubbus.org/ after free registration).
LIN Basics
The LIN standard has been established by a set of
companies involved with the automotive domain. The
current version referenced in this Application Note
(Revision 1.2) was issued in November 2000. LIN targets
low-cost automotive networks as a complement to the
existing portfolio of automotive multiplex networks. The
main properties of the LIN bus are:
ƒ
ƒ
ƒ
Single-master, multiple-slaves (up to 16 slaves)
ƒ
ƒ
ƒ
Self-synchronization of slaves to master speed
Single-wire (max 40 m)
Speed up to 19.2 Kbps (choice is 2400, 9600, 19200
bps)
Data format similar to common serial UART format
Safe and reliable behavior with data checksums, error
detection, node defect
Document No. 001-41061 Rev. **
1
[+] Feedback
AN2045
Physical Bus
The physical LIN bus is a single line, wired-AND, with a
termination resistor in every node (1 kΩ for master, 30 kΩ
for slaves) and supplied from the vehicle power net (VBAT,
8 to 18V), as represented in Figure 1.
Apart from the Synch Break, all other fields are byte fields
where the format is the common UART 8N1 coding format
(Figure 3); one start bit (dominant), eight data bits, no
parity, one stop bit (recessive).
Figure 3. Byte Field Format
Figure 1. LIN Physical Layer
Byte field
VBAT
LSB
RT
Electronic
Control Unit
start bit
LIN bus line
GND
LIN bus logical values are named 'dominant' and
'recessive', with the following correspondence:
Logical Value
Bit Value
Bus Voltage
Dominant
0
Ground
Recessive
1
Battery
Each transceiver converts the single-wire battery-level LIN
bus into a standard UART-like two-wire interface (RX, TX).
There are several LIN transceiver manufacturers, such as
Melexis, whose TH8080 transceiver family is used on the
Cypress LIN Reference Design Kit.
8 data bit
stop bit
Synch Break
The Synch Break (Figure 4) provides a regular opportunity
for slaves to synchronize to the master’s clock. From the
master’s perspective, the dominant phase of the break
(TSYNBRK) must be at least 13-bit times long, followed by at
least 1-recessive bit time (TSYNDEL). The maximum length
of the break is not explicitly specified but must fit into the
time budget given for the whole header (THEADER_MAX = 49
bit times).
From the slave’s point of view, the Synch Break must be
detected after 11-bit times of permanent dominant state.
Given the clock tolerances allowed in a LIN network, this
ensures that any break sent by the master will be detected
as such by its slaves.
Figure 4. Synch Break Field
Synch break field
Synch field
Clock Recovery and Synchronization
While idle, the bus is in a permanent recessive state. The
master communicates with the slaves through messages
starting with a Synchronization Field in the message
header. By measuring the bit time of the synchronization
field, slaves can acquire the master transmission speed
and adjust accordingly.
Message Transfer
As represented in Figure 2, each message starts with a
header (sent by the master) including a Synchronization
break (Synch Break), a Synchronization field (Synch
Field), and an Identifier field (ID Field), followed by a
Response (sent by master or slave) composed of Data
Fields and a final Checksum Field.
TSYNBRK
Synch Field
As stated earlier, the Synch Field (Figure 5) contains the
information for slave-clock synchronization. In targeting
low-cost applications, LIN does not place excessive
frequency precision constraints (+/- 15%) on slaves, which
otherwise result in the need for a crystal or resonator.
PSoC’s internal 24 MHz (+/- 2.5%) clock provides
exceptional frequency accuracy. The master generates
messages at a precise baud rate, so slaves must be able
to synchronize with the master during each message. The
Synch Field serves this purpose: in conjunction with its
start and stop bits, the '55h' pattern provides 5 falling
edges within 8 bit times.
Figure 2. Message Frame
Figure 5. Synch Field Format
Message frame
Header
Synchronization
Break
Synch
Field
Interframe
idle state
Response
Identifier
Field
Data
Field
Data
Field
Data
Field
Data
Field
TSYNDEL
Synch field
Checksum
Field
start 0 1 2 3 4 5 6 7 stop
bit
bit
November 11, 2002
Document No. 001-41061 Rev. **
2
[+] Feedback
AN2045
Identifier Field
Slave-Not-Responding Error
The ID Field (Figure 6) defines the content and length of a
message. LIN protocol does not use direct slave
addressing by the master. Instead, each slave decodes
the ID Field to determine if it should participate in the
current message. This way a message can be sent by
master to multiple slaves, or answered by one slave that is
received by several other slaves.
The LIN master must detect an error if the message frame
has not fully completed after a given period (90, 120 or
175 bit times depending on the message-response length;
2, 4 or 8 data bytes).
Figure 6. Identifier Field
Identifier field
A no-bus-activity condition (not necessarily an error) has
to be detected by slaves if no valid Synch Break was
received for more than 25000 bit times.
Detected errors are not signaled by the LIN protocol; they
are locally flagged in each node and reported on demand.
ID0 ID1 ID2 ID3 ID4 ID5 P0
P1
start
bit
stop
bit
LIN Slave Controller Implementation
Odd parity on ID1, ID3, ID4, ID5
Even parity on ID0, ID1, ID2, ID4
ID5 ID4 Number of Data fields
0
No-Bus-Activity
0
1
2
0
1
0
4
1
1
8
2
Response Field
A message response (Figure 7) is composed of 2, 4 or 8
data fields depending on the ID Field just received,
followed by a 1-byte checksum.
Figure 7. Response Field
ID field
Due to the single master and multiple-slave network
organization, LIN slaves represent the dominant
population, covering hundreds of different applications.
Thanks to its unrivaled flexibility, PSoC’s architecture is an
optimum candidate for these applications. For this reason
we will first describe the implementation of the LIN Slave
Controller.
Figure 8 represents a LIN slave node. The PSoC device is
directly connected to TX and RX pins of the LIN
transceiver, which attaches to the LIN bus (the 30 kΩ
termination resistor is integrated into the LIN transceiver).
Frequency tolerances for LIN slave nodes allow use of the
PSoC Internal Main Oscillator without an external crystal,
so that no external components are required.
Response field
Data field
Data field
LSB
start
bit
Figure 8. LIN Slave Node with PSoC
Checksum field
Slave LIN node
LSB
Voltage
Regul.
stop
bit
VBAT
5V
Number of data fields extracted from ID field (ID4,ID5)
TX
Error Detection and Handling
Bit Error
A master or slave node sending a bit on the bus must also
monitor the bus; a bit error has to be detected when the
actual bit value of the bus is different from the value that
should be sent.
It should be pointed out that bit-time error detection
methods generally use a standard UART, which is not
compliant with LIN specification since errors are reported
on byte boundaries. The PSoC architecture allows for
immediate bit-error detection, as described later.
LIN bus
RX
Five error types are specified, three of them with
implications in the LIN controller architecture.
November 11, 2002
LIN transceiver
(e.g.TH8080)
PSoC
GND
From the LIN slave perspective, a message frame is
composed of three stages (Figure 9). Each stage requires
a different set of PSoC resources as follows:
ƒ
Synchronization Stage: covers the bus idle state,
Synch Break and Synch Field reception
ƒ
Data Receive Stage: covers the Identifier Field, and
the Response Field if data direction is master-to-slave
ƒ
Data Transmit Stage: covers the Response Field if
transfer direction is slave-to-master
Document No. 001-41061 Rev. **
3
[+] Feedback
AN2045
Figure 9. Slave Message Stages
Header
Synchronisation
Break
Synch
Field
Response
Identifier
Field
Data
Field
Synchronisation stage Data Receive
Data
Field
Data
Field
Data
Field
Checksum
Field
Data Receive or Data Transmit
Figure 11. GPIO ISR During Synchronization Stage
Synchronization (Figure 10)
This stage requires two functions, implemented in three
digital PSoC blocks:
ƒ
ƒ
A 16-bit Timer for no-bus-activity detection and breaklength measurement. Measurements are made using
the hardware capture of a timer, thus avoiding any
errors due to software latency. Timer width and clock
frequency (24V1 = 8 MHz) are selected to meet LIN
specifications, both for synchronization measurement
precision and maximum count (25,000 bit times for
no-bus-activity).
A Digital Inverter is used for hardware capture on the
RX-pin falling edge. The inverter User Module could
be replaced with the optional inverter on the timer’s
capture input to free the block for other purposes.
Figure 10. Synchronization Stage (Slave)
LIN bus
LIN Transceiver
TX pin
RX pin
interrupt
8MHz
(VC1)
clk
Value
16
16--bit
bit Timer
Timer
Capture
GPIO
ISR
interrupt
Out
Digital
Inverter
Synch break
Synch field
RX pin
start-of-break
end-of-break
(check dominant length)
nop
nop
nop
calculate baud rate
start-of-synch
(check idle length)
When the end-of-break occurs (RX rising-edge interrupt),
the dominant break length is checked by comparing the
newly captured timer value to the previously saved value.
Before returning, the GPIO ISR prepares for the next
event (start-of-Synch-field). The timer capture signal is
connected back to the Digital Inverter output (idle length of
the break still has to be measured), and the RX pin is
programmed to interrupt on a falling edge.
When start-of-Synch-field occurs, the timer-capture value
is read (and saved) and compared to the previous value
for idle length checking (parameter TSYNDEL, Figure 4). Any
error detected during the Synch Break causes the slave to
return to its initial idle state.
The baud rate can now be calculated. No change is made
to the timer-capture selection and GPIO interrupt (both on
RX falling edge). For the greatest precision, the calculation
is executed after 4 bit times, i.e., four successive GPIO
interrupts. The timer value saved on the start-of-Synchfield event is subtracted from the latest captured value and
divided by four. If the result is within specified LIN
tolerances, the corresponding baud rate will be used
during the next message stages. If not, the message is
ignored and the slave returns to idle state.
Timeout
ISR
TC
Ideally, a Synch Break will occur before the bus timeout
happens. The corresponding GPIO interrupt service
routine (ISR) reads and saves the timer captured value,
and prepares for the next event detection (end-of-break).
The timer capture signal is now directly connected to the
RX pin. The RX pin is configured to interrupt on a rising
edge (Figure 11 shows which RX edges activate the GPIO
interrupt during the Synchronization Stage).
In
While the LIN bus is idle, two interrupts are enabled:
ƒ
GPIO interrupt on the RX-pin falling edge, for start-ofbreak detection
ƒ
Timer Terminal Count, for no-bus-activity detection
(bus timeout)
November 11, 2002
Document No. 001-41061 Rev. **
4
[+] Feedback
AN2045
Data Receive (Figure 12)
Synchronization is a measurement stage. The next stages
are reception and transmission, thereby requiring different
resources. The following resources are required for data
reception:
ƒ
Baud rate generator implemented in an 8-bit Counter
(clock VC1 = 8 MHz for 9600/19200 bauds, 2.4 MHz
for 2400 bauds, and period value being set according
to previous stage calculation). Optionally, the user
can configure VC3 as the baud rate generator in order
to free a digital block for other purposes.
ƒ
ƒ
UART Receiver (1 Digital Communications block).
Counter for message timeout detection (slave-notresponding). To save hardware resources, this
function is implemented as an 8-bit Counter extended
with a software counter. The counter, clocked with the
baud rate generator output, generates an interrupt
every 5 bit times (lowest frequency compatible with
timeout-detection tolerance) which in turn increments
the software counter and checks for timeout.
Figure 12. Data Receive Implementation
LIN bus
LIN Transceiver
TX pin
RX pin
DataReceive
ISR
If the received ID is valid for the slave and corresponds to
a receive message (master-to-slave), the next data bytes
will be received without changing the PSoC device
configuration. The length of the data field is extracted from
the ID Field (see Figure 6). Data are sequentially saved in
the application buffer selected by the ID table, after which
the data checksum is calculated. When the Checksum
Field is received and tested against the calculated
checksum, a transaction status byte is saved at the top of
the data buffer for application use before switching back to
the Synchronization Stage.
Data Transmit (Figure 14)
If the received ID Field is valid for the slave and
corresponds to a transmit message (slave-to-master), the
Data Transmit Stage is entered. Following are required
resources for this stage:
ƒ
Baud rate generator (1 digital block or optionally VC3,
same as in Data Receive Stage).
ƒ
ƒ
UART Transmitter (1 Digital Communications block).
Bit-error detection, implemented with an 8-bit
Counter. As stated earlier, LIN protocol requests that
nodes sending data check the actual value present on
the bus and detect any error at the bit time it occurs.
The bit-error-detection counter generates an interrupt
in the middle of each bit sent, so that the actual value
of the RX pin can be checked against the value of the
TX pin.
Figure 14. Data Transmit Implementation
interrupt
VC1
clk
Baud Rate
(8-bit Counter)
clk
Receiver
(RX8)
RX
LIN bus
LIN Transceiver
clk
Timeout
TC
(8-bit Counter)
Timeout
management
TX pin
Receiver interrupts are generated at the character rate.
The first character received is the Identifier Field defining
message type and length. For ID Field decoding, a table is
used, telling which ID values are valid for the slave
(Figure 13).
DataTransmit
ISR
interrupt
VC1
clk
Baud Rate
(8-bit Counter)
'FFh' : end of table
November 11, 2002
Send/Receive
Buffer pointer
clk
clk
Figure 13. Identifier Table Example
Accepted ID value
RX pin
Transmitter
(TX8)
TX
Bit-time
TC
(8-bit Counter)
interrupt
Bit - error detect
ISR
The data buffer is sent at byte boundaries to the UART
transmitter, followed by the checksum byte. When the
Data Transmit Stage is complete, the transaction status
byte is updated at the top of the data buffer for application
use before switching back to the Synchronization Stage.
Document No. 001-41061 Rev. **
5
[+] Feedback
AN2045
Dynamic Re-configuration
Without dynamic re-configuration, the total number of
digital PSoC blocks needed to implement a LIN Slave
Controller in hardware would be 8:
ƒ
ƒ
ƒ
2 for 16-bit Timer (Synchronization Stage)
ƒ
ƒ
ƒ
ƒ
1 for character reception (Data Receive Stage)
Message transfer still makes use of Synchronization, Data
Transmit, and Data Receive stages, in a slightly different
manner (Figure 16).
Figure 16. Master Message Stages
Header
1 for Digital Inverter (Synchronization Stage)
Synchronisation
Break
1 for Baud Rate Generator (Data Receive and Data
Transmit stages)
1 for timeout counter (Data Receive Stage)
1 for character transmission (Data Transmit Stage)
Synchronisation stage
Synch
Field
Identifier
Field
Data
Field
Data Transmit
Data
Field
Data
Field
Data
Field
Checksum
Field
Data Transmit or Data Receive
Synchronization (Figure 17)
The difference from the slave is that the master sends the
synchronization elements. The following are required
resources for Synchronization Stage:
ƒ
Baud rate generator implemented in an 8-bit Counter
(clock VC1 = 2.4 MHz for 9600/19200 bauds, 2 MHz
for 2400 bauds, and counter period set accordingly).
ƒ
Break generator implemented in an 8-bit Counter,
clocked by the baud rate generator output. When
sending a break, duration will be 13 bit times.
ƒ
Bit-time counter implemented in an 8-bit Counter,
clocked by the baud rate generator output. This
counter allows for bit-error detection by generating an
interrupt in the middle of every bit sent to check the
RX pin value against the TX sent value.
1 for bit-error detection (Data Transmit Stage)
Because the LIN-controller host is also expected to be the
end-application microcontroller, it is of utmost importance
to minimize the number of LIN blocks, leaving most
resources to the application. This is made possible by the
dynamic re-configuration capability of PSoC blocks. Each
message stage --Synchronization, Receive, Transmit-requires three digital blocks, so applying dynamic reconfiguration between each stage limits the total number
of required blocks to three; two standard digital blocks plus
one Digital Communications block.
Response
Figure 17. Synchronization Stage (Master)
LIN Master Controller
Hardware for the LIN master (Figure 15) is almost identical
to slave hardware. The main difference is that the LIN
frequency tolerance for message-header generation now
implies the use of a 32 kHz crystal as reference for the
PSoC MCU Internal Main Oscillator.
LIN bus
LIN Transceiver
TX pin
RX pin
End of break
ISR
interrupt
TC
VC1
Also, the LIN bus pull-up resistor integrated in the
transceiver (30 kΩ) is not sufficient for master node,
therefore, an external 1 kΩ resistor is added.
clk
Baud Rate
(8-bit Counter)
Break Gen
clk
(8-bit Counter)
Out
clk
Bit-time
TC
(8-bit Counter)
Bit -error detect
ISR
interrupt
Figure 15. LIN Master Node with PSoC
Master LIN node
Voltage
Regul.
VBAT
5V
RT
For the LIN Master Controller, Synchronization ends with
break generation. The next fields, including Synch Field
and ID Field, are generated during the Data Transmit
Stage.
TX
LIN transceiver
(e.g.TH8080)
PSoC
32KHz
LIN bus
RX
GND
November 11, 2002
Document No. 001-41061 Rev. **
6
[+] Feedback
AN2045
Data Transmit
The PSoC device configuration for this stage is identical to
Slave Data Transmit configuration. Refer to paragraph 3.3
for details.
The Data Transmit Stage for the master terminates either
after sending the whole message if sender is master, or
after sending the ID Field if the message response comes
from a slave. In the second case, the Data Transmit Stage
is followed by a Data Receive Stage.
Data Receive
The PSoC device configuration for this stage is identical to
Slave Data Receive configuration. Refer to paragraph 3.2
for details.
Dynamic Re-configuration
As for slave mode, each stage in the master uses three
digital blocks (including one Digital Communications
block). By re-configuring between each stage, the LIN
master firmware re-uses the same three blocks throughout
the whole message, saving much of microcontroller
resources for the end-application.
On the firmware side, because automotive and control
applications are often real-time, the LIN driver only makes
use of interrupts, with no active loop or any blocking
functions.
Overhead measurements made on a LIN bus with
messages transferred at 19200 bauds and the PSoC CPU
running at 24 MHz, show a 0% overhead between
messages, and a maximum overhead of 10% while
sending or receiving messages.
Additionally, when not using the LIN bus, the PSoC device
is able to dynamically re-configure, thereby freeing all
digital blocks for use in the user’s application.
Summary
The PSoC architecture is optimal for LIN applications. A
full-featured LIN controller can be efficiently implemented
with a few internal resources of the device; unused
resources are available for end-application usage, and
PSoC configurability allows a large variety of applications
to be built from a single hardware platform.
Performance
The objective of the LIN controller is to be integrated in the
same microcontroller as the end-application. For this
reason, we must make sure that it does not consume
excessive resources and processing power.
We've already seen that the LIN controller implementation
(master or slave) leaves 5 of 8 digital blocks and all 12
analog blocks for the end-application.
November 11, 2002
Document No. 001-41061 Rev. **
7
[+] Feedback
AN2045
About the Author
Name:
Title:
Background:
Contact:
Philippe Larcher
Field Application Engineer
Cypress-France
20 years of activity in computer and
electronic system design. 13 years
as FAE for Cypress.
[email protected]
Tel: 33 1 69 29 88 92
In March of 2007, Cypress recataloged all of its Application Notes using a new documentation number and revision code. This new documentation
number and revision code (001-xxxxx, beginning with rev. **), located in the footer of the document, will be used in all subsequent revisions.
PSoC is a registered trademark of Cypress Semiconductor Corp. "Programmable System-on-Chip," PSoC Designer, and PSoC Express are trademarks
of Cypress Semiconductor Corp. All other trademarks or registered trademarks referenced herein are the property of their respective owners.
Cypress Semiconductor
198 Champion Court
San Jose, CA 95134-1709
Phone: 408-943-2600
Fax: 408-943-4730
http://www.cypress.com/
© Cypress Semiconductor Corporation, 2002-2007. The information contained herein is subject to change without notice. Cypress Semiconductor
Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any
license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or
safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as
critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The
inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies
Cypress against all charges.
This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide
patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a
personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative
works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress
integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source
Code except as specified above is prohibited without the express written permission of Cypress.
Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the
right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or
use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a
malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support systems
application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges.
Use may be limited by and subject to the applicable Cypress software license agreement.
November 11, 2002
Document No. 001-41061 Rev. **
8
[+] Feedback