LIN protocol

[coderatchance]

Hello all and happy 26!

Time allows me to put together the LIN protocol. The hardware seems to be working!

I am on 1626 as master and 1624 as slave, both have the TJA1027 transceivers and 2nd serial is used for the debugging on both.

Started with the so called LIN frame, but cannot get around it, I can successfully observe the output on the "lin bus" via the LOGIC analyser. For reference I am following this doc, its "recent" lin version, namely 2.1.

Here is the (starting) code:

The setup:

#define LIN_BAUD 19200

//the pin to enable the TRANSCIEVER TJA1021 -> connected to the WAKE_N pin 2 SLP_N
byte txEnPin = 12;

void setup() {

  pinMode(txEnPin, OUTPUT);

  //LIN setup
  Serial.swap(0);

  Serial.begin(LIN_BAUD, SERIAL_8N1 ); // using non parity on stop 1 bit
  
  //Serial.begin(SERIAL_AUTOBAUD | LIN_BAUD); // there is a solution for Auto baud...
  
  //normal, print out serial
  Serial1.swap(0);
  Serial1.begin(9600);
  Serial1.println(" dev board 2: --- ATtiny1626 LIN Master Starting --- ");

 //activate the Transceiver 
  digitalWrite(txEnPin, HIGH);
  
}

The header test:

In general, the LIN frame starts with the header that has the 'break, sync and PID field', see p. 28 for more...

void sendHeader(uint8_t pid) {
  // 1. Manually generate Break Field
  pinMode(PIN_PB2, OUTPUT); // Default TX pin for ATtiny1626 is PB2
  digitalWrite(PIN_PB2, LOW);
  
  // Calculate delay: 13 bits at 9600 baud ≈ 1354us
  // Formula: (1,000,000 / BaudRate) * 13
  delayMicroseconds(1354); 
  
  digitalWrite(PIN_PB2, HIGH);
  delayMicroseconds(104); // Break Delimiter (at least 1 bit time)

  // 2. Resume Hardware Serial for Sync and PID
  //Serial.begin(9600); 
  Serial.write(0x55);  // Sync Field
  Serial.write(pid);   // Protected Identifier

  Serial1.print("Sending header... "); 
  Serial1.println(pid, HEX);
}

The analyser capture:

Apparently this works, however, I guess that the error (violet) on LIN: Data is due to the fact the Frame is complete ?

Anyway, next follows the "complete LIN frame" :

void sendLINFrame(uint8_t id, uint8_t* data, uint8_t len) {
  //uint8_t pid = getPID(id);
  uint8_t pid = pid_Calc(id);
  //uint8_t checksum = calculate_Enhanced_Checksum(pid, data, len);
  uint8_t checksum = checksum_Calc(pid, data, len);

  // 1. Double Break (approx 26 bit-times at 19200 baud)
  //Serial.end();
  
  //pinMode(PIN_PA1, OUTPUT); 
  pinMode(PIN_PB2, OUTPUT);
  
  //digitalWrite(PIN_PA1, LOW);
  digitalWrite(PIN_PB2, LOW);
  
  delayMicroseconds(1400); // 26 bits * 52us/bit
  
  //digitalWrite(PIN_PA1, HIGH);
  digitalWrite(PIN_PB2, HIGH);
  
  delayMicroseconds(100);  // Break Delimiter


  //Serial.doubleBreak();
  //Serial.breakAndSync(uint8_t factor = 1)

  // 2. Send Header (Sync + PID)
  //Serial.begin(LIN_BAUD);
  
  Serial.write(0x55);  // Sync
  Serial.write(pid);   // Enhanced PID

  //sendHeader(id);

  // 3. Send Data & Checksum
  for(uint8_t i = 0; i < len; i++) {
    Serial.write(data[i]);
  }
  Serial.write(checksum);

  // Debug Print
  Serial1.print("Master Sent ID: 0x");
  Serial1.print(id, HEX);
  Serial1.print(" | PID: 0x");
  Serial1.print(pid, HEX);
  Serial1.print(" checksum: ");
  Serial1.println(checksum);
}

Including the PID and Checksum callculations:

//my calculate the PID
uint8_t pid_Calc(uint8_t ID)
{
  //if(ID>0x3F) Error_Handler();
  uint8_t IDBuf[6];
  for (int i = 0; i < 6; i++)
  {
    IDBuf[i] = (ID >> i) & 0x01;
  }
  uint8_t P0 = (IDBuf[0] ^ IDBuf[1] ^ IDBuf[2] ^ IDBuf[4]) & 0x01;
  uint8_t P1 = ~((IDBuf[1] ^ IDBuf[3] ^ IDBuf[4] ^ IDBuf[5]) & 0x01);

  ID = ID | (P0 << 6) |  (P1 << 7);
  //return protective id
  return ID;
}

