This is just a rough edited copy of some of my LIN Notes... supplied 'as is' No guarentees implied!
LIN.
Good introductions to LIN
https://www.csselectronics.com/screen/p ... anguage/en
https://www.ni.com/en-gb/innovations/wh ... --bus.html
Sources.
http://ww1.microchip.com/downloads/en/a ... 00729a.pdf
Microchip applicatio note AN729 – was written in 2000, the provided code was also in Assembler, which is out of my depth!
And it does not take advantage of the newer hardware EUART features in the PIC USART but it still contains some helpful info.
My hardware - LIN master.
I used a ECIO40P for development, this has a Microchip PIC 18F4455, this has Enhanced UART with a several features that are designed to help with LIN.
Overview - As I currently understand.
A whole LIN message, or Frame, is actually made of a sequence of asynchronous fields, SCI (serial control interface) frame transmissions.
These are essentially 8 bit bytes but with start and stop bits conforming to NRZ (non-return to-zero). Dont worry..It looks like the PICs UART will handle this side of things so we can just deal with the 8 data bits in each character.
For a very simple ‘unconditional frame’ response from a LIN slave, the Master should need to just send the message header, the slave will then respond with the data and a checksum.
The master's header needs a;
Break byte
Sync byte
ID and Parity byte. (PID)
For sending a control message to a LIN slave, the Master needs to send.
Break Field
Sync byte
ID and Parity byte. (PID)
Data Bytes – 2, 4 or 8 bytes
Check Sum.
For data values longer than 8 bits, the LSB is contained in the byte sent first and the entity MSB in the byte sent last (little-endian).
LIN Bytes
The PIC USART has features to help transmit a valid BREAK and SYNC so after reading the PIC data sheet and playing about, these were achieved.
ID and PID
Each Slave device has an Identifier (ID), this enable the master to target specific slaves to request information and request a given action is performed.
A total of total 64 ID are possible.
0-59 for normal data frames
60 & 61 are diagnostic data.
62 reserved for user-defined extensions.
63 reserved for official LIN future extensions.
Bits 0 to 3 of the ID indicate the target address of the LIN Slave.
Bits 4 to 5 the expected number of response data bytes. 2 , 4 or 8
See Microchip AN729. Page 5. Fig5.
PARITY BITS and PID
The ID is only 6 bits long (bit0 to bit5), bit6 and bit7 are used as parity bytes and provide a basic error detection this SCI frame. Once these parity bits are added to the ID, the byte is then known as the PID or Protected ID.
(I’ve found a couple of examples for calculating the parity bits ..some are total B*!!*£$£ )
Microchip AN729 and the LIN Specification gave info on this;
See Microchip AN729. Page 5. Fig5.
See LIN Spec 2.2. 2.3.1.3
My method implemented in FC look clunky...if anyone else has a better method let me know.
Upper two bits (7:6) are parity bits. Lower 6 bits (5:0) are the address.
Parity calculation method, using bitwise XOR
Parity 1 (Bit 7) = NOT( Bit1 XOR Bit3 XOR Bit 4 XOR Bit 5)
Parity 0 (Bit 6) = Bit0 XOR Bit 1 XOR Bit 2 XOR Bit 4
CHECKSUM
See LIN Spec 2.3.1.5
The last field of a frame is the checksum.
Classic checksum (LIN Slaves 1.x) contains the inverted eight bit sum with carry over all data bytes.
i.e. Sum up all of your 8 bit data bytes, allowing roll over, then bitwise invert the result.
Enhanced checksum (LIN Slaves 2.x) contains the inverted eight bit sum with carry over all data bytes and the protected identifier.
i.e. Sum up all of your 8 bit data bytes and the PID, allowing roll over, then bitwise invert the result.
As suggested in the PIC app note, I worked with an integer, monitored the value of the SUM, if this ever exceeded 256, subtracted 255.
Then cast the final value to a byte.
Use of classic or enhanced checksum is managed by the master node. So you need to know if your LIN devices are LIN 1.x or LIN 2.x slave nodes.
Frame identifiers 60 (0x3C) to 61 (0x3D) always use classic checksum.
