LIN Telegramme mit Atmega und MCP2021 versenden

[Chris T. (chris0086)]

Hallo Leute,
ich benötige Hilfe bei der Umsetzung zum versenden von LIN Nachrichten 
per MCP2021 und einem Atmega.

Folgende Ausgangssituation:
Ich habe eine Abzugshaube deren Bedienteil als Master mit der 
Haubenelektronik kommuniziert.

Ich habe die Telegramme mit einem Peak LIN Adapter aufgezeichnet.
Es sind nur 4 unterschiedliche Telegramme die gesendet werden müssen.
In einem Telegramm steckt die einzustellende Stufe, der Rest ist immer 
gleich. (Ein Ausschnitt im Anhang)
Ich habe alle Zustände mitgeschnitten, sodass ich für jedes Telegramm 
auch die Checksumme habe. Muss also wahrscheinlich nicht mal so viel 
berechnen.
Ich muss nur die passenden Telegramme raus schicken.

Also die Hardware funktioniert erstmal denke ich, habe einfach per uart 
mal ein Hallo und eine Nachricht raus geschickt und den LA auf Async 
Serial gestellt. Auf der Lin Leitung wurde das was ich geschickt habe 
auch wieder gegeben (Siehe Anhang).

Jetzt geht es daran ein richtiges LIN Paket zu versenden, da wollte ich 
mal fragen ob jemand einen Codeschnipsel oder andere helfende Hinweise 
hat wie ich das am einfachsten angehe.