//My CHECKSUM calculate the Checksum (enhanced option)
uint8_t checksum_Calc(uint8_t PID, uint8_t *data, uint8_t size)
{
  uint8_t buffer[size + 2];
  uint16_t sum = 0;
  buffer[0] = PID;

  for (int i = 0; i < size; i++)
  {
    buffer[i + 1] = data[i];
  }

  for (int i = 0; i < size + 1; i++)
  {
    sum = sum + buffer[i];
    if (sum > 0xff)
      sum = sum - 0xff;
  }
  //invert the result
  sum = 0xff - sum;
  return sum;
}

My 1st consideration is wether the "delay", for example, used for the "delimiters", e.g. see break delimiter:
delayMicroseconds(100); // Break Delimiter
I guess this should not be actual delay() which stops the whole uC, but rather a "pause", do I understand this properly?

Here is the analyser output:

And here is the loop()

void loop() {

  uint8_t dataPayload[8] = {0xFF, 0x12, 0x23, 0x34, 0x45, 0x56, 0x67, 0xFF};
 
  sendLINFrame(0x1A, dataPayload, 8); // Example ID 0x1A

  delay(1000); 
  
}

To conclude, I am not sure where I am making it working, but somehow I cannot get read of the LIN: Data error (the violet bar).
It looks that "checksum" is not OK? For example, the calculated checksum seems to be : 121 while the analyser finds it: 79 .
Not sure what is going on :)

Best.

PS wanted to use the Serial Double break as described here
but not sure how to work it out?

[coderatchance]

Upgrade 👍 But not there yet 👎

Sometimes I "can't see the forest for the trees", as it goes... anyway, the break field of the header is missing...
Looked at the tiny's data sheet and there no hw, namely peripheral support :/
So manual will have to do :)

Generating the "header" manually ?

void sendLINFrame(uint8_t id, uint8_t* data, uint8_t len) {
  

  uint8_t pid = pid_Calc(id);
  uint8_t checksum = checksum_Calc(pid, data, len);

  //1. sending my Break?
  sendLINHeader_master(pid);  //the new break?

  // 2. Send Header (Sync + PID)
  Serial.write(0x55);  // Sync
  Serial.write(pid);   // Enhanced PID

  // 3. Send Data & Checksum
  for(uint8_t i = 0; i < len; i++) {
    Serial.write(data[i]);
  }
  Serial.write(checksum);

  // Debug 
  Serial1.print("No.: ");
  Serial1.print(i);
  Serial1.print(" ");
  Serial1.print("Master Sent ID: 0x");
  Serial1.print(id, HEX);
  Serial1.print(" | PID: 0x");
  Serial1.print(pid, HEX);
  Serial1.print(" checksum: ");
  Serial1.println(checksum);
}

void sendLINHeader_master(uint8_t pid) {

  // 1. Calculate bit timing for LIN baud
  const uint32_t baud = LIN_BAUD;
  const uint32_t bitTime_us = 1000000 / baud;
  
  // 2. MANUALLY SEND BREAK: Disable USART to control the TX pin
  USART0.CTRLB &= ~USART_TXEN_bm; 
  PORTB.DIRSET = PIN2_bm;      // Ensure PB2 is output
  PORTB.OUTCLR = PIN2_bm;      // Drive LOW
  
  //make this unblocking ???
  delayMicroseconds(bitTime_us * 13); // 13-bit Break
  
  // 3. SEND DELIMITER: Drive HIGH
  PORTB.OUTSET = PIN2_bm;
  
  //make this unblocking ???
  delayMicroseconds(bitTime_us * 1);  // 1-bit Delimiter
 
  // 4. HAND OFF TO USART: Re-enable for the rest of the frame
  USART0.CTRLB |= USART_TXEN_bm;
  USART0.CTRLB |= USART_RXEN_bm;
}

Here it is , more green than red, as it should be :)

Next should be the slave, that should be possible due to the fact that tiny is supports this in the usart peripheral ... fingers crossed !

Question 1: the code and LIN frame is "made", hopefully properly, wondering, if the delays that are in 'us' should be made as non-blocking, indeed, they are short, but its blocking the processor and "other work", right? See the next question.

Question 2: when looking at the analysis of the Frame, the warning is found actually the Frame error:

when looking at the whole frame, it looks only one warning is found :

_Looking at the "response and the header" of the Frame,
from the code and analyser perspective,
I am wondering, if we can conclude that the Frame error in the header is due to the blocking delay used?

_ For example, there is no delay used in the response? Moreover, when the delay is inserted in the response part of the frame , something like delay(2), which is a lot in this case, the response falls apart...
Indeed, the non-blocking delay should be created, right? Would not be even better to explore the "Serial REF" if the break, etc. over-there is useful for this?

Best.

PS for those who have the spare time , wondering where to find the slave. Started, but cannot get around the Serial.read() , do we have the example(s) where I could explore this more?

[coderatchance]

Did some reading and it looks that these Tinys 1626, 1624' do not have the "on-board" U(S)ART peripheral with the so-called 'LIN break field' ? Which is apparently only required for the Master. However, there seems to be the Slave support, more below.

Anyway, after looking at the Serial Ref of the recent megaTinyCore (updated to the latest version as of Jan 2026) it looks the so-called Serial.breakAndSync(); does not want to compile, which would be very helpful, maybe I am using it wrong, please advice how to use it?However, there are other practical solutions for such a case, next follows one of them.

The analysis :

The idea is to slow down the baud rate while sending the 0x00 and then returning it back to the normal LIN baud rate (in my case, 9600). Apparently this is the industry practice when dealing with the uC without "on board break field" :)

void LIN_SendBreak(uint32_t normalBaud) {
  // 1. Save original baud rate
  uint16_t originalBaud = USART0.BAUD;

  // 2. Set Baud Rate for Break (1.5x slower)
  // Formula for ATtiny1626: BAUD = (64 * fclk_per) / (16 * f_baud)
  USART0.BAUD = (uint16_t)((originalBaud * 15) / 10);

  // 3. Send 0x00 to create the 13-bit dominant pulse
  while (!(USART0.STATUS & USART_DREIF_bm));
  USART0.TXDATAL = 0x00;

  // 4. Wait for transmission to complete
  while (!(USART0.STATUS & USART_TXCIF_bm));
  USART0.STATUS |= USART_TXCIF_bm; // Clear flag

  // 5. Restore original baud rate
  USART0.BAUD = originalBaud;

  // 6. Mandatory Break Delimiter (at least 1 bit high)
 // either 9600 or 19200, stupid automatic decision according to the selected Baud rate ...
  if (normalBaud == 9600) {
    waitWithTasks(104); //delay at 9600
    Serial1.print("wait us:");
    Serial1.println("104");
  }
  else {
    waitWithTasks(52); //delay at 19200
    Serial1.print("wait us:");
    Serial1.println("52");
  }
}

Indeed , the only confirmation will be when tested on a LIN slave.
See below.

Best.

[coderatchance]

Here we go!
The Tiny 1624 at hand actually supports the LIN slave,
so only the following part of the code is necessary for a complete slave,
e.g. to print out the receiving data from the master !

#include <Arduino.h>
#include <avr/io.h>
#define LIN_BAUD 9600

//the pin to enable the TRANSCIEVER TJA1021 -> connected to the WAKE_N pin 2 SLP_N
byte txEnPin = 1;  //PA5
int incomingByte;

void setup() {

  // pin for enabling the transciever 
  pinMode(txEnPin, OUTPUT);

  //LIN setup
  Serial.swap(0);
  Serial.begin(LIN_BAUD, SERIAL_8N1); //original master and slave

  // Directly modify registers for LIN Auto-Baud (Constrained)
  USART0.CTRLB |= USART_RXMODE_LINAUTO_gc; // Enable LIN Auto-baud mode
  USART0.CTRLB |= USART_SFDEN_bm;          // Enable Start-of-Frame Detection
  USART0.CTRLB |= USART_WFB_bm;            // This ensures the hardware ignores current traffic and waits for a fresh frame

  //normal, print out serial
  Serial1.swap(0);
  Serial1.begin(9600);
  Serial1.println(" dev board 1: --- ATtiny1624 LIN Slave Starting --- ");

  //activate the Transceiver
  digitalWrite(txEnPin, HIGH);  

}//end of setup

void loop() {

  // Check if at least one byte has arrived in the buffer
  if (Serial.available() > 0) {

    // Read the oldest byte from the buffer
    incomingByte = Serial.read();

    // 1. Print formatted Hex with leading zero (best for LIN/Binary)
    Serial1.print("Hex: 0x");
    if (incomingByte < 0x10) Serial1.print("0");
    Serial1.print(incomingByte, HEX);

    // 2. Print Decimal value
    Serial1.print("\tDec: ");
    Serial1.print(incomingByte, DEC);

    // 3. Print Binary representation
    Serial1.print("\tBin: ");
    Serial1.println(incomingByte, BIN);

    // Special Action: Trigger if the specific NULL byte (0x00) is received
    if (incomingByte == 0x00) {
      Serial1.println(">> Special Case: Null Byte Detected!");
    }
  }

  // Error Handling: Check for "Inconsistent Sync Field"
  if (USART0.STATUS & USART_ISFIF_bm) {
    // If the Sync byte wasn't 0x55, the receiver halts.
    Serial1.println("halting");
    // You must toggle RXEN to reset it (as per 2026 errata).
    USART0.CTRLB &= ~USART_RXEN_bm;
    USART0.CTRLB |= USART_RXEN_bm;
    USART0.STATUS |= USART_ISFIF_bm; // Clear the flag
  }

}//end of LOOP

The analysis:

The program works beautifully, the led will be easily toggled, however, I guess the "wait" between the consecutively sending a command should be at lest 500mS ? This is the result that I got when using maximum speed ( 19200 ) .
Anyway, this is not a complete LIN application, for example, the so-called "schedule table" should be considered. This will depend on the number of commands, namely Frames send on the bus, etc. which calls for the application consideration and its functions...

This is rather a whole process of developing the LIN protocol on new Tinys, anyway, please comment, correct, etc.

Best.

DISCLAIMER :)

• this program does not consider the case of power down and back on, sleep-mode, etc. It should be noted that in such cases the LIN bus may hang etc. Anyway, this can be quickly solved with the so-called reinitialisation of the transceiver, etc.