AN235, Implementing a LIN Master Node Driver …

1 2002 Microchip Technology 1AN235 INTRODUCTIONLike most network protocols, the Local InterconnectNetwork (LIN) as described in the official specificationis a multi-layered system. The levels vary from thephysical interface up to the high level application, withlogical data connections between nodes at various lay-ers. This application note focuses on the implementa-tion of an interface between the physical interface andhigher level application firmware, essentially a hard-ware Driver (the shaded blocks in Figure 1). Specifi-cally, this document presents a Master node Driver thatis designed for PIC18 microcontrollers with a standardUSART module. FIGURE 1:BASIC LIN SYSTEM This application note provides a high level view of howthe LIN Driver is implemented, as well as examples ofthe actual code.

2 Those who are interested in gettingstarted right away may refer to Setting Up and Usingthe Firmware (page 8) on how to create their ownsoftware is assumed that the reader is familiar with the LINspecification. Therefore, not all of the details about LINare discussed. Refer to the references listed at the endof this document for additional information. Users interested in the implementation of LIN Slavenodes (not discussed in this document) areencouraged to visit the Microchip web site( ) for additional application notesand other OF THE DRIVERT here are five functions found in the associated examplefirmware that control the operation of the LIN interface: The LIN Transmit/Receive Daemon LIN Timekeeper LIN Transmit LIN Receive Hardware InitializationThe Transmit/Receive DaemonThe USART module is the key element used for LINcommunications.

3 Using the USART module as theserial engine for LIN has certain advantages. One par-ticular advantage is that it puts serial control in thehardware rather than in software; thus, miscellaneousprocessing can be performed while data is being trans-mitted or received. With this in mind, the Master NodeLIN Protocol Driver is designed to run in the back-ground, basically as a daemon . The user needs onlyto initiate the daemon through the transmit or receivefunctions. The daemon is interrupt driven via the USART receiveinterrupt. Because of the physical feedback nature ofthe LIN bus (Figure 2), a USART receive interrupt willoccur regardless of transmit or receive operations.

4 Bitflags are used to retain information about variousstates within the daemon between interrupts. In addi-tion, status flags are maintained to indicate errorsduring transmit or receive operations. FIGURE 2:SIMPLIFIED LIN TRANSCEIVERA uthor:Ross M. FoslerMicrochip Technology Single Wire BusHigher LevelTransceiverUSARTLIN Protocol DriverApplicationsSlave DevicesMasterVBATOpen DrainPIC18 TXRXB ufferLIN busImplementing a LIN Master Node Driver on a PIC18 Microcontroller with USARTAN235DS00235A-page 2 2002 Microchip Technology AND STATE FLAGSThe LIN daemon uses state flags to remember where itis between interrupts. When an interrupt occurs, thedaemon uses these flags to decide what is the nextunexecuted state, then jumps to that state.

5 Figure 3and Figure 4 outline the program flow through thedifferent states, which are listed and defined below. STATUS AND ERROR FLAGSW ithin various states, status flags may be set depend-ing on certain conditions. For example, if the transmit-ted break is not received as a break within the readback state, then a bit error is indicated through a statusflag. Unlike state flags, status flags are not reset auto-matically. Status flags are left for the LIN systemdesigner to act upon within the higher levels of 3:LIN HEADER FLOW CHARTI nterruptBusy TX orRX?Test for Wake-upConditionSent Break?Slow Bit Rateand Send 00hSent Sync?Reset Bit Rateand Send 55hSent ID?

6 Calculate Parityand Send IDYesRead BackReady?Test for Bit ErrorNoYesYesNoNoYesYesNoNoReturnReset Bus TimerAfrom Interrupt(to LIN Message Flow Chart ) 2002 Microchip Technology 3AN235 FIGURE 4:LIN MESSAGE FLOW CHARTCOUNT, ID, AND MESSAGEThe daemon requires a data count, an identifier byte,and a pointer to a message area to function checksum and parity are automatically calculated;however, the data count is not. Although the specifica-tion defines the message size for most of the IDs, theExtended Frame ID is not defined. The data count ofthis ID is left for the user to LIN Timekeeper FunctionThe LIN specification dictates maximum frame timesand bus IDLE times. For this reason, a timekeepingfunction is implemented.

7 This function works togetherwith the daemon and the transmit and receive func-tions. Essentially, the daemon and the transmit andreceive functions update the appropriate time, bus andframe time when called. Figure 3 and Figure 4 showwhere the timers are the timekeeping function is implemented, thetiming base is not, since there are numerous ways ofgenerating a time-base on a PIC18 is left for the LIN system designer. The examplefirmware for this application note uses Timer0 togenerate a a ByteSent SentChecksum?Send ChecksumRESET StatesReturnNoYesYesReceived Get ChecksumYesNoNoTX or RX?RXTXAI ncrementPointerDecrementCounterAdd toChecksumall Data?all Data?

8 Send a ByteIncrementPointerDecrementCounterAdd toChecksumfrom Interrupt(from LIN Header Flow Chart )AN235DS00235A-page 4 2002 Microchip Technology and Receive FunctionsAlthough the transmit and receive functions are calledseparately, they are very nearly the same differ only by one state flag. These functions basi-cally initiate the first state for either a LIN frame transmitor receive operation. Once initiated, the daemon takescontrol via a receive interrupt. The program flow isoutlined in Figure Initialization FunctionAn initialization function is provided to configureUSART operation. The state and status flags are alsocleared. Flags related to hardware interrupts andtimers are not modified.

9 FIGURE 5:TRANSMIT AND RECEIVE FUNCTION FLOWTX or RX StartBus Busy?Reset Frame Timerand Set BUSY FlagBus Sleeping?Send a BreakSend a Wake-upFinishYesNoNoYes 2002 Microchip Technology 5AN235 Implementing THE DRIVERThe core of the firmware is written in an assembly mod-ule to provide good execution performance and useless program memory. However, the examples pro-vided in this section use the C file definitions, with thecore being linked into a C programming the assembly and C include files that are providedwith the example firmware. Setup and InitializationBefore attempting to execute the LIN firmware, therelated registers and hardware must be initialized. Thel_init_hw function is provided for this reason.

10 Itsthree key tasks are: Initialize the daemon (starts the LIN Driver ) Initialize registers (sets known values) Set up a timer (sets and starts a time-base)This function has one static parameter: bit rate value for PIC18 devices is calculated usingthe baud rate equation for standard USARTs:where B is the bit rate in bits per second, X is the valueof the SPBRG register, and FOSC is the clock frequency(in Hz). The initialization function also acts as a RESET. Thus,executing this function will clear all errors, includingerrors related to the USART. EXAMPLE 1:SETUP EXAMPLES etting Up TimingThe LIN specification sets limits on the frame time andthe maximum bus IDLE time. For this reason, a timefunction, l_time_update, is provided.