Vorrangig geht's um die richtige Umsetzung des Break-Signal und des 
Syncfeldes.
Ich habe bereits gelesen das man das mit dem Herabsetzen der Baudrate 
hinbekommt,
sowie Beitrag "Uart mit LIN Protokoll"
und
Beitrag "LIN Bus mit Atmega als Master (Botschaft senden)"
durchgelesen aber noch nicht wirklich weiter gekommen. Leider richten 
die Infos für einen Ansatz noch nicht aus :(

Kann mir da jemand helfen?

[Harald A. (embedded)]

Mit dem Umstellen der Baudrate geht es tatsächlich sehr gut! Wenn man 
per UART-Hardware raussendet, ist die Herausforderung, den Zeitpunkt zum 
Umstellen der Baudrate auf "Originalwert" herauszufinden. Das "UART 
Empty" kommt ja unmittelbar nach Absenden, das wäre zu früh. Man braucht 
ein "UART Busy" Flag, aber auch diese Info kommt manchmal etwas zu früh. 
Ob man zu diesem Zeitpunkt (sofern man daraus einen Interrupt ableiten 
kann) schon die Baudrate wieder umstellen kann, zeigt ein Test. Wenn das 
alles zu kompliziert wird, kann man auch einfach den UART "vom Portpin 
nehmen", die entsprechende Zeit Low einfach per Bitbanging erzeugen und 
die Kontrolle wieder an den UART übergeben. Frisst natürlich Rechenzeit.
Danach ist alles sehr einfach, Sync, ID, LEN, Daten und Checksumme 
nacheinander raussenden, ganz so als ob man eine "normale" UART vor sich 
hat. Mit der Checksumme musst Du mal nachrechnen, wie die das gemacht 
haben. Es gab zwischen den offiziellen LIN Versionen leichte 
Unterschiede, bei Nicht-Automotive wird auch gerne mal was anderes 
verwendet - muss man mal etwas nachrechnen und beobachten. Vielleicht 
sind das auch statische Botschaften, dann kannst du einfach kopieren.

Noch etwas: Der Master beginnt IMMER mit dem Break, Sync, ID und LEN, 
bei einer Antwort vom Slave muss dieser den Rest des Frames "auffüllen". 
Aber wie gesagt, Nicht-Automotive weichen gerne mal von Standards ab und 
verwenden eigene Logiken. Vielleicht schaust Du mit einem Logik-Analyzer 
an jeweils RX/TX des Bausteins Master und Slave, wer was tatsächlich 
sendet.

[Teee (Gast)]

Würde auch die Baudrate umschalten. Da LIN nur eine 1-Draht-Leitung hat, 
könnte man auch erst das Zeichen wieder zurücklesen und dann umschalten. 
Man müsste mal schauen, ob der Zeitpunkt dann passt. Dann einfach die 
Baudrate umschalten und 0x55 fürs Syncfiel, gefolgt von dem Rest, 
senden.

Harald A. schrieb:
> Noch etwas: Der Master beginnt IMMER mit dem Break, Sync, ID und LEN,
> bei einer Antwort vom Slave muss dieser den Rest des Frames

Genau, nur das LEN-Field habe ich noch nie gesehen. Das gibt es 
zumindestens nicht in der offizellen LIN-Spec.

[Rudolph (Gast)]

Wenn Du einen ATTiny87/ATTiny167 verwenden magst, die haben einen 
LIN-USART.
Der kümmert sich selber um solche Dinge wie Break, Sync und Checksumme.
Man muss auch die Daten nicht selber Byte-für-Byte auf den LIN werfen.

Dazu gibt es auch eine passende Application-Note bei Atmel.

[Harald (Gast)]

Teee schrieb:
> Genau, nur das LEN-Field habe ich noch nie gesehen. Das gibt es
> zumindestens nicht in der offizellen LIN-Spec.

Ups, sorry, Teee hat natürlich recht. Das war alles nur aus der 
Erinnerung geschrieben, daher der Fehler.

[Chris T. (chris0086)]

Hallo Leute,
danke für die Antworten. Ich musste erstmal einen anderen LIN 
Transceiver bestücken der auch mit Pegeln ab 5V zurecht kommt.
Jetzt hab ich mal meinen ersten Befehl raus geschickt und habe folgende 
Frage.
Wie muss ich die Baudratenumstellung machen damit das der UART auch 
'frisst'?
mit folgender Routine sende ich derzeit um die Kommunikation zu testen 
(Aufnahme mit dem LA um die Telgegramme zu vergleichen):

void USART_SendS(uint8_t *werte, uint8_t rep)
{
  //receive_string[0] = 1;
  uint8_t i;

  UCSR0B &= ~(1<<TXEN0);  // disable UART
    UBRR0H = UBRR_VAL_UH >> 8;
    UBRR0L = UBRR_VAL_UH & 0xFF;
    UCSR0B |= 1<<TXEN0;  // enable UART
    USART_Transmit(0x00);
    //_delay_us(400);
    UCSR0B &= ~(1<<TXEN0);  // disable UART
    UBRR0H = UBRR_VAL_U0 >> 8;
    UBRR0L = UBRR_VAL_U0 & 0xFF;
    UCSR0B |= 1<<TXEN0;  // enable UART
    USART_Transmit(0x55);

  for(i=0;i<rep;i++)
  {
    USART_Transmit(werte[i]);
  }
}

egal was ich für eine halbe Baudrate einstelle am LA ist der Headerbreak 
immer gleich lang (und das Telegramm wird vom LA nicht als Lin Telegramm 
erkannt), wenn ich natürlich das _delay_us einkommentiere passt die 
Länge und das Telegramm wird komplett als Lin Telegramm erkannt. Aber 
auf solche Methoden würde ich gerne verzichten.

[Rudolph R. (rudolph)]

Einmal reicht schon und es muss auch nicht die halbe Baudrate sein, die 
muss nur niedrig genug sein, damit 8 Null-Bits bei nomineller Bitrate 
wie 13 Null-Bits aussehen. Also für 19200 reichen <11800.

Aber auf das Ende der Übertragung sollte man schon warten.

[Chris T. (chris0086)]

Hallo Rudolph,
vielen Dank für deine Antwort.

Also auf das Ende der Übertragung warte ich doch eigentlich hier:

void USART_Transmit( char data )
{
  /* Wait for empty transmit buffer */
  while ( !( UCSR0A & (1<<UDRE0)) )
    ;
  /* Put data into buffer, sends the data */
  UDR0 = data;
}

oder meinst du etwas anderes?

[Rudolph (Gast)]

Der Schnipsel hat gefehlt...

Du wartest so nicht wirklich auf das Ende der Übertragung.
Der UART ist mit einem Byte gepuffert in Sende-Richtung und wenn Du mit 
UDRE0 prüfst, dann ist das beim ersten zu sendenden Byte quasi 
unmittelbar wieder auf 1.
Zudem prüfst Du vor der Übertragung, das ist dann zusätzlich falsch bei 
dem Programm und würde auch schief gehen wenn das Warten an sich richtig 
wäre.

Ein
while ( !( UCSR0A & (1<<TXC0)) );
nach dem
USART_Transmit(0x00);

dürfte einen kräftigen Unterschied machen.

[Chris T. (chris0086)]

Danke für die Korrektur :)

Wenn man darüber nachdenkt hätte man auch slebst darauf kommen müssen.
Also das erste Telegramm läuft jetzt soweit und wird auch von meinem LIN 
Dongle erkannt.
Jetzt habe ich aber das Problem, dass das erste Telegramm kommplett 
durch geht und das bei den nachfolgenden Telegrammen die 
Baudratenumstellung irgendwie nicht mehr gemacht wird. Der Headerbreak 
ist zu kurz und die Telegramme werden nichtmehr als solche erkannt. 
Dachte irgendwie das mir der Timer dazwischen funkt und hab mal noch cli 
und sei eingefügt aber bringt nix.
Hier mal der Code

#define T0_ON      TIMSK |= (1<<TOIE0)
#define T0_OFF      TIMSK &= ~(1<<TOIE0); TCNT0 = 0


void USART_SendS(uint8_t *werte, uint8_t rep)
{
  //receive_string[0] = 1;
  uint8_t i;
  cli();
  UCSR0B &= ~(1<<TXEN0);  // disable UART
    UBRR0H = UBRR_VAL_UH >> 8;
    UBRR0L = UBRR_VAL_UH & 0xFF;
    UCSR0B |= 1<<TXEN0;  // enable UART
    USART_Transmit(0x00);
    while ( !( UCSR0A & (1<<TXC0)) );

    UCSR0B &= ~(1<<TXEN0);  // disable UART
    UBRR0H = UBRR_VAL_U0 >> 8;
    UBRR0L = UBRR_VAL_U0 & 0xFF;
    UCSR0B |= 1<<TXEN0;  // enable UART
    USART_Transmit(0x55);

  for(i=0;i<rep;i++)
  {
    USART_Transmit(werte[i]);
  }
  sei();
}


ISR(TIMER0_OVF_vect)
{
  sendframe_status = 1;
}


int main(void)
{

    //USART initialisieren

  //USART0
    UBRR0H = UBRR_VAL_U0 >> 8;
    UBRR0L = UBRR_VAL_U0 & 0xFF;
    //USART1
    UBRR1H = UBRR_VAL_KNX >> 8;
    UBRR1L = UBRR_VAL_KNX & 0xFF;
    //USART0
    UCSR0B |= (1<<TXEN0);                // UART TX einschalten
    UCSR0B |= (1<<RXEN0);
    UCSR0B |= (1<<RXCIE0);
    UCSR0C |= (1<<URSEL0)|(1<<UCSZ00)| (1<<UCSZ01);    // Asynchron 8N1

  //USART1

    UCSR1B |= (1<<TXEN1);                // UART TX einschalten
    UCSR1B |= (1<<RXEN1);
    UCSR1B |= (1<<RXCIE1);
    UCSR1C |= (1<<URSEL1)|(1<<UCSZ10)| (1<<UCSZ11)| (1<<UPM11);    // Asynchron 8N1 even

    //Timer 1 konfigurieren
    TCCR1B |= (1<<CS12) | (1<<CS10);
    TCNT1 = T_PRELOAD;

    //Timer 0 konfigurieren
    TCCR0 |= (1<<CS02) | (1<<CS00);

    sei();

    UART1_Transmit('H');
    UART1_Transmit('a');
    UART1_Transmit('l');
    UART1_Transmit('l');
    UART1_Transmit('o');

    sendstr[0] = werte[0].id;
    sendstr[1] = werte[0].byte0;
    sendstr[2] = werte[0].byte1;
    sendstr[3] = werte[0].byte2;
    sendstr[4] = werte[0].byte3;
    sendstr[5] = werte[0].byte4;
    sendstr[6] = werte[0].checksum;
    
    USART_SendS(sendstr,7);

    T0_ON;
  while(1)
  {
    if(sendframe_status >= 1)
    {
      T0_OFF;
      USART_SendS(sendstr,7);
      sendframe_status =0;
      T0_ON;
    }
}

[Chris T. (chris0086)]

Habs jetzt noch mal mit dem Delay probiert.
Ich muss das schon auf 700 us stellen damit der Break lang genug ist.

void USART_SendS(uint8_t *werte, uint8_t rep)
{
  //receive_string[0] = 1;
  uint8_t i;

  UCSR0B &= ~(1<<TXEN0);  // disable UART
    UBRR0H = UBRR_VAL_UH >> 8;
    UBRR0L = UBRR_VAL_UH & 0xFF;
    UCSR0B |= (1<<TXEN0);  // enable UART
    USART_Transmit(0x00);
    while ( !( UCSR0A & (1<<TXC0)) );
    _delay_us(700);
    UCSR0B &= ~(1<<TXEN0);  // disable UART
    UBRR0H = UBRR_VAL_U0 >> 8;
    UBRR0L = UBRR_VAL_U0 & 0xFF;
    UCSR0B |= (1<<TXEN0);  // enable UART
    USART_Transmit(0x55);

  for(i=0;i<rep;i++)
  {
    USART_Transmit(werte[i]);
  }

}

Ich seh mal wieder nicht den Fehler

[Rudolph (Gast)]

So richtig durchschaue ich den Code nicht, der ist aber auch immer noch 
nicht vollständig und somit compilierbar.

Das mit dem Timer-Overflow ist auch ein seltsames Konstrukt.
Mit "T0_OFF" läuft der Timer übrigens weiter, wie lang ist dann die Zeit 
zwischen "T0_ON" und Interrupt?

Am Ende sollte doch eigentlich raus kommen, dass die Botschaften gemäß 
des Schedule-Tables sauber getimed raus gehen, zum Beispiel alle 10 ms 
eine Botschaft.

Auf einem 90CAN habe ich das mal mit dem UART-Sende-Interrupt umgesetzt.

Scheduler...Arrays füllen...
if(sent == 0)...
UBRR0 = 78; // 12660 Baud @ 16 MHz - Sync langsamer übertragen
UDR0 = 0x00; // Übertragung anschieben!
sent = 1;

ISR (USART0_TX_vect) // UART Sende-IRQ
{

 if(sent == 1)
 {
  UBRR0 = 51; // 19200 Baud @ 16 MHz
  UDR0 = 0x55; // Sync
  sent++;
  return;
 }

 if(send_message_number == 0)
 {
  if(sent > 11) // break+sync+id+8+checksumme
  {
   sent = 0;
   return;
  }
  UDR0 = lin_data_0[sent-2]; // ID, Datenbytes 1..8, Checksumme der Botschaft
 }

 if(send_message_number == 1)
 {
  if(sent > 2) // break+sync+id
  {
   return; // nichts machen, sent muss durch den Empfangs-IRQ zurückgesetzt werden
  }
  UDR0 = lin_data_1[sent-2]; // ID
 }

Na so in der Art, den originalen und vollständigen Code kann ich nicht 
posten.

Auf einem ATMega16M1 oder ATTiny167 ist das durch den LIN-USART alles 
viel einfacher